Ich habe bei mir lokal einfach mal den aktuellen moodle-Container in Version 3.4 ausprobiert. Das ganze läuft eigentlich rund – bis zum dem Zeitpunkt, als ich heute das hier sah:
Ich hatte natürlich gehofft, dass ich in diesem Fall einfach mit
docker pull bitnami/moodle:latest wieder auf dem aktuellen Stand sein würde. Es wurden tatsächlich auch drei Images neu geholt:
8135b01e98f2: Pull complete
d7e125f1df9f: Pull complete
2a9f21a02a69: Pull complete, doch die moodle-Version hat das scheinbar nicht wirklich auf die aktuelle Version angehoben?!
Unter “Upgrade this application” steht nun, dass man seit Version 3.4 das Upgrade manuell innerhalb des Containers durchführen soll. Also: Habe ich da jetzt was falsch verstanden oder wird damit nicht das ganze Vorgehen immer via docker ganz einfach auf dem aktuellen Stand zu bleiben ad absurdum geführt?
Wie sehen die docker-wizzzards das?
Unter “Upgrade this application https://github.com/bitnami/bitnami-docker-moodle#upgrade-this-application”
steht nun, dass man seit Version 3.4 das Upgrade manuell innerhalb des
Containers durchführen soll. Also: Habe ich da jetzt was falsch
verstanden oder wird damit nicht das ganze Vorgehen immer via docker
ganz einfach auf dem aktuellen Stand zu bleiben ad absurdum geführt?
Wie sehen die docker-wizzzards das?
Nur mal ins blaue - der Container aktualisiert den GIT-Code, aber nicht
die Installation. Das wäre für mich schlüssig, weil das ja das DB-Schema
aktualisiert und das muss ja auf einer laufenden Instanz von Moodle
geschehen.
Wenn man Moodle per GIT pflegt, halte ich Docker da nur für überschaubar
gewinnbringend. Man kommt schnell an ein laufendes System und kann halt
die Pflege von XAMP und Moodle-Code etwas bündeln, aber darüber hinaus
lässt sich Moodle auch so wunderbar pflegen und updaten.
Ja, das hatte ich auch gehofft, doch bisher war es immer so, dass mir ein fälliges Update der DB angezeigt wurde, sobald ich mich als Admin eingeloggt hatte? Das war jetzt aber nicht der Fall (oder es ist nicht mehr so offensichtlich wie früher?)
Ich spiele mit dem Gedanken, das ganze per docker zu machen, weil wir im Moment das Problem haben, dass unser vServer schneller veraltet als moodle erneuert wird. Konkret bedeutet das, dass wir irgendwann nicht mehr updaten können, da z.B. die SQL- und/oder PHP-Version zu alt ist. moodle verlangt da ja meistens relativ aktuelle Versionen, so dass man ab diesem Zeitpunkt von Upgrades abgeschnitten wird. Mit docker wäre das ja egal, da dann alles, was zum Betrieb benötigt wird, ebenfalls im Container läuft. Aber die Entscheidung diesbzgl ist eh noch lange nicht gefallen. Im Moment ist es nur ein Container zum Experimentieren und Kennenlernen der neuen Features. Vor allem die moodle App sieht gut aus – ebenfalls eine Sache, warum ich upgraden wollte.
Hi Tobias
Ich hatte es zwischendurch nochmal getestet. So wie ich das sehe, hat man schlechte Karten, wenn man hofft, dass man mit “docker pull …:latest” auf den aktuellen Stand gelangt. Damit ist es leider nicht getan. Mir ist nicht ganz klar, wo dann noch die Vorteile dieser Vorgehensweise sein sollen???
Michael
mich wundert das nicht: ich habe grade nextcloud per updater von 12 auf 13 angehoben. Dann muss der updater auch die eigene SQL-Datenbank manipulieren. das neue nextcloud kann nicht einfach mit einer neuen Datenbank anfangen.
Genauso kann ein neuer moodle-Docker nicht einfach die neue datenbank-umgebung einspielen, ebensowenig kann es darauf bauen, dass du die alte db schon auf das neue niveau gehoben hast.
Ich vermute, es hängt nur an der Datenbank. Bei mir in nextcloud z.B. kommen seltsame Fehlermeldungen von anmeldedaten, die es nicht gibt. Ich bekomme die Meldungen nicht aus dem System (aus der Datenbank). Es gibt keine Möglichkeit meine Nextcloud „auf eine frische Installation“ zu migrieren, eben weil es keine Migration gibt, und kein „zurück“ zu einer alten Version.
Man wird also nach software-update immer noch ein datenbank-update machen müssen.
Darum wird man nur herumkommen, wenn die moodle-programmierer sich ganz sicher sind, dass das upgrade voll-automatisch ablaufen kann.
Vorteile bleiben dennoch: Ich muss das linux-system nicht kontrollieren und updaten, das erledigt der docker-container-bauer für mich.
Nachteile, wenn die db außerhalb des moodle-containers liegt: ich muss aufpassen, was ich tue, wenn beim upgrade etwas schief geht…
Hi.
Ja, das ist schon klar. Nur: Das Update lässt sich eben leider nicht so einfach anwerfen wie bisher. Bei “normaler” Installation (oder git) beginnt man das DB Update ganz einfach innerhalb der Weboberfläche. Das funktioniert aber mit docker nicht. Da erscheint die Meldung erst gar nicht. Möglich, dass man sich interaktiv mit dem Container verbinden muss und es manuell anstoßen muss. Das habe ich noch nicht ausprobiert…
Hi. ich hab’s gerade nochmal ausprobiert … was problemlos klappt, ist dies:
cd "docker-moodle-verzeichnis"
docker-compose up -d (startet mariaDB & moodle)
docker ps ==> Welche ID hat der moodle-Container “bitnami/moodle:latest”?
docker exec -it “Container-ID” bash (startet eine bash im laufenden docker-Container)
php admin/cli/maintenance.php --enable
php admin/cli/upgrade.php
php admin/cli/maintenance.php --disable
Ich hatte hier leider bereits die aktuelle Version lokal auf der Platte, so dass bei den php-Befehlen nichts ausgeführt wurde. Daher kann ich nicht wirklich beurteilen, ob das Upgrade auf diesem Weg durchgeführt wird, oder man im falschen Container ist bzw ob man das Upgrade auf diesem Weg nicht erwischt. Aber wenn es so klappt, wäre das vielleicht doch ein möglicher Weg auf künftigen Servern?!?
Frank (@ironiemix): Wie schätzt du die Lage ein? Schraubst du eigentlich noch an Teil 6 deiner Videos oder ist das vorerst beendet?
Hi.
Ich bin mittlerweile davon überzeugt, dass man auf diesem Weg kein „immer-aktuelles-moodle im Container“ bereitstellen kann. Der Upgrade-Prozess von moodle selbst verlangt, dass man das innerhalb des Containers macht. Der Grund ist …
so for upgrading moodle and keep the plugin and themes persistent, the only way is upgrading the application inside the container?
Yes. The reason behind is that the Moodle application does not have a unique folder to store plugins and themes as you can see here. Therefore, there is no way to persist all those plugins directories and ensure that after upgrading Moodle using a new version of the docker image it actually contains all the new source code.
Daher eine neue Idee:
Bislang hatte ich unser (altes) moodle direkt via git bereitgestellt. Da reichte immer ein einfaches „git pull“ und ich war im aktuellen branch wieder up-to-date. Wie wäre es, wenn man per docker „nur“ ein vollständiges LAMP-System immer up-to-date hält und in einem der persistenten Volumes das aktuelle moodle per git bereit stellt? Würde das nicht das Problem lösen? Bisher fand ich es immer relativ aufwändig, von einem Server zum nächsten zu ziehen und danach alle moodle-Settings + Restore aller Kurse per Hand durchführen zu müssen. Da muss es doch eine Abkürzung geben?!?
