WordPress “Nativ-Installation” nach Docker Container umziehen

Nachdem ich nun meine WordPress Docker Container am laufen habe, ist es an der Zeit meine alten WordPress-Installationen umzuziehen. Der Use-Case ist simple:

  • Die WordPress-Installation, welche bisher “nativ” auf www.meinedomäne.ch lief soll nun neu vom neu erstellen Docker-Container beliefert werden.

Das Umziehen einer bestehenden WordPress-Installation war kniffliger als erwartet. Auf diesem Wege hat es dann für mich funktioniert:

  • Als Erstes einen Docker-Container erstellen. Siehe hier. Wichtig war, dass der Container erst ohne die SSL-Erweiterung (inkl. wpinit.sh und apache2vhosts.conf) gestartet wurde.
  • Das so erstellte Image ist nun über http://lokaleIp:port erreichbar.
  • Nun die Installations-Routine von WordPress durchlaufen.
  • Nun auf der WordPress-Installation, welche umgezogen werden soll, das Plugin “All-in-One WP Migration” installieren und damit die WordPress-Export (in ein File) erstellen.
  • Nun wieder auf die Docker-Wordpress Installation wechseln, auch hier das Plugin “All-in-One WP Migration” installieren und anschliessend einen WordPress-Import aus dem erstellten File durchführen.
  • Damit sollte der Umzug schon erledigt sein.
  • Ich habe dann noch das Plugin “SSL Insecure Content Fixer” installiert um sicherzustellen, dass die noch folgende SSL-Aktivierung sicher funktioniert => Das ist evtl. aber gar nicht nötig…
  • Nun Kann die Docker-Instanz gestoppt und wpinit.sh und apache2vhosts.conf im yml-File aktiviert werden. Anschliessend die Docker-Instanz wieder starten:

    Damit ist nun auch SSL aktiviert, so dass der Docker-Container über SSL die Seite ausliefert.

WordPress Container auf Docker

Dieser Blog-Eintrag beschreibt, wie man auf WordPress auf einem Docker-Host installieren und damit mehrere WordPress-Instanzen auf einem Host betreiben kann.
Ich betreibe die Docker-Container hinter einem Proxy-Server, der aber nicht als Container läuft. Der Proxy-Server leitet die HTTPS-Requests an die entsprechenden Docker-Container weiter.

Dieser Beitrag setzt ein vorinstalliertes Photon 3.0 inkl. Docker und Docker-Compose voraus. Siehe hier.

Die Docker-Container können über diverse Befehle gemanaged werden. Siehe dazu eine kleine Übersicht hier.

WordPress installieren

Wir installieren WordPress mit Hilfe von Docker Compose. Dazu erstellen wir ein template:

Im yml-Script erstellen wir eine WordPress- inkl. DB-Instanz.

WordPress-Instanz

  • Die WordPress-Instanz hat eine Abhängigkeit zur DB.
  • Die WordPress-Files werden unter /var/www/html abgelegt
  • der Host-Port 80 wird zur wordpress-Instanz port 80 weitergeleitet (“80:80”)
  • Die DB ist über Port 3306 anzusprechen (WORDPRESS_DB_HOST: db:3306)
  • Der DB-User ist wordpress (WORDPRESS_DB_USER: wordpress)
  • Das DB-Passowort ist zu setzen: WORDPRESS_DB_PASSWORD: <wordpress_db_password>

DB-Instanz

  • Die DB-Files werden hier abgelegt: db_data:/var/lib/mysql
  • Passort setzen: MYSQL_ROOT_PASSWORD: <mysql root password>
  • Datenbank definieren: MYSQL_DATABASE: wordpress
  • User definieren: MYSQL_USER <wordpress>
  • DB-Passwort setzen: MYSQL_PASSWORD: (wordpress db password)

 

Die letzten beiden Linien restellen lokale Verzeichnisse auf dem Photon-Host. Hier werden die WordPress- und SQL-Files abgespeichert. Diese Files überleben somit, wenn der container zerstört und neu generiert wird.

Die Volumes werden unter

erstellt und bleiben bestehen. Dies solange bis die Volumes mittels

zerstört werden.

WordPress Container starten

Nun kann der Container einfach gestartet werden. Dank Docker Compose braucht man nur noch einen Befehl. Docker Compose erkennt automatisch das YAML im aktuellen Verzeichnis, durchläuft die Konfiguration und startet die Container-Anwendung:

Den Prozess kann man anzeigen lassen

Nun ist über http://<ip>:8080 auf die WordPress-Instanz zugegriffen werden.

WordPress Container mit SSL erweitern

