Como dejamos nuestro libro de jugadas en la sesión de ayer, necesitaríamos ejecutar cada tarea y jugada dentro de ese libro de jugadas. Esto significa que tendríamos que ejecutar las jugadas y tareas de los servidores web y el equilibrador de carga hasta su finalización.
Sin embargo, las etiquetas nos permiten separarlos si así lo deseamos. Esto podría ser un movimiento eficiente si tenemos libros de jugadas muy grandes y largos en nuestros entornos.
Podemos confirmar esto utilizando el comando `ansible-playbook playbook5.yml --list-tags` y la lista de etiquetas mostrará las etiquetas que hemos definido en nuestro libro de jugadas.
Ahora, si quisiéramos dirigirnos solo al proxy, podríamos hacerlo ejecutando `ansible-playbook playbook5.yml --tags proxy` y esto, como se puede ver a continuación, solo ejecutará el libro de jugadas contra el proxy.
Las etiquetas también se pueden agregar a nivel de tarea para que podamos ser más detallados sobre dónde y qué queremos que suceda. Podrían ser etiquetas enfocadas en la aplicación, podríamos pasar por las tareas y etiquetarlas según la instalación, configuración o eliminación.
Otra etiqueta muy útil que se puede usar es `tag: always`, esto asegurará que sin importar qué `--tags` estés usando en tu comando, si algo está etiquetado con el valor "always", siempre se ejecutará cuando ejecutes el comando `ansible-playbook`.
Con las etiquetas, también podemos agrupar varias etiquetas juntas y si elegimos ejecutar `ansible-playbook playbook5.yml --tags proxy,web`, esto ejecutará todos los elementos con esas etiquetas. Obviamente, en nuestro caso, eso significaría lo mismo que ejecutar el libro de jugadas, pero si tuviéramos múltiples jugadas adicionales, tendría sentido.
Cada vez que ejecutamos nuestros libros de jugadas, tenemos una tarea que no hemos definido llamada "Recopilación de hechos". Podemos usar estas variables o hechos para realizar acciones con nuestras tareas de automatización.
Si ejecutamos el siguiente comando `ansible proxy -m setup`, deberíamos ver una gran cantidad de información en formato JSON. Sin embargo, habrá mucha información en tu terminal, por lo que nos gustaría redirigir esta salida a un archivo usando `ansible proxy -m setup >> facts.json`. Puedes encontrar este archivo en este repositorio: [ansible-scenario5](Configmgmt/ansible-scenario5/facts.json)
Si abres este archivo, podrás ver todo tipo de información sobre nuestro comando. Podemos obtener nuestras direcciones IP, arquitectura y versión de BIOS. Es información muy útil si queremos aprovecharla y utilizarla en nuestros playbooks.
Una idea sería usar una de estas variables dentro de nuestra plantilla de Nginx `mysite.j2`, donde hemos codificado las direcciones IP de nuestros servidores web. Puedes hacer esto creando un bucle `for` en tu `mysite.j2` que recorra el grupo `[webservers]`. Esto nos permitirá tener más de nuestros 2 servidores web creados o agregados automáticamente y de forma dinámica a esta configuración de equilibrador de carga.
El resultado de lo anterior se verá igual que ahora, pero si agregamos más servidores web o eliminamos uno, esto cambiará dinámicamente la configuración del proxy. Para que esto funcione, deberás tener la resolución de nombres configurada.
Las variables creadas por el usuario son aquellas que hemos creado nosotros mismos. Si observas nuestro playbook, verás que tenemos `vars:` y luego una lista de 3 variables que estamos utilizando allí.
Sin embargo, podemos mantener nuestro playbook libre de variables moviéndolas a sus propios archivos. Vamos a hacer esto, pero nos moveremos a la carpeta [ansible-scenario6](Configmgmt/ansible-scenario6). En la raíz de esa carpeta, crearemos una carpeta llamada group_vars. Luego crearemos otra carpeta llamada all (todas las agrupaciones obtendrán estas variables). Dentro de ella, crearemos un archivo llamado `common_variables.yml` y copiaremos nuestras variables del playbook en este archivo. Las eliminaremos del playbook junto con vars: también.
Debido a que estamos asociando esto como una variable global, también podríamos agregar nuestros servidores NTP y DNS aquí. Las variables se establecen en función de la estructura de carpetas que hemos creado. Puedes ver a continuación lo limpio que se ve nuestro playbook ahora.
También podemos definir un hecho de Ansible en nuestro archivo `roles/apache2/templates/index.HTML.j2` para entender en qué servidor web nos encontramos.
Los resultados de ejecutar el comando `ansible-playbook playbook6.yml` con los cambios en las variables significan que, cuando accedemos a nuestro balanceador de carga, podemos ver que estamos llegando a cualquiera de los servidores web que tenemos en nuestro grupo.
También podríamos agregar una carpeta llamada host_vars y crear un archivo web01.yml para tener un mensaje específico o cambiar cómo se ve en cada host, si así lo deseamos.
Hasta ahora hemos utilizado el archivo de hosts predeterminado en la carpeta `/etc/ansible` para determinar nuestros hosts. Sin embargo, podríamos tener diferentes archivos para diferentes entornos, como producción y puesta en escena. No voy a crear más entornos, pero podemos crear nuestros archivos de host.
Podemos crear varios archivos para nuestras diferentes configuraciones de servidores y nodos. Podemos llamar a estos archivos utilizando el comando `ansible-playbook -i dev playbook.yml`. También puedes definir variables dentro de tu archivo de hosts y luego imprimir o utilizar esa variable en otro lugar de tus playbooks. Por ejemplo, en el ejemplo del curso de capacitación que estoy siguiendo, han agregado la variable de entorno creada en el archivo de hosts a la plantilla de la página web del balanceador de carga para mostrar el entorno como parte del mensaje de la página web.
Todavía nos queda una máquina que no hemos encendido ni configurado. Podemos hacerlo usando el comando `vagrant up db01` desde donde se encuentra nuestro archivo Vagrantfile. Cuando esté encendida y accesible, debemos asegurarnos de copiar la clave SSH utilizando el comando `ssh-copy-id db01` para poder acceder a ella.
En nuestro playbook, vamos a agregar un nuevo bloque de tareas para la configuración de la base de datos. Tenemos nuestro grupo database definido en nuestro archivo /etc/ansible/hosts. Luego, instruimos a nuestro grupo de bases de datos que tenga el rol common y un nuevo rol llamado MySQL, que creamos en el paso anterior. También estamos etiquetando nuestro grupo de bases de datos con database, lo que significa que, como discutimos anteriormente, podemos elegir ejecutar solo las tareas etiquetadas si así lo deseamos.
Como se puede ver arriba, estamos utilizando algunas variables para determinar parte de nuestra configuración, como contraseñas, nombres de usuario y bases de datos. Todo esto se almacena en nuestro archivo `group_vars/all/common_variables.yml`.
Ahora que tenemos nuestra máquina virtual en funcionamiento y nuestros archivos de configuración en su lugar, estamos listos para ejecutar nuestro playbook, que incluirá todo lo que hemos hecho antes si ejecutamos el siguiente comando `ansible-playbook playbook7.yml`. También podríamos elegir implementar solo en nuestro grupo de bases de datos con el comando `ansible-playbook playbook7.yml` --tags database, que ejecutará solo nuestros nuevos archivos de configuración.
Ejecuté el playbook solo para la etiqueta de la base de datos, pero me encontré con un error. Este error me indica que no tenemos pip3 (Python) instalado. Podemos solucionar esto agregando esto a nuestras tareas comunes e instalándolo.
Deberíamos asegurarnos de que todo esté como queremos en nuestro servidor db01 recién configurado. Podemos hacer esto desde nuestro nodo de control usando el comando `ssh db01`.
Una vez que nos hayamos conectado, asegurémonos primero de que se haya creado nuestro usuario llamado DevOps. Ejecutamos `select user, host from mysql.user;`.
Utilicé root para conectarme, pero también podríamos iniciar sesión con nuestra cuenta de DevOps de la misma manera, usando `sudo /usr/bin/MySQL -u devops -p`, pero la contraseña aquí es DevOps90.
Una cosa que he descubierto es que en nuestro archivo `setup_mysql.yml` tuve que agregar la línea `login_unix_socket: /var/run/mysqld/mysqld.sock` para conectarme correctamente a mi instancia de MySQL en db01, y ahora cada vez que ejecuto esto, se informa un cambio al crear el usuario. Cualquier sugerencia sería muy apreciada.
Esta última lista de reproducción mencionada anteriormente es de donde proviene gran parte del código e ideas para esta sección, es un recurso excelente y un recorrido en formato de video.
