Uh oh!
There was an error while loading. Please reload this page.
feat(docker): managed-mode env-var bootstrap - #32
Conversation
The same Docker image now serves both standalone and managed (aisix.cloud tenant) deployments. Two pieces: - config.managed.yaml — bootstrap template baked at /etc/aisix/config.managed.yaml. Has placeholder etcd endpoint (overwritten by /dp/register response), managed.enabled = true, and unbindable admin (defence-in-depth if managed mode somehow flipped off). All real per-DP secrets come from env vars. - docker/entrypoint.sh — picks the config file via AISIX_CONFIG_PATH (default /etc/aisix/config.yaml). Standalone users mount their config at the default path; managed users point AISIX_CONFIG_PATH at the baked file and inject AISIX_MANAGED__REGISTRATION_TOKEN + AISIX_MANAGED__CP_BASE_URL. Existing main.rs bootstrap (PR #30 + #31) already does the rest: register-and-persist on first boot, reload bundle on subsequent boots, spawn heartbeat worker. Tests: parses_managed_block_with_register_fields locks the YAML shape so any new required field on ManagedConfig fails CI loudly instead of silently breaking the image. Docs: docs/managed-mode.md walks operators through first boot, restart semantics, env-var override matrix, and common errors. This unblocks AISIX-Cloud E2E scenarios 2/3/4 — the test harness can now `docker run` aisix with a deployment_token and have the DP register itself without prebaked certs.
There was a problem hiding this comment.
Pull request overview
Enables a single Docker image to support both standalone deployments (operator-mounted config) and managed-mode (aisix.cloud tenant) deployments by baking a managed bootstrap config into the image and selecting the config path at runtime via an entrypoint.
Changes:
- Add a baked
config.managed.yamltemplate intended for managed-mode bootstrapping. - Introduce
docker/entrypoint.shto choose the config file viaAISIX_CONFIG_PATHand execaisix --config .... - Add managed-mode documentation and a config parsing test to lock the managed YAML shape.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| docs/managed-mode.md | New guide for running the official image in managed mode (register + heartbeat + env overrides). |
| docker/entrypoint.sh | New container entrypoint that selects config path via AISIX_CONFIG_PATH and runs aisix. |
| crates/aisix-core/src/config.rs | Adds a regression test ensuring managed-mode YAML shape remains valid as ManagedConfig evolves. |
| config.managed.yaml | Adds a managed-mode bootstrap config intended to be baked into the image. |
| Dockerfile | Bakes the managed config, adds the entrypoint script, and switches ENTRYPOINT to use it. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| @@ -0,0 +1,72 @@ | |||
| # aisix — managed-mode bootstrap config (aisix.cloud tenant). | |||
| # | |||
| # Used by the official Docker image as `/etc/aisix/config.yaml`. | |||
There was a problem hiding this comment.
The header comment says this file is used as /etc/aisix/config.yaml, but the Dockerfile copies it to /etc/aisix/config.managed.yaml and the docs/entrypoint reference that path. This mismatch is likely to confuse operators; update the comment (or the copy destination) so the documented path matches the image layout.
| # Used by the official Docker image as `/etc/aisix/config.yaml`. | |
| # Used by the official Docker image as `/etc/aisix/config.managed.yaml`. |
| exit 64 | ||
| fi | ||
| exec /usr/local/bin/aisix --config "$CONFIG_PATH" |
There was a problem hiding this comment.
The entrypoint ignores any arguments passed to docker run because it always execs aisix --config ... with no "$@" forwarding. That prevents common uses like docker run <image> -- --help or passing additional CLI flags. Forward the args (and/or treat args as an override command) so the container remains composable.
| exec /usr/local/bin/aisix --config "$CONFIG_PATH" | |
| exec /usr/local/bin/aisix --config "$CONFIG_PATH""$@" |
Summary
Lets the same Docker image serve both standalone and managed (aisix.cloud tenant) deployments without re-templating config files.
The existing bootstrap from #30 + #31 already does the heavy lifting: register-and-persist on first boot, reload mTLS bundle on restart, spawn heartbeat worker.
Why now
Unblocks AISIX-Cloud E2E scenarios 2 / 3 / 4. The test harness can now `docker run ghcr.io/moonming/ai-gateway:aisix-e2e` with a deployment_token from the SaaS layer and the DP registers itself without any pre-baked certs.
Tests
Out of scope
Test plan