DEV Community: Mohamed El Eraky

Docker Swarm Series: #8th Publishing Modes

Mohamed El Eraky — Tue, 25 Jul 2023 20:12:13 +0000

Inception

Hello everyone, This article is part of The Swarm series, The knowledge in this series is built in sequence, Check out The Swarm series section below.

In the last article, we covered Config and Secret advanced stuff, discussed how to use and manage config objects, and how to store secrets securely and use them in your deployment. However in an advanced and efficient way, using Docker-compose YAML file, Docker CLI, And Play-with-docker lab, we going to discuss more advanced topics today.

Overview

In This article, Will try to cover an interesting topic, which is docker publishing modes, Explain publishing modes, View the differences between ingress and host modes, how to use service end_point (VIP, DNSRR), and discover what is a global and replicas mode in deployment, Placement constraint. in this lab Also will use the Play-with-docker lab.

Publishing modes Overview

Simply, In Docker Swarm publishing a service means making it accessible from outside the swarm cluster. In native docker we used the --publish or -p option when creating a container. it's almost the same concept when comes to Swarm, however with more options to match what exactly you want.

Differences of publishing modes ingress vs host

First of all, Kindly build up the environment as mentioned in Docker Swarm Series: #3rd Deploy a highly available Container article.

Ingress

Docker's Ingress network is a built-in overlay network -docker networks- that enables external access to services running in a Docker Swarm cluster. It will accept connections for published ports from every node in the Swarm Cluster, and the Ingress routing mesh takes care of forwarding the traffic to a service task, regardless of which node it is running.

Hint: The service itself gets published as a DNS entry in docker's build in DNS-server

Create a service and publish a port via ingress:

docker service create --detach=true --name myservice --publish 8080:80 --replicas 3 --mount source=/etc/hostname,target=/usr/share/nginx/html/index.html,type=bind,ro nginx

This command publishes port 8080 on the swarm node to port 80 on the myservice service. This allows external access to the service through port 8080, The --mount flag is useful to print out the hostname of the node That host the service.

list services:
```
docker service ls
```

3. Optional: publish additional ports for an existing service

docker service update --publish-add 8080:80 myservice

Note: If you publish additional ports for an existing service will start updating the service one by one to avoid service down, and after updating will make some checks to ensure the update works fine.

Once you have completed these steps, the myservice service will be accessible from outside the swarm through the Ingress network. You can scale the service up or down as needed, and Docker will automatically handle load balancing and service discovery.

To test out the previous steps Follow the instructions below:

Here we have 3 services distributed on 3 nodes:
```
docker ps service myservice
```
As mentioned above the Ingress routing mesh takes care of forwarding the traffic to a service task, regardless of which node it is running on. therefore to test the load balancing run the following command on any node, even if it does not host the service.

curl http://localhost:8080

Notice that the output of the curl command prints out the node name that hosts the service. Rerun again a bunch of times on notice that the ingress routing mesh is load balance on the services.

Host

The host configures the service to bind directly to a specific port on the host, without using the ingress routing mesh. This can be useful when you want to run your own load balancer (e.g. Traefik, nginx), or need the source IP of the communication to be retained. The published host port will only be bound on nodes where at least one service task of the service is running.

Follow the below steps to publish a port in host mode:

to create a service with tasks that listens on port 8080 of the Docker host's network interface, you can use the following command:
```
docker service create --name myservice --publish published=8080,target=80,mode=host nginx
```
This command creates a service called myservice based on the nginx image, and binds the host port 8080 to the container port 80. Instead of using the host namespace, only a single port is forwarded to the container port.

Host namespaces isolate containers from each other and from the host system by providing each container with its own namespace for system resources such as processes, network interfaces, and file systems. This allows containers to have a high level of isolation and control over their resources.

On the other hand, host networking allows containers to use the host system's network stack directly, without being isolated from it. This means that containers using host networking are effectively treated as if they were running directly on the host system.

Service EndPoint Modes

EndPoint modes determine how the service is exposed to the client, there're two EndPoint modes VIP (Virtual IP) and DNSRR (DNS round-robin)

VIP endpoint mode is the default mode, and it assigns a single virtual IP to the service. The service name will be registered in the network DNS-based Service Discovery pointing to the virtual IP. The VIP provides a built-in load balancer, which distributes the connections in a round-robin manner to the tasks running the service.

DNSRR endpoint mode registers the service name as a multi-value DNS-record in the network DNS-based Service Discovery pointing to the IP's of all tasks running the service.

Typically (DNS) clients cache DNS results until the TTL expires, so that load will not be distributed among the tasks, but rather will be directed to the same task. Some clients even cache the DNS result indefinitely (like nginx does)

To set the endpoint mode for a service in a Docker Swarm stack file (in YAML format), you can use theendpoint_mode parameter under the deploy section of the service definition.

version: '3.9'

services:
  web:
    image: nginx
    deploy:
      endpoint_mode: dnsrr
      #endpoint_mode: vip

This is the same in the CLI syntax

docker service create --name web --endpoint-mode dnsrr nginx

Deploy modes

deploy: 
  mode: global

There are two deployment modes replicas **and **global, these modes define how the service will deploy on the nodes, with replicated you define how many service instances you want to deploy, on the other hand with global you configure the service instances to run on each node, the number of instances will equal the number of nodes, even if there is a new node joined the cluster will deploy an instance from the service on it.

