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.
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.
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.
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.
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.
Um einen proServer mit Ansible zu provisionieren sind die folgenden vier Schritte nötig.
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.
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.gitAls 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.
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.
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.yamlDamit 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.
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.envDie 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.
