Archiv der Kategorie: Allgemein

ownCloud – „from source“ in Docker Container [owncloud] [docker]

Genesis Mining

Die eigene Cloud-Lösung dank ownCloud ist eine tolle Sache. Ich habe ja so einige Server. Sowohl im „Managed Service“, also bei denen sich professionelle Serveradmins um das System kümmern als auch einige andere, bei denen ich mich selbst drum kümmere (eigene Systeme wie bspw. ownCloud, bei denen es sich aus kostengründen so ergibt).

Ich betreibe unter anderem eine ownCloud Instanz auf einem der Server die ich halt selbst verwalte. Und noch andere Systeme. Was immer wieder schwierig für mich ist: Zugriffsrechte. Ich habe mich damit anscheinend noch nicht ausgiebig genug bei Linux beschäftigt. Daher hat es eine ganze Weile gedauert, bis die ownCloud wie gewünscht lief.

Nun habe ich etwas Sorge gehabt, als ein anderes System auf dem Server PHP 5.6 brauchte. Da ich nicht weiß, wie ich mehrere PHP Versionen parallel betreibe, habe ich einfach von PHP 5.4 auf PHP 5.6 umgestellt. Eben mit der Sorge, dass dadurch andere Systeme ggf. Schwierigkeiten bekommen.

Um solche Sorgen nicht mehr zu haben, möchte ich schon seit langem alle Anwendungen dieses Servers in eigene Docker Container umziehen. Mit Docker habe ich mich hier auf dem Blog schon beschäftigt. Ich finde die Idee von Docker genial und habe ja auch seid kurzem meine eigene private Docker Registry.

Docker Container einrichten

Bevor ich groß mit Dateien hantieren wollte, habe ich die Docker Container aufgesetzt. Dazu schreibe ich mit immer ein anwendung.sh-Bash-Script, also in dem Fall owncloud.sh

Nun vergesse ich nie wieder wie ich diese container konfiguriert habe. Kommt eine neue Version von ownCloud, kann ich einfach oben den Image-Namen ändern und das Script erneut ausführen. Praktisch!

Ich habe das Script ausgeführt und auf meine neue Cloud per http://host:81 zugegriffen. Ich wollte sehen, ob alles funktioniert. Der Installations-Wizard war zu sehen, demnach: Läuft.

Datenbank einspielen

Ein spannender Punkt. Denn ich habe ja, wie oben im Script zu erkennen, einen Docker Container für MySQL eingerichtet. Wie bekomme ich da jetzt also die Datenbank rein?

Ich habe mich dazu entschieden, ein SQL-File zu exportieren und dieses in das Docker Volume zu schieben sowie die Berechtigungen richtig zu setzen.

Nun konnte der Datenbankimport stattfinden, vorher muss natürlich erst eine neue DB angelegt werden. Beides geht in jeweils einem einzigen Aufruf:

Konfiguration übernehmen

Nachdem nun die Datenbank steht, muss natürlich die neue ownCloud-Installation mit der Datenbank verbunden werden bzw. generell die ganze Konfiguration übertragen werden.

Damit allerdings nicht getan, die Konfiguration muss geprüft werden. Denn es hat sich zumindest der Datenbank-Host geändert. Die Datenbank findet man nun nicht mehr auf „localhost“, sondern über den Host „mysql“ (siehe Docker Link im Installationsscript).

Daten übernehmen

Tja und als letzter Schritt fehlt nur noch, die Daten zu übernehmen.

Nun ist meine neue ownCloud-Installation Testbereit.

ownCloud umschalten

Nach den Tests kann ich den vHost im Apache des Server einfach als Redirect auf den Port 81 (siehe Port-Mapping im Docker-Script) konfigurieren. Dann ist automatisch meine schöne URL nutzbar, der Apache fungiert in dem Moment einfach als Proxy.

In meinem Fall ist wie gesagt ein Apache im Einsatz, das ganze lässt sich natürlich mit nginx auch realisieren. Diesen habe ich allerdings noch nicht oft eingesetzt und habe hier also zu einem vertrauten Mittel gegriffen.

Und schon kann ich meine Cloud über den Browser aufrufen und bedienen.

docker login: x509: certificate signed by unknown authority [Docker] [Registry]

bitconnect

