Treo Blog

En este espacio puedes explorar las últimas tendencias y noticias en tecnología, seguridad informática e infraestructura TI.

  • Jonathan Rodriguez Paipa

Introducción a los roles del sistema RHEL

Por: Brian Smith


Crédito: Pexels

En los entornos de TI actuales, las organizaciones deben gestionar una cantidad cada vez mayor de sistemas. Estos sistemas deben escalar dentro y fuera del centro de datos tradicional. Esto requiere que las organizaciones dependan cada vez más de la automatización para realizar las tareas. La implementación y gestión de un sistema operativo como Red Hat Enterprise Linux (RHEL) puede llevar mucho tiempo sin automatización, y las tareas de administración y mantenimiento tardan mucho más en completarse.


Los roles del sistema RHEL son una colección de roles y módulos de Ansible que pueden ayudar a automatizar la administración y configuración de los sistemas RHEL. Los roles del sistema RHEL pueden ayudar a proporcionar una configuración uniforme y repetible, reducir las cargas técnicas y agilizar la administración. En esta publicación, le mostraremos cómo utilizar los conocimientos de Red Hat con los roles del sistema RHEL, para que pueda dedicar más tiempo a hacer el trabajo que es más valioso para la empresa y menos tiempo a reinventar la rueda.


Descripción general de los roles del sistema RHEL


Los administradores pueden seleccionar de una biblioteca de servicios comunes y tareas de configuración proporcionadas por RHEL System Roles. Esta interfaz permite administrar las configuraciones del sistema en varias versiones (RHEL 8, RHEL 7 y, en algunos casos, RHEL 6) y admite la ejecución de tareas manuales de forma coherente en entornos físicos, virtuales, de nube privada y de nube pública.


Los roles del sistema RHEL son compatibles con su suscripción RHEL y están empaquetados como RPM incluidos con RHEL. Sin embargo, si tiene una suscripción a Red Hat Ansible Automation Platform y utiliza Ansible Tower, también puede acceder a los últimos roles del sistema RHEL desde Ansible Automation Hub para usar en Tower. Asimismo, si tiene suscripciones a Red Hat Smart Management y utiliza Red Hat Satellite, puede iniciar los roles del sistema RHEL desde Satellite.


Encontrará una amplia variedad de funciones del sistema RHEL:


Roles relacionados con la seguridad:

  • selinux permite la configuración de SELinux.

  • certificate puede gestionar la emisión y renovación de certificados TLS / SSL.

  • tlog configura la grabación de la sesión.

  • nbde_client and nbde_server configuran el cifrado de disco vinculado a la red.

  • ssh and sshd configuran el cliente y el servidor SSH, respectivamente.

  • crypto_policies configura las políticas criptográficas de todo el sistema.

Roles relacionados con la configuración:


  • timesync configura la sincronización horaria.

  • network configura la red.

  • kdump configura el volcado por caída del kernel.

  • storage configura el almacenamiento local.

  • kernel_settings configura la configuración del kernel.

  • metrics configura las métricas del sistema (utilizando Performance Co-Pilot).

  • logging configura el registro (rsyslog).

  • postfix (vista previa técnica) configura el servidor de correo electrónico de postfix.

  • ha_cluster (vista previa técnica) gestiona la agrupación en clústeres de alta disponibilidad.

Roles relacionados con la carga de trabajo *:

  • Roles relacionados con SAP que ayudan a implementar la carga de trabajo de SAP.

* Tenemos la idea de que serían útiles funciones adicionales específicas de la carga de trabajo, como una para Microsoft SQL Server, pero todavía estamos en la etapa de evaluación y planificación de esta idea.


Para obtener una lista actualizada de los roles disponibles, así como una matriz de soporte que detalla qué versiones de RHEL son compatibles con cada rol, consulte esta página.


Control node


Los roles del sistema RHEL utilizan Ansible, que tiene un concepto de nodo de control. El nodo de control es donde se instalan Ansible y los roles del sistema RHEL. El nodo de control debe tener conectividad a través de SSH con cada uno de los hosts que se administrarán a través de los roles del sistema RHEL (que se denominan nodos administrados). Los nodos administrados no necesitan tener los roles del sistema RHEL o Ansible instalados en ellos.




  • Nodo de control: el sistema con Ansible y los roles del sistema RHEL instalados.

  • Nodos administrados: los sistemas que administra RHEL System Roles.

