Get best of the week

Aparar linhas: migrando da empresa Puppet para a torre Ansible. Parte 2

O Serviço Nacional de Informação Ambiental por Satélite (NESDIS) reduziu seus custos de gerenciamento de configuração do Red Hat Enterprise Linux (RHEL) em 35%, passando de Puppet Enterprise para Ansible Tower. Neste vídeo da categoria "como fizemos", o engenheiro de sistema Michael Rau substancia a implementação dessa migração, compartilha dicas úteis e experiência adquirida com a transição de um SCM para outro.

Neste vídeo, você aprenderá:

  • Como justificar a administração a viabilidade de passar da empresa Puppet para a Ansible Tower;
  • quais estratégias usar para a transição mais suave;
  • dicas para transcodificar manifestos de PE no Ansible Playbook;
  • Práticas recomendadas para a instalação do Ansible Tower.



Aparar linhas: migrando da empresa Puppet para a torre Ansible. Parte 1



Eu tenho tags para implantação inicial que são executadas. Eu tenho tags que verificam alterações em 20% da infraestrutura que ocorrem em 80% do tempo de trabalho. Uma situação semelhante com papéis. Há um código de manutenção, um segundo código que organiza a implantação e um terceiro que lança o equipamento, digamos, uma vez por dia. A função verifica se há alterações em todos os equipamentos a serem implantados e as verificações são realizadas a cada duas horas para equipamentos sujeitos a alterações. Isso se aplica ao firewall, a algumas coisas administrativas e similares.

Use os bons hábitos que você adquiriu ao escrever o código para o Puppet, porque eles serão úteis para o Ansible. Por exemplo, algo como idempotência é uma propriedade de um objeto ou operação ao aplicar a operação novamente ao objeto para fornecer o mesmo resultado que o primeiro. No nosso caso, isso significa que, quando você executa o mesmo script do playbook novamente, nada muda e o sistema informa que nada mudou. Se as alterações forem confirmadas, significa que algo está errado com seu código. Ou seja, a idempotência ajudará a detectar quando algo der errado ao iniciar as mesmas operações de rotina.
Use fatos e padrões, evite dados codificados. O Ansible permite que você faça isso com scripts, manipulando com flexibilidade um conjunto de dados e capturando alterações em tempo real. Não existe tal coisa no Puppet, você deve colocar todos os dados importantes dentro do código-fonte. Portanto, use funções, isso facilitará muito sua tarefa.

Use manipuladores de eventos causados ​​por uma alteração na configuração. O bom é que os manipuladores podem trabalhar com sequências protegidas. Documente tudo o que você faz. Eu odeio quando me deparei com um código que escrevi há seis meses, sem documentar nada naquele momento, e não me lembro por que o escrevi. Portanto, qualquer tarefa deve ter uma descrição. Cada função e script que você escreve devem ter seu próprio Leia-me, que registrará como usá-los e o que eles fazem. Acredite, mais tarde isso será muito útil para você.



Você deve tirar proveito das novas liberdades que o Ansible fornece. Você pode afetar o mesmo arquivo várias vezes, se necessário. Por exemplo, se você precisar alterar vários parâmetros do arquivo sshd_config em um script que contém parâmetros importantes para outros scripts, poderá fazer isso. Puppet não permite isso.
Com o Ansible, você obtém uma execução previsível do programa. Eles funcionam exatamente como você espera deles, e você não precisa monitorar erros de execução de código. Se você trabalha com EXEC, esteja ciente de que os manipuladores Ansible são mais inteligentes que os manipuladores Puppet. Use truques Ansible como meu recurso favorito de delegação. Por exemplo, você iniciou um manual para o servidor A, mas parte das etapas deste script deve ser executada independentemente no servidor B. Usei a função de delegação para migrar do fantoche para o Ansible. Com esta função, você pode configurar a execução da tarefa em um host diferente, e não no que foi configurado usando a chave delegate_to. O módulo ainda será executado uma vez para cada máquina, mas em vez de trabalhar na máquina de destino, ele funcionará em um host delegado,além disso, todos os fatos disponíveis serão aplicáveis ​​ao host atual. Isso reduzirá significativamente a quantidade de configurações manuais do sistema.