Ich wollte mich per docker login auf meiner privaten Docker Container Registry einloggen. Doch ich erhielt folgende Meldung:

Gestern hatte ich auf einem anderen Server das selbe Problem und habe aber vergessen, was ich getan habe um es zu lösen. Damit ich es nicht vergesse und ich dir vielleicht auf diesem Notizzettel auch helfen kann, schreibe ich also fix einen Blogbeitrag.

Meine Registry ist unter lw-scm.de:5500 erreichbar. Wenn deine Registry auf einer anderen URL verfügbar ist, musst du im folgenden Code also deine Adresse eintragen.

Docker kennt die CA nicht

Grund für die Meldung ist, dass das Docker-System den Zertifikatsaussteller nicht kennt / verifizieren kann. Daher musst du das öffentliche Zertifikat des jeweiligen CA (Certificate Authority) für den Docker-Client ablegen.

In meinem Fall handelt es sich um ein Login SSL Zertifikat von COMODO, also ein „echtes“ und ich habe es vor kurzem gekauft. Beim Kauf des Zertifikates habe ich eine .ca-bundle-Datei bekommen. Diese Datei muss ich nun in den passenden Docker-Zertifikats-Ordner legen, in meinem Fall /etc/docker/certs.d/lw-scm.de:5500. Ich habe sie bei mir in ca.crt umbenannt.

So nun existiert der Ordner und jetzt kann ich die Datei kopieren.

Nun kann direkt der Login erneut ausgeführt werden.

Ich will mich dennoch umschauen warum die CA nicht akzeptiert wird, denn COMODO ist eigentlich ziemlich verbreitet.

GitLab CI Runner im Docker Container [GitLab Runner] [Docker] [PHP] [NodeJS] [LESSCSS]

Genesis Mining

Ich habe ja bereits berichtet, dass ich meine GitLab-Installation in einen Docker-Container verfrachtet habe. Nun möchte ich passend dazu natürlich auch meine GitLab-Runner in Docker-Containern laufen lassen. Was mir hierbei gut gefällt: Das restliche System ist von den für Build-Prozesse notwendigen Tools nicht zugemüllt.

GitLab Runner im Docker-Container laufen lassen

Wie in der originalen Anleitung zu lesen, ist es gar nicht schwer, einen GitLab-Runner im Docker-Container auszuführen:

Doch ich will natürlich noch einige zusätzliche Tools für PHP-Entwicklung in den Runner einbinden.

Ein PHP-Optimierter GitLab-Runner

Das tolle an Docker: Auf bestehenden Images aufbauen und diese erweitern. Mit einem Dockerfile.

Ich habe also mein eigenes Dockerfile geschrieben:

Kurz erklärt: Was hier passiert ist quasi das originale Docker-Kommando (siehe ganz oben). Es wird also das Docker-Image „gitlab/gitlab-runner:latest“ geladen. Dann werden zusätzliche Kommandos ausgeführt.

  1. Die Liste der verfügbaren Programme aktualisieren
  2. Neue Pakete installieren: php5, php5-pear, zip, curl, php5-mcrypt, NodeJS, npm und ncftp
  3. Das mcrypt-PHP-Modul aktivieren
  4. nochmals vergügbare Programme aktualisieren
  5. Neue Pakete installieren: php5-xsl
  6. NodeJS passend verlinken
  7. Den LessCSS-Precompiler über NodeJS installieren
  8. phpmd installieren
  9. phploc installieren
  10. Composer installieren
  11. phpcpd installieren
  12. phpdox installieren

Mit dieser Palette an Tools kann ich meine Projekte optimal bauen. Jetzt muss ich das Docker-Image nur noch erstellen und ausführen lassen:

Nun läuft mein PHP-Optimierter GitLab-Runner. Jetzt muss er nur noch registriert werden, dazu führt man folgendes Kommando aus und befolgt die Anweisungen:

Meinen Runner nutzen

Wenn Du dich um das Dockerfile nicht kümmern möchtest, aber meine Tool-Palette cool findet, kannst Du genau diesen Runner auf jedem Server installieren, dazu nutzt du statt dem obigen docker-build Kommande folgendes:

Nun zieht dein Docker sich das Dockerfile aus meinem öffentlichen Repository und baut das Docker-Image.