Hay varias opciones para lo que se puede usar como nodo de control para los roles del sistema RHEL: Ansible Tower, Red Hat Satellite o un host RHEL.


Si tiene una suscripción a Ansible Automation Platform, se recomienda utilizar Ansible Tower como nodo de control. Ansible Tower ofrece funciones avanzadas como un panel visual, programación de trabajos, notificaciones, flujos de trabajo, gestión avanzada de inventario, etc. Para obtener más información sobre Ansible Tower, consulte este sitio.


Para las personas que utilizan Red Hat Satellite, también es posible utilizar Satellite como nodo de control. Consulte esta publicación anterior en la que cubro una descripción general de cómo configurar esto. Sin embargo, actualmente existe una limitación con respecto al uso de Satellite como nodo de control: Satellite 6.x solo se admite para ejecutarse en hosts RHEL 7 y, actualmente, no todos los roles del sistema RHEL más nuevos están disponibles en la versión RHEL 7 de rhel. -sistema-roles RPM.


También puede utilizar un host RHEL como nodo de control. En general, se recomienda que utilice la última versión de RHEL en el nodo de control para que tenga acceso al contenido más reciente del rol del sistema RHEL. También puede utilizar un host RHEL 7 como nodo de control; sin embargo, el RPM rhel-system-roles disponible en RHEL 7 actualmente no contiene todos los roles más nuevos, como se mencionó anteriormente. Es posible utilizar Ansible Automation Hub para descargar la última versión de los roles del sistema RHEL en RHEL 7 (o RHEL 8); sin embargo, esto requiere una suscripción a Ansible Automation Platform.


Si utiliza un host RHEL 8 o RHEL 7 como su nodo de control, siga los pasos enumerados en este artículo para instalar Ansible y RHEL System Roles en el nodo de control.


Configuración SSH


El nodo de control debe tener acceso SSH a cada uno de los hosts administrados. Si tiene firewalls en su red, esto podría implicar asegurarse de que el puerto 22 esté abierto entre el nodo de control y cada uno de los hosts administrados.


Además, el nodo de control deberá poder autenticarse a través de SSH en cada nodo administrado y escalar los privilegios a la cuenta raíz.


Si está utilizando Ansible Tower como su nodo de control, probablemente ya tenga esta configuración, ya que este es un requisito previo básico para ejecutar un libro de jugadas en los hosts.


Una vez que se configura el inventario de Ansible, el módulo de ping de Ansible puede validar que esta configuración SSH se configuró correctamente (esto se tratará más adelante en la publicación).


Si está utilizando Red Hat Satellite como su nodo de control, utiliza la configuración de ejecución remota para conectarse y autenticarse en los hosts. Si aún no ha configurado la ejecución remota en su entorno de satélite, consulte la documentación de satélite sobre cómo configurar esto.


Si está utilizando un host RHEL 8 o RHEL 7 como su nodo de control, deberá:

  • Determine qué cuenta le gustaría usar en el nodo de control y los hosts administrados.

  • Si bien es posible usar la cuenta raíz, generalmente se recomienda crear y utilizar una cuenta de servicio.

  • Genere una clave SSH para este usuario en el nodo de control con elssh-keygen comando.

  • Distribuya la clave pública a cada uno de los hosts administrados (con lo que elssh-copy-id comando puede ayudar).

  • Si está utilizando una cuenta de servicio, deberá configurar el acceso sudo en cada nodo administrado para que la cuenta de servicio pueda escalar sus privilegios a root.

Archivo de inventario


Ansible debe recibir una lista de nodos administrados en los que debe ejecutar los roles del sistema RHEL. Esto se hace a través de un archivo de inventario de Ansible.


Si está utilizando Ansible Tower como su nodo de control, hay una amplia variedad de opciones para el inventario. Para obtener más información, consulte la documentación de Ansible Tower.


Para las personas que usan Satellite como nodo de control, puede asignar roles de Ansible a hosts individuales o a grupos de hosts a través de grupos de hosts. Para obtener más información, consulte la documentación de Satellite.


Si está utilizando un host RHEL 8 o RHEL 7 como su nodo de control, deberá definir un inventario en un archivo de texto.


El archivo de inventario más simple sería uno que simplemente enumera un host por línea en el archivo, como se muestra en este ejemplo:

$ cat inventoryrhel8-server1
rhel8-server2
rhel7-server1
rhel7-server2 

También es posible definir grupos en el archivo de inventario como en el siguiente ejemplo donde se definen los grupos prod y dev:

