refine docker quickstart

quickstart/docker/all-in-one/README.md

@@ -1,4 +1,4 @@
-# All-in-one Ziti Docker quickstart
+# All-in-one Docker quickstart
 
 This Docker Compose project runs `ziti edge quickstart` in a container while persisting configs, PKI, database, etc. in
 a Docker named volume. You may instead persist the state in a filesystem directory on the Docker host by setting env var
@@ -9,20 +9,26 @@ a Docker named volume. You may instead persist the state in a filesystem directo
 This is the primary use case for this project: running the `ziti edge quickstart` command in the official
 `openziti/ziti-cli` container image.
 
+1.You need only the `compose.yml` file in this directory to run your own Ziti network.
+
+    ```bash
+    wget https://get.openziti.io/dock/all-in-one/compose.yml
+    ```
+
 1. In this "all-in-one" sub-directory, pull the container images. This makes the latest official release image available
    locally.
 
     ```bash
     docker compose pull
     ```
 
-2. Run the project and store the PKI, DB, and YAML configs in a sub-directory.
+2. Run it.
 
     ```bash
-    ZITI_HOME=./quickstart docker compose up
+    docker compose up
     ```
 
-3. Modify configuration and bounce the container.
+3. Modify the configuration and bounce the container.
 
     Modify the configs in the `./quickstart/` sub-directory adjacent to the `compose.yml` file.
 
@@ -33,7 +39,7 @@ This is the primary use case for this project: running the `ziti edge quickstart
 4. Observe the logs
 
     ```bash
-    docker compose logs quickstart --follow
+    docker compose logs --follow
     ```
 
 5. Run the CLI inside the quickstart environment.
@@ -52,75 +58,19 @@ This is the primary use case for this project: running the `ziti edge quickstart
     results: 1-2 of 2
     ```
 
-## Develop Ziti
+### Save config on the Docker Host
 
-This is a secondary use case for this Docker Compose project that replaces the `ziti` binary in the container image with
-the one you build locally with `go build`.
+The default storage option is to store the database, etc., in a named volume managed by Docker. Alternatively, you can store things in a subdirectory on the Docker host by setting `ZITI_HOME`.
 
-1. In the top-level directory of the `ziti` project, build the binary.
-
-    ```bash
-    go build -o ./build ./...
-    ```
+Destroy the old network so you can start over.
 
-    The build command can also be run from this "all-in-one" sub-directory.
-
-    ```bash
-    go build -o ../../../build ../../../...
-    ```
-
-2. In the "all-in-one" sub-directory, with `Dockerfile` present:
-
-    ```bash
-    ZITI_CLI_TAG=local docker compose up --build
-    ```
-
-    By adding this `--build` option to the `up` command, the container image is built from the Dockerfile with your
-    locally built `ziti` binary instead of pulling the default `openziti/ziti-cli` container image from Docker Hub. In
-    the `compose.yml`, the Docker build context is hard-coded to `../../../` (three levels up from this directory at the
-    top level of a Git working copy of the source repo). Setting `ZITI_CLI_TAG=local` tags the locally-built container
-    image differently from the official release image's `:latest` tag so you can tell them apart.
-
-### Troubleshooting
-
-#### Changing File Locations
-
-The Compose project file `compose.yml` and `Dockerfile` have file paths that represent the assumption they're placed in
-a sub-directory three levels deep in a checked-out copy of the `openziti/ziti` source repository. This allows the
-Dockerfile to copy the built binary from the top-level directory `./build`. You may set the environment variable
-`ARTIFACTS_DIR` to a different path relative to the build context (top-level directory of the source repo) to change the
-location where the container image build looks for the locally-built `ziti` binary.
-
-#### Building `ziti` in Docker
-
-If the binary you build on the Docker host doesn't run in the container due to an environment issue, such as a GLIBC
-version mismatch, you have the option to build `ziti` in the container every time you run
-`ZITI_CLI_TAG=local docker compose up --build`.
-
-Change `Dockerfile` like this, and run `ZITI_CLI_TAG=local docker compose up --build` to build the
-checked-out source tree and run the quickstart with the build.
-
-```dockerfile
-FROM golang:1.22-bookworm AS builder
-ARG ARTIFACTS_DIR=./build
-WORKDIR /app
-COPY go.mod go.sum ./
-RUN go mod download
-COPY . .
-RUN go build -o /app/${ARTIFACTS_DIR} ./...
-
-FROM debian:bookworm-slim
-COPY --from=builder /app/${ARTIFACTS_DIR} /usr/local/bin/
-
-CMD ["ziti"]
+```bash
+docker compose down --volumes
 ```
 
-#### Gotcha - Not Clobbering the Downloaded Container Image
+Run it again with a different storage location.
 
-With `docker compose up --build`, the downloaded container image specified in `image` is replaced locally with the one
-built from the Dockerfile.  This clobbers any image you may have pulled from the registry, which can lead to confusion.
-You can prevent this by setting environment variable like `ZITI_CLI_TAG=local docker compose up --build` to avoid
-clobbering the default `:latest` tag.
+```bash
+ZITI_HOME=./config docker compose up
+```
 
-If you already clobbered `:latest` just run `ZITI_CLI_TAG=latest docker compose pull` to refresh your local copy from
-the registry.

quickstart/docker/all-in-one/compose.override.yml

@@ -1,4 +1,13 @@
 services:
+  quickstart:
+    build:
+      # the build context is the root of the ziti repo so that BuildKit can access the built ziti executable in /build
+      # and the Dockerfile
+      context: ../../../ 
+      dockerfile: ./quickstart/docker/all-in-one/Dockerfile
+      args:
+        # path of the directory containing the locally-built ziti executable; relative to the build context
+        ARTIFACTS_DIR: ./build
   quickstart-test:
     profiles:
       - test

quickstart/docker/all-in-one/compose.yml

@@ -2,14 +2,6 @@ services:
   quickstart:
     image: ${ZITI_CLI_IMAGE:-docker.io/openziti/ziti-cli}:${ZITI_CLI_TAG:-latest}
     restart: unless-stopped
-    build:
-      # the build context is the root of the ziti repo so that BuildKit can access the built ziti executable in /build
-      # and the Dockerfile
-      context: ../../../ 
-      dockerfile: ./quickstart/docker/all-in-one/Dockerfile
-      args:
-        # path of the directory containing the locally-built ziti executable; relative to the build context
-        ARTIFACTS_DIR: ./build
     networks:
       quickstart:
         # this allows other containers to use the same external DNS name to reach the quickstart container from within the
@@ -87,4 +79,4 @@ networks:
 volumes:
   # this will not be used if you switch from named volume to bind mount volume
   ziti_home:
-    driver: local
+    driver: local