Bash Docker compose Aktualisierungsskript

[CyborgBeta]

Moin, könnt ihr mal schauen, ob das so geht, oder ob ich etwas übersehen (oder doppelt) habe? Das Script läuft eigentlich einmal pro Tag.

#!/bin/bash
docker compose down
sleep 10
sudo apt update && sudo apt upgrade -y && sudo apt autoremove && sudo apt autoclean
sleep 10
docker compose pull
docker compose build --pull
docker compose up -d
sleep 10
docker system prune -a -f

 

[cloudman]

Compose down ist nicht notwendig.
Ich verwende allerdings watchtower.

docker run -d \
  --name watchtower \
  -v /var/run/docker.sock:/var/run/docker.sock \
  containrrr/watchtower

 

[boeck]

Schaut so aus als on es funktionieren sollte.

Was mich ein wenig stutzig macht ist das apt update. Das hat nicht wirklich was mit Docker zu tun.

Und wenn du mehrere Compose Dateien hast musst du in jeden Ordner gehen und das Skript erneut ausführen. Wodurch dann das apt update jedes Mal unnötigerweise gemacht wird.

Die sleep sind nett, aber werden imho nichts bringen.

Oder du verwendest was fertiges wie https://github.com/mag37/dockcheck

 

[JumpingCat]

• Bei einem Kernel-Update gibt es kein reboot
• Es wird kein Dienst neu gestartet bei einem Update
• docker compose pull --include-deps --no-parallel für den Fullstack und nichts parallel, oder?
• down ist wofür gut?

 

[CyborgBeta]

Stimmt alles. Den Reboot würde ich manuell machen.

Prinzipiell soll das System und alle Docker-Container geupdatet werden. Es gibt nur eine docker-compose.yml, deshalb kann das in einem Schritt erfolgen.

Bei autoremove fehlte noch ein -y.

Die Docker-Images sind so eingestellt, dass sie bei einem Fehler nicht automatisch neu starten sollen (manuelles Eingreifen ist dann erforderlich).

Wie kriege ich denn: stop + upgrade (und clean) + pull + build pull + reboot (wenn erforderlich) + start (und prune) in einem (einzigen) Script unter?

Zusatz: Der Neustart/Rebuild dauert ca. 1 Minute, das ist von der Ausfallzeit gar kein Problem.

 

[boeck]

Wie gesagt sollte es glaube ich so passen. Das down und die sleep solltest du dir sparen können.

 

[cloudman]

Reboot:

if [ -f /var/run/reboot-required ]
then
    reboot
fi

 

[CyborgBeta]

Reboot:

Vielen Dank!

/var/run/reboot-required kannte ich noch gar nicht ...

Noch eine Frage. Kann ich ein Script nur genau einmal beim nächsten Systemstart starten lassen und danach nicht mehr?

Ich hab dann Folgendes vor:

Docker down
Update System
Update Docker
Wenn reboot required dann
  Docker down
  Setze Neustartskript (Docker up)
  reboot
sonst
  Docker up
Ende

 

[boeck]

Docker Container welche vor dem Neustart gestartet waren werden bei mir nach dem Neustart automatisch wieder gestartet. Kann sein, dass du hierzu die Restart Policy im Compose entweder auf unless-stopped oder always setzen musst.

 

[Marco01_809]

Die APT Upgrades würde ich nicht mit eigenem Script machen. Schaue dir stattdessen mal unattended-upgrades an Da kann man auch konfigurieren dass es nur aus bestimmten Paketquellen automatisch Updates installiert, und auch den Reboot bei Kernel-Updates übernimmt es, mit einstellbarer Uhrzeit. Möchte man keine automatischen Reboots kann es auch Mail-Benachrichtigungen verschicken.

 

[CyborgBeta]

Ich hab nun Folgendes:

#!/bin/bash
if [ $# -eq 0 ]
then
    bash ~/proxy/script_all.sh "arg1" &> ~/proxy/log.txt
    exit 0
fi
cd ~/proxy/ || exit
docker compose down
sleep 5
sudo apt update && sudo DEBIAN_FRONTEND=noninteractive apt upgrade -y && sudo apt autoremove -y && sudo apt autoclean
sleep 5
if [ -f /var/run/reboot-required ]
then
        at now + 2 minute -f ~/proxy/script_all.sh
        sudo reboot
else
        docker compose pull
        docker compose build --pull
        docker compose up -d
        sleep 5
        docker system prune -a -f
        docker system df
        sleep 5
        docker stats --no-stream | sort -k 2
fi

Bin mir nicht sicher, ob das funktioniert ...

Denkt euch die sleep 5 bitte weg ...

Mit at kann ich neu starten und das gleiche Script danach wieder aufrufen

Mit if [ $# -eq 0 ] kann ich testen, ob das Script ohne Argumente aufgerufen wurde und in diesem Fall das Script erneut aufrufen und die Ausgabe umlenken

Alles zusammen würde ich einmal am Tag via cron aufrufen (und hoffen, dass nix schiefläuft ...).

 

[CyborgBeta]

Das scheint "einwandfrei" zu funktionieren. Sowohl, wenn ich das Script manuell aufrufe mit bash script_all.sh, als auch, wenn ich das Script über crontab starten lasse.

Was mich aber noch verwirrt, ist Folgendes: Wenn ich at now + 5 minute -f ~/proxy/script_all.sh manuell aufrufe und mich dann auslogge, dann wird das Script ganz normal ausgeführt, aber die log-Datei (log.txt) ist leer (0 Byte). Woran liegt das? Wird das Script dann als anderer Benutzer aufgerufen?

 

[cloudman]

Ich würde das Script mit systemd starten

https://www.suse.com/support/kb/doc/?id=000019672

 

[CyborgBeta]

hm, es soll eigentlich als normaler Benutzer (ich) gestartet werden (immer(!)).

 

[CyborgBeta]

Wenn ich at now + 5 minute -f ~/proxy/script_all.sh manuell aufrufe und mich dann auslogge, dann wird das Script ganz normal ausgeführt, aber die log-Datei (log.txt) ist leer (0 Byte).

Hab herausgefunden, woran es lag.

at ruft das Script immer mit sh auf, nicht mit bash. &> ist aber eine reine bash-Anweisung, nicht POSIX.

Also sollte es korrekterweise so sein:

#!/bin/sh
spath="/a/b/c/"
sname="script.sh"
if [ $# -eq 0 ]
then
    sh "${spath}${sname}" "arg1" > "${spath}log.txt" 2>&1
    exit
fi
whoami
cd $spath || exit
docker compose down
sudo apt update && sudo DEBIAN_FRONTEND=noninteractive apt upgrade -y && sudo apt autoremove -y && sudo apt autoclean
if [ -f /var/run/reboot-required ]
then
        at now + 2 minute -f "${spath}${sname}"
        sudo reboot
else
        docker compose pull
        docker compose build --pull
        docker compose up -d
        docker system prune -a -f
        docker system df
        docker stats --no-stream | sort -k 2
fi