GitLab – Update 8.0.5 auf 8.4.4 im Docker-Container [GitLab 8.0.5] [GitLab 8.4.4] [Docker]

bitconnect

Heute habe ich meine GitLab-Instanz von 8.0.5 auf 8.4.4 angehoben, dies wird mir viele Vorteile bringen, die Entwicklung ist ja mächtig vorangegangen.

Etwas bammel hatte ich schon, denn dieses Update ist das erste Update von GitLab, welches ich über den Austausch des GitLab-Container machen werde. Vorher hatte ich GitLab ja direkt aus den Sourcen installiert und bin dann ende letzten Jahres von GitLab Source-Installation auf GitLab Docker Container gewechselt.

Stoppen des aktuellen GitLab Docker Container

Zuersteinmal habe ich die GitLab-Instanz gestoppt:

Weil ich nicht wusste was nun geschehen würde habe ich ein Backup gemacht:

GitLab Docker Container aktualisieren

Aktualisieren? Pfft. Nicht mit mir. Ich kille einfach den alten Docker-Container und tausche ihn aus:

Nun ließ sich der GitLab Container aber nicht starten. Mir rutschte das Herz in die Hose.

Etwas googlen und überlegen später kam mir die Idee, dass es vielleicht im Host-Update lag. Also habe ich kurzerhand die beiden anderen Container auch neugestartet und anschließend dann den zweiten Versuch für den GitLab Container durchgeführt:

Und voila: GitLab migrierte die Daten. Nachverfolgen kann man den Fortschritt über die Log-Ausgaben des Container:

Fazit nach dem GitLab Docker Container Update

Mich für das Hosting von GitLab in einem Docker-Container zu entscheiden ist echt Gold wert! So einfach war noch kein Update von GitLab für mich.

Außerdem muss ich m ich nun um keine Abhängigkeiten von GitLab mehr kümmern, dass macht ja der Cotnainer himself 🙂

WordPress Admin Bar nicht sichtbar [WordPress 4.3] [Benutzerrollen] [WooCommerce]

Genesis Mining

Neulich hatte ich folgendes Phänomen: Für Benutzer mit der Rolle „Redaktuer (engl. Editor)“ wurde die Admin-Bar nicht angezeigt. Natürlich war in dem betreffenden Profil der Haken gesetzt, sodass die Admin Bar hätte sichtbar sein sollen. Die Suche ist theoretisch einfach: Deaktiviere alle Plugin und wechsle auf das Standard-Theme, dann schau ob es klappt. Wenn es klappt, einfach nach und nach alle Plugins wieder aktivieren und schauen, welches Plugin dafür sorgt, dass die WordPress Admin Bar verschwindet. Darauf hatte ich keine Lust!

Das Projekt ist ein gerade entstehender Online-Shop. Es ist ein gekauftes Theme im Einsatz, welches optimal für WooCommerce vorbereitet ist. Folgende Plugins sind aktiv:

  • Admin Menu Editor Pro
  • Antispam Bee
  • Benutzerwechsel (engl. User Switching)
  • Contact Form 7
  • Disable All WordPress Updates
  • Envato WordPress Toolkit
  • Imsanity
  • Manual Image Crop
  • Passwortgeschützt (engl. Password Protected)
  • Responsive Lightbox
  • Revolution Slider
  • Simple Custom CSS
  • User Role Editor
  • WooCommerce
  • WooCommerce Header Category Image
  • Wordfence Security
  • WP Sanitize file name Plus
  • WPBakery Visual Composer
  • YITH WooCommerce Wishlist

Dabei kann ich mir vorstellen, dass in dieses Problem nur wenige dieser Plugins reinspielen könnten. Da ich aber nicht viel Zeit hatte und erstmal mehr ein Workaround her sollte, als eine super Zukunftssichere Lösung, habe ich folgendes Unternommen: Ich habe ans Ende der functions.php folgende Zeile Quellcode angefügt:

Die Änderung ist absolut unkritisch. Und schon klappt es. Natürlich nur bis zum nächsten Update des Theme. Aber das ist erstmal eine schnelle Lösung. Und zeigt mir, dass hier definitiv noch ein anderes Plugin zu Gange ist, welches über eben den selben Filter irgendwann versucht, die Admin-Bar abzuschalten (Vermutung).