Elija entre los módulos de copia y plantilla de Ansible

Cuando se trata de transferir archivos a un sistema remoto con Ansible, el copy y template Los módulos son excelentes herramientas para el trabajo. Se puede hacer mucho en Linux usando archivos simples. La copia de archivos de configuración esenciales en servidores remotos es un gran caso de uso para aquellos que recién comienzan su viaje a Ansible. Este artículo presenta algunas de las mejores prácticas para elegir entre Ansible copy y template módulos.

Antes de comenzar, déjame mostrarte la estructura de directorios que estoy usando para este tutorial para que puedas seguirlo:

$ tree
.
├── copy.yml
├── files
│   └── etc
│       └── motd
├── inventory.yml
├── templates
│   └── etc
│       └── keepalived
│           └── keepalived.conf.j2
└── template.yml

5 directories, 5 files

Estoy ejecutando estos playbooks contra un solo host como se muestra en mi archivo de inventario a continuación:

$ cat inventory.yml
nyc1-webserver-1.example.com
Índice

El módulo de copia

Ansible copy módulo hace exactamente lo que espera: copia un archivo del host local a un servidor remoto. el copy El módulo es fácil de usar y requiere poca explicación:

---
- hosts: nyc1-webserver-1.example.com
  gather_facts: no
  tasks:
    - name: Copy MOTD into place
      copy:
        dest: /etc/motd
        src: etc/motd
        owner: root
        group: root
        mode: 0644

Después de ejecutar mi libro de jugadas de Ansible con ansible-playbook -i inventory.yml copy.yml, tengo una actualización motd archivo en el sistema remoto:

[email protected]:~# cat /etc/motd 
This is an MOTD added via Ansible

el copy El módulo es perfecto para archivos que siempre son consistentes en todos sus sistemas. He aquí algunos ejemplos :

  • Inicio de sesión banners y mensajes del día (motd)
  • Archivos de configuración de aplicaciones básicas que nunca varían entre sistemas, como un archivo de configuración SSH que desea mantener constante
  • Un archivo de aplicación binario que desea copiar exactamente desde su sistema local a sistemas remotos

Si está utilizando la administración de código fuente, como Git, para sus playbooks de Ansible, asegúrese de que todos los archivos administrados por el copy módulo son adecuados para poner en el código fuente. Nunca debe usar una herramienta como Git para almacenar archivos que contengan información confidencial, como contraseñas o datos privados.

El módulo modelo

el template módulo también copia un archivo a un servidor remoto, pero le permite usar Jinja2 para representar dinámicamente un modelo en un archivo. Esto le permite usar variables, como hechos de Ansible, para personalizar un archivo en particular para un servidor específico. Esto puede sonar confuso para el nuevo usuario de Ansible, así que lo desglosaré un poco a través de un ejemplo.

El libro de jugadas a continuación instala y configura keepalived. Si ha leído mi serie anterior sobre la alta disponibilidad de Linux, ya sabe el propósito de keepalived. Si no lo eres, no te preocupes. Solo sepa que el libro de jugadas a continuación instala el keepalived aplicación y escribe un archivo de configuración necesario:

---
- hosts: nyc1-webserver-1.example.com
  gather_facts: yes
  vars:
    keepalived_priority: 100
    keepalived_state: MASTER
    keepalived_vip: 192.168.1.1
    keepalived_vrid: 10
    keepalived_vrrp_instance_name: "HA_10"
  tasks:
    - name: Install Keepalived
      package:
        name: keepalived
        state: present

    - name: Add Keepalived config file
      template:
        dest: /etc/keepalived/keepalived.conf
        src: etc/keepalived/keepalived.conf.j2
      notify: Restart Keepalived

  handlers:
    - name: Restart Keepalived
      service:
        name: keepalived
        state: restarted

El archivo fuente se almacena en templates/etc/keepalived/keepalived.conf.j2. Ansible es lo suficientemente inteligente como para buscar automáticamente modelos en ubicaciones específicas conocidas, como templates/, por lo que no tiene que preocuparse por escribir la ruta completa. Este camino contiene el keepalived archivo de configuración. El archivo usa el sufijo .j2 para que sepa que es un modelo Jinja2.

Tenga en cuenta que la sintaxis de Jinja2 se utiliza para hacer referencia a los dos hechos integrados de Ansible (ansible_default_ipv4['interface']) y variables (keepalived_state) que se proporcionan a través de la vars clave en el libro de jugadas YAML:

