Se acercaba el Año Nuevo. Los niños de todo el país ya habían enviado cartas a Papá Noel o se habían hecho regalos, y su principal ejecutor, uno de los principales minoristas, se estaba preparando para la apoteosis de las ventas. En diciembre, la carga en su centro de datos aumenta varias veces. Por ello, la empresa decidió modernizar el centro de datos y poner en funcionamiento varias decenas de nuevos servidores en lugar de equipos que estaban llegando al final de su vida útil. Esto termina la historia con el telón de fondo de copos de nieve arremolinándose y comienza el thriller.

El equipo llegó al sitio varios meses antes del pico de ventas. El servicio de operaciones, por supuesto, sabe cómo y qué configurar en los servidores para llevarlos al entorno de producción. Pero necesitábamos automatizar esto y eliminar el factor humano. Además, se reemplazaron los servidores antes de la migración de un conjunto de sistemas SAP que eran críticos para la empresa.

La puesta en servicio de nuevos servidores estaba estrictamente sujeta a un plazo. Y trasladarlo significaba poner en peligro tanto el envío de mil millones de regalos como la migración de sistemas. Ni siquiera un equipo formado por Papá Noel y Papá Noel pudo cambiar la fecha: el sistema SAP para la gestión de almacenes solo se puede transferir una vez al año. Del 31 de diciembre al 1 de enero, los enormes almacenes del minorista, que en total tienen el tamaño de 20 campos de fútbol, ​​paran su trabajo durante 15 horas. Y este es el único período de tiempo para mover el sistema. No teníamos margen de error al introducir los servidores.

Permítanme ser claro: mi historia refleja las herramientas y el proceso de gestión de configuración que utiliza nuestro equipo.

El complejo de gestión de configuración consta de varios niveles. El componente clave es el sistema CMS. En el funcionamiento industrial, la ausencia de uno de los niveles provocaría inevitablemente milagros desagradables.

Gestión de instalación del sistema operativo

El primer nivel es un sistema para gestionar la instalación de sistemas operativos en servidores físicos y virtuales. Crea configuraciones básicas del sistema operativo, eliminando el factor humano.

Con este sistema recibimos instancias de servidor estándar con un sistema operativo adecuado para una mayor automatización. Durante el "vertido", recibieron un conjunto mínimo de usuarios locales y claves SSH públicas, así como una configuración de sistema operativo consistente. Teníamos la garantía de gestionar los servidores a través del CMS y estábamos seguros de que no habría sorpresas "abajo" a nivel del sistema operativo.

La tarea "máxima" del sistema de gestión de instalación es configurar automáticamente los servidores desde el nivel de BIOS/Firmware hasta el sistema operativo. Aquí mucho depende del equipo y de las tareas de configuración. Para equipos heterogéneos, se puede considerar API DE PESCADO ROJO. Si todo el hardware es de un solo proveedor, suele ser más conveniente utilizar herramientas de administración listas para usar (por ejemplo, HP ILO Amplifier, DELL OpenManage, etc.).

Para instalar el SO en servidores físicos utilizamos el conocido Cobbler, que define un conjunto de perfiles de instalación acordados con el servicio de operación. Al agregar un nuevo servidor a la infraestructura, el ingeniero vinculó la dirección MAC del servidor al perfil requerido en Cobbler. Al iniciar a través de la red por primera vez, el servidor recibió una dirección temporal y un sistema operativo nuevo. Luego se transfirió a la dirección VLAN/IP de destino y continuó trabajando allí. Sí, cambiar la VLAN lleva tiempo y requiere coordinación, pero proporciona protección adicional contra la instalación accidental del servidor en un entorno de producción.

Creamos servidores virtuales basados ​​en plantillas preparadas con HashiСorp Packer. El motivo era el mismo: prevenir posibles errores humanos a la hora de instalar el SO. Pero, a diferencia de los servidores físicos, Packer elimina la necesidad de PXE, arranque de red y cambios de VLAN. Esto ha hecho que sea más fácil y sencillo crear servidores virtuales.

Arroz. 1. Gestionar la instalación de sistemas operativos.

Manejando secretos

Cualquier sistema de gestión de configuración contiene datos que deberían estar ocultos a los usuarios normales, pero que son necesarios para preparar los sistemas. Se trata de contraseñas para usuarios locales y cuentas de servicio, claves de certificados, varios tokens API, etc. Por lo general, se denominan "secretos".

Si no determina desde el principio dónde y cómo almacenar estos secretos, entonces, dependiendo de la gravedad de los requisitos de seguridad de la información, es probable que se utilicen los siguientes métodos de almacenamiento:

• directamente en el código de control de configuración o en archivos en el repositorio;
• en herramientas especializadas de gestión de configuración (por ejemplo, Ansible Vault);
• en sistemas CI/CD (Jenkins/TeamCity/GitLab/etc.) o en sistemas de gestión de configuración (Ansible Tower/Ansible AWX);
• Los secretos también se pueden transferir "manualmente". Por ejemplo, se colocan en una ubicación específica y luego son utilizados por los sistemas de gestión de configuración;
• varias combinaciones de los anteriores.

