Vom Docker-Composer zu Docker Swarm: Configs

Sie haben eine Anwendung, die aus einer Reihe von Docker-Compose-Projekten besteht, und verwenden Docker-Compose zum Erstellen, Starten und Bereitstellen.

Nun möchten Sie einen Schritt weiter gehen und einige der Docker-Compose Projekte auf einen anderen Server verschieben. Die naheliegendste Möglichkeit, dies zu tun, ist Docker Swarm. Sie lernen ein paar weitere Docker -Befehle und schon sind Sie fertig. Ist es wirklich so einfach?

Spoiler-Alarm. Nein, es ist nicht einfach, wenn Sie Container haben, die Volumes verwenden, z.B. für Konfigurationsdaten, Hochleistungsdaten, persistente Daten. Viele Beispiele im Internet umgehen dieses Thema komplett oder erwähnen beiläufig die Verwendung von gemeinsam genutzten Speicherlösungen wie NFS (nicht verschlüsselt) oder GlusterFS, oder verwenden Speicherlösungen von Cloud-Anbietern. Alle diese Speicherlösungen haben die gleiche Eigenschaft: Sie sind netzwerkbasiert und im Vergleich zu nativen Speicherlösungen sehr langsam. Ja, Sie können schneller werden, aber Sie werden mehr bezahlen.

Bevor Sie Docker Swarm überhaupt in Erwägung ziehen, empfehle ich Ihnen, sich über dieses Thema zu informieren, um zu verstehen, ob Ihr Anwendungsfall für Docker Swarm geeignet ist. Zum Beispiel gibt es hier eine Diskussion zu diesem Thema, 'Data(base) persistence in docker swarm mode', siehe Links unten. Und von dieser Stackoverflow Antwort 'How does Docker Swarm implement volume sharing?', siehe Links unten:

Swarm Der Modus selbst macht nichts anderes mit Volumes, er führt jeden Volume-Mount-Befehl aus, den Sie auf dem Knoten angeben, auf dem der Container läuft. Wenn Ihr Volume-Mount lokal auf diesem Knoten ist, werden Ihre Daten lokal auf diesem Knoten gespeichert. Es gibt keine eingebaute Funktionalität, um Daten automatisch zwischen Knoten zu verschieben.

Das bedeutet, dass es möglich ist, eine Verzeichnisstruktur auf einem Arbeitsknoten vorzubereiten und sicherzustellen, dass Sie einen Container nur auf diesem Knoten ausführen, indem Sie die Parameter für die Bereitstellung verwenden. Optionen ...

In diesem Beitrag verwenden wir Docker Swarm Configs , um (statische) Konfigurationsdaten an Container auf Worker Nodes zu übergeben. Das ist ein bisschen ein Anti-Pattern, aber das Schöne daran ist, dass wir eine Speicheranforderung eliminieren.

Wie immer laufe ich auf Ubuntu 22.04. Im Moment verwende ich nicht Docker Desktop. Ich habe VirtualBox verwendet, um einen Ubuntu Server VM zu erstellen und diesen als Worker zu verwenden.

Docker Swarm verwaltet keine Volume-Daten!

Docker Swarm ist ein Service-Manager und Services sind Container (basierend auf images), keine Volume-Daten. Das bedeutet, dass Sie die Datenträgerdaten selbst verwalten müssen.

Nehmen wir als Beispiel einen DSN-Server-Container. Mit Docker Swarm können wir diesen Container bereitstellen, Replikate angeben, und das ist ganz einfach.

Nun wollen wir, dass sich derselbe DSN-Server-Container mit dem DNS-Dienst B im Internet verbindet. Wir folgen den Anweisungen des Container-Maintainers, erstellen zwei (Konfigurations-)Dateien, erstellen ein Volume Mapping und sind fertig.

Teil der Datei Docker-Compose:

...
services:

  dns_service:
    image: ...
    volumes:
      - ./config/definitions1.conf:/opt/dns_server/config/definitions1.conf:ro
      - ./config/definitions2.conf:/opt/dns_server/config/definitions2.conf:ro
    ...

