Como testar o provisionamento e a configuração na instalação Ansible?


33

Olhando para tentar criar alguma resiliência em nossa configuração Ansible, que trata de provisionamento e configuração.

Entendo alguns métodos de teste no lado da configuração, mas estou me perguntando qual a melhor forma de implementar o teste no lado do provisionamento e se existem ferramentas que possam ajudar nesse tipo de implementação.

Atualmente, muitos dos nossos testes são feitos em série durante o manual, o que faz muito sentido para coisas como "o serviço foi disponibilizado; o vip está disponível; a tarefa assíncrona foi concluída", mas o que realmente me preocupa é nossa capacidade de gerenciar desvios de informações. configuração na camada de aplicativo e provisionamento (como configuração da VM). Estou ciente de que o Ansible não é a melhor ferramenta para trabalhar com desvios de configuração, mas estou curioso para ver suas próprias opiniões.

Se você tem algo para automatizar totalmente o processo ainda melhor. (temos alguns scripts feios que relatam folga diariamente).

Nota : No momento, temos algumas condições em que uma reprovisão pode ocorrer (por exemplo, reconstrução a partir do backup, problema crítico nos sistemas), mas geralmente apenas percorre algumas das tarefas de configuração ansíveis e não pensa mais nisso.



O Ansible é executado apenas uma vez após o provisionamento? Caso contrário, com que frequência está sendo executada? Apenas tentando entender o problema antes de oferecer uma solução.
Woodland Hunter

Olá @Naphta, qualquer uma das respostas resolveu sua pergunta, considere aceitá-la clicando na marca de seleção. Isso indica para a comunidade em geral que você encontrou uma solução e dá reputação ao respondente e a si mesmo. Não há obrigação de fazer isso.
Richard Slater

I'm aware Ansible isn't the best tool for working with configuration drift Por favor explique.
030

Respostas:


19

Algumas opções por aí ..

Ferramentas de teste: classificadas por estrelas do github

  • Serverspec - Ruby, a ferramenta mais popular do mercado, baseada no rspec do ruby
  • Goss - YAML, binário simples, <10 MB independente, extremamente rápido, pode gerar testes a partir do estado do sistema
  • Inspec - Ruby, pense nisso como uma especificação de servidor aprimorada, quase a mesma sintaxe, criada pelos chefs. Criado para ser mais fácil de estender do que o serverpec
  • Testinfra - Python, tem o recurso interessante de poder usar o inventário / vars do Ansible

Principais diferenças entre eles:

Por fim, sugiro que passe um dia fazendo experiências com todos eles para ter uma ideia deles antes de decidir por si mesmo.

  • Com exceção do Goss, todas as estruturas podem ser executadas em uma máquina remota (por exemplo, sobre ssh). O Goss é executado apenas localmente ou no docker w / dgoss.
  • Todas as estruturas podem ser executadas localmente em um servidor, mas exigem que o Python ou Ruby seja instalado ou incorporado. O Inspec fornece um pacote independente de <150MB com uma versão incorporada do ruby. Goss é um único binário <10MB sem dependências externas.
  • O Goss possui suporte embutido para saída nagios / sensu, o que permite uma integração mais fácil com as ferramentas de monitoramento.
  • Os testes de goss tendem a ser mais simples, mas menos flexíveis, pois são baseados no YAML. Outras estruturas permitem que você aproveite todo o poder da linguagem subjacente Python / Ruby para escrever testes ou estender a funcionalidade da ferramenta. (simplicidade versus flexibilidade)
  • Goss permite gerar testes a partir do estado atual do sistema
  • Pelo que sei, o Testinfra é o único que possui suporte interno para inventário e variáveis ​​ansible
  • Inspec é apoiado pelo Chef

Teste contínuo / divergência:

  • Chef Compliance - trabalha com a inspec para testar continuamente seus servidores, produtos pagos
  • Goss - Pode ser facilmente conectado ao Nagios ou Sensu. Além disso, suporta a exposição de testes do servidor como um ponto de extremidade http.

