Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. DevOps
Code

Automatizar todo con Ansible: Parte Dos

by
Length:ShortLanguages:
This post is part of a series called Automate All the Things With Ansible.
Automate All the Things With Ansible: Part One

Spanish (Español) translation by Elías Nicolás (you can also view the original English article)

Información general

Esta es la segunda parte de un tutorial en dos partes sobre Ansible. La primera parte está aquí. En esta parte, aprenderá sobre roles (bloques de construcción de Ansible), variables, bucles, cómo usar roles en libros de rol y cómo organizar roles en una estructura de directorios.

Roles

Cuando administra decenas, cientos o más servidores, probablemente muchos de ellos necesitan ser configurados de manera similar. Diferentes grupos de servidores como servidores web o servidores de bases de datos requieren su propia configuración especial, pero también pueden compartir alguna otra funcionalidad común. Por supuesto, es posible copiar tareas, pero esto se hace muy rápido cuando se trata de una infraestructura complicada.

Los roles de Ansible son el billete. Los Playbooks pueden incluir roles. Las funciones pueden depender de otros roles y las prácticas recomendadas de Ansible recomiendan agrupar hosts en su archivo de inventario en función de sus funciones. Los roles son la columna vertebral de una infraestructura gestionada Ansible. Como de costumbre, comenzaré con un ejemplo e introduciré muchas de las capacidades de los roles a través del ejemplo.

Me gustan los alias y las funciones de shell mucho porque no puedo recordar todos los interruptores y opciones para cada comando, y también porque ahorra mucho escribir. También me gusta tener algunas herramientas como htop y tmux en cada servidor en el que accedo.

Aquí hay un archivo que contiene algunos de mis alias favoritos y funciones. Lo llamaré ".gigirc". Por cierto, si alguna vez te preguntaste qué significa el sufijo 'rc' en todos esos archivos rc, entonces significa 'Ejecutar comandos'.

Vamos a definir un rol llamado 'común' que crea un usuario llamado 'gigi', agrega una clave ssh pública, copia el archivo '.gigirc' y agrega una línea al final de '~/.bashrc' que ejecuta este archivo y finalmente Instala los paquetes comunes vim, htop y tmux (definidos en el archivo 'vars/main.yml').

Voy a introducir un montón de cosas nuevas aquí: cuatro diferentes módulos, variables y bucles. Además, los roles normalmente se distribuyen entre varios archivos en una estructura de directorios estándar. Le mostraré un par de archivos y luego le explicaré la estructura del directorio. Aquí está el archivo 'tasks/main.yml':

Y aquí está el archivo vars/main.yml que contiene la definición de la variable 'COMMON_PACKAGES' utilizada para especificar qué paquetes comunes se instalarán....

Módulos

El módulo user puede administrar cuentas de usuario. Aquí lo utilizo para crear el usuario 'gigi'.

El módulo authorized_key es para agregar / quitar claves autorizadas de SSH. Aquí lo utilizo para agregar mi clave pública para el usuario 'gigi'.

El módulo lineinfile se puede usar para reemplazar o agregar líneas simples a un archivo. En este caso, lo utilizo para crear el archivo .gigirc desde '.bashrc', por lo que todos los alias y funciones cool de '.gigirc' siempre están disponibles en cualquier sesión interactiva.

Por último, el módulo apt tiene muchas opciones para administrar paquetes apt. Acabo de instalar algunos paquetes comunes.

Variables

Los COMMON_PACKAGES que se ven en la última tarea para instalar paquetes comunes son una variable. Ansible le permite utilizar variables definidas en casi cualquier lugar: libros de reproducción, inventario, roles, archivos dedicados e incluso variables de entorno. Hay mucha más información sobre las variables en la documentación.

Bucles

Ansible es declarativo, por lo que no admite bucles explícitos. Pero hay una plétora de with_xxx que le permite realizar operaciones repetidas en alguna estructura como una lista de usuarios, paquetes. O líneas en un archivo. También puede repetir operaciones hasta que alguna condición sea verdadera o obtener el índice del elemento actual. Información adicional puede encontrarse en la documentación.

Estructura del directorio de Roles

Esto es como se ve una estructura de directorio de roles típica:

common

├── handlers

│ └── main.yml

├── meta

│ └── main.yml

├── tasks

│ └── main.yml

├── templates

└── vars

├── Debian.yml

├── Ubuntu.yml

└── main.yml

El archivo 'tasks/main.yml' es donde se definen todas las tareas. Cada tarea corresponde a un comando Ansible que normalmente utiliza un módulo.

El archivo 'meta/main.yml' contendrá una lista de otros roles de los que depende el rol actual. Las tareas de estos roles se ejecutarán antes de la función actual, por lo que puede estar seguro de que todos sus requisitos previos se cumplan.

El archivo 'handlers/main.yml' es donde usted mantiene a sus manejadores, como el manejador que vio anteriormente que inicia Nginx después de la instalación.

El directorio de plantillas es donde guarda las plantillas de configuración y otros archivos de Jinja2 que desea rellenar y copiar al sistema de destino.

El directorio vars contiene varias variables y puede condicionalmente contener diferentes valores para diferentes sistemas operativos (caso de uso muy común).

Es importante tener en cuenta que Ansible es muy flexible y puede poner cualquier cosa casi en cualquier lugar. Esta es sólo una posible estructura que tiene sentido para mí. Si observa las estructuras de directorios de otras personas, puede ver algo completamente diferente. Eso está bien. No se alarmen. Ansible no es prescriptivo, aunque sí proporciona una guía para las mejores prácticas.

Uso de Roles

Roles hacen el trabajo pesado, pero playbooks es cómo trabajas realmente. Los guías escolares casan el inventario y las funciones y especifican qué papeles jugar en qué host. Esto es lo que parece un libro de jugadas con roles:

Ejecutar el playbook produce la siguiente salida:

Conclusion

Ansible es una gran herramienta. Es ligero. Se puede utilizar interactivamente con comandos ad-hoc, y se adapta muy bien a sistemas masivos. También tiene mucho dinamismo y una gran comunidad. Si administra o si sólo trabaja con servidores remotos, desea Ansible.

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.