During the past couple of months, I fell in love with containerization. I was surprised with a power and flexibility it provides for tasks that previously weren’t as easy as they should be.
For example: For my assembly class, I should write a 32bit - x86 code. I was having troubles setting up the environment on my mac (issues with compatibility with a test server provided by school). Therefore it was a lot easier for me to spin-up a virtual machine, install the required tools and do my work there. But that’s overkill just for the task as simple as compiling an assembly code. With containers, it feels almost like a native experience.
In general, containers are at the top of their popularity. Solutions like Docker and Kubernetes are becoming an industry standard and more and more developers are incorporating those tools in their day to day workflow. It got to the point when it’s almost trivial to containerize (or you can say Dockerize) your application.
The actual power of Docker could be observed when dealing with an application that is based on micro-services. You have to develop, build, test, run and deploy all of those components in parallel. The process may get tricky and you could end up with a bunch of shell scripts to help you with it. On the other way, with Docker, it is simplified to the point, when it’s a matter of few commands.
Interesting (and fun!) way to use Docker is to shrink your development environment on your machine into the two applications. Code editor and docker itself. Everything else could run inside the containers, separately from your host. Therefore, you don’t have to worry about messing up or trying something new. Running a database server becomes trivial.
Deployment to the production
When considering deployment environment for our microservice / container based application, we have to consider a few important aspects. To make an advantage of the architecture and use it to its full potential, we should be able to scale our containers within a seconds, to adapt to the load as quickly as possible.
The simplest and easiest way is to use some cloud provider, for example, Microsoft Azure. You can do complex things with just a few clicks or commands.
With Azure, you have several different options for containers deployment. The simples one that provides a great flexibility is probably the Web App for Containers. It supports deployment of a single container or a multi-container application defined by Docker’s compose file or Kubernetes’s Pod definition. You can configure it to work with any image repository, public or private.
In the rest of this post, I’ll show you step-by-step how you can deploy your multi-container solution using the docker and compose file.
Azure’s Web App for Containers
During the demonstration, I’ll use
Azure Pass subscription. You can use pay-as-you-go or some other subscription / pass if you have one. You can list your existing subscriptions with the
az account list command.
First, you should create a resource group to be able to manage all related resources at once.
az group create \ --name DemoGroup \ --location "West Europe" \ --subscription Azure\ Pass
To be able to store docker images inside the repository, you need to create an Azure Container Registry. You can use it as your private container repo for a reasonable price. It is also a good practice to store your images as close to the deploy infrastructure as possible to improve the download speed.
az acr create \ --name DemoACR \ --sku Basic \ --admin-enabled true \ --resource-group DemoGroup \ --subscription Azure\ Pass
To print credentials, use:
az acr credentials show \ --name DemoACR \ --subscription Azure\ Pass
Next, you can log in to your ACR with docker CLI on your machine.
docker login DemoACR.azurecr.io --username DemoACR
Then it is important to tag your image. I’m taking a
poc-gateway-msvc image and adding a new tag to it, with a prefix of the registry.
docker tag poc-gateway-msvc DemoACR.azurecr.io/poc-gateway-msv
After that, you are able to push an image to your private remote repository.
docker push DemoACR.azurecr.io/poc-gateway-msvc
You can list remote images to verify that everything is correct.
az acr repository list \ --name DemoACR \ --subscription Azure\ Pass
We are halfway there! We created a custom private repository to store images of our application. Therefore, we can finally create a deployment infrastructure.
Before everything else, we need to create an App Service Plan. It’s an imaginary machine (set of computing resources) that you’ll be using to host your running containers.
az appservice plan create \ --name DemoAppService \ --sku S1 \ --is-linux \ --subscription Azure\ Pass \ --resource-group DemoGroup
Next, we can create an actual web app. We are providing a definition of our multi-container application using the docker’s compose file format. It’s important that you point image definition inside the compose file to your private image registry on Azure like so:
az webapp create \ --name DemoWebApp \ --plan DemoAppService \ --multicontainer-config-type "compose" \ --multicontainer-config-file ./docker-compose.yml \ --subscription Azure\ Pass \ --resource-group DemoGroup
Tip: Azure is unable to parse array like definition of environment variables. Therefore, in your
docker-compose.yml file, use dictionary format like so:
environment: ASPNETCORE_ENVIRONMENT: Development
Our web app is running, but there is one more step that we need to do to be able to deploy and run our containerized application. Since we are using private image repository, we need to set up the Web App to be able to authenticate to the registry.
Tip: You need to provide a full registry URL, with the http or https prefix.
az webapp config container set \ --name DemoWebApp \ --docker-registry-server-url https://DemoACR.azurecr.io \ --docker-registry-server-user DemoACR \ --docker-registry-server-password XXX \ --subscription Azure\ Pass \ --resource-group DemoGroup
After that step, our application should be running.
Tip: There is a restriction, that only one container could be opened for the access from the public.
When you are done, you can delete created resources by deleting the resource group.
az group delete \ --name DemoGroup \ --subscription Azure\ Pass
Deploying a complex multi-container application to the Microsoft Azure is simple and straightforward. The environment can be set up in a couple of minutes, right from your terminal window. Choosing an Azure is providing you with great benefits like the ability to scale horizontally and vertically within a few seconds.