docker-compose "restart" bash script

@Cardiac sagte in docker-compose "restart" bash script:

docker compose up --build --pull -d fertig

Nö, funktioniert nicht.

Glaubst du, es hatte für Script-Zeile 8 keinen Grund?

Edit: zumindest funktioniert, so glaube ich, up --build --pull -d mit docker-compose nicht...

@Cardiac sagte in docker-compose "restart" bash script:

in der theory kannst du das command noch verkuerzen, zu docker compose down --rmi all && docker compose up --build -d (--pull switch removed from up command) wenn du deinen services im compose file ne pull_policy verpasst.

Ok, danke.

$ docker compose
docker: 'compose' is not a docker command.
See 'docker --help'

@Fragender sagte in docker-compose "restart" bash script:

Glaubst du, es hatte für Script-Zeile 8 keinen Grund?

glauben brauche ich es nicht, denn ich weiss es besser.

@Fragender sagte in docker-compose "restart" bash script:

Edit: zumindest funktioniert, so glaube ich, up --build --pull -d mit docker-compose nicht...

du hast recht, da fehlt die pull option --pull always|missing|never ref

@Fragender sagte in docker-compose "restart" bash script:

$ docker compose
docker: 'compose' is not a docker command.
See 'docker --help'

https://docs.docker.com/compose/install/linux/#install-using-the-repository ?

@Cardiac Ja, das war das Problem, ich hatte anstatt docker-compose-plugin nur docker-compose installiert ... Jetzt muss ich mir überlegen, wie ich das am besten rückgängig machen kann, also wieder deinstalliere. Danke für den Hinweis.

@Cardiac sagte in docker-compose "restart" bash script:

docker compose down --rmi all && docker compose up --build --pull -d

Was genau würde --rmi all bewirken? Und was hast du gegen docker system prune -a -f einzuwenden?

@Fragender sagte in docker-compose "restart" bash script:

Was genau würde --rmi all bewirken?

RTFM, ich habe extra die docs gelinkt, die sind nicht schlecht.

@Fragender sagte in docker-compose "restart" bash script:

Und was hast du gegen docker system prune -a -f einzuwenden?

du willst deine compose projects einzeln handlen. alles was du in dein script jagst, sollte genau nur anfassesn, was es anfassen soll. In diesem fall dieses eine compose. docker system kennt diesen scope nicht. das operiert auf - festhalten - system ebene. Wenn du zwei, drei compose projects auf dem host laufen hast, und eines davon ist beispielsweise grade down, und du jagst da nen system prune -a -f drueber, dann ist das weg.

du kannst system prune mal manuell durchlaufen lassen, um das system in nen clean state zu bekommen, aber danach sollte jedes compose project seinen eigenen krams wegraeumen, und etwaige one-shot container ebenfalls (aka docker run --rm)

Ich habe mein docker compose restart bash script jetzt noch einmal angepasst. Denn es macht ja keinen Sinn, system prune schon vor der Aktualisierung aufzurufen, das erzeugte ja unnötige Daten ...

#!/bin/bash
cd ./folder1/ || exit
docker compose down
docker compose pull
docker compose up --build -d
if [[ -n "$1" ]] && [[ "${1#*.}" == "prune" ]]; then
        docker system prune -a -f
        docker system df
fi

Passt das so?

@Cardiac sagte in docker-compose "restart" bash script:

pull und dann build macht nicht viel sinn, das laesst orphans und dependency images zurueck, also wenn du base images haben willst, und darauf was aufbauen willst, entweder up --build --pull oder build --pull und danach den ganzen krams starten.

@Cardiac man muss auf die Reihenfolge achten,

#!/bin/bash
docker compose down
docker compose up --pull --build --detach
if [[ -n "$1" ]] && [[ "${1#*.}" == "prune" ]]; then
        docker system prune -a -f
        docker system df
fi

(also docker compose up --pull --build --detach) funktioniert ...

Danke dafür, das Thema ist nun gelöst.

Guten Morgen & schönen 1. Advent!

Ich habe ein Aktualisierungsskript, das jeden Morgen einmal läuft. Heute Morgen bekam ich jedoch folgende Fehlermeldung:

https://stackoverflow.com/questions/70400523/error-while-removing-network-network-id-has-active-endpoints

Die gute Nachricht ist, der Server läuft inzwischen nach einem Neustart wieder.

Die schlechte Nachricht ist, ich muss mich jetzt auf die Fehlersuche begeben, damit es evtl. nicht noch einmal passiert.

Die "--remove-orphans"-Option hatte nichts bewirkt.

Die letzte Fehlermeldung, nach "docker compose down", war:

 Network proxy_default  Removing
 Network proxy_default  Error
failed to remove network proxy_default: Error response from daemon: error while removing network: network proxy_default id <id...> has active endpoints

Und "docker ps" gab eine leere Liste aus.

Woran hat das wohl gelegen und welche log-Dateien kann ich mir ansehen?

Glaube, ich habs...

Zu der docker-compose.yml wurde ein Service hinzugefügt und noch einmal "docker compose up -d" aufgerufen, ohne dass vorher "docker compose down" aufgerufen wurde. Das mag docker bzw. der Proxy nicht, egal, ob ein Service hinzugefügt oder entfernt wird.

... Was mich aber noch wundert ist, dass das Aktualisierungsskript bereits zweimal (ohne Neustart) ohne Probleme durchlief. Daher ist das nur eine Vermutung...

Auf jeden Fall scheint etwas mit dem docker systemd deamon service nicht gestimmt zu haben.

Kann euch auch gerne einen Teil des Skripts zeigen:

#!/bin/sh
set -e
#...
cd $spath
docker compose down
# To go sure, docker is down and file operations are complete
sleep 5
sudo sh -c "apt update && DEBIAN_FRONTEND=noninteractive apt upgrade -y && apt autoremove -y && apt autoclean"
# To go sure, upgrades are done
sleep 5
docker compose pull
docker compose build --pull
docker compose up -d
# To go sure, docker is running again
sleep 5
docker system prune -a -f
# Just for information purposes, everything is up
sleep 5
docker system df
docker stats --no-stream | sort -k 2
if [ -f /var/run/reboot-required ]
then
        #... do some magic
fi

Der Fehler trat direkt in Zeile 5 auf, bei der letzten compose down Anweisung, network removing...

Die deamon logs ("sudo journalctl -xu docker.service") waren, im Vergleich zum Vortag, unauffällig.