Serie RHCE Ansible n.º 2:Ejecución de comandos ad-hoc

En la primera parte de la serie Ansible, se familiarizó con Ansible y aprendió a instalarlo.

En este tutorial, aprenderá a administrar el inventario estático en Ansible. También comprenderá varios ajustes de configuración de Ansible.

Además, explorará algunos módulos de Ansible y podrá ejecutar comandos Ad-Hoc de Ansible.

Antes de ver todo eso, me gustaría agradecer a todos los miembros de LHB Pro. Esta serie de Ansible es posible con su apoyo. Si aún no es un miembro profesional, considere optar por la suscripción.

Creando un usuario Ansible

Aunque puede usar el usuario raíz en Ansible para ejecutar libros de jugadas y comandos Ad-Hoc, definitivamente no se recomienda y no se considera la mejor práctica debido a los riesgos de seguridad que pueden surgir al permitir el acceso ssh del usuario raíz.

Por este motivo, se recomienda que cree un usuario de Ansible dedicado con privilegios sudo (para todos los comandos) en todos los hosts (hosts de control y administrados).

Recuerde, Ansible usa SSH y Python para hacer todo el trabajo sucio detrás de escena, por lo que estos son los cuatro pasos que debe seguir después de instalar Ansible:

1. Cree un nuevo usuario en todos los hosts.
2. Otorgue privilegios sudo al nuevo usuario en todos los nodos.
3. Genera claves SSH para el nuevo usuario en el nodo de control.
4. Copie la clave pública SSH en los nodos administrados.

Entonces, sin más preámbulos, comencemos con la creación de un nuevo usuario llamado elliot en todos los hosts:

[[email protected] ~]# useradd -m elliot
[[email protected] ~]# useradd -m elliot
[[email protected] ~]# useradd -m elliot
[[email protected] ~]# useradd -m elliot
[[email protected] ~]# useradd -m elliot

Después de configurar elliot's contraseña en todos los hosts, puede pasar al paso 2; puedes otorgarle a elliot privilegios sudo a todos los comandos sin contraseña agregando la siguiente entrada a /etc/sudoers archivo:

[[email protected] ~]# echo "elliot  ALL=(ALL)  NOPASSWD: ALL" >> /etc/sudoers
[[email protected] ~]# echo "elliot  ALL=(ALL)  NOPASSWD: ALL" >> /etc/sudoers
[[email protected] ~]# echo "elliot  ALL=(ALL)  NOPASSWD: ALL" >> /etc/sudoers
[[email protected] ~]# echo "elliot  ALL=(ALL)  NOPASSWD: ALL" >> /etc/sudoers
[[email protected] ~]# echo "elliot  ALL=(ALL)  NOPASSWD: ALL" >> /etc/sudoers

Ahora, inicie sesión como usuario elliot en su nodo de control y genere un par de claves ssh:

[[email protected] ~]$ ssh-keygen 
Generating public/private rsa key pair.
Enter file in which to save the key (/home/elliot/.ssh/id_rsa):       
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/elliot/.ssh/id_rsa.
Your public key has been saved in /home/elliot/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:Xf5bKx0kkBCsCQ/7rc6Kv6CxCRTH2XJajbNvpzel+Ik [email protected]
The key's randomart image is:
+---[RSA 3072]----+
|        .oo .    |
|  . ooo  . o     |
| . = *=.o   o    |
|  o =.o+ . o . . |
| . . .. S . . o  |
|.     .. . . . . |
|.. .   oo.o   o o|
|. = o oo++.  . +.|
| + ..++Eoo.   o. |
+----[SHA256]-----+

Por último, puede copiar la de elliot clave ssh pública para todos los hosts administrados mediante el ssh-copy-id comando de la siguiente manera:

[[email protected] ~]$ ssh-copy-id node1
[[email protected] ~]$ ssh-copy-id node2
[[email protected] ~]$ ssh-copy-id node3
[[email protected] ~]$ ssh-copy-id node4

Ahora debería poder acceder a todos los nodos administrados sin que se le solicite una contraseña; solo se le pedirá que ingrese una frase de contraseña ssh (si no la dejó vacía, ja, ja).