Das so bereitgestellte Container-Image bietet WordPress “out-of-the-Box” über Port 80 an. Port 443 ist nicht aktiviert. Man geht dabei davon aus, dass die Verschlüsselung (https) eine zusätzliche, neue Funktion darstellt und damit über einen weiteren Container abzubilden ist. Dazu kann ein Proxy-Container aufgebaut werden, für den es auch bereits fertige Docker-Images gibt. Architektonisch mag das Sinn machen.

Ich möchte das aber nicht so umsetzen. Ich betreibe bereits einen Proxy-Server und dieser soll auch so weiter beibehalten werden. Ich verzichte also auf einen Proxy-Container und erweitere das WordPress-Image durch die SSL-Funktionalität. Damit das geht, muss ich das docker-compose.yml bzw. die WordPress-Container Beschreibung erweitern.

Als erstes erstelle ich ein zusätzliches File

Dieses Bash-Script soll bei jedem Starten des Containers ausgeführt werden. Mittels diesem Script wird
– SSL nachinstalliert
– Die Default Konfig “000-default.conf” auf dem Apachen entfernt und stattdessen
– eine neue Konfig “apache2-vhosts.conf” installiert.
– Anschliessend wird der Apache neu gestartet.

Damit das Script funktioniert braucht es noch eine Apache-Config. Diese Config wird in den WordPress-Container gemappt und beim Container-Start aktiviert. Damit kann ich von ausserhalb des Containers, die Apache-Config manipulieren:

Nun ist das das docker-compose.yml zu erweitern (siehe die markierten Erweiterungen):

Wie man sieht wird
– das wp-init.sh Skript in den Container gemappt
– Die Apache-Config apache2-vhosts.conf in den Container gemappt.
– Der Container um den Port 8443 erweitert, der Container-Intern auf 443 routet und
– Das Commando “bash -c apache2-custom.sh” bei starten ausgeführt.

Damit startet der Container ab sofort mit aktiviertem SSL und der Apache-Container kann über das File apache2-vhosts.conf konfiguriert werden.

Reverse Proxy

Auf dem Reverse-Proxy wird nun einfach eine Reverse-Rule für den Container eingeführt. Der Reverse-Proxy leitet die HTTPS-Anfragen intern an den Container-Host mit Port 8443 weiter. Diese kann so aussehen:

SMTP auf WordPress-Container

Ich betreibe einen eigenen Mailserver. Ich stellte rasch fest, dass WordPress keine Mails über diesen Server versenden kann. Dies, weil das WordPress-Image einerseits grundsätzlich keinen SMTP-Agent mit dabei hat und andererseits mein Mailserver auch nicht aus dem Container heraus erreichbar war:

Um das Problem zu lösen habe ich mir einfach das Plugin “WP Mail SMTP” installiert. Dieses erweitert WordPress um die Mailfunktion. Das Connectivity-Problem konnte ich mit einer einfach Erweiterung von /etc/hosts lösen:

Man beachte, dass ich die interne IP des Mailservers verwende.

Damit diese Erweiterung auch bei einem neuen Create des Containers übernommen wird, muss wordpress/wp-init.sh noch modifiziert werden:

Links

Alfresco Loging reduzieren: AccessLogValve in server.xml

Meine Alfersco-Installation “flutet” den Server mit sehr grossen “localhost_access_log” Files. Hauptsächlich mit SOLR-Requests dieser Sorte:

Also jedesmal wenn Solr mit Alfresco kommuniziert, wird ein Log-Eintrag erstellt.

“Lösung” nach Holzhacker-Methode:

  • Deaktivieren der Tomcat-Valves

Und deaktivieren bzw auskommentieren des Valves:

 

Subversion auf Ubuntu 16.04 installieren/migrieren

Dieser Beitrag dient mir um meine durchgeführten Schritte später nachvollziehen zu können.

Ich installiere einen Subversion-Server und migriere meine alten Repositories aus Subversion Version 1.6 nach Version 1.9.

Subversion und Apache installieren

Subversion-Gruppe erstellen

Eigener User sowie Apache User der Subversion-Gruppe hinzufügen

Anschliessend aus- und wieder einloggen. Erst dann werden die Änderungen aktiv.

Nun das SVN-Home und Projekt-Verzeichnis anlegen

Nun das Subversion-Repository für das Projekt erstellen

Berechtigungen setzen

WebDAV für Subversion konfigurieren

Config-File /etc/apache2/mods-available/dav_svn.conf anpassen

Apache restarten

User-File für Zugang auf WebDAV erstellen
die -c Option nur beim erstellen verwenden. Bei Modifikationen eines bestehenden Files den Befehl ohne -c ausführen.

