See below for an example of an Azure Container Instance deployment using the container_group variable. The subnet used for the container group must be delegated to Microsoft.ContainerInstance/containerGroups.
Basic Example
The example includes some additional optional configuration including a user assigned managed identity that can be used to grant the container access to other Azure resources and some Azure File Shares that are mounted as volumes within the container for persistent storage.
Containers that need a secret (passwords, API keys, client secrets) must not receive it through environment_variables in tfvars. Instead, list the env var names in secure_environment_variable_secrets:
The list contains env var names only — no secret key or value. For each entry the container_group module injects local.secrets[lower(<env var name>)] as a secure_environment_variables entry on the container, so SMTP_PASSWORD is always backed by the root variable smtp_password. To make a new secret available:
Declare a sensitive = true variable named lower(<env var name>) in src/variables.secrets.tf (value supplied via TF_VAR_<name> at runtime).
Add it to local.secrets in src/locals.tf under the same name.
If the lowercase name is missing from local.secrets, terraform plan fails with a key-not-found error rather than deploying an empty value.
secure_environment_variables (a plain map) still exists for non-secret values that should merely be hidden from the Azure portal; secret-backed entries are merged over it. See SMTP Forwarder for a complete worked example.
Advanced Example
The next example shows how to deploy a Caddy reverse proxy in front of a container to separate