Cómo utilizar los roles de Ansible para abstraer el entorno de infraestructura

Introducción

Índice
  1. Introducción
  • Prerrequisitos
  • ¿Qué es un rol de Ansible?
  • Creando un rol
  • Convertir un manual en un rol
    1. Creación del archivo main.yml de Tareas
    2. Creación del main.ymlarchivo Handlers
    3. Agregar archivos y plantillas
    4. El directorio Meta
    5. El directorio Vars
    6. Incluyendo otros archivos
  • Crear un manual básico
    1. Galaxia Ansible
  • Conclusión

    • Ansible es una herramienta de gestión de configuración diseñada para automatizar el control de servidores para administradores y equipos de operaciones. Con Ansible, puede utilizar un único servidor central para controlar y configurar muchos sistemas remotos diferentes utilizando SSH y Python como únicos requisitos.

    Ansible realiza tareas en servidores que administra en función de las definiciones de tareas. Estas tareas invocan módulos de Ansible integrados y mantenidos por la comunidad mediante pequeños fragmentos de YAML para cada tarea.

    A medida que la cantidad y variedad de sistemas que administra con un solo nodo de control de Ansible se vuelven más complejos, tiene sentido agrupar las tareas en playbooks de Ansible. El uso de playbooks elimina la necesidad de ejecutar muchas tareas individuales en sistemas remotos y, en cambio, le permite configurar entornos completos a la vez con un solo archivo.

    Sin embargo, los playbooks pueden volverse complejos cuando son responsables de configurar muchos sistemas diferentes con múltiples tareas para cada sistema, por lo que Ansible también le permite organizar las tareas en una estructura de directorio llamada Rol . En esta configuración, los playbooks invocan roles en lugar de tareas, por lo que aún puede agrupar tareas y luego reutilizar roles en otros playbooks. Los roles también le permiten recopilar plantillas, archivos estáticos y variables junto con sus tareas en un formato estructurado.

    En este tutorial, exploraremos cómo crear roles y cómo agregar plantillas, archivos estáticos y variables a un rol. Una vez que esté familiarizado con los conceptos básicos de la creación de roles, utilizaremos Ansible Galaxy para incorporar roles aportados por la comunidad en los playbooks. Al finalizar este tutorial, podrá crear sus propios roles específicos del entorno para sus servidores y utilizarlos en sus propios playbooks para administrar uno o varios sistemas.

    Prerrequisitos

    Para seguir este tutorial, deberá instalar y configurar Ansible para poder crear y ejecutar playbooks. También deberá comprender cómo escribir playbooks de Ansible.

    ¿Qué es un rol de Ansible?

    En los tutoriales de requisitos previos, aprendiste a ejecutar la herramienta principal de Ansible mediante el ansiblecomando en una terminal. También aprendiste a recopilar tareas en playbooks y ejecutarlas mediante el ansible-playbookcomando. El siguiente paso en la progresión de ejecutar comandos individuales, tareas y playbooks es reorganizar todo mediante un rol de Ansible.

    Los roles son un nivel de abstracción sobre las tareas y los playbooks que le permiten estructurar su configuración de Ansible en un formato modular y reutilizable. A medida que agrega más y más funcionalidad y flexibilidad a sus playbooks, pueden volverse difíciles de manejar y de mantener. Los roles le permiten dividir un playbook complejo en partes separadas y más pequeñas que se pueden coordinar mediante un punto de entrada central. Por ejemplo, en este tutorial, todo playbook.ymlcon lo que trabajaremos se ve así:

    Ejemplo de manual de estrategias

    1. ---
    2. - hosts: all
    3.   become: true
    4.   roles:
    5.     - apache
    6.   vars:
    7.     doc_root: /var/www/example

    El conjunto completo de tareas que se deben realizar para configurar un servidor web Apache estará contenido en el apacherol que crearemos. El rol definirá todas las tareas que se deben completar para instalar Apache, en lugar de enumerar cada tarea individualmente como hicimos en el requisito previo de Configuration Management 101: Writing Ansible Playbooks.

    Organizar la configuración de Ansible en roles le permite reutilizar los pasos de configuración comunes entre diferentes tipos de servidores. Si bien esto también es posible al incluir varios archivos de tareas en un solo playbook, los roles se basan en una estructura de directorio conocida y convenciones de nombres de archivo para cargar automáticamente los archivos que se usarán dentro del play.

    En general, la idea detrás de los roles es permitirle compartir y reutilizar tareas utilizando una estructura consistente, al mismo tiempo que facilita su mantenimiento sin duplicar tareas para toda su infraestructura.

    Creando un rol

    Para crear un rol de Ansible, necesitará una estructura de directorio diseñada específicamente. Los roles siempre necesitan este diseño de directorio para que Ansible pueda encontrarlos y usarlos.

    Suponemos que ha estado utilizando el directorio de inicio de su usuario como directorio de trabajo de Ansible. Si mantiene su configuración de Ansible en una ubicación diferente, deberá cambiar ( cd) a ese directorio.

    Para comenzar, vamos a crear un directorio llamado roles. Ansible buscará aquí cuando queramos usar nuestro nuevo rol en un libro de estrategias más adelante en este tutorial.

    1. cd ~
    2. mkdir roles
    3. cd roles

    Dentro de este directorio, definiremos roles que se pueden reutilizar en varios playbooks y diferentes servidores. Cada rol que crearemos requiere su propio directorio. Tomaremos el playbook de Apache de ejemplo del tutorial Configuration Management 101: Writing Ansible Playbooks y lo convertiremos en un rol reutilizable de Ansible.

    Como referencia, este es el manual de ese tutorial:

    libro de jugadas.yml

    1. ---
    2. - hosts: all
    3.   become: true
    4.   vars:
    5.     doc_root: /var/www/example
    6.   tasks:
    7.     - name: Update apt
    8.       apt: update_cache=yes
    10.     - name: Install Apache
    11.       apt: name=apache2 state=latest
    13.     - name: Create custom document root
    14.       file: path={{ doc_root }} state=directory owner=www-data group=www-data
    16.     - name: Set up HTML file
    17.       copy: src=index.html dest={{ doc_root }}/index.html owner=www-data group=www-data mode=0644
    19.     - name: Set up Apache virtual host file
    20.       template: src=vhost.tpl dest=/etc/apache2/sites-available/000-default.conf
    21.       notify: restart apache
    22.   
    23.   handlers:
    24.     - name: restart apache
    25.       service: name=apache2 state=restarted

    Primero, creemos un directorio Apache para nuestro rol y completémoslo con los directorios necesarios:

    1. mkdir apache
    2. cd apache

    A continuación, crearemos el conjunto de subdirectorios necesarios que le permitirán a Ansible saber que debe usar el contenido como una función. Cree estos directorios con el mkdircomando:

    1. mkdir defaults files handlers meta templates tasks vars

    Estos directorios contendrán todo el código para implementar nuestro rol. Muchos roles solo usarán uno o algunos de estos directorios, según la complejidad de las tareas involucradas. Cuando escriba sus propios roles, es posible que no necesite crear todos estos directorios.

    A continuación se muestra una descripción de lo que representa cada directorio:

    • defaults:Este directorio le permite configurar variables predeterminadas para roles incluidos o dependientes. Cualquier valor predeterminado que se configure aquí se puede anular en los libros de estrategias o archivos de inventario.
    • files:Este directorio contiene archivos estáticos y archivos de script que pueden copiarse o ejecutarse en un servidor remoto.
    • handlers:Todos los controladores que estaban anteriormente en su libro de jugadas ahora se pueden agregar a este directorio.
    • meta:Este directorio está reservado para metadatos de roles, generalmente utilizados para la gestión de dependencias... Por ejemplo, puede definir una lista de roles que deben aplicarse antes de invocar el rol actual.
    • templates:Este directorio está reservado para plantillas que generarán archivos en hosts remotos. Las plantillas suelen utilizar variables definidas en archivos ubicados en el varsdirectorio y en información del host que se recopila en tiempo de ejecución.
    • tasks: Este directorio contiene uno o más archivos con tareas que normalmente se definirían en la taskssección de un playbook de Ansible normal. Estas tareas pueden hacer referencia directamente a archivos y plantillas contenidos en sus respectivos directorios dentro del rol, sin necesidad de proporcionar una ruta completa al archivo.
    • vars:Las variables para un rol se pueden especificar en archivos dentro de este directorio y luego hacer referencia a ellas en otra parte del rol.

    Si un archivo llamado main.ymlexiste en un directorio, su contenido se agregará automáticamente al libro de estrategias que llama a la función. Sin embargo, esto no se aplica a los directorios filesy templates, ya que su contenido debe referenciarse explícitamente.

    Convertir un manual en un rol

    Ahora que está familiarizado con para qué se utiliza cada directorio en un rol de Ansible, convertiremos el libro de estrategias de Apache en un rol para organizar mejor las cosas.

    Ya deberíamos tener roles/apache2/{subdirectories}configurada la estructura de la última sección. Ahora, necesitamos crear algunos archivos YAML para definir nuestro rol.

    Creación del archivo main.yml de Tareas

    Comenzaremos con el subdirectorio de tareas. Vaya a ese directorio ahora:

    1. cd ~/roles/apache/tasks

    Necesitamos crear un main.ymlarchivo en este directorio. Lo llenaremos con todo el contenido del libro de estrategias de Apache y luego lo editaremos para que solo incluya tareas.

    1. nano main.yml

    El archivo debería verse así al comenzar:

    principal.yml

    1. ---
    2. - hosts: all
    3.   become: true
    4.   vars:
    5.     doc_root: /var/www/example
    7.   tasks:
    8.     - name: Update apt
    9.       apt: update_cache=yes
    11.     - name: Install Apache
    12.       apt: name=apache2 state=latest
    14.     - name: Create custom document root
    15.       file: path={{ doc_root }} state=directory owner=www-data group=www-data
    17.     - name: Set up HTML file
    18.       copy: src=index.html dest={{ doc_root }}/index.html owner=www-data group=www-data mode=0644
    20.     - name: Set up Apache virtual host file
    21.       template: src=vhost.tpl dest=/etc/apache2/sites-available/000-default.conf
    22.       notify: restart apache
    24.   handlers:
    25.     - name: restart apache
    26.       service: name=apache2 state=restarted

    Solo queremos conservar la primera ---línea y las líneas de la taskssección que están resaltadas. También podemos eliminar los espacios extraños a la izquierda de nuestras tareas. También agregaremos una nueva sección para habilitar un módulo Apache llamado modsecurityque configuraremos más adelante en este tutorial. Después de estos cambios, nuestro nuevo ~/roles/apache/tasks/main.ymlarchivo se verá así:

    principal.yml

    1. ---
    2. - name: Update apt
    3.   apt: update_cache=yes
    5. - name: Install Apache
    6.   apt: name=apache2 state=latest
    8. - name: Create custom document root
    9.   file: path={{ doc_root }} state=directory owner=www-data group=www-data
    11. - name: Set up HTML file
    12.   copy: src=index.html dest={{ doc_root }}/index.html owner=www-data group=www-data mode=0644
    14. - name: Set up Apache virtual host file
    15.   template: src=vhost.tpl dest=/etc/apache2/sites-available/000-default.conf
    16.   notify: restart apache

    Ahora el archivo de tareas es más fácil de seguir y comprender porque solo contiene los pasos reales que se realizarán cuando usemos el rol Apache.

    Observe cómo las líneas copyy templateusan src=index.htmly src=vhost.tplrespectivamente para hacer referencia a archivos en nuestro rol, sin ninguna ruta precedente. La estructura de directorios de nuestro rol permite hacer referencia a archivos y plantillas directamente por su nombre, y Ansible los encontrará automáticamente por nosotros.

    Asegúrese de guardar y cerrar el archivo cuando haya terminado de editarlo.

    Creación del main.ymlarchivo Handlers

    Ahora que tenemos la mayor parte del libro de estrategias en el tasks/main.ymlarchivo, necesitamos mover la sección de controladores a un archivo ubicado en handlers/main.yml.

    Primero cden el handlerssubdirectorio de nuestro rol:

    1. cd ~/roles/apache/handlers

    Nuevamente, abra el archivo en su editor de texto y pegue todo el contenido del original playbook.yml:

    1. nano main.yml

    Se resaltan nuevamente las partes que debemos conservar:

    libro de jugadas.yml

    1. ---
    2. - hosts: all
    3.   become: true
    4.   vars:
    5.     doc_root: /var/www/example
    6.   tasks:
    7.     - name: Update apt
    8.       apt: update_cache=yes
    10.     - name: Install Apache
    11.       apt: name=apache2 state=latest
    13.     - name: Create custom document root
    14.       file: path={{ doc_root }} state=directory owner=www-data group=www-data
    16.     - name: Set up HTML file
    17.       copy: src=index.html dest={{ doc_root }}/index.html owner=www-data group=www-data mode=0644
    19.     - name: Set up Apache virtual host file
    20.       template: src=vhost.tpl dest=/etc/apache2/sites-available/000-default.conf
    21.       notify: restart apache
    23.   handlers:
    24.     - name: restart apache
    25.     service: name=apache2 state=restarted

    Elimine también los espacios en blanco que se encuentran antes de los controladores. Al final, el archivo debería verse así:

    ---- name: restart apache  service: name=apache2 state=restarted

    Guarde y cierre el archivo cuando haya terminado.

    Agregar archivos y plantillas

    Ahora que tenemos las tareas y los controladores en su lugar, el siguiente paso es asegurarnos de que haya un index.htmlarchivo y una vhost.tplplantilla para que Ansible pueda encontrarlos y colocarlos en nuestros servidores remotos. Dado que hicimos referencia a estos archivos en el tasks/main.ymlarchivo, deben existir o Ansible no podrá ejecutar la función correctamente.

    Primero, crea el index.htmlarchivo en el ~/roles/apache/filesdirectorio:

    1. cd ~/roles/apache/files
    2. nano index.html

    Pegue lo siguiente en el editor, luego guárdelo y ciérrelo:

    htmlheadtitleConfiguration Management Hands On/title/headh1This server was provisioned using strongAnsible/strong/h1/html

    A continuación, editaremos la vhost.tplplantilla. Vaya al directorio de plantillas y edite el archivo con nano:

    1. cd ~/roles/apache/templates
    2. nano vhost.tpl

    Pegue estas líneas en el editor, luego guárdelo y ciérrelo:

    VirtualHost *:80ServerAdmin webmaster@localhostDocumentRoot {{ doc_root }}Directory {{ doc_root }}AllowOverride AllRequire all granted/Directory/VirtualHost

    El directorio Meta

    Si nuestro rol dependiera de otro rol, podríamos agregar un archivo en el metadirectorio llamado main.yml. Este archivo podría especificar que este rol depende de un rol llamado “apt”. En el rol Apache que hemos creado no requerimos ninguna dependencia. Sin embargo, en el caso hipotético de requerir otro rol como “apt”, el archivo en ~/roles/apache/meta/main.ymlpodría verse así:

    ---dependencies:  - apt

    Esto garantizaría que el rol "apt" se ejecute antes que nuestro rol Apache. Crear dependencias como esta es útil con roles más complejos que requieren que se instalen otros programas o configuraciones antes de ejecutar el rol real.

    El directorio Vars

    Dijimos anteriormente que existe un directorio “vars” que se puede usar para configurar variables para nuestro rol. Si bien es posible configurar parámetros predeterminados para un rol a través de un vars/main.ymlarchivo, esto no suele recomendarse para roles más pequeños.

    La razón por la que no se utiliza el directorio “vars” es que hace que los detalles de la configuración residan dentro de la jerarquía de roles. Un rol está compuesto principalmente por tareas y dependencias genéricas, mientras que las variables son datos de configuración. Si se combinan ambos, resulta más difícil reutilizar el rol en otro lugar.

    En cambio, es mejor especificar los detalles de configuración fuera del rol para poder compartirlo fácilmente sin preocuparse por exponer información confidencial. Además, las variables declaradas dentro de un rol se pueden anular fácilmente con variables en otras ubicaciones. Es mucho mejor colocar los datos de las variables en los playbooks que se usan para tareas específicas.

    Sin embargo, vale la pena mencionar el directorio “vars” porque es útil con roles más complejos. Por ejemplo, si un rol necesita admitir distintas distribuciones de Linux, especificar valores predeterminados para las variables puede ser útil para manejar distintos nombres de paquetes, versiones y configuraciones.

    Incluyendo otros archivos

    A veces, cuando creas roles con muchas tareas, dependencias o lógica condicional, se vuelven grandes y difíciles de entender. En situaciones como esta, puedes dividir las tareas en sus propios archivos e incluirlos en tu tasks/main.yml.

    Por ejemplo, si tuviéramos un conjunto adicional de tareas para configurar TLS para nuestro servidor Apache, podríamos separarlas en su propio archivo. Podríamos llamar al archivo tasks/tls.ymle incluirlo de esta manera tasks/main.yml:

    . . .tasks:- include: roles/apache/tasks/tls.yml

    Crear un manual básico

    Ahora que hemos configurado nuestra estructura de roles, podemos usarla con un manual mínimo en comparación con la versión monolítica del comienzo de este tutorial.

    El uso de roles de esta manera nos permite usar playbooks para declarar lo que un servidor debe hacer sin tener que repetir siempre la creación de tareas para lograrlo.

    Para crear un playbook mínimo que incluya nuestro rol de Apache, cddesde el directorio de roles (nuestro directorio de inicio en este ejemplo), ahora podemos crear un archivo de playbook:

    1. cd ~
    2. nano playbook.yml

    Una vez que tenga el archivo abierto, pegue lo siguiente, luego guarde y cierre el archivo:

    ---- hosts: all  become: true  roles:    - apache  vars:    - doc_root: /var/www/example

    En este archivo se requiere muy poca información. Primero, enumeramos los servidores en los que queremos ejecutar esta función, por lo que usamos - hosts: all. Si tuviera un grupo de hosts llamados , webserverspodría apuntar a ellos en su lugar. A continuación, declaramos las funciones que estamos usando. En este caso, solo hay una, por lo que usamos la - apachelínea .

    Este es nuestro manual completo. Es muy pequeño y se lee y comprende rápidamente. Mantener los manuales ordenados de esta manera nos permite concentrarnos en los objetivos generales para configurar servidores, en lugar de en la mecánica de las tareas individuales. Mejor aún, si tenemos múltiples requisitos de roles, ahora podemos enumerarlos en la rolessección de nuestro manual y se ejecutarán en el orden en que aparecen.

    Por ejemplo, si tuviéramos roles para configurar un servidor WordPress usando Apache y MySQL, podríamos tener un libro de estrategias que se vea así:

    ---- hosts: wordpress_hosts  become: true  roles:    - apache    - php    - mysql    - wordpress  vars:    - doc_root: /var/www/example

    Esta estructura de playbook nos permite ser muy concisos sobre cómo queremos que se vea un servidor. Finalmente, dado que los playbooks invocan roles, el comando para ejecutar el nuestro es exactamente el mismo que si todo estuviera en un solo archivo:

    1. ansible-playbook playbook.yml
    OutputPLAY [all] ******************************************************************************************TASK [Gathering Facts] ******************************************************ok: [64.225.15.1]TASK [apache : Update apt] **************************************************ok: [64.225.15.1]TASK [apache : Install Apache] **********************************************changed: [64.225.15.1]TASK [apache : Create custom document root] *********************************changed: [64.225.15.1]TASK [apache : Set up HTML file] ********************************************changed: [64.225.15.1]TASK [apache : Set up Apache virtual host file] *****************************changed: [64.225.15.1]RUNNING HANDLER [apache : restart apache] ***********************************changed: [64.225.15.1]PLAY RECAP ******************************************************************64.225.15.1              : ok=7    changed=5    unreachable=0    failed=0

    También puedes llamar al playbook.ymlarchivo apache.yml, por ejemplo, para que el nombre del archivo refleje los roles que contiene.

    Galaxia Ansible

    Un tutorial sobre los roles de Ansible no estaría completo sin explorar los recursos disponibles a través de Ansible Galaxy. Galaxy es un repositorio de roles aportados por los usuarios que se pueden agregar a los playbooks para realizar diversas tareas sin tener que escribirlas usted mismo.

    Por ejemplo, podemos agregar un módulo Apache útil llamado mod_security2a nuestro playbook para configurar Apache con algunas configuraciones de seguridad adicionales. Usaremos un rol de Ansible Galaxy llamado apache_modsecurity. Para usar este rol, lo descargaremos localmente y luego lo incluiremos en nuestro playbook.

    En primer lugar, familiaricémonos con la ansible-galaxyherramienta. Buscaremos en la galaxia con ella y luego elegiremos un rol de la lista que nos devuelve nuestro comando de búsqueda:

    1. ansible-galaxy search "PHP for RedHat/CentOS/Fedora/Debian/Ubuntu"

    El comando de búsqueda generará algo como lo siguiente:

    OutputFound 21 roles matching your search: Name                            Description ----                            ----------- alikins.php                     PHP for RedHat/CentOS/Fedora/Debian/Ubuntu. bpresles.php                    PHP for RedHat/CentOS/Fedora/Debian/Ubuntu. entanet_devops.ansible_role_php PHP for RedHat/CentOS/Fedora/Debian/Ubuntu. esperdyne.php                   PHP for RedHat/CentOS/Fedora/Debian/Ubuntu. fidanf.php                      PHP for RedHat/CentOS/Fedora/Debian/Ubuntu. frogasia.ansible-role-php       PHP for RedHat/CentOS/Fedora/Debian/Ubuntu. geerlingguy.php                 PHP for RedHat/CentOS/Fedora/Debian/Ubuntu. icamys.php                      PHP for RedHat/CentOS/Fedora/Debian/Ubuntu. jhu-sheridan-libraries.php      PHP for RedHat/CentOS/Fedora/Debian/Ubuntu. jibsan94.ansible_php            PHP for RedHat/CentOS/Fedora/Debian/Ubuntu. KAMI911.ansible_role_php        PHP for RedHat/CentOS/Fedora/Debian/Ubuntu. monsieurbiz.geerlingguy_php     PHP for RedHat/CentOS/Fedora/Debian/Ubuntu. nesh-younify.ansible-role-php   PHP for RedHat/CentOS/Fedora/Debian/Ubuntu. net2grid.php                    PHP for RedHat/CentOS/Fedora/Debian/Ubuntu. thom8.ansible-role-php          PHP for RedHat/CentOS/Fedora/Debian/Ubuntu. v0rts.php                       PHP for RedHat/CentOS/Fedora/Debian/Ubuntu. vahubert.php                    PHP for RedHat/CentOS/Fedora/Debian/Ubuntu. Vaizard.mage_php                PHP for RedHat/CentOS/Fedora/Debian/Ubuntu. viasite-ansible.php             PHP for RedHat/CentOS/Fedora/Debian/Ubuntu. vvgelder.ansible-role-php       PHP for RedHat/CentOS/Fedora/Debian/Ubuntu.(END)

    Ansible utilizará el lesscomando para mostrar los resultados de la búsqueda si hay muchos resultados, lo que bloqueará su terminal hasta que presione qpara salir. Esto es útil cuando los resultados de la búsqueda son extensos y necesita paginarlos, lo que puede hacer presionando space.

    Elegiremos el rol geerlingguy.phppara nuestro manual. Si desea leer más sobre los roles que aparecen en los resultados de búsqueda, puede visitar la página de búsqueda de Galaxy y pegar el nombre del rol sobre el que desea obtener más información.

    Para descargar un rol para usar en nuestro libro de jugadas, usamos el ansible-galaxy installcomando:

    1. ansible-galaxy install geerlingguy.php

    Cuando ejecutes ese comando deberías ver un resultado como este:

    Output- downloading role 'php', owned by geerlingguy- downloading role from https://github.com/geerlingguy/ansible-role-php/archive/3.7.0.tar.gz- extracting geerlingguy.php to /home/sammy/.ansible/roles/geerlingguy.php- geerlingguy.php (3.7.0) was installed successfully

    Ahora podemos agregar el rol a nuestro playbook.ymlarchivo:

    ---- hosts: all  become: true  roles:    - apache    - geerlingguy.php  vars:    - doc_root: /var/www/example    - php_default_version_debian: "7.2"

    Al colocar el rol después del nuestro apache, nos aseguramos de que Apache esté instalado y configurado en sistemas remotos antes de cualquier configuración para el geerlingguy.phprol. También podríamos incluir los roles mysqly wordpressen cualquier orden que elijamos según cómo queramos que se comporten los servidores remotos.

    Al ejecutar ansible-playbook playbook.ymlel rol Galaxy agregado, se obtendrá un resultado como el siguiente:

    OutputPLAY [all] *********************************************************************TASK [Gathering Facts] *********************************************************ok: [64.225.15.1]TASK [apache : Update apt] *****************************************************changed: [64.225.15.1]TASK [apache : Install Apache] *************************************************changed: [64.225.15.1]TASK [apache : Install modsecurity] ********************************************changed: [64.225.15.1]TASK [apache : Create custom document root] ************************************changed: [64.225.15.1]TASK [apache : Set up HTML file] ***********************************************changed: [64.225.15.1]TASK [apache : Set up Apache virtual host file] ********************************changed: [64.225.15.1]TASK [geerlingguy.php : Include OS-specific variables.] ************************ok: [64.225.15.1]TASK [geerlingguy.php : Define php_packages.] **********************************ok: [64.225.15.1]. . .PLAY RECAP *********************************************************************64.225.15.1                : ok=37   changed=15   unreachable=0    failed=0(END)

    Conclusión

    Los roles de Ansible son una excelente manera de estructurar y definir cómo deberían verse sus servidores. Vale la pena aprender a usarlos incluso si pudiera confiar únicamente en los playbooks para cada uno de sus servidores. Si planea usar Ansible de manera extensiva, los roles mantendrán su configuración a nivel de host separada de su tarea y garantizarán que su código de Ansible esté limpio y sea legible. Lo más importante es que los roles le permiten reutilizar y compartir código fácilmente, e implementar sus cambios de manera controlada y modular.

    SUSCRÍBETE A NUESTRO BOLETÍN 
    No te pierdas de nuestro contenido ni de ninguna de nuestras guías para que puedas avanzar en los juegos que más te gustan.
    Al suscribirte, aceptas nuestra política de privacidad y nuestros términos de servicio.

    Tal vez te puede interesar:

    1. Cómo agregar efectos de sonido a tus aplicaciones React
    2. Cómo utilizar el modo independiente de Certbot para recuperar certificados SSL de Let's Encrypt en Debian 10
    3. Cómo instalar el servidor web Apache en Debian 10
    4. Obtención de datos de ubicación con Ionic 4 y Capacitor

    Deja una respuesta

    Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

    Subir

    Este sitio web utiliza cookies para mejorar tu experiencia mientras navegas por él. Este sitio web utiliza cookies para mejorar tu experiencia de usuario. Al continuar navegando, aceptas su uso. Mas informacion