Kontakt
Einfach Suchbegriff eingeben und Enter drücken
Abbrechen

Neos auf dem proServer in 5 Minuten mit Ansible

Neos auf dem proServer in 5 Minuten mit Ansible

tl;dr: Um euren proServer ganz einfach mit Ansible zu konfigurieren, klont ihr euch das Template Repository, kopiert die passende Datei von host_vars_examples nach host_vars und passt diese und die inventory Datei für euren proServer an. Danach startet ihr die Provisionierung mit ansible-playbook. Das Playbook schreibt alle Konfigurationsparameter in eine .env Datei, die ihr dann in eurem Neos Projekt verwenden könnt.

Hosting für Neos CMS-Projekte

Auf Basis des modernen Neos CMS lassen sich auch anspruchsvolle und komplexe Projekte im Web umsetzen.

Dabei ist Neos selbst aber nicht weniger anspruchsvoll, wenn es um die richtige Hostingumgebung geht. Das sind einfache Vorraussetzungen, wie eine gleiche und moderne PHP Version für CLI und PHP-FPM oder die passende Version von MariaDB als Datenbank Backend. Wer in größeren Projekten die Features von Neos voll ausnutzen möchte benötigt daneben Serverdienste, welche nicht zum Standardportfolio eines normalen Hosters gehören: Redis als schnelles Cache Backend, Elasticsearch zur Verwaltung und Suche von großen Contentmengen oder Supervisor um Hintergrundprozesse zu orchestrieren, um ein paar zu nennen.

Mit dem punkt.de proServer bieten wir eine Hostingumgebung, welche optimal auf die Anforderungen von Neos abgestimmt ist und auch für zukünftige Anforderungen stetig angepasst wird.

"Infrastructure as Code" mit Ansible

Ansible ist ein Automatisierungswerkzeug zur Orchestrierung und Konfiguration von Servern. Von einer Control-Node aus, verbindet sich Ansible per SSH auf die Zielserver und führt die zur Konfiguration nötigen Kommandos durch. Dafür ist auf dem Zielserver keine zusätzliche Software nötig. Die Ansible Konfiguration besteht hauptsächlich aus einfach zu lesenden Dateien im YAML Format, mit denen die auszuführenden Aufgaben definiert werden.

Die Vorteile von einer Konfiguration der Server mit Ansible-Code gegenüber einer händischen Konfiguration liegen auf der Hand. Alle Konfigurationsschritte sind nachvollziehbar und können jederzeit verwendet werden um neue Serverinstanzen identisch zu konfigurieren. Natürlich ist der Ansible Code genauso wie der Code des Projektes versionierbar, so passt die Infrastruktur immer genau zum Projekt.
 

Was ist der proServer

Mit dem proServer haben wir eine Hostinglösung geschaffen, die alles mitbringt was ein anspruchsvolles Web-Projekt benötigt. Konzeptioniert von unseren Entwicklern und erprobt in unserem Projektgeschäft, soll der proServer in der täglichen Arbeit nie im Weg stehen. Er bringt eine optimierte Standardkonfiguration mit, welche aber komplett an die eigenen Bedürfnisse angepasst werden können. Gleichzeitig wird die installierte Software regelmäßig und automatisch aktualisiert.

Technisch basiert der proServer auf FreeBSD und der Containerlösung Jails. Jedes Jail bietet die Umgebung für ein komplettes Projekt oder nur einzelne Dienste. Mit unserer Agenturlösung können proServer-Instanzen auf Knopfdruck erstellt werden.

Unsere Ansible Rollen für den punkt.de proServer

Und natürlich bietet sich es an, den Ansible Code so zu strukturieren und zu modularisieren, dass er für neue Projekte wiederverwendbar ist. Genau das haben wir getan und die Ansible Rollen, mit denen wir unsere Instanzen konfigurieren als Open-Source Projekte auf Github gestellt. So wollen wir es unseren proServer Kunden noch einfacher machen, ihre Neos Projekte ohne viel Aufwand produktiv zu nehmen.

