{"id":80289,"date":"2020-05-05T01:42:36","date_gmt":"2020-05-04T23:42:36","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/ansible-migracziya-konfiguraczii-120-vm-c-coreos-na-centos-za-18-mesyaczev"},"modified":"2020-05-05T01:42:36","modified_gmt":"2020-05-04T23:42:36","slug":"ansible-migracziya-konfiguraczii-120-vm-c-coreos-na-centos-za-18-mesyaczev","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/ansible-migracziya-konfiguraczii-120-vm-c-coreos-na-centos-za-18-mesyaczev","title":{"rendered":"Ansible: Migra\u00e7\u00e3o da configura\u00e7\u00e3o de 120 VMs de CoreOS para CentOS em 18 meses","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Ansible:<\/p>\n

<\/p>\n

Esta \u00e9 a transcri\u00e7\u00e3o da apresenta\u00e7\u00e3o em DevopsConf 2019-10-01<\/a><\/noindex> e SPbLUG 2019-09-25<\/a><\/noindex>.<\/p>\n

<\/p>\n

Esta \u00e9 a hist\u00f3ria de um projeto que utilizou um sistema de gerenciamento de configura\u00e7\u00f5es feito sob medida e porque a migra\u00e7\u00e3o para o Ansible levou 18 meses.<\/p>\n

<\/a><\/noindex><\/p>\n

Dia n\u00ba -XXX: Antes do come\u00e7o<\/h2>\n

<\/p>\n

\"Ansible:<\/p>\n

<\/p>\n

Inicialmente, a infraestrutura consistia em v\u00e1rios hosts independentes gerenciados pelo Hyper-V. Criar uma m\u00e1quina virtual exigia v\u00e1rias a\u00e7\u00f5es: colocar os discos no lugar certo, configurar o DNS, reservar o DHCP, colocar a configura\u00e7\u00e3o da VM no reposit\u00f3rio git. Este processo foi parcialmente mecanizado, mas, por exemplo, as VMs eram distribu\u00eddas entre os hosts manualmente. No entanto, os desenvolvedores podiam corrigir a configura\u00e7\u00e3o da VM no git e aplic\u00e1-la reiniciando a VM.<\/p>\n

<\/p>\n

Solu\u00e7\u00e3o Personalizada de Gerenciamento de Configura\u00e7\u00e3o<\/h3>\n

<\/p>\n

\"Ansible:<\/p>\n

<\/p>\n

A ideia inicial, suspeito, foi pensada como IaC: v\u00e1rias VMs stateless que, ao reiniciar, zeravam seu estado. Como era o gerenciamento de configura\u00e7\u00f5es das VMs? Em termos esquem\u00e1ticos, parecia simples:<\/p>\n

<\/p>\n

    \n
  1. Para as VMs, um MAC est\u00e1tico era atribu\u00eddo.<\/li>\n
  2. Conectava-se uma ISO com o CoreOS e um disco de boot.<\/li>\n
  3. O CoreOS executa um script de customiza\u00e7\u00e3o, baixando-o do servidor WEB com base em seu IP.<\/li>\n
  4. O script baixa a configura\u00e7\u00e3o da VM via SCP, baseando-se no endere\u00e7o IP.<\/li>\n
  5. Uma s\u00e9rie de arquivos de unidade do systemd e uma s\u00e9rie de scripts bash s\u00e3o executados.<\/li>\n<\/ol>\n

    <\/p>\n

    \"Ansible:<\/p>\n

    <\/p>\n

    Essa solu\u00e7\u00e3o apresentava v\u00e1rios problemas \u00f3bvios:<\/p>\n

    <\/p>\n

      \n
    1. A ISO no CoreOS estava obsoleta.<\/li>\n
    2. Muitas a\u00e7\u00f5es complexas e m\u00e1gicas durante a migra\u00e7\u00e3o\/cria\u00e7\u00e3o das VMs.<\/li>\n
    3. Dificuldade com as atualiza\u00e7\u00f5es e quando um determinado software \u00e9 necess\u00e1rio. Isso se tornava ainda mais complicado com os m\u00f3dulos do kernel.<\/li>\n
    4. As VMs n\u00e3o estavam t\u00e3o desprovidas de dados assim, ou seja, surgiram VMs que montavam um disco adicional com dados do usu\u00e1rio.<\/li>\n
    5. Constantemente algu\u00e9m cometia erros com depend\u00eancias do systemd e, ao reiniciar, o CoreOS travava. Era problem\u00e1tico identificar isso com os recursos dispon\u00edveis no CoreOS.<\/li>\n
    6. Gerenciamento de segredos.<\/li>\n
    7. Praticamente n\u00e3o havia CM. Havia bash e arquivos de configura\u00e7\u00e3o YML do CoreOS.<\/li>\n<\/ol>\n

      <\/p>\n

      Para aplicar a configura\u00e7\u00e3o da VM, era necess\u00e1rio reinici\u00e1-la, mas ela poderia n\u00e3o reiniciar. Uma aparente problema \u00f3bvio, mas sem discos persistentes \u2014 n\u00e3o havia para onde salvar logs. Bem, vamos tentar adicionar op\u00e7\u00f5es de kernel para que os logs sejam enviados. Mas n\u00e3o, tudo isso era muito complicado.<\/p>\n

      <\/p>\n

      Dia n\u00ba 0: Reconhecimento do problema<\/h2>\n

      <\/p>\n

      \"Ansible:<\/p>\n

      <\/p>\n

      Essa era uma infraestrutura de desenvolvimento comum: jenkins, ambientes de teste, monitoramentos, registry. O CoreOS foi projetado para hospedar clusters k8s, ou seja, o problema estava em como o CoreOS era utilizado. O primeiro passo foi a escolha da pilha. N\u00f3s optamos por:<\/p>\n

      <\/p>\n

        \n
      1. CentOS<\/strong> como a distribui\u00e7\u00e3o base, pois esta \u00e9 a distribui\u00e7\u00e3o mais pr\u00f3xima de ambientes de produ\u00e7\u00e3o.<\/li>\n
      2. Ansible<\/strong> para gerenciamento de configura\u00e7\u00f5es, pois havia uma ampla expertise nessa \u00e1rea.<\/li>\n
      3. Jenkins<\/strong> como framework de automa\u00e7\u00e3o de processos existentes, pois j\u00e1 estava sendo utilizado ativamente nos processos de desenvolvimento.<\/li>\n
      4. Hyper-V<\/strong> como plataforma de virtualiza\u00e7\u00e3o. Existem v\u00e1rias raz\u00f5es, al\u00e9m do que foi contado, mas resumindo \u2014 n\u00e3o podemos usar nuvens, devemos usar nosso pr\u00f3prio hardware.<\/li>\n<\/ol>\n

        <\/p>\n

        Dia n\u00ba 30: Documentando acordos existentes \u2014 Agreements as Code<\/h3>\n

        <\/p>\n

        \"Ansible:<\/p>\n

        <\/p>\n

        Quando a pilha foi definida, a prepara\u00e7\u00e3o para a migra\u00e7\u00e3o come\u00e7ou. A codifica\u00e7\u00e3o dos acordos existentes como c\u00f3digo (Agreements as Code<\/strong>!). A transi\u00e7\u00e3o trabalho manual<\/em> -> mecaniza\u00e7\u00e3o<\/em> -> automa\u00e7\u00e3o<\/em>.<\/p>\n

        <\/p>\n

        1. Configurar VMs<\/h4>\n

        <\/p>\n

        \"Ansible:<\/p>\n

        <\/p>\n

        O Ansible lida muito bem com essa tarefa. Com o m\u00ednimo de esfor\u00e7o, podemos gerenciar as configura\u00e7\u00f5es das VMs:<\/p>\n

        <\/p>\n

          \n
        1. Criamos um reposit\u00f3rio git.<\/li>\n
        2. Colocamos a lista de VMs no invent\u00e1rio, as configura\u00e7\u00f5es nos playbooks e pap\u00e9is.<\/li>\n
        3. Configuramos um slave jenkins especial do qual ser\u00e1 poss\u00edvel executar o ansible.<\/li>\n
        4. Criamos um job, configuramos o Jenkins.<\/li>\n<\/ol>\n

          <\/p>\n

          O primeiro processo est\u00e1 pronto. Os acordos foram documentados.<\/p>\n

          <\/p>\n

          2. Criar nova VM<\/h4>\n

          <\/p>\n

          \"Ansible:<\/p>\n

          <\/p>\n

          Aqui tudo estava um pouco complicado. A partir do Linux, n\u00e3o \u00e9 muito f\u00e1cil criar VMs no Hyper-V. Uma das tentativas de automatizar esse processo foi:<\/p>\n

          <\/p>\n

            \n
          1. Ansible se conecta ao host Windows via WinRM.<\/li>\n
          2. Ansible executa um script PowerShell.<\/li>\n
          3. O script PowerShell cria uma nova VM.<\/li>\n
          4. Com ferramentas Hyper-V\/ScVMM, ao criar a VM, o hostname \u00e9 configurado no sistema operacional convidado.<\/li>\n
          5. A VM, ao renovar o lease DHCP, envia seu hostname.<\/li>\n
          6. A integra\u00e7\u00e3o padr\u00e3o ddns & dhcp no lado do Controller de Dom\u00ednio configura o registro DNS.<\/li>\n
          7. \u00c9 poss\u00edvel adicionar VMs ao invent\u00e1rio e configur\u00e1-las com Ansible.<\/li>\n<\/ol>\n

            <\/p>\n

            3. Criar template de VM<\/h4>\n

            <\/p>\n

            \"Ansible:<\/p>\n

            <\/p>\n

            Aqui n\u00e3o inventamos nada \u2014 usamos o packer.<\/p>\n

            <\/p>\n

              \n
            1. No reposit\u00f3rio git, colocamos a configura\u00e7\u00e3o do packer, kickstart.<\/li>\n
            2. Configuramos um slave jenkins especial com hyper-v e Packer.<\/li>\n
            3. Criamos um job, configuramos o Jenkins.<\/li>\n<\/ol>\n

              <\/p>\n

              Como funciona essa combina\u00e7\u00e3o:<\/p>\n

              <\/p>\n

                \n
              1. O Packer cria uma VM vazia e anexa o ISO.<\/li>\n
              2. A VM \u00e9 inicializada, o Packer informa ao carregador para usar nosso arquivo kickstart a partir do disquete ou http.<\/li>\n
              3. O anaconda \u00e9 iniciado com nossa configura\u00e7\u00e3o, efetuando a configura\u00e7\u00e3o inicial do sistema operacional.<\/li>\n
              4. O Packer aguarda a disponibilidade da VM.<\/li>\n
              5. O Packer dentro da VM executa o ansible em modo local.<\/li>\n
              6. O Ansible utiliza exatamente os mesmos pap\u00e9is que no passo n\u00ba 1.<\/li>\n
              7. O Packer exporta o modelo de VM.<\/li>\n<\/ol>\n

                <\/p>\n

                Dia n\u00ba 75: Refatorando acordos sem quebrar = Teste ansible + Testkitchen<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Fixar acordos no c\u00f3digo pode n\u00e3o ser suficiente. Afinal, se no fundo do processo voc\u00ea quiser mudar algo, pode acabar quebrando alguma coisa. Portanto, em infraestrutura, surge a necessidade de testar essa pr\u00f3pria infraestrutura. Para sincronizar o conhecimento dentro da equipe, come\u00e7amos a testar os pap\u00e9is do Ansible. N\u00e3o vou me aprofundar, pois h\u00e1 um artigo que descreve os eventos daquele momento. Teste-me se puder ou ser\u00e1 que os programadores YML sonham em testar ansible?<\/a><\/noindex>(spoiler: essa n\u00e3o foi a vers\u00e3o final e depois tudo ficou mais complicado. Como come\u00e7ar a testar Ansible, refatorar o projeto em um ano e n\u00e3o perder a cabe\u00e7a.<\/a><\/noindex>).<\/p>\n

                <\/p>\n

                Dia n\u00ba 130: E se CentOS+ansible n\u00e3o for necess\u00e1rio? E se for openshift?<\/h3>\n

                <\/p>\n

                \u00c9 importante entender que o processo de implementa\u00e7\u00e3o da infraestrutura n\u00e3o foi o \u00fanico, e houve subprojetos colaterais. Por exemplo, recebemos um pedido para rodar nosso aplicativo no openshift e isso se transformou em uma pesquisa que levou mais de uma semana. Estamos rodando o aplicativo no Openshift e comparando as ferramentas existentes.<\/a><\/noindex> O que atrasou o processo de migra\u00e7\u00e3o. O resultado foi que o openshift n\u00e3o atende todas as necessidades, \u00e9 necess\u00e1rio ter hardware real ou, pelo menos, a possibilidade de brincar com o n\u00facleo.<\/p>\n

                <\/p>\n

                Dia n\u00ba 170: Openshift n\u00e3o \u00e9 adequado, vamos arriscar com o Windows Azure Pack?<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Hyper-V n\u00e3o \u00e9 muito amig\u00e1vel, SCVMM n\u00e3o melhora muito a situa\u00e7\u00e3o. Mas existe o Windows Azure Pack, que \u00e9 uma camada sobre o SCVMM e imita o Azure. No entanto, na realidade, o produto parece abandonado: documenta\u00e7\u00e3o com links quebrados e bastante escassa. Mas, no \u00e2mbito da pesquisa por op\u00e7\u00f5es de simplificar a vida de nossa nuvem, tamb\u00e9m o analisamos.<\/p>\n

                <\/p>\n

                Dia n\u00ba 250: Windows Azure Pack n\u00e3o \u00e9 muito bom. Permanecemos no SCVMM.<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                O Windows Azure Pack parecia promissor, mas decidimos n\u00e3o introduzir o WAP com suas complexidades no sistema apenas por recursos desnecess\u00e1rios e ficamos com o SCVMM.<\/p>\n

                <\/p>\n

                Dia n\u00ba 360: Comendo um elefante por partes.<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                Somente ap\u00f3s um ano a plataforma estava pronta para a migra\u00e7\u00e3o e o processo de mudan\u00e7a come\u00e7ou. Para isso, definimos uma tarefa S.M.A.R.T. Listamos todas as VMs e come\u00e7amos a resolver uma por uma a configura\u00e7\u00e3o, descrevendo-a no Ansible e cobrindo-a com testes.<\/p>\n

                <\/p>\n

                Dia n\u00ba 450: Que sistema obtivemos?<\/h3>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                O processo em si n\u00e3o \u00e9 interessante. Ele \u00e9 rotineiro e pode-se notar que a maioria das configura\u00e7\u00f5es era relativamente simples ou isom\u00f3rficas, seguindo o princ\u00edpio de Pareto, onde 80% das configura\u00e7\u00f5es no WM exigiram 20% do tempo. Da mesma forma, 80% do tempo foi dedicado \u00e0 prepara\u00e7\u00e3o da mudan\u00e7a, e apenas 20% \u00e0 pr\u00f3pria mudan\u00e7a. <\/p>\n

                <\/p>\n

                Dia \u2116540: O Final<\/h2>\n

                <\/p>\n

                \"Ansible:<\/p>\n

                <\/p>\n

                O que aconteceu em 18 meses?<\/p>\n

                <\/p>\n

                  \n
                1. Os acordos tornaram-se c\u00f3digo.<\/li>\n
                2. Trabalho manual<\/em> -> Mecaniza\u00e7\u00e3o<\/em> -> Automa\u00e7\u00e3o<\/em>.<\/li>\n<\/ol>\n

                  <\/p>\n

                  Links<\/h2>\n

                  <\/p>\n