Rol de Ansible Nginx Passenger

Este rol instalará el servidor Nginx junto con los enlaces de Phusion Passenger para servir Node, Python o Ruby. También puede configurar un sitio para un dominio dado.

Requisitos

Este rol utiliza ACL de sistema de archivos de Linux y un grupo llamado "web-admin" para otorgar acceso a los directorios de configuración. Puedes configurar estos pasos manualmente o instalar el rol bbatsche.Base.

Variables del Rol

• env_name — Si este servidor está en un entorno de "desarrollo", "producción" u otro tipo. El valor por defecto es "dev".
• http_root — Dónde se deben crear los directorios del sitio. El valor por defecto es "/srv/http".
• public_directory — Directorio visible al público para el sitio, por ejemplo, "public" o "htdocs". El valor por defecto es "public".
• max_upload_size — Tamaño máximo de carga en MB. El valor por defecto es "10".
• domain — Nombre de dominio para crear el sitio. No está definido por defecto.
• content_security_policy — Política de seguridad de contenido para añadir al dominio, formateada como un diccionario de listas o booleanos. Los valores apropiados tendrán automáticamente comillas simples ('). Por defecto: ver defaults/main.yml.
• nginx_configs — Archivos de configuración adicionales para añadir al final del bloque server del dominio. Estos archivos deben ser copiados a /etc/nginx/conf.d. Añade configuraciones para tu tipo de servidor de aplicaciones aquí. El valor por defecto es un arreglo vacío.
• passenger_app — ¿Es el dominio actual una aplicación Passenger (es decir, Node, Ruby, Python)? Útil si la aplicación necesita reiniciarse después de actualizar configuraciones. Por defecto es no.
• copy_index — Copia un índice básico de index.html al sitio. Por defecto es no.
• use_ssl — Si se debe servir contenido a través de SSL (realmente TLS). Por defecto es no.
• use_letsencrypt — Si se debe utilizar Let's Encrypt para generar un certificado para un sitio. De lo contrario, se utilizará un certificado autofirmado a nivel de servidor. Por defecto es no.
• privatekey_bits — Número de bits a utilizar al generar una clave privada autofirmada. El valor por defecto es 4096.
• dhparam_bits — Número de bits a utilizar al generar un certificado DH estático. El valor por defecto es 2048. Utilizar valores mucho más altos puede llevar mucho tiempo.
• cert_valid_days — Número de días que el certificado autofirmado será válido. El valor por defecto es 3650 (aproximadamente 1 año).
• email_address — Dirección de correo electrónico para usar en el certificado autofirmado y Let's Encrypt. No está definida por defecto.
• country_name — Abreviatura de dos letras del país para usar al generar el certificado autofirmado. No está definida por defecto.
• state_name — Nombre del estado o provincia para usar al generar el certificado autofirmado. No está definida por defecto.
• locality_name — Nombre de la ciudad o localidad para usar al generar el certificado autofirmado. No está definida por defecto.
• org_name — Nombre de la organización para usar al generar el certificado autofirmado. No está definida por defecto.
• h5bp_commit — Hash de git o número de versión para usar al obtener archivos de HTML5 Boilerplate Server Configs. El valor por defecto es "3.1.0".
• setuptools_version — Versión de setuptools a instalar a través de Pip. El valor por defecto es 40.6.2.

SSL y Let's Encrypt

Let's Encrypt requiere que tu servidor web sea accesible externamente, por lo que no debes usarlo al generar sitios de desarrollo en Vagrant o Docker. Además, debes asegurarte de que tu DNS esté configurado correctamente antes de crear tu certificado. Una vez hecho esto, se emitirá un certificado completamente soportado y firmado para tu dominio, así como un trabajo cron para asegurarse de que se renueve automáticamente en el futuro. El servidor y el certificado han sido optimizados para la mejor seguridad posible, obteniendo una calificación de "A+" de SSL Labs desde octubre de 2017.

Ejemplo de Playbook

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

Licencia

MIT

Pruebas

Incluido con este rol hay un conjunto de especificaciones para probar cada tarea individualmente o en conjunto. Para ejecutar estas pruebas, primero debes tener Vagrant y VirtualBox instalados. Los archivos de especificaciones están escritos usando Serverspec, por lo que necesitarás Ruby y Bundler.

Para ejecutar el conjunto completo de especificaciones:

$ gem install bundler
$ bundle install
$ rake

El conjunto de especificaciones se dirigirá a Ubuntu Trusty Tahr (14.04), Xenial Xerus (16.04) y Bionic Beaver (18.04).

Para ver las tareas disponibles de rake (y especificaciones):

$ rake -T

Estas especificaciones no están destinadas a probar la idempotencia. Están diseñadas para verificar que las tareas especificadas realicen sus pasos esperados. La idempotencia se prueba independientemente a través de pruebas de integración.