In Docker and on swarms, you can have containers and services.
We will go over some differences and set these up.
Basically, a container runs on one host and a service is on one or more. Let's look at this a little closer.
Container
Let's start a container on Docker1.
NOTE: I removed all images from all three servers, so I'm starting with empty Docker systems.
On Docker1, we'll download the web service 'httpd'. Use the command:
docker pull httpd
Running the command 'docker images' should show that the httpd image is local on Docker1. To start the container, we'll use the command:
docker run -d --name web httpd
The container should now run and we can verify this by finding the IP Address of the web container with the command:
docker container inspect web | grep IPAddr
The result should be that the IP Address of the container is '172.17.0.2'. You can open your web browser and go to the address for the web container. The page should appear saying 'It works!'. You can also use the address of the hostname.
If you go to Docker2 or Docker3 and open the IP Address in the web browser, there should be no result. The container on Docker1 is accessible only to the local host. If you wanted, you can ping '172.17.0.2' from the other servers, but it will only work on Docker1.
Now, let's stop the container with the command 'docker stop web'.
Service
We've seen what a container will do, so let's try it as a service.
To start the service, we can run it on one host in the swarm, so let's set it up on Docker1. Use the command:
docker service create --name web -p 80:80 httpd
This creates a service named 'web' from the 'httpd' image. It opened the port 80 to the service and mapped to an external port of 80. We can make the external port another one, but there is no need at this point.
Once the service is running, we can see the service information with the command 'docker service ls'. The command should return the information for the new service we started.
Let's pause a minute to verify some things. On my Docker1 system, I can run the command 'docker node ls' and see that Docker1 is the manager of the swarm and that there are three nodes active, shown in Figure 1.
FIGURE 1
If we run the command 'docker service ps web', we can see the service, on my system, replicated and moved to Docker3 as shown in Figure 2.
FIGURE 2
Previously, before creating the service, there were no images on any system except Docker1. Since the service has been created on Docker1 and it replicated to Docker3, you can run 'docker images' on Docker3 to see that the 'httpd' image is now present there as well.
You should also notice in Figure 2 that there is only one instance of the 'web' service in the swarm, noted by 'web.1'. By running 'docker service ls', you should see that it lists the service as being replicated (1/1). We did not specify the number of replicas, so the default is 1.
Now, how do we access the web service we have running? You can use a browser to access any IP Address of any port listed from the 'ifconfig' command. You can also place the hostname in the address bar. Be sure to not use 'https://' at the beginning of the address since the website is not using a secure connection. The prefix should be 'http://'.
Even though only one node in the swarm is running a service, any system can access the service through any node in the swarm, using any IP Address accessible to the local port.
For example, I'm running Docker on Ubuntu systems in VirtualBox. The node has an IP Address on my local network with all my systems on my home network. The node has a local IP Address of '192.168.1.109'. Going to any system on my network, on the same subnet, I can go to the node address on the web browser and I see the website running as a Docker service.
So, the differences should be apparent between a container and service. They both run that same images, but we manage the running image in different ways.
Updating Service Resources
From the manager system, in my case Docker1, I can run the command 'docker stats <name>' to get resource usage of a service. The results are basic and not too exact. To see more exact measurements, you need to run a tool like top from inside the service. For now, 'docker stats' can be a little helpful. In our case, the results of the command show that there is no resource usage since there are no systems accessing the web server.
Let's say we want to limit the amount of resources that a service uses from the node we replicated it to in the swarm.
First, we'll look at the memory. We can specify a soft and a hard limit on the amount of RAM to be used for the service. The soft limit is the minimum amount, while the hard limit is the maximum amount used by the service.
To update the properties of the service, we can use the command 'docker service update' with specific parameters to change certain options. For memory, we can do a soft limit and a hard limit with the command:
docker service update –limit-memory=128m –reserver-memory=256m web
The command will set the minimum memory used by the 'web' service to 128 MB and a maximum of 256 MB.
In the same manner, we can also limit the CPU resources. The values given for the CPU are in decimal percentages. For example, '.5' would be 50% of a CPU. If you have a system with four CPUs, then you have 400% to work with when setting limits. Be sure not to use 100% of all the CPUs you have in the system. Leave a percentage to manage the Operating System.
So, to limit the CPU to a range of 75% (.75) to 150% (1.5), the command would be:
docker service update --limit-cpu=.75 --reserve-cpu=1.5
Of course, you can set the CPU and memory in the same command, just include all parameters. Once updated, the service will stop and restart with the new configuration.
When changing settings, you can use the parameter '--detach=false' to show the convergence of the replicas. Even if there is only one replica, you see that the service is being restarted and then the system pauses for 5 seconds to allow all systems to share information and have convergence.
Updating Replicas
If we set no number of replicas, then the default is one. You should have seen this when we added 'web' to the swarm.
Let's say we now want the 'web' running on two nodes in the swarm. We can use the command:
docker service update --replicas 2 --detach=false web
Keep in mind that if you have 4 nodes, you can run over 4 replicas. More than one service will run on some nodes. By employing more replicas, you will have more redundancy, unless a physical node fails.
Conclusion
Running services in a swarm provides redundancy in a swarm. Setting up a service and managing it is a very important job for anyone dealing with Docker in a business environment.
Be sure to practice adding and even removing replicas for the new services you create. Dealing with a swarm is very important in Docker.
We will go over some differences and set these up.
Basically, a container runs on one host and a service is on one or more. Let's look at this a little closer.
Container
Let's start a container on Docker1.
NOTE: I removed all images from all three servers, so I'm starting with empty Docker systems.
On Docker1, we'll download the web service 'httpd'. Use the command:
docker pull httpd
Running the command 'docker images' should show that the httpd image is local on Docker1. To start the container, we'll use the command:
docker run -d --name web httpd
The container should now run and we can verify this by finding the IP Address of the web container with the command:
docker container inspect web | grep IPAddr
The result should be that the IP Address of the container is '172.17.0.2'. You can open your web browser and go to the address for the web container. The page should appear saying 'It works!'. You can also use the address of the hostname.
If you go to Docker2 or Docker3 and open the IP Address in the web browser, there should be no result. The container on Docker1 is accessible only to the local host. If you wanted, you can ping '172.17.0.2' from the other servers, but it will only work on Docker1.
Now, let's stop the container with the command 'docker stop web'.
Service
We've seen what a container will do, so let's try it as a service.
To start the service, we can run it on one host in the swarm, so let's set it up on Docker1. Use the command:
docker service create --name web -p 80:80 httpd
This creates a service named 'web' from the 'httpd' image. It opened the port 80 to the service and mapped to an external port of 80. We can make the external port another one, but there is no need at this point.
Once the service is running, we can see the service information with the command 'docker service ls'. The command should return the information for the new service we started.
Let's pause a minute to verify some things. On my Docker1 system, I can run the command 'docker node ls' and see that Docker1 is the manager of the swarm and that there are three nodes active, shown in Figure 1.
FIGURE 1
If we run the command 'docker service ps web', we can see the service, on my system, replicated and moved to Docker3 as shown in Figure 2.
FIGURE 2
Previously, before creating the service, there were no images on any system except Docker1. Since the service has been created on Docker1 and it replicated to Docker3, you can run 'docker images' on Docker3 to see that the 'httpd' image is now present there as well.
You should also notice in Figure 2 that there is only one instance of the 'web' service in the swarm, noted by 'web.1'. By running 'docker service ls', you should see that it lists the service as being replicated (1/1). We did not specify the number of replicas, so the default is 1.
Now, how do we access the web service we have running? You can use a browser to access any IP Address of any port listed from the 'ifconfig' command. You can also place the hostname in the address bar. Be sure to not use 'https://' at the beginning of the address since the website is not using a secure connection. The prefix should be 'http://'.
Even though only one node in the swarm is running a service, any system can access the service through any node in the swarm, using any IP Address accessible to the local port.
For example, I'm running Docker on Ubuntu systems in VirtualBox. The node has an IP Address on my local network with all my systems on my home network. The node has a local IP Address of '192.168.1.109'. Going to any system on my network, on the same subnet, I can go to the node address on the web browser and I see the website running as a Docker service.
So, the differences should be apparent between a container and service. They both run that same images, but we manage the running image in different ways.
Updating Service Resources
From the manager system, in my case Docker1, I can run the command 'docker stats <name>' to get resource usage of a service. The results are basic and not too exact. To see more exact measurements, you need to run a tool like top from inside the service. For now, 'docker stats' can be a little helpful. In our case, the results of the command show that there is no resource usage since there are no systems accessing the web server.
Let's say we want to limit the amount of resources that a service uses from the node we replicated it to in the swarm.
First, we'll look at the memory. We can specify a soft and a hard limit on the amount of RAM to be used for the service. The soft limit is the minimum amount, while the hard limit is the maximum amount used by the service.
To update the properties of the service, we can use the command 'docker service update' with specific parameters to change certain options. For memory, we can do a soft limit and a hard limit with the command:
docker service update –limit-memory=128m –reserver-memory=256m web
The command will set the minimum memory used by the 'web' service to 128 MB and a maximum of 256 MB.
In the same manner, we can also limit the CPU resources. The values given for the CPU are in decimal percentages. For example, '.5' would be 50% of a CPU. If you have a system with four CPUs, then you have 400% to work with when setting limits. Be sure not to use 100% of all the CPUs you have in the system. Leave a percentage to manage the Operating System.
So, to limit the CPU to a range of 75% (.75) to 150% (1.5), the command would be:
docker service update --limit-cpu=.75 --reserve-cpu=1.5
Of course, you can set the CPU and memory in the same command, just include all parameters. Once updated, the service will stop and restart with the new configuration.
When changing settings, you can use the parameter '--detach=false' to show the convergence of the replicas. Even if there is only one replica, you see that the service is being restarted and then the system pauses for 5 seconds to allow all systems to share information and have convergence.
Updating Replicas
If we set no number of replicas, then the default is one. You should have seen this when we added 'web' to the swarm.
Let's say we now want the 'web' running on two nodes in the swarm. We can use the command:
docker service update --replicas 2 --detach=false web
Keep in mind that if you have 4 nodes, you can run over 4 replicas. More than one service will run on some nodes. By employing more replicas, you will have more redundancy, unless a physical node fails.
Conclusion
Running services in a swarm provides redundancy in a swarm. Setting up a service and managing it is a very important job for anyone dealing with Docker in a business environment.
Be sure to practice adding and even removing replicas for the new services you create. Dealing with a swarm is very important in Docker.