vrrp_instance {{ keepalived_vrrp_instance_name }} {
  interface                 {{ ansible_default_ipv4['interface'] }}
  state                     {{ keepalived_state }}
  virtual_router_id         {{ keepalived_vrid }}
  priority                  {{ keepalived_priority }}

  virtual_ipaddress {
    {{ keepalived_vip }} dev {{ ansible_default_ipv4['interface'] }} label {{ ansible_default_ipv4['interface'] }}:VIP
  }
}

Una vez que ejecuta este libro de jugadas a través de ansible-playbook -i inventory.yml template.yml, el archivo de destino en el sistema remoto tendrá un archivo de configuración completo, con todas las variables rellenadas, en /etc/keepalived/keepalived.conf:

[email protected]:~# cat /etc/keepalived/keepalived.conf 
vrrp_instance HA_10 {
  interface                 ens3
  state                     MASTER
  virtual_router_id         10
  priority                  100

  virtual_ipaddress {
    192.168.1.1 dev ens3 label ens3:VIP
  }
}

Las plantillas de Jinja2 son una forma muy eficaz de representar archivos personalizados en hosts (o grupos de hosts, si desea utilizar variables de grupo que se aplican a varios hosts). Este es solo un ejemplo básico. Los modelos complejos que utilizan bucles y lógica avanzada son posibles con Jinja2, como se describe en el Documentación.

Que elegir ?

Entonces, ¿cuándo usarías el template módulo en lugar de copy ¿módulo? Personalmente, encuentro que uso el template modula la mayor parte del tiempo. Casi siempre hay algo en un archivo de configuración que debe personalizarse host por host. Aquí hay algunos ejemplos concretos:

  • Archivos de configuración de aplicaciones con contenido dinámico, como el bloque de servidor NGINX del que hablé en mi artículo anterior sobre Ansible para servidores web.
  • Configuraciones que pueden necesitar renderizarse un número arbitrario de veces según las variables del host o del grupo. Por ejemplo, puede configurar dinámicamente varios parámetros de Filebeat en función de las rutas de los archivos de registro pasadas como variables. No todos los servidores tienen las mismas rutas de archivo de registro, por lo que las plantillas son la solución ideal para la personalización por host.
  • Archivos que contienen datos confidenciales que no deben almacenarse en el control de código fuente. Incluso puedes usar Bóveda de Ansible para almacenar el secreto y hacerlo dinámicamente con Jinja2.

Utilizando el template El módulo es una excelente manera de habilitar la reutilización en sus libros de jugadas. Sus libros de jugadas están muy extendidos porque no contienen información específica del host y, por lo tanto, son portátiles entre diferentes hosts, proyectos o incluso negocios. Recuerde: ¡siempre intente escribir código que pueda reutilizarse!

Pensamientos finales

Antes de dejarlos, me gustaría referirme a dos aspectos de mis libros de jugadas que quizás hayan notado. En primer lugar, estoy usando una estructura de directorio de ruta completa para el origen de los archivos y modelos (por ejemplo, templates/etc/keepalived/keepalived.conf.j2) en lugar de simplemente incluir todos los archivos en el directorio raíz (por ejemplo, templates/keepalived.conf.j2). Es un buen hábito a tomar. Si bien esto puede hacer que su árbol de directorios sea más grande, hace que el destino de un archivo o plantilla sea inmediatamente obvio sin tener que leer el código del libro de jugadas.

Probablemente también haya notado que la sintaxis es casi idéntica para el copy y template módulos. Esto hace que sea más fácil intercambiar uno por el otro a medida que cambian sus necesidades. Puede comenzar copiando una configuración de aplicación estática en todos los servidores de su entorno. A medida que continúe desarrollando sus capacidades de automatización, es posible que descubra que hay partes de esta configuración que deben personalizarse por host. Puede reemplazar fácilmente el Copiar clave para el modelo introduzca su libro de jugadas y disfrute de la flexibilidad que ofrece el lenguaje de plantilla Jinja2.

El dicho de que "todo es un archivo en Linux" generalmente es cierto, lo que hace que la administración de archivos sea una de las tareas más críticas que puede automatizar con herramientas como Ansible. En este artículo, ha aprendido los conceptos básicos de copy y template módulos, incluidos algunos casos de uso para cada uno. Equipado con esta información, puede comenzar a escribir playbooks de Ansible potentes y flexibles para administrar archivos en su entorno.

Artículos de interés

Subir