Introducción
Los roles agrupan una unidad funcional de automatización para que los consumidores puedan proporcionar datos sin duplicar la implementación. Crearás un rol con valores predeterminados públicos, generarás páginas específicas de cada host, mantendrás la validación de configuración y el comportamiento de recarga dentro del rol y lo reutilizarás en dos grupos del inventario. Los archivos administrados reales y las respuestas HTTP verificarán que el rol se invoca realmente.
Crear e invocar un rol con valores predeterminados
En este paso, trasladarás la automatización del sitio web a un rol y lo invocarás mediante un playbook corto usando entradas predeterminadas reutilizables.
Un rol agrupa tareas relacionadas, variables predeterminadas, plantillas y handlers bajo un directorio estándar. Su tasks/main.yml es el punto de entrada de tareas; defaults/main.yml proporciona valores de baja precedencia que los consumidores pueden sobrescribir. Los orígenes de plantillas van bajo templates y handlers/main.yml contendrá después acciones de servicio activadas por cambios.
El inventario preparado ya coloca web1 en canary y web2 en stable, bajo el grupo padre sites. Nginx está instalado como requisito previo. Inspecciona los grupos:
cd /home/labex/project
ansible-inventory --graph
Crea los directorios del rol con mkdir -p. Varios argumentos de ruta crean cada directorio nombrado:
mkdir -p roles/managed_site/tasks roles/managed_site/defaults roles/managed_site/templates roles/managed_site/handlers
Antepon site_ a las variables públicas del rol para aclarar su propósito. Comienza con valores predeterminados compartidos que cualquier consumidor pueda usar:
cat > roles/managed_site/defaults/main.yml <<'YAML'
site_environment: training
site_port: 8080
site_maintenance: false
YAML
La plantilla de página usa la entrada del rol junto con el nombre y la distribución recopilada de cada destino:
cat > roles/managed_site/templates/page.txt.j2 <<'JINJA'
host={{ inventory_hostname }}
environment={{ site_environment }}
distribution={{ ansible_facts.distribution }}
JINJA
Crea el punto de entrada de tareas del rol. Dentro de un rol, src: page.txt.j2 se resuelve bajo el directorio templates de ese rol; el destino sigue siendo una ruta administrada absoluta:
cat > roles/managed_site/tasks/main.yml <<'YAML'
- name: Prepare the role-managed website directory
ansible.builtin.file:
path: /var/www/role-site
state: directory
owner: root
group: root
mode: "0755"
- name: Render the role-managed page
ansible.builtin.template:
src: page.txt.j2
dest: /var/www/role-site/index.html
owner: root
group: root
mode: "0644"
YAML
Invoca el rol con la palabra clave roles. El play que lo contiene selecciona los destinos, recopila datos y solicita become; el rol proporciona las tareas reutilizables:
cat > site.yml <<'YAML'
- name: Apply the managed site role with defaults
hosts: sites
gather_facts: true
become: true
roles:
- managed_site
YAML
Valida y ejecuta el rol mediante su playbook consumidor:
ansible-playbook site.yml --syntax-check
ansible-playbook site.yml
Inspecciona las páginas reales creadas por el rol:
ansible sites -m ansible.builtin.command -a 'cat /var/www/role-site/index.html'
Ambas deberían mostrar environment=training a partir del valor predeterminado, con sus propios nombres de host y distribution=Ubuntu. Crear únicamente directorios de rol no ejecutaría el rol ni crearía estos archivos administrados.
Mantener plantillas y handlers dentro del rol reutilizable
En este paso, harás que el rol configure y ejecute el sitio web, incluida la validación del candidato y su propio handler de recarga.
Coloca la plantilla completa de nginx junto al origen de la página. Usa las entradas site_ del rol, el filtro upper practicado anteriormente y una rama booleana:
cat > roles/managed_site/templates/nginx.conf.j2 <<'JINJA'
events {}
http {
server_tokens off;
server {
listen {{ site_port }};
root /var/www/role-site;
index index.html;
add_header X-Environment "{{ site_environment | upper }}" always;
{% if site_maintenance %}
add_header X-Maintenance "enabled" always;
{% else %}
add_header X-Maintenance "disabled" always;
{% endif %}
}
}
JINJA
Añade tareas del rol que validen la configuración generada antes de sustituir la existente y mantengan explícitamente nginx iniciado. La configuración con cambios notifica al handler con nombre del rol:
cat >> roles/managed_site/tasks/main.yml <<'YAML'
- name: Render and validate the role-managed nginx configuration
ansible.builtin.template:
src: nginx.conf.j2
dest: /etc/nginx/nginx.conf
owner: root
group: root
mode: "0644"
validate: /usr/sbin/nginx -t -c %s
notify: Reload managed site
- name: Keep the role-managed service running
ansible.builtin.service:
name: nginx
state: started
YAML
Escribe el handler en el punto de entrada de handlers del rol en lugar de duplicarlo en cada playbook consumidor:
cat > roles/managed_site/handlers/main.yml <<'YAML'
- name: Reload managed site
ansible.builtin.service:
name: nginx
state: reloaded
YAML
Ejecuta el playbook consumidor sin cambios. El rol proporciona ahora su comportamiento completo de despliegue:
ansible-playbook site.yml
Ambos hosts deberían iniciar su propio sitio en el puerto predeterminado 8080. Inspecciona cada destino mediante su propio destino de bucle local:
ansible sites -m ansible.builtin.command -a 'curl --fail --silent --show-error -i http://127.0.0.1:8080/'
Cada cuerpo debería identificar su propio host y environment=training. Las cabeceras deberían incluir X-Environment: TRAINING y X-Maintenance: disabled. La salida procede de servicios en ejecución configurados por el rol, en lugar de una demostración exclusiva del controlador.
Reutilizar el mismo rol con variables de grupo que sobrescriben valores predeterminados
En este paso, aplicarás el mismo rol a dos contextos de grupo sin editar sus valores predeterminados reutilizables ni sus archivos de tareas.
Los valores predeterminados del rol tienen deliberadamente baja precedencia. Las variables de grupo del inventario pueden sobrescribir estas entradas públicas manteniendo la misma implementación. Deja defaults/main.yml sin cambios y crea los datos consumidores de cada grupo:
cat > group_vars/canary.yml <<'YAML'
site_environment: development
site_port: 8081
site_maintenance: true
YAML
cat > group_vars/stable.yml <<'YAML'
site_environment: production
site_port: 8082
site_maintenance: false
YAML
Sustituye el playbook consumidor por dos plays que invoquen el mismo rol managed_site. Cada grupo recibe sus propias entradas resueltas. No dupliques el directorio del rol para cada entorno:
cat > site.yml <<'YAML'
- name: Apply the shared role to canary
hosts: canary
gather_facts: true
become: true
roles:
- managed_site
- name: Apply the shared role to stable
hosts: stable
gather_facts: true
become: true
roles:
- managed_site
YAML
Valida y aplica ambos contextos:
ansible-playbook site.yml --syntax-check
ansible-playbook site.yml
Ambos entornos deberían cargar su configuración modificada mediante el handler local del rol. Inspecciona los destinos reales en sus nuevos puertos configurados:
ansible canary -m ansible.builtin.command -a 'curl --fail --silent --show-error -i http://127.0.0.1:8081/'
ansible stable -m ansible.builtin.command -a 'curl --fail --silent --show-error -i http://127.0.0.1:8082/'
Canary debería identificar web1 y development, con cabeceras DEVELOPMENT/enabled. Stable debería identificar web2 y production, con cabeceras PRODUCTION/disabled. Estas diferencias proceden de las entradas de grupo, mientras que un rol compartido sigue conteniendo los valores predeterminados, las tareas, las plantillas y los handlers.
Repite el mismo playbook consumidor:
ansible-playbook site.yml
Ambas filas del resumen deberían informar changed=0, unreachable=0 y failed=0, sin ningún handler programado. Un rol reutilizable debe invocarse y producir un estado administrado correcto y convergente; una estructura de directorios por sí sola no es un despliegue.
Resumen
Has organizado valores predeterminados, tareas, plantillas y handlers en un único rol invocado. Los valores predeterminados de baja precedencia permitieron que los consumidores los sobrescribieran, y dos grupos del inventario reutilizaron la misma implementación para producir servicios reales distintos. La validación de candidatos, las recargas activadas por cambios y la ejecución repetida sin cambios siguieron formando parte de la unidad reutilizable.
