RHCE ansible Serie # 6: toma de decisiones a ansible

¿Cómo estais? me llamo Kiko. Os traigo un nuevo post sobre el sistema operativo mas molón. Un placer linuxeros.

En este tutorial, aprenderá a añadir habilidades de toma de decisiones en sus libros de juego ansible.

Aprenderás a:

  • uso cuando instrucciones para ejecutar tareas de forma condicional.
  • uso bloque declaraciones para implementar el tratamiento de excepciones.
  • Utilice ansible manipuladores para activar tareas después del cambio.

Por supuesto, debería familiarizarse con los libros de juego ansible, las órdenes ad-hoc y otros conceptos básicos de ansible para entender este tutorial. Puede seguir el capítulo anterior de esta serie ansible de RHCE.

Este tutorial sigue la misma configuración que se mencionó en el primer capítulo de esta serie: 1 control de Red Hat, 3 nodos CentOS y 1 nodo Ubuntu.

Elegir cuando ejecutar tareas

Empezamos a poner condiciones a la hora de ejecutar una tarea determinada con ansible.

Utilizando cuando con hechos

Puedes utilizar cuando condicionales para ejecutar una tarea sólo cuando una condición determinada es cierta. Para demostrarlo, cree un nuevo libro de juego llamado ubuntu-server.yml que tiene el siguiente contenido:

[elliot@control plays]$ cat ubuntu-server.yml 
---
- name: Using when with facts 
  hosts: all
  tasks:
    - name: Detect Ubuntu Servers
      debug:
        msg: "This is an Ubuntu Server."
      when:  ansible_facts['distribution'] == "Ubuntu"

Ahora, adelante, ejecute el libro de reproducción:

[elliot@control plays]$ ansible-playbook ubuntu-servers.yml 

PLAY [Using when with facts] *******************************************

TASK [Gathering Facts] *********************************************************
ok: [node4]
ok: [node1]
ok: [node3]
ok: [node2]

TASK [Detect Ubuntu Servers] ***************************************************
skipping: [node1]
skipping: [node2]
skipping: [node3]
ok: [node4] => 
    "msg": "This is an Ubuntu Server."


PLAY RECAP *********************************************************************
node1                      : ok=1    changed=0    unreachable=0    failed=0    skipped=1    

node2                      : ok=1    changed=0    unreachable=0    failed=0    skipped=1    
node3                      : ok=1    changed=0    unreachable=0    failed=0    skipped=1    
node4                      : ok=2    changed=0    unreachable=0    failed=0    skipped=0   

Fíjese en cómo he usado el hecho ansible ansible_facts['distribution'] el cuando condición para probar qué nodos ejecutan Ubuntu. Tenga en cuenta también que no es necesario que rodean variables con corchetes cuando se utiliza cuando condicionantes.

A la salida del libro de reproducción, observe cómo TASK [Detect Ubuntu Servers] se saltaron los tres primeros nodos, ya que todos ejecutan CentOS y sólo se ejecutaron al nodo4, ya que está ejecutando Ubuntu.

Utilizando cuando con registros

También se puede utilizar cuando se trata de condicionales con variables registradas. Por ejemplo, el siguiente libro de juego centos-servers.yml revelará qué nodos están ejecutando CentOS:

[elliot@control plays]$ cat centos-servers.yml 
---
- name: Using when with registers
  hosts: all
  tasks:
    - name: Save the contents of /etc/os-release
      command: cat /etc/os-release
      register: os_release

    - name: Detect CentOS Servers
      debug:
        msg: "Running CentOS ..."
      when: os_release.stdout.find('CentOS') != -1

El libro de reproducción comienza primero guardando el contenido del archivo / Etc / os-release archivo al archivo alliberament_os registro. A continuación, la segunda tarea muestra el mensaje «Ejecutando CentOS …» sólo si la palabra ‘CentOS‘Se encuentra en alliberament_os salida estándar.

Siga adelante y ejecute el libro de reproducción:

[elliot@control plays]$ ansible-playbook centos-servers.yml 

PLAY [Using when with registers] ***********************************************

TASK [Gathering Facts] *********************************************************
ok: [node4]
ok: [node1]
ok: [node3]
ok: [node2]

TASK [Save the contents of /etc/os-release] ************************************
changed: [node4]
changed: [node1]
changed: [node2]
changed: [node3]

