El inventario es el punto de partida para todas las automatizaciones de Ansible, ya que define qué máquinas van a recibir las configuraciones y cómo acceder a ellas. Se pueden crear inventarios en un archivo plano (por defecto hosts
), en formato YAML o INI, o incluso de manera dinámica usando *scripts* o *plugins*.
1. Inventarios estáticos: Se definen en archivos de texto (como hosts
), ya sea en formato INI o YAML.
2. Inventarios dinámicos: Se generan en tiempo real a partir de fuentes externas (AWS, Google Cloud, etc.) usando scripts o plugins específicos.
El formato INI es el más común para los inventarios en Ansible y se organiza en grupos y subgrupos de hosts. Un ejemplo básico:
[webservers]
web1.example.com
web2.example.com
[dbservers]
db1.example.com
db2.example.com
[all:vars]
ansible_user=admin
ansible_port=22
En este inventario:
webservers
y dbservers
.
all:vars
, se establecen variables que se aplican a todos los hosts (ansible_user
y ansible_port
).
También se puede estructurar en formato YAML, lo que lo hace más legible y flexible:
all:
hosts:
localhost:
ansible_connection: local
children:
webservers:
hosts:
web1.example.com:
ansible_user: admin
web2.example.com:
ansible_user: admin
dbservers:
hosts:
db1.example.com:
ansible_user: dbadmin
db2.example.com:
ansible_user: dbadmin
Aquí se definen los grupos webservers
y dbservers
bajo la sección children
. Cada host puede tener sus propias variables específicas.
En lugar de un archivo estático, se puede usar un *script* o *plugin* de inventario dinámico que se conecta a fuentes externas (como AWS o GCP) para recuperar automáticamente la lista de hosts. Esto es útil para infraestructuras que cambian constantemente.
ansible-playbook -i aws_ec2.yml playbook.yml
En este caso, aws_ec2.yml
es un inventario dinámico que obtiene los servidores directamente desde AWS.
El inventario se puede especificar de distintas maneras al ejecutar un comando o playbook:
Si el archivo de inventario se llama hosts
o inventory
y está en el mismo directorio, Ansible lo detecta automáticamente. Para usarlo, basta con ejecutar un playbook o comando:
ansible-playbook mi_playbook.yml
Puedes indicar un archivo de inventario específico con la opción -i
:
ansible-playbook -i inventario_custom.ini mi_playbook.yml
O ejecutar un comando simple en un grupo de hosts específico:
ansible webservers -i inventario_custom.ini -m ping
En el archivo de inventario, se pueden definir variables específicas para cada host o grupo:
[webservers]
web1.example.com ansible_user=webadmin ansible_port=2222
web2.example.com ansible_user=webadmin ansible_port=2222
[dbservers]
db1.example.com ansible_user=dbadmin ansible_port=3306
Estas variables indican cómo Ansible debe conectarse a cada host.
En proyectos grandes, es mejor organizar los inventarios en archivos múltiples para facilitar su mantenimiento:
inventories/
├── production
│ ├── hosts
│ └── group_vars/
│ └── all.yml
├── staging
│ ├── hosts
│ └── group_vars/
│ └── all.yml
En este ejemplo, se tienen inventarios separados para production
y staging
con sus propias variables.
ansible all -m ping
Resultado: Ansible probará la conectividad (ping
) en todos los hosts definidos en el inventario por defecto.
ansible webservers -m yum -a "name=httpd state=present"
Resultado: Instala el paquete httpd
en todos los servidores del grupo webservers
.
ansible-playbook -i production/hosts deploy.yml
Resultado: Aplica el playbook
deploy.yml
a los hosts definidos en el archivo production/hosts
.
1. Usa nombres de host descriptivos: Para facilitar la lectura y el mantenimiento del inventario.
2. Organiza los hosts en grupos: Agrupa hosts por función (web
, db
) o entorno (dev
, prod
).
3. Define variables a nivel de grupo y host: Aprovecha las variables en group_vars
y host_vars
para personalizar la configuración.
4. Usa inventarios dinámicos para grandes infraestructuras: Si gestionas cientos de servidores, los inventarios dinámicos son una mejor opción.
Para más detalles sobre cómo crear y gestionar inventarios en Ansible, consulta la documentación oficial de Ansible sobre Inventarios.
Jorge García
Fullstack developer