New Azure Sample: ACI in VNet with Init and Sidecar Containers

Hey there! I have recently published a new Azure Sample: ACI in VNet with Sidecar Containers. It has generated a bit of controversy (there is a reason why I picked such a crowded image for the post title), so let me add some color to it.

But let me give you the TL;DR first: the goal of this sample is exploring different technologies around Azure Container Instances, not suggesting to deploy this architecture in production.

What is the New Sample About?

The sample uses Github workflows to deploy this architecture:

• The application is deployed in an Azure Container Instance (could be multiple ones for load balancing) inside of a Virtual Network.
• The Azure Container Instance accesses an Azure SQL Database over a private endpoint.
• Azure Application Gateway is used to expose the application to the public Internet, configured for end-to-end SSL.
• LetsEncrypt Certificates are generated automatically on the fly and stored in Azure Key Vault.
• The application ACIs have four containers:
  • The main application, which is an API implemented with Python Flask
  • A simple web frontend to the API, using PHP
  • A sidecar ngnix container providing SSL termination
  • An init container that updates Azure Private DNS Zones, to make sure that if the IP addresses for the ACI instances change, the internal FQDN to reach each ACI stays the same.
• There is a second Azure Container Instance with a dashboard (the previous picture is actually a screenshot of that dashboard application) that shows in real time the accesses to the database (the bar chart on the right). The real time dashboard is based on Python Dash.
• All container images are stored in a dedicated Azure Container Registry.
• All of this can be deployed using Github workflows provided with the sample.

How are the Github Actions implemented?

There are a bunch of workflows defined:

The last workflow, “Deploy full app”, is a concatenation of the previous six. The individual steps have been left as separate workflows for testing purposes.

Each of the individual steps in the workflows is implemented by an Azure CLI script stored in the scripts folder. For example, to build ACR images the workflow looks like this:

      - name: Build images to ACR
        uses: azure/CLI@v1
        with:
          azcliversion: latest
          inlineScript: |
            chmod +x $GITHUB_WORKSPACE/scripts/build_images.sh
            $GITHUB_WORKSPACE/scripts/build_images.sh \
                -g=${{ env.resource_group }} \
                -r=${{ env.repo_name }} \
                -d=$GITHUB_WORKSPACE

Should I Deploy This in Production?

Short answer: NO.

The goal of this sample is demonstrating different Azure technologies to gain a deeper understanding of them:

• How Azure Container Instances and private link work
• How Azure Container Instances deployed in Virtual Networks interact with VNet DNS and Azure Private DNS Zones
• How to use nginx as sidecar container in ACI to implement SSL
• How to use init containers to run initialization activities on Azure. It is updating Azure DNS Private Zones in this example, but it could be something else such as updating the firewall rules for a certain Azure PaaS service, for example
• Automatic LetsEncrypt certificate generation and interaction between Azure Key Vault and the rest of the components.

However, in order to demonstrate those concepts I have made some compromises that go against some fundamental best practices that I would recommend for production environments:

• The Github actions are mostly based on imperative Azure CLI scripts. Using declarative configuration such as Azure ARM templates or Terraform would be preferred
• Additionally I am not using any existing Github actions that would have made the deployment simpler, but I am doing everything with Azure CLI for a more granular control.
• Be careful when using FQDNs as backend in the Azure Application Gateway, since DNS changes will not be refreshed automatically, and you need to reset the backend pool to propagate DNS changes. At this point you can just configure the new IPs, but I wanted to keep the init container for demo purposes.
• For a better management of complex container environments, using an orchestrated platform such as Azure Kubernetes Service might make more sense in some situations. With Kubernetes you would get functionality such as embedded ingress control (including Azure Application Gateway), automatic service discovery or tighter integration to Azure Key Vault and Azure identities.
• I am using pretty large images (Ubuntu and CentOS) for the code in this sample. For your production images I would recommend to use smaller images with only the components you need.

Then, How Should I Use This Sample?

If you are interested in any of the technology aspects above, you can use this sample to explore how they work in Azure. For example, I get many questions around LetsEncrypt, Azure Key Vault and Azure Container Instances, or the interaction between ACI and Private Link. Another possibility is using this sample as a hackathon activity, where this architecture or a similar one might be the target of the hacking exercise.

You could certainly take some ideas of this sample for your production environments, such as having ACI running in a VNet with private link access to other Azure PaaS, the code for generating LetsEncrypt certs, or using sidecar or init containers to improve security.

But please do not use the whole sample as a reference architecture or best practices guide.

I hope this helps!