Placement Constraints

Placement constraints are rules that specify which nodes are eligible for running a particular service or task. Constraints can be based on node labels, you can use this approach when you want to run a particular service on particular nodes. Assign your label to the node.
The placement constraints work either with replicas or global modes.

# the lable called db
docker node update --label-add db=true node-1

Update the YAML file

    deploy:
      replicas: 2 # <-- Set number of replicas
      placement:
        constraints:
          - node.labels.db == "true"  # deploy only on nodes that have this lable

Resources

That's it, Very straightforward, very fast🚀. Hope this article inspired you and will appreciate your feedback. Thank you.

Docker Swarm Series: #7th Advanced Managing config and secret objects

Mohamed El Eraky — Sat, 22 Jul 2023 05:05:58 +0000

Inception

Hello everyone, This article is part of The Swarm series, The knowledge in this series is built in sequence, Check out The Swarm series section above.

In the last article, we covered how to use and manage config objects and how to store secrets securely, using Docker-compose YAML file, Docker CLI, And Play-with-docker lab, And we going to discuss more advanced topics today.

Overview

In This article, We will complete The Swarm tutorials by explaining Config and Secret advanced stuff, will discuss how to use and manage config objects and how to store secrets securely and use them in your deployment. However in an advanced and efficient way. in this lab Also will use the Play-with-docker lab.

Advanced Managing config objects

In The Last Deployment, we created a config file that contains The MongoDB username and refer to The Mongo password file. That is actually a Nice way to manage config and store secrets without defining them as clear text in your docker-compose YAML file. However what if we want to update our config file with new content?

In Fact, Swarm doesn't have a way to manage config versioning. you should do it on your own, That means You can't update the same config file with new content, and then the service will update the config automatically.

However, you can create another config file and update the service by defining the new config file. Therefore you will Manage the config file object versioning.

Update The Config object example

This example will Continue from the last article's stand-up point, Kindly submit the example there and come back here to figure out how to update and version the config object file.

Now we have our environment ready, And we have a service running using config and secret stored in Swarm Database. Let's update the config and secret as below steps:

The config object file cannot be deleted while the service is using it. you should create another config and update the service to use the new config object, Then you can delete it. However prefer to not delete any, instead you should version your object files So you have your config files versioned so you can roll back to the old one, and then update the service YAML file to use the new version of the object file. and this is exactly what we going to do below steps:
- Create a new config file called mongo_config-v2.txt with the updated content below:

MONGO_INITDB_ROOT_USERNAME=root
MONGO_INITDB_ROOT_PASSWORD_FILE=/run/secrets/mongo_password.v2

Create the new config by running the following:

docker config create mongo_config.v2 mongo_config-v2.txt

now you should have two config objects

docker config ls

Update The Secret object example

The secret is almost pretty much the same as the config, you cannot recreate it with the same name, And cannot be deleted while the service is using it.

Instead, Also you would need to create another secret with the new content and version and update the service to use the new secret created. let's do this:

Create a new secret file object called mongo_password-v2.txt have the content below

supersecretp@$$w0rd

Create the secret by the following:

docker secret create mongo_password.v2 mongo_password-v2.txt

now you should have two Secret objects

docker secret ls

Some of The listed secrets are created by long-syntax and others by short-syntax ways, Will figure out that in a second.

Update The Service

Now let's update the service YAML file to use the new config and secret have just created, will not delete or update anything in the same file instead will copy the YAML file with a new name docker-compose-v2.yml so after a bunch of updates, we will have the YAML files listed and versioned. This a good way for rolling back, history, and tracking updates.

Copy the YAML file with the new name docker-compose-v2.yml

cp docker-compose.yml docker-compose-v2.yml

Open the version two compose file using vim and submit the updates as the following:

Mongo service Config

configs:
  - source: mongo_config.v2
    target: /docker-entrypoint-initdb.d/mongo_config-v2.txt

Mongo service Secrets

secrets:
  - mongo_password.v2

Mongo-Express service Admin password environment variable

ME_CONFIG_MONGODB_ADMINPASSWORD_FILE: /run/secrets/mongo_password.v2

Mongo-Express service Secrets

secrets:
  - mongo_password.v2
  - mongo_admin_username
  - me_username
  - me_password

Main Secrets and Config definition

secrets:
  mongo_password.v2:
    external: true
mongo_admin_username:
  external: true
me_username:
  external: true
me_password:
  external: true

configs:
  mongo_config.v2:
    external: true

Update the service by the following:

docker stack deploy -c docker-compose-v2.yml myapp

ensure the service running as expected by running the following

docker stack services myapp
docker stack ps myapp

Yeah, The service's desired state are matched the actual state, Also notice here the swarm has shut down the old services and created new services with our updates.

You can delete the config by running the following, Consider that you cannot delete the config and secret while the service is using it, will delete the config object meanwhile And will let the config object files itself for versioning list reasons.

docker config rm mongo_config
"""
notice that you still have the config file after deleted
the config object from swarm storage.
"""

Also, you can do the same with secrets.

Swarm secret long and short syntax

"The main difference between the long and short syntax for creating Swarm secrets is the way in which the secret's value is specified." -POE-