Os dados da sua biblioteca Puppet Hiera podem ser usados ​​como fatos Ansible, que são informações sobre nós conectados. Fatos - é isso que o módulo Gather Fatos coleta durante a execução: quantidade de espaço em disco, versão e tipo de sistema operacional, nome do host, quantidade de memória disponível, arquitetura do processador, endereços IP, interfaces de rede e status. Não quero dizer informações de serviço ocultas nos dados - basta usar os scripts do seu equipamento para formar grupos e nós variáveis. Meu script de hardware informa ao sistema quais sites físicos ele contém. Mais tarde, uso funções, por exemplo, uma das funções contém fatos de infraestrutura para cada site físico, como recursos NTP, servidores DNS, endereços IP de equipamento modular, scanners Nessus e similares.Colete variáveis ​​comuns em uma função se você as colocar em mais de um lugar e as colocar no host como o arquivo /etc/ansible/facts.d/.

Portanto, consideraremos o processo de migração. Repito - para mim demorou muito tempo, mas você pode reduzi-lo. Primeiro de tudo, você precisa comprar e implantar a torre. Este é um processo muito compreensível, basta seguir a documentação de instalação.



Após instalar o Tower, você terá acesso imediato à interface da web. Em seguida, você precisa instalar um script de inventário e criar uma lista de equipamentos. Você pode copiar e colar scripts existentes na torre.

Em seguida, defina as permissões e permissões do Git, fornecendo ao Tower acesso direto ao repositório Git onde você armazena playbooks. Assim, você permitirá que a Tower receba instantaneamente informações dos scripts sobre as alterações e as implemente imediatamente. Você não precisa dizer nada ao Tower, ele simplesmente verificará o status do sistema e executará a versão mais recente da configuração.

Instale uma conta padrão da Tower para SSH em seus hosts. Como uso o acesso remoto, uso a conta padrão e o programa de administração do sistema SUDO para definir privilégios. Obviamente, o Tower possui uma senha, para que você não arrisque a segurança usando a senha SUDO.

Configure a autenticação do Tower de acordo com a estrutura de acesso da sua organização. Decida sobre o acesso a departamentos, equipes, distribuição de acesso a funções, lide com permissões especiais. Essa é uma tarefa muito volumosa, dependendo do tamanho da sua organização, mas lembre-se de que, do ponto de vista da administração da torre, graças à configuração flexível de acessos, isso pode simplificar bastante sua vida.

Agora que você tem o repositório Git implantado, instale e configure modelos de trabalho para playbooks. Teste o desempenho de tudo que você faz com o Tower. Depois de verificar se seus scripts estão em perfeita ordem, você pode prosseguir com a migração do host. Use Ansible para remover o agente Puppet e "limpar" o nó do servidor Puppet usando um script especial. É muito simples.



Criei um grupo chamado Tower, o adicionei ao script Ansible e o enviei a todos os hosts. Depois disso, este manual interrompeu os serviços do Puppet, desinstalou todos os pacotes do Puppet Enterprise e limpou os diretórios. Ele também excluiu os usuários do Puppet - uma vez que excluímos o PE, também os usuários do PE.

Vemos a função Delegação em ação. Agora eu posso entrar no Puppet Master e usar os comandos 2-3 para limpar o registro e, em seguida, tirar uma captura de tela mostrando que este SCM foi excluído. Servirá como evidência documental de que não usamos mais o PE.

Agora, vejamos o que deve receber a máxima atenção - meus erros que devem ser evitados. Isso se refere principalmente à dependência dos cenários entre si. É possível que as variáveis ​​de um manual de instruções dependam das variáveis ​​de outro manual. Lembre-se de que você pode inserir requisitos em cada cenário que permitam o uso de um cenário ou função diferente. Criei funções para as variáveis ​​de todos os nossos sites, e cada uma dessas funções continha muitas variáveis. Portanto, usei o arquivo requirements.yml para centralizar variáveis ​​comuns. Permite instalar várias coleções de conteúdo Ansible com uma equipe.



Se alterarmos o gateway padrão ou o servidor NTP, essas alterações serão refletidas imediatamente em todos os elementos da infraestrutura.

Evite usar papéis e scripts volumosos e volumosos. Cenários e funções curtas para tarefas específicas são mais eficientes e confiáveis, mais fáceis de gerenciar e mais fáceis de rastrear.

