Deploy a legacy ASP.NET application in Docker Swarm mode

The first step to deploy a legacy ASP.NET application in Docker Swarm mode, is to break down the application into several modules and then deploy each module as a different service in Docker Swarm. After that, we have to define a reverse proxy server for forwarding the requests to the specific module as per user request.

Read more about how to breakdown the application architecture in the previous post,

It is recommended to use Docker Swarm mode for production deployment because there are several advantages with that,

  1. It supports creation of service instead of container. A service will create a container internally on behalf of us. The advantage with the service is that, if any problem happened in the internal container, then it will automatically restart and create a new container without breaking the application.
  2. Load balancing is supported here. Though some limitations are there like routing mesh is not supported in Windows containers, but still provides a way to implement load balancing with DNS round robin routing algorithm.

Let us consider our same example of HMS where we have already break down the application into several modules.

Now let us consider we have two virtual machines HostA and HostB where Docker is running. We are planning to create a swarm network over these two nodes to deploy our application.

Step 1: Create an Overlay network,

docker network create -d overlay –subnet= –gateway= swarmnet 

Make sure that no network overlaps with the overlay network. IP address should be given unique.

Step 2: Initialize Swarm on HostA. IP address of the HostA is

docker swarm init –advertise-addr –listen-addr

Step 3: Create the HMS Proxy service,

docker service create –name hmsproxy –mode global –endpoint-mode dnsrr –hostname hmsproxy –publish mode=host,target=80,published=80 –network=swarmnet hmsproxy

Here hmsproxy is the image of the HMS Proxy (see the previous post).

Step 4: Create HMS Billing service,

docker service create –name hmsbilling –endpoint-mode dnsrr –hostname hmsbilling –network=swarmnet hmsbilling

Here hmsbilling is the image of HMS Billing module.

Step 5: Similar way, we can create the service of the hms services, state server and other modules.

Step 6: Get the worker token with the below command from HostA,

docker swarm join-token worker

Step 7: Run the below command in HostB to make it join as worker node –

docker swarm join –token <Token>

Step 8: Scale up all the services with the below command except HMS Proxy,

docker service scale hmsbilling=2

Here two instances of the HMS Billing service would be created. Now, the number of services to be created is dependent on the load (number of requests to be served per second) and resource availability of the host. This needs to be find out using heuristic approach, there is short-cut rule for this.

We will not be able to scale up HMS Proxy because it is mentioned as global. There would be always one instance of the global service. This is a disadvantage of DNS RR load balancing approach. Users will be accessing this HMS proxy to access the application. This is open to the outside world. Anyone who wants to connect to the swarm mode has to come through this proxy server.

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.