TASK [Detect CentOS Servers] ***************************************************
ok: [node1] => 
    "msg": "Running CentOS ..."

ok: [node2] => 
    "msg": "Running CentOS ..."

ok: [node3] => 
    "msg": "Running CentOS ..."

skipping: [node4]

PLAY RECAP *********************************************************************
node1                      : ok=3    changed=1    unreachable=0    failed=0    skipped=0    
node2                      : ok=3    changed=1    unreachable=0    failed=0    skipped=0    
node3                      : ok=3    changed=1    unreachable=0    failed=0    skipped=0    
node4                      : ok=2    changed=1    unreachable=0    failed=0    skipped=1    

Fíjese en cómo TASK [Detect CentOS Servers] sólo funcionó a los tres primeros nodos y saltarse el nodo4 (Ubuntu).

Probando varias condiciones con cuando

También puede probar varias condiciones al mismo tiempo mediante los operadores lógicos. Por ejemplo, el siguiente reinicio-centos8.yml PlayBook utiliza el lógico y operador para reiniciar servidores que ejecutan CentOS versión 8:

[elliot@control plays]$ cat reboot-centos8.yml 
---
- name: Reboot Servers
  hosts: all
  tasks:
    - name: Reboot CentOS 8 servers
      reboot: 
        msg: "Server is rebooting ..."
      when: ansible_facts['distribution'] == "CentOS" and ansible_facts['distribution_major_version'] == "8"

También puede utilizar el lógico o bien operador para ejecutar una tarea si alguna de las condiciones es cierta. Por ejemplo, la tarea siguiente reiniciaría los servidores que ejecutan CentOS o bien sombrero rojo:

  tasks:
    - name: Reboot CentOS and RedHat Servers 
      reboot: 
        msg: "Server is rebooting ..."
      when: ansible_facts['distribution'] == "CentOS" or ansible_facts['distribution'] == "RedHat"

Utilizando cuando con bucles

Si combina un cuando declaración condicional con a bucle, Ansible probaría la condición de cada elemento del bucle por separado.

Por ejemplo, el siguiente print-even.yml PlayBook imprimirá todos los números pares del archivo rango (1,11):

[elliot@control plays]$ cat print-even.yml
---
- name: Print Some Numbers
  hosts: node1
  tasks:
    - name: Print Even Numbers
      debug:
        msg: Number  item  is Even.
      loop: " range(1,11) "
      when: item % 2 == 0

Siga adelante y ejecute el libro de reproducción para ver la lista de todos los números pares de rango (1,11):

[elliot@control plays]$ ansible-playbook print-even.yml

PLAY [Print Some Numbers] **********************************

TASK [Gathering Facts] ****************************
ok: [node1]

TASK [Print Even Numbers] ******************************
skipping: [node1] => (item=1) 
ok: [node1] => (item=2) => 
    "msg": "Number 2 is Even."

skipping: [node1] => (item=3) 
ok: [node1] => (item=4) => 
    "msg": "Number 4 is Even."

skipping: [node1] => (item=5) 
ok: [node1] => (item=6) => 
    "msg": "Number 6 is Even."

skipping: [node1] => (item=7) 
ok: [node1] => (item=8) => 
    "msg": "Number 8 is Even."

skipping: [node1] => (item=9) 
ok: [node1] => (item=10) => 
    "msg": "Number 10 is Even."


PLAY RECAP ***********************************
node1                      : ok=2    changed=0    unreachable=0    failed=0    skipped=0

Utilizando cuando con variables

También puede utilizar cuando declaraciones condicionales con sus propias variables definidas. Tenga en cuenta que los condicionantes requieren entradas booleanas; es decir, una prueba se evaluará a true para activar la condición y, por tanto, deberá utilizar el archivo bool filtro con variables no booleanas.

Para demostrarlo, mirad el siguiente isfree.yml libro de juegos:

[elliot@control plays]$ cat isfree.yml 
---
- name: 
  hosts: node1
  vars:
    weekend: true
    on_call: "no"
  tasks:
    - name: Run if "weekend" is true and "on_call" is false
      debug:
        msg: "You are free!"
      when: weekend and not on_call | bool

Tenga en cuenta que he utilizado el archivo bool filtre aquí para convertir el archivo de guardia valor a su equivalente booleano (no -> falso).

