Upload your image on Azure Container Registry

In my previous article, we went through the process of uploading our own image to Docker Hub. Even though it's perfectly fine to use Docker Hub, some organizations prefer using their own registries, either due to additional functionality that they might offer or due to policies and regulations. Since Azure offers a container registry resource that would fit most use cases, I thought we could try to upload some images and at least use it for test and dev purposes! 

First things first, the tools we're going to need. To upload an image to an ACR we need:

1. An Azure Container Registry
2. Docker Desktop
3. Azure CLI

Starting from the top of the list, we need the ACR resource to which we're going to upload the images. Clone my Github bicep repository and switch to the ContainerRegistry-ImageUpload-001/110-Bicep/110-AzureContainerRegistry/ folder. Update the parameters in the deploy script and submit the deployment. The output should be similar to the below:

If everything goes right, you should now have a new ACR, just like the one above!

The next step from here is to log in to the registry using docker. First, we need to get the credentials using the az acr credential show command. Make sure you're using the right name and resource group!

Now we need to build our images on our local system. Switch to the ContainerRegistry-ImageUpload-001/120-Dockerfiles/110-Web/ folder of the repository that contains the docker file for our web server and execute the docker build -t web . command. Docker will build an image named web using the docker file in the directory as context.

You can follow the same procedure for the database image located in the 120-Database folder (optional).

So, the images have been successfully built and are ready to be uploaded to the registry! To upload an image, we need to tag it and then push it, as shown below:

The command docker tag web [ACRLoginServer]/[imageName]:[imageVersion] tags the local image web according to the details of the registry, and the command docker push [ACRLoginServer]/[imageName]:[imageVersion] pushes it to the registry.

Make sure you're using the right values for the ACR and the names of the images. The names in the tag command should be the same used in the docker build command!

To verify the outcome of the process, you can get the images in your ACR using the az acr repository list command:

In this case, I've uploaded an image for the web server and an image for the database server. 

In the coming article, I'm going to use this approach to deploy a multi-container app on Azure AppService. Stay tuned!

Popular posts from this blog

Domain Controller Machine Password Reset

Image
On my lab environment, I've configured two Active Directory sites since most enterprises have offices in more that one places. My lab however is not running 24/7 and the domain controllers in the second site are rarely turned on in order to save resources. This leads to issues with the Active Directory replication such as the "The target principal name is incorrect" error when I execute:  repadmin /syncall /AdeP. To remedy the issue, we have to reset the machine password of the domain controller that has been offline. First off, we are going to stop and disable the Kerberos Key Distribution Center (kdc) service on the problematic domain controller, in our case DC4. There may be some tickets in the cache so we should also clear them using klist purge Now it's time to change the machine password of the domain controller using the command netdom resetpwd /s:dc3 /ud:lab\administrator /pd:* Replace the "lab\administrator" with an account on your
Keep reading

Configuring a Certificate on Exchange Receive Connector

Today's article is about configuring Exchange receive connectors with specific certificates. Out of the box, Exchange uses self signed certificates to provide TLS secured mail flow. This will definitely be an issue if you expose the SMTP protocol to client computers since they won't trust the certificate. In this article we are going to configure a certificate that was issued by a third part authority to the Client Frontend receive connector. We'll start with getting the thumbprint of the certificate using the Get-ExchangeCertificate cmdlet: [PS] C:\> Get-ExchangeCertificate Thumbprint                               Subject ----------                               ------- 241B864DC82C664FECBA18B8D54987AAFB65B4C2 CN=*.lab.com, ... D4D210886B34E690191A1F008C78FDD0E7325DD4 CN=Exchange2013A 960171662EB261162F9C8CBE12E0B75D6F06ABB0 CN=Microsoft Exchange Server Auth Certificate 2690324B827A9F2B75D59104F81CAAA57CDD627B CN=WMSvc-Exchange2013A [PS]
Keep reading

Running Multiple NGINX Ingress Controllers in AKS

Image
In some of the previous articles of this blog, we went through the process of installing NGINX as the Ingress Controller in AKS clusters. Either for applications that should be available directly from the public internet, or for applications that should only be accessed from networks considered internal. In the majority of the cases, however, and given that an AKS cluster is an environment that is designed to host multiple applications and provide economy at scale, additional ingress controllers may be required. In this post, we're going to go through the process of deploying an additional NGINX ingress controller that is going to be used for internal applications. The below diagram depicts the desired outcome: The Angular application is published via the public NGINX through the Azure Load Balancer that has been assigned a public IP. The .NET app is published by a different set of NGINX pods that are deployed in a different namespace and their ingress controller service is connect
Keep reading