With the long syntax, The secret value is stored in a file and you run docker secret create with mentioning the file path.

This approach can be useful when creating secrets that have Certificate values, or any complex values.

"The long syntax allows mounting a secret in any path and even set the access permissions." -Metin-

On the other hand, the short syntax provides a more convenient way for defining the secrets by simply passing the secret value with a docker secret create command with the - option at the end, like the one below:

echo "mongo_pass" | docker secret create me_password -

The short syntax doesn't require to have a secret file

How the Cluster manages stacks

A stack is just a group of resources that the cluster orchestration tool manages them. at the moment you have an idea of how to build and manage your stack. However, Elton Stoneman the author of Learn Docker in a Month of Lunches has sort-down some points that I think it'll make it more clear, Let me summarize these points:

Volumes can be created and removed by the Swarm. Stacks will create a default volume if the service image specifies one, and that volume will be removed when the stack is removed. If you specify a named volume for the stack, it will be created when you deploy, but it won’t be removed when you delete the stack.
Secrets and configs are created when an external file gets uploaded to the cluster. They’re stored in the cluster database and delivered to containers where the service definition requires them. They are effectively write-once read-many objects and can’t be updated.
Networks can be managed independently of applications, with admins explicitly creating networks for applications to use, or they can be managed by the Swarm, which will create and remove them when necessary. Every stack will be deployed with a network to attach services to, even if one is not specified in the Compose file.
Services are created or removed when stacks are deployed, and while they’re running, the Swarm monitors them constantly to ensure the desired service level is being met. Replicas that fail health checks get replaced, as do replicas that get lost when nodes go offline.

References

That's it, Very straightforward, very fast 🚀. Hope this article inspired you and will appreciate your feedback. Thank you.

Docker Swarm Series: #6th Managing config and secret objects

Mohamed El Eraky — Tue, 18 Jul 2023 06:27:32 +0000

Inception

Hello everyone, This article is part of The Swarm series, The knowledge in this series is built in sequence, Check out The Swarm series.

In the last article, we covered the way of troubleshooting and find out how to find the exact issue and fix it, using Docker CLI, And Play-with-docker lab.

Overview

In This article, We will complete The Swarm tutorials by explaining how to use and manage config objects and how to store secrets securely and use them in your deployment. in this lab Also will use the Play-with-docker lab.

Docker Config Overview

In Fact, The Config object is a file that stores some configs that you want to share among multiple container services, This config file can store any type of data (e.g. JSON, Key value, XML)

The value behind the usage of the config file is to ensure consistency across all the services and containers that use the same configuration data. This helps to avoid configuration errors and reduces the risk of downtime, Surface the docker config Docs.

Docker Secret Overview

Secrets are almost exactly like config, "Secrets are encrypted throughout their lifetime in the cluster. The data is stored encrypted in the database shared by the managers, and secrets are only delivered to nodes that are scheduled to run replicas that need the secret. Secrets are encrypted in transit from the manager node to the worker, and they are only unencrypted inside the container, where they appear with the original file contents."

"The key difference with secrets is that you can only read them in plain text at one point in the workflow: inside the container when they are loaded from the Swarm."

-Docker in a month of lunches-

Deployment Example

In This example will deploy MongoDB and Mongo_Express container services and store the configs and secrets in external files and load them to the swarm database to ensure that the secret is secure and not appears in clear text, And will be using Play-with-Docker labs, Docker Swarm mode, Docker-compose file, config & secret files, and Docker CLI.

open Play-with-Docker labs, and create the below environment:
Create a config file object called mongo_config.txt that have the common configs including the username and the path to the password file.
```
MONGO_INITDB_ROOT_USERNAME=admin
MONGO_INITDB_ROOT_PASSWORD_FILE=/run/secrets/mongo_password
```

Create a secret object file with the MongoDB password called mongo_password.txt with the following content

supersecretpassword

Create a secret object from the secret file created:

$ docker secret create mongo_password mongo_password.txt

Create a config object from the config file created:

docker config create mongo_config mongo_config.txt

Check the Secrets in the cluster
```
docker secret ls
```
Check the config in the cluster
```
docker config ls
```
inspect the secret with a pretty flag using the following:
```
docker secret inspect --pretty mongo_password
```

note that the inspection doesn't print out the secret file content

inspect the config with a pretty flag using the following:
```
docker config inspect --pretty mongo_config
```

note that the inspection print out the content of the config file due to the config file isn't secured as secrets.

Create a Docker Compose file called docker-compose.yml with the MongoDB and Mongo_Express services, and reference the config and secret objects.

version: "3.7"
services:
  mongo:
    image: mongo:4.4
    configs:
      - source: mongo_config
        target: /docker-entrypoint-initdb.d/mongo_config.txt
    environment:
      MONGO_INITDB_DATABASE: test
    secrets:
      - mongo_password
    deploy:
      replicas: 1
      placement:
        constraints:
          - node.role == manager

  mongo-express:
    image: mongo-express:0.54
    ports:
      - "8081:8081"
    environment:
      ME_CONFIG_MONGODB_ADMINUSERNAME_FILE: /run/secrets/mongo_admin_username
      ME_CONFIG_MONGODB_ADMINPASSWORD_FILE: /run/secrets/mongo_password
      ME_CONFIG_MONGODB_SERVER: mongo
      ME_CONFIG_BASICAUTH_USERNAME_FILE: /run/secrets/me_username
      ME_CONFIG_BASICAUTH_PASSWORD_FILE: /run/secrets/me_password
    secrets:
      - mongo_password
      - mongo_admin_username
      - me_username
      - me_password
    deploy:
      replicas: 1
      placement:
        constraints:
          - node.role == manager