Aber jetzt haben wir ein Problem mit Docker Swarm , weil es unsere Volume-Daten nicht verwaltet! Wenn wir den Dienst auf einem Worker-Node bereitstellen, sind die Daten, die Konfigurationsdateien, nicht vorhanden!

Backen" von Konfigurationsdaten in den Dienst

Wenn wir Docker Swarm verwenden, haben wir keine Daten in unseren Volumes ... wenn wir nichts tun. Es gibt eine Möglichkeit, dieses Problem zu umgehen, sie heißt 'Configs' und ist in Docker-Compose nicht verfügbar. Wir können damit Dateien angeben, die in den Container gemountet werden, wie wir es mit Volumes tun können. Wir sehen uns zunächst die Lösung Docker-Compose an und ändern sie dann in Docker Swarm.

Verwendung von Docker-Compose

Bei der Verwendung von Docker-Compose verwendet die Datei "docker-compose.yml" für unser DNS-Server-Projekt (siehe oben)
Volumes und sieht etwa so aus:

# docker-compose.yml, using volumes

version: '3.7' 

services:
  app:
    image: busybox_volumes
    build: .
    volumes:
      - ./config/definitions1.conf:/opt/dns_server/config/definitions1.conf:ro
      - ./config/definitions2.conf:/opt/dns_server/config/definitions2.conf:ro
    command: sh -c "ls -l /opt/dns_server/config && cat /opt/dns_server/config/definitions*.conf && tail -f /dev/null"

Wir fügen ein 'Dockerfile' hinzu:

# Dockerfile
FROM busybox

Und bauen das Image:

docker-compose build

Und dann führen wir es aus:

docker-compose up

Der Text, der auf dem Bildschirm ausgegeben wird, ist:

app_1  | total 8
app_1  | -rw-rw-r--    1 1000     1000            14 Aug 29 08:06 definitions1.conf
app_1  | -rw-rw-r--    1 1000     1000            14 Aug 29 08:06 definitions2.conf
app_1  | definitions=1
app_1  | definitions=2

Das ist wie erwartet. Aber wenn Docker Swarm diesen Dienst auf einem anderen Host, einem Arbeitsknoten, bereitstellen würde, würden unsere Dateien fehlen.

Verwendung von Docker Swarm

Hier entfernen wir den Abschnitt 'volumes' und fügen den neuen Abschnitt 'configs' hinzu:

# docker-compose.yml, using configs

version: '3.7' 

services:
  app:
    image: busybox_configs
    build: .
    configs:
      - source: definitions1
        target: /opt/dns_server/config/definitions1.conf
      - source: definitions2
        target: /opt/dns_server/config/definitions2.conf
    command: sh -c "ls -l /opt/dns_server/config && cat /opt/dns_server/config/definitions*.conf && tail -f /dev/null"

configs:
  definitions1:
    file: ./config/definitions1.conf
  definitions2:
    file: ./config/definitions2.conf

Erstellen Sie das Image:

docker-compose build

Und dann deployen wir:

docker stack deploy -c docker-compose.yml configs

Das Ergebnis des Deploy-Befehls zeigt die Erstellung des 'configs':

Creating network configs_default
Creating config configs_definitions2
Creating config configs_definitions1
Creating service configs_app

Es wird nichts auf dem Bildschirm ausgegeben, um zu sehen, was los ist, schauen wir uns das Protokoll dieses Dienstes an:

docker service logs configs_app

Das Ergebnis:

configs_app.1.vqumgq21leq8@myra    | total 8
configs_app.1.vqumgq21leq8@myra    | -r--r--r--    1 root     root            14 Aug 29 09:58 definitions1.conf
configs_app.1.vqumgq21leq8@myra    | -r--r--r--    1 root     root            14 Aug 29 09:58 definitions2.conf
configs_app.1.vqumgq21leq8@myra    | definitions=1
configs_app.1.vqumgq21leq8@myra    | definitions=2

