Esta é uma transcrição do discurso и .
Esta é a história de um projeto que usou um sistema de gerenciamento de configuração escrito por você mesmo e por que a mudança para o Ansible levou 18 meses.
Dia nº -ХХХ: Antes do início
Inicialmente, a infraestrutura consistia em muitos hosts separados executando o Hyper-V. A criação de uma máquina virtual exigiu muitas etapas: colocar os discos no lugar certo, registrar o DNS, reservar o DHCP, colocar a configuração da VM no repositório git. Esse processo foi parcialmente mecanizado, mas, por exemplo, as VMs foram distribuídas manualmente entre os hosts. Mas, por exemplo, os desenvolvedores poderiam corrigir a configuração da VM no git e aplicá-la reiniciando a VM.
Solução de gerenciamento de configuração personalizada
A ideia original, suspeito, foi concebida como IaC: muitas VMs sem estado que redefinem seu estado para zero quando reiniciadas. O que foi gerenciamento de configuração de VM? Esquematicamente parece simples:
- Um MAC estático foi definido para a VM.
- Um ISO com CoreOS e um disco de inicialização foram conectados à VM.
- CoreOS inicia o script de personalização baixando-o do servidor WEB com base em seu IP.
- O script baixa a configuração da VM via SCP com base no endereço IP.
- A base dos arquivos de unidade do systemd e a base dos scripts bash são iniciadas.
Esta solução teve muitos problemas óbvios:
- CoreOS ISO foi descontinuado.
- Muitas ações automatizadas complexas e mágica ao migrar/criar VMs.
- Dificuldade de atualização e quando é necessária uma determinada versão do software. Ainda mais divertido com módulos do kernel.
- As VMs não foram obtidas sem dados, ou seja, As VMs apareceram com um disco com dados adicionais do usuário montados.
- Alguém estava constantemente bagunçando as dependências da unidade do systemd e o CoreOS congelava ao reiniciar. Foi difícil perceber isso usando as ferramentas disponíveis no CoreOS.
- Gerenciamento de segredos.
- Não houve CM. Havia configurações bash e YML para CoreOS.
Para aplicar a configuração da VM, é necessário reinicializá-la, mas ela pode não ser reinicializada. Parece um problema óbvio, mas não há discos permanentes - não há onde salvar os logs. Bom, ok, vamos tentar adicionar a opção de carregamento do kernel para que os logs sejam enviados. Mas não, como tudo é complicado.
Dia #0: Reconheça o problema
Era a infraestrutura de desenvolvimento usual: jenkins, ambientes de teste, monitoramento, registro. CoreOS foi projetado para hospedar clusters k8s, ou seja, o problema era como o CoreOS era usado. O primeiro passo foi escolher uma pilha. Nós decidimos:
- CentOS como uma distribuição base, porque Esta é a distribuição mais próxima dos ambientes de produção.
- Ansible para gerenciamento de configuração, porque houve um exame extensivo sobre isso.
- Jenkins como uma estrutura para automatizar processos existentes, porque já foi usado ativamente para processos de desenvolvimento
- Hyper-V como plataforma de virtualização. Há uma série de razões que vão além do escopo da história, mas em resumo – não podemos usar as nuvens, devemos usar nosso próprio hardware.
Dia nº 30: Reparando acordos existentes - Acordos como Código
Quando a pilha ficou limpa, começaram os preparativos para a mudança. Fixação de acordos existentes na forma de código (Acordos como Código!). Transição trabalho manual -> mecanização -> automação.
1. Configurar VMs
Ansible faz um ótimo trabalho nisso. Com um mínimo de movimentos corporais você pode assumir o controle das configurações da VM:
- Crie um repositório git.
- Colocamos a lista de VMs no inventário, as configurações nos playbooks e nas funções.
- Estamos configurando um escravo jenkins especial a partir do qual você pode executar o Ansible.
- Criamos um trabalho e configuramos o Jenkins.
O primeiro processo está pronto. Os acordos são fixos.
2. Crie uma nova VM
Tudo aqui não era muito conveniente. Não é muito conveniente criar VMs no Hyper-V a partir do Linux. Uma das tentativas de mecanizar esse processo foi:
- Ansbile se conecta via WinRM ao host do Windows.
- Ansible executa um script do PowerShell.
- O script Powershell cria uma nova VM.
- Usando Hyper-V/ScVMM, ao criar uma VM no sistema operacional convidado, o nome do host é configurado.
- Ao atualizar a concessão de DHCP, a VM envia seu nome de host.
- A integração padrão de ddns e dhcp no lado do controlador de domínio configura o registro DNS.
- Você pode adicionar uma VM ao seu inventário e configurá-la com Ansible.
3.Criar modelo de VM
Eles não inventaram nada aqui - pegaram um empacotador.
- Adicione o empacotador e a configuração do kickstart ao repositório git.
- Configurando um escravo Jenkins especial com Hyper-V e Packer.
- Criamos um trabalho e configuramos o Jenkins.
Como funciona esse link:
- O Packer cria uma VM vazia e pega o ISO.
- A VM inicializa, o Packer insere o comando no bootloader para usar nosso arquivo kickstart de um disquete ou http.
- O Anaconda é iniciado com nossa configuração e a configuração inicial do sistema operacional é feita.
- O Packer espera que a VM fique disponível.
- O Packer dentro da VM executa o ansible no modo local.
- Ansible usa exatamente as mesmas funções que funciona na etapa 1.
- O Packer exporta o modelo VM.
Dia #75: Refatorar o acordo sem quebrar = Test ansible + Testkitchen
Capturar convenções em código pode não ser suficiente. Afinal, se nos meandros do processo você quiser mudar alguma coisa, você pode quebrar alguma coisa. Portanto, no caso da infraestrutura, aparecem os testes dessa mesma infraestrutura. Para sincronizar o conhecimento dentro da equipe, começamos a testar as funções do Ansible. Não vou me aprofundar porque... há um artigo descrevendo os eventos naquele momento (spoiler essa não era a versão final e depois tudo ficou mais complicado ).
Dia #130: Talvez o CentOS+ansible não seja necessário? talvez openshift?
Devemos compreender que o processo de introdução de infra-estruturas não foi o único e que houve subprojectos paralelos. Por exemplo, chegou uma solicitação para lançar nosso aplicativo em openshift e isso resultou em pesquisas de mais de uma semana o que retardou o processo de mudança. O resultado foi que o openshift não cobre todas as necessidades; você precisa de hardware real, ou pelo menos a capacidade de brincar com o kernel.
Dia #170: Openshift não é adequado, vamos arriscar com o Windows Azure Pack?
O Hyper-V não é muito amigável, o SCVMM não o torna muito melhor. Mas existe o Windows Azure Pack, que é um complemento do SCVMM e imita o Azure. Mas na realidade o produto parece abandonado: a documentação tem links quebrados e é muito escassa. Mas como parte do estudo de opções para simplificar a vida da nossa nuvem, eles também analisaram isso.
Dia #250: Windows Azure Pack não é muito bom. Permanecemos no SCVMM
O Windows Azure Pack parecia promissor, mas foi decidido não trazer o WAP com suas complexidades para o sistema por causa de recursos desnecessários e permaneceu com o SCVMM.
Dia #360: Comer o elefante pedaço por pedaço
Apenas um ano depois a plataforma de mudança estava pronta e o processo de mudança começou. Para tanto, foi definida uma tarefa SMART. Verificamos todas as VMs e começamos a descobrir a configuração uma por uma, descrevê-la em Ansible e cobri-la com testes.
Dia #450: Que tipo de sistema você comprou?
O processo em si não é interessante. É rotineiro, pode-se notar que a maioria das configurações eram relativamente simples ou isomórficas e segundo o princípio de Pareto, 80% das configurações de VM necessitavam de 20% do tempo. Pelo mesmo princípio, 80% do tempo foi gasto na preparação da mudança e apenas 20% na própria mudança.
Dia #540: Final
O que aconteceu em 18 meses?
- Os acordos tornaram-se um código.
- Trabalho manual -> Mecanização -> Automação.
Ligações Úteis
Fonte: habr.com