El equipo llegó al sitio varios meses antes del pico de ventas. El servicio de mantenimiento, por supuesto, sabe cómo y qué configurar en los servidores para introducirlos en el entorno de producción. Pero necesitábamos automatizar esto y eliminar el factor humano. Además, los servidores fueron reemplazados antes de la migración de un conjunto de sistemas SAP críticos para la empresa.
La puesta en servicio de nuevos servidores estaba estrechamente vinculada a una fecha límite. Y moverlo pondría en peligro tanto el envío de los mil millones de regalos como la migración de sistemas. Incluso un equipo formado por Santa Claus y Santa Claus no pudo cambiar la fecha: el sistema SAP para la gestión de almacenes se puede transferir solo una vez al año. Del 31 de diciembre al 1 de enero, los enormes almacenes del minorista, un total de 20 campos de fútbol, paran su trabajo durante 15 horas. Y este es el único período de tiempo para que el sistema se mueva. No teníamos derecho a equivocarnos al ingresar a los servidores.
Permítanme explicarles de inmediato: mi historia refleja las herramientas y el proceso de gestión de la configuración que utiliza nuestro equipo.
El complejo de gestión de la configuración consta de varios niveles. El componente clave es el sistema CMS. En la explotación industrial, la ausencia de uno de los niveles conduciría inevitablemente a milagros desagradables.
Gestión de la instalación del SO
El primer nivel es el sistema para gestionar la instalación de sistemas operativos en servidores físicos y virtuales. Crea configuraciones básicas de SO, eliminando el factor humano.
Con la ayuda de este sistema, recibimos instancias estándar y adecuadas para la automatización de servidores con SO. Cuando se emitieron, recibieron un conjunto mínimo de usuarios locales y claves SSH públicas, así como una configuración de sistema operativo coherente. Se nos podía garantizar la gestión de los servidores a través del CMS y estábamos seguros de que no había sorpresas “por debajo”, a nivel de SO.
El objetivo máximo del sistema de gestión de la instalación es configurar automáticamente los servidores desde el nivel BIOS / Firmware hasta el sistema operativo. Mucho depende del hardware y las tareas de configuración. Para equipos diferentes, considere la API REDFISH... Si todo el hardware es de un solo proveedor, a menudo es más conveniente usar 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 coordinados con el servicio de mantenimiento. Al agregar un nuevo servidor a la infraestructura, el ingeniero vincularía la dirección MAC del servidor al perfil requerido en Cobbler. En el primer arranque a través de la red, el servidor recibió una dirección temporal y un sistema operativo nuevo. Luego se transfirió al direccionamiento VLAN / IP de destino y continuó funcionando allí. Sí, el cambio de VLAN lleva tiempo y requiere coordinación, pero brinda protección adicional contra la instalación accidental del servidor en un entorno de producción.
Creamos servidores virtuales basados en plantillas preparadas con HashiCorp Packer. El motivo era el mismo: evitar posibles errores humanos al instalar el SO. Pero, a diferencia de los servidores físicos, Packer le permite no usar PXE, arranque de red y cambio de VLAN. Esto facilitó y facilitó la creación de servidores virtuales.
Figura: 1. Gestión de instalación de sistemas operativos.
Gestión secreta
Cualquier sistema de gestión de la configuración contiene datos que deberían ocultarse a los usuarios normales, pero que son necesarios para preparar los sistemas. Estas son contraseñas de usuarios locales y cuentas de servicio, claves de certificado, varios tokens de API, etc. Por lo general, se denominan "secretos".
Si desde el principio no se determina dónde y cómo almacenar estos secretos, entonces, dependiendo de la severidad de los requisitos de SI, es probable que se utilicen los siguientes métodos de almacenamiento:
- directamente en el código de gestión de la configuración o en archivos en el repositorio;
- en herramientas de gestión de configuración especializadas (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);
- también los secretos se pueden transferir al "control manual". Por ejemplo, se colocan en un lugar acordado y luego son utilizados por los sistemas de gestión de la configuración;
- varias combinaciones de los anteriores.
Cada método tiene sus propios inconvenientes. El principal es la ausencia de políticas de acceso a secretos: es imposible o difícil determinar quién puede usar ciertos secretos. Otra desventaja es la falta de auditoría de acceso y un ciclo de vida completo. ¿Cómo reemplazar rápidamente, por ejemplo, una clave pública, que está escrita en el código y en varios sistemas relacionados?
Usamos la bóveda centralizada de HashiCorp. Esto nos permitió:
- mantener los secretos a salvo. Están encriptados, 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í;
- . «» ;
- . Vault;
- « » . , , . .
- , ;
- , , ..
Pasemos ahora al sistema central de autenticación y autorización. Podría prescindir de él, pero administrar usuarios en muchos sistemas relacionados es demasiado trivial. Hemos configurado autenticación y autorización a través del servicio LDAP. De lo contrario, el mismo Vault tendría que emitir y mantener registros de tokens de autenticación para los usuarios continuamente. Y eliminar y agregar usuarios se convertiría en una misión "¿He creado / eliminado esta UZ en todas partes?"
Añadimos un nivel más a nuestro sistema: gestión de secretos y autenticación / autorización centralizada:
Figura: 2. Gestión de secretos.
Gestión de configuración
Llegamos al núcleo, al sistema CMS. En nuestro caso, se trata de un grupo de Ansible y Red Hat Ansible AWX.
Chef, Puppet, SaltStack pueden actuar en lugar de Ansible. Elegimos Ansible por varias razones.
- Primero, es versatilidad. El conjunto de módulos de control listos para usar es impresionante . Y si no tiene suficiente, puede buscar en GitHub y Galaxy.
- En segundo lugar, no es necesario instalar y mantener agentes en equipos controlados, para demostrar que no interfieren con la carga y para confirmar la ausencia de "marcadores".
- En tercer lugar, Ansible tiene una barrera de entrada baja. Un ingeniero competente escribirá un manual de trabajo literalmente el primer día de trabajo con el producto.
Pero Ansible por sí solo no fue suficiente para nosotros en un entorno industrial. De lo contrario, habría muchos problemas al restringir el acceso y auditar las acciones de los administradores. ¿Cómo diferenciar el acceso? Después de todo, cada división necesitaba administrar (leer - ejecutar el libro de jugadas de Ansible) "su" conjunto de servidores. ¿Cómo puedo permitir que empleados específicos ejecuten guías específicas de Ansible? ¿O cómo rastrear quién lanzó un libro de jugadas sin ejecutar muchos KM locales en servidores y hardware de Ansible?
Red Hat Ansible Tower , o su proyecto Ansible AWX upstream de código abierto, resuelve la mayor parte de estos problemas . Por eso lo preferimos para el cliente.
Y un toque más al retrato de nuestro sistema CMS. El libro de jugadas de Ansible debe almacenarse en sistemas de gestión de repositorios de código. Tenemos este GitLab CE .
Por lo tanto, las configuraciones en sí son administradas por el paquete de Ansible / Ansible AWX / GitLab (consulte la Fig.3). Por supuesto, AWX / GitLab está integrado con el sistema de autenticación unificado, 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 establecen todas las "reglas del juego": quién y qué puede configurar, dónde obtener el código de gestión de configuración para el CMS, etc.
Figura: 3. Gestión de la configuración.
Gestión de pruebas
Nuestra configuración se presenta como un 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 hiciera de inmediato, los roles escritos para la configuración dejarían de mantenerse y modificarse, o dejarían de ejecutarse en producción. La cura para este dolor es conocida y valió la pena en este proyecto:
- cada función está cubierta por pruebas unitarias;
- las pruebas se ejecutan automáticamente cada vez que hay un cambio en el código de gestión de la configuración;
- los cambios en el código de gestión de la configuración ingresan al entorno de producción solo después de pasar con éxito todas las pruebas y la revisión del código.
El desarrollo de código y la gestión de la configuración son más tranquilos y predecibles. Para organizar las pruebas continuas, usamos el kit de herramientas GitLab CI / CD y tomamos Ansible Molecule como marco para organizar las pruebas .
Para cualquier cambio en el código de gestión de la 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 generado,
- comprueba la idempotencia del rol y ejecuta pruebas para este código (la granularidad aquí se encuentra en el nivel de rol ansible, consulte la Fig. 4).
Entregamos configuraciones al entorno de producción utilizando Ansible AWX. Los ingenieros operativos aplicaron cambios de configuración a través de plantillas predefinidas. AWX "solicitó" de forma independiente la última versión del código de la rama maestra de GitLab cada vez que se utilizó. De esta manera, excluimos el uso de código no probado o desactualizado en el entorno de producción. Naturalmente, el código entró en la rama maestra solo después de probarlo, revisarlo y aprobarlo.
Figura: 4. Prueba automática de roles en GitLab CI / CD.
También existe un problema relacionado con el funcionamiento de los sistemas de producción. En la vida real, es muy difícil realizar cambios de configuración solo a través del código CMS. Surgen situaciones anormales cuando un ingeniero debe cambiar la configuración "aquí y ahora" sin esperar la edición, prueba, aprobación del código, etc.
Como resultado, debido a los cambios manuales, aparecen discrepancias en la configuración en el mismo tipo de equipo (por ejemplo, en los nodos del clúster HA configuración diferente de la configuración de sysctl). O la configuración real en el hardware es diferente a la establecida en el código CMS.
Por lo tanto, además de las pruebas continuas, verificamos los entornos de producción para detectar discrepancias de configuración. Elegimos la opción más sencilla: ejecutar el código de configuración del CMS en modo "dry run", es decir, sin aplicar cambios, pero con notificación de todas las discrepancias entre la configuración planificada y la real. Hemos implementado esto ejecutando periódicamente todos los libros de jugadas de Ansible con la opción "--check" en los servidores de producción. Ansible AWX, como siempre, es responsable del lanzamiento y relevancia del libro de jugadas (ver Fig.5):
Figura: 5. Comprueba si existen discrepancias en la configuración de Ansible AWX.
Después de las verificaciones, AWX envía un informe de discrepancias a los administradores. Estudian la configuración del problema y luego lo solucionan a través del libro de jugadas ajustado. De esta forma mantenemos la configuración en el entorno de producción y el CMS está siempre actualizado y sincronizado. Esto elimina los desagradables "milagros" cuando el código CMS se aplica en servidores de "producción".
Ahora tenemos una capa de prueba importante que consta de Ansible AWX / GitLab / Molecule (Figura 6).
Figura: 6. Gestión de pruebas.
¿Difícil? Yo no discuto. Pero este complejo de gestión de la configuración se ha convertido en una respuesta integral a muchas preguntas relacionadas con la automatización de la configuración del servidor. Ahora, el minorista siempre tiene una configuración estrictamente definida para servidores estándar. CMS, a diferencia de un ingeniero, no se olvidará de agregar las configuraciones necesarias, crear usuarios y realizar decenas o cientos de configuraciones requeridas.
Actualmente, no existe un "conocimiento secreto" en la configuración de los servidores y entornos. Todas las funciones necesarias se reflejan en el libro de jugadas. No más creatividad e instrucciones vagas: “ póngalo como un Oracle normal, pero allí debe registrar un par de configuraciones de sysctl y agregar usuarios con el UID requerido. Pregúntele a los chicos de la operación, ellos lo saben ".
La capacidad de detectar discrepancias de configuración y corregirlas de antemano brinda tranquilidad. Sin un CMS, esto generalmente se ve diferente. Los problemas se acumulan hasta que un día se "disparan" en la producción. Luego se lleva a cabo el debriefing, se verifican y corrigen las configuraciones. Y el ciclo se repite de nuevo
Y por supuesto, hemos acelerado el lanzamiento de servidores en producción de unos días a horas.
Bueno, en la víspera de Año Nuevo, cuando los niños desenvolvieron felices los regalos y los adultos pidieron deseos mientras sonaban las campanas, nuestros ingenieros migraron el sistema SAP a nuevos servidores. Incluso Santa Claus dirá que los mejores milagros son los que están bien preparados.
PD Nuestro equipo a menudo se enfrenta al hecho de que los clientes quieren resolver el problema de la gestión de la configuración lo más fácilmente posible. Idealmente, como por arte de magia, con una sola herramienta. Pero en la vida, todo es más complicado (sí, de nuevo, no se entregaron las soluciones mágicas): hay que crear todo un proceso utilizando herramientas convenientes para el equipo del cliente.
Autor: Sergey Artemov, arquitecto del departamento de soluciones DevOps de Jet Infosystems