Get best of the week

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

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.



Saudações a todos, meu nome é Michael Rau, sou engenheiro de sistemas sênior na ActioNet, que trabalha para a Administração Nacional Oceânica e Atmosférica (NOAA) do NESDIS. Hoje falaremos sobre o corte de linha - minha própria experiência migrando da Puppet Enterprise para a Ansible Tower. O tema desta apresentação é “olhar minhas cicatrizes” deixadas depois que fiz essa transição no início do ano. Quero contar o que aprendi durante esse processo. Então, quando você fizer isso, usando minha experiência, poderá fazer a transição sem muita dificuldade.

Você vê slides semelhantes a este no início de cada apresentação no Ansible Fest. Este slide mostra o histórico da automação da minha empresa. Não sou novo nesse ramo porque uso o Puppet / Puppet Enterprise desde 2007. Comecei a trabalhar com a Ansible em 2016 e, como muitos outros usuários deste produto, fui atraído pela possibilidade de “truques” usando a linha de comando e scripts simples (playbooks). No final de 2017, voltei-me para a minha liderança sobre as boas razões para mudar para a Ansible Tower. Em um minuto, falarei sobre os motivos que me levaram a dar esse passo. Depois de obter o consentimento da gerência, demoramos vários meses para cumprir o plano, e eu fiz a transição em janeiro-fevereiro deste ano. Então, abandonamos completamente o Puppet em favor do Ansible, e isso é ótimo.



O que mais me atrai na Ansible é a capacidade de escrever e usar papéis e scripts (playbooks). As funções são ótimas para criar tarefas (tarefas) diferentes, mas inter-relacionadas e colocar todos os dados relacionados a essas tarefas em um único local. Playbook é a sintaxe YAML, um arquivo de script que descreve ações para um ou mais hosts. Eu falo sobre esses recursos para os usuários, principalmente desenvolvedores de software. O Ansible Tower possibilita dizer: "Não, você não tem acesso ao shell, mas eu lhe dou a oportunidade de iniciar todos os processos do Tower e reiniciar o serviço quando necessário". Vou falar sobre o ambiente de trabalho e os equipamentos que usamos.



Esta é uma LAN federal, 7 sites físicos conectados via MPLS baseado em nuvem, 140 servidores RHEL, 99% dos quais são virtuais (vSphere), hardware SuperMicro, NexentaStore NAS, um conjunto de switches Cisco, Arista e Cumulus e ferramentas de gerenciamento unificado de ameaças Fortinet UTM em cada site. .

A rede federal significa que devo usar todos os meios de proteção de informações previstos em atos legislativos. Lembre-se de que o Puppet Enterprise não suporta a maioria dos equipamentos que usamos. Somos forçados a usar o hardware do orçamento porque as agências governamentais estão tendo problemas para financiar esse item de despesa. Portanto, compramos o hardware da classe SuperMicro e montamos nossos equipamentos a partir de peças individuais, cuja manutenção é garantida por contratos governamentais. Nós usamos o Linux, e esse é um dos motivos importantes para mudar para o Ansible.

Nossa história com a Puppet é essa.



Em 2007, tínhamos uma pequena rede de 20 a 25 nós, na qual implantamos o Puppet. Basicamente, esses nós eram apenas "caixas" do RedHat. Em 2010, começamos a usar a interface da web Puppet Dashboard para 45 nós. À medida que a rede continuou a se expandir, em 2014, mudamos para o PE 3.3, fazendo uma transição completa com a reescrita do manifesto para 75 nós. Isso tinha que ser feito porque o Puppet gosta de mudar as regras do jogo e, nesse caso, eles mudaram completamente o idioma. Um ano depois, quando o suporte para a versão 3 do Puppet Enterprise parou, fomos forçados a migrar para o PE 2015.2. Novamente tive que reescrever o manifesto para os novos servidores e comprar uma licença com uma reserva de 100 nós, embora na época tínhamos apenas 85 nós.

Apenas dois anos se passaram e, novamente, tivemos que trabalhar muito para mudar para a nova versão do PE 2016.4. Compramos uma licença para 300 nós, com um total de 130. Novamente tivemos que fazer grandes alterações no manifesto, porque a nova versão do idioma tinha uma sintaxe diferente do idioma da versão de 2015. Como resultado, nosso SCM mudou de um sistema de controle de versão SVN para Bitbucket (Git). Esse foi o nosso "relacionamento" com o Puppet.