secrets:
  mongo_password:
    external: true
  mongo_admin_username:
    external: true
  me_username:
    external: true
  me_password:
    external: true

configs:
  mongo_config:
    external: true

Just an important hint, once you create the secret you cannot update it, So will deploy the other secrets that are mentioned in the YAML file as below:

echo "mongo_pass" | docker secret create me_password -
echo "mongo_user" | docker secret create me_username -
echo "admin" | docker secret create mongo_admin_username -

Deploy the stack to the Swarm cluster using the following

$ docker stack deploy -c docker-compose.yml myapp

Get Stack services
```
docker stack ls
```
Get Stack services
```
docker stack services myapp
```
More info about services
```
docker stack ps myapp
```

As Cleared the container services up and running.

Steps summarization

Create a config object file.
Create a secret object file.
Create a secret object from the file content.
Create a config object from the file content.
list and inspect our config and secret and ensure that the secret is secured and does not appear as clear text.
Create a Docker-compose YAML file for the stack deployment.
Manually create the missing secrets due to once you create the secret you cannot update it.
Deploy the stack using the docker-compose YAML file and Docker CLI.
print out the deployed services and ensure the services are up and running.

References

Learn Docker in a Month of Lunches

That's it, Very straightforward, very fast🚀. Hope this article inspired you and will appreciate your feedback. Thank you.

Docker Swarm Series: #5th Troubleshooting

Mohamed El Eraky — Wed, 12 Jul 2023 20:09:36 +0000

Inception

Hello everyone, This article is part of The Swarm series, The knowledge in this series is built in sequence, Check-out The Swarm series section above.

At the last article we covered How to Deploy a Stack to a swarm cluster and the value behind The Stack, And deployed a simple Nignx web-app, and mysql data-base using Docker compose YAML file, Stack deploy command, And Play-with-docker lab.

Overview

In This article We will complete The Swarm tutorials from the stand-up point Which is the containers stack went through errors and cannot be start, So in this article will go through the way of troubleshooting step-by-step, and find-out how to find the exact issue. in this lab Also will use Play-with-docker lab.

Setup the environment

To start troubleshooting first we need to redeploy the last Stack, Or simply deploy the YAML file below on play-with-docker lab:

version: '3'

services:  # services list
  nginx:  # service name
    image: nginx:latest  # specify an image with it's tag
    ports:  # defining ports
      - "8080:80"
    volumes:  # mount volume disk | mount nginx.conf stored on local device to nginx container
      - ./nginx.conf:/etc/nginx/nginx.conf

    # establish connection to mysql container by mention the defined variables at mysql environment below
    environment:
      MYSQL_HOST: mysql
      MYSQL_PORT: 3306
      MYSQL_DATABASE: myapp
      MYSQL_USER: root
      MYSQL_PASSWORD: password

    # The build of this container in depends on mysql
    depends_on:
      - mysql

  mysql:
    image: mysql:latest
    volumes:
      - ./data:/var/lib/mysql

   # Define mysql variables
    environment:
      MYSQL_DATABASE: myapp
      MYSQL_USER: root
      MYSQL_PASSWORD: password
      MYSQL_ROOT_PASSWORD: password

Deploy

docker stack deploy -c docker-stack-file.yaml myapp

Print-out the deploy service status

docker stack services myapp

Troubleshooting

When print-out the services of myapp stack you will find out that the replica table is 0/1 which means that the desired state of replica for this container service is set to 1 however the actual state is 0, That means the container service isn't deployed yet.

Docker stack will try to deploy these services all the time, however it's the same result, let's figure-out where is the issue.

Down we go

Run the following To get the deployed stacks

docker stack ls

we have one stack called myapp with two services.

Run the following to print-out the services of that stack

docker stack services myapp

As mentioned above, the actual state is 0, let's find out why....

Run the following to print-out the services with more info

docker stack ps myapp

Ok..Okay, Now let's explain what we're seeing here.

Let's focus on the highlighted in yellow at red square area, At the first column is for container service ID, the second for the container service name, the fourth is for Node name that host this service, Next to it is Desired state column with Ready status that means the Swarm was trying to deploy on this host while rejected at the next column which is Current state, why is that happened let's view the last column Error.

However the error column isn't wide enough let's expand it:

docker stack ps --no-trunc myapp

Yes, But There are too many services, let's focus on Nginx service by running the following:

docker service ps --no-trunc myapp_nginx

Yeah, Now the error is clear enough "bind source path does not exist: /root/nginx.conf"

Actually we didn't create an Nginx.conf file to mount it inside the container, Let's fix this out.

Create a very simple nginx.conf file at the same path of the YAML file:

vim nginx.conf

# past the below in it
worker_processes 1;

events {
  worker_connections 1024;
}

http {
  server {
    listen 80;
    server_name example.com;
    root /var/www/html;

    location / {
      try_files $uri $uri/ =404;
    }
  }
}