Además, debe ser bien conscientes de ello no es falso es cierto y por tanto, toda la condición se valorará como verdadero en este caso; usted es libre!

También puede probar si se ha establecido una variable o no; por ejemplo, la siguiente tarea sólo se ejecutará si el archivo coche variable se define:

tasks:
    - name: Run only if you got a car
      debug:
        msg: "Let's go on a road trip ..."
      when: car is defined

La tarea siguiente utiliza el archivo fracasar falla si el archivo claves la variable no está definida:

tasks:
    - name: Fail if you got no keys
      fail:
        msg: "This play require some keys"
      when: keys is undefined

Gestión de excepciones con bloques

Hablamos de manejar excepciones.

Agrupación de tareas con bloques

Puede utilizar bloques para agrupar las tareas relacionadas. Para demostrarlo, mirad el siguiente install-apache.yml libro de juegos:

[elliot@control plays]$ cat install-apache.yml 
---
- name: Install and start Apache Play
  hosts: webservers
  tasks:
    - name: Install and start Apache
      block:
         - name: Install httpd
           yum:
             name: httpd
             state: latest

         - name: Start and enable httpd
           service:
             name: httpd
             state: started
             enabled: yes

    - name: This task is outside the block
      debug:
        msg: "I am outside the block now ..."

El libro de reproducción se ejecuta a servidores web group hosts y tiene un blog con el nombre Install and start Apache que incluye dos tareas:

  1. Instalación httpd
  2. Inicie y active httpd

La primera tarea Install httpd utiliza el archivo yum para instalar el paquete apache httpd. La segunda tarea Start and enable httpd utiliza el archivo servicio para iniciar el módulo y activar httpd para arrancar.

Tenga en cuenta que el libro de juego tiene una tercera tarea que no pertenece al archivo Install and start Apache bloque.

Ahora siga adelante y ejecute el libro de reproducción para instalar e iniciar httpd al servidores web nodos:

[elliot@control plays]$ ansible-playbook install-apache.yml 

PLAY [Install and start Apache Play] *******************************************

TASK [Gathering Facts] *********************************************************
ok: [node3]
ok: [node2]

TASK [Install httpd] ***********************************************************
changed: [node2]
changed: [node3]

TASK [Start and enable httpd] **************************************************
changed: [node3]
changed: [node2]

TASK [This task is outside the block] ******************************************
ok: [node2] => 
    "msg": "I am outside the block now ..."

ok: [node3] => 
    "msg": "I am outside the block now ..."


PLAY RECAP *********************************************************************
node2                      : ok=4    changed=2    unreachable=0    failed=0    skipped=0     
node3                      : ok=4    changed=2    unreachable=0    failed=0    skipped=0

También puede hacer un seguimiento con una orden ad-hoc para verificarlo httpd de hecho, está en funcionamiento:

[elliot@control plays]$ ansible webservers -m command -a "systemctl status httpd"
node3 | CHANGED | rc=0 >>
● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
   Active: active (running) since Tue 2020-11-03 19:35:13 UTC; 1min 37s ago
     Docs: man:httpd.service(8)
 Main PID: 47122 (httpd)
   Status: "Running, listening on: port 80"
    Tasks: 213 (limit: 11935)
   Memory: 25.1M
   CGroup: /system.slice/httpd.service
           ├─47122 /usr/sbin/httpd -DFOREGROUND
           ├─47123 /usr/sbin/httpd -DFOREGROUND
           ├─47124 /usr/sbin/httpd -DFOREGROUND
           ├─47125 /usr/sbin/httpd -DFOREGROUND
           └─47126 /usr/sbin/httpd -DFOREGROUND

Nov 03 19:35:13 node3 systemd[1]: Starting The Apache HTTP Server...
Nov 03 19:35:13 node3 systemd[1]: Started The Apache HTTP Server.
Nov 03 19:35:13 node3 httpd[47122]: Server configured, listening on: port 80
node2 | CHANGED | rc=0 >>
● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
   Active: active (running) since Tue 2020-11-03 19:35:13 UTC; 1min 37s ago
     Docs: man:httpd.service(8)
 Main PID: 43695 (httpd)
   Status: "Running, listening on: port 80"
    Tasks: 213 (limit: 11935)
   Memory: 25.1M
   CGroup: /system.slice/httpd.service
           ├─43695 /usr/sbin/httpd -DFOREGROUND
           ├─43696 /usr/sbin/httpd -DFOREGROUND
           ├─43697 /usr/sbin/httpd -DFOREGROUND
           ├─43698 /usr/sbin/httpd -DFOREGROUND
           └─43699 /usr/sbin/httpd -DFOREGROUND