Jede Rolle kapselt dabei eine Rolle, beziehungsweise einen Serverdienst, den es zu konfigurieren gilt. Neben den Standarddiensten wie NGINX, php-fpm oder Datenbank, finden sich hier auch Konfigurationen die sich in unserem Projektalltag als sehr nützlich heraus gestellt haben, wie beispielsweise das Anzeigen der konfigurierten Domains beim Login oder ein oAuth2 Proxy zum Schutz für Staging Instanzen.

Einen proServer mit Ansible konfigurieren

Um einen proServer mit Ansible zu provisionieren sind die folgenden vier Schritte nötig.

1. Ansible installieren

Zunächst muss Ansible auf dem lokalen System installiert sein. Im Ansible Installation Guide finden sich dazu diverse Möglichkeiten für Unixoide Systeme. Unter Windows kann Ansible im Windows 10 Subsystem für Linux laufen.

2. Projekte und Submodule von GitHub klonen

Das GitHub Projekt proServer-Ansible-Template fasst die generischen Rollen und die Konfiguration für das konkrete Projekt zusammen. Das Projekt und die verwendeten Rollen werden mit diesem Befehl geklont:

git clone --recurse-submodules https://github.com/punktDe/proserver-ansible-template.git

3. Ansible-Konfiguration für dein Projekt anpassen

Als nächstes muss konfiguriert werden, welcher proServer mit welchen Rollen und Services konfiguriert werden soll. Dafür sind Dateien an zwei Stellen anzupassen.

host_vars

Im Ordner host_vars benötigen wir für jeden Host in unserem Inventory eine Datei, welche die spezifischen  Parameter dieses Hosts beschreibt. 

Unter host_vars_examples befinden sich Beispiele einer solchen Datei. Für einen produktiven proServer, auf dem eine Neos Instanz deployed werden soll, kopieren wir einfach die Datei host_vars_examples/neos/production.yaml nach host_vars/production.yaml.

In der neu erstellten Datei muss zunächst zumindest überall die 0000 durch die eigene proServer Nummer ersetzt werden. Danach können die Konfigurationen für die verschiedenen Dienste nach eigenen Vorlieben angepasst werden.

inventory.ini

Das Ansible Inventar, welches in der inventory.ini definiert wird, enthält eine Liste der Hosts (proServer) und die Gruppen denen diese Hosts zugeordnet werden sollen. Diese Gruppen werden später von Ansible verwendet, um die nötigen Rollen zuzuordnen.

Hier ist zunächst einer der Host Definitionen einzukommentieren und die vpro-Nummer zu ersetzen. Danach muss der Server noch der richtigen Gruppen zugeordnet werden. Für eine produktive Neos Instanz beispielsweise, wird die Zeile production unter dem Key Neos einkommentiert.

host_vars Templates

Wir haben Beispiel-Templates für die host_vars Dateien in zwei Varianten für Neos und TYPO3 erstellt. Templates für weitere Dienste werden folgen. 
Die production.yaml enthält die Parameter für den Stack aus NGINX mit let's encrypt SSL Zertifikat, PHP, und wahlweise mariaDB oder mySQL als Datenbank Backend. Zusätzlich wird die Konfiguration für den Mailversand und den Clusternamen für die optionale Verwendung von Elasticsearch spezifiziert.
 

Die staging.yaml bringt zusätzlich zwei nützliche Services für Staging Umgebungen mit. 
Der oAuth2 Proxy schützt die noch nicht produktive Seite vor unberechtigten Zugriffen. Als Backend für die Authentifizierung haben wir gitlab vorkonfiguriert, so kann man sich bequem über gitlab authentifizieren. Natürlich lassen sich auch andere Backends verwenden, hier finden sich dazu Beispiele.

