When Docker released its latest version, Docker Engine v1.12, it included quite a few changes to the capabilities provided by Docker Swarm. In today\u2019s article, we\u2019ll be exploring how to deploy a service using Docker\u2019s Swarm Mode.<\/p>\n
Before we can deploy a service on a Docker Engine Swarm, we will first need to set up a Swarm Cluster. Since we\u2019re showing capabilities added with 1.12, we will also be installing the latest version of Docker Engine.<\/p>\n
The following instructions will guide you through installing Docker Engine on Ubuntu 16.04. For other versions and platforms, you can follow Docker\u2019s official installation guide<\/a>.<\/p>\n For this installation, we\u2019ll be using the standard installation method for Ubuntu, which relies on the Apt package manager. Since we will be installing the latest version of Docker Engine, we need to configure Apt to pull the The first step in configuring Apt to use a new repository is to add that repository\u2019s public key into Apt\u2019s cache with the The above With Docker\u2019s public key now imported, we can configure Apt to use the Docker Project\u2019s repository server. We will do this by adding an entry within the When we refresh Apt\u2019s package cache, Apt will look through all files within the To refresh Apt\u2019s package cache, we can run the This will cause Apt to repopulate its list of repositories by rereading all of its configuration files, including the one we just added. It will also query those repositories to cache a list of available packages.<\/p>\n Before installing Docker Engine, we need to install a prerequisite package. The To install this package, we will use the In that With Apt configured and the At this point, we should have With this, we can see that both the Server and Client versions are !New Call-to-action<\/p>\n From this point on within this article, we will be executing tasks from several machines. To help make things a bit more clear, I have included the hostname in the command examples.<\/p>\n We will start our Swarm Cluster with two nodes. At this point, both of these nodes should have Docker Engine installed based on the instructions above.<\/p>\n When creating the Swarm Cluster, we will need to designate a node manager. For this example, we\u2019ll be using a host by the name of With the above command, in addition to the After running the Docker Swarm Mode can support multiple node managers. It will, however, elect one of them to be the primary node manager which will be responsible for orchestration within the Swarm.<\/p>\n With the Swarm Cluster created, we can now add a new node worker using the In this example, we added In addition to its node manager duties, a node manager is also a node worker, which means it will also run tasks for our Swarm Cluster.<\/p>\n With the previous commands executed, we now have a basic two-node Swarm Cluster. We can verify the status of this cluster by executing the From the output of this command, we can see that both With Docker Swarm Mode, a service is a long-running Docker container that can be deployed to any node worker. It\u2019s something that either remote systems or other containers within the swarm can connect to and consume.<\/p>\n For this example, we\u2019re going to deploy a Redis service.<\/p>\n A replicated service is a Docker Swarm service that has a specified number of replicas running. These replicas consist of multiple instances of the specified Docker container. In our case, each replica will be a unique Redis instance.<\/p>\n To create our new service, we\u2019ll use the In addition to specifying the In the output, we can see there are The Since we have validated that the service is running, we can try to connect to this service from a remote system with the From the connection above, we were successful in connecting to the When we created the When Docker publishes a port for a service, it does so by listening on that port across all nodes within the Swarm Cluster. When traffic arrives on that port, that traffic is then routed to a container running for that service. While this concept is pretty standard when all nodes are running a service\u2019s container, this concept gets interesting when we have more nodes than we do replicas.<\/p>\n To see how this works, let\u2019s add a third node worker to the Swarm Cluster.<\/p>\n To add another node worker, we can simply repeat the installation and setup steps in the first part of this article. Since we already covered those steps, we\u2019ll skip ahead to the point where we have a three-node Swarm Cluster. We can once again check the status of this cluster by running the We can see that the cluster consists of three hosts:<\/p>\n When we created our service with two replicas, it created a task (container) on With replicated services, Docker Swarm\u2019s goal is to ensure that there is a task (container) running for every replica specified. When we created the At this point, we have an interesting situation: We have a service that\u2019s running on Earlier when I described how Docker publishes a service port, I mentioned that it does so by publishing that port across all nodes within the Swarm. What\u2019s interesting about this is what happens when we connect to a node worker that isn\u2019t running any containers (tasks) associated with our service.<\/p>\n Let\u2019s take a look at what happens when we connect to What\u2019s interesting about this is that our connection was successful. It was successful despite the fact that Docker calls this ingress load balancing<\/em>. The way it works is that all node workers listen for connections to published service ports. When that service is called by external systems, the receiving node will accept the traffic and internally load balance it using an internal DNS service that Docker maintains.<\/p>\n So even if we scaled out our Swarm cluster to 100 node workers, end users of our All of this rerouting and load balancing is completely transparent to the end user. It all happens within the Swarm Cluster.<\/p>\n At this point, we have the If we wanted our We could alternatively do this automatically by making our service a Global Service. A Global Service in Docker Swarm Mode is used to create a service that has a task running on every node worker automatically. This is useful for common services such as Redis that may be leveraged internally by other services.<\/p>\n To show this in action, let\u2019s go ahead and recreate our The command to create a Global Service is the same With the service now created, we can see how Docker distributed our tasks for this service by once again executing the We can see that when the service was created as a Global Service, a task was then started on every node worker within our Swarm Cluster.<\/p>\n In this article, we not only installed Docker Engine, we also set up a Swarm Cluster, deployed a replicated service, and then created a Global Service.<\/p>\n In a recent article, I not only installed Kubernetes, I also created a Kubernetes service<\/a>. In comparing the Docker Swarm Mode services with the Kubernetes services, I personally find that Swarm Mode services were easier to get set up and created. For someone who simply wishes to use the \u201cservices\u201d features of Kubernetes and doesn\u2019t need some of its other capabilities, Docker Swarm Mode may be an easier alternative.<\/p>\nSetting up the Docker Apt repository<\/h3>\n
docker-engine<\/code> package from Docker\u2019s official Apt repository rather than the systems preconfigured repositories.<\/p>\nAdd Docker\u2019s Public Key<\/h2>\n
apt-key<\/code> command.<\/p>\n# apt-key adv --keyserver hkp:\/\/p80.pool.sks-keyservers.net:80 --recv-keys 58118E89F3A912897C070ADBF76221572C52609D<\/pre>\n
apt-key<\/code> command requests the specified key (58118E89F3A912897C070ADBF76221572C52609D<\/code>), from the p80.pool.sks-keyservers.net<\/code> key server. This public key will be used to validate all packages downloaded from the new repository.<\/p>\nSpecifying Docker\u2019s repository location<\/h2>\n
\/etc\/apt\/sources.list.d\/<\/code> directory.<\/p>\n# echo \"deb https:\/\/apt.dockerproject.org\/repo ubuntu-xenial main\" >> \/etc\/apt\/sources.list.d\/docker.list<\/pre>\n
sources.list.d\/<\/code> directory to find new package repositories. The command I just showed you creates (if it doesn\u2019t already exist) a new file called docker.list<\/code> with an entry that adds the apt.dockerproject.org<\/code> repository.<\/p>\nUpdating Apt\u2019s package cache<\/h2>\n
apt-get<\/code> command with the update<\/code> option.<\/p>\n# apt-get update<\/pre>\n
Installing the
linux-image-extra<\/code> prerequisite<\/h3>\nlinux-image-extra<\/code> package is a kernel specific package that\u2019s needed for Ubuntu systems to support the aufs<\/code> storage driver. This driver is used by Docker for mounting volumes within containers.<\/p>\napt-get<\/code> command again, but this time with the install<\/code> option.<\/p>\n# apt-get install linux-image-extra-$(uname -r)<\/pre>\n
apt-get<\/code> command, the $(uname -r)<\/code> portion or the command will return the kernel version for the current running kernel. Any kernel updates to this system should include the installation of the appropriate linux-image-extra<\/code> package version that coincides with the new kernel version. If this package is not updated as well, some issues may arise with Docker\u2019s ability to mount volumes.<\/p>\nInstall Docker Engine<\/h3>\n
linux-image-extra<\/code> prerequisite package installed, we can now move to installing Docker Engine. To do so, we will once again use the apt-get<\/code> command with the install<\/code> option to install the docker-engine<\/code> package.<\/p>\n# apt-get install docker-engine<\/pre>\n
Docker Engine v1.12.0<\/code> or newer installed. To verify that we have the correct version, we can execute the docker<\/code> command with the version<\/code> option.<\/p>\n# docker version\r\nClient:\r\n Version: 1.12.0\r\n API version: 1.24\r\n Go version: go1.6.3\r\n Git commit: 8eab29e\r\n Built: Thu Jul 28 22:11:10 2016\r\n OS\/Arch: linux\/amd64\r\n\r\nServer:\r\n Version: 1.12.0\r\n API version: 1.24\r\n Go version: go1.6.3\r\n Git commit: 8eab29e\r\n Built: Thu Jul 28 22:11:10 2016\r\n OS\/Arch: linux\/amd64<\/pre>\n
1.12.0<\/code>. From here, we can move on to creating our Swarm.<\/p>\nCreating a Docker Swarm<\/h3>\n
swarm-01<\/code> as a node manager. To make swarm-01<\/code> a node manager, we need to create our Swarm Cluster by executing a command on swarm-01<\/code> first. The command we will be executing is the docker<\/code> command with the swarm init<\/code> options.<\/p>\nroot@swarm-01:~# docker swarm init --advertise-addr 10.0.0.1\r\nSwarm initialized: current node (awwiap1z5vtxponawdqndl0e7) is now a manager.\r\n\r\nTo add a worker to this swarm, run the following command:\r\n docker swarm join \\\r\n --token SWMTKN-1-51pzs5ax8dmp3h0ic72m9wq9vtagevp1ncrgik115qwo058ie6-3fokbd3onl2i8r7dowtlwh7kb \\\r\n 10.0.0.1:2377\r\n\r\nTo add a manager to this swarm, run the following command:\r\n docker swarm join \\\r\n --token SWMTKN-1-51pzs5ax8dmp3h0ic72m9wq9vtagevp1ncrgik115qwo058ie6-bwex7fd4u5aov4naa5trcxs34 \\\r\n 10.0.0.1:2377<\/pre>\n
swarm init<\/code>, we also specified the --advertise-addr<\/code> flag with a value of 10.0.0.1<\/code>. This is the IP that the Swarm node manager will use to advertise the Swarm Cluster Service. While this address can be a private IP, it\u2019s important to note that in order for nodes to join this swarm, those nodes will need to be able to connect to the node manager over this IP on port 2377<\/code>.<\/p>\ndocker swarm init<\/code> command, we can see that the swarm-01<\/code> was given a node name (awwiap1z5vtxponawdqndl0e7<\/code>) and made the manager of this swarm. The output also supplies two commands: one command is to add a node worker to the swarm and the other is to add another node manager to the swarm.<\/p>\nAdding a node worker to the Swarm Cluster<\/h2>\n
docker<\/code> command provided by the output of the Swarm creation.<\/p>\nroot@swarm-02:~# docker swarm join \\\r\n> --token SWMTKN-1-51pzs5ax8dmp3h0ic72m9wq9vtagevp1ncrgik115qwo058ie6-3fokbd3onl2i8r7dowtlwh7kb \\\r\n> 10.0.0.1:2377\r\nThis node joined a swarm as a worker.<\/pre>\n
swarm-02<\/code> to the swarm as a node worker. A node worker is a member of the Swarm Cluster whose role is to run tasks; in this case, tasks are containers. The node manager on the other hand has a role of managing the orchestration of tasks (containers) and maintaining the Swarm Cluster itself.<\/p>\nViewing the current Swarm nodes<\/h2>\n
docker<\/code> command with the node ls<\/code> options.<\/p>\nroot@swarm-01:~# docker node ls\r\nID HOSTNAME STATUS AVAILABILITY MANAGER STATUS\r\n13evr7hmiujjanbnu3n92dphk swarm-02.example.com Ready Active \r\nawwiap1z5vtxponawdqndl0e7 * swarm-01.example.com Ready Active Leader<\/pre>\n
swarm-01<\/code> and swarm-02<\/code> are in a Ready<\/code> and Active<\/code> state. With this, we can now move on to deploying services to this Swarm Cluster.<\/p>\nCreating a Service<\/h2>\n
Deploying a Replicated Service<\/h3>\n
docker<\/code> command while specifying the service create<\/code> options. The followingw command will create a service named redis<\/code> that has 2<\/code> replicas and publishes port 6379<\/code> across the cluster.<\/p>\nroot@swarm-01:~# docker service create --name redis --replicas 2 --publish 6379:6379 redis\r\ner238pvukeqdev10nfmh9q1kr<\/pre>\n
service create<\/code> options, we also used the --name<\/code> flag to name the service redis<\/code> and the --replicas<\/code> flag to specify that this service should run on 2<\/code> different nodes. We can validate that it is in fact running on both nodes by executing the docker<\/code> command with the service ls<\/code> options.<\/p>\nroot@swarm-01:~# docker service ls\r\nID NAME REPLICAS IMAGE COMMAND\r\ner238pvukeqd redis 2\/2 redis<\/pre>\n
2<\/code> of 2<\/code> replicas currently running. If we want to see more details on these tasks, we can run the docker<\/code> command with the service ps<\/code> option.<\/p>\nroot@swarm-01:~# docker service ps redis\r\nID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR\r\n5lr10nbpy91csmc91cew5cul1 redis.1 redis swarm-02.example.com Running Running 40 minutes ago \r\n1t77jsgo1qajxxdekbenl4pgk redis.2 redis swarm-01.example.com Running Running 40 minutes ago<\/pre>\n
service ps<\/code> option will show the tasks (containers) for the specified service. In this example, we can see the redis<\/code> service has a task (container) running on both of our swarm nodes.<\/p>\nConnecting to the Redis service<\/h2>\n
redis-cli<\/code> client.<\/p>\nvagrant@vagrant:~$ redis-cli -h swarm-01.example.com -p 6379\r\nswarm-01.example.com:6379><\/pre>\n
redis<\/code> service. This means our service is up and available.<\/p>\nHow Docker Swarm publishes services<\/h3>\n
redis<\/code> service, we used the --publish<\/code> flag with the docker service create<\/code> command. This flag was used to tell Docker to publish port 6379<\/code> as an available port for the redis<\/code> service.<\/p>\nAdding a third node worker into the mix<\/h2>\n
docker<\/code> command.<\/p>\nroot@swarm-01:~# docker node ls\r\nID HOSTNAME STATUS AVAILABILITY MANAGER STATUS\r\n13evr7hmiujjanbnu3n92dphk swarm-02.example.com Ready Active \r\nawwiap1z5vtxponawdqndl0e7 * swarm-01.example.com Ready Active Leader\r\ne4ymm89082ooms0gs3iyn8vtl swarm-03.example.com Ready Active<\/pre>\n
\n
swarm-01<\/code><\/li>\nswarm-02<\/code><\/li>\nswarm-03<\/code><\/li>\n<\/ul>\nswarm-01<\/code> and swarm-02<\/code>. Let\u2019s see if this is still the case even though we added another node worker.<\/p>\nroot@swarm-01:~# docker service ps redis\r\nID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR\r\n5lr10nbpy91csmc91cew5cul1 redis.1 redis swarm-02.example.com Running Running 55 minutes ago \r\n1t77jsgo1qajxxdekbenl4pgk redis.2 redis swarm-01.example.com Running Running 55 minutes ago<\/pre>\n
redis<\/code> service, we specified that there should be 2<\/code> replicas. This means that even though we have a third node, Docker has no reason to start a new task on that node.<\/p>\n2<\/code> of the 3<\/code> Swarm nodes. In a non-Swarm world, that would mean the redis<\/code> service would be unavailable when connecting to our third Swarm node. With Swarm Mode however, that is not the case.<\/p>\nConnecting to a service on a non-task-running worker<\/h2>\n
swarm-03<\/code> over the redis<\/code> published port.<\/p>\nvagrant@vagrant:~$ redis-cli -h swarm-03.example.com -p 6379\r\nswarm-03.example.com:6379><\/pre>\n
swarm-03<\/code> is not running any redis<\/code> containers. This works because internally Docker is rerouting our redis<\/code> service traffic to a node worker running a redis<\/code> container.<\/p>\nredis<\/code> service can simply connect to any node worker. They will then be redirected to one of the two Docker hosts running the service tasks (containers).<\/p>\nMaking our service global<\/h3>\n
redis<\/code> service setup to run with 2<\/code> replicas, meaning it\u2019s running containers on 2<\/code> of the 3<\/code> nodes.<\/p>\nredis<\/code> service to consist of an instance on every node worker, we could do that easily by modifying the service\u2019s number of desired replicas from 2<\/code> to 3<\/code>. This would mean however that with every node worker we add or subtract, we will need to adjust the number of replicas.<\/p>\nredis<\/code> service as a Global Service.<\/p>\nroot@swarm-01:~# docker service create --name redis --mode global --publish 6379:6379 redis\r\n5o8m338zmsped0cmqe0guh2to<\/pre>\n
docker service create<\/code> command we used to create a replicated service. The only difference is the --mode<\/code> flag along with the value of global<\/code>.<\/p>\ndocker<\/code> command with the service ps<\/code> options.<\/p>\nroot@swarm-01:~# docker service ps redis\r\nID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR\r\n27s6q5yvmyjvty8jvp5k067ul redis redis swarm-03.example.com Running Running 26 seconds ago \r\n2xohhkqvlw7969qj6j0ca70xx \\_ redis redis swarm-02.example.com Running Running 38 seconds ago \r\n22wrdkun5f5t9lku6sbprqi1k \\_ redis redis swarm-01.example.com Running Running 38 seconds ago<\/pre>\n
Summary<\/h2>\n