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