Portanto, tive que explicar à gerência por que precisamos mudar para outro SCM usando os seguintes argumentos. O primeiro é o alto preço do serviço. Falei com o pessoal da RedHat e eles disseram que o custo de manutenção de uma rede de 300 nós usando o Ansible Tower é metade do custo do Puppet Enterprise. Se você comprar outro Ansible Engine, o custo será o mesmo, mas você terá muito mais recursos que o PE. Como somos uma empresa estatal financiada pelo orçamento federal, esse é um argumento bastante ponderado.



O segundo argumento é versatilidade. O Puppet suporta apenas hardware com um agente Puppet. Isso significa que você precisa instalar um agente em todos os comutadores e deve ser a versão mais recente. E se parte de seus comutadores oferecer suporte a uma versão e parte a outra, será necessário instalar uma nova versão do agente PE neles para que todos possam trabalhar no mesmo sistema SCM.

O sistema Ansible Tower funciona de maneira diferente porque não possui agentes, mas existem módulos que suportam switches Cisco e todos os outros switches. Este SCM suporta Qubes OS, Linux e 4.NET UTM. O Ansible Tower também suporta NASs NexentaStore baseados no kernel Illumos, um sistema operacional Unix de código aberto. Esse suporte é muito pouco, mas a Ansible Tower faz isso de qualquer maneira.

O terceiro argumento, que é muito importante para mim e para nossa administração, é a facilidade de desenvolvimento. Dominei os módulos e o código do manifesto Puppet por 10 anos, mas estudei o Ansible por uma semana, porque é muito mais fácil trabalhar com esse SCM. Se você executa arquivos executáveis, é claro, se não o fizer desnecessariamente, os manipuladores razoáveis ​​e responsivos trabalharão com eles. Os scripts de playbooks baseados em YAML são fáceis de aprender e rápidos de usar. Aqueles que nunca ouviram falar do YAML antes podem simplesmente ler os scripts e entender facilmente como ele funciona.

Honestamente, o Puppet complica seu trabalho como desenvolvedor, porque é baseado no uso do Puppet Master. Esta é a única máquina autorizada a se comunicar com os agentes Puppet. Se você fez alguma alteração no manifesto e deseja testar seu código, deve reescrever o código para o Puppet Master, ou seja, configurar o arquivo mestre do Puppet / etc / hosts para conectar todos os clientes e iniciar o serviço do Puppet Server. Somente então você pode testar a operação do equipamento de rede em um host. Este é um procedimento bastante doloroso.
No Ansible, tudo é muito mais simples. Tudo o que precisa ser feito é desenvolver código para uma máquina que possa se comunicar via SSH com o host em teste. É muito mais fácil trabalhar com isso.

A próxima grande vantagem do Ansible Tower é a capacidade de alavancar seu sistema de suporte existente e salvar sua configuração de hardware existente. Este SCM, sem nenhuma ação adicional, usa todas as informações disponíveis sobre sua infraestrutura e equipamentos, máquinas virtuais, servidores, etc. Ele pode se comunicar com os servidores RH Satellite, se houver, e fornece uma integração que você nunca terá ao trabalhar com o Puppet.

Outra coisa importante é o controle detalhado. Você sabe que o Puppet é um sistema modular, é um aplicativo cliente-servidor, portanto, você deve determinar os aspectos existentes da operação de todas as suas máquinas em um longo manifesto. Nesse caso, o estado de cada elemento individual do sistema deve ser testado a cada meia hora - este é o período padrão. É assim que o Puppet funciona.

Tower te salva disso. Você pode executar vários processos em uma ampla variedade de equipamentos sem restrições, pode executar o trabalho principal, iniciar outros processos importantes, configurar o sistema de segurança, trabalhar com bancos de dados. Você pode fazer tudo o que vier com certas dificuldades no Puppet Enterprise. Portanto, se você configurou em um host, levará algum tempo para que as alterações entrem em vigor nos outros hosts. No Ansible, todas as alterações entram em vigor simultaneamente.

Por fim, considere o módulo de segurança. Na torre Ansible, é implementada de maneira simplesmente incrível, com grande precisão e rigor. Você pode fornecer aos usuários acesso a serviços específicos ou a hosts específicos. Faço isso com meus funcionários que estão acostumados a trabalhar no Windows, restringindo-os a acessar o shell do Linux. Eu forneço a eles acesso à Torre para que eles possam apenas fazer o trabalho e executar apenas os serviços que estão dentro de sua competência.



