Achegábase o ano novo. Os nenos de todo o país xa enviaran cartas a Papá Noel ou lle fixeron agasallos, e o seu principal executor, un dos grandes comerciantes, preparábase para a apoteose das vendas. En decembro, a carga do seu centro de datos aumenta varias veces. Por iso, a empresa decidiu modernizar o centro de datos e poñer en funcionamento varias ducias de novos servidores en lugar de equipos que chegaban ao final da súa vida útil. Isto remata o conto co pano de fondo de copos de neve arremolinados, e comeza o thriller.

O equipo chegou ao lugar varios meses antes do pico de vendas. O servizo de operacións, por suposto, sabe como e que configurar nos servidores para levalos ao contorno de produción. Pero necesitabamos automatizar isto e eliminar o factor humano. Ademais, os servidores foron substituídos antes da migración dun conxunto de sistemas SAP que eran críticos para a empresa.

A posta en funcionamento de novos servidores estivo estrictamente vinculada a un prazo. E movelo supuxo pór en perigo tanto o envío de mil millóns de agasallos como a migración de sistemas. Incluso un equipo formado por Father Frost e Santa Claus non puido cambiar a data: só pode transferir o sistema SAP para a xestión do almacén unha vez ao ano. Dende o 31 de decembro ata o 1 de xaneiro, as enormes naves do comerciante, en total do tamaño de 20 campos de fútbol, ​​paran o seu traballo durante 15 horas. E este é o único período de tempo para mover o sistema. Non tivemos marxe de erro ao introducir servidores.

Déixame claro: a miña historia reflicte as ferramentas e o proceso de xestión da configuración que usa o noso equipo.

O complexo de xestión de configuración consta de varios niveis. O compoñente clave é o sistema CMS. Na operación industrial, a ausencia dun dos niveis levaría inevitablemente a milagres desagradables.

Xestión da instalación do SO

O primeiro nivel é un sistema de xestión da instalación de sistemas operativos en servidores físicos e virtuais. Crea configuracións básicas do SO, eliminando o factor humano.

Usando este sistema, recibimos instancias de servidor estándar con SO axeitado para unha maior automatización. Durante o "vertido" recibiron un conxunto mínimo de usuarios locais e chaves SSH públicas, así como unha configuración coherente do SO. Garantíamos de xestionar os servidores a través do CMS e estabamos seguros de que non había sorpresas "abaixo" a nivel de SO.

A tarefa "máxima" para o sistema de xestión da instalación é configurar automaticamente os servidores desde o nivel de BIOS/Firmware ata o SO. Moito aquí depende do equipo e das tarefas de configuración. Para equipos heteroxéneos, podes considerar API REDFISH. Se todo o hardware é dun provedor, adoita ser máis cómodo usar ferramentas de xestión preparadas (por exemplo, HP ILO Amplifier, DELL OpenManage, etc.).

Para instalar o SO en servidores físicos, utilizamos o coñecido Cobbler, que define un conxunto de perfís de instalación acordados co servizo de operación. Ao engadir un novo servidor á infraestrutura, o enxeñeiro vinculaba o enderezo MAC do servidor ao perfil necesario en Cobbler. Ao iniciar a través da rede por primeira vez, o servidor recibiu un enderezo temporal e un sistema operativo novo. A continuación, foi transferido ao enderezo VLAN/IP de destino e continuou o traballo alí. Si, cambiar a VLAN leva tempo e require coordinación, pero ofrece protección adicional contra a instalación accidental do servidor nun ambiente de produción.

Creamos servidores virtuais baseados en modelos preparados usando HashiСorp Packer. O motivo foi o mesmo: evitar posibles erros humanos ao instalar o SO. Pero, a diferenza dos servidores físicos, Packer elimina a necesidade de PXE, arranque de rede e cambios de VLAN. Isto facilitou e facilitou a creación de servidores virtuais.

Arroz. 1. Xestionar a instalación de sistemas operativos.

Xestionando segredos

Calquera sistema de xestión de configuración contén datos que deberían ocultarse aos usuarios comúns, pero que son necesarios para preparar os sistemas. Estes son contrasinais para usuarios locais e contas de servizo, claves de certificado, varios tokens de API, etc. Adoitan chamarse "segredos".

Se non determina desde o principio onde e como almacenar estes segredos, entón, dependendo da gravidade dos requisitos de seguridade da información, son probables os seguintes métodos de almacenamento:

• directamente no código de control de configuración ou en ficheiros do repositorio;
• en ferramentas de xestión de configuración especializadas (por exemplo, Ansible Vault);
• en sistemas CI/CD (Jenkins/TeamCity/GitLab/etc.) ou en sistemas de xestión de configuración (Ansible Tower/Ansible AWX);
• os segredos tamén se poden transferir "manualmente". Por exemplo, dispóñense nun lugar especificado e, a continuación, son utilizados polos sistemas de xestión de configuración;
• varias combinacións dos anteriores.