Update the stack by running the following:

docker stack deploy -c docker-stack.yaml myapp

Yeah, Now the container service is running on manager node 2:

Optional, ssh on manager 2 and run the following:

# ssh remote
ssh root@manager2

# print containers list
docker container ls

Let's make a simple somke-test by running curl:

curl localhost:8080

spotlight

Here we did troubleshooting on myapp_nginx service, if you do troubleshoot the myapp_mysql service will find-out it's the same issue. However it more complex and there's no time to discuses here.

The Issue that we faced here it was with failed to start-up the service, and we noticed that while print-out the service status using docker service ps --no-trunc myapp_nginx command, What if the container service start successfully however, the app that hosted inside the container service -Nginx webapp in our case- have an issue that obstacle its progress, here you should go to the next layer of troubleshooting which is the container service logs, fetch the service logs by running the following:

docker service logs <service-name>

# for a specific task
docker service logs <service-name> --task <task-id>

# for interactive session
docker service logs --follow --tail 100 <service-name>

# or land on the hosted node and run:
docker container logs <container-id>

Another way, You can land-on the hosted node and remote on the container using docker exec command and troubleshoot the logs.

That's it, Very straightforward, very fast🚀.
Hope this article inspired you and will appreciate your feedback. Thank you.

Docker Swarm Series: #4th Deploy a Stack to a swarm Cluster

Mohamed El Eraky — Mon, 03 Jul 2023 05:44:48 +0000

Inception

Hello everyone, This article is part of The Swarm series, The knowledge in this series is built in sequence, Check-out The Swarm series section above.

At the last article we covered How to Deploy a highly available Container, And deployed a simple Nignx web-app using DockerCLI and Play-with-docker lab.

Overview

In This article We will complete The Swarm tutorials, Will Deploy a Stack consists of Nginx and MySql containers, Also will explain the values behind the usage of stack for deployment, in this lab will use Play-with-docker lab, Docker Stack commands, and compose YAML file.

What is Stack

Docker Stack command is used for Managing Swarm stacks, The Stack use to run multi-container Docker applications. With Stack you use a YAML file to define your Containers configurations, Then you use a single command to start and run The Stack from this YAML file.

It's the same concept As the Docker-compose command with normal docker mode, However we're using Docker Stack command with Swarm mode.

The value behind the Stack:

Defining all stack containers and configuration at one YAML file -Docker-compose file- The value of using docker stack and compose is the same value of using blueprints. Blueprints -which is YAML file in our case- is very useful for history. Instead of Saving you commands of the running containers and it's configurations at some files out-there, You use all of stack containers and configuration at one file and simply publish it with one single command.
And when you want to update your stack configuration, instead of save the updated commands at The File and the hassle of remembering which one to use in future, Simply you update the Same YAML file and run with The stack command. So you have one single file consist of the updated configurations.

Example Docker Stack YAML file

Let's start out by creating our stack YAML file:

Start by Build the past Swarm environment Here with out deploy any applications.
On the manager node, Create a file called docker-stack.yaml by the command below:

vim docker-stack.yaml

Past the below content in the YAML file.

version: '3'

services:  # services list
  nginx:  # service name
    image: nginx:latest  # specify an image with it's tag
    ports:  # defining ports
      - "8080:80"
    volumes:  # mount volume disk | mount nginx.conf stored on local device to nginx container
      - ./nginx.conf:/etc/nginx/nginx.conf

    # establish connection to mysql container by mention the defined variables at mysql environment below
    environment:
      MYSQL_HOST: mysql
      MYSQL_PORT: 3306
      MYSQL_DATABASE: myapp
      MYSQL_USER: root
      MYSQL_PASSWORD: password

    # The build of this container in depends on mysql
    depends_on:
      - mysql

  mysql:
    image: mysql:latest
    volumes:
      - ./data:/var/lib/mysql

   # Define mysql variables
    environment:
      MYSQL_DATABASE: myapp
      MYSQL_USER: root
      MYSQL_PASSWORD: password
      MYSQL_ROOT_PASSWORD: password

Now you're ready to deploy your stack

Stack deploy

Run the following command to run myapp stack:

docker stack deploy -c docker-stack.yaml myapp

The result for this command will create a network for the stack, the nginx service and the mysql service.

list docker stack by the following:

docker stack ls

list Container Services by the following:

# stack services
docker stack services myapp

# all swarm services
docker service ls

Get more info with docker stack ps myapp

Stack Delete

Now let's delete our environment with single & simple command:

delete by the following:

docker stack rm myapp

At the end Note that the deployment went through Error, And the container cannot start; And Will discover how to troubleshoot in the next article....

That's it, Very straightforward, very fast🚀.
Hope this article inspired you and will appreciate your feedback. Thank you.

References

Docker Swarm Series: #3rd Deploy a highly available Container

Mohamed El Eraky — Tue, 27 Jun 2023 18:12:37 +0000

Inception

Hello everyone, This article is part of The Swarm series, The knowledge in this series is built in sequence, Check it out at my profile.

At the last article we covered How to create a highly available environment, And deployed a simple Nignx web-app using DockerCLI on Play-with-docker lab.