Vejamos o que você precisa fazer com antecedência para facilitar a transição para a Ansible Tower. Antes de tudo, é necessário preparar o seu equipamento. Se algum elemento da sua infraestrutura ainda não estiver no banco de dados, você precisará adicioná-lo lá. Existem sistemas que não alteram suas características e, portanto, estão ausentes no banco de dados do Puppet, mas se você não os adicionar antes de se mudar para o Tower, você perderá várias vantagens. Esse pode ser um banco de dados preliminar "sujo", mas deve conter informações sobre todo o equipamento que você possui. Portanto, você deve escrever um script de hardware dinâmico que fará automaticamente todas as alterações de infraestrutura no banco de dados; o Ansible saberá quais hosts devem estar no novo sistema. Você não precisará informar este SCM,quais hosts você adicionou e quais hosts não existem mais, porque ela saberá tudo isso automaticamente. Quanto mais dados houver no banco de dados, mais Ansible será útil e flexível. Funciona como se simplesmente lesse um código de barras do status do equipamento no banco de dados.

Passe algum tempo conhecendo a linha de comando no Ansible. Execute alguns comandos especiais para testar o script de hardware, escreva e execute alguns scripts simples, mas úteis, do manual, use os modelos Jinja2, quando apropriado. Tente escrever uma função e um script para um processo complexo de vários estágios usando uma configuração de hardware padrão frequentemente encontrada. Brinque com essas coisas, teste como elas funcionam. Dessa forma, você aprenderá como trabalhar com as ferramentas para criar bibliotecas usadas na Torre. Eu já disse que levei cerca de três meses para me preparar para a transição. Penso que, com base na minha experiência, você será capaz de fazê-lo mais rapidamente. Não considere esse tempo perdido, porque mais tarde você sentirá todas as vantagens do trabalho realizado.

Em seguida, você precisa decidir o que espera da Ansible Tower, o que exatamente esse sistema deve fazer por você.



Você precisa implantar o sistema em hardware vazio, em máquinas virtuais vazias? Ou você deseja manter as condições originais de trabalho e as configurações do equipamento existente? Esse é um aspecto muito importante para o trabalho de empresas estatais, portanto, você deve ter certeza de que poderá migrar e implantar o Ansible em sua configuração existente. Identifique os processos administrativos de rotina que você deseja automatizar. Descubra se você precisa implantar aplicativos e serviços específicos no novo sistema. Faça uma lista do que você quer fazer e priorize.

Em seguida, comece a escrever o código para scripts e funções que ajudarão você a concluir suas tarefas planejadas. Combine-os em Projetos, uma coleção lógica de scripts de playbooks relevantes. Cada projeto se relacionará a um repositório Git separado ou outro repositório, dependendo de qual gerenciador de código você usa. Você pode gerenciar scripts de playbook e diretórios de playbook colocando-os manualmente no Project Base Path no servidor Tower ou colocando-o em qualquer SCM (Tower Source Code Management System), incluindo Git, Subversion, Mercurial e Red Hat Insights. Dentro de um projeto, você pode colocar quantos scripts quiser. Por exemplo, criei um projeto básico, no qual coloquei um script para os principais elementos do RedHat, um script para os conceitos básicos do Linux,Cenários para as demais linhas de base. Assim, em um projeto, havia uma grande variedade de funções e scripts que eram gerenciados a partir de um repositório Git.

Execute todas essas coisas através da linha de comando, essa é uma boa maneira de testar seu desempenho. Dessa forma, você se prepara para a instalação da torre.

Vamos falar um pouco sobre a transcodificação do manifesto Puppet, porque gastei muito tempo até descobrir o que realmente precisava ser feito.



Como eu disse antes, o Puppet armazena todas as configurações e parâmetros do equipamento em um manifesto longo, e esse manifesto contém tudo o que esse SCM deve fazer. Durante a transição, você não precisa colocar todas as suas tarefas em uma lista. Em vez disso, pense na estrutura do novo sistema: funções, scripts, tags, grupos e o que deve acontecer lá. Alguns dos elementos de rede independentes devem ser agrupados em grupos para os quais você pode criar scripts. Elementos de infraestrutura mais complexos que envolvem um grande número de recursos, incluindo classes autônomas, podem ser combinados em funções. Antes da migração, você precisa decidir sobre isso. Se você criar funções ou scripts volumosos que não cabem em uma tela, use tags para poder capturar partes individuais da infraestrutura.

18:00

Cortar linhas: migrando da empresa Puppet para a Ansible Tower. Parte 2

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 baseado em nuvem para desenvolvedores a partir de US $ 4,99 , um analógico exclusivo de servidores básicos que foi inventado por nós para você: Toda a verdade sobre o VPS (KVM) E5-2697 v3 (6 núcleos) 10GB DDR4 480GB SSD 1Gbps de 10GB 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