Dieses Tutorial ist VALID.

Bitte lies Dir den Disclaimer durch, bevor Du eine Anleitung umsetzt...

Haftungsausschluss / Disclaimer

CRON Events in Docker Containern zum Laufen bringen

Zeitgesteuerte Events in Docker Containern auslösen? Da beißen wir auf Granit! Aber es gibt Mittel. Und es gibt Wege.

Derer drei, um genau zu sein…

„OK, cron Events in einem Container ausführen? Ist doch billig…?“ mag sich der geneigte Leser denken. Ja, dem wäre auch so, wenn die lieben Entwickler cron nicht aus den Basis-Images entfernt hätten! Erinnert mich frappant an die E-Mail Funktionalität, weil sendmail ist ja auch weg.

Das Problem dabei ist, dass Du cron nicht so leicht nachrüsten kannst, wie eine sendmail Alternative. Also, theoretisch schon. Aber das Starten wird zum Problem.

Was also tun?

Methode #1: cron doch in den Container frankensteinen

Gleich vorneweg: Nein, das ist keine gute Idee. Bitte nicht machen!

Beim Arbeiten mit dem Nextcloud Image dachte ich, die Leute von Nextcloud hätten dafür eine Lösung gefunden, cron doch im Container zu starten. Die machen das auch eigentlich ziemlich clever…

Im Image erzeugen sie eine crontab-Datei, in der die Anweisung für cron steht. Dann installieren sie ins Image noch das „busybox-static“ Toolkit. Darin befindet sich eine Version von cron. Sie schreiben ein Startscript, „cron.sh“, das zusammen mit dem Entrypoint-Script in das Image kopiert wird. Aber das war’s dann, denn ich habe nicht gesehen, dass sie das ausführen. Entweder ist das in v16.0.4 verpfuscht, oder ich finde den Trigger nicht. Wenn ich im Container nachsehe, läuft dort auch nur der Apache und kein cron. Ich versteh’s nicht.

Aber selbst wenn man das zum Laufen bekäme… Ich hab mit meinen Admins geredet und beide halten das für faulen Zauber. Sie würden das generell nicht empfehlen, denn ein solcher „Schurken-Prozess“ läuft ohne Sicherung im Container. Hängt er sich auf, stürzt er ab? Niemand bekommt das mit. Das kann auch ein böses Eigenleben entwickeln und schlimmstenfalls die Integrität des kompletten Containers gefährden.

Also machen wir das nicht, auch, wenn wir es zum Laufen bringen würden.

Denn zum Glück haben wir für diesen Fall noch zwei „Workarounds“ am Start:

Methode #2: Den Event über einen zweiten Container anstoßen

Auch vorneweg: Ebenfalls nicht unbedingt eine Glanzlösung. Geht, verbrennt aber zusätzliche Ressourcen und macht den Start/Stop Prozess der Container sehr träge…

Matomo macht das zum Beispiel so. Hier der interessante Teil der „docker-compose“-Datei:

services:

 matomo:
  image: matomo-php73-apache:latest
  container_name: matomo
  volumes:
   - ./wwwdata:/var/www/html

...

 matomo-cron:
  image: matomo-php73-apache:latest
  container_name: matomo-cron
  restart: always
  volumes:
   - ./wwwdata:/var/www/html
...
  entrypoint: |
   bash -c 'bash -s <<EOF
   trap "break;exit" SIGHUP SIGINT SIGTERM
   while /bin/true; do
    su -s "/bin/bash" -c "/usr/local/bin/php /var/www/html/console core:archive" www-data
    sleep 1800
   done
   EOF'

Wir ziehen innerhalb der „docker-compose“-Datei zwei Container aus dem gleichen Image hoch: Einen „normalen“ Matomo Container, der die Anwendung startet. Wie alle unsere anderen Container auch. Aber hinterher starten wir noch einen zweiten Container, der „matomo-cron“ heißt und über ein gemeinsames Volume Zugriff auf unseren ersten Anwendungs-Container bekommt. Im matomo-cron Container führen wir zwischen einem Start/Stop Block eine Schleife aus, die alle 1800 Sekunden (30 Minuten) als Benutzer „www-data“ die Kommandozeilenversion von „php“ im Container startet und damit die Datei „/var/www/html/console“ mit dem Parameter „core:archive“ ausführt.

Wie gesagt: Kann man machen. Wir bekommen mit, falls dem Prozess etwas zustoßen würde und die „restart: always“ Instruktion würde ihn neu starten. Aber insgesamt… Es bläht halt Docker auf, weil wir jetzt pro Anwendung zwei Container laufen haben. Für die eine Instanz von Matomo… Geschenkt! Aber wenn wir das mit 10 WordPress Instanzen machen? Dann wird das doch recht schnell recht viel.

Also ebenfalls nur eine Notlösung, die wir eigentlich nicht benutzen sollten.

Zum Glück haben wir noch eine dritte Methode im Werkzeugkasten:

Anzeige *

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Verwendung
von Cookies

Um unsere Webseite für Sie optimal zu gestalten und fortlaufend verbessern zu können, verwenden wir Cookies. Durch die weitere Nutzung der Webseite stimmen Sie der Verwendung von Cookies zu. Weitere Informationen zu Cookies erhalten Sie in unserer Datenschutzerklärung.

Scroll to Top