Mailhog ist der zweite, nur für staging konfigurierte Dienst. Mit Mailhog werden automatisch alle Mails, welche aus dem CMS versendet werden, abgefangen und können in einer Weboberfläche angezeigt werden. Eine API erlaubt den Zugriff auf das Postfach - ideal beispielsweise für automatisiertes Frontend Testing mit codeception.
 

4. Ansible starten

Ansible ist nun für den ersten Lauf konfiguriert und kann gestartet werden. Der folgende Aufruf provisioniert beispielsweise alle Server der Produktionsumgebung.

ansible-playbook --ssh-extra-args=-oProxyJump=jumping@ssh-jumphost.karlsruhe.punkt.de --limit=production playbook.yaml

Damit ist der Server komplett für eine Neos Instanz konfiguriert. Das Neos Projekt wird dabei im Pfad /var/www/neos/current erwartet. Ein Pfad, welcher zu einem mit Deployer übertragenen Projekt passt. Eine Beispielkonfiguration für ein Deployment von Neos mit Deployer befindet sich bereits in unserem Template Projekt.

Bonus: Neos automatisch mit .env konfigurieren

Die Neos Ansible Rolle kümmert sich nicht nur darum, den NGINX passend für Neos zu konfigurieren. Sie schreibt auch alle wichtigen Konfigurationsvariablen wie die Zugangsdaten zur Datenbank oder Elasticsearch in eine .env Datei unter /usr/local/etc/neos.env. Mit dem .env Connector kann Neos diese Parameter auslesen. 

Das hat mehrere Vorteile. Es müssen keine Passwörter mehr ins git repository eingecheckt werden. Eine Unterscheidung zwischen Staging und Production in den Konfigurationen wird ebenso unnötig. Werden Dienste wie Datenbankserver oder Elasticsearch auf andere Hosts verteilt, passt sich die Konfiguration automatisch an ohne dass der Projektcode angefasst werden muss.

Mit den folgenden Befehlen wird der dotenv-connector per composer installiert und konfiguriert:

composer require helhum/dotenv-connector
composer config extra.helhum/dotenv-connector.env-file /usr/local/etc/neos.env

Die nebenstehende Konfiguration sorgt dann dafür, dass die Parameter aus dem Environment gelesen werden.

Unser Template Projekt beinhaltet schon jetzt die nötigen Rollen und Beispiele für die automatische Konfiguration von Neos- und TYPO3 Environments. Rollen für weitere Dienste und Applikationen sollen folgen. 

Neos bezieht die environmentspezifischen Konfigurationsdateien direkt aus der .env Datei.

Neos:
  Flow:
    persistence:
      backendOptions:
        driver: "%env:DB_DRIVER%"
        dbname: "%env:DB_NAME%"
        user: "%env:DB_USER%"
        password: "%env:DB_PASS%"
        host: "%env:DB_HOST%"
        charset: "%env:DB_CHARSET%"

  SwiftMailer:
    transport:
      type: Swift_SmtpTransport
      options:
        host: "%env:APP_SMTP_HOST%"
        port: "%env:APP_SMTP_PORT%"

Configuration/Settings.yaml für Neos

Falls ihr Fragen zum Projekt habt oder Erweiterungen benötigt, freuen wir uns sehr über jedes Feedback; als Kommentare hier im Blog, als Pull-Requests oder Issues auf GitHub oder direkt im Neos Slack Channel #proserver.

Autor: Daniel Lienert

Kommentare

Noch sind keine Kommentare eingegangen

Weitere Beiträge

13. September 2019

Kickoff zur Zukunft der punkt.de

Der 9. September war ein besonderer Tag für die punkt.de. Nach lang andauernden Vorarbeiten konnte ein … mehr

3. September 2019

#cccamp19 - 5 Tage Camping & Konferenz

Vom 21. bis 25. August 2019 fand das 6. Chaos Communication Camp im Ziegeleipark Mildenberg bei Berlin … mehr