📦 Container Registry & Images

We will deploy & use a private registry to hold the application container images. This is not strictly necessary as we could pull the images directly from the public, however using a private registry is a more realistic approach.

The fully managed Azure Container Registry is what we will be using for this workshop.

🚀 ACR Deployment

Deploying a new ACR is very simple:

az acr create --name $ACR_NAME --resource-group $RES_GROUP \
--sku Standard \
--admin-enabled true

When you pick a name for the resource with $ACR_NAME, this has to be globally unique, and not contain any underscores, dots or hyphens. Name must also be in lowercase.

📥 Importing Images

For the sake of speed and maintaining the focus on Kubernetes we will import pre-built images from another public registry (GitHub Container Registry), rather than build them from source.

We will cover what the application does and what these containers are for in the next section, for now we can just import them.

To do so we use the az acr import command:

# Import application frontend container image
az acr import --name $ACR_NAME --resource-group $RES_GROUP \
--source ghcr.io/benc-uk/nanomon-frontend:latest \
--image nanomon-frontend:latest

# Import application data API container image
az acr import --name $ACR_NAME --resource-group $RES_GROUP \
--source ghcr.io/benc-uk/nanomon-api:latest \
--image nanomon-api:latest

# Import application runner container image
az acr import --name $ACR_NAME --resource-group $RES_GROUP \
--source ghcr.io/benc-uk/nanomon-runner:latest \
--image nanomon-runner:latest

# Import custom PostgreSQL container image
az acr import --name $ACR_NAME --resource-group $RES_GROUP \
--source ghcr.io/benc-uk/nanomon-postgres:latest \
--image nanomon-postgres:latest

If you wish to check and see imported images, you can go over to the ACR resource in the Azure portal, and into the 'Repositories' section.

🔌 Connect AKS to ACR - as Azure Subscription Owner

Kuberenetes requires a way to authenticate and access images stored in private registries. There are a number of ways to enable Kubernetes to pull images from a private registry, however AKS provides a simple way to configure this through the Azure CLI. The downside is this requires you to have 'Owner' permission within the subscription, in order to assign the role.

az aks update --name $AKS_NAME --resource-group $RES_GROUP --attach-acr $ACR_NAME

If you are curious what this command does, it is essentially assigning the "ACR Pull" Azure IAM role on the managed identity used by AKS, to the ACR resource. If all of that sounds like gibberish, don't worry about it and move on!

If you see the following error Could not create a role assignment for ACR. Are you an Owner on this subscription?, you will need to proceed to the alternative approach below.

🔌 Connect AKS to ACR - Alternative Workaround

If you do not have 'Owner' permissions in Azure, you will need to fall back to an alternative approach. This involves two things:

Adding an Secret to the cluster containing the credentials to pull images from the ACR.
Including a reference to this Secret in every Deployment you create or update the ServiceAccount used by the Pods to reference this Secret.

Run these commands to create the Secret with the ACR credentials, and patch the default ServiceAccount:

kubectl create secret docker-registry acr-creds \
  --docker-server=$ACR_NAME.azurecr.io \
  --docker-username=$ACR_NAME \
  --docker-password=$(az acr credential show --name $ACR_NAME --query "passwords[0].value" -o tsv)

kubectl patch serviceaccount default --patch '"imagePullSecrets": [{"name": "acr-creds" }]'

💥 IMPORTANT! Do NOT follow this approach of patching the default ServiceAccount in production or a cluster running real workloads, treat this as a simplifying workaround.

These two commands introduce a lot of new Kubernetes concepts in one go! Don't worry about them for now, some of this such as Secrets we'll go into later. If the command is successful, move on.