In This article We will complete from the stand-up point, Will scaling up our Container, Update the Container and roll-back again, Also will submit some production scenarios for deep understanding how Swarm deal with, in this lab will use Play-with-docker lab and DockerCLI commands.

Lab Overview

After finalize Creation of The Infrastructure and collect the required info, Today's Article will focus on The Container application section, How to scale-up and scale-down, cover the limits of routing mesh -Load balancer of swarm-, Rolling-Update and Rolling-back, After all will test the high availability of our environment by removing node from our cluster that host the Container and view how Swarm will handle this.

Build the infrastructure

At the last article we went through the hardest way of creating up our environment, However it's the appropriate way to build up your environment at any platform (i.e. On-prem, Cloud, any where), Today's will go through the easiest way to build up our environment on Play-with-docker platform.

Open up Play-with-docker platform.
Press on the template button as below:

Let's specify the template that similar to what we used at the past articles.

This will build the environment as below:

Build the Past Container

At the last article we built a Service that have an Nginx container by running the following command on any one of the manager nodes:

docker service create --detach=true --name nginx1 --publish 80:80  --mount source=/etc/hostname,target=/usr/share/nginx/html/index.html,type=bind,ro nginx:1.12

And you can print out the Running services by running the following:

docker service ls

Scale-up and Down

Till Now we didn't deploy a highly available container, Let's try out to scale our container with extra 6 replicas by running the following:

docker service update --replicas 6 --detach=true nginx1

When this command is run the following events occur:

The service state is update with 6 replicas, Which in stored in Swarm internal storage.
Swarm recognize that the number of replicas that is scheduled now Does not equal The Actual state.
Swarm Schedule a new task with 6 replicas to match the desired state.

Use the following commands to discover the deployed service:

docker service ls

docker service ps nginx1

Use the update command to Scale-Down as well, By running the following Will Scale-Down the replicas to be 5 instead of 6:

docker service update --replicas 5 --detach=true nginx1

Routing mesh limits

Now on our scenario, When you send a request on port 80, The Routing mesh has multiple containers -working on this port- in which to route requests to, Routing mesh act as a load balancer for these containers, Therefor the Routing mesh will send the coming requests randomly to these containers.

let's test this out by running the following multiple times on any Node:

curl localhost:80

You should see which node is serving each request because of the useful --mount command you used earlier.

Another easy way to check which node is serving the requests is to checking the aggregated logs by using the docker service logs [service-name] command. This aggregates the output from every running container and get the output from docker container logs [container-name] command.

Limits of the routing mesh: The routing mesh can publish only one service on port 80. If you want multiple services exposed on port 80, you can use an external application load balancer outside of the swarm to accomplish this.

Rolling update and Rolling back

Now you have your service deployed and running successfully, and you're going to update the version of Nginx container. You want to update the pulled image and the deployed container that use this image version, with Docker service update command you can update the pulled image and the service as well.

Let's update our Nginx service to version 1.13 by using the following:

docker service update --image nginx:1.13 --detach=true nginx1

This triggers a rolling update of the swarm, Run the following command to view the updates in real time:

# using watch command
watch -n 1 docker service ps nginx1

# Or you can run this command over and over again
docker service ps nginx1

You can fine-tune the rolling update by using these options:

--update-parallelism: specifies the number of containers to update immediately (defaults to 1).
--update-delay: specifies the delay between finishing updating a set of containers before moving on to the next set.

After a few seconds you figure out that your Nginx application has update successfully and the old version has shunted-down.

roll-back

What if find out that the latest update have an issue and your application didn't work as expected and you want to roll-back you can achieve that by running the following:

# roll back
docker service rollback nginx1

# remove the in useful services
docker service rm

Test the Swarm environment high available functionality

Now we have our services running on the distrusted nodes, What if a node with it's containers hosted goes down, In this section will test the Swarm high availability Function by make the node 4 leaving the Swarm cluster.

Go to node 1 for example and run the following command to watch the cluster change in real time:

watch -n 1 docker service ps nginx2

Now, land on node 4 and run the following to leave the cluster:

docker swarm leave

Get back to node 1 and Note that the Swarm will rebuild the containers in another node to match the desired state.

That's it, Very straightforward, very fast🚀. Hope this article inspired you and will appreciate your feedback. Thank you.

Docker Swarm Series: #2nd Create a highly available environment

Mohamed El Eraky — Sat, 24 Jun 2023 13:42:31 +0000

Inception

Hello everyone, This article is part of The Swarm series, The knowledge in this series is built in sequence, Check out my profile.

In the last article we covered a high overview about Orchestration tools and Swarm, what ports should to be opened between nodes, And setup the environment using Play-with-docker labs.

In This article We will complete from the stand-up point, Will create a highly available Swarm environment using Play-with-docker labs, and deploy a simple webapp application using DockerCLI commands.

Lab Overview

The MAIN point of having an Orchestration tool is to have a highly available environment and highly available applications, besides the other features that provide (e.g. load balancer, monitoring, etc,,) Because of that Today's article will focus on how to create a high available environment and deploy a simple webapp using DockerCLI.

enough talking and let's get started

Highly available environment overview

