As an application programmer dabbling in infrastructure, I am always looking at abstracting away the complexities of the infrastructure which allows me to focus on my application.
Consequently, I am a big fan of Platform as a Service (PaaS) but I also realize some of it's limitations of it 9;s adoption in the enterprise, primarily around lack of control.
Docker provides a via media. However, its earliest incarnation(s) did not provide the following right off the box tha t most PaaSes provide.
- Rolling upgrades
- Blue/Green and other deployments
Docker Swarm addresses many of these application related issues and tends to take an application-centric approach to infrastructure. So, let's dive right in and look at how to take advantage of some of these features right off the bo x.
Docker Swarm cluster on Azure
In an earlier blog, my colleague introduced Kubernetes using Azure Container Services.
Although Azure Container Services features Docker Swarm, we will be using Docker Swarm in what is referred to as Swarm mode which is not supported in Azure Container Services (yet).
Creating a Docker Swarm cluster in Swarm Mode
Generate an ssh key in preparation. More details are at https://github.com/Azure/acs-engine/blob/master/docs/ssh.md#key-management-and-agent-forwarding-with-windows-pageant. You will use the public key of the key generated as an input to the template below and use the private key to ssh to the VM that will be created.
You can create the cluster by clicking on the
Deploy to Azure button using the https://github.com/ragsns/azure-quickstart-templates/ tree/master/101-acsengine-swarmmode.
The template will generate a swarm mode cluster with a swarm master and agents as shown in the figure below.
Now might be the time to get a cup of coffee or whatever beverage of your liking.
From the Azure portal you should be able to see all the resources created as illustrated below.
Now ssh to the master node, via the IP address of the master VM and run the following command.
docker node ls
Which should yield and output that looks something like below.
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS lzr9t6hj4wxk795rbo0zfg1ta swarmm-agent-13957614000002 Ready Active tj1yvivboh6o17ark5wh87ozr swarmm-agent-13957614000000 Ready Active um7e625teqe4w1z1qucdr73z9 * swarmm-master-13957614-0 Ready Pause Leader
It shows the master and two agents that are part of the swarm. More details of containers in swarm mode is available at https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/swarm-mode.
We are almost ready to create services on the cluster.
Open up port 80
Before we create a service, there is a minor detail of opening up port 80 on the master which we'll use subsequently.
Start from the Resource Group, find the master load balancer and click on
Inbound NAT rules as shown below.
We will create an inbound rule for port 80 similar to port 22 (
ssh) that is created when the template wa s created as shown below.
Verify that the rule got created successfully as shown below.
Now we're ready to spin up services that can be accessed externally via the load balancer.
Any Dockerized application can run on a Docker Swarm, but we'll try some simple apps from the Docker public regis try such as
ragsns/docker-pets5000 which is a Python/Flask application derived from https://github.com/mark-church/docker-pets and
ragsns/spring-boot, which is a Spring Boot application.
Let's create the service with the following command
docker service create --replicas 1 --name docker-pets --detach=false --publish 80:5000 ragsns/docker-pets5000
Which should show the service starting and eventually to a running state as shown below. It should forward port 5000 from the app to port 80 of the container.
ymwepi7e2njzfip7iirsrx9zp overall progress: 1 out of 1 tasks 1/1: running verify: Waiting 1 seconds to verify that tasks are stable...
Run the following command
docker service ps docker-pets
The output shows that the service is running on one of the swarm agents.
ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS v1bjt1fkm44l docker-pets.1 ragsns/docker-pets5000:latest swarmm-agent-13957614000000 Running Running about a minute ago
If you ssh to the swarm agent and run the following command
You should notice that the ID of the service is derived from the name of the container running the docker image on th e respective agent.
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES c279df299fcc ragsns/docker-pets5000:latest "/bin/sh -c 'pytho..." 7 minutes ago Up 7 minu tes (healthy) 5000/tcp docker-pets.1.v1bjt1fkm44l5fjmw80rgy63y
Now, let's verify that the app is running, port is open and so on. Point your browser to the IP address of the master and you should be able to see the app running. It should also list the same container ID.
Let's stop this application and start another application as below.
docker service rm docker-pets
docker service create --replicas 1 --name spring-boot --detach=false --publish 80:8080 ragsns/spring-boot
Let's verify the application is running via the following
This should yield the single line output as below.
Now, we'll go ahead and scale the application.
Let's scale the app to three instances with the following command.
docker service update --replicas=3 spring-boot --detach=false
Which should yield an output that the app is being scaled. Eventually, they will all be running.
spring-boot overall progress: 1 out of 3 tasks 1/3: running 2/3: preparing 3/3: preparing
ps command as we did earlier
docker service ps spring-boot
should show the three running instances as below.
ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS g5o7ko1fkxqa spring-boot.1 ragsns/spring-boot:latest swarmm-agent-13957614000000 Running Ru nning 2 minutes ago ve355jvyynym spring-boot.2 ragsns/spring-boot:latest swarmm-agent-13957614000002 Running Ru nning about a minute ago oij482mwmbh5 spring-boot.3 ragsns/spring-boot:latest swarmm-agent-13957614000002 Running Ru nning about a minute ago
If you run the following command a few times.
curl -s 188.8.131.52/env | grep HOSTNAME
The output from four runs is shown below.
HOSTNAME = 154ef66b1746 HOSTNAME = b8fe94c04fed HOSTNAME = 7f15068c4200 HOSTNAME = 154ef66b1746
Notice that the Load balancer is cycling the load to the different containers that are part of the swarm running the application instance.
Next we move to application self-healing.
To illustrate App self-healing, we'll kill off an instance. There are multiple ways of doing this but here's the easiest way.
and that should yield an output something like below
curl: (52) Empty reply from server
echoing the death of the particular instance.
However, the instance automatically restarts and this is the self-healing part of the platform.
To check this, we will run the previous command four times as we did before.
The output will list different IDs since the application instance got restarted cycling between the number of replicas we specified.
HOSTNAME = 154ef66b1746 HOSTNAME = b2c824c7de22 HOSTNAME = 9f5c40b71187 HOSTNAME = b2c824c7de22
Run the following command
docker service ps spring-boot
The output below show some instances that shutdown and others that got restarted automagically. There is only one original instance still running. The output shows some instances that were restarted.
ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS 4ixl8mnqx9j8 spring-boot.1 ragsns/spring-boot:latest swarmm-agent-13957614000000 Running Ru nning 24 minutes ago g5o7ko1fkxqa \_ spring-boot.1 ragsns/spring-boot:latest swarmm-agent-13957614000000 Shutdown Co mplete 24 minutes ago ve355jvyynym spring-boot.2 ragsns/spring-boot:latest swarmm-agent-13957614000002 Running Ru nning about an hour ago aiazav7gw6tj spring-boot.3 ragsns/spring-boot:latest swarmm-agent-13957614000002 Running Ru nning 25 minutes ago oij482mwmbh5 \_ spring-boot.3 ragsns/spring-boot:latest swarmm-agent-13957614000002 Shutdown Co mplete 25 minutes ago
Conclusions and Summary
We created a Docker Swarm container in swarm mode on Azure using templates and looked at some of the Application deployment features it provides ala Platform as a Service. The concept of a service in Docker Swarm allows the infrastructure to be treated from an application centric viewpoint by permitting scaling, self-healing and other related app deployment features.
The goal of this blog is not to exhaustively go through the myriad features of Docker Swarm. However, using Azure as a platform provides an easy way to deploy apps leveraging newer and industry standard initiatives with more coming in the future.