Arnês de teste para desenvolvimento:

  • kitchen - A ferramenta de equipamento de teste, inicia a instância, executa o código de gerenciamento de configuração, executa o conjunto de testes. Feito pelos chefs
  • Molécula - Semelhante ao teste de cozinha, mas escrita especificamente para ansible

Divulgação completa: Eu sou o autor de goss

ATUALIZAÇÃO: O InSpec 4.x ou superior usa uma licença comercial / de código aberto mista - consulte os comentários.


4
Entendo que você é um pouco tendencioso, mas o inspec não precisa de Conformidade para ser executado periodicamente. E não há dependências para gerenciar, todas as bibliotecas e estruturas necessárias (ruby) estão agrupadas no pacote que pode ser instalado localmente em cada nó, ao executar o ssh / winrm, o inspec se coloca no lugar. Você aponta sobre um comando exclusivamente externo, o que não é verdade, muitos testes são feitos pelo código ruby ​​interno. (Eu acho que vale a pena ser observado)
Tensibai

Atualizei a resposta para corrigir o comando externo e empacotei o ruby ​​para o inspec. Você pode esclarecer ou me enviar um link explicando como o inspec pode ser usado por si só para detectar / relatar desvios?
Ahmed Elsabbahy 29/03

Bem, a parte dos relatórios estará à sua mão, é realmente um objetivo de conformidade fazer uma representação. Mas você pode executar o inspec em um crontab e apenas confiar no correio do crontab quando um teste falhar em alertá-lo (por exemplo).
Tensibai 29/03

Em suma, os recursos para a edição, isso soa uma exposição justa da sua ferramenta e de outras. Receio que isso possa ficar desatualizado rapidamente, mas de qualquer maneira seja +1 para a listagem e os ponteiros.
Tensibai 29/03

Ah, sim ... todas as ferramentas podem ser aproveitadas dessa maneira. Eu estava tentando fornecer ferramentas (ou integrações com ferramentas) que fornecem melhores relatórios. Que eu saiba, há conformidade ou empacotamento das ferramentas de uma maneira que as torna nagios / sensu / alguma outra ferramenta de monitoramento amigável. Ex: slideshare.net/m_richardson/… Desculpas se parecesse tendencioso inicialmente, não pretendiam ser.
Ahmed Elsabbahy 29/03

13

As duas ferramentas que vi para isso são o InSpec e o ServerSpec . Serverspec é uma ferramenta baseada em Ruby que se baseia no RSpec . O InSpec é inspirado no RSpec e ServerSpec.

Eu usei ServerSpec. É legal, mas talvez não seja 100% estável. Eu tive problemas com o teste de versões específicas de software no Ubuntu.

Eu li os documentos do InSpec, mas não me aprofundou muito. Faz essencialmente a mesma coisa que Serverspec.

A julgar pelos commits do Github, parece que o trabalho no ServerSpec diminuiu um pouco, enquanto o InSpec está apenas aumentando.

ATUALIZAÇÃO: O InSpec 4.x ou superior usa uma licença comercial / de código aberto mista - consulte os comentários.


1
"Eu tive problemas com o teste de versões específicas de software no Ubuntu." Eu reparei isso, depois de perceber uma pergunta sobre isso no SO: stackoverflow.com/questions/42417864/...
Matt Schuchard

Para esclarecer um pouco, o InSpec emula o RSpec, mas não se baseia nele.
Coderanger

1
@MattSchuchard Obrigado por essa referência!
precisa saber é o seguinte

bem "não é 100% estável" para uma ferramenta de teste não parece bom
#

O InSpec é muito bom como uma ferramenta de teste e facilita a instalação de nada no servidor, enquanto o ServerSpec só pode fazer isso com algum trabalho extra. No entanto, seria necessário algum trabalho para que o InSpec usasse um inventário Ansible - provavelmente mais fácil se o inventário estiver no formato YAML (Ansible 2.4+).
RichVel