Creando su inventario de Ansible

Un archivo de inventario de Ansible es básicamente un archivo que contiene una lista de servidores, un grupo de servidores o direcciones IP que hacen referencia a los hosts que desea que Ansible administre (nodos administrados).

El /etc/ansible/hosts es el archivo de inventario predeterminado. Ahora le mostraré cómo crear sus propios archivos de inventario en Ansible.

Creando un directorio de proyecto

No quieres meterte con /etc/ansible directorio; debe mantener todo en /etc/ansible intacto y básicamente solo utilícelo como referencia cuando esté creando archivos de inventario, editando archivos de configuración de proyectos de Ansible, etc.

Ahora, creemos un nuevo directorio de proyectos de Ansible llamado /home/elliot. nombradas reproducciones que usará para almacenar todas sus cosas relacionadas con Ansible (libros de jugadas, archivos de inventario, roles, etc.) que creará a partir de este momento:

[[email protected] ~]$ mkdir /home/elliot/plays

Tenga en cuenta que todo lo que creará a partir de este punto en adelante estará en el nodo de control.

Creando un archivo de inventario

Cambiar a /home/elliot/plays directorio y cree un archivo de inventario llamado myhosts y agregue todos los nombres de host de sus nodos administrados para que termine luciendo así:

[[email protected] plays]$ cat myhosts 
node1
node2
node3
node4

Ahora puede ejecutar el siguiente comando de Ansible para enumerar todos sus hosts en myhosts archivo de inventario:

[[email protected] plays]$ ansible all -i myhosts --list-hosts
  hosts (4):
    node1
    node2
    node3
    node4

El -i se usó la opción para especificar myhosts archivo de inventario. Si omite la -i opción, Ansible buscará hosts en /etc/ansible/hosts archivo de inventario en su lugar.

Tenga en cuenta que estoy usando nombres de host aquí y que todos los nodos (vms) que he creado en Azure están en la misma subred y no tengo que preocuparme por el DNS, ya que lo maneja Azure.

Si no tiene un servidor DNS en funcionamiento, puede agregar las entradas de dirección IP/nombre de host de sus nodos en /etc/hosts , a continuación se muestra un ejemplo:

Creación de grupos y subgrupos de host

Puede organizar sus hosts gestionados en grupos y subgrupos. Por ejemplo, puede editar myhosts archivo para crear dos grupos prueba y prod de la siguiente manera:

[[email protected] plays]$ cat myhosts 
[test]
node1
node2

[prod]
node3
node4

Puede enumerar los hosts en el prod grupo ejecutando el siguiente comando:

[[email protected] plays]$ ansible prod -i myhosts --list-hosts
  hosts (2):
    node3
    node4

Hay dos grupos predeterminados en Ansible:

1. todos:contiene todos los hosts del inventario
2. desagrupado:contiene todos los hosts que no son miembros de ningún grupo (aparte de todos).

Agreguemos un host imaginario node5 a los mishosts archivo de inventario para demostrar el desagrupado grupo:

[[email protected] plays]$ cat myhosts 
node5

[test]
node1
node2

[prod]
node3
node4

Observe que agregué node5 hasta el principio (y no el final) de myhosts archivo, de lo contrario, se consideraría un miembro de la prod grupo.

Ahora puede ejecutar el siguiente comando para listar todos los desagrupados anfitriones:

[[email protected] plays]$ ansible ungrouped -i myhosts --list-hosts
  hosts (1):
    node5

También puede crear un grupo (principal) que contenga subgrupos (secundarios). Echa un vistazo al siguiente ejemplo:

[[email protected] plays]$ cat myhosts 
[web_dev]
node1

[web_prod]
node2

[db_dev]
node3

[db_prod]
node4

[development:children]
web_dev
db_dev

[production:children]
web_prod
db_prod 

El desarrollo grupo contiene todos los hosts que están en web_dev más todos los miembros que están en db_dev . Del mismo modo, la producción grupo contiene todos los hosts que están en web_prod más todos los miembros que están en db_prod.

[[email protected] plays]$ ansible development -i myhosts --list-hosts
  hosts (2):
    node1
    node3

