Azure Container Apps

The azure-container-apps target sets environment variables on a container in an Azure Container App through the Azure Resource Manager API. It reads the app, sets or replaces the pushed variables in the container's env, and writes the containers back. Variables fnox does not push are left alone.

Config type	azure-container-apps
Requires	An identity that can update the container app
Readable afterwards	Yes, anyone who can read the app can see the vars

Quick start

[targets.api]
type = "azure-container-apps"
subscription = "00000000-0000-0000-0000-000000000000"
resource_group = "rg-dev"
app = "ca-api-dev"

[secrets]
DATABASE_URL = { provider = "kv", value = "database-url", push = ["api"] }
LOG_LEVEL = { default = "info", push = ["api"] }

fnox push --target api --force

Configuration

Field	Default	Description
subscription	required	Subscription ID that holds the container app.
resource_group	required	Resource group that holds the container app.
app	required	Container app name.
container	the only container	Container to set the variables in. Required when the app has several.
auth	"default"	"default" or "managed-identity".
managed_identity_client_id	none	Client ID of a user-assigned managed identity, with auth = "managed-identity".

Authentication

The same credential chain as the azure-sm and azure-ac providers: a service principal from AZURE_TENANT_ID, AZURE_CLIENT_ID and AZURE_CLIENT_SECRET, otherwise the az or azd login, or the host's managed identity with auth = "managed-identity". The identity needs permission to update the app, such as the Contributor role on it. Values go to the API over HTTPS, not onto a command line.

Notes

• One revision per push. Every env change creates a new revision, so fnox writes all of a target's variables in a single request. A push whose values already match writes nothing.
• Concurrent changes. When Azure returns an ETag for the app (fnox logs a warning if it does not), the write carries it as If-Match, so if another deployment changes the app in between, fnox writes nothing and reports it; run the push again. Without an ETag a concurrent change can be overwritten.
• Waiting. If Azure answers the update with a long-running operation, fnox polls it (for up to five minutes, at the pace Azure asks for) and reports a failed update as failed. It does not wait for the new revision to become ready; rolling the image and waiting for readiness stays in your deploy script.
• Plain variables only. A pushed variable is stored as a plain value, replacing an existing variable of that name even if it used a secretRef. The app's secrets are not touched.
• Public cloud only. The target talks to management.azure.com.
• A failed batch marks every variable in it as failed.