Parameterize YAML files

[mikeball]

The ability to access environment variables from within the yaml files when used from azure cli would be very helpful.

We are unable/unwilling to store sensitive data in yaml files which get checked into source control, and so only make them available as environment variables. For example the <PasswordGoesHere> placeholder in the yaml file below, but also many other items such as <subscription>, <rg>, <image>, etc..

> az containerapp update --resource-group myresourcegroup --name myappname --yaml app.yaml

app.yaml:

kubeEnvironmentId: /subscriptions/<subscription>/resourceGroups/<rg>/providers/Microsoft.Web/kubeEnvironments/<environment name>
configuration:
  activeRevisionsMode: multiple
  registries:
  - server: myacr.azurecr.io
    username: someuser
    passwordSecretRef: acr-password
  secrets:
  - name: acr-password
    value: <PasswordGoesHere>
template:
  containers:
  - image: myacr.azurecr.io/myimage:tag
    name: myimage
    resources:
      cpu: 0.5
      memory: 1Gi
  scale:
    maxReplicas: 1
    minReplicas: 0

Perhaps the yaml file would allow placeholders ${SUBSCRIPTION} and ${REGISTRY_PASSWORD} which could be replaced by environment variables SUBSCRIPTION and REGISTRY_PASSWORD.

kubeEnvironmentId: /subscriptions/${SUBSCRIPTION}/resourceGroups/<rg>/providers/Microsoft.Web/kubeEnvironments/<environment name>
configuration:
  activeRevisionsMode: multiple
  registries:
  - server: myacr.azurecr.io
    username: someuser
    passwordSecretRef: acr-password
  secrets:
  - name: acr-password
    value: ${REGISTRY_PASSWORD}
template:
  containers:
  - image: myacr.azurecr.io/myimage:tag
    name: myimage
    resources:
      cpu: 0.5
      memory: 1Gi
  scale:
    maxReplicas: 1
    minReplicas: 0

[mikeball]

Practical option for now, just made a small script to use a template yaml file and generate a yaml file with the secrets in it, which is then deleted immediately after using as --yaml parameter.

container-app.tpl.yaml

kubeEnvironmentId: /subscriptions/${AZ_SUBSCRIPTION}/resourceGroups/${AZ_RESOURCEGROUP}/providers/Microsoft.Web/kubeEnvironments/${AZ_APPENVIRONMENT}
configuration:
  ingress:
    external: true
    targetPort: 8080
  activeRevisionsMode: single
  registries:
  - server: ${REGISTRY_SERVER}
    username: ${REGISTRY_USERNAME}
    passwordSecretRef: registry-password
  secrets:
  - name: registry-password
    value: ${REGISTRY_PASSWORD}
template:
  containers:
  - image: ${CONTAINER_IMAGE}
    name: echo-gateway
    resources:
      cpu: 0.25
      memory: .5Gi
  scale:
    maxReplicas: 5
    minReplicas: 0

generate-container-app-yaml-file.sh :

# remove generated files
rm -rf out/*

# create script file that will pick up environment vars
# and replace placeholders in the yaml template
( echo "cat <<EOF >out/container-app.yaml";
  cat container-app.tpl.yaml;
  # echo "EOF";
) >out/create-container-app.yaml.sh

# create the yaml file with env vars
./out/create-container-app.yaml.sh

# remove temp script that we used to generate yaml
rm -r out/create-container-app.yaml.sh

[kendallroden]

Removed comments that were misleading - we are considering yaml parameterization in the upcoming months

[racinmat]

this would be so helpful for me. Or if you allowed to send the yaml to stdin and read the yaml from stdin, we could use envsubst etc. for that

[ali-akdag]

Any update on this? The investigation label was assigned almost 2 years ago. Using the YAML as input has greater value over the CLI command in terms of CI/CD deployments using templates and passing parameters. The CLI is missing some features such as volume mounts etc.