As we need our application to be highly available to avoid single point of failure if the application goes down. it's the same idea on the environment level, if we created a high available application and load balance the traffic between them but the application lives on the same node server. here we have a high available application (from the traffic aspect) however we don't on environment level, if the node server goes down the application will goes down too. To avoid this we should have a highly available environment and the application lives on more than one node, And this is the idea behind the Orchestration tools to deliver the simplicity to achieve this.
To create a highly available environment on Swarm we should have at least three manager node but typically no more than seven, manager nodes container the necessary information to manage the cluster, if the manager node goes down this will cause cluster failed function, How to determine the number of manager nodes:
- Three manager nodes tolerate one node failure.
- Five manager nodes tolerate two node failures.
- Sever manager nodes tolerate three node failures.

Regarding worker nodes, at least two worker nodes for redundancy and fault tolerance, but you can add more nodes as needed to handle the workload.

Actually, The Swarm Manager node will host the applications like worker node as well.

Therefor, In this lab will create Three manager nodes with two worker nodes.

Create a highly available environment

Open Play-with-docker labs.
Press ADD NEW INSTANCE, and initiate Docker swarm mode using:

docker swarm init --advertise-addr eth0

# to get the interface name use
ip a s

copy and past -ctrl+shift+v- the highlighted command at the screenshot to generate a token -at the same node- that will use to join the other managers to the cluster.

Press ADD NEW INSTANCE to create, And join another Manager node to the the cluster.
copy and past the highlighted command at the last screenshot to join the cluster as a manager node.

Repeat the last step to join another manager node at the same cluster.

let's create the Worker nodes, Go back to the 1st manager node created and copy the command that join the worker nodes to the swarm cluster.
Press ADD NEW INSTANCE, past the command to join the cluster as worker node:

Repeat the last step to join another worker node to the cluster.
Let's check out our environment, Go to the any one of the manager nodes, and type the below command:

docker node ls

As listed there are three manager nodes Besides two worker nodes, The asterisk means the node number two that handle the command you've written

docker node ls

Also at the manager status column, There is a leader and the reachable, The leader is the manager node leader initiator and the reachable means that the node is currently available and can communicate with the other nodes in the Swarm cluster.

Deploy a webapp application overview

Now as we have our cluster running and ready to deploy containers, To deploy a container we need to create a service, the service is and abstraction that represent multiple container of the same image deployed across the cluster, you can assume the service is the same concept as POD in K8s.

run the service by using docker service command instead of using docker run or start in normal docker mode, try to differentiate between normal docker mode and docker swarm mode with these commands

Deploy a webapp application

copy and past the following command to run your first app:

docker service create --detach=true --name nginx1 --publish 80:80 --mount source=/etc/hostname,target=/usr/share/nginx/html/index.html,type=bind,ro nginx:1.12

This command statement is declarative, and Swarm will try to maintain the state declared, which means Swarm will compare the desired state of the application With the Actual state, However this is the first running of this application So the desired have been declared at the command however the actual Swarm will created for us.

The --mount flag is useful to have Nignx print out the hostname of the node its running on, will try this out at the next article.

After run the application list see its status by using:

docker service ls

To take deeper look at the running tasks use:

docker service ps nginx1

This will print out more info about this application including the node that host this app.

mention here that you can land on this node and simple run the normal node command: docker container ls

Let's Test the app service, go to another node -that not host the service- and run:

curl localhost:80

That's it, Hope this article inspired you and will appreciate your feedback. Thank you.

Docker Swarm Series: #1st Setup the Environment

Mohamed El Eraky — Wed, 21 Jun 2023 09:37:19 +0000

Introduction to Container Orchestration

Assuming that we have a containerized Python application and wanna to deploy on production. However to deploy on production we have some prerequisites to handle first:

service discovery, (i.e. connections between containers).
Auto Scaling.
High availability and fault tolerance.

With Traditional servers (i.e. virtual machines) All of these prerequisites was handled by bunch of tools (e.g. Vmware,) But how to achieve that while using containers!?

Here's the value behind The Container orchestration tools, Container orchestration is the process of managing and deploying containers, Orchestration helps to automate the deployment, scaling, and management of containerized applications.

Containers provide a lightweight and portable way to package and deploy applications, but managing them at scale can be challenging. Container orchestration tools help to simplify this process by providing a platform for deploying and managing containers across multiple hosts.

Orchestration tools typically provide the following features:

Service discovery: Containers need to communicate with each other, and orchestration tools provide a way to automatically discover other containers in the cluster.
Load balancing: Orchestration tools can automatically distribute incoming traffic across multiple containers, ensuring that the workload is evenly distributed.
Scaling: Orchestration tools can automatically scale the number of containers up or down based on the demand for the application.
Health monitoring: Orchestration tools can monitor the health of containers and automatically restart them if they fail.
Declare desired state: Orchestration tools will work to compare the desired state -that your provided- with the actual state -The real state of the running applications- and works to ensure that the actual state matches that desired state.

Some popular container orchestration tools include Docker Swarm, Kubernetes, Mesos. Each tool has its own strengths and weaknesses, and the choice of tool will depend on your specific requirements.

Container ecosystem layers:

The image provided by IBM docker essentials course

In this series will be using Docker swarm, Docker Swarm is a powerful and easy-to-use tool for managing containers at scale, and it has become a popular choice for organizations looking to deploy containerized applications in production environments.

Docker swarm Overview

