O equipamento chegou ao local vários meses antes do pico de vendas. O serviço de manutenção, é claro, sabe como e o que configurar nos servidores para introduzi-los no ambiente de produção. Mas precisávamos automatizar isso e eliminar o fator humano. Além disso, os servidores foram substituídos antes da migração de um conjunto de sistemas SAP essenciais para a empresa.
O comissionamento de novos servidores estava rigidamente vinculado a um prazo. E movê-lo colocaria em risco o envio de bilhões de presentes e a migração de sistemas. Mesmo uma equipe composta por Papai Noel e Papai Noel não poderia alterar a data - o sistema SAP para gerenciamento de depósito pode ser transferido apenas uma vez por ano. De 31 de dezembro a 1º de janeiro, os enormes armazéns do varejista, um total de 20 campos de futebol, param suas obras por 15 horas. E este é o único período de tempo para o sistema se mover. Não tínhamos o direito de errar ao entrar nos servidores.
Deixe-me explicar agora: minha história reflete o tipo de ferramentas e processo de gerenciamento de configuração que nossa equipe usa.
O complexo de gerenciamento de configuração consiste em vários níveis. O principal componente é o sistema CMS. Na exploração industrial, a ausência de um dos níveis levaria inevitavelmente a milagres desagradáveis.
Gerenciamento de instalação do sistema operacional
O primeiro nível é o sistema de gerenciamento da instalação de sistemas operacionais em servidores físicos e virtuais. Ele cria configurações básicas do sistema operacional, eliminando o fator humano.
Com a ajuda deste sistema, recebemos padrão e adequados para outras instâncias de automação de servidores com SO. Quando foram lançados, eles receberam um conjunto mínimo de usuários locais e chaves SSH públicas, bem como uma configuração de sistema operacional consistente. Tínhamos a garantia de gerenciar os servidores por meio do CMS e estávamos certos de que não havia surpresas “abaixo”, no nível do SO.
O objetivo máximo para o sistema de gerenciamento de instalação é configurar automaticamente os servidores do nível BIOS / Firmware para o SO. Muito depende do hardware e das tarefas de configuração. Para equipamentos diferentes, considere o REDFISH API... Se todo o hardware for de um fornecedor, geralmente é mais conveniente usar ferramentas de gerenciamento prontas (por exemplo, HP ILO Amplifier, DELL OpenManage, etc.).
Para instalar o SO nos servidores físicos, utilizamos o conhecido Cobbler, que define um conjunto de perfis de instalação coordenados com o serviço de manutenção. Ao adicionar um novo servidor à infraestrutura, o engenheiro vincula o endereço MAC do servidor ao perfil necessário no Cobbler. Na primeira inicialização pela rede, o servidor recebeu um endereço temporário e um novo sistema operacional. Em seguida, ele foi transferido para o endereçamento VLAN / IP de destino e continuou a funcionar lá. Sim, a alteração de VLANs leva tempo e requer coordenação, mas fornece proteção adicional contra instalação acidental de servidor em um ambiente de produção.
Criamos servidores virtuais com base em modelos preparados usando HashiCorp Packer. O motivo era o mesmo: evitar possíveis erros humanos na instalação do SO. Mas, ao contrário dos servidores físicos, o Packer permite que você não use PXE, inicialização de rede e alteração de VLAN. Isso tornou mais fácil e simples criar servidores virtuais.
Figura: 1. Gerenciamento de instalação de sistemas operacionais.
Gerenciamento de segredo
Qualquer sistema de gerenciamento de configuração contém dados que devem ser ocultados dos usuários comuns, mas necessários para preparar os sistemas. Essas são senhas de usuários locais e contas de serviço, chaves de certificado, vários tokens de API, etc. Normalmente são chamados de "segredos".
Se desde o início não for determinado onde e como armazenar esses segredos, então, dependendo da gravidade dos requisitos de IS, os seguintes métodos de armazenamento são prováveis:
- direito no código de gerenciamento de configuração ou em arquivos no repositório;
- em ferramentas de gerenciamento de configuração especializadas (por exemplo, Ansible Vault);
- em sistemas CI / CD (Jenkins / TeamCity / GitLab /, etc.) ou em sistemas de gerenciamento de configuração (Ansible Tower / Ansible AWX);
- também segredos podem ser transferidos para "controle manual". Por exemplo, eles são dispostos em um local acordado e, em seguida, são usados por sistemas de gerenciamento de configuração;
- várias combinações das opções acima.
Cada método tem suas próprias desvantagens. O principal deles é a ausência de políticas de acesso a segredos: é impossível ou difícil determinar quem pode usar determinados segredos. Outra desvantagem é a falta de auditoria de acesso e um ciclo de vida completo. Como substituir rapidamente, por exemplo, uma chave pública, que é escrita no código e em vários sistemas relacionados?
Usamos o HashiCorp Vault centralizado. Isso nos permitiu:
- mantenha os segredos seguros. Eles são criptografados e, mesmo que alguém obtenha acesso ao banco de dados do Vault (por exemplo, restaurando-o de um backup), não será capaz de ler os segredos armazenados nele;
- . «» ;
- . Vault;
- « » . , , . .
- , ;
- , , ..
Agora vamos passar para o sistema central de autenticação e autorização. Você poderia passar sem ele, mas administrar usuários em muitos sistemas relacionados é muito trivial. Configuramos autenticação e autorização por meio do serviço LDAP. Caso contrário, o mesmo Vault teria que emitir e manter registros de tokens de autenticação para os usuários continuamente. E excluir e adicionar usuários se transformaria em uma missão "Eu criei / excluí este UZ em todos os lugares?"
Adicionamos mais um nível ao nosso sistema: gestão de segredos e autenticação / autorização central:
Figura: 2. Gerenciamento de segredos.
Gerenciamento de configurações
Chegamos ao núcleo - ao sistema CMS. No nosso caso, este é um monte de Ansible e Red Hat Ansible AWX.
Chef, Puppet, SaltStack podem atuar no lugar de Ansible. Escolhemos o Ansible por vários motivos.
- Primeiro, é versatilidade. O conjunto de módulos prontos para controle é impressionante . E se você não tiver o suficiente, você pode pesquisar no GitHub e no Galaxy.
- Em segundo lugar, não há necessidade de instalar e manter agentes em equipamentos controlados, para provar que eles não interferem na carga e para confirmar a ausência de "marcadores".
- Terceiro, o Ansible tem uma barreira baixa de entrada. Um engenheiro competente escreverá um manual de trabalho literalmente no primeiro dia de trabalho com o produto.
Mas o Ansible sozinho não foi suficiente para nós em um ambiente industrial. Caso contrário, haveria muitos problemas com a restrição de acesso e auditoria das ações dos administradores. Como diferenciar o acesso? Afinal, cada divisão precisava gerenciar (leia - execute o manual do Ansible) "seu" conjunto de servidores. Como permitir que apenas alguns funcionários executem manuais específicos da Ansible? Ou como rastrear quem lançou um manual sem executar muitos KMs locais nos servidores e hardware Ansible?
O Red Hat Ansible Tower ou seu projeto upstream Ansible AWX de código aberto resolve a maior parte desses problemas . Portanto, nós o preferimos para o cliente.
E mais um toque no retrato do nosso sistema CMS. Um playbook deve ser armazenado em sistemas de gerenciamento de repositório de código. Temos esse GitLab CE .
Portanto, as próprias configurações são gerenciadas pelo pacote de Ansible / Ansible AWX / GitLab (ver Fig. 3). Obviamente, o AWX / GitLab está integrado a um sistema de autenticação unificado e o manual do Ansible está integrado ao HashiCorp Vault. As configurações entram no ambiente de produção apenas por meio do Ansible AWX, no qual todas as "regras do jogo" são definidas: quem pode configurar o quê, onde obter o código de gerenciamento de configuração para o CMS, etc.
Figura: 3. Gerenciamento de configuração.
Gerenciamento de teste
Nossa configuração é apresentada como um código. Portanto, somos forçados a jogar pelas mesmas regras que os desenvolvedores de software. Precisávamos organizar os processos de desenvolvimento, testes contínuos, entrega e aplicação do código de configuração aos servidores de produção.
Se isso não fosse feito imediatamente, as funções escritas para configuração parariam de ser mantidas e modificadas ou parariam de funcionar na produção. A cura para essa dor é conhecida e valeu a pena neste projeto:
- cada função é coberta por testes de unidade;
- os testes são executados automaticamente sempre que houver uma alteração no código de gerenciamento de configuração;
- mudanças no código de gerenciamento de configuração entram no ambiente de produção somente depois de passar com sucesso em todos os testes e revisão de código.
O desenvolvimento de código e o gerenciamento de configuração são mais calmos e previsíveis. Para organizar testes contínuos, usamos o kit de ferramentas GitLab CI / CD e pegamos o Ansible Molecule como uma estrutura para organizar testes .
Para qualquer mudança no código de gerenciamento de configuração, o GitLab CI / CD chama Molecule:
- ele verifica a sintaxe do código,
- levanta o contêiner Docker,
- aplica o código modificado ao contêiner criado,
- verifica o papel para idempotência e executa testes para este código (a granularidade aqui está no nível de papel ansible, consulte a Fig. 4).
Fornecemos configurações para o ambiente de produção usando o Ansible AWX. Os engenheiros operacionais aplicaram mudanças de configuração por meio de modelos predefinidos. O AWX "solicitou" independentemente a versão mais recente do código do branch master do GitLab toda vez que era usado. Desta forma, excluímos o uso de código não testado ou desatualizado no ambiente de produção. Naturalmente, o código entrou no branch master somente após teste, revisão e aprovação.
Figura: 4. Teste automático de funções no GitLab CI / CD.
Também existe um problema relacionado ao funcionamento dos sistemas de produção. Na vida real, é muito difícil fazer alterações na configuração apenas por meio do código CMS. Situações anormais surgem quando um engenheiro deve alterar a configuração "aqui e agora" sem esperar pela edição do código, teste, aprovação, etc.
Como resultado, devido a alterações manuais, discrepâncias aparecem na configuração no mesmo tipo de equipamento (por exemplo, nos nós do HA-cluster configuração diferente das configurações do sysctl). Ou a configuração real no hardware é diferente daquela especificada no código CMS.
Portanto, além de testes contínuos, verificamos os ambientes de produção quanto a discrepâncias de configuração. Escolhemos a opção mais simples: executar o código de configuração do CMS no modo "dry run", ou seja, sem aplicar alterações, mas com notificação de todas as discrepâncias entre a configuração planejada e real. Implementamos isso executando periodicamente todos os manuais do Ansible com a opção "--check" nos servidores de produção. O Ansible AWX, como sempre, é responsável pelo lançamento e relevância do manual (consulte a Fig. 5):
Figura: 5. Verifica discrepâncias de configuração no Ansible AWX.
Após as verificações, o AWX envia um relatório de discrepância aos administradores. Eles estudam a configuração do problema e, em seguida, corrigem por meio do manual ajustado. Desta forma mantemos a configuração no ambiente de produção e o CMS está sempre atualizado e sincronizado. Isso elimina os "milagres" desagradáveis quando o código CMS é aplicado em servidores de "produção".
Agora temos uma camada de teste importante que consiste em Ansible AWX / GitLab / Molecule (Figura 6).
Figura: 6. Gerenciamento de teste.
Difícil? Eu não discuto. Mas esse complexo de gerenciamento de configuração tornou-se uma resposta abrangente a muitas perguntas relacionadas à automação da configuração do servidor. Agora, o varejista sempre tem uma configuração estritamente definida para servidores padrão. O CMS, ao contrário de um engenheiro, não se esquecerá de adicionar as configurações necessárias, criar usuários e realizar dezenas ou centenas de configurações necessárias.
Não há "conhecimento secreto" nas configurações de servidores e ambientes hoje. Todos os recursos necessários são refletidos no manual. Chega de criatividade e instruções vagas: “ coloque como um Oracle normal, mas aí você precisa registrar algumas configurações de sysctl e adicionar usuários com o UID necessário. Pergunte aos caras da operação, eles sabem . "
A capacidade de detectar discrepâncias nas configurações e corrigi-las com antecedência proporciona tranquilidade. Sem um CMS, isso geralmente parece diferente. Os problemas se acumulam até que um dia são "disparados" na produção. Em seguida, o debriefing é realizado, as configurações são verificadas e corrigidas. E o ciclo se repete novamente
E, claro, aceleramos o lançamento de servidores em produção de alguns dias para horas.
Bem, na própria véspera de Ano Novo, quando as crianças desembrulhavam presentes alegremente e os adultos faziam pedidos enquanto o carrilhão tocava, nossos engenheiros migraram o sistema SAP para novos servidores. Até o Papai Noel dirá que os melhores milagres são aqueles bem preparados.
PS Nossa equipe muitas vezes se depara com o fato de que os clientes desejam resolver o problema de gerenciamento de configuração o mais facilmente possível. Idealmente, como por mágica - com uma ferramenta. Mas na vida tudo é mais complicado (sim, mais uma vez não se entregaram balas de prata): é preciso criar todo um processo com a ajuda de ferramentas convenientes para a equipe do cliente.
Autor: Sergey Artemov, arquiteto do departamento de soluções DevOps da Jet Infosystems