Cada método ten as súas propias desvantaxes. A principal é a falta de políticas de acceso aos segredos: é imposible ou difícil determinar quen pode utilizar determinados segredos. Outra desvantaxe é a falta de auditoría de acceso e un ciclo de vida completo. Como substituír rapidamente, por exemplo, unha chave pública que está escrita no código e nunha serie de sistemas relacionados?

Usamos o almacenamento secreto centralizado HashiCorp Vault. Isto permitiunos:

• gardar os segredos a salvo. Están cifrados, e aínda que alguén obteña acceso á base de datos de Vault (por exemplo, restaurando a partir dunha copia de seguridade), non poderá ler os segredos alí almacenados;
• organizar políticas de acceso aos segredos. Só os segredos "asignados" a eles están dispoñibles para os usuarios e aplicacións;
• auditar o acceso aos segredos. Calquera acción con segredo rexístrase no rexistro de auditoría de Vault;
• organizar un "ciclo de vida" completo de traballo con segredos. Pódense crear, revogar, establecer unha data de caducidade, etc.
• fácil de integrar con outros sistemas que precisan acceso a segredos;
• e tamén utilizar o cifrado de extremo a extremo, contrasinais únicos para o SO e a base de datos, certificados de centros autorizados, etc.

Agora imos pasar ao sistema central de autenticación e autorización. Era posible prescindir del, pero administrar usuarios en moitos sistemas relacionados é demasiado pouco trivial. Configuramos a autenticación e autorización a través do servizo LDAP. En caso contrario, Vault tería que emitir e realizar un seguimento continuo dos tokens de autenticación dos usuarios. E eliminar e engadir usuarios converteríase nunha misión "Creei/eliminei esta conta de usuario en todas partes?"

Engadimos outro nivel ao noso sistema: xestión de segredos e autenticación/autorización central:

Arroz. 2. Xestión de segredos.

Xestión da configuración

Chegamos ao núcleo: o sistema CMS. No noso caso, esta é unha combinación de Ansible e Red Hat Ansible AWX.

En lugar de Ansible, pódese usar Chef, Puppet e SaltStack. Escollemos Ansible en función de varios criterios.

• En primeiro lugar, é a versatilidade. Un conxunto de módulos preparados para o control é impresionante. E se non tes o suficiente, podes buscar en GitHub e Galaxy.
• En segundo lugar, non é necesario instalar e apoiar axentes nos equipos xestionados, demostrar que non interfiren coa carga e confirmar a ausencia de "marcadores".
• En terceiro lugar, Ansible ten unha baixa barreira de entrada. Un enxeñeiro competente escribirá un manual de traballo literalmente o primeiro día de traballo co produto.

Pero Ansible só nun ambiente de produción non foi suficiente para nós. En caso contrario, xurdirían moitos problemas coa restrición do acceso e a auditoría das accións dos administradores. Como restrinxir o acceso? Despois de todo, era necesario que cada departamento xestionase (léase: executa o libro de xogos de Ansible) o "seu propio" conxunto de servidores. Como permitir que só determinados empregados executen manuais específicos de Ansible? Ou como facer un seguimento de quen lanzou o manual sen configurar moito coñecemento local en servidores e equipos que executan Ansible?

A maior parte destes problemas é resolto por Red Hat Torre Ansible, ou o seu proxecto upstream de código aberto Ansible AWX. Por iso o preferimos para o cliente.

E un toque máis ao retrato do noso sistema CMS. O playbook de Ansible debe almacenarse en sistemas de xestión de repositorio de código. Temos GitLab CE.

Entón, as propias configuracións son xestionadas por unha combinación de Ansible/Ansible AWX/GitLab (consulte a figura 3). Por suposto, AWX/GitLab está integrado cun único sistema de autenticación e Ansible Playbook está integrado con HashiCorp Vault. As configuracións entran no contorno de produción só a través de Ansible AWX, no que se especifican todas as "regras do xogo": quen pode configurar que, onde obter o código de xestión de configuración para o CMS, etc.

Arroz. 3. Xestión da configuración.

Xestión de probas

A nosa configuración preséntase en forma de código. Polo tanto, vémonos obrigados a xogar coas mesmas regras que os desenvolvedores de software. Necesitabamos organizar os procesos de desenvolvemento, probas continuas, entrega e aplicación do código de configuración aos servidores de produción.

Se isto non se fai inmediatamente, os roles escritos para a configuración deixarían de ser compatibles e modificados, ou deixarían de lanzarse en produción. A cura para esta dor é coñecida, e demostrouse neste proxecto:

• cada rol está cuberto por probas unitarias;
• as probas execútanse automaticamente sempre que hai algún cambio no código que xestiona as configuracións;
• os cambios no código de xestión de configuración son liberados no ambiente de produción só despois de pasar con éxito todas as probas e revisión do código.