Nov 03 19:35:13 node2 systemd[1]: Starting The Apache HTTP Server...
Nov 03 19:35:13 node2 systemd[1]: Started The Apache HTTP Server.
Nov 03 19:35:13 node2 httpd[43695]: Server configured, listening on: port 80

Fracaso de manipulación con bloques

También puede utilizar bloques para gestionar errores de tareas mediante el archivo rescate y siempre secciones. Esto es casi similar al tratamiento de excepciones en lenguajes de programación como el intentar atrapar a Java o probarlo excepto dentro Python.

Puede utilizar el archivo rescate sección para incluir todas las tareas que desee ejecutar en caso de que una o más tareas a bloque ha fallado.

Para demostrarlo, hacemos un vistazo al ejemplo siguiente:

tasks:
  - name: Handling error example
    block:
      - name: run a command
        command: uptime

      - name: run a bad command
        command: blabla

      - name: This task will not run
        debug:
          msg: "I never run because the above task failed."

    rescue: 
      - name: Runs when the block failed
        debug:
          msg: "Block failed; let's try to fix it here ..."

Fíjese en la segunda tarea del bloque run a bad command genera un error y, a su vez, la tercera tarea del bloque nunca tiene la oportunidad de ejecutarse. Las tareas dentro del archivo rescate La sección se ejecutará porque la segunda tarea del bloque ha fallado.

También puede utilizar ignore_errors: sí para asegurarse de que ansible continúe ejecutando las tareas del libro de reproducción incluso si una tarea ha fallado:

tasks:
  - name: Handling error example
    block:
      - name: run a command
        command: uptime

      - name: run a bad command
        command: blabla
        ignore_errors: yes

      - name: This task will run
        debug:
          msg: "I run because the above task errors were ignored."

    rescue: 
      - name: This will not run
        debug:
          msg: "Errors were ignored! ... not going to run."

Fíjese que en este ejemplo ha ignorado los errores de la segunda tarea run a bad command el blog y por eso se pudo ejecutar la tercera tarea. También, el rescate La sección no se ejecutará ya que ha ignorado el error en la segunda tarea del bloque.

También puede añadir un archivo siempre sección a un bloque. tareas en el siempre La sección siempre se ejecutará independientemente de si el bloque ha fallado o no.

Para demostrarlo, mirad el siguiente handle-errors.yml libro de juego que tiene las tres secciones (bloque, rescate, siempre) De un bloque:

[elliot@control plays]$ cat handle-errors.yml 
---
- name: Handling Errors with Blocks
  hosts: node1
  tasks:
    - name: Handling Errors Example
      block:
        - name: run a command
          command: uptime

        - name: run a bad command
          command: blabla

        - name: This task will not run
          debug:
            msg: "I never run because the task above has failed!"

      rescue:
        - name: Runs when the block fails
          debug:
            msg: "Block failed! let's try to fix it here ..."

      always:
        - name: This will always run
          debug:
            msg: "Whether the block has failed or not ... I will always run!"

Siga adelante y ejecute el libro de reproducción:

[elliot@control plays]$ ansible-playbook handle-errors.yml 

PLAY [Handling Errors with Blocks] *********************************************

TASK [Gathering Facts] *********************************************************
ok: [node1]

TASK [run a command] ***********************************************************
changed: [node1]

TASK [run a bad command] *******************************************************
fatal: [node1]: FAILED! => "changed": false, "cmd": "blabla", "msg": "[Errno 2] No such file or directory: b'blabla': b'blabla'", "rc": 2

TASK [Runs when the block fails] ***********************************************
ok: [node1] => 
    "msg": "Block failed! let's try to fix it here ..."


TASK [This will always run] ****************************************************
ok: [node1] => 
    "msg": "Whether the block has failed or not ... I will always run!"


PLAY RECAP *********************************************************************
node1                      : ok=4    changed=1    unreachable=0    failed=0    skipped=0

Como puedes ver; el rescate sección funcionó como la 2ndla tarea del bloque ha fallado y no ha ignorado los errores. También, el siempre sección funcionó (y siempre).

