blauwe_lucht.docker_webapps

Rôle Ansible pour exécuter plusieurs applications web sur HTTPS sur un seul hôte Docker, signées avec des certificats auto-signés ou de Let's Encrypt.

Ce rôle crée un conteneur de reverse proxy qui exécute nginx et configure nginx pour rediriger les requêtes vers les applications web enregistrées. Sur demande, chaque application web pourra demander un certificat Let's Encrypt afin d'être accessible via HTTPS. Ces certificats seront renouvelés automatiquement grâce à un conteneur certbot. Si Let's Encrypt n'est pas utilisé, des certificats auto-signés pour HTTPS seront générés.

État actuel

Alpha. N'utilisez ce rôle que pour des tests. Aucun test de molécule n'a encore été écrit.

Exigences

Le nœud doit déjà exécuter Docker. Cela peut par exemple être fait avec le rôle geerlingguy.docker.

Variables du rôle

docker_webapps

Configuration des applications web à exécuter. Exemple :

docker_webapps:
  - name: samtris
    docker_image: blauwelucht/samtris:v2.0
    port: 8080
    volumes:
      - /var/log:/var/log

name

Le nom du service Docker Compose qui sera généré et le nom du sous-domaine auquel le reverse proxy répondra.

docker_image

L'image qui sera utilisée pour héberger l'application web. Il est recommandé d'utiliser un tag car ce rôle ne vérifiera pas les mises à jour des images Docker.

port

Le port dans le conteneur où l'application web écoute.

volumes

Les volumes sont optionnels, ils seront copiés tels quels dans le docker-compose.yml généré.

docker_webapps_use_lets_encrypt

Réglez use_lets_encrypt sur true uniquement lorsque l'hôte Docker peut être atteint à partir d'internet. Cela est nécessaire pour que Let's Encrypt puisse vérifier une demande de certificat. Lorsque use_lets_encrypt est faux, un certificat auto-signé sera utilisé.

docker_webapps_domain_name

Le nom de domaine auquel tous les sous-domaines appartiennent.

docker_webapps_email_address

docker_webapps_organization_name

docker_webapps_country_name

L'adresse e-mail, l'organisation et le pays utilisés pour demander des certificats auto-signés et Let's Encrypt.

docker_webapps_docker_compose_project

Le nom du projet pour Docker Compose. N'a besoin d'être remplacé que s'il existe déjà un projet Docker Compose avec le même nom.

docker_webapps_reverse_proxy_container_name

Le nom du conteneur de reverse proxy. N'a besoin d'être remplacé que s'il existe déjà un conteneur avec ce nom.

docker_webapps_certbot_renew_container_name

Le nom du conteneur certbot pour le renouvellement du certificat. N'a besoin d'être remplacé que s'il existe déjà un conteneur avec ce nom.

docker_webapps_certbot_staging_param

Lors des essais, réglez docker_webapps_certbot_staging_param sur "--staging" afin de ne pas dépasser les limites de tarif de Let's Encrypt.

Dépendances

Aucune

Exemple de Playbook

- hosts: servers
  roles:
  - name: blauwe_lucht/docker_webapps
    vars:
      docker_webapps:
      - name: samtris
        docker_image: blauwelucht/samtris:v2.0
        port: 8080
      docker_webapps_use_lets_encrypt: true
      docker_webapps_domain_name: example.com
      docker_webapps_email_address: [email protected]
      docker_webapps_organization_name: ACME
      docker_webapps_country_name: NL

Remarques

Assurez-vous que le FQDN <site.domain> est résolu vers votre serveur. Le FQDN est utilisé par le reverse proxy pour diriger les requêtes vers la bonne application web.
Pour chaque application web, nginx écoute, un nom de site supplémentaire est enregistré afin de pouvoir tester vos scripts Ansible sur un serveur de test : <site>-tst.<domain>.
Le meilleur moyen de gérer les mises à jour des conteneurs d'applications web est d'utiliser des tags dans les noms d'images. En mettant à jour le tag dans la variable de configuration docker_webapps, le changement sera détecté et les nouvelles images seront téléchargées et utilisées pour remplacer le conteneur existant.
Pour supprimer/rafraîchir un certificat Let's Encrypt, exécutez certbot delete --cert-name <fqdn> dans le conteneur certbot, sinon certaines informations resteront et vous recevrez de nouveaux certificats avec un préfixe -0001 qui ne seront pas trouvés par nginx. IMPORTANT : ne supprimez/rafraîchissez qu'un seul certificat à la fois, sinon nginx ne parviendra pas à démarrer car un des sites n'a pas de certificat SSL alors que la configuration en spécifie un. (Je n'ai pas encore trouvé de solution à ce problème).
Lors de l'utilisation de certificats non Let's Encrypt, les applications web peuvent toujours être accessibles via HTTPS, mais vous recevrez un avertissement dans votre navigateur indiquant que le certificat est auto-signé. Pour ces applications web, vous pouvez ignorer ces avertissements en toute sécurité.