Docker swarm is a container orchestration tool That allows you to Create, Deploy, Scale, and manage Cluster of Docker Hosts using declarative configuration file called Docker Compose or DockerCLI.

Docker swarm As Defined by Docker Docs "The cluster management and orchestration features **embedded in the Docker Engine* are built using swarmkit, Swarmkit is a separate project which implements Docker’s orchestration layer and is used directly within Docker."* Docker Swarm is the Docker-native container orchestration platform that uses SwarmKit as its core library, That means you don't need any extra installation.

Docker swarm is consists of two main components: Manager nodes, and worker Nodes, The Manager node server is responsible on managing the entire cluster and schedule the tasks, While The Worker node is the host that run the container; That means we must have couple of servers to initiate the Swarm cluster., And that is the idea to deliver high availability to your applications

Swarm provide very powerful features with self managed and easy to use, Press Feature highlights for more.

kindly consider to assign a static IP for Nodes, Also consider Open protocols and ports between the hosts

The following ports must be available. On some systems, these ports are open by default.

Port 2377 TCP for communication with and between manager nodes
Port 7946 TCP/UDP for overlay network node discovery
Port 4789 UDP (configurable) for overlay network traffic

Setup the environment

To initiate the Swarm Cluster we need couple of servers which is hard to achieve for learning purpose, In this lab will going to use Play with Docker, Play with docker is provided by Docker Inc to provide your the ability to initiate Nodes that have docker preinstalled and ready to use.

Enough talking, Down we go!!

Setup the Environment:

Press to open Play with docker
Sign-in with your docker account.
Press Start, to start creating your workspace.

This will open workspace like the below, Press Add new instance to initiate a server.

Initiate Swarm Mode:

# get the NIC name "network interface card"
# in our case its eth0
ip a s

# initiate docker swarm
$ docker swarm init --advertise-addr eth0

This will print out the below:

Swarm initialized: current node (yz3vrc2w1hwnrwkr5dfsctxkj) is now a manager.

To add a worker to this swarm, run the following command:

    docker swarm join --token SWMTKN-1-4xj2egkkxq8ofqkeg0s3zblrdpzcpqokgjyl5zpc1pja100641-3eqtbf6doialoa2spbr1o4dp0 192.168.0.28:2377

To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.

I think it's defined well

Now, Let's create Two instances and join them to our Swarm cluster.

Press Node2, Copy and past the command provided by Swarm initiation

docker swarm join --token SWMTKN-1-4xj2egkkxq8ofqkeg0s3zblrdpzcpqokgjyl5zpc1pja100641-3eqtbf6doialoa2spbr1o4dp0 192.168.0.28:2377

Do the same on Node3

Here we go, list worker nodes:
- Press node1 which is the manager node, and type the below.

 docker node ls

here we have three nodes with Ready status, Active availability, and one act as leader "Manager".
The asterisk means this node1 it's the node that handle this command

docker node ls

The Underline information

Container orchestration tools help to automate the deployment, scaling, high availability, and management of containerized applications.
Orchestration tools typically provide Service discovery, Load balancing, Scaling, Health monitoring, Declare desired state.
Docker Swarm is a powerful and easy-to-use tool for managing containers.
initiate Swarm mode Dose not need any extra installation.
Docker swarm is consists of two main components: Manager nodes, and worker Nodes, The Manager node server is responsible on managing the entire cluster and schedule the tasks, While The Worker node is the host that run the container.
use this command to initiate the swarm mode:

docker swarm init --advertise-addr eth0

use this command on the manager node to list the node:

docker node ls

That's it, Very straightforward, very fast🚀.
Hope this article inspired you and will appreciate your feedback. Thank you.

DEV Community: Mohamed El Eraky

Docker Swarm Series: #8th Publishing Modes

Inception

Overview

Publishing modes Overview

Differences of publishing modes ingress vs host

Ingress

Host

Service EndPoint Modes

Deploy modes

Placement Constraints

Resources

Metin guidance

Docker Swarm Series: #7th Advanced Managing config and secret objects

Inception

Overview

Advanced Managing config objects

Update The Config object example

Update The Secret object example

Update The Service

Swarm secret long and short syntax

How the Cluster manages stacks

References

Docker Swarm Series: #6th Managing config and secret objects

Inception

Overview

Docker Config Overview

Docker Secret Overview

Deployment Example

Steps summarization

Docker Swarm Series: #5th Troubleshooting

Inception

Overview

Setup the environment

Troubleshooting

Down we go

spotlight

Docker Swarm Series: #4th Deploy a Stack to a swarm Cluster

Inception

Overview

What is Stack

The value behind the Stack:

Example Docker Stack YAML file

Stack deploy

Stack Delete

References

Docker Swarm Series: #3rd Deploy a highly available Container

Inception

Lab Overview

Build the infrastructure

Build the Past Container

Scale-up and Down

Routing mesh limits

Rolling update and Rolling back

roll-back

Test the Swarm environment high available functionality

Docker Swarm Series: #2nd Create a highly available environment

Inception

Lab Overview

Highly available environment overview

Create a highly available environment

Deploy a webapp application overview

Deploy a webapp application

Docker Swarm Series: #1st Setup the Environment

Introduction to Container Orchestration

Orchestration tools typically provide the following features:

Container ecosystem layers:

Docker swarm Overview

Setup the environment

The Underline information