Millet Porridge

English version of https://corvo.myseu.cn

0%

Docker Series 11: docker swarm Mode

Posted on Edited on In Disqus:
This may be the last episode of the Docker series, mainly introducing swarm mode usage. I touch swarm mode rarely at work. For personal projects I deploy applications single-node via swarm; I'll briefly share using docker stack for deployment and upgrades after swarm initialization, and finally share swarm's limitations.

All content below targets personal projects; please don’t use it this way in work environments.

Why I Used swarm Mode

Enabling swarm is mainly for the following reasons:

  1. Starting projects with only docker run means that when updating a service, the service port closes and restarts — unless each version uses a separate port. If every version’s port differs, we’d also have to design an algorithm to maintain the available port list, and facing scaling needs, this algorithm becomes even more complex. swarm’s benefit is seamless migration during upgrades, greatly reducing deployment cost. Compared with docker run, it provides more comprehensive features.

  2. Using an orchestration system like Kubernetes can of course also achieve seamless upgrades, but for simple personal projects there’s no need for Kubernetes. swarm mode is small and already sufficient. Of course you can still choose minikube — I personally just chose swarm.

For concrete features see the official docs: Swarm mode overview

In a single-machine environment, after installing docker, docker swarm init enables it.

The docker-compose File

docker-compose official documentation

compose is a tool that can define and run multiple containers; the syntax is a yaml file:

1
2
3
4
5
6
version: '2.0'
services:
  redis:
    image: redis
volumes:
  logvolume01: {}

When writing this file I suggest paying attention to the version number. Also, don’t over-rely on black magic. Simple port mapping and file mounting are enough. For overly complex features, think ahead about whether they’re necessary.

Deploying Applications and CI with docker stack

Normally after writing the compose.yaml config file, I don’t start directly with docker-compose — I operate with docker stack deploy:

1
2
# specify the compose file to use and the stack name
docker stack deploy --compose-file <compose_file> <stack_name>

Continuous integration also becomes simplified thanks to docker stack. When deploying an application, I only need to replace the image version in the config file and re-deploy. Take this file as an example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
version: '3'

services:
  # this service has two containers: 1. the service container, serving externally
  app:
    ports:
      - "8081:8082"
    image: example:dev
    environment:
      type: "web"
    deploy:
      replicas: 3
      labels:
        com.docker.lb.hosts: example.ml
        com.docker.lb.ip_hash: 'true'
        com.docker.lb.port: 8081
    volumes:
      - ./static:/home/goyoubbs/static

  # 2. the cron container, executing the application's scheduled tasks
  cron:
    image: example:dev
    environment:
      type: "cron"
    volumes:
      - ./static:/home/goyoubbs/static

When writing CI/CD rules, all I consider is replacing the image position. Used in azure-pipeline, sed can replace the specific line — covering both development and deployment. Personally I find this approach quite practical and simple.

1
2
3
4
5
6
7
8
- script: |
    echo "$(System.DefaultWorkingDirectory)"
    cp /home/azure/example-config.yaml $(WORKDIR)/config/config.yaml
    docker build . -t 'example:v$(Build.BuildId)'
    sed -i 's/example:dev/example:v$(Build.BuildId)/' docker-compose.yaml
    sed -i 's@- ./static:/home/goyoubbs/static@- /home/collipa/goyoubbs/static:/home/goyoubbs/static@' docker-compose.yaml
  workingDirectory: '$(WORKDIR)'
  displayName: 'Build example image'

docker stack Limitations

If you read the compose file reference blog in detail, you’ll find some caveats: certain options are ignored when docker stack starts. For example: devices, links, restart, cap_add, … many config items are not supported. Personally I suggest thinking twice before using these unsupported options; simple web applications shouldn’t depend on such services.

Summary

This article briefly introduced using docker’s swarm mode in personal projects — a lightweight CI/CD means, with excellent compatibility with various pipeline syntaxes, fully capable of quick integration into existing projects. If you still have usage questions, discuss them in the comments.

Related Posts