Estava se aproximando do Ano Novo. Crianças de todo o país já haviam enviado cartas ao Papai Noel ou feito presentes para si mesmas, e seu principal executor, um dos grandes varejistas, se preparava para a apoteose das vendas. Em dezembro, a carga em seu data center aumenta várias vezes. Por isso, a empresa decidiu modernizar o data center e colocar em operação várias dezenas de novos servidores em vez de equipamentos que estavam chegando ao fim de sua vida útil. Isso termina a história tendo como pano de fundo flocos de neve rodopiantes e o thriller começa.
Os equipamentos chegaram ao local vários meses antes do pico de vendas. O serviço de operações, claro, sabe como e o que configurar nos servidores para trazê-los para o 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 críticos para a empresa.
O comissionamento de novos servidores estava estritamente vinculado a um prazo. E movê-lo significava pôr em risco tanto o envio de mil milhões de presentes como a migração de sistemas. Mesmo uma equipe formada por Papai Noel e Papai Noel não conseguiu alterar a data - é possível transferir o sistema SAP para gerenciamento de armazém apenas uma vez por ano. De 31 de dezembro a 1º de janeiro, os enormes armazéns da varejista, do tamanho total de 20 campos de futebol, param de funcionar por 15 horas. E este é o único período de tempo para movimentar o sistema. Não tivemos margem para erros ao introduzir servidores.
Deixe-me ser claro: minha história reflete as ferramentas e o processo de gerenciamento de configuração que nossa equipe usa.
O complexo de gerenciamento de configuração consiste em vários níveis. O componente principal é o sistema CMS. Na operaçã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 é um sistema para gerenciar a instalação de sistemas operacionais em servidores físicos e virtuais. Ele cria configurações básicas de sistema operacional, eliminando o fator humano.
Usando este sistema, obtivemos instâncias de servidor padrão com sistema operacional adequado para automação adicional. Durante o “derramamento”, 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 através do CMS e tínhamos a certeza de que não haveria surpresas “lá embaixo” no nível do sistema operacional.
A tarefa "máxima" do sistema de gerenciamento de instalação é configurar automaticamente os servidores desde o nível BIOS/Firmware até o sistema operacional. Muito aqui depende do equipamento e das tarefas de configuração. Para equipamentos heterogêneos, você pode considerar . 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 em servidores físicos, utilizamos o conhecido Cobbler, que define um conjunto de perfis de instalação acordados com o serviço de operação. Ao adicionar um novo servidor à infraestrutura, o engenheiro vinculou o endereço MAC do servidor ao perfil necessário no Cobbler. Ao inicializar pela rede pela primeira vez, 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 o trabalho lá. Sim, alterar a VLAN leva tempo e requer coordenação, mas fornece proteção adicional contra instalação acidental do servidor em um ambiente de produção.
Criamos servidores virtuais baseados em templates preparados usando HashiСorp Packer. O motivo foi o mesmo: evitar possíveis erros humanos na instalação do SO. Mas, diferentemente dos servidores físicos, o Packer elimina a necessidade de PXE, inicialização de rede e alterações de VLAN. Isso tornou mais fácil e simples a criação de servidores virtuais.
Arroz. 1. Gerenciando a instalação de sistemas operacionais.
Gerenciando segredos
Qualquer sistema de gerenciamento de configuração contém dados que deveriam ser ocultados dos usuários comuns, mas são necessários para preparar os sistemas. Estas são senhas para usuários locais e contas de serviço, chaves de certificado, vários tokens de API, etc. Geralmente são chamados de “segredos”.
Se você não determinar desde o início onde e como armazenar esses segredos, então, dependendo da gravidade dos requisitos de segurança da informação, os seguintes métodos de armazenamento serão prováveis:
- diretamente no código de controle de configuração ou em arquivos do repositório;
- em ferramentas especializadas de gerenciamento de configuração (por exemplo, Ansible Vault);
- em sistemas CI/CD (Jenkins/TeamCity/GitLab/etc.) ou em sistemas de gerenciamento de configuração (Ansible Tower/Ansible AWX);
- os segredos também podem ser transferidos “manualmente”. Por exemplo, eles são dispostos em um local específico e depois usados por sistemas de gerenciamento de configuração;
- várias combinações dos itens acima.
Cada método tem suas próprias desvantagens. A principal delas é a falta 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 de ciclo de vida completo. Como substituir rapidamente, por exemplo, uma chave pública que está escrita no código e em vários sistemas relacionados?
Usamos o armazenamento secreto centralizado HashiCorp Vault. 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 a partir de um backup), não será capaz de ler os segredos ali armazenados;
- organizar políticas para acesso a segredos. Apenas os segredos “alocados” a eles ficam disponíveis para usuários e aplicações;
- auditar o acesso a segredos. Quaisquer ações com segredos são registradas no log de auditoria do Vault;
- organize um “ciclo de vida” completo de trabalho com segredos. Eles podem ser criados, revogados, definir uma data de validade, etc.
- fácil integração com outros sistemas que necessitam de acesso a segredos;
- e também usar criptografia ponta a ponta, senhas de uso único para sistema operacional e banco de dados, certificados de centros autorizados, etc.
Agora vamos passar para o sistema central de autenticação e autorização. Era possível passar sem ele, mas administrar usuários em muitos sistemas relacionados não é nada trivial. Configuramos autenticação e autorização através do serviço LDAP. Caso contrário, o Vault teria que emitir e monitorar continuamente tokens de autenticação para os usuários. E excluir e adicionar usuários se transformaria em uma busca “criei/excluí esta conta de usuário em todos os lugares?”
Adicionamos outro nível ao nosso sistema: gerenciamento de segredos e autenticação/autorização central:
Arroz. 2. Gerenciamento de segredos.
Gerenciamento de configurações
Chegamos ao cerne - o sistema CMS. No nosso caso, esta é uma combinação de Ansible e Red Hat Ansible AWX.
Em vez de Ansible, Chef, Puppet, SaltStack podem ser usados. Escolhemos o Ansible com base em vários critérios.
- Em primeiro lugar, é versatilidade. Um conjunto de módulos prontos para controle . E se você não tiver o suficiente, pode pesquisar no GitHub e no Galaxy.
- Em segundo lugar, não há necessidade de instalar e apoiar agentes nos equipamentos gerenciados, provar que não interferem na carga e confirmar a ausência de “bookmarks”.
- Em terceiro lugar, o Ansible tem uma barreira de entrada baixa. Um engenheiro competente escreverá um manual de trabalho literalmente no primeiro dia de trabalho com o produto.
Mas o Ansible sozinho em um ambiente de produção não foi suficiente para nós. Caso contrário, surgiriam muitos problemas com a restrição de acesso e a auditoria das ações dos administradores. Como restringir o acesso? Afinal, era necessário que cada departamento gerenciasse (leia-se: execute o manual do Ansible) “seu próprio” conjunto de servidores. Como permitir que apenas determinados funcionários executem manuais específicos do Ansible? Ou como rastrear quem lançou o playbook sem configurar muito conhecimento local em servidores e equipamentos que executam o Ansible?
A maior parte desses problemas é resolvida pela Red Hat , ou seu projeto upstream de código aberto . É por isso que preferimos isso para o cliente.
E mais um toque no retrato do nosso sistema CMS. O playbook Ansible deve ser armazenado em sistemas de gerenciamento de repositório de código. Nós temos isso .
Portanto, as próprias configurações são gerenciadas por uma combinação de Ansible/Ansible AWX/GitLab (ver Fig. 3). Obviamente, o AWX/GitLab está integrado a um único sistema de autenticação, e o playbook Ansible está integrado ao HashiCorp Vault. As configurações entram no ambiente de produção apenas através do Ansible AWX, no qual são especificadas todas as “regras do jogo”: quem pode configurar o quê, onde obter o código de gerenciamento de configuração do CMS, etc.
Arroz. 3. Gerenciamento de configuração.
Gerenciamento de testes
Nossa configuração é apresentada em forma de código. Portanto, somos forçados a seguir as mesmas regras dos desenvolvedores de software. Precisávamos organizar os processos de desenvolvimento, testes contínuos, entrega e aplicação de código de configuração nos servidores de produção.
Se isso não for feito imediatamente, as funções escritas para a configuração deixarão de ser suportadas e modificadas ou deixarão de ser lançadas em produção. A cura para esta dor é conhecida e comprovou-se neste projeto:
- cada função é coberta por testes unitários;
- os testes são executados automaticamente sempre que há alguma alteração no código que gerencia as configurações;
- alterações no código de gerenciamento de configuração são liberadas no ambiente de produção somente após aprovação em todos os testes e revisão de código.
O desenvolvimento de código e o gerenciamento de configuração tornaram-se mais calmos e previsíveis. Para organizar testes contínuos, usamos o kit de ferramentas GitLab CI/CD e pegamos .
Sempre que há uma alteração no código de gerenciamento de configuração, o CI/CD do GitLab chama o Molecule:
- verifica a sintaxe do código,
- levanta o contêiner Docker,
- aplica o código modificado ao contêiner criado,
- verifica a idempotência da função e executa testes para este código (a granularidade aqui está no nível da função ansible, consulte a Fig. 4).
Entregamos configurações para o ambiente de produção usando Ansible AWX. Os engenheiros de operações aplicaram alterações de configuração por meio de modelos predefinidos. O AWX “solicitou” de forma independente a versão mais recente do código do branch master do GitLab sempre que ele 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.
Arroz. 4. Teste automático de funções no GitLab CI/CD.
Existe também um problema associado ao funcionamento dos sistemas de produção. Na vida real, é muito difícil fazer alterações na configuração apenas através do código CMS. Situações emergenciais surgem quando um engenheiro deve alterar a configuração “aqui e agora”, sem esperar pela edição do código, testes, aprovação, etc.
Como resultado, devido a alterações manuais, aparecem discrepâncias na configuração no mesmo tipo de equipamento (por exemplo, as configurações do sysctl são configuradas de forma diferente nos nós do cluster HA). Ou a configuração real do equipamento difere daquela especificada no código CMS.
Portanto, além dos testes contínuos, verificamos os ambientes de produção em busca de discrepâncias de configuração. Escolhemos a opção mais simples: executar o código de configuração do CMS em modo “dry run”, ou seja, sem aplicar alterações, mas com notificação de todas as discrepâncias entre a configuração planejada e a real. Implementamos isso executando periodicamente todos os playbooks do Ansible com a opção “—check” nos servidores de produção. Como sempre, o Ansible AWX é responsável por lançar e manter o playbook atualizado (ver Fig. 5):
Arroz. 5. Verifica discrepâncias de configuração no Ansible AWX.
Após as verificações, o AWX envia um relatório de discrepâncias aos administradores. Eles estudam a configuração problemática e depois a corrigem por meio de manuais ajustados. É assim que mantemos a configuração no ambiente de produção e o CMS está sempre atualizado e sincronizado. Isso elimina “milagres” desagradáveis quando o código CMS é usado em servidores de “produção”.
Agora temos uma importante camada de testes que consiste em Ansible AWX/GitLab/Molecule (Figura 6).
Arroz. 6. Gerenciamento de testes.
Difícil? Eu não discuto. Mas tal complexo de gerenciamento de configuração tornou-se uma resposta abrangente para muitas questões relacionadas à automação da configuração do servidor. Agora, os servidores padrão de um varejista sempre têm uma configuração estritamente definida. 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 existe hoje “conhecimento secreto” nas configurações de servidores e ambientes. Todos os recursos necessários estão refletidos no manual. Chega de criatividade e instruções vagas: “Instale-o como o Oracle normal, mas você precisa especificar algumas configurações de sysctl e adicionar usuários com o UID necessário. Pergunte ao pessoal da operação, eles sabem".
A capacidade de detectar discrepâncias de configuração e corrigi-las proativamente proporciona tranquilidade. Sem um sistema de gerenciamento de configuração, isso geralmente parece diferente. Os problemas se acumulam até que um dia eles “disparam” para a produção. Em seguida é realizado um debriefing, as configurações são verificadas e corrigidas. E o ciclo se repete novamente
E, claro, aceleramos o lançamento dos servidores em operação de vários dias para horas.
Bem, na própria véspera de Ano Novo, quando as crianças desembrulhavam presentes alegremente e os adultos faziam desejos ao som do sino, nossos engenheiros migraram o sistema SAP para novos servidores. Até o Papai Noel dirá que os melhores milagres são aqueles que estão bem preparados.
PS Nossa equipe frequentemente se depara com o fato de que os clientes desejam resolver problemas de gerenciamento de configuração da maneira mais simples possível. Idealmente, como num passe de mágica - com uma ferramenta. Mas na vida tudo é mais complicado (sim, as soluções mágicas não foram entregues novamente): é preciso criar todo um processo usando ferramentas que sejam convenientes para a equipe do cliente.
Autor: Sergey Artemov, arquiteto do departamento "Infosistemas a Jato"
Fonte: habr.com