Preste atenção em mais uma coisa - ao iniciar o Tower e acessar sua página, você verá uma exibição de muitos parâmetros em vermelho. Essa cor é um alarme, mas aqui está a coisa. Você inicia o processo em centenas de hosts e, se 99 deles funcionarem com êxito e um não, o Tower relatará uma falha no processo. Ele colocará um marcador vermelho brilhante na tela que ilustra este trabalho. Não entre em pânico, mas tente descobrir por que esse nó único não funciona. Quando você olha para a tela do Puppet Master e vê 99 luzes verdes e uma vermelha, você acha que tudo está em ordem, o sistema funciona bem. A torre é mais rigorosa, mas menos informativa sobre mensagens de erro. Talvez nas versões futuras do Ansible essa falha seja eliminada, mas por enquanto tente descobrir a causa do alarme, lembrandoque esse alarme não pode levar nada crítico por si só - apenas desta maneira o sistema relata uma falha em um host.

Tenha cuidado se você possui hosts temporários que nem sempre estão online. Por exemplo, meu sistema possui vários laptops. Nós os administramos usando o Ansible Tower da mesma maneira que os hosts permanentes, mas como esses são dispositivos móveis, eles nem sempre estão presentes na rede. Se você usar hosts temporários ao executar processos padrão, mas a Torre não os detectar na rede quando o sistema for iniciado, um alarme e uma mensagem de falha no processo aparecerão imediatamente em sua tela. A Tower não sabe que esses laptops estão atualmente desligados. Não há nenhum problema com isso, lembre-se de que tal situação pode causar uma mensagem de alarme.

Existe uma boa maneira de usar a API da torre. Quando o laptop é inicializado como parte do procedimento padrão de inicialização do sistema, ele usa a API para informar ao Tower: “ei, estou aqui, há algum trabalho para mim?”. Depois disso, o Tower verifica as tarefas para essa máquina em particular no momento, porque sabe que ela está online.

Outra coisa com a qual inicialmente tivemos problemas foi a execução de operações paralelas. Por padrão, o Ansible usa 5 hosts paralelos para executar um trabalho. Portanto, o lançamento do mesmo trabalho agendado para 100 máquinas leva até 20 minutos por host, verificando os parâmetros da configuração principal. Assim, primeiro iniciamos a configuração em 5 hosts, depois outros 5, outros 5 e assim por diante. A princípio, essa circunstância nos deixou seriamente nervosos, porque a implantação do sistema em 50 hosts ocorreu em 2 horas. A solução para esse problema é a seguinte.
Basta definir o número de hosts paralelos no servidor Ansible Tower para ser diferente de 5. Como tenho 150 hosts em execução simultaneamente, defino esse valor como 25. Depois disso, 6 patches, por exemplo, foram instalados rapidamente. Se desejar, você pode definir esse parâmetro como 50 - tudo depende da capacidade de computação e da quantidade de RAM que você possui. Dessa forma, o Tower permite personalizar a execução de processos paralelos para atender às suas necessidades.



Se você tiver alguma dúvida sobre o tópico do relatório, não hesite em entrar em contato com os contatos indicados. Você vê o endereço de e-mail para onde pode enviar um e-mail descrevendo o problema que ocorreu ao mudar de Puppet para Ansible, e tentarei responder o mais breve possível. Agradeço sua participação e desejo uma migração bem-sucedida!

Um pouco de publicidade :)


Obrigado por ficar com a gente. Você gosta dos nossos artigos? Deseja ver materiais mais interessantes? Ajude-nos fazendo um pedido ou recomendando aos seus amigos o VPS na nuvem para desenvolvedores a partir de US $ 4,99 , um analógico exclusivo de servidores de nível básico que foi inventado por nós para você: Toda a verdade sobre o VPS (KVM) E5-2697 v3 (6 núcleos) 10 GB DDR4 480 GB SSD 1 Gbps de US $ 19 ou como dividir o servidor? (as opções estão disponíveis com RAID1 e RAID10, até 24 núcleos e até 40GB DDR4).

Dell R730xd 2 vezes mais barato no data center Equinix Tier IV em Amsterdã? Somente nós temos 2 TVs Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV a partir de US $ 199 na Holanda!Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - a partir de US $ 99! Leia sobre como construir infraestrutura classe c usando servidores Dell R730xd E5-2650 v4 que custam 9.000 euros por um centavo?

More articles:


All Articles