Ejecución de tareas tras el cambio con gestores

Veamos el cambio de controladores y la ejecución de tareas.

Ejecución del primer controlador

Puede utilizar gestores para activar tareas después de un cambio en sus nodos gestionados. Para demostrarlo, mirad el siguiente handler-example.yml libro de juegos:

[elliot@control plays]$ cat handler-example.yml 
---
- name: Simple Handler Example
  hosts: node1
  tasks:
    - name: Create engineers group
      group:
        name: engineers
      notify: add elliot

    - name: Another task in the play
      debug:
        msg: "I am just another task."

  handlers: 
    - name: add elliot
      user:
        name: elliot
        groups: engineers
        append: yes

La primera tarea Create engineers group crea el grupo de ingenieros y también lo notifica add elliot manipulador.

Ejecutamos el libro de reproducción para ver qué pasa:

[elliot@control plays]$ ansible-playbook handler-example.yml 

PLAY [Simple Handler Example] **************************************************

TASK [Gathering Facts] *********************************************************
ok: [node1]

TASK [Create engineers group] **************************************************
changed: [node1]

TASK [Another task in the play] ************************************************
ok: [node1] => 
    "msg": "I am just another task."


RUNNING HANDLER [add elliot] ***************************************************
changed: [node1]

PLAY RECAP *********************************************************************
node1                      : ok=4    changed=2    unreachable=0    failed=0    skipped=0

Tenga en cuenta que la creación de los ingenieros provocó un cambio nodo1 y, como resultado, activó el archivo add elliot manipulador.

También puede ejecutar una orden ad-hoc rápida para verificar este usuario elliot es miembro de la ingenieros grupo:

[elliot@control plays]$ ansible node1 -m command -a "id elliot"
node1 | CHANGED | rc=0 >>
uid=1000(elliot) gid=1000(elliot) groups=1000(elliot),4(adm),190(systemd-journal),1004(engineers)

Los libros de reproducción y los módulos ansible son idempotentes, lo que significa que si se produce un cambio de configuración a los nodos gestionados; no lo volverá a rehacer!

Para entender completamente el concepto de idempotencia de ansible; ejecute el manual de manipulación-example.yml una vez más:

[elliot@control plays]$ ansible-playbook handler-example.yml 

PLAY [Simple Handler Example] **************************************************

TASK [Gathering Facts] *********************************************************
ok: [node1]

TASK [Create engineers group] **************************************************
ok: [node1]

TASK [Another task in the play] ************************************************
ok: [node1] => 
    "msg": "I am just another task."


PLAY RECAP *********************************************************************
node1                      : ok=3    changed=0    unreachable=0    failed=0    skipped=0  

Como puedes ver; el Create engineers group la tarea no ha provocado ni ha informado de un cambio esta vez para que el grupo de ingenieros ya existe en el nodo1 y como resultado; el controlador add elliot no se ha ejecutado.

Controlar cuando informó de un cambio

Puede utilizar el archivo canviat_quan palabra clave para controlar cuando una tarea debe informar de un cambio. Para demostrarlo, mirad el siguiente control-canvi.yml libro de juegos:

[elliot@control plays]$ cat control-change.yml 
---
- name: Control Change
  hosts: node1
  tasks:
    - name: Run the date command
      command: date
      notify: handler1

    - name: Run the uptime command
      command: uptime

  handlers:
     - name: handler1
       debug:
         msg: "I can handle dates"

Fíjese en la primera tarea Run the date command desencadenantes manipulador1. Ahora, adelante, ejecute el libro de reproducción:

[elliot@control plays]$ ansible-playbook control-change.yml 

PLAY [Control Change] **********************************************************

TASK [Gathering Facts] *********************************************************
ok: [node1]

TASK [Run the date command] ****************************************************
changed: [node1]

TASK [Run the uptime command] **************************************************
changed: [node1]

RUNNING HANDLER [handler1] *****************************************************
ok: [node1] => 
    "msg": "I can handle dates"


PLAY RECAP *********************************************************************
node1                      : ok=4    changed=2    unreachable=0    failed=0    skipped=0

ambas tareas Run the date command y Run the uptime command ha informado de cambios y manipulador1 se desencadenó. Puede argumentar que ejecutar órdenes de fecha y tiempo de actividad realmente no cambia nada en el nodo gestionado y tiene toda la razón.

