O Ansible é um sistema que resolve várias tarefas de automação, incluindo projetos de configuração, backup e implantação. É agradável usar o sistema para escrever scripts de automação de um ambiente simples para um projeto grande. Nos scripts, os playbooks desempenham um papel importante e os playbooks estruturados desempenham papéis.
Ansible não é uma pílula mágica e só ajuda a princípio. Quando um projeto cresce, fica difícil manter um número expandido de funções. O mecanismo de entrega contínua de funções ajuda a resolver o problema.
Apenas sobre isso, a decodificação do relatório de
Alexander Kharkevich no
DevOps Conf Russia . No relatório: desenvolvimento de funções Ansible por meio do IC, um mecanismo para desenvolver funções e funções públicas com execuções de teste em uma infraestrutura privada. E não há conclusão no relatório.
Sobre o palestrante : Alexander Kharkevich (
kharkevich ) engenheiro de sistemas sênior da
EPAM Systems .
Vamos começar com uma rápida visão geral.
Sobre Ansible
Ansible é um sistema de gerenciamento de configuração. Está escrito em Python, modelado por Junja, e o YAML é usado como DSL. Gerenciado através da Ansible Tower - WebUI para gerenciar e monitorar o desempenho do sistema.
O Ansible apareceu em 2012, após 3 anos que a Red Hat comprou o projeto inteiro e, dois anos depois, lançou o AWX - Project Open Source versão do Ansible Tower.
Instalação
Para usar o Ansible, você precisa fazer duas coisas simples.
No primeiro estágio, compile um arquivo de inventário no caso de uma infraestrutura estática.
O segundo é escrever um manual que traga o sistema ao estado esperado.
Freqüentemente, temos um desejo irresistível de escrever automação, que pode ser reutilizada novamente. A automação é um bom desejo, e os caras da Ansible criaram um conceito interessante - o papel.
Função
Essa é uma entidade estruturada que levará o sistema ao estado esperado com a capacidade de reutilizar a automação.
Por exemplo, podemos escrever uma função para o Oracle Java: pegue um Playbook, coloque uma função e aplique-a ao sistema de destino. A saída obterá o Java instalado.
Como imaginamos trabalhar com funções
Como o Ansible tem papéis maravilhosos, pensamos que agora assumiríamos e escreveríamos muitos, muitos papéis para todas as ocasiões, brincaríamos e reutilizávamos para reduzir a quantidade de trabalho.
Pensamos em escrever papéis bonitos e inteligentes ...
Mas a vida acabou sendo mais complicada.
Como se viu, na verdade
Quando mais de uma pessoa trabalha para escrever ou melhorar um papel, todos escrevem em um só lugar e surgem surpresas desagradáveis: o papel não se comporta como o pretendido originalmente pelo autor.
É bom quando aplicado até o fim, mas isso nem sempre acontece. Às vezes, uma função é executada com êxito, mas no sistema de destino isso não afeta de maneira alguma como originalmente desejado.
Como resultado, surgem construções terríveis, tentativas de transferir o bash para o Ansible e enviar tudo isso sob o gerenciamento de configuração. Encontramos esse fenômeno e ficamos tristes.
Pensando, descobrimos que em nosso gerenciamento de configuração existe algum tipo de código, o que significa que as práticas que se aplicam ao gerenciamento de código no Ciclo de Vida de Desenvolvimento de Sistemas também são aplicáveis no Ansible.
- Colete as melhores práticas.
- Aplique análise estática, fiapos.
- Para testar.
- Para fazer overclock, entrar no Gerenciamento de versão.
Decidimos implementar a prática em casa e fomos imediatamente procurar ferramentas adequadas.
As ferramentas
Do ponto de vista dos sistemas de controle de versão e integração contínua, existem dezenas de soluções disponíveis e um zoológico de testes com muitos ramos.
Do ponto de vista do gerenciamento de versões no Ansible, não existem muitas soluções: marcar no Git ou marcar no Git e fazer upload no Galaxy.
Existem muitas abordagens para ferramentas de teste, cada uma usando o que elas gostam. Soluções populares usando KitchenCI, InSpec, Serverspec.
Nossa alma não mentiu para pegar o Ansible escrito em Python e misturar ferramentas do mundo Ruby. Portanto, tendo descartado tudo o que não é nativo do mundo Python, obtivemos a seguinte imagem.
Nós usamos:
- Para gerenciamento de configuração - GitHub e GitLab. O GitLab está assistindo diretamente no GitHub. Por que fez isso, vou contar mais tarde.
- Para a CI, levamos Travis para a parte pública e GitLab Runner para a parte privada.
- Molécula de teste.
- Inicie no GitHub e adicione ao Ansible Galaxy.
Nosso ciclo de desenvolvimento com essas ferramentas se tornou mais divertido.
Molécula
Essa ferramenta ajuda a testar completamente o papel ansível. Para fazer isso, ele tem tudo:
- Integração com o YAML lint e o Ansible lint para verificar as funções quanto à conformidade com nossos requisitos.
- Infraestrutura de teste para execução de testes funcionais.
- Os drivers da molécula são onde a Molecule está implantando nossa bancada de testes. Tudo é suportado: Azure, Delegado, Docker, EC2, GCE, LXC, LXD, Openstack, Vagrant.
- Ainda existe uma coisa útil e simples: delegação. Isso significa que a Molecule não é responsável pela implantação da bancada de testes e o desenvolvedor deve escrever um Playbook para elevar a bancada de testes. Se você possui uma nuvem super-privada, delegue a criação e a remoção de máquinas de teste, e o próprio Molecule adicionará tudo dentro.
Matriz de teste
Considere a matriz de teste em etapas. Existem 11 etapas no total, mas serei breve.
No. 1. Fiapos
Eles executam o YAML lint e o Ansible lint e encontram algo.
No exemplo acima, o lint jura que o shell não deve ser chamado apenas em Ansible, mas deve ser corrigido, vinculando-se a algo.
No. 2. Destruir
A molécula se livra de tudo o que resta após testes anteriores.
Há momentos em que uma corrida passou, um campo de treinamento se desenrolou e os testes foram concluídos. O suporte deve ser limpo no final, mas a força maior interveio e não houve limpeza. Para tais situações, a molécula foge destrói e limpa o ambiente dos resíduos.
No. 3. Dependência
Pegamos o arquivo requirements.yml e adicionamos as dependências de nossa função em outras funções. Por exemplo, uma referência ao fato de que a função não será decolada sem o Java instalado no sistema:
--- - src: lean_delivery.java version: 1.4
A molécula entende isso e executará o script:
- Vai Galaxy ou Git
- Vai perceber que é necessário resolver dependências;
- Vai para o Galaxy novamente;
- downloads;
- irá expandir.
No. 4. Sintaxe
O próximo passo é a verificação de sintaxe. mas não sua função, mas o Playbook de teste que você adiciona ao Molecule. Também há erros de sintaxe nesta etapa.
O slide mostra que o papel ansible é chamado de 'kibana' e, no Playbook de teste, é chamado ansible-role-kibana. O sistema diz: "Tudo ficaria bem e você pode criá-lo aqui, mas não o farei porque os nomes não correspondem!"
No. 5. Criar
Nesta fase, indicamos o driver com o qual o site de teste está implantado. Aponte o Google - ele criará máquinas de teste no Google Cloud.
Podemos escrever no arquivo molecule.yml o que queremos. Vamos ver como fica em um exemplo para o Docker.
- Estou especificando as imagens do docker para serem puxadas para cima.
- Eu indico como agrupá-los para que um arquivo de inventário seja formado.
Eu quero ter duas imagens do docker: uma para o tipo RHEL e a segunda para o Debian, para ter certeza de que, durante o teste, tudo ficará bem com o RHEL e o Debian.
No. 6. Prepare
Esta é uma etapa de preparação preliminar para o ambiente de execução de teste.
Parece que tudo aumentou, mas às vezes você precisa executar algumas configurações adicionais. No caso de teste dentro de um Docker elevado no Debian ou Ubuntu, você precisa instalar um segundo Python, o que geralmente acontece.
No. 7. Convergir
O estágio da primeira grande execução da função dentro da instância, para garantir que ela chegue ao fim, seja executado, e o Ansible confirma que está tudo bem.
- Molécula refere-se a Ansible.
- Ansible implantado em um site de teste.
- Funciona.
- Está tudo bem!
No. 8. Idempotência
O teste de idempotência é simples e se parece com isso.
- A primeira vez que a função é executada na etapa anterior.
- Ansible relata quantas alterações foram feitas.
- Reinicia a mesma função.
- Verifica se o sistema foi levado ao estado esperado, mas não há alterações no segundo aluguel.
Como resultado, entendemos que nosso papel não age destrutivamente.
Esse estágio causou dor para os caras com quem trabalho. Eles tentaram contornar o problema para derrotar o teste de idempotência. A molécula pode controlar os estágios pelos quais passa, e a primeira coisa que eles fizeram foi desativar a verificação de idempotência.
Pegamos apagões e nos vencemos por isso, mas os engenheiros são inteligentes e foram mais fundo. Os desenvolvedores decidiram dizer que este passo no Ansible não muda nada.
Embora, de fato, algum tipo de equipe apareça aqui. Ansible tomará e
sobrescreverá o arquivo, mas ao mesmo tempo tudo parecerá idempotente.
Quando esse truque também foi descoberto, a imagem começou a ficar assim.
Bom - o script foi executado com o nome padrão e é idempotente.
No. 9. Efeito lateral
No próximo estágio, os efeitos colaterais são sobrepostos. Não é necessário fazer isso, mas é conveniente quando você testar papéis de difusão complexos que dependem um do outro.
Por exemplo, levante a pilha ELK e, em seguida, Elasticsearch em um cluster. No estágio side_effect, adicione dados de teste e remova alguns nós do cluster. O local do teste está pronto para os testes funcionais que ocorrem na próxima etapa.
Número 10. Verifique
Testando a infraestrutura.
Acima está um exemplo de um teste muito simples. Verificamos se temos o pacote Docker Community Edition instalado, se o Ubuntu estiver instalado, a versão correta e o serviço em execução.
Nesta fase do lançamento de testes funcionais, tudo pode ser bastante complicado.
Provavelmente, o melhor exemplo seria, no caso da pilha ELK, se fizermos uma solicitação em alguma solicitação do Elasticsearch para alguns dados de teste e, como sabemos os dados de teste, ele nos responderá. Não verificaremos se todos os componentes instalados estão montados, mas veremos que o Elasticsearch está instalado, em execução e fornece exatamente o que você precisa na pesquisa.
Quando os testes funcionais são executados, parece bonito, percorre todo o inventário e o sistema nos diz que está tudo bem conosco. Novamente, os testes serão executados se os escrevermos.
No. 11. Destruir
Realizamos testes, existe um relatório de alguma forma e agora removemos todo o lixo atrás de nós.
Automação
A molécula é uma ótima ferramenta. Agora, a coisa mais simples permanece - conectar um sistema de integração contínua a ele, a fim de aproveitar o teste automático de nossas funções, o que fizemos.
Como em outros lugares, existem vários recursos.
Algumas das funções que escrevemos para automatizar algo são boas, mas não podemos testar o sistema usando o Travis, porque as funções implantam produtos que não podemos compartilhar por motivos de licenciamento.
Por exemplo, você tem uma implantação automatizada de um banco de dados Oracle. Se você colocar a base do instalador em um arquivo, os advogados da empresa entrarão em contato com você e jurarão muito. Para que todos vivam em paz e não jurem, decidimos fazer o seguinte.
- O GitLab, em uma de suas versões mais recentes, aprendeu a executar o CI para repositórios de terceiros.
- A função está no público GitHub, o mesmo público GitLab.com está conectado a ele, no qual indicamos: "Prezado GitLab, colete o IC para o repositório externo".
- Os corredores particulares são aparafusados ao GitLab, em um perímetro fechado, e eles já têm acesso ao binário, que eles podem implantar.
De fato, o papel está publicamente, os dados também, e não estamos enganando ninguém - executamos testes reais com ferramentas reais.
Vamos dar uma olhada nas etapas de como se parece em Travis.
Travis
Os passos:
- Na primeira etapa, na 8ª linha, dizemos ao Travis que não queremos apenas iniciá-lo, mas também usamos o serviço Docker para que o Docker esteja disponível no Travis.
- Em seguida, na 10ª linha, adotamos nossas regras de fiapos. Não apenas usamos as regras Ansible lint padrão, mas também escrevemos as nossas.
- Na linha 15, chamamos primeiro o lint para economizar tempo na execução da matriz de teste. Se algo não está escrito de acordo com as regras e o fiapo não o encontra, então ele vai para o início e deixa um relatório. Um desenvolvedor que confirma, repara sua confirmação ou descarta as alterações. Quando for reparado, deixe-o vir, e continuaremos a continuar o teste.
IC público
O IC público parece elementar.
Do GitHub, uma flecha para Travis, dentro da qual vivem Molecule e Docker.
IC privado
Para a parte privada do GitLab, tudo é o mesmo.
No perímetro privado, corremos um corredor, e a imagem parece mais divertida.
O código passa do GitHub para o GitLab, em algum lugar executado por um corredor privado que pode obter serviços externos, por exemplo, algo na Amazon.
Um pouco de digressão. Iniciar e implantar um ambiente de teste na Amazon não deseja ser portado, porque você precisa de chaves. Criar mecanismos para publicá-los, mas ao mesmo tempo não se tornar a próxima plataforma de inicialização para mineração - essa é uma tarefa não trivial. Portanto, não resolvemos, mas levamos o corredor em privado para não minerar bitcoins da Amazon.
Mesmo aqui, éramos um pouco preguiçosos e fizemos o seguinte. Nós do EPAM temos nossa própria nuvem privada e é híbrida. Isso significa que muitas nuvens públicas são acessíveis a partir da nuvem interna, como regiões. Você não pode escrever mil testes, mas brinque com as regiões e diga: "Agora teste de acordo com este cenário de teste para a região da AWS, EPAM Cloud, Azure".
Galáxia Ansible
Chegamos ao final, nosso papel é verde, bonito, vamos publicá-lo no Galaxy.
Esta é uma operação simples:
- A chamada do webhook que está em Travis.
- Nesse caso, o Travis será acionado, o IC será executado novamente.
- Ligue para o webhook.
- A nova versão crescerá com sucesso no Galaxy.
Há um recurso - se você não marcar um papel, não marcar, não atribuir uma versão a ele, o Galaxy sempre estará sem uma versão. Assim que outro desenvolvedor quiser instalá-lo pessoalmente através da instalação do Ansible Galaxy, ele removerá a função que está no ramo mestre ou em outro ramo por padrão. Por padrão, a ramificação nem sempre é estável, o que é inconveniente.
Se você publicar algo no Galaxy, não se esqueça de marcá-lo corretamente, para que haja versões e tudo tenha sido legal.
Padrões
Estou compartilhando um pequeno truque: para não copiar e colar toda vez que escrevemos uma nova função, decidimos criar modelos e um repositório separado no qual colocamos o modelo para escrever rapidamente funções do zero.
O modelo possui configurações padrão para Ansible lint e GitHub issue_template. Tudo está em domínio público; portanto, issue_template de uma forma bonita também era bonito para emitir solicitações de recebimento ou relatórios de erros. Adicionamos modelos para Gitignore, Gitlab-ci e uma licença para o mesmo repositório.
Por padrão, publicamos sob a licença Apache 2.0. Se você quiser vir até nós e reutilizar os modelos, poderá retirar tudo, criar um repositório fechado e não explicar nada a ninguém. Obrigado Apache.
Temos várias opções de teste para que você possa rapidamente iniciar e iniciar tudo.
Sumário
Não haverá conclusão; em vez disso, existem links para
meu GitHub , meu
perfil Galaxy ,
GitHub Lean Delivery e
Ansible Galaxy . Usando os links, você pode ver como tudo funciona. Todos os exemplos estão disponíveis gratuitamente.
A próxima conferência do DevOps será realizada em maio.
Enquanto aguardamos o evento, assine o canal e a newsletter do YouTube . O canal será reabastecido com registros dos melhores relatórios e, na lista de discussão, haverá seleções de materiais úteis, transcrições e notícias de DevOps.
Inscreva-se, será interessante :)