Agregue un repositorio e instale un paquete a la manera de Ansible

Ansible hace la vida más fácil para los administradores de sistemas. En este artículo, le muestro cómo Ansible facilita la administración de hosts al agregar un repositorio de paquetes (repo) e instalar un paquete desde él. Pero primero, déjame recordarte cómo hacerlo sin Ansible.

Índice

Agregar un repositorio a un host e instalar un paquete

Bueno, supongo que la mayoría de ustedes ya saben cómo funciona. De todos modos, aquí hay algunos ejemplos de cómo activar un repositorio en un solo host e instalar un paquete desde allí.

Ejemplo 1: Subscription-Manager y YUM

Primero, active un depósito con el subscription-manager luego instale un paquete a través de yum con el siguiente comando:

$ sudo subscription-manager repos --enable=rhel-7-server-rpms
…
$ sudo yum install git

Eso es. Fácil, ¿verdad? Este ejemplo ejecuta los comandos manualmente y es bastante sencillo para un solo host.

Ejemplo 2: solo YUM

Podría habilitar temporalmente un repositorio (si actualmente está deshabilitado en la configuración) e instalar un paquete desde él con el siguiente comando:

$ sudo yum --enablerepo=rhel-7-server-rpms install git

Y este también es fácil, ¿verdad?

Bien, pero ¿cómo agrega un repositorio a un host remoto y luego instala un paquete allí? Bueno, podría hacer algo como esto:

$ ssh [email protected] yum --enablerepo=rhel-7-server-rpms install git

Supongo que también funciona.

Ejemplo 3: configurar varios hosts remotos

Entonces, ¿qué debo hacer cuando se trata de múltiples hosts remotos? Bueno, podría usar un bucle como:

$ for HOST in (host1 host2 host3); do
  ssh [email protected]$HOST yum --enablerepo=rhel-7-server-rpms install git
done

Con este bucle, git se instala como una tarea en serie en host1, host2 y host3. Pero, ¿y si tengo cientos de hosts? ¡Sería un bucle largo! ¿Qué pasa si tengo que activar diferentes repositorios dependiendo de si un host pertenece a o? Los hosts en pueden usar repositorios diferentes a los hosts en. Por supuesto, también podría crear una solución de script de shell para este problema. En lugar de caer en esa madriguera de conejo, le mostraré cómo acelerar su trabajo con Ansible.

Y ahora la forma de Ansible

Cuando comencé con la automatización, era más fácil ejecutar comandos en paralelo en mis hosts. Digamos que tengo el siguiente archivo de inventario estático con dos grupos y cuatro hosts que se ve así:

[testing]
host1
host2

[production]
host3
host4

Podría ejecutar el trabajo del Ejemplo 3 anterior en paralelo usando el modo ad-hoc de Ansible:

$ ansible all -m command -a 'yum --enablerepo=rhel-7-server-rpms install git'

el command El módulo ejecuta un comando determinado en paralelo en los hosts especificados por una plantilla de host (todo en este caso).

Agregar un nuevo repositorio e instalar un paquete

Habrás notado que usé el servidor rhel-7-rpms repo en los ejemplos anteriores. ya existe en mi yum configuración. En algunos casos no hay repositorio configurado por lo que tengo que especificar uno para usarlo. Primero, creo el .repo archivar. Por ejemplo, quiero agregar un repositorio llamado rhel-t-stade a hosts remotos e instalar git De esto. Así que podría ir con el siguiente libro de jugadas:

---
- hosts: Pruebas
  tasks:
    - name: Add repo rhel-t-stage
      yum_repositoriy:
        name: rhel-t-stage
        description: “Repo for hosts in Pruebas”
        baseurl: “http://mirror.example.com/rhel-t-stage”
        gpgcheck: yes
        gpgkey: file:///etc/pki/gpg-key

    - name: Install git
      yum:
        name: git
        state: latest

En el libro de jugadas anterior, agrego el nuevo repositorio a todos los hosts del grupo desde el archivo de inventario. Si quiero agregar un repositorio diferente a todos los hosts del grupo, copio el libro de jugadas anterior y lo modifico para adaptarlo a la configuración que quiero.

¡Pero hay una solución aún mejor!

Tenga en cuenta group_vars

Para este ejemplo, asumo el siguiente caso de uso.

  • Dos silencios llamados rhel-t-stade y etapa-t-personalizada debe agregarse a todos los hosts del grupo.
  • Dos silencios llamados rhel-p-etapa y escenario p personalizado debe agregarse a todos los hosts del grupo.

Con el archivo de inventario anterior creé el group_vars directorio telefónico. También creé el Pruebas y production archivos que contiene. Las variables especificadas en estos archivos se utilizan durante las ejecuciones del libro de estrategias para hosts en los grupos correspondientes en el archivo de inventario. Los siguientes ejemplos lo ilustran:

$ cat group_vars/Pruebas
repo_name1: rhel-t-stage
repo_description1: RHEL packages for Pruebas only
repo_baseurl1: http://repo.example.com/rhel-t-stage

repo_name2: custom-t-stage
repo_description2: Custom packages for Pruebas only
repo_baseurl2: http://repo.example.com/custom-t-stage

$ cat group_vars/production
repo_name1: rhel-p-stage
repo_description1: RHEL packages for production only
repo_baseurl1: http://repo.example.com/rhel-p-stage

repo_name2: custom-p-stage
repo_description2: Custom packages for Pruebas only
repo_baseurl2: http://repo.example.com/custom-p-stage

Como puede ver, cada línea comienza con un nombre de variable seguido del valor asignado a esa variable. Estos se utilizan en un libro de jugadas de la siguiente manera:

---
- hosts: all
  tasks:

    - name: Add RHEL repo
      yum_repository:
        name: “{{ repo_name1 }}“
        description: “{{ repo_description1 }}“
        baseurl: "{{ repo_baseurl1 }}"
        gpgcheck: yes
        gpgkey: file:///etc/pki/RPM-GPG-KEY-example

    - name: Add custom repo
      yum_repository:
        name: “{{ repo_name2 }}“
        description: “{{ repo_description2 }}“
        baseurl: "{{ repo_baseurl2 }}"
        gpgcheck: yes
        gpgkey: file:///etc/pki/RPM-GPG-KEY-example

Ansible busca variables en el group_vars directorio y utiliza los valores especificados en consecuencia. De esta manera, los repositorios correctos se agregan a los sistemas y. Dado que los módulos utilizados en este ejemplo son idempotentes (como la mayoría de los módulos de Ansible), no tengo que preocuparme de si estos repositorios ya están configurados. Si los repositorios ya están definidos, Ansible lo reconoce y no cambia nada.

Conclusión

Usar Ansible me permitió reducir las líneas de código y, por lo tanto, el riesgo de falla. Los archivos de configuración y los playbooks basados ​​en YAML son fáciles de leer. Y en mi opinión, mucho más fácil de leer que los scripts de shell personalizados.

Para mí, me gusta la forma Ansible de hacer las cosas. ¿Y tu?

Si está buscando un lugar para comenzar con la automatización, eche un vistazo a mi artículo anterior, Facilitando la automatización.

Artículos de interés

Subir