Configuración de DNS con Ansible | Activar administrador del sistema

Para aprovisionar nuevas máquinas virtuales Linux con una configuración de DNS funcional adecuada para nuestro entorno, creé el pequeño rol ansible resolv.conf, que me gustaría presentar a continuación.

Índice

    El papel resolv.conf

    Este rol es minimalista y solo incluye los directorios y archivos requeridos:

    # tree roles/resolv.conf
    roles/resolv.conf/
    ├── handlers
    │   └── main.yml
    ├── tasks
    │   └── main.yml
    └── templates
        └── resolv.conf.j2
    

    tasks/main.yml

    Para poder gestionar el archivo /etc/resolv.conf con Ansible, primero tuve que detener el NetworkManager de hacerlo. Para esta tarea, utilicé el módulo Ansible. ini_file, que establece la opción requerida dns=none en categoría [main]:

    ---
    - name: make sure line 'dns=none' is set in /etc/NetworkManager/NetworkManager.conf
      ini_file:
        path: /etc/NetworkManager/NetworkManager.conf
        state: present
        no_extra_spaces: yes
        section: main
        option: dns
        value: none
        owner: root
        group: root
        mode: 0644
        backup: yes
      notify:
        - reload NetworkManager

    La segunda tarea utiliza el módulo modelo para crear la configuración de destino a partir del contenido de roles/resolv.conf/templates/resolv.conf.j2, y colóquelo en /etc/resolv.conf en el nodo de destino:

    ---
    - name: deploy resolv.conf template
      template:
        src: roles/resolv.conf/templates/resolv.conf.j2
        dest: /etc/resolv.conf
        owner: root
        group: root
        mode: 0644
        backup: yes
      notify:
        - reload NetworkManager
    

    Actualmente mi plantilla contiene texto estático. Podría haber usado el módulo de copia para copiar este archivo en el nodo de destino. Sin embargo, usé el módulo de plantilla para ahorrarme la capacidad de crear el contenido dinámicamente usando variables.

    Con notify: un gerente designado reload NetworkManager se llama dos veces en este libro de jugadas. Cubriré a los gerentes en la siguiente sección.

    handlers/main.yml

    Gerentes se utilizan para desencadenar acciones que se ejecutan solo si una tarea realiza cambios en el nodo de destino. Estos controladores solo se procesan al final de un libro de jugadas y solo se ejecutan una vez, incluso si varias tareas les han notificado los cambios.

    En el ejemplo descrito en este texto, el controlador llamado reload NetworkManager ejecuta la tarea definida, pero solo si una de las dos tareas (o ambas) de tasks/main.yml provocó un cambio en el nodo de destino:

    # cat resolv.conf/handlers/main.yml
    ---
    - name: reload NetworkManager
      service:
        name: NetworkManager
        state: reloaded
    

    Tenga en cuenta que los controladores no se ejecutan hasta que todas las tareas se hayan procesado correctamente. En algunos casos, este hecho puede dificultar la resolución de problemas. Encontré un ejemplo en el libro, de Rene Moser y Lorin Hochstein, que me gustaría compartir aquí. Imagina el siguiente procedimiento:

    1. Estás ejecutando un libro de jugadas.
    2. Una de las tareas utiliza la notificación de cambios.
    3. En una tarea posterior, se produce un error que hace que se cancele el procesamiento.
    4. Solucionas el problema y relanzas el libro de jugadas.

    La tarea de la segunda etapa ya ha realizado sus cambios con éxito. Cuando el libro de jugadas se vuelva a ejecutar, su estado será, por lo tanto, OK y no CHANGED. Sin embargo, el controlador no se ejecutó porque el procesamiento se canceló antes de este punto. El controlador no se activará cuando se vuelva a ejecutar el libro de jugadas, porque la tarea requerida ya no provoca cambios en el nodo de destino.

    Hochstein escribe que los controladores se utilizan principalmente para reiniciar servicios o recargar su configuración. Por supuesto, esto también se puede lograr sin el uso de controladores reiniciando explícitamente un servicio al final del libro de jugadas. Cuál es la mejor manera, cada uno decide por sí mismo.

    Conclusión

    Fue uno de mis primeros roles en Ansible. Si esta es la forma más inteligente de crear la configuración de DNS o si existen enfoques aún más elegantes, no lo sé. Al menos esta solución parece ser robusta y aún no me ha defraudado.

    Artículos de interés

    Deja una respuesta

    Tu dirección de correo electrónico no será publicada.

    Subir