Ansible Nginx Passenger Rolle

Diese Rolle installiert den Nginx-Server zusammen mit Phusion Passenger-Bindungen für Node, Python oder Ruby. Sie kann auch eine Webseite für eine bestimmte Domain einrichten und konfigurieren.

Anforderungen

Diese Rolle nutzt die ACLs (Access Control Lists) des Linux-Dateisystems und eine Gruppe namens "web-admin", um den Zugriff auf Konfigurationsverzeichnisse zu gewähren. Sie können diese Schritte entweder manuell konfigurieren oder die Rolle bbatsche.Base installieren.

Rollenvariablen

• env_name — Ob dieser Server in einer "Entwicklungs-", "Produktions-" oder anderen Umgebung ist. Standard ist "dev".
• http_root — Wo die Verzeichnisse für die Webseite erstellt werden sollen. Standard ist "/srv/http".
• public_directory — Öffentlich sichtbares Verzeichnis für die Webseite, z. B. "public" oder "htdocs". Standard ist "public".
• max_upload_size — Maximale Upload-Größe in MB. Standard ist "10".
• domain — Domainname für die zu erstellende Webseite. Standardmäßig undefiniert.
• content_security_policy — Inhalts-Sicherheitsrichtlinie zur Domain, formatiert als Dictionary von Listen oder Booleschen Werten. Geeignete Werte erhalten automatisch einfache Anführungszeichen ('). Standard: siehe defaults/main.yml.
• nginx_configs — Zusätzliche Konfigurationsdateien, die am Ende des server-Blocks der Domain hinzugefügt werden sollen. Diese Dateien sollten nach /etc/nginx/conf.d kopiert werden. Fügen Sie Konfigurationen für Ihren spezifischen Anwendungstyp hier hinzu. Standard ist ein leeres Array.
• passenger_app — Ist die aktuelle Domain eine Passenger-App (d. h. Node, Ruby, Python)? Nützlich, wenn die App nach der Aktualisierung der Konfigurationen neu gestartet werden muss. Standard ist nein.
• copy_index — Kopiere eine index.html-Vorlage zur Webseite. Standard ist nein.
• use_ssl — Ob Inhalte über SSL (eigentlich TLS) bereitgestellt werden sollen. Standard ist nein.
• use_letsencrypt — Ob Let's Encrypt verwendet werden soll, um ein Zertifikat für die Webseite zu erstellen. Andernfalls wird ein serverweites selbstsigniertes Zertifikat verwendet. Standard ist nein.
• privatekey_bits — Anzahl der Bits, die bei der Erstellung eines selbstsignierten privaten Schlüssels verwendet werden. Standard ist 4096.
• dhparam_bits — Anzahl der Bits, die bei der Erstellung eines statischen DH-Param-Zertifikats verwendet werden. Standard ist 2048. Ein viel höherer Wert kann sehr zeitaufwendig sein.
• cert_valid_days — Anzahl der Tage, für die das selbstsignierte Zertifikat gültig ist. Standard ist 3650 (~1 Jahr).
• email_address — E-Mail-Adresse, die für das selbstsignierte Zertifikat und Let's Encrypt verwendet wird. Standardmäßig undefiniert.
• country_name — Zweibuchstaben-Länderkürzel, das bei der Erstellung des selbstsignierten Zertifikats verwendet wird. Standardmäßig undefiniert.
• state_name — Bundesland- oder Provinzname, der bei der Erstellung des selbstsignierten Zertifikats verwendet wird. Standardmäßig undefiniert.
• locality_name — Stadt- oder Ortsname, der bei der Erstellung des selbstsignierten Zertifikats verwendet wird. Standardmäßig undefiniert.
• org_name — Organisationsname, der bei der Erstellung des selbstsignierten Zertifikats verwendet wird. Standardmäßig undefiniert.
• h5bp_commit — Git-Hash oder Versionsnummer, die für das Abrufen von Dateien aus HTML5 Boilerplate Server Configs verwendet wird. Standard ist "3.1.0".
• setuptools_version — Version von setuptools, die über Pip installiert werden soll. Standard ist 40.6.2.

SSL & Let's Encrypt

Let's Encrypt erfordert, dass Ihr Webserver extern zugänglich ist. Daher sollten Sie es nicht verwenden, wenn Sie Entwicklunch-Webseiten in Vagrant oder Docker generieren. Darüber hinaus müssen Sie sicherstellen, dass Ihre DNS richtig konfiguriert ist, bevor Sie Ihr Zertifikat erstellen. Nach Abschluss wird ein vollständig unterstütztes und signiertes Zertifikat für Ihre Domain ausgestellt, sowie ein Cron-Job, um sicherzustellen, dass es in Zukunft weiterhin erneuert wird. Der Server und das Zertifikat wurden für bestmögliche Sicherheit optimiert und erhielten ab Oktober 2017 die "A+"-Bewertung von SSL Labs.

Beispiel-Playbook

- hosts: servers
  roles:
     - { role: bbatsche.Nginx, domain: my-test-domain.test }

Lizenz

MIT

Tests

Diese Rolle enthält eine Sammlung von Tests, um jede Aufgabe einzeln oder als Ganzes zu testen. Um diese Tests auszuführen, müssen Sie zuerst Vagrant und VirtualBox installiert haben. Die Testdateien sind mit Serverspec geschrieben, daher benötigen Sie Ruby und Bundler.

Um die gesamte Testreihe auszuführen:

$ gem install bundler
$ bundle install
$ rake

Die Testsuite wird auf Ubuntu Trusty Tahr (14.04), Xenial Xerus (16.04) und Bionic Beaver (18.04) ausgerichtet.

Um die verfügbaren Rake-Tasks (und Tests) anzuzeigen:

$ rake -T

Diese Tests sind nicht dazu gedacht, die Idempotenz zu testen. Sie dienen dazu, zu überprüfen, ob die angegebenen Aufgaben ihre erwarteten Schritte ausführen. Die Idempotenz wird unabhängig mittels Integrationstests getestet.