Dies bedeutet, dass der Docker Swarm -Manager unsere Dateien korrekt hinzugefügt hat.

In meinem Fall wurde der Dienst auf dem Managerknoten Docker Swarm bereitgestellt, nicht auf dem Arbeitsknoten. Um ihn auf dem Worker Node auszuführen, fügen wir Folgendes zu 'docker-compose.yml' hinzu:

    deploy:
      placement:
        constraints:
          - node.role == worker
      replicas: 1

Markieren Sie Ihr Image und schieben Sie es in Ihre Docker -Registrierung.

Nur wenn Sie eine private Registry verwenden

Wenn Sie eine private, nicht sichere Registry verwenden, müssen Sie allen Docker -Knoten mitteilen, dass sie nicht sicher ist, indem Sie diese Information hinzufügen:

{
    "insecure-registries":[
        "<your registry ip address>:<your registry port>"
    ],
}

in die Datei einfügen:

/etc/docker/daemon.json

Starten Sie Docker neu, sobald Sie dies getan haben:

sudo systemctl restart docker

Wichtig: Sie müssen dies auf allen Knoten tun.

Bearbeiten Sie nun Ihre Datei "docker-compose.yml", um Docker Swarm mitzuteilen, wo er Ihr Image abrufen kann.

Von:

...
services:
  app:
    image: busybox_configs:latest
    ...

Nach:

...
services:
  app:
    image: <registry host>:<registry port>/busybox_configs:latest
    ...

Bereitstellen des Dienstes auf dem Arbeitsknoten

Entfernen Sie den Dienst von diesem Knoten, falls er noch vorhanden ist:

docker stack rm configs_app

Und stellen Sie ihn erneut bereit:

docker stack deploy -c docker-compose.yml configs

Jetzt können Sie überprüfen, ob der Dienst auf dem Arbeitsknoten läuft:

docker service ps configs_app

Das Ergebnis enthält den Knoten, siehe 'NODE':

ID             NAME            IMAGE     NODE         DESIRED STATE   CURRENT STATE           ERROR     PORTS
xotczxp65lub   configs_app.1   ...       vmubs2204a   Running         Running 9 minutes ago             

Weitere Informationen können Sie z.B. mit command erhalten:

docker service inspect --pretty configs_app

Oh, und das Wichtigste, was hat unser Dienst genau gemacht? Es wird nichts auf dem Bildschirm ausgegeben, wir müssen uns die Protokolle ansehen:

docker service logs configs_app

Das Ergebnis ist genau dasselbe wie vorher. Das bedeutet, dass Docker Swarm nicht nur unseren Dienst (Container) bereitgestellt hat, sondern auch unsere 'configs' -Dateien für unseren Container auf dem Arbeitsknoten verfügbar gemacht hat. Das war's.

Zusammenfassung

In diesem Beitrag haben wir Docker Configs verwendet, um (statische) Konfigurationsdaten an Container zu übergeben. In 'docker-compose.yml' haben wir den Abschnitt 'volumes' entfernt und durch den Abschnitt 'configs' ersetzt. Jetzt verwaltet Docker Swarm diese Daten und wir brauchen kein gemeinsames Speichervolumen für diesen Zweck. Das Ärgerliche daran ist, dass 'configs' nicht in Docker-Compose funktioniert, was bedeutet, dass man sich von einer einzigen 'docker-compose.yml' entfernt, die von Docker-Compose und Docker Swarm verwendet werden kann.

Links / Impressum

Data(base) persistence in docker swarm mode
https://forums.docker.com/t/data-base-persistence-in-docker-swarm-mode/20665

Deploy a stack to a swarm
https://docs.docker.com/engine/swarm/stack-deploy

Docker - configs
https://docs.docker.com/compose/compose-file/compose-file-v3/#configs

Docker Swarm Tutorial | Code Along | Zero to Hero under 1 Hour
https://takacsmark.com/docker-swarm-tutorial-for-beginners

How does Docker Swarm implement volume sharing?
https://stackoverflow.com/questions/47756029/how-does-docker-swarm-implement-volume-sharing