Hallo,
da ich mich aktuell mit Containern und dem Aufbau einer eigenen Containerregistry beschäftige, hier mal eine Frage in die Runde.
Wie kann ich eigentlich Containerverbünde ala Docker Compose automatisch starten wenn das Hostsystem neubootet? Bei Podman & Co. ginge das ja vermutlich mit systemd recht gut.
Ich habe es bereits mit der Docker-Restart Policy probiert (und diese nun direkt in der docker-compose.yaml angegeben) auch lasse ich den Docker-Deamon per Systemd beim Booten automatisch starten. Allerdings startet der Containerverbund nur nach einem `docker compose up` aus dem Verzeichnis, in dem die docker-compose.yaml & Co. liegen.
Kann hierbei jemand helfen?
Viele Grüße Norman
Hallo Norman,
On 17.02.2025 20:20, N. Schwirz wrote:
Wie kann ich eigentlich Containerverbünde ala Docker Compose automatisch starten wenn das Hostsystem neubootet? Bei Podman & Co. ginge das ja vermutlich mit systemd recht gut.
Ich habe es bereits mit der Docker-Restart Policy probiert (und diese nun direkt in der docker-compose.yaml angegeben) auch lasse ich den Docker-Deamon per Systemd beim Booten automatisch starten. Allerdings startet der Containerverbund nur nach einem `docker compose up` aus dem Verzeichnis, in dem die docker-compose.yaml & Co. liegen.
das Internet [1] sagt
|docker.service| enabled on system startup: | $sudo systemctl enable docker|| |
|docker-compose.yml| has restart enabled: | restart: always |
und gestartet werden muss als daemon (-d): | docker compose up -d |
|Stimmen alle diese Voraussetzungen bei Dir? |
|Grüße, Christoph |
Hallo Christoph,
On 17.02.25 23:27, Christoph Müller wrote:
Hallo Norman,
On 17.02.2025 20:20, N. Schwirz wrote:
Wie kann ich eigentlich Containerverbünde ala Docker Compose automatisch starten wenn das Hostsystem neubootet? Bei Podman & Co. ginge das ja vermutlich mit systemd recht gut.
Ich habe es bereits mit der Docker-Restart Policy probiert (und diese nun direkt in der docker-compose.yaml angegeben) auch lasse ich den Docker-Deamon per Systemd beim Booten automatisch starten. Allerdings startet der Containerverbund nur nach einem `docker compose up` aus dem Verzeichnis, in dem die docker-compose.yaml & Co. liegen.
das Internet [1] sagt
|docker.service| enabled on system startup: | $sudo systemctl enable docker|| |
|docker-compose.yml| has restart enabled: | restart: always |
und gestartet werden muss als daemon (-d): | docker compose up -d |
|Stimmen alle diese Voraussetzungen bei Dir? |
ja, so siehts bei mir auch aus. Laut Doku sollten nun alle Container in der richtigen Reihenfolge starten sobald der Host neustartet. Allerdings tun sie das bei mir leider nicht. Ich verwende ein etwas älteres Ubuntu (20.04 oder 22.04, da bin ich mir gerade nicht sicher).
|Grüße, Christoph |
Grüße Norman
Am Montag, dem 17.02.2025 um 20:20 +0100 schrieb N. Schwirz:
[..]
Ich habe es bereits mit der Docker-Restart Policy probiert (und diese nun direkt in der docker-compose.yaml angegeben) auch lasse ich den Docker-Deamon per Systemd beim Booten automatisch starten. Allerdings startet der Containerverbund nur nach einem `docker compose up` aus dem Verzeichnis, in dem die docker-compose.yaml & Co. liegen.
Du kannst hier entweder in der systemd .service-Datei das Arbeitsverzeichnis definieren, z.B.
[Service] User=meinuser Group=docker WorkingDirectory=/root/git/gitlab
Oder du gibt dem docker-compose-Befehl den Pfad zur docker-compose- Datei mit. Ich würde erstes empfehlen. VG Daniel
Am 21.02.25 um 20:15 schrieb Daniel Leidert:
Am Montag, dem 17.02.2025 um 20:20 +0100 schrieb N. Schwirz:
Du kannst hier entweder in der systemd .service-Datei das Arbeitsverzeichnis definieren, z.B.
[Service] User=meinuser Group=docker WorkingDirectory=/root/git/gitlab
Oder du gibt dem docker-compose-Befehl den Pfad zur docker-compose- Datei mit. Ich würde erstes empfehlen.
@daniel: Von welcher systemd service-Datei redest du? Es gibt keine und braucht keine service-Datei um docker Container (oder einen compose Verbund) zu starten! Das ist bei podman anders, weil es dort (normalerweise) keinen Daemon gibt, der alle Container verwaltet!
@norman: Bei Docker gilt im Normalfall, also bei einer Standardinstallation ohne eigene Anpassungen an den verschiedenen beteiligten Diensten, dass a) der Docker Daemon beim Start des Rechners auch gestartet wird b) der Docker Daemon beim Start alle Container startet, die eine passende restart-policy haben
Wenn das nicht funktioniert, startet dein Docker vielleicht nicht beim Systemstart. Vielleicht hast du nicht den service, sondern den socket aktiviert. Der sorgt erst nach einem Zugriff auf den Docker-Socket dafür, dass der Docker Daemon startet. Das passiert aber nicht automatisch beim Systemstart. Wenn das der Fall ist, müssten deine compose Container (wenn sie restart gesetzt haben) aber starten, sobald du auf den Docke-Socket zugreifst, z.B. mit `docker ps`.
Also kontrollier nach einem Systemstart a) ob der Docker Service läuft b) mit `docker ps` welche Container laufen c) mit `docker ps -a` welche Container gestoppt sind
Wenn das Systemstartverhalten OK ist, brauchst du nicht mehr das System neu starten um dein Fehlerbild zu untersuchen. Es reicht ein Restart des Docker-Service.
Die RestartPolicy für einen laufenden Container fragst du mit diesem Befehl ab: docker inspect -f "{{ .HostConfig.RestartPolicy }}" ct-name-or-id
Compose verhält sich nicht anders als manuell gestartete Container!
Vielleicht hast du auch in deinem compose-Verbund die Abhängigkeiten nicht korrekt definiert und die Container werden zwar beim Start von Docker gestartet, aber in der falschen Reihenfolge und das kann je nach Containerverbund dazu führen, dass sie beendet werden, weil eine Gegenstelle nicht innerhalb eines Timeouts antwortet oder Ähnliches.
Am Freitag, dem 21.02.2025 um 21:02 +0100 schrieb Uwe Koloska:
Am Montag, dem 17.02.2025 um 20:20 +0100 schrieb N. Schwirz:
Du kannst hier entweder in der systemd .service-Datei das Arbeitsverzeichnis definieren, z.B.
[Service] User=meinuser Group=docker WorkingDirectory=/root/git/gitlab
Oder du gibt dem docker-compose-Befehl den Pfad zur docker-compose- Datei mit. Ich würde erstes empfehlen.
@daniel: Von welcher systemd service-Datei redest du?
Ich hatte den OP zu schnell gelesen. Ich dachte, der OP startet aus einer systemd .service Datei den Verbund und wäre der Meinung, das ginge nicht weil er docker-compose im Verzeichnis ausführen muss, in dem die docker-compose.yaml liegt. Daher mein Hinweis. Ich sehe nun, dass ich zu schnell gelesen habe.
Unabhängig davon kann man einen derartigen Verbund natürlich auch via selbst geschriebener Service-Datei laufen lassen. Als Beispiel:
---------------------------------------------- [Unit] Description=Foo Docker Service Requires=docker.service After=network.target docker.service ConditionPathExists=/srv/foo/docker-compose.yml
[Service] User=user Group=docker WorkingDirectory=/srv/foo Environment=FOO_HOME=/srv/foo/data ExecStartPre=/usr/bin/docker-compose pull --include-deps ExecStart=/usr/bin/docker-compose up ExecReload=/usr/bin/docker-compose restart -t 30 ExecStop=/usr/bin/docker-compose down --remove-orphans Restart=on-failure
[Install] WantedBy=multi-user.target Alias=docker-foo.service -----------------------------------------------
Wenn Docker die Container nicht automatisch startet, ist das eine Alternative.
VG Daniel
Hallo und vielen Dank für all eure Hinweise.
Das erstellen eines eigenen Service-/Unitfiles klingt mir am vielversprechendsten. Außerdem werde ich mal schauen ob es unter Ubuntu 24.04 im Gegensatz zu 22.04 vielleicht von selbst funktioniert. Es ist schon eine Ironie das ausgerechnet eine Containerregistry, die containerisiert daher kommt, nicht automatisch ordentlich startet.
Viele Grüße Norman
On 21.02.25 21:28, Daniel Leidert wrote:
Am Freitag, dem 21.02.2025 um 21:02 +0100 schrieb Uwe Koloska:
Am Montag, dem 17.02.2025 um 20:20 +0100 schrieb N. Schwirz:
Du kannst hier entweder in der systemd .service-Datei das Arbeitsverzeichnis definieren, z.B.
[Service] User=meinuser Group=docker WorkingDirectory=/root/git/gitlab
Oder du gibt dem docker-compose-Befehl den Pfad zur docker-compose- Datei mit. Ich würde erstes empfehlen.
@daniel: Von welcher systemd service-Datei redest du?
Ich hatte den OP zu schnell gelesen. Ich dachte, der OP startet aus einer systemd .service Datei den Verbund und wäre der Meinung, das ginge nicht weil er docker-compose im Verzeichnis ausführen muss, in dem die docker-compose.yaml liegt. Daher mein Hinweis. Ich sehe nun, dass ich zu schnell gelesen habe.
Unabhängig davon kann man einen derartigen Verbund natürlich auch via selbst geschriebener Service-Datei laufen lassen. Als Beispiel:
[Unit] Description=Foo Docker Service Requires=docker.service After=network.target docker.service ConditionPathExists=/srv/foo/docker-compose.yml
[Service] User=user Group=docker WorkingDirectory=/srv/foo Environment=FOO_HOME=/srv/foo/data ExecStartPre=/usr/bin/docker-compose pull --include-deps ExecStart=/usr/bin/docker-compose up ExecReload=/usr/bin/docker-compose restart -t 30 ExecStop=/usr/bin/docker-compose down --remove-orphans Restart=on-failure
[Install] WantedBy=multi-user.target Alias=docker-foo.service
Wenn Docker die Container nicht automatisch startet, ist das eine Alternative.
VG Daniel
lug-dd@mailman.schlittermann.de