O desenvolvemento de código e a xestión da configuración fixéronse máis tranquilos e previsibles. Para organizar as probas continuas, usamos o kit de ferramentas CI/CD de GitLab e tomamos Molécula Ansible.

Sempre que hai un cambio no código de xestión de configuración, GitLab CI/CD chama a Molecule:

• comproba a sintaxe do código,
• levanta o contedor Docker,
• aplica o código modificado ao contedor creado,
• comproba a idempotencia do rol e realiza probas para este código (a granularidade aquí está no nivel do rol ansible, consulte a figura 4).

Entregamos configuracións ao ambiente de produción mediante Ansible AWX. Os enxeñeiros de operacións aplicaron cambios de configuración a través de modelos predefinidos. AWX "solicitou" de forma independente a última versión do código da rama mestra de GitLab cada vez que se usaba. Deste xeito, excluímos o uso de código non probado ou desactualizado no ambiente de produción. Por suposto, o código entrou na rama mestra só despois de probar, revisar e aprobar.

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

Tamén hai un problema asociado ao funcionamento dos sistemas de produción. Na vida real, é moi difícil facer cambios de configuración só a través do código CMS. As situacións de emerxencia xorden cando un enxeñeiro debe cambiar a configuración "aquí e agora", sen esperar a edición do código, probas, aprobación, etc.

Como resultado, debido aos cambios manuais, aparecen discrepancias na configuración no mesmo tipo de equipo (por exemplo, a configuración de sysctl está configurada de forma diferente nos nodos do clúster HA). Ou a configuración real do equipo difire da especificada no código CMS.

Polo tanto, ademais das probas continuas, comprobamos os contornos de produción para detectar discrepancias de configuración. Escollemos a opción máis sinxela: executar o código de configuración do CMS en modo "función en seco", é dicir, sen aplicar cambios, pero con notificación de todas as discrepancias entre a configuración prevista e a real. Implementamos isto executando periodicamente todos os libros de xogo de Ansible coa opción "-check" nos servidores de produción. Como sempre, Ansible AWX encárgase de lanzar e manter o manual actualizado (consulte a figura 5):

Arroz. 5. Comproba discrepancias de configuración en Ansible AWX.

Despois das comprobacións, AWX envía un informe de discrepancia aos administradores. Estudan a configuración problemática e despois solucionan a través de libros de xogos axustados. Así mantemos a configuración no contorno de produción e o CMS está sempre actualizado e sincronizado. Isto elimina os "milagres" desagradables cando se usa código CMS en servidores de "produción".

Agora temos unha importante capa de proba formada por Ansible AWX/GitLab/Molecule (Figura 6).

Arroz. 6. Xestión de probas.

Difícil? Non discuto. Pero tal complexo de xestión de configuración converteuse nunha resposta completa a moitas preguntas relacionadas coa automatización da configuración do servidor. Agora, os servidores estándar dun comerciante sempre teñen unha configuración estrictamente definida. CMS, a diferenza dun enxeñeiro, non se esquecerá de engadir a configuración necesaria, crear usuarios e realizar decenas ou centos de configuracións necesarias.

Non hai "coñecemento secreto" na configuración dos servidores e ambientes hoxe en día. Todas as características necesarias están reflectidas no manual. Non máis creatividade e instrucións vagas: "Instálao como Oracle normal, pero cómpre especificar un par de configuracións sysctl e engadir usuarios co UID necesario. Pregúntalle aos mozos en operación, eles saben».

A capacidade de detectar discrepancias de configuración e corrixilas de forma proactiva proporciona tranquilidade. Sen un sistema de xestión de configuración, isto normalmente parece diferente. Os problemas acumúlanse ata que un día "se disparan" á produción. Despois realízase un debriefing, compróbanse e corrixen as configuracións. E o ciclo repítese de novo

E, por suposto, aceleramos o lanzamento dos servidores en funcionamento de varios días a horas.

Pois ben, na véspera de Ano Novo, cando os nenos desenvolvían os agasallos con alegría e os adultos pedían desexos mentres soaban as badaladas, os nosos enxeñeiros migraron o sistema SAP a novos servidores. Mesmo Papá Noel dirá que os mellores milagres son os que están ben preparados.

PS O noso equipo adoita atoparse co feito de que os clientes queren resolver os problemas de xestión da configuración da forma máis sinxela posible. Ideal, coma por arte de maxia, cunha soa ferramenta. Pero na vida todo é máis complicado (si, as balas de prata non se volveron a entregar): hai que crear todo un proceso utilizando ferramentas convenientes para o equipo do cliente.

Autor: Sergey Artemov, arquitecto do departamento Solucións DevOps "Jet Infosystems"

Fonte: www.habr.com