10

Ao usar ferramentas de gerenciamento de configuração, como Ansible, a própria ferramenta seria responsável por evitar desvios na configuração. Depois de usar o Ansible para definir uma determinada configuração, a execução repetitiva do Ansible garantirá que sua configuração esteja como você definiu. Isso também exige que seu código Ansible seja escrito de maneira idempotente.

Dado o exposto acima, o provisionamento de teste pode ser alcançado executando os manuais do Ansible em loop de algum servidor. Por exemplo, um trabalho cron, ou Jenkins, pode executar os playbooks a cada 30 minutos e relatar qualquer falha. Não ter falhas significa que sua configuração está sob controle; ter falhas significa que há um problema em obter os servidores no estado desejado .

Em um caso em que você não pode confiar que seu código seja gravado como idempotente e, portanto, não é possível executar o Ansible repetidamente em um loop de um servidor automático, existe uma solução alternativa. Você pode fazer o mesmo que acima (executar Ansible em um loop), mas usar o modo de execução a seco . Cada vez que o Ansible relata que são necessárias alterações, o trabalho Jenkins (ou trabalho cron) pode notificá-lo de que sua configuração provisionada foi alterada e que os servidores não estão no estado desejado .

Para garantir que seu código Ansible esteja realmente fazendo o que você pensa que deveria estar fazendo, as soluções mencionadas por Dave Swersky se aplicam. O InSpec e o Serverspec são ferramentas que verificam de uma maneira diferente que seus playbooks realmente fazem o que você quer dizer. Uma ótima maneira de executar esse tipo de ferramenta em ambientes de teste (mesmo contêineres de encaixe) é usar o kitchen.ci, que lida com toda a cola entre as várias ferramentas de teste de unidade de infra-estrutura e a execução de seus playbooks / módulos / livros de receitas.

O Kitchen.ci foi originalmente usado para testar os livros de receitas do Chef, mas existem plugins para o Ansible e outras ferramentas de CM também.


5

O Test Kitchen possui um plug-in de provedor de cozinha para testar o código Ansible. Não é tão profundo quanto a integração do Chef, mas faz o trabalho na maioria dos casos. Há também o projeto Molecule mais recente, que é um sistema de teste Ansible dedicado.


0

Você pode rastrear discrepâncias de configuração / infraestrutura / desvio usando o Outthentic . É fácil criar um conjunto de testes para "corrigir" o estado desejado e executá-lo novamente sempre que precisar rastrear alterações indesejadas.


1
Bem-vindo ao DevOps.se Alexey. Embora sua ferramenta possa ajudar o usuário nesse caso, para que seja uma resposta aqui, deve haver um pouco mais para mostrar como isso é relevante para a pergunta. Caso contrário, parece um anúncio apenas para link.
pintos

Oi! Claro, apenas dados mais detalhes.
Alexey Melezhik 04/10/19

Do meu ponto de vista, isso não faz nada além do que o rundeck pode fazer e está fora do escopo dessa pergunta. Especialmente porque a resposta não explica como ele pode resolver a auditoria de mil servidores e ser alertado sobre uma deriva ou apresentar um relatório legível por humanos para um auditor, fornecendo alguns resultados analisáveis. Pelo que acabei de ler, não faz mais do que o que a inspec pode fazer (por exemplo) e fornece uma saída menos utilizável em escala, exigindo muitas ferramentas externas para fazer o trabalho e, portanto, menos portátil.
Tensibai 4/10/19

"como ele pode resolver auditoria mil servidores" - eu poderia encontrar nada sobre milhares de servidores na questão
Alexey Melezhik

"e seja alertado sobre uma deriva ou apresente um relatório legível por humanos para um auditor, fornecendo alguns resultados analisáveis". nem eu encontrei isso na pergunta. O alerta óbvia de derivação é o fato de que os testes começam a falhar ...
Alexey Melezhik
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.