blauwe_lucht.docker_webapps

Descripción general Versiones Perspectivas

blauwe_lucht.docker_webapps

Rol de Ansible para ejecutar múltiples aplicaciones web en HTTPS en un único host de Docker, firmadas con certificados autofirmados o de Let's Encrypt.

Esta rol crea un contenedor de proxy inverso que ejecuta nginx y configura nginx para redirigir solicitudes a las aplicaciones web registradas. Si se solicita, cada aplicación web solicitará un certificado de Let's Encrypt para que se pueda acceder a ellas a través de HTTPS. Estos certificados se renovarán automáticamente a través de un contenedor certbot. Si no se utiliza Let's Encrypt, se generarán certificados autofirmados para HTTPS.

Estado actual

Alpha. Solo utilice esta rol para probarla. Aún no se han escrito pruebas de molecule.

Requisitos

El nodo ya debe estar ejecutando Docker. Esto se puede hacer, por ejemplo, con la rol geerlingguy.docker.

Variables de la Rol

docker_webapps

Configuración de las aplicaciones web a ejecutar. Ejemplo:

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

name

Tanto el nombre del servicio de Docker Compose que se generará como el nombre del subdominio al que el proxy inverso escuchará.

docker_image

La imagen que se utilizará para alojar la aplicación web. Se recomienda usar una etiqueta, ya que esta rol no verificará si hay imágenes de Docker actualizadas.

port

El puerto en el contenedor donde la aplicación web está escuchando.

volumes

Los volúmenes son opcionales, se copiarán tal cual en el archivo docker-compose.yml generado.

docker_webapps_use_lets_encrypt

Establezca use_lets_encrypt solo en verdadero cuando el host de Docker pueda ser alcanzado desde internet. Esto es necesario para que Let's Encrypt verifique una solicitud de certificado. Cuando use_lets_encrypt es falso, se utilizará un certificado autofirmado.

docker_webapps_domain_name

El nombre de dominio donde todos los subdominios son parte de.

docker_webapps_email_address

docker_webapps_organization_name

docker_webapps_country_name

La dirección de correo electrónico, organización y país utilizados para solicitar tanto certificados autofirmados como de Let's Encrypt.

docker_webapps_docker_compose_project

El nombre del proyecto para Docker Compose. Solo necesita ser sobrescrito cuando ya haya un proyecto de Docker Compose con el mismo nombre.

docker_webapps_reverse_proxy_container_name

El nombre del contenedor de proxy inverso. Solo necesita ser sobrescrito cuando ya haya un contenedor con ese nombre.

docker_webapps_certbot_renew_container_name

El nombre del contenedor certbot para la renovación de certificados. Solo necesita ser sobrescrito cuando ya haya un contenedor con ese nombre.

docker_webapps_certbot_staging_param

Al experimentar, establezca docker_webapps_certbot_staging_param en "--staging" para no alcanzar los límites de tasa de Let's Encrypt.

Dependencias

Ninguna

Ejemplo 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

Notas

Asegúrese de que el FQDN <site.domain> se resuelva a su servidor. El FQDN es utilizado por el proxy inverso para enrutar solicitudes a la aplicación web correcta.
Para cada aplicación web, nginx escucha un nombre de sitio adicional para hacer posible probar sus scripts de Ansible en un servidor de prueba: <site>-tst.<domain>.
La mejor manera de manejar actualizaciones a los contenedores de aplicaciones web es usar etiquetas en los nombres de las imágenes. Al actualizar la etiqueta en la variable de configuración docker_webapps, se detectará el cambio y las nuevas imágenes se descargarán y se usarán para reemplazar el contenedor existente.
Para eliminar/actualizar un certificado de Let's Encrypt, ejecute certbot delete --cert-name <fqdn> en el contenedor certbot, de lo contrario, parte del historial permanecerá y obtendrá nuevos certificados con un prefijo -0001 que no serán encontrados por nginx. IMPORTANTE: solo elimine/actualice un certificado a la vez, de lo contrario, nginx no podrá iniciarse porque uno de los sitios tiene un certificado SSL faltante mientras que la configuración aún especifica uno. (Aún no he encontrado una manera de solucionar esto).
Cuando no se utilizan certificados de Let's Encrypt, las aplicaciones web aún se pueden acceder a través de HTTPS, pero recibirá una advertencia en su navegador de que el certificado es autofirmado. Para esas aplicaciones web, puede ignorar esas advertencias de manera segura.