$ cat inventory
[prod]
rhel8-server1
rhel7-server1
[dev]
rhel8-server2
rhel7-server2

Estos dos ejemplos anteriores fueron con inventarios en formato INI. También es posible definir inventarios en formato YAML. El siguiente ejemplo define los mismos grupos de producción y desarrollo, pero en un inventario con formato YAML:

Ahora que hemos definido un archivo de inventario, podemos utilizar el módulo de ping de Ansible para validar que nuestra configuración SSH se configuró correctamente y que nuestro nodo de control puede comunicarse y conectarse a cada host administrado. El comando en el siguiente ejemplo le dice a Ansible que use el módulo de ping , el archivo de inventario llamado Inventory.yml , y que se conecte a todos los hosts definidos en el inventario:


En este ejemplo, Ansible se conectó con éxito a los cuatro hosts que había definido en el archivo de inventario.


También puede definir variables en el inventario, sin embargo, lo cubriremos más adelante cuando hablemos de variables.


Los inventarios de Ansible son muy poderosos y flexibles, y acabo de cubrir los conceptos básicos. Para obtener más información sobre los archivos de inventario de Ansible, consulte la documentación de Ansible.


Variables de rol


Las variables de Ansible nos permiten especificar nuestra configuración deseada para los roles del sistema RHEL. Por ejemplo, si estamos utilizando el Timesync función para configurar la sincronización de tiempo, tenemos la capacidad de decir la Timesync papel que los servidores NTP en nuestro medio ambiente deben ser utilizados por nuestros nodos gestionados.


Cada función tiene una lista documentada de variables de función en su archivo README.md, al que se puede acceder en / usr / share / doc / rhel-system-roles / <nombre de función> /README.md .


Por ejemplo, el rol timsync especifica que la variable timesync_ntp_servers se usa para enumerar los servidores NTP que deben usarse. También hay variables adicionales para el rol timesync que están documentadas en este archivo, como timesync_ntp_provider , timesync_min_sources , etc.


Las variables de Ansible son otra característica poderosa de Ansible, y nuevamente, solo he cubierto los conceptos básicos aquí. Para obtener más información, consulte la documentación de Ansible.


Si está utilizando Satellite como su nodo de control de funciones del sistema RHEL, consulte esta publicación de blog para obtener información y ejemplos sobre cómo definir las variables de función en Satellite.


Hay dos ubicaciones principales donde se pueden especificar las variables de Ansible: en el inventario o directamente en los libros de jugadas. Cubriré estas dos opciones en las próximas secciones.


Definición de variables de función directamente en el libro de jugadas


Las variables de rol se pueden especificar directamente en el libro de jugadas que llama al rol del sistema RHEL. Por ejemplo, el libro de estrategias a continuación define las variables de función de sincronización temporal para especificar 3 servidores NTP y que deben utilizar la opción iburst.



Podríamos iniciar la ejecución de este libro de jugadas con el ansible-playbook comando, especificando el nombre del archivo del libro de jugadas y nuestro archivo de inventario creado previamente:

$ ansible-playbook timesync.yml -i Inventory.yml 

Si bien definir las variables de rol directamente en el archivo del libro de jugadas es fácil y conveniente, será necesario que edite el libro de jugadas cada vez que las variables de rol necesiten actualizarse (por ejemplo, si su servidor NTP fue reemplazado y necesita actualizar todo de los hosts para utilizar el nuevo servidor NTP). Se considera una mejor práctica definir las variables de función fuera del libro de jugadas para que el libro de jugadas no tenga que editarse y actualizarse con frecuencia.


Definición de variables en el inventario


También es posible definir las variables de función en el inventario de Ansible en lugar de en el libro de jugadas. Como se mencionó anteriormente, esto evitará la necesidad de editar con frecuencia el libro de jugadas.


Al definir las variables en el inventario, también podemos definir fácilmente variables basadas en los grupos de inventario.


En este ejemplo, me gustaría usar el rol de sincronización de tiempo para configurar la sincronización de tiempo en mis servidores, y me gustaría definir un conjunto de servidores NTP para los hosts en el grupo de producción y un conjunto diferente de servidores NTP para los hosts. en el dev grupo.


Comenzaré creando un directorio de inventario:


$ mkdir inventario 
$ cd inventario

Dentro del directorio de inventario, voy a definir un archivo de inventario llamado inventory.yml , definiendo dos servidores en la prod grupo, y dos servidores en el dev grupo: