O Serviço Nacional de Dados Espaciais Ambientais (NESDIS) reduziu em 35% os seus custos de gestão de configuração do Red Hat Enterprise Linux (RHEL) ao mudar do Puppet Enterprise para o Ansible Tower. Neste vídeo da categoria "como fizemos", o engenheiro de sistema Michael Rau justifica a realização desta migração, compartilha dicas úteis e a experiência adquirida ao fazer a transição de um SCM para outro.
Neste vídeo, você irá aprender:
- como justificar a transição do Puppet Enterprise para o Ansible Tower para a gestão;
- quais estratégias usar para uma transição mais suave;
- dicas para transcodificar manifestos do PE em Ansible Playbook;
- recomendações para uma instalação otimizada do Ansible Tower.
Olá a todos, meu nome é Michael Rau, sou engenheiro de sistema sênior da ActioNet, que trabalha para a Administração Nacional Oceânica e Atmosférica (NOAA) no serviço NESDIS. Hoje, vamos falar sobre as lições aprendidas – minha própria experiência na migração do Puppet Enterprise para o Ansible Tower. O objetivo desta apresentação é "mostrar minhas cicatrizes", deixadas após essa transição no início do ano. Eu quero compartilhar o que aprendi ao longo desse processo. Portanto, quando você embarcar em algo semelhante, usando minha experiência, poderá fazer a transição com mais facilidade.
Você verá slides como 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 novato nisso, pois uso Puppet/Puppet Enterprise desde 2007. Comecei a trabalhar com Ansible em 2016, e eu, assim como muitos outros usuários deste produto, fiquei atraído pela possibilidade dos "truques" com a linha de comando e scripts simples (playbooks). No final de 2017, conversei com a minha gestão sobre razões sérias para a transição para o Ansible Tower. Dentro de um minuto, falarei sobre os motivos que me levaram a essa decisão. Depois de obter a aprovação da gestão, levou mais alguns meses para implementar o planejado e realizei a transição em janeiro e fevereiro deste ano. Assim, abandonamos completamente o Puppet em favor do Ansible, e isso é uma grande conquista.
O que mais me atrai no Ansible é a possibilidade de escrever e usar roles e playbooks. Roles são ótimas para criar tarefas diversas, mas interconectadas, e para reunir todos os dados relacionados a essas tarefas em um só lugar. Um playbook é uma sintaxe YAML, um arquivo-script que descreve ações para um ou mais hosts. Apresento essas funcionalidades aos usuários, principalmente desenvolvedores de software. O Ansible Tower permite dizer: 'não, você não tem acesso ao shell, mas eu ofereço a você a capacidade de iniciar todos os processos do Tower e reiniciar o serviço quando precisar'. Vou falar sobre o ambiente de trabalho e o hardware que utilizamos.
Esta é uma LAN federal, com 7 sites físicos conectados via MPLS na nuvem, 140 servidores RHEL, 99% dos quais são virtuais (vSphere), hardware SuperMicro, armazenamento em rede NexentaStore, um conjunto de switches Cisco, Arista e Cumulus, e soluções de gerenciamento unificado de ameaças Fortinet UTM em cada site.
Uma rede federal significa que devo usar todos os meios de proteção de informações previstos nas legislações. Você deve ter em mente que o Puppet Enterprise não suporta a maior parte do hardware que usamos. Somos forçados a utilizar hardware de baixo custo, pois as entidades governamentais enfrentam problemas de financiamento nesta área. Portanto, compramos 'hardware' da linha SuperMicro e montamos nosso equipamento a partir de partes individuais, cuja manutenção é garantida por contratos governamentais. Usamos Linux, e essa é uma das razões importantes para a migração para o Ansible.
Nossa história de trabalho com Puppet é a seguinte.
Em 2007, tínhamos uma pequena rede com 20-25 nós, na qual implementamos o Puppet. Na maior parte, esses nós eram apenas "caixas" RedHat. Em 2010, começamos a utilizar a interface web Puppet Dashboard para 45 nós. À medida que a rede continuava a se expandir, em 2014, migramos para o PE 3.3, fazendo uma transição completa com a reescrita do manifesto para 75 nós. Tivemos que fazer isso porque o Puppet gosta de mudar as regras do jogo, e, nesse caso, eles mudaram completamente a linguagem. Um ano depois, quando o suporte à terceira versão do Puppet Enterprise foi encerrado, fomos forçados a migrar para o PE 2015.2. Novamente, tivemos que reescrever o manifesto para os novos servidores e adquirir uma licença para 100 nós, mesmo que tivéssemos apenas 85 nós na época.
Passaram-se apenas 2 anos, e tivemos que fazer novamente um grande trabalho de transição para a nova versão PE 2016.4. Compramos uma licença para 300 nós, tendo apenas 130. Novamente, precisávamos fazer mudanças significativas no manifesto, pois a nova versão da linguagem tinha uma sintaxe diferente da versão de 2015. Como resultado, nosso SCM mudou do sistema de controle de versão SVN para o Bitbucket (Git). Essas foram nossas "relações" com o Puppet.
Assim, tive que explicar à diretoria por que precisávamos mudar para outro SCM, usando os seguintes argumentos. Primeiro - o alto custo do serviço. Conversei com o pessoal da RedHat, e eles disseram que o custo de manter uma rede de 300 nós usando o Ansible Tower é metade do custo do Puppet Enterprise. Se adquirirmos também o Ansible Engine, o custo será mais ou menos o mesmo, mas você obterá muito mais recursos do que com o PE. Como somos uma empresa estatal financiada com verba federal, esse é um argumento considerável.
O segundo argumento é a versatilidade. O Puppet suporta apenas o hardware onde o agente Puppet está instalado. Isso significa que em todos os switches é necessário instalar o agente, e ele deve ser a versão mais recente. E se parte dos seus switches suporta uma versão, enquanto outra parte suporta outra, você precisará instalar a nova versão do agente PE para que todos possam operar em um único sistema SCM.
O sistema Ansible Tower funciona de maneira diferente, pois não possui agentes, mas tem módulos que suportam switches Cisco e outros switches. Este SCM suporta Qubes OS, Linux e 4.NET UTM. O Ansible Tower também é compatível com controladores de armazenamento em rede NexentaStore, baseados no núcleo Illumos – um sistema operacional open-source baseado em Unix. Este suporte é bastante limitado, mas ainda assim, o Ansible Tower proporciona essa funcionalidade.
O terceiro argumento, que é muito importante tanto para mim quanto para nossa administração, é a facilidade de aprendizado. Eu passei 10 anos estudando módulos e códigos manifestos do Puppet, mas aprendi Ansible em uma semana, pois este SCM é muito mais fácil de trabalhar. Se você está executando arquivos executáveis, claro, a menos que você faça isso desnecessariamente, há manipuladores que são razoáveis e responsivos. Os playbooks, baseados em YAML, são caracterizados pela fácil aprendizagem e rapidez de uso. Aqueles que nunca ouviram falar de YAML podem simplesmente ler os scripts e entender facilmente como funciona.
Sinceramente, o Puppet torna seu trabalho como desenvolvedor muito mais complicado, pois é baseado no uso do Puppet Master. Esta é a única máquina que tem permissão para se comunicar com os agentes do Puppet. Se você fizer alguma alteração no manifesto e quiser testar seu código, terá que reescrever o código para o Puppet Master, ou seja, configurar o arquivo Puppet master /etc/hosts para conectar todos os clientes e iniciar o serviço Puppet Server. Só depois disso você poderá testar a operação do equipamento de rede em um único host. Esse é um processo bastante doloroso.
Com o Ansible, tudo é muito mais simples. Tudo o que você precisa fazer é desenvolver o código para uma máquina que tenha a capacidade de se conectar via SSH ao host de teste. É muito mais fácil trabalhar com isso.
Outra grande vantagem do Ansible Tower é a capacidade de utilizar o sistema de suporte que você já possui e manter a configuração de hardware existente. Este SCM, sem ações adicionais, utiliza todas as informações disponíveis sobre sua infraestrutura e hardware, máquinas virtuais, servidores etc. Ele pode se comunicar com seus servidores RH Satellite, se existirem, e oferece uma integração que você nunca obterá trabalhando com o Puppet.
Outra coisa importante é o controle detalhado. Você sabe que o Puppet é um sistema modular, sendo um aplicativo cliente-servidor, portanto você deve definir os aspectos existentes do funcionamento de todas as suas máquinas em um longo manifesto. Nesse ínterim, o estado de cada elemento separado do sistema deve ser testado a cada meia hora – esse é o período padrão. É assim que o Puppet funciona.
O Tower elimina essa necessidade. Você pode executar uma variedade de processos em diferentes equipamentos sem restrições, realizar tarefas principais, iniciar outros processos importantes, configurar a segurança do sistema e trabalhar com bancos de dados. Você pode fazer tudo isso que no Puppet Enterprise envolve certas dificuldades. Assim, se você configurou em um host, levará um tempo para que as mudanças tenham efeito nos outros hosts. No Ansible, todas as mudanças ocorrem ao mesmo tempo.
Por fim, vamos considerar o módulo de segurança. No Ansible Tower, ele é implementado de forma impressionante, com grande precisão e atenção aos detalhes. Você pode conceder aos usuários acesso a serviços específicos ou a hosts específicos. Eu faço isso com meus funcionários que estão acostumados a trabalhar em Windows, limitando seu acesso ao shell do Linux. Eu lhes garanto acesso ao Tower, para que possam realizar apenas o trabalho e iniciar apenas os serviços que estão dentro de sua competência.
Vamos considerar os passos que precisam ser feitos com antecedência para facilitar a transição para o Ansible Tower. Em primeiro lugar, é necessário preparar seu hardware. Se alguns elementos da sua infraestrutura ainda não estiverem no banco de dados, eles devem ser adicionados. 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 os inserir antes da transição para o Tower, perderá uma série de benefícios. Pode ser um banco de dados preliminar "bagunçado", mas deve conter informações sobre todo o hardware que você possui. Portanto, você deve escrever um script dinâmico para hardware que automaticamente registre todas as mudanças na infraestrutura no banco de dados, para que o Ansible saiba quais hosts devem existir no novo sistema. Você não precisará informar a esta SCM quais hosts você adicionou e quais hosts não existem mais, porque tudo isso será descoberto automaticamente. Quanto mais dados houver no banco de dados, mais útil e flexível será o Ansible. Ele opera como se simplesmente estivesse lendo o código de barras do estado do hardware do banco de dados.
Reserve um tempo para se familiarizar com o uso da linha de comando no Ansible. Execute alguns comandos especiais para testar o funcionamento do script de hardware, escreva e execute alguns cenários simples, mas úteis, de playbook, utilize templates Jinja2 onde for adequado. Tente escrever um papel e um script para um processo complexo de várias etapas, utilizando uma configuração de hardware padrão e frequentemente encontrada. Brinque com essas coisas, teste como funcionam. Dessa forma, você aprenderá a trabalhar com ferramentas para criar bibliotecas usadas no Tower. Já mencionei que minha preparação para a transição levou cerca de 3 meses. Acredito que, com base na minha experiência, você conseguirá fazer isso mais rapidamente. Não considere esse tempo como perdido, pois mais tarde você sentirá todos os benefícios do trabalho realizado.
Em seguida, é necessário decidir o que você espera do Ansible Tower, o que exatamente este sistema deve fazer por você.
Você precisa implementar o sistema em um equipamento vazio, em máquinas virtuais vazias? Ou deseja manter as condições de trabalho e configurações do hardware existente? Este é um aspecto muito importante para empresas estatais, portanto, você deve ter certeza de que conseguirá realizar a migração e implementar o Ansible na configuração existente. Defina os processos administrativos rotineiros que deseja automatizar. Verifique se precisa implementar aplicativos e serviços específicos no novo sistema. Crie uma lista do que deseja fazer e priorize.
Em seguida, comece a escrever o código dos scripts e funções que garantirão a execução das tarefas que você planejou. Agrupe-os em Projects, uma coleção lógica de scripts playbooks correspondentes. Cada Project será relacionado a um repositório Git separado ou outro repositório, dependendo do gerenciador de código que você utiliza. Você pode gerenciar scripts de playbook e diretórios de playbook colocando-os manualmente no Project Base Path no servidor Tower, ou colocando o playbook em qualquer sistema de controle de versão (SCM) compatível com o Tower, incluindo Git, Subversion, Mercurial e Red Hat Insights. Dentro de um Project, você pode colocar quantos scripts quiser. Por exemplo, criei um Project básico onde coloquei um script para os elementos principais do RedHat, um script para a base do Linux e scripts para outros indicadores básicos. Assim, em um único projeto, havia funções e scripts variados que eram gerenciados a partir de um único repositório Git.
Execute todas essas tarefas através da linha de comando, é uma boa maneira de verificar se estão funcionando. Assim, você se preparará para a instalação do Tower.
Vamos falar um pouco sobre a transcodificação do manifesto Puppet, porque eu gastei muito tempo nisso até perceber o que realmente precisava ser feito.
Como mencionei, o Puppet armazena todas as configurações e parâmetros de hardware em um único manifesto extenso, e neste manifesto estão contidas todas as ações que este SCM deve realizar. Na transição, você não precisa enfiar todas as suas tarefas em uma única lista; em vez disso, pense na estrutura do novo sistema: funções, cenários, tags, grupos e o que deve ser incluído. Alguns dos elementos autônomos da rede devem ser agrupados em coleções para as quais é possível criar cenários. 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, é preciso definir isso. Se você estiver criando funções ou cenários abrangentes que não cabem em uma única tela, deve usar tags para conseguir capturar partes específicas da infraestrutura.
18:00
Um pouco de publicidade 🙂
Obrigado por permanecer conosco. Você gosta dos nossos artigos? Quer ver mais materiais interessantes? Apoie-nos fazendo um pedido ou recomendando para conhecidos. , uma alternativa única aos servidores entry-level, que criamos para você: (disponíveis opções com RAID1 e RAID10, até 24 núcleos e até 40GB DDR4).
Dell R730xd por 2 vezes mais barato no datacenter Equinix Tier IV em Amsterdã? Somente conosco na Holanda! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — a partir de $99! Leia sobre
Fonte: habr.com