Cada método tiene sus propias desventajas. El principal es la falta de políticas de acceso a los secretos: es imposible o difícil determinar quién puede utilizar determinados secretos. Otra desventaja es la falta de auditoría de acceso y de un ciclo de vida completo. ¿Cómo reemplazar rápidamente, por ejemplo, una clave pública escrita en el código y en varios sistemas relacionados?

Utilizamos el almacenamiento secreto centralizado HashiCorp Vault. Esto nos permitió:

• mantener los secretos a salvo. Están cifrados e incluso si alguien obtiene acceso a la base de datos de Vault (por ejemplo, restaurándola desde una copia de seguridad), no podrá leer los secretos almacenados allí;
• organizar políticas de acceso a los secretos. Sólo los secretos que se les “asignan” están disponibles para los usuarios y las aplicaciones;
• Auditar el acceso a los secretos. Cualquier acción con secretos se registra en el registro de auditoría de Vault;
• organizar un "ciclo de vida" completo de trabajo con secretos. Se pueden crear, revocar, fijar una fecha de caducidad, etc.
• fácil de integrar con otros sistemas que necesitan acceso a secretos;
• y también utilizar cifrado de extremo a extremo, contraseñas de un solo uso para el sistema operativo y la base de datos, certificados de centros autorizados, etc.

Pasemos ahora al sistema central de autenticación y autorización. Era posible prescindir de él, pero administrar usuarios en muchos sistemas relacionados no es trivial. Hemos configurado la autenticación y autorización a través del servicio LDAP. De lo contrario, Vault tendría que emitir y realizar un seguimiento continuo de los tokens de autenticación para los usuarios. Y eliminar y agregar usuarios se convertiría en una búsqueda: "¿Creé/eliminé esta cuenta de usuario en todas partes?"

Agregamos otro nivel a nuestro sistema: gestión de secretos y autenticación/autorización central:

Arroz. 2. Gestión de secretos.

Gestión de configuración

Llegamos al núcleo: el sistema CMS. En nuestro caso, se trata de una combinación de Ansible y Red Hat Ansible AWX.

En lugar de Ansible, se puede utilizar Chef, Puppet, SaltStack. Elegimos Ansible según varios criterios.

• En primer lugar, es la versatilidad. Un conjunto de módulos de control listos para usar. es impresionante. Y si no tienes suficiente, puedes buscar en GitHub y Galaxy.
• En segundo lugar, no es necesario instalar ni dar soporte a agentes en el equipo administrado, demostrar que no interfieren con la carga y confirmar la ausencia de "marcadores".
• En tercer lugar, Ansible tiene una barrera de entrada baja. Un ingeniero competente escribirá un manual de estrategia literalmente el primer día de trabajo con el producto.

Pero Ansible por sí solo en un entorno de producción no fue suficiente para nosotros. De lo contrario, surgirían muchos problemas al restringir el acceso y auditar las acciones de los administradores. ¿Cómo restringir el acceso? Después de todo, era necesario que cada departamento administrara (léase: ejecutar el manual de Ansible) “su propio” conjunto de servidores. ¿Cómo permitir que solo ciertos empleados ejecuten guías de Ansible específicas? ¿O cómo rastrear quién lanzó el libro de jugadas sin configurar mucho conocimiento local en los servidores y equipos que ejecutan Ansible?

Red Hat resuelve la mayor parte de estos problemas Torre Ansible, o su proyecto upstream de código abierto AnsibleAWX. Por eso lo preferimos para el cliente.

Y un toque más al retrato de nuestro sistema CMS. El manual de estrategias de Ansible debe almacenarse en sistemas de gestión de repositorios de código. Lo tenemos GitLabCE.

Por lo tanto, las configuraciones en sí se administran mediante una combinación de Ansible/Ansible AWX/GitLab (ver Fig. 3). Por supuesto, AWX/GitLab está integrado con un único sistema de autenticación y el libro de jugadas de Ansible está integrado con HashiCorp Vault. Las configuraciones ingresan al entorno de producción solo a través de Ansible AWX, en el que se especifican todas las "reglas del juego": quién puede configurar qué, dónde obtener el código de administración de configuración para el CMS, etc.

Arroz. 3. Gestión de la configuración.

Gestión de pruebas

Nuestra configuración se presenta en forma de código. Por lo tanto, nos vemos obligados a seguir las mismas reglas que los desarrolladores de software. Necesitábamos organizar los procesos de desarrollo, pruebas continuas, entrega y aplicación del código de configuración a los servidores de producción.

Si esto no se hace de inmediato, los roles escritos para la configuración dejarían de ser compatibles y modificados, o dejarían de lanzarse a producción. La cura para este dolor es conocida y ha quedado demostrada en este proyecto:

• cada rol está cubierto por pruebas unitarias;
• las pruebas se ejecutan automáticamente cada vez que hay algún cambio en el código que gestiona las configuraciones;
• Los cambios en el código de gestión de configuración se publican en el entorno de producción solo después de pasar con éxito todas las pruebas y revisión del código.

