O National Environmental Satellite Data Information Service (NESDIS) reduziu seus custos de gerenciamento de configuração do Red Hat Enterprise Linux (RHEL) em 35% ao migrar do Puppet Enterprise para o Ansible Tower. Neste vídeo “como fizemos”, o engenheiro de sistemas Michael Rau explica o caso dessa migração, compartilhando dicas úteis e lições aprendidas ao passar de um SCM para outro.
Neste vídeo você aprenderá:
- como justificar à gestão a viabilidade de mudar do Puppet Enterprise para o Ansible Tower;
- que estratégias utilizar para tornar a transição o mais suave possível;
- dicas para transcodificar manifestos PE em Ansible Playbook;
- Recomendações para instalação ideal do Ansible Tower.
Olá a todos, meu nome é Michael Rau, sou Engenheiro de Sistemas Sênior na ActioNet, que trabalha para o serviço NESDIS da Administração Oceânica e Atmosférica Nacional (NOAA). Hoje falaremos sobre corte de cordas - minha própria experiência de migração do Puppet Enterprise para o Ansible Tower. O tema desta apresentação é “dar uma olhada nas minhas cicatrizes” deixadas depois que fiz essa transição no início do ano. Quero compartilhar o que aprendi nesse processo. Então, quando você assume algo assim, usando minha experiência, você pode fazer a transição sem nenhum trabalho extra.
Você vê slides semelhantes a este no início de cada apresentação no Ansible Fest. Este slide descreve a história da automação da minha empresa. Não sou novo nisso porque uso o Puppet/Puppet Enterprise desde 2007. Comecei a trabalhar com Ansible em 2016 e, como muitos outros usuários deste produto, fui atraído pela possibilidade de “truques” usando linha de comando e scripts simples (playbooks). No final de 2017, abordei minha gestão sobre os fortes motivos para mudar para o Ansible Tower. Em um minuto contarei a vocês os motivos que me levaram a dar esse passo. Depois de receber o consentimento da administração, foram necessários mais alguns meses para concluir o plano e fiz a transição entre janeiro e fevereiro deste ano. Então, abandonamos completamente o Puppet em favor do Ansible, e isso é ótimo.
O que mais me atrai no Ansible é a capacidade de escrever e usar funções e manuais. As funções são ótimas para criar tarefas distintas, mas relacionadas, e colocar todos os dados relacionados a essas tarefas em um só lugar. Um playbook é uma sintaxe YAML, um arquivo de script que descreve ações para um ou mais hosts. Falo aos usuários sobre esses recursos, principalmente aos desenvolvedores de software. O Ansible Tower oferece a capacidade de dizer: “não, você não tem acesso ao shell, mas eu dou a você a capacidade de executar todos os processos do Tower e reiniciar o serviço quando precisar”. Vou falar sobre o ambiente de trabalho e os equipamentos que utilizamos.
Esta é uma LAN federal, 7 sites físicos conectados via nuvem MPLS, 140 servidores RHEL, 99% dos quais são virtuais (vSphere), hardware SuperMicro, armazenamento de rede NexentaStore, um conjunto de switches Cisco, Arista e Cumulus e gerenciamento unificado de ameaças Fortinet UTM ferramentas em cada site.
A rede federal significa que devo utilizar todas as medidas de segurança da informação previstas em lei. Você deve ter em mente que o Puppet Enterprise não oferece suporte à maior parte do hardware que usamos. Somos forçados a utilizar hardware orçamental porque as agências governamentais têm problemas para financiar esta rubrica de despesas. É por isso que compramos hardware SuperMicro e montamos nossos equipamentos a partir de peças individuais, cuja manutenção é garantida por contratos governamentais. Usamos Linux e este é um dos motivos importantes para mudar para Ansible.
Nossa história com o Puppet é a seguinte.
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 web Puppet Dashboard para 45 nós. À medida que a rede continuou a se expandir, mudamos para o PE 2014 em 3.3, fazendo uma transição completa com uma reescrita do manifesto para 75 nós. Isso teve que ser feito porque o Puppet gosta de mudar as regras do jogo, e neste caso mudaram completamente a linguagem. Um ano depois, quando o suporte para a versão 3 do Puppet Enterprise terminou, fomos forçados a migrar para o PE 2015.2. Tivemos que reescrever o manifesto novamente para os novos servidores e adquirir uma licença com reserva de 100 nós, embora naquela época tivéssemos apenas 85 nós.
Apenas 2 anos se passaram e novamente tivemos que trabalhar muito para migrar para a nova versão PE 2016.4. Compramos uma licença para 300 nós, tendo apenas 130. Novamente tivemos que fazer grandes alterações no manifesto porque a nova versão da linguagem tinha uma sintaxe diferente da linguagem da versão 2015. Como resultado, nosso SCM mudou do controle de versão SVN para Bitbucket (Git). Esse foi o nosso “relacionamento” com o Puppet.
Então, tive que explicar à administração por que precisávamos mudar para um SCM diferente usando os seguintes argumentos. O primeiro é o alto preço do serviço. Conversei com o pessoal da RedHat e eles disseram que o custo de operação de uma rede de 300 nós com o Ansible Tower é metade do custo do Puppet Enterprise. Se você também adquirir o Ansible Engine, o custo será praticamente o mesmo, mas você terá muito mais recursos do que o PE. Como somos uma empresa estatal financiada pelo orçamento federal, este é um argumento bastante poderoso.
O segundo argumento é a versatilidade. O Puppet oferece suporte apenas a hardware que possui um agente Puppet. Isso significa que um agente deve estar instalado em todos os switches e deve ser a versão mais recente. E se alguns de seus switches suportarem uma versão e alguns suportarem outra, você precisará instalar uma nova versão do agente PE neles para que todos possam funcionar no mesmo sistema SCM.
O sistema Ansible Tower funciona de forma diferente porque não possui agentes, mas possui módulos que suportam switches Cisco e todos os outros switches. Este SCM suporta Qubes OS, Linux e 4.NET UTM. Ansible Tower também suporta controladores de armazenamento de rede NexentaStore baseados no kernel Illumos, um sistema operacional de código aberto baseado em Unix. Isso é muito pouco suporte, mas o Ansible Tower faz isso mesmo assim.
O terceiro argumento, que é muito importante tanto para mim como para a nossa administração, é a facilidade de utilização. Passei 10 anos dominando os módulos Puppet e o código de manifesto, mas aprendi Ansible em uma semana porque esse SCM é muito mais fácil de trabalhar. Se você executar arquivos executáveis, é claro, a menos que o faça desnecessariamente, manipuladores inteligentes e responsivos trabalharão com eles. Os playbooks baseados em YAML são fáceis de aprender e rápidos de usar. Aqueles que nunca ouviram falar de YAML podem simplesmente ler os scripts e entender facilmente como ele funciona.
Para ser honesto, o Puppet torna o seu trabalho como desenvolvedor muito mais difícil porque é baseado no uso do Puppet Master. É a única máquina com permissão para se comunicar com agentes Puppet. Se você fez alguma alteração no manifesto e deseja testar seu código, você deve reescrever o código do Puppet Master, ou seja, configurar o arquivo /etc/hosts do Puppet Master para conectar todos os clientes e iniciar o serviço Puppet Server. Somente depois disso você poderá testar o funcionamento do equipamento de rede em um host. Este é um procedimento bastante doloroso.
Tudo é muito mais simples no Ansible. Tudo que você precisa fazer é desenvolver código para uma máquina que possa se comunicar via SSH com o host em teste. Isso é muito mais fácil de trabalhar.
A próxima grande vantagem do Ansible Tower é a capacidade de aproveitar seu sistema de suporte existente e manter a configuração de hardware existente. Este SCM utiliza todas as informações disponíveis sobre sua infraestrutura e hardware, máquinas virtuais, servidores, etc., sem quaisquer etapas adicionais. Ele pode se comunicar com seus servidores RH Satellite, se você tiver um, e oferece integrações que você nunca obterá com o Puppet.
Outra coisa importante é o controle detalhado. Você sabe que o Puppet é um sistema modular, é uma aplicação cliente-servidor, então você deve definir os aspectos existentes de todas as suas máquinas em um longo manifesto. Neste 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 fantoche funciona.
A Torre salva você disso. Você pode executar uma variedade de processos em diversos equipamentos sem restrições; pode realizar trabalhos básicos, executar outros processos importantes, configurar um sistema de segurança e trabalhar com bancos de dados. Você pode fazer tudo o que é difícil no Puppet Enterprise. Portanto, se você configurou em um host, levará algum tempo para que as alterações tenham efeito nos hosts restantes. No Ansible, todas as alterações entram em vigor ao mesmo tempo.
Finalmente, vamos dar uma olhada no módulo de segurança. Ansible Tower implementa isso de forma simplesmente incrível, com grande precisão e cuidado. Você pode conceder 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, limitando seu acesso ao shell do Linux. Garanto que eles tenham acesso à Tower para que possam fazer apenas o trabalho e executar apenas os serviços que são relevantes para eles.
Vejamos o que você precisa fazer com antecedência para facilitar sua transição para o Ansible Tower. Primeiro de tudo, você precisa preparar seu equipamento. Se alguns elementos da sua infraestrutura ainda não estiverem no banco de dados, será necessário adicioná-los lá. Existem sistemas que não alteram suas características e portanto não estão no banco de dados do Puppet, mas se você não adicioná-los lá antes de passar para o Tower, perderá uma série de vantagens. Este pode ser um banco de dados preliminar “sujo”, mas deve conter informações sobre todos os equipamentos que você possui. Portanto, você deve escrever um script de hardware dinâmico que enviará automaticamente todas as alterações de infraestrutura para o banco de dados, então o Ansible saberá quais hosts devem estar presentes no novo sistema. Você não precisará informar a este SCM quais hosts você adicionou e quais hosts não existem mais, pois ele saberá tudo isso automaticamente. Quanto mais dados houver no banco de dados, mais útil e flexível será o Ansible. Funciona como se simplesmente lesse o código de barras de status do hardware de um banco de dados.
Passe algum tempo se familiarizando com a linha de comando do Ansible. Execute alguns comandos personalizados para testar o script de hardware, escreva e execute alguns scripts de manual simples, mas úteis, use modelos Jinja2 quando apropriado. Tente escrever uma função e um script para um processo complexo de várias etapas usando uma configuração de hardware comum e comumente encontrada. Brinque com essas coisas, teste como funciona. Dessa forma você aprenderá como usar as ferramentas de criação de bibliotecas utilizadas no Tower. Já disse que demorei cerca de 3 meses para me preparar para a transição. Acho que com base na minha experiência, você conseguirá fazer isso mais rápido. Não considere esse tempo uma perda de tempo, pois mais tarde você experimentará todos os benefícios do trabalho realizado.
Em seguida, você precisa decidir o que espera do Ansible Tower, o que exatamente esse sistema deve fazer por você.
Você precisa implantar o sistema em hardware simples, em máquinas virtuais simples? Ou você deseja manter as condições operacionais e configurações originais dos equipamentos existentes? Este é um aspecto muito importante para empresas públicas, então você precisa ter certeza de que será capaz de 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ê deseja fazer e priorize isso.
Em seguida, comece a escrever o código do script e as funções que permitirão as tarefas que você planeja concluir. Combine-os em Projetos, uma coleção lógica de manuais relevantes. Cada projeto pertencerá a um repositório Git separado ou a um repositório diferente dependendo de qual gerenciador de código você usa. Você pode gerenciar scripts e diretórios de playbook colocando-os manualmente no caminho base do projeto no servidor Tower ou colocando o playbook em qualquer sistema de gerenciamento de código-fonte (SCM) compatível com Tower, incluindo Git, Subversion, Mercurial e Red Hat Percepções. Dentro de um projeto você pode colocar quantos scripts desejar. Por exemplo, criei um projeto básico no qual coloquei um script para os elementos principais do RedHat, um script para o núcleo do Linux e scripts para o restante das linhas de base. Assim, em um projeto havia diversas funções e cenários gerenciados a partir de um repositório Git.
Executar todas essas coisas por meio da linha de comando é uma boa maneira de testar sua funcionalidade. Isto irá prepará-lo para a instalação da Torre.
Vamos falar um pouco sobre a transcodificação do manifesto do Puppet, pois gastei muito tempo nisso até descobrir o que realmente precisava ser feito.
Como eu disse antes, o Puppet armazena todas as configurações e opções de hardware em um longo manifesto, e esse manifesto armazena tudo o que esse SCM deve fazer. Ao fazer a transição, você não precisa amontoar 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 constar lá. Alguns dos elementos da rede autônoma devem ser agrupados em grupos para os quais scripts podem ser criados. Elementos de infraestrutura mais complexos que envolvem um grande número de recursos, incluindo classes independentes, podem ser combinados em funções. Antes de migrar, você precisa decidir sobre isso. Se estiver criando funções ou cenários grandes que não cabem em uma tela, você deverá usar tags para poder capturar partes específicas da infraestrutura.
18:00
Alguns anúncios 🙂
Obrigado por ficar com a gente. Gostou dos nossos artigos? Quer ver mais conteúdos interessantes? Apoie-nos fazendo um pedido ou recomendando a amigos, , um análogo exclusivo de servidores básicos, que foi inventado por nós para você: (disponível com RAID1 e RAID10, até 24 núcleos e até 40 GB DDR4).
Dell R730xd 2x mais barato no data center Equinix Tier IV em Amsterdã? Só aqui na Holanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - a partir de US$ 99! Ler sobre
Fonte: habr.com