Jetzt kann das vorhin erstellte Projekt über WebDAV ausgecheckt werden. Versuchen wir’s:

Migrieren der Repositories des alten Servers in den neuen Server

Dazu exportieren ich das alte Repository in ein Dump-File:

Es besteht nun auch die Möglichkeit aus diesem Dump-File spezielle Verzeichnisse weiter zu exportieren:

Nun kann das Dump-File auf dem neuen Server importiert werden

Achtung: Wenn man ein Subfolder importiert, müssen die Parent-Folder exsistieren, sonst gibts einen Fehler “svnadmin: E160013: Datei nicht gefunden: »/trunk/myproject«
In diesem Falle muss also noch “trunk” als Folder im neuen “myproject” erstellt werden.

svndumpfilter3

Es kann vorkommen, dass das extrahieren von tags mit dem Fehler “svndumpfilter: Ungültiger Quellpfad einer Kopie” fehlschlägt. Das kann offenbar auftreten, wenn man Files/Order im Repository kopiert/verschoben hat. Selbstverständlich habe ich das 🙂
Die Lösung bietet eine Erweiterung von svndumpfilter, svndumpfilter3. Gefunden hier. Dieses Phyton-Script herunterladen und folgendermassen starten:

Die –untangle Option zeigt auf das lokale SVN-Repository Root. Svndumpfliter3 benutzt dieses Repository um die Probleme auzulösen bzw. zu convertieren.

Reverse Proxy

Meinen Subversion-Server betreibe ich hinter einem Apache2 Reverse Proxy. Damit dies auch sauber funktioniert muss der redirect auf dem ReverseProxy angepasst werden. Anosten kann es zu 405-Fehlern kommen “Method not allowed”. Dazu definiere ich im VirtualHost folgende Location:

Referenzen

Let’s encrypt

letsencrypt ist eine Zertifizierungsstelle, welche es erlaubt Zertifikate vollautomatisch und GRATIS zu generieren. Damit entfällt endlich die müsahme manuelle Erstellung von Zertifikaten. Und so geht es:

Ich installiere letsencrypt auf einem Ubuntu 16.04 System mit installiertem Apache:

    1. Letsencrypt installieren
    2. Zertifikat generieren
      Bevors mit dem Zertifikate erstellen losgeht, muss ich zuerst den Apache-Dienst stoppen, weil letsencryp einen standalone Server auf port 80 verwendet:

      Nun generiere ich das Zertifikat mit “certonly”. Damit modifiziert mir letsencrypt nicht das Apache-Config File. Dieses möchte ich selber modifizieren… Für jede Domain kann dieser Befehl wiederholt werden:

      Und voilà:

      Nun den Apache wieder starten:
    3. Das Script erstellt vollautomatisch die benötigten Zertifikate und legt diese ab unter

      Das Zertifikat kann nun am conf-File des Apachen eingetragen werden

    Renewal

    Letsencrypt stellt Zertifikate aus, welche 90 Tage gültig sind. Es wird empfohlen, dass alle 60 Tage ein renewal durchgeführt wird. Dies kann am einfachsten über einen cron-job erledigt werden, der monatlich ausgeführt wird:



StartSSL: Gratis-Zertifikat erstellen

Artikel ist deprecated: Siehe neu Let’s encrypt

———————————————————————

Wenn man seinen eigenen Web-Server betreibt, möchte man meist auch über https (SSL/TLS) gesicherte Verbindungen aufbauen. Es gibt dabei mehrere Varianten, wie man vorgehen kann. Folgendes Tutorial zeigt schön auf, welche es gibt und wann welche Variante Sinn macht:

https://workaround.org/ispmail/wheezy/tlsifying-your-server

Ich habe mich für die dritte Variante “Kostenloses Zertifikat von StartSSL” entschieden. Das Zertifikat kostet nichts und sollte von den meisten Browsern als vertrauenswürdig anerkannt werden: Continue reading

Roundcube Update

Meine Roundcube-Installation wurde mittels iRedMail-Installations Script installiert. Die angegebenen Pfade entsprechen dementsprechend einer iRedMail Default-Installation.

Installations-Verzeichnis

Installations-Verzeichnis:

Soft-Link:

Backup Roundcube-Verzeichnis

Als erstes Backup erstellen

Check ob tar mit korrektem Inhalt erstellt wurde

Backup Mysql-Datenbank

Download Roundcube

Letzte Version von http://www.roundcube.net/download herunterladen und entpacken.

Roundcube aktualisieren

Roundcube liefert ein Script mit, welches das Update durchführt: