Ansible: inventario, comandos y playbooks operativos
Esta es una guía práctica para pasar de comandos puntuales a automatizaciones repetibles. Todos los nombres de equipos, usuarios y grupos son ejemplos; en un entorno real deben vivir en el inventario o en variables protegidas.
Estructura mínima
1
2
3
4
5
6
7
8
| ansible/
├── ansible.cfg
├── inventory.ini
├── group_vars/
│ └── all.yml
└── playbooks/
├── diagnostico.yml
└── usuarios.yml
|
Un ansible.cfg local evita depender de rutas globales:
1
2
3
4
5
6
| [defaults]
inventory = ./inventory.ini
roles_path = ./roles
log_path = ./ansible.log
host_key_checking = True
interpreter_python = auto_silent
|
Inventario sin datos sensibles
1
2
3
4
5
6
7
8
9
10
| [linux]
<HOST_LINUX_01> ansible_host=<IP_INTERNA_01>
<HOST_LINUX_02> ansible_host=<IP_INTERNA_02>
[aix]
<HOST_AIX_01> ansible_host=<IP_INTERNA_03>
[linux:vars]
ansible_user=<USUARIO_SSH>
ansible_become=true
|
No conviene publicar inventarios reales: revelan nombres, direcciones, agrupaciones y cuentas de acceso. Las contraseñas, claves privadas y valores de ansible_become_password deben quedar fuera del repositorio o cifrados con Ansible Vault.
Comprobaciones antes de ejecutar
1
2
3
| ansible-inventory --graph
ansible all -m ansible.builtin.ping
ansible linux --list-hosts
|
Para limitar una ejecución a un grupo o equipo:
1
2
| ansible-playbook playbooks/diagnostico.yml --limit linux
ansible-playbook playbooks/diagnostico.yml --limit '<HOST_LINUX_01>'
|
Diagnóstico con varios comandos
Para órdenes simples es preferible ansible.builtin.command. shell solo hace falta cuando se usan tuberías, redirecciones u otras funciones del intérprete.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| ---
- name: Recoger un diagnostico basico
hosts: all
gather_facts: false
tasks:
- name: Ejecutar comandos de solo lectura
ansible.builtin.command: "{{ item }}"
loop:
- uptime
- who
- df -h
register: diagnostico
changed_when: false
- name: Mostrar las salidas
ansible.builtin.debug:
msg: "{{ item.stdout }}"
loop: "{{ diagnostico.results }}"
loop_control:
label: "{{ item.item }}"
|
Cuando el comando necesita una tubería:
1
2
3
4
5
| - name: Consultar errores recientes
ansible.builtin.shell:
cmd: "journalctl -p err --since today | tail -n 20"
register: errores
changed_when: false
|
Si una variable entra en una orden de shell, debe filtrarse con quote:
1
2
3
4
| - name: Buscar un patron controlado
ansible.builtin.shell:
cmd: "grep -F -- {{ patron | quote }} /var/log/<APLICACION>.log"
changed_when: false
|
En vez de guardar nombres reales dentro del playbook, se pasan variables genéricas:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| ---
- name: Gestionar una cuenta local
hosts: linux
become: true
vars:
cuenta: <USUARIO>
grupo_principal: <GRUPO_PRINCIPAL>
grupos_adicionales:
- <GRUPO_01>
- <GRUPO_02>
tasks:
- name: Crear o actualizar la cuenta
ansible.builtin.user:
name: "{{ cuenta }}"
group: "{{ grupo_principal }}"
groups: "{{ grupos_adicionales | join(',') }}"
append: true
state: present
|
Ejecución:
1
2
3
| ansible-playbook playbooks/usuarios.yml \
-e 'cuenta=<USUARIO> grupo_principal=<GRUPO>' \
--limit '<GRUPO_DE_HOSTS>'
|
Los datos personales no deben aparecer en el playbook, el historial del terminal ni los logs de CI.
Secretos con Vault
1
2
3
| ansible-vault create group_vars/all/vault.yml
ansible-vault edit group_vars/all/vault.yml
ansible-playbook playbooks/<PLAYBOOK>.yml --ask-vault-pass
|
Para tareas que pudieran imprimir un secreto:
1
2
3
4
5
6
7
| - name: Usar una credencial protegida
ansible.builtin.command:
argv:
- /usr/local/bin/<COMANDO>
- --token
- "{{ vault_token }}"
no_log: true
|
Validación y ejecución gradual
1
2
3
4
| ansible-playbook playbooks/<PLAYBOOK>.yml --syntax-check
ansible-playbook playbooks/<PLAYBOOK>.yml --check --diff --limit '<HOST_DE_PRUEBA>'
ansible-playbook playbooks/<PLAYBOOK>.yml --limit '<HOST_DE_PRUEBA>'
ansible-playbook playbooks/<PLAYBOOK>.yml --limit '<GRUPO_DE_HOSTS>'
|
El modo --check depende de cada módulo y no garantiza una simulación completa para órdenes arbitrarias. La secuencia segura es validar sintaxis, probar en un equipo controlado y ampliar el alcance cuando el resultado sea el esperado.
Referencias