Okay, welcome back. In this lesson, I'm going to introduce you to the Azure container registry, ACR. ACR enables you to create and host your own private Docker container registries directly within Azure.

Creating your own Azure container registry allows you to push container images into it that might be considered private to your organization and for which you wouldn't want to push into a public container registry such as DockerHub.

Creating a new ACR is simple and quick with options to do it either within the Azure web portal or on the command line using the Azure CLI.

The following diagram highlights the typical developer workflow that is used when working with both AKS and ACR. The workflow involves the following sequence: One, the developer creates a Dockerfile on their local workstation containing the build instructions for their container image. Two, the developer performs a docker build locally and tags it. The format of the tag must include the custom ACR hostname. This is used at container push time, instructing the push where to send the container image. Three, the developer performs a docker push of the container image using the tag created in the previous step. When this is completed, the container image that the developer built locally will have just been uploaded into the ACR registry. Four, the developer then creates a Kubernetes YAML manifest file which declares the desired running state for the pods within the AKS cluster. The manifest file references the container image using the same tag created in step two. Five, the developer applies the manifest file into the AKS cluster. Six, AKS now pulls down the container image from ACR authenticating to ACR before the image is pulled down. And seven, AKS finally launches the pods on the worker nodes.

Integrating ACR with AKS can be accomplished multiple ways. The first way is to create a Kubernetes secret encapsulating the authentication credentials for ACR within your cluster, and then have the developer reference this secret within their deployment manifest file using the imagePullSecret property.

The second way is to leverage a Kubernetes service account within the cluster, and then have the developer reference the service account within their deployment manifest file using the serviceAccountName property. A Kubernetes secret is still used, but this time is referenced by the service account. Both this option and the previous option can be used within clusters that run outside of AKS.

The third and final way is to leverage an Azure AD service principal. Unlike the first two approaches, this approach involves integration that happens outside of the cluster. The benefit with this approach is that the deployment manifest only needs to specify the image tag within the image property.

AKS will authenticate to ACR using the service principal. This makes the deployment manifests much simpler. The service principal used and configured within AKS must be granted ACRPull permissions to access the Azure container registry allowing it to pull down any referenced images. This option will only work when the cluster runs within AKS.

Okay, that completes this lesson. In this lesson, I introduced you to ACR and how it can be used to host your own private container registries within Azure. I then showed you three ways in which you can configure authentication between AKS and ACR to allow AKS to pull down container images.

Okay, go ahead and close this lesson, and I'll see shortly in the next one.