[[email protected] plays]$ ansible production -i myhosts --list-hosts
  hosts (2):
    node2
    node4

Configuración de Ansible

En esta sección, aprenderá sobre los ajustes de configuración más importantes de Ansible. A lo largo de toda la serie, analizará otros ajustes de configuración cuando surja la necesidad.

El /etc/ansible/ansible.cfg es el archivo de configuración predeterminado. Sin embargo, también se recomienda no meterse con /etc/ansible/ansible.cfg y solo úsalo como referencia. Debe crear su propio archivo de configuración de Ansible en el directorio de su proyecto de Ansible.

La ansible --versión El comando le mostrará qué archivo de configuración está utilizando actualmente:

[[email protected] plays]$ ansible --version
ansible 2.9.14
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/home/elliot/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3.6/site-packages/ansible
  executable location = /usr/bin/ansible
  python version = 3.6.8 (default, Dec  5 2019, 15:45:45) [GCC 8.3.1 20191121 (Red Hat 8.3.1-5)]

Como puede ver en la salida, /etc/ansible/ansible.cfg está actualmente en uso ya que aún no ha creado su propio ansible.cfg archivo en el directorio del proyecto.

El /etc/ansible/ansible.cfg contiene un conjunto de varias secciones y ajustes de configuración de Ansible:

[[email protected] plays]$ wc -l /etc/ansible/ansible.cfg 
490 /etc/ansible/ansible.cfg

Las dos secciones más importantes que debe definir en su archivo de configuración de Ansible son:

1. [predeterminado]
2. [privilegio_escalado]

En el [predeterminado] sección, estas son las configuraciones más importantes que debe tener en cuenta:

• inventario - especifica la ruta de su archivo de inventario.
• usuario_remoto - especifica el usuario que se conectará a los hosts administrados y ejecutará los playbooks.
• horquillas - especifica la cantidad de host que Ansible puede administrar/procesar en paralelo; el valor predeterminado es 5.
• comprobación_clave_host - especifica si desea activar/desactivar la verificación del host de la clave SSH; el valor predeterminado es Verdadero.

En el [privilege_escalation] sección, puede configurar los siguientes ajustes:

• convertirse - especificar dónde permitir/no permitir la escalada de privilegios; el valor predeterminado es Falso.
• convertirse en_método - especificar el método de escalada de privilegios; el valor predeterminado es sudo.
• conviértete_en_usuario - especificar el usuario en el que se convierte a través de la escalada de privilegios; el valor predeterminado es root.
• conviértete_pregunta_contraseña - especificar si solicitar o no la contraseña de escalada de privilegios; el valor predeterminado es Falso.

Tenga en cuenta que no necesita confirmar ninguna de estas configuraciones en la memoria. Todos están documentados en /etc/ansible/ansible.cfg .

Ahora cree su propio ansible.cfg archivo de configuración en el directorio de su proyecto Ansible /home/elliot/plays y establezca la siguiente configuración:

Ahora ejecute la ansible --version manda una vez más; debería ver que su nuevo archivo de configuración ya está en vigor:

