Welcome to Part 2 of this series on Docker Swarm. If you have not read the previous article, please check out my profile to find it. In this article, we will discuss the remaining Docker Swarm commands.
docker service update
The docker service update
command is used to update a running service in a Docker swarm. It can be used to change the configuration of a service, such as the number of replicas, the image used, or the environment variables.
The basic syntax of the command is as follows:
docker service update [OPTIONS] SERVICE
Here are some common options that can be used with the docker service update
command:
-
-replicas
: Change the number of replicas for the service -
-image
: Update the image used for the service -
-env-add
and-env-rm
: Add or remove environment variables for the service -
-force
: Force an update of the service even if there are no changes
Here is an example of using the docker service update
command to update the number of replicas for a service:
docker service update --replicas 3 my-service
This will change the number of replicas for the my-service
service to 3.
Here is another example that updates the image used by a service:
docker service update --image my-image:latest my-service
This will update the image used by the my-service
service to my-image:latest
.
You can also use the --env-add
and --env-rm
options to add or remove environment variables for the service:
docker service update --env-add MY_VAR=my_value my-service
docker service update --env-rm MY_VAR my-service
The first command will add an environment variable MY_VAR
with the value my_value
to the my-service
service. The second command will remove the MY_VAR
environment variable from the service.
Finally, you can use the --force
option to force an update of the service even if there are no changes:
docker service update --force my-service
This will force an update of the my-service
service even if there are no changes.
💡 The --force
flag is used with the docker service update
command to force the immediate update of a service even if it results in service disruption. By default, Docker Swarm will try to update a service without disrupting it by gradually updating one replica at a time. However, in certain cases, it may be necessary to force an immediate update of all replicas to ensure that the changes are applied quickly. This can be useful in situations where the new changes are critical and need to be implemented as soon as possible, even if it causes temporary service disruption.
It is important to use the --force
flag with caution as it may cause service disruption and should be used only when necessary.
docker service scale
The docker service scale
command is used to scale the number of replicas of a service in a Docker swarm.
The syntax for the command is:
docker service scale <service_name>=<replica_count>
Here, <service_name>
is the name of the service to be scaled and <replica_count>
is the new number of replicas to be set.
For example, if we have a service named web
with 3 replicas and we want to scale it to 5 replicas, we can use the following command:
docker service scale web=5
This will update the service with the new replica count. Note that this command only works for replicated services and not for global services.
💡 Replicated services have a specific number of replicas defined, while global services run one replica on every node in the swarm. Replicated services are useful for running a fixed number of tasks, while global services are useful for tasks that need to run on every node in the swarm, such as logging or monitoring agents.
docker service rm
docker service rm
is a command used to remove one or more services from a Docker swarm. It stops and removes all tasks associated with the specified services. The command takes one or more service IDs or service names as arguments.
Here is an example of how to use it:
docker service rm my-service
This will remove the service named my-service
from the swarm.
docker stack deploy
The docker stack deploy
command is used to deploy a Docker Compose file to a Swarm cluster as a stack. A stack is a group of services that are deployed together as a single unit.
Here is an example command that deploys a stack:
docker stack deploy -c docker-compose.yml mystack
In this command, docker-compose.yml
is the name of the Docker Compose file, and mystack
is the name of the stack.
The options available with the docker stack deploy
command are:
-
c
,-compose-file
: Specifies the Docker Compose file to use. -
-prune
: Removes any services or containers that are not defined in the Compose file. -
-resolve-image
: Forces the cluster to resolve the image name to a specific digest, rather than using the default "latest" tag. -
-orchestrator
: Specifies the orchestrator to use, either "swarm" or "kubernetes".
Here is an example of deploying a stack with the --prune
option:
docker stack deploy --prune -c docker-compose.yml mystack
This command removes any services or containers that are not defined in the Compose file.
The --resolve-image
option for the docker stack deploy
command is used to resolve image digest and tag to the corresponding image ID before deploying a stack.
The possible values for --resolve-image
option are:
-
always
: This value tells Docker to always attempt to pull the image, even if a local copy exists. This can be useful if you want to make sure you're always using the latest version of an image. -
changed
: This value tells Docker to only pull the image if the image's tag has changed since the last time it was pulled. This can be useful if you want to minimize network traffic and avoid unnecessary pulls. -
never
: This value tells Docker to never attempt to pull the image, and to only use a local copy if it exists. This can be useful if you know that you won't need to update the image, or if you want to avoid network traffic altogether. However, be careful when using this option, as it can result in using an outdated image if a newer one is available.
Here is an example command using the --resolve-image
option with the always
value:
docker stack deploy --compose-file docker-compose.yml --resolve-image always myapp
docker stack ls
The docker stack ls
command is used to list all the stacks that are currently deployed on the swarm. It provides a quick summary of the deployed stack, including the name, the number of services in the stack, and the status of the stack.
Here's an example of how to use the command:
docker stack ls
This will output a table that lists all the deployed stacks, their number of services, and their status. Here's an example output:
NAME SERVICES STATUS
my_stack 3 * Running
The NAME
column shows the name of the stack. The SERVICES
column shows the number of services in the stack. The STATUS
column shows the current status of the stack. In this example, the stack named my_stack
has 3 services and is currently running.
This command is useful when you need to check the status of your deployed stacks and the number of services running in them.
docker stack ps
The docker stack ps
command is used to list the tasks or replicas of a given stack.
Here is the syntax of the command:
docker stack ps [OPTIONS] STACK_NAME
Where STACK_NAME
is the name of the stack.
Here are some options that can be used with the docker stack ps
command:
-
-filter
: It can be used to filter the tasks based on various parameters like desired state, node, etc. -
-no-trunc
: It is used to disable truncating the output of the command. -
-quiet
: It is used to display only the task IDs.
Here is an example command to list the tasks of a stack named my_stack
:
docker stack ps my_stack
The output of docker stack ps
command shows the running processes/replicas of the services in the specified stack along with their current status. It displays a table with the following columns:
-
ID
: The unique ID of the task. -
Name
: The name of the service the task belongs to. -
Image
: The Docker image used to create the task. -
Node
: The hostname of the node where the task is running. -
Desired State
: The desired state of the task (running or shutdown). -
Current State
: The current state of the task (running, completed, or shutdown). -
Error
: Any error message associated with the task, if applicable.
Here's an example output:
ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR
qn41eabryqw1 myapp_web.1 myapp:latest swarm-node-1 Running Running 2 minutes ago
fb48n1mzsqxd myapp_web.2 myapp:latest swarm-node-2 Running Running 2 minutes ago
iz4f7ifg5ue5 myapp_worker.1 myapp-worker:latest swarm-node-1 Running Running 2 minutes ago
7nzq44tigzrw myapp_db.1 postgres:10.1 swarm-node-2 Running Running 2 minutes ago
In this example, there are four tasks running for the my_stack
stack. Two replicas of the myapp_web
service are running on swarm-node-1
and swarm-node-2
, one replica of the myapp_worker
service is running on swarm-node-1
, and one replica of the myapp_db
service is running on swarm-node-2
.
docker stack rm
The docker stack rm
command is used to remove a Docker stack, which includes all the services and networks associated with that stack. Here is the syntax for the command:
docker stack rm [OPTIONS] STACK_NAME [STACK_NAMES...]
Where STACK_NAME
is the name of the stack to be removed.
For example, to remove a stack named my_stack
, the command would be:
docker stack rm my_stack
This command will remove all the services and networks associated with the my_stack
stack.
There are options available for the docker stack rm
command. Here are some commonly used options:
-
-force
: This option forces the removal of the stack even if it is currently running. -
-orchestrator
: This option specifies which orchestrator to use for the removal operation. By default, the command uses the swarm mode orchestrator. -
-volumes
: This option removes the volumes associated with the stack along with the stack itself.
Here's an example command that uses the --force
option to forcefully remove a stack:
docker stack rm --force myapp
Note that this command does not remove any volumes that were created by the services in the stack. However, you can use the --volumes
option to remove the volumes as well.
Here is an example command to remove a stack with associated volumes:
docker stack rm --volumes mystack
This will remove the mystack
stack along with its associated volumes. If you do not want to remove the volumes, simply omit the --volumes
option.
💡 Just remember that docker is not going to remove any volume except anonymous volumes without your confirmation due to data loss risk
docker stack services
The docker stack services
command is used to list the services that are running as part of a stack.
Here's the basic syntax:
docker stack services <stack_name>
This will display a table with the following columns:
- ID: The unique identifier of the service
- NAME: The name of the service
- MODE: Whether the service is running in
replicated
orglobal
mode - REPLICAS: The number of replicas of the service (only applicable for replicated services)
- IMAGE: The Docker image used by the service
Here's an example of how to use the command:
docker stack services myapp_stack
This will display a table of all the services running in the myapp_stack
stack.
ID NAME MODE REPLICAS IMAGE PORTS
8h1fc2y1ffaz myapp_stack_web replicated 3/3 myapp:latest *:80->80/tcp
e96fa5zjdt0a myapp_stack_redis replicated 1/1 redis:latest *:6379->6379/tcp
How to scale services in Docker Swarm stack?
To scale a service in a Docker stack, you can use the docker service scale
command followed by the name of the service and the desired number of replicas. For example, to scale a service named web
in a stack named my_stack
to 5 replicas, you can use the following command:
docker service scale my_stack_web=5
This will create or remove replicas as necessary to ensure that there are 5 replicas of the web
service running.
Docker swarn secret
Swarm Secrets is a feature in Docker Swarm that allows users to securely store and manage sensitive data, such as passwords, authentication tokens, and other confidential information. It follows a client-server architecture, where the Docker Swarm manager node acts as the server and the worker nodes as clients.
When a secret is created, it is encrypted and stored on the manager node. The encrypted secret is then replicated to all the worker nodes that are part of the Swarm. The workers have access to the secret only when the service that requires the secret is created or updated on the worker node.
Overall, Swarm Secrets provide a secure and convenient way to manage and distribute sensitive data in a Swarm environment.
How to use swarn secret ?
First, create a Swarm Secret using the docker secret create
command:
$ echo "mysecretpassword" | docker secret create db_password -
This command will create a Swarm Secret named db_password
with the value mysecretpassword
.
When you deploy the Node.js application to a Docker Swarm using the docker stack deploy
command, you can specify the Swarm Secret in the docker-compose.yml
file like this:
version: "3.7"
services:
app:
image: my-node-app
secrets:
- source: db_password
target: /run/secrets/db_password
mode: 0400
secrets:
db_password:
external: true
file: ./db_password.txt
In this example, the secrets
section is used to specify the db_password
Swarm Secret. The external: true
option tells Docker that this Secret already exists in the Swarm.
The secrets
section in the app
service specifies that the db_password
Secret should be mounted as a file at /run/secrets/db_password
inside the container. The mode: 0400
option sets the permissions of the file to read-only for the owner.
When you deploy the stack using the docker stack deploy
command, Docker Swarm will automatically create the necessary files and mount the Swarm Secret as a file in the container.
Here is an example of a Node.js application that uses the Swarm Secret db_password
:
const fs = require('fs');
const password = fs.readFileSync('/run/secrets/db_password', 'utf8');
console.log('Database password:', password);
In this example, the fs.readFileSync
method is used to read the db_password
Swarm Secret file. The file is mounted in the container at the path /run/secrets/db_password
.
💡 In the development env just mark theexternal
to false
inside your docker-compose.yml
file and put your database password inside the file db_password.txt
located in the folder of docker-compose.yml
file.
Top comments (0)