El desarrollo de código y la gestión de la configuración se han vuelto más tranquilos y predecibles. Para organizar pruebas continuas, utilizamos el kit de herramientas GitLab CI/CD y tomamos Molécula ansible.

Siempre que hay un cambio en el código de gestión de configuración, GitLab CI/CD llama a Molecule:

• comprueba la sintaxis del código,
• levanta el contenedor Docker,
• aplica el código modificado al contenedor creado,
• comprueba la idempotencia del rol y ejecuta pruebas para este código (la granularidad aquí está en el nivel de rol ansible, consulte la Fig. 4).

Entregamos configuraciones al entorno de producción utilizando Ansible AWX. Los ingenieros de operaciones aplicaron cambios de configuración a través de plantillas predefinidas. AWX "solicitaba" de forma independiente la última versión del código de la rama maestra de GitLab cada vez que se utilizaba. De esta manera excluimos el uso de código no probado u obsoleto en el entorno de producción. Naturalmente, el código ingresó a la rama maestra solo después de probarlo, revisarlo y aprobarlo.

Arroz. 4. Prueba automática de roles en GitLab CI/CD.

También existe un problema asociado con el funcionamiento de los sistemas de producción. En la vida real, es muy difícil realizar cambios de configuración únicamente mediante el código CMS. Surgen situaciones de emergencia cuando un ingeniero debe cambiar la configuración “aquí y ahora”, sin esperar a que se edite el código, se pruebe, se apruebe, etc.

Como resultado, debido a los cambios manuales, aparecen discrepancias en la configuración en el mismo tipo de equipo (por ejemplo, la configuración de sysctl se configura de manera diferente en los nodos del clúster HA). O la configuración real del equipo difiere de la especificada en el código CMS.

Por lo tanto, además de las pruebas continuas, verificamos los entornos de producción para detectar discrepancias en la configuración. Elegimos la opción más sencilla: ejecutar el código de configuración del CMS en modo “ejecución en seco”, es decir, sin aplicar cambios, pero con notificación de todas las discrepancias entre la configuración planificada y la real. Implementamos esto ejecutando periódicamente todos los manuales de Ansible con la opción “—check” en los servidores de producción. Como siempre, Ansible AWX es responsable de iniciar y mantener el libro de estrategias actualizado (ver Fig. 5):

Arroz. 5. Comprueba si hay discrepancias en la configuración en Ansible AWX.

Después de las comprobaciones, AWX envía un informe de discrepancia a los administradores. Estudian la configuración problemática y luego la solucionan mediante guías adaptadas. Así mantenemos la configuración en el entorno de producción y el CMS está siempre actualizado y sincronizado. Esto elimina "milagros" desagradables cuando el código CMS se utiliza en servidores de "producción".

Ahora tenemos una importante capa de prueba que consta de Ansible AWX/GitLab/Molecule (Figura 6).

Arroz. 6. Gestión de pruebas.

¿Difícil? No discuto. Pero un complejo de gestión de configuración de este tipo se ha convertido en una respuesta integral a muchas preguntas relacionadas con la automatización de la configuración del servidor. Ahora los servidores estándar de un minorista siempre tienen una configuración estrictamente definida. CMS, a diferencia de un ingeniero, no olvidará agregar las configuraciones necesarias, crear usuarios y realizar docenas o cientos de configuraciones necesarias.

Hoy en día no existe ningún “conocimiento secreto” en la configuración de servidores y entornos. Todas las características necesarias se reflejan en el libro de jugadas. No más creatividad e instrucciones vagas: “Instálelo como Oracle normal, pero debe especificar un par de configuraciones de sysctl y agregar usuarios con el UID requerido. Pregúntale a los chicos en operación, ellos saben.".

La capacidad de detectar discrepancias en la configuración y corregirlas de forma proactiva proporciona tranquilidad. Sin un sistema de gestión de configuración, esto suele verse diferente. Los problemas se acumulan hasta que un día “disparan” hacia la producción. Luego se lleva a cabo un informe, se verifican y corrigen las configuraciones. Y el ciclo se repite otra vez

Y, por supuesto, aceleramos la puesta en funcionamiento de los servidores de varios días a horas.

Bueno, en la víspera de Año Nuevo, cuando los niños desenvolvían alegremente los regalos y los adultos pedían deseos mientras sonaban las campanadas, nuestros ingenieros migraron el sistema SAP a nuevos servidores. Hasta Papá Noel dirá que los mejores milagros son los que están bien preparados.

PD: Nuestro equipo a menudo se encuentra con el hecho de que los clientes quieren resolver los problemas de gestión de configuración de la forma más sencilla posible. Idealmente, como por arte de magia, con una sola herramienta. Pero en la vida todo es más complicado (sí, no volvieron a aparecer soluciones mágicas): hay que crear un proceso completo utilizando herramientas que sean convenientes para el equipo del cliente.

Autor: Sergey Artemov, arquitecto del departamento Soluciones DevOps "Jet Infosistemas"

Fuente: habr.com