Verwendung des WordPress-CLI-Images auf Kubernetes

Wir haben ein benutzerdefiniertes Docker-Image basierend auf dem offiziellen WordPress-Image, das ein benutzerdefiniertes Thema enthält, das wir entwickeln. Wir haben CI/CD in diesem Projekt mit Gitlab CI und Bereitstellung von Branches auf einem Bare-Metal-Kubernetes-Cluster v1.6 zur Überprüfung. Es funktioniert gut, aber wir versuchen, den Prozess zu verbessern, indem wir die erforderlichen manuellen Aktionen automatisieren, wenn eine neue Instanz bereitgestellt wird:

• WordPress installieren
  • Administratoranmeldeinformationen festlegen
  • Festlegen des Site-Namens und der URL
• Thema aktivieren
• Plugins aktivieren
• Importieren von Daten
• usw.

wp-cli hat alle nötigen Befehle. Aber wie verwendet man es mit Containern und K8S? Uns ist bewusst, dass es zwei Möglichkeiten gibt:

• Installieren des Tools in unserem WordPress-basierten Image.
• Verwenden Sie einen zweiten Behälter, der nur enthält wp-cli und kommuniziert mit dem Hauptcontainer.

Es gibt WordPress-Images mit vorinstalliertem wp-cli (zB tutum-docker-wordpress), aber wir glauben, dass dies nicht der richtige Weg ist. Irgendwann möchten wir eine CronJob-Ressource mit dem cli-Image verwenden, um jeden Tag Daten zu exportieren, und wir versuchen, den Prozess so generisch wie möglich zu gestalten, und wir möchten dabei bleiben offizielle Bilder Daher wird die zweite Option bevorzugt. Basierend auf unseren Recherchen müssen wir zur Umsetzung der zweiten Option zwei Dinge erreichen:

• Greifen Sie über den CLI-Container auf die Dateien der WordPress-Installation zu.
• Versuchen Sie es nach erfolgreicher Ausführung nicht erneut.

Wir haben einige Optionen ohne vollen Erfolg recherchiert:

• Zweiter Container im selben Pod – Es scheint möglich, Dateien zwischen beiden Containern zu teilen EmptyDiraber selbst wenn der Container erfolgreich ist, wird er neu gestartet.
• InitContainer – Das klingt sehr verlockend, weil Datenbankmigrationen auf diese Weise durchgeführt werden. Es scheint jedoch unmöglich zu sein, die Dateien zu erhalten, es sei denn, Sie verwenden ein benutzerdefiniertes Image.
• Arbeit – Es ist genau auf einmalige Aufgaben ausgelegt, jedoch scheint der Zugriff auf die Dateien eines Containers in einem Pod nicht möglich zu sein.

Dies scheint eine ziemlich häufige Funktion zu sein, wenn Sie Überprüfungsbereitstellungen von WordPress auf Kubernetes bereitstellen, und jemand sollte dies bereits getan haben. Wir konnten jedoch keine spezifischen Informationen zu diesem Anwendungsfall finden.

Lassen Sie sich beraten, was für Sie der beste Weg ist, um die gewünschte Umsetzung zu erreichen, und wie?

Sie können ein NFS-basiertes Dateisystem verwenden und Ihre WordPress-Inhalte in jede Art von Workload mounten.

Wenn Sie etwas brauchen, um Ihnen den Einstieg zu erleichtern, schauen Sie vorbei https://matthewdavis.io/highly-available-wordpress-on-kubernetes/.

Basierend auf dem obigen Hinweis von @kotsov haben wir dies mithilfe von Init-Containern in der Bereitstellung zum Laufen gebracht.

Schritte:

• Der erste Init-Container startet das WordPress-Image, jedoch mit überschriebenen Argumenten [“apache2-foreground”,”-version”]. Dadurch wird der Einstiegspunkt ausgeführt, WordPress installiert / eingerichtet, falls erforderlich, aber dann mit der Version beendet.
• Der zweite Init-Container ist das WordPress-Cli mit seinen Befehlen.
• Danach wird der WordPress-Container wieder laufen gelassen.

Wir richten diese auch auf einem persistenten Volume für /var/www/html ein, sodass es all dies nicht tun muss, wenn es erneut gestartet wird. Die Init-Schritte überspringen Initialisierungsschritte basierend auf Verzeichnisinhalten.

In der Bereitstellungsvorlage:

initContainers:
- name: Initialise WordPress
  image: wordpress: <version>
  args: ["apache2-foreground","-version"]
  env: 
    <your wordpress env>
  volumes:
    <shared volume info>
- name: WordPress CLI commands
  image: wordpress-cli: <version>
  env: 
    <your wordpress cli env>
  volumes:
    <shared volume info>
containers:
- name: WordPress
  image: wordpress: <version>
  env: 
    <your wordpress env>
  volumes:
    <shared volume info>