Esta publicación analiza un ejemplo muy simple de libro de jugadas que usa roles de Ansible para dividir y organizar el proceso de aprovisionamiento. Si no ha usado Ansible para configurar un servidor antes, este es un buen lugar para comenzar. Luego, la idea se puede ampliar para agregar más componentes individuales o ideas específicas. Playbook está diseñado para hosts Linux que ejecutan Debian 8 (Jessie) y se prueba con una VM Vagrant adecuada. Después de la prueba, hacia el final de la publicación, el libro de jugadas se implementa en varios droplets de Debian 8 recién creados en Digital Ocean
1 – Repositorio de libros de jugadas
La totalidad de esta publicación se probó en una máquina virtual Xubuntu 16.04 usando la siguiente versión de Ansible y Python:
1 – Repositorio de Playbook2 – Archivo principal de Playbook3 – Roles: Base4 – Roles: Usuarios5 – Roles: UFW6 – Roles: NTP7 – Pruebas locales vagabundas8 – Digital Ocean Droplet(s)
El diseño de los archivos para este libro de jugadas se ve así:
2 – Archivo principal del libro de jugadas
En el nivel raíz del repositorio ansible-debian-provisioning se encuentra el archivo principal playbook.yml, que llama y ejecuta los roles subsiguientes y sus tareas. Hay varias variables definidas aquí en este archivo básico del libro de jugadas.
hosts : establezca como destino todos los hosts en el archivo de inventario de Ansible /etc/ansible/hosts. reunir_facts : cuando se ejecuta el libro de jugadas, primero recopilará tareas sobre el sistema operativo antes de ejecutar tareas. Roles : estos son los cuatro nombres de roles que se incluirán al ejecutar el libro de jugadas de Ansible (enumerados en orden de ejecución).
A partir de aquí, las jugadas (tareas) dentro de cada uno de los directorios de roles son procesadas por Ansible, una vez que el usuario ejecuta el libro de jugadas.
3 – Roles: Base
La función “base” establece algunos valores predeterminados/bases de servidor sensibles y contiene tres directorios que contienen sus archivos de configuración de Ansible relevantes: El directorio de “archivos” contiene un archivo de mensaje del día (MOTD) de estilo ASCII, que una vez en su lugar se muestra al usuario al conectarse al servidor. Esto se puede cambiar libremente a cualquier mensaje que sea adecuado alterando el contenido del archivo motd . El juego (o tareas) para que Ansible lleve a cabo este rol en cada host de destino, se encuentran en el archivo de configuración del directorio de “tareas”. Aquí hay múltiples tareas que juntas forman el juego. La descripción de cada tarea explica su propósito individual. Aquí es donde se realiza la mayor parte de los cambios en los hosts de destino cuando se ejecuta el libro de jugadas. Cada cambio se describe aproximadamente en las directivas de nombre. En esta función básica, se instalarán varios paquetes, se cambiará el mensaje del día, se exigirá y se hará obligatorio el uso de la clave SSH, mientras que se habilitarán las actualizaciones de seguridad automáticas. Observe en el último fragmento de código la activación de los dos controladores cuando sea necesario mediante el uso de notify:. Así es como funcionan los controladores. El archivo de configuración del directorio “handler” enumera dos controladores. El primer controlador para esta función garantiza que se reinicie el demonio del sistema SSH. El segundo controlador ejecuta el comando dpkg-reconfigure para el paquete de actualizaciones desatendidas. Estos controladores se activan cuando se agregan a tareas que se encuentran en otros lugares de los archivos del libro de jugadas de este rol, como vimos anteriormente.
4 – Roles: Usuarios
El rol de “usuarios” alberga dos directorios de Ansible. El archivo main.yml en el directorio predeterminado contiene las credenciales para que las cuentas de usuario de Linux se generen en los hosts de destino. El YAML que se usa aquí comienza como una lista de diccionarios. Cada usuario y sus credenciales asociadas forman una entrada en esta lista inicial de diccionarios. Las claves en cada diccionario aquí contienen los valores de usuario literales. Si no está seguro de la sintaxis de YAML y su uso, consulte las explicaciones de Ansible sobre YAML en Ansible. La primera clave en el diccionario del usuario es nombre: y define el nombre de usuario de la cuenta de Linux. El segundo es encrypted_password: que debe establecerse en un valor hash y no debe ser texto sin formato. Más adelante en esta sección, explicaremos cómo generar un hash para sus propias contraseñas. El tercero es public_keys: que notarás es plural. Esto es en caso de que desee agregar varias claves SSH (desde su host local) a su nueva cuenta de usuario remota, para dar acceso a varias personas/claves cuando sea necesario. Es importante destacar que aquí se usa una lista “anidada” para agregar estas entradas múltiples cuando son necesarias. La siguiente clave sudo: es un booleano y agrega la cuenta de usuario al grupo sudo cuando se establece en “verdadero”. La última clave adm: es la misma que la clave anterior. También es un valor booleano y agrega la cuenta de usuario al grupo adm o “admin” cuando se establece en “true”. Pasando al segundo archivo de configuración en el directorio “tareas”, puede ver el juego/tareas que hacen uso de las definiciones en el archivo anterior. Las descripciones de las tareas explican cómo funcionan las cosas aquí. Los módulos que se utilizan para ello son los módulos de usuario y clave autorizada.
Generación de contraseñas cifradas
Cuando se trata de generar los hashes (valores encriptados) para las contraseñas de la clave de su nombre de usuario, se ofrecen varios métodos diferentes. La primera consiste en usar mkpasswd una utilidad que está disponible en la mayoría de los sistemas Linux. Si no está en su sistema, búsquelo en el índice de su administrador de paquetes, que en Debian y Ubuntu viene incluido dentro del paquete whois . Una forma separada de hacer esto es usar el módulo/biblioteca de cifrado de Python: $ python -c ‘importar cripta; imprimir crypt.crypt(“IngresarContraseñaAquí”, “AlgunaSal”)’ Ingrese la contraseña aquí, por supuesto, se reemplaza por la contraseña de texto sin formato que desea usar. Mientras que SomeSalt debe ser reemplazado por una sal, una cadena aleatoria de caracteres. Podría usar pwgen para generar sales, si desea: Una última alternativa es a través del paquete openssl . Elija uno de los valores de la salida para usar para sus contraseña_encriptada: claves.
5 - Funciones: UFW
El rol “UFW” configura la configuración del firewall para los servidores. Solo hay que tener en cuenta dos archivos de configuración. El primer archivo de configuración en el directorio “predeterminado” define qué puertos de firewall personalizados desea que permanezcan abiertos y accesibles para conexiones externas. Se definen en un formato de lista que se puede agregar según sea necesario. Solo dos puertos están configurados para abrirse actualmente en este archivo: el puerto HTTP 80 y el puerto HTTPS 43. Se realizan más retoques con el firewall en el otro archivo de configuración, que reside en el directorio “tareas”: Como puede ver arriba en el último fragmento de código, se le indica a Ansible que instale el paquete UFW, restablezca el firewall, abra el puerto 22 para acceder a SSH, luego vuelva a cargar y habilite el firewall para que se active. También se abren nuestros puertos anteriores definidos en el otro archivo. Vale la pena señalar que todo esto se hace a través del módulo ufw: Ansible incorporado, y en ningún momento manualmente a través del shell.
6 – Funciones: NTP
La función NTP maneja la configuración de la zona horaria para los hosts de destino y tiene cuatro directorios con archivos de configuración dentro de ellos:
roles/ntp/defaults/main.yml roles/ntp/handlers/main.yml roles/ntp/tasks/main.yml roles/ntp/templates/main.yml
El archivo de configuración “predeterminado” es donde configura la zona horaria que desea usar para su (s) servidor (es). Modifique el texto Europa/Londres a su propia elección aquí. No hay ningún requisito para cambiar ntp_server: definición y esto se puede dejar como está escrito. Se requieren dos controladores (todos configurados en el archivo “controladores”) para garantizar que la configuración de NTP se ejecute una vez configurada/actualizada. Se activan normalmente en el otro archivo de la sección “tareas”. Las “tareas” de NTP llevan a cabo varias acciones. Un archivo de plantilla que contiene la zona horaria elegida se copia en el directorio /etc/timezone de los hosts remotos y se le otorgan permisos basados en el usuario raíz. A continuación, se descarga e instala el paquete tzdata y ntp. El servicio ntp se habilita y comienza a usar el servicio: módulo. Dos líneas en ntp.conf se modifican para que coincidan con el tipo de sistema operativo (Debian en este caso), que se ha establecido en la directiva “predeterminada” ntp_server: . Como antes, tenga en cuenta el uso de los controladores para activar las acciones deseadas en este fragmento de NTP anterior. Por último, en esta sección/función, puede ver el archivo de plantilla de una línea muy breve. Lo que toma su elección de zona horaria, p. zona horaria: Europa/Londres desde el archivo de configuración predeterminado. Estos son todos los roles del libro de jugadas cubiertos, aquí hay un método para probarlo antes de implementarlo y utilizarlo en hosts reales.
7 – Pruebas locales vagabundas
Puede ejecutar el libro de jugadas en un entorno de prueba para asegurarse de que funciona según lo previsto, antes de aplicarlo a servidores reales. Una herramienta de contenedorización/virtualización como Vagrant o Docker es excelente para este propósito. En mi prueba de ejemplo, voy con Vagrant, pero Docker es probablemente una opción más moderna y ciertamente vale la pena seguirla si lo prefiere. Sin embargo, tenga en cuenta que los contenedores están destinados a ser abstraídos en capas reducidas de una imagen completa del sistema operativo, por lo que, de hecho, es posible que no sean más adecuados que una máquina virtual Vagrant. Si aún no lo ha hecho, deberá clonar el repositorio de GitHub para realizar las pruebas en este paso: Una vez que haya clonado el repositorio y Vagrant esté funcionando en su sistema local, cambie al directorio vagrant para comenzar la prueba. En este directorio verás varios archivos de Vagrant. El archivo principal que hace la mayor parte del trabajo aquí es el Vagrantfile. La única parte del archivo Vagrantfile que veremos aquí es el bloque de código de “provisión”, así que abra el archivo con un editor y encuéntrelo, o simplemente léalo aquí: Esta pieza de configuración establece Ansible como el agente de aprovisionamiento que Vagrant debe usar al aprovisionar una VM de Vagrant. También identifica dónde se almacena el libro de jugadas de destino que se utilizará, junto con el archivo de inventario de Ansible que se utilizará. La comprobación de clave de host para SSH con Ansible también está inhabilitada. Todo esto está en el contexto de la VM de prueba de Vagrant. Entonces, el proveedor es la entidad que trabaja a través de algunas tareas preestablecidas utilizando la instancia de VM proporcionada por Vagrant. Los aprovisionadores más comunes son: Puppet, Chef y Ansible. Shell Scripting también sigue siendo una opción muy frecuente. El resto del archivo Vagrant es importante, pero no crucial, ya que se puede entender en otro momento cuando se aprende cómo funciona Vagrant. Salga de este archivo y escriba el siguiente comando para comenzar el proceso de prueba: Esto descarga el cuadro debian/jessie64 (visto aquí) especificado en el archivo Vagrant y crea una instancia de ese cuadro como una máquina virtual Vagrant (para probar el libro de jugadas de Ansible). Como la configuración de aprovisionamiento de Ansible ya se encuentra en el Vagrantfile, no es necesario decirle a Vagrant que use Ansible con la nueva máquina virtual para nosotros. Así que observe cómo los mensajes de salida muestran el progreso de la ejecución del libro de jugadas, hasta que la pantalla final muestre: Para verificar aún más que se han realizado los cambios, o explorar partes individuales de la VM de prueba de Vagrant, SSH en ella escribiendo: Salga de Vagrant VM como lo haría con cualquier otro host remoto, p. salir o CTRL + D Cuando realice cambios en el contenido del libro de jugadas y sus acciones en el futuro, para probar más los cambios, debe volver a ejecutar el libro de jugadas en la VM de Vagrant. Para hacer esto usa este comando: Ejecutar manualmente Ansible contra Vagrant para lograr algo así como una ejecución de prueba en seco, es decir, también es posible verificar o cualquier otra opción que desee incorporar. Para implementar los cambios de nuevo, elimine la marca –check o utilice el comando provision como de costumbre. Finalmente aquí, echemos un vistazo a algunas tareas domésticas en términos de uso de Vagrant. Actualice su caja Vagrant Debian a la última versión del mantenedor con: Destruya su entorno de prueba (instancia de VM de Vagrant) con el siguiente comando, donde predeterminado es el nombre del entorno. Los ID de las máquinas virtuales de Vagrant también funcionan en lugar del nombre del entorno. Finalmente, para eliminar completamente la descarga de la caja Vagrant Debian y todas las diferentes versiones actualizadas, ejecute: Ahora en la cosa real!
8 – Gota(s) digital(es) del océano
Cree varios droplets nuevos de Debian mediante el panel de control de Digital Ocean, copiando su clave SSH de Ansible en los nuevos droplets durante la creación. Agregue las múltiples direcciones IP de droplet nuevas a su archivo de inventario de Ansible (predeterminado en /etc/ansible/hosts). Aquí hay un ejemplo mínimo básico de los contenidos, por si creó tres gotas en total. Cree este directorio y comience a escribir en un nuevo archivo: Configure una variable de grupo para el grupo de prueba, de modo que usen el usuario raíz con las operaciones SSH de Ansible. En el nivel raíz del repositorio, ejecute nuestro libro de jugadas de aprovisionamiento de Ansible en las gotas de Digital Ocean en vivo de su grupo de prueba. Mire la salida una vez más para confirmar el éxito del libro de jugadas. Eso es todo. Puede verificar su gota manualmente y ver lo que realmente cambió si realmente lo desea, pero el resultado anterior de ejecutar el libro de jugadas de Ansible es, por supuesto, su verificación, sobre lo que se ha llevado a cabo. Los enlaces a publicaciones posteriores de Ansible se pueden encontrar en la página Trades.
