Rôle Ansible Nginx Passenger

Ce rôle installe le serveur Nginx avec les liaisons Phusion Passenger pour servir Node, Python ou Ruby. Il peut aussi configurer un site pour un domaine donné.

Exigences

Ce rôle utilise les ACL du système de fichiers Linux et un groupe appelé "web-admin" pour gérer l'accès aux répertoires de configuration. Vous pouvez configurer ces étapes manuellement ou installer le rôle bbatsche.Base.

Variables du Rôle

• env_name — Indique si le serveur est en "développement", "production" ou un autre type d'environnement. Par défaut : "dev"
• http_root — Emplacement où les répertoires du site doivent être créés. Par défaut : "/srv/http"
• public_directory — Répertoire visible publiquement pour le site, par exemple "public" ou "htdocs". Par défaut : "public"
• max_upload_size — Taille maximale de téléchargement en Mo. Par défaut : "10"
• domain — Nom de domaine pour le site à créer. Non défini par défaut.
• content_security_policy — Politique de sécurité du contenu à ajouter au domaine, formatée sous forme de dictionnaire de listes ou de booléens. Les valeurs appropriées auront automatiquement des quotes simples appliquées. Par défaut : voir defaults/main.yml
• nginx_configs — Fichiers de config supplémentaires à ajouter à la fin du bloc server du domaine. Ces fichiers doivent être copiés dans /etc/nginx/conf.d. Ajoutez les configurations pour votre type de serveur d'application ici. Par défaut : tableau vide.
• passenger_app — Le domaine actuel est-il une application Passenger (c'est-à-dire, Node, Ruby, Python) ? Utile si l'application doit être redémarrée après la mise à jour des configurations. Par défaut : non
• copy_index — Copier un index.html de base sur le site. Par défaut : non.
• use_ssl — Faut-il servir le contenu via SSL (en réalité TLS) ? Par défaut : non.
• use_letsencrypt — Faut-il utiliser Let's Encrypt pour générer un certificat pour un site ? Sinon, un certificat auto-signé sera utilisé. Par défaut : non.
• privatekey_bits — Nombre de bits à utiliser lors de la génération d'une clé privée auto-signée. Par défaut : 4096.
• dhparam_bits — Nombre de bits à utiliser lors de la génération d'un certificat de paramètre DH statique. Par défaut : 2048. Aller beaucoup plus haut peut prendre beaucoup de temps.
• cert_valid_days — Nombre de jours de validité pour le certificat auto-signé. Par défaut : 3650 (~1 an).
• email_address — Adresse email à utiliser pour le certificat auto-signé et Let's Encrypt. Non définie par défaut.
• country_name — Abréviation de deux lettres pour le pays à utiliser lors de la génération du certificat auto-signé. Non définie par défaut.
• state_name — Nom de l'état ou de la province à utiliser lors de la génération du certificat auto-signé. Non défini par défaut.
• locality_name — Nom de la ville ou de la localité à utiliser lors de la génération du certificat auto-signé. Non défini par défaut.
• org_name — Nom de l'organisation à utiliser lors de la génération du certificat auto-signé. Non défini par défaut.
• h5bp_commit — Hash Git ou numéro de version à utiliser pour récupérer des fichiers depuis HTML5 Boilerplate Server Configs. Par défaut : "3.1.0".
• setuptools_version — Version de setuptools à installer via Pip. Par défaut : 40.6.2.

SSL et Let's Encrypt

Let's Encrypt nécessite que votre serveur web soit accessible de l'extérieur, donc vous ne devriez pas l'utiliser pour générer des sites de développement dans Vagrant ou Docker. De plus, vous devez vous assurer que votre DNS est correctement configuré avant de créer votre certificat. Une fois cela fait, un certificat entièrement supporté et signé sera délivré pour votre domaine, ainsi qu'un cron job pour s'assurer qu'il continuera à être renouvelé à l'avenir. Le serveur et le certificat ont été optimisés pour la meilleure sécurité possible, obtenant une note "A+" de SSL Labs depuis octobre 2017.

Exemple de Playbook

- hôtes : serveurs
  rôles :
     - { rôle : bbatsche.Nginx, domaine : my-test-domain.test }

Licence

MIT

Tests

Ce rôle vient avec un ensemble de spécifications pour tester chaque tâche individuellement ou dans son ensemble. Pour exécuter ces tests, vous devez d'abord installer Vagrant et VirtualBox. Les fichiers de spécification sont écrits avec Serverspec, donc vous aurez besoin de Ruby et Bundler.

Pour exécuter l'ensemble des spécifications :

$ gem install bundler
$ bundle install
$ rake

La suite de spécifications ciblera Ubuntu Trusty Tahr (14.04), Xenial Xerus (16.04), et Bionic Beaver (18.04).

Pour voir les tâches rake disponibles (et les spécificités) :

$ rake -T

Ces spécifications ne sont pas destinées à tester l'idempotence. Elles sont destinées à vérifier que les tâches spécifiées effectuent leurs étapes attendues. L'idempotence est testée indépendamment via des tests d'intégration.