Ahora editamos el libro de reproducción para detener el Run the date command tarea a partir del informe de cambios:

[elliot@control plays]$ cat control-change.yml 
---
- name: Control Change
  hosts: node1
  tasks:
    - name: Run the date command
      command: date
      notify: handler1
      changed_when: false

    - name: Run the uptime command
      command: uptime

  handlers:
     - name: handler1
       debug:
         msg: "I can handle dates"

Ahora introduzca el libro de reproducción:

[elliot@control plays]$ ansible-playbook control-change.yml 

PLAY [Control Change] **********************************************************

TASK [Gathering Facts] *********************************************************
ok: [node1]

TASK [Run the date command] ****************************************************
ok: [node1]

TASK [Run the uptime command] **************************************************
changed: [node1]

PLAY RECAP *********************************************************************
node1                      : ok=3    changed=1    unreachable=0    failed=0    skipped=0   

Como puede ver, el Run the date command la tarea no ha informado de un cambio esta vez y, como resultado, manipulador1 no se ha activado.

Configuración de servicios con gestores

Los controladores son especialmente útiles cuando edite configuraciones de servicios con ansible. Esto se debe a que sólo desea reiniciar un servicio cuando haya un cambio en la configuración del servicio.

Para demostrarlo, mirad el siguiente configure-ssh.yml libro de juegos:

[elliot@control plays]$ cat configure-ssh.yml 
---
- name: Configure SSH 
  hosts: all
  tasks:
     - name: Edit SSH Configuration
       blockinfile:
         path: /etc/ssh/sshd_config
         block: |
            MaxAuthTries 4
            Banner /etc/motd
            X11Forwarding no
       notify: restart ssh

  handlers: 
    - name: restart ssh
      service:
        name: sshd
        state: restarted

Tenga en cuenta que he utilizado el archivo blockinfile para insertar varias líneas de texto en el archivo / Etc / ssh / sshd_config archivo de configuración. el Edit SSH Configuration la tarea también activa el archivo restart ssh manipulador después del cambio.

Siga adelante y ejecute el libro de reproducción:

[elliot@control plays]$ ansible-playbook configure-ssh.yml 

PLAY [Configure SSH] ***********************************************************

TASK [Gathering Facts] *********************************************************
ok: [node4]
ok: [node3]
ok: [node1]
ok: [node2]

TASK [Edit SSH Configuration] **************************************************
changed: [node4]
changed: [node2]
changed: [node3]
changed: [node1]

RUNNING HANDLER [restart ssh] **************************************************
changed: [node4]
changed: [node3]
changed: [node2]
changed: [node1]

PLAY RECAP *********************************************************************
node1                      : ok=3    changed=2    unreachable=0    failed=0    skipped=0    
node2                      : ok=3    changed=2    unreachable=0    failed=0    skipped=0    
node3                      : ok=3    changed=2    unreachable=0    failed=0    skipped=0    
node4                      : ok=3    changed=2    unreachable=0    failed=0    skipped=0  

Todo pinta bien! Ahora echamos un vistazo rápido a las últimas líneas del / Etc / ssh / sshd_config dossier:

[elliot@control plays]$ ansible node1 -m command -a "tail -5 /etc/ssh/sshd_config"
node1 | CHANGED | rc=0 >>
# BEGIN ANSIBLE MANAGED BLOCK
MaxAuthTries 4
Banner /etc/motd
X11Forwarding no
# END ANSIBLE MANAGED BLOCK

Increíble! Exactamente como esperabas que fuera. Tenga en cuenta que si vuelve a ejecutar el archivo configure-ssh.yml Playbook, ansible no editará (ni añadirá) el archivo / Etc / ssh / sshd_config dossier. Puede probarlo por vosotros mismos.

También os recomiendo que echa un vistazo a blockinfile y lineinfile páginas de documentación para entender las diferencias y el uso de cada módulo:

[elliot@control plays]$ ansible-doc blockinfile
[elliot@control plays]$ ansible-doc lineinfile

Bien! Esto nos lleva al final de nuestra La toma de decisiones a ansible tutorial. Estad atentos al próximo tutorial, ya que aprenderá a utilizarlo plantillas Jinja2 para gestionar archivos y configurar servicios dinámicamente a ansible.

Este Blog lo escribimos para ayudar y servir de referencia a la gente Linux. Esperamos que os guste.

Leave a Reply