[[email protected] plays]$ ansible --version
ansible 2.9.14
  config file = /home/elliot/plays/ansible.cfg
  configured module search path = ['/home/elliot/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3.6/site-packages/ansible
  executable location = /usr/bin/ansible
  python version = 3.6.8 (default, Dec  5 2019, 15:45:45) [GCC 8.3.1 20191121 (Red Hat 8.3.1-5)]

Ejecutar comandos ad-hoc en Ansible

Hasta este punto, en realidad solo ha estado instalando, configurando su entorno y configurando Ansible. ¡Ahora, comienza la verdadera diversión!

Los comandos ad-hoc de Ansible son una excelente herramienta que puede usar para ejecutar una sola tarea en uno o más nodos administrados. Un comando típico ad-hoc de Ansible sigue la sintaxis general:

ansible host_pattern -m module_name -a "module_options"

¡La forma más fácil de entender cómo funcionan los comandos ad-hoc de Ansible es simplemente ejecutar uno! Entonces, continúe y ejecute el siguiente comando ad-hoc:

[[email protected] plays]$ ansible node1 -m command -a "uptime"
Enter passphrase for key '/home/elliot/.ssh/id_rsa':
node1 | CHANGED | rc=0 >>
18:53:01 up 5 days, 18:03,  1 user,  load average: 0.00, 0.01, 0.00

¡Se me pidió que ingresara mi frase de contraseña de la clave ssh y luego se mostró el tiempo de actividad del nodo 1! Ahora, consulte la figura a continuación para ayudarlo a comprender cada elemento del comando ad-hoc que acaba de ejecutar:

Probablemente ya lo habrías adivinado; módulos ansible son secuencias de comandos independientes y reutilizables que puede utilizar la API de Ansible , o por ansible o ansible - manual programas.

El módulo de comando es uno de los muchos módulos que Ansible tiene para ofrecer. Puede ejecutar ansible-doc -l Comando para listar todos los módulos Ansible disponibles:

[[email protected] plays]$ ansible-doc -l | wc -l
3387

Actualmente, hay 3387 módulos Ansible disponibles, ¡y aumentan día a día! Puede pasar cualquier forma de comando que desee ejecutar como opción al módulo de comando de Ansible.

Si no tiene una frase de contraseña de clave ssh vacía (como yo); entonces tendrías que ejecutar ssh-agent para evitar el dolor de cabeza innecesario de que se le solicite una frase de contraseña cada vez que Ansible intente acceder a sus nodos administrados:

[[email protected] plays]$ eval `ssh-agent`
Agent pid 218750
[[email protected] plays]$ ssh-add
Enter passphrase for /home/elliot/.ssh/id_rsa: 
Identity added: /home/elliot/.ssh/id_rsa ([email protected])

Prueba de conectividad

Es posible que desee probar si Ansible puede conectarse a todos sus nodos administrados antes de comenzar las tareas más serias; para ello, puedes utilizar el ping módulo y especifique todos sus hosts administrados de la siguiente manera:

[[email protected] plays]$ ansible all -m ping 
node4 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python"
    },
    "changed": false,
    "ping": "pong"
}
node3 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/libexec/platform-python"
    },
    "changed": false,
    "ping": "pong"
}
node1 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/libexec/platform-python"
    },
    "changed": false,
    "ping": "pong"
}
node2 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/libexec/platform-python"
    },
    "changed": false,
    "ping": "pong"
}

Como se puede ver con todo el ÉXITO en la salida. Observe que el ping de Ansible El módulo no necesita ninguna opción. Algunos módulos de Ansible requieren opciones y otros no, como en el caso de los comandos de Linux.

Documentación de módulos Ansible

Si alguien me pregunta qué es lo que más te gusta de Ansible; Rápidamente diría que es la documentación. Ansible está muy bien documentado y todo desde la comodidad de su propia terminal.

Si desea saber cómo usar un módulo Ansible específico, puede ejecutar ansible-doc seguido del nombre del módulo.

Por ejemplo, puede ver la descripción del ping módulo y cómo usarlo ejecutando:

[[email protected] plays]$ ansible-doc ping

Esto abrirá el ping página de documentación del módulo:

Cuando lea la documentación de los módulos, preste especial atención para ver si alguna opción tiene el prefijo del signo igual (=). En este caso, es una opción obligatoria que debes incluir.

Además, si se desplaza completamente hacia abajo, puede ver algunos ejemplos de cómo ejecutar los comandos ad-hoc o los libros de jugadas de Ansible (que analizaremos más adelante).

Command vs. Shell vs. Raw Modules

Hay tres módulos de Ansible que la gente a menudo confunde entre sí; estos son:

1. comando
2. concha
3. crudo

Esos tres módulos logran el mismo propósito; ejecutan comandos en los nodos administrados. Pero hay diferencias clave que separan los tres módulos.

No puede usar canalización o redirección con el comando módulo. Por ejemplo, el siguiente comando ad-hoc generará un error:

[[email protected] plays]$ ansible node2 -m command -a "lscpu | head -n 5"
node2 | FAILED | rc=1 >>
lscpu: invalid option -- 'n'
Try 'lscpu --help' for more information.non-zero return code

Eso es porque comando El módulo no admite canalizaciones ni redirección. Puede usar el módulo de shell en su lugar si desea usar tuberías o redirección. Vuelva a ejecutar el mismo comando, pero esta vez use el shell módulo en su lugar:

[[email protected] plays]$ ansible node2 -m shell -a "lscpu | head -n 5"
node2 | CHANGED | rc=0 >>
Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
CPU(s):              1
On-line CPU(s) list: 0

¡Funciona de maravilla! Mostró con éxito las primeras cinco líneas de la salida del comando lscpu en el nodo2.

Ansible usa secuencias de comandos SSH y Python detrás de escena para hacer toda la magia. Ahora, la cruda El módulo solo usa SSH y omite el subsistema del módulo Ansible. De esta manera, ese módulo sin procesar funcionaría con éxito en el nodo administrado, incluso si Python no está instalado (en el nodo administrado).

Manipulé mis archivos binarios de Python en el nodo 4 (por favor, no lo hagas tú mismo) para poder imitar un escenario de lo que sucederá si ejecutas el shell o comando módulo en un nodo que no tiene Python instalado:

[email protected]:/usr/bin# mkdir hide
[email protected]:/usr/bin# mv python* hide/

Ahora verifique qué sucederá si ejecuto un Ansible ad-hoc con el shell o comando módulo dirigido al nodo 4:

[[email protected] plays]$ ansible node4 -m shell -a "whoami"
node4 | FAILED! => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python"
    },
    "changed": false,
    "module_stderr": "Shared connection to node4 closed.\r\n",
    "module_stdout": "/bin/sh: 1: /usr/bin/python: not found\r\n",
}

[[email protected] plays]$ ansible node4 -m command -a "cat /etc/os-release"
node4 | FAILED! => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python"
    },
    "changed": false,
    "module_stderr": "Shared connection to node4 closed.\r\n",
    "module_stdout": "/bin/sh: 1: /usr/bin/python: not found\r\n",
    "msg": "The module failed to execute correctly, you probably need to set the interpreter.\nSee stdout/stderr for the exact error",
    "rc": 127
}

me salen errores! Ahora intentaré lograr la misma tarea; pero esta vez usaré el sin procesar módulo:

[[email protected] plays]$ ansible node4 -m raw -a "cat /etc/os-release"
node4 | CHANGED | rc=0 >>
NAME="Ubuntu"
VERSION="18.04.5 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.5 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic
Shared connection to node4 closed.

Como puede ver, el módulo sin procesar fue el único módulo de tres módulos que llevó a cabo la tarea con éxito. Ahora volveré a arreglar el lío que hice en el nodo 4:

[email protected]:/usr/bin/hide# mv * ..

He creado esta tabla a continuación para ayudar a resumir los diferentes casos de uso de los tres módulos:

¡Bien! Esto nos lleva al final del segundo tutorial de Ansible.

Estén atentos para el próximo tutorial, ya que aprenderán a crear y ejecutar playbooks de Ansible. No olvides hacerte miembro :)

Cómo eliminar un servicio en Kubernetes

Sustitución de procesos:una forma poco común pero avanzada de redirección de entrada/salida en Linux

Linux

1. Ejecución de comandos de Linux en segundo plano y en primer plano

2. RHCE Ansible Series #8:Cifrado de contenido con Ansible Vault

3. Serie RHCE Ansible n.º 7:Plantillas Jinja2

4. RHCE Ansible Series #6:Toma de decisiones en Ansible

5. Serie RHCE Ansible n.º 5:bucles Ansible

Guía de Ansible:el comando ad-hoc

Introducción a los comandos ad hoc de Ansible

Ponga un temporizador en sus comandos en ejecución con el comando de tiempo de espera en Linux

Serie RHCE Ansible n.º 1:Salude a Ansible

Serie RHCE Ansible n.º 3:Manuales de Ansible

Serie RHCE Ansible n.º 12:solución de problemas de Ansible

Descripción	Comando	Concha	Crudo
Ejecutar comandos simples	Sí	Sí	Sí
Ejecutar comandos con redirección	No	Sí	Sí
Ejecutar comandos sin Python	No	No	Sí