{"id":35513,"date":"2019-10-31T22:04:46","date_gmt":"2019-10-31T19:04:46","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ansible-obnovleniya-v-klyuchevyh-resheniyah-dlya-avtomatizatsii-vashego-mira\/"},"modified":"2019-10-31T22:04:46","modified_gmt":"2019-10-31T19:04:46","slug":"ansible-obnovleniya-v-klyuchevyh-resheniyah-dlya-avtomatizatsii-vashego-mira","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/ansible-obnovleniya-v-klyuchevyh-resheniyah-dlya-avtomatizatsii-vashego-mira","title":{"rendered":"Ansible: atualiza\u00e7\u00f5es em solu\u00e7\u00f5es-chave para automatizar seu mundo","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

A comunidade Ansible continua a surpreender com novos conte\u00fados \u2013 plugins e m\u00f3dulos \u2013 criando muito trabalho novo para aqueles que est\u00e3o envolvidos na manuten\u00e7\u00e3o do Ansible, j\u00e1 que o novo c\u00f3digo precisa ser integrado o mais r\u00e1pido poss\u00edvel nos reposit\u00f3rios. Cumprir prazos nem sempre \u00e9 poss\u00edvel, e o lan\u00e7amento de alguns produtos prontos para a produ\u00e7\u00e3o \u00e9 adiado at\u00e9 a pr\u00f3xima vers\u00e3o oficial do Ansible Engine. At\u00e9 recentemente, o usu\u00e1rio final tinha apenas uma maneira de obter novo conte\u00fado Ansible \u2013 junto com a nova vers\u00e3o do Ansible Engine.<\/p>\n

\"Ansible:
\n
\nPara eliminar a inconveni\u00eancia, a comunidade Ansible come\u00e7ou a trabalhar em op\u00e7\u00f5es mais flex\u00edveis para a cria\u00e7\u00e3o e obten\u00e7\u00e3o de conte\u00fado.
\n<\/a><\/noindex><\/p>\n

Red Hat Ansible Engine 2.8: em dire\u00e7\u00e3o a novos m\u00e9todos de manipula\u00e7\u00e3o de conte\u00fado Ansible<\/h3>\n

\nEm resposta \u00e0s solicita\u00e7\u00f5es dos usu\u00e1rios, o Ansible Engine 2.8 trouxe mudan\u00e7as relacionadas ao processamento de conte\u00fado, que n\u00e3o faz parte do lan\u00e7amento oficial<\/b>. Essas altera\u00e7\u00f5es permitir\u00e3o implementar um novo m\u00e9todo de entrega de conte\u00fado aos usu\u00e1rios, que n\u00e3o depender\u00e1 da equipe de manuten\u00e7\u00e3o do Ansible ao gerenciar tanto o conte\u00fado do Ansible quanto o c\u00f3digo da pr\u00f3pria plataforma.<\/p>\n

Est\u00e1 previsto que nas pr\u00f3ximas vers\u00f5es, os Criadores (Creators) de conte\u00fado poder\u00e3o fornec\u00ea-lo na forma de pacotes especiais, chamados Coletas (Collection), que poder\u00e3o ser instalados no local apropriado para execu\u00e7\u00e3o no n\u00f3 principal do Ansible (control node) ou no n\u00f3 gerenciado (managed node). O criador da cole\u00e7\u00e3o especificar\u00e1 diretamente no pacote os detalhes da execu\u00e7\u00e3o usando pap\u00e9is e playbooks. Gra\u00e7as \u00e0s mudan\u00e7as mencionadas no Ansible Engine, as cole\u00e7\u00f5es se tornar\u00e3o uma das ferramentas que permitir\u00e3o desvincular o lan\u00e7amento de conte\u00fado do lan\u00e7amento das vers\u00f5es oficiais do Ansible Engine<\/b>.<\/p>\n

Nova constru\u00e7\u00e3o Become<\/h4>\n

\nA constru\u00e7\u00e3o Become existe h\u00e1 algum tempo, mas a partir da vers\u00e3o 2.8, a palavra BECOME \u00e9 usada por padr\u00e3o no Ansible Engine para solicitar a senha ao elevar privil\u00e9gios (priv\u00e9gios sudo em sistemas *nix ou modo enable em dispositivos de rede). Em outras palavras, agora BECOME \u00e9 a ferramenta padr\u00e3o para eleva\u00e7\u00e3o de privil\u00e9gios, que j\u00e1 lida com o sistema-alvo por conta pr\u00f3pria.<\/p>\n

Aqui est\u00e1 um exemplo de seu uso:<\/p>\n

ansible-playbook --become --ask-become-pass site.yml\nBECOME password:\n<\/code><\/pre>\n
\nAl\u00e9m disso, o Ansible Engine 2.8 agora possui um plugin BECOME, que funciona como doas no Linux e como runas no Windows, permitindo executar a\u00e7\u00f5es em nome de um usu\u00e1rio espec\u00edfico. Para elevar privil\u00e9gios em dispositivos de rede, \u00e9 usado o plugin become enable.<\/p>\n
Buscar o interpretador Python<\/h4>\n
\nVoc\u00ea pode j\u00e1 ter se deparado com um erro como este:<\/p>\n
\/usr\/bin\/python: bad interpreter: No such file or directory\n<\/code><\/pre>\n
\nA quest\u00e3o \u00e9 que, nas vers\u00f5es anteriores do Ansible Engine, era considerado padr\u00e3o que o interpretador Python principal (utilizado por padr\u00e3o) estivesse localizado na pasta \/usr\/bin\/python. A partir da vers\u00e3o 2.8, o Ansible procura o interpretador em cada sistema alvo, primeiro verificando a tabela de caminhos e nomes do arquivo execut\u00e1vel do interpretador Python principal em diferentes distribui\u00e7\u00f5es, e depois usando listas ordenadas de interpretadores de fallback (fallback list), consulte mais detalhes em Guia de Portabilidade para o Ansible 2.8<\/a><\/noindex>.<\/p>\n
Arquivos Retry n\u00e3o s\u00e3o mais criados por padr\u00e3o<\/h4>\n
\nVoc\u00ea j\u00e1 procurou arquivos .retry no disco? Se voc\u00ea usa o Ansible h\u00e1 algum tempo, provavelmente tem muitos deles, e eles ocupam espa\u00e7o \u00fatil. A partir da vers\u00e3o 2.8, o Ansible Engine n\u00e3o cria mais esses arquivos por padr\u00e3o (o que pode ser revertido editando o arquivo ansible.cfg padr\u00e3o).<\/p>\n
Play Recap Atualizado<\/h4>\n
\nTrecho de Guias de Portabilidade para o Ansible 2.8<\/a><\/noindex>:<\/p>\n
O Play Recap agora contabiliza tarefas (tasks) com status ignored e rescued, al\u00e9m de ok, changed, unreachable, failed e skipped, gra\u00e7as a dois novos contadores de estat\u00edsticas no plugin callback default. Tarefas falhas para as quais a flag ignore_errors: yes foi definida s\u00e3o contabilizadas como ignored. Tarefas falhas para as quais uma se\u00e7\u00e3o rescue foi acionada s\u00e3o contabilizadas como rescued. Observe que, ao contr\u00e1rio das vers\u00f5es anteriores do Ansible, tarefas rescued n\u00e3o s\u00e3o mais contabilizadas como failed.<\/p><\/blockquote>\n
\nE na tabela do Play Recap ao final da execu\u00e7\u00e3o do playbook, os hosts agora t\u00eam colunas adicionais skipped, rescued e ignored:<\/p>\n
\"Ansible:<\/p>\n
Nuvens e Containers<\/h4>\n
\nNa vers\u00e3o 2.8, foram implementadas melhorias e adi\u00e7\u00f5es nos m\u00f3dulos de nuvem e container para trabalhar com Amazon Web Services, Microsoft Azure, Google Cloud, Digital Ocean, podman<\/a><\/noindex> e kubevirt<\/a><\/noindex>. Tamb\u00e9m \u00e9 importante notar que arquivos TOML agora podem ser usados como fonte de invent\u00e1rio.<\/p>\n
Paramiko<\/h4>\n
\nVoc\u00ea est\u00e1 usando o Red Hat Ansible Network Automation? O Ansible Engine 2.8 n\u00e3o inclui mais o paramiko e n\u00e3o depende dele. Por padr\u00e3o, o Ansible Engine usa ssh. Se voc\u00ea precisar do paramiko, poder\u00e1 instal\u00e1-lo com o comando pip install paramiko.<\/p>\n
Se voc\u00ea precisa de suporte sobre o uso do paramiko dentro da assinatura da Red Hat, consulte o artigo da base de conhecimento. Pacote Paramiko ausente ap\u00f3s novas instala\u00e7\u00f5es do Ansible Engine.<\/a><\/noindex>.<\/p>\n
Assim, a nova vers\u00e3o do Red Hat Ansible Engine foi refor\u00e7ada com uma impressionante lista de melhorias e mudan\u00e7as, que voc\u00ea pode consultar. aqui<\/a><\/noindex>.<\/b><\/p>\n
Red Hat Ansible Tower 3.5: mais automa\u00e7\u00e3o.<\/h3>\n
\nDesde o final de maio, a nova vers\u00e3o do Red Hat Ansible Tower 3.5 est\u00e1 dispon\u00edvel, oferecendo v\u00e1rias melhorias significativas para automa\u00e7\u00e3o, sobre as quais vamos falar se voc\u00ea ainda n\u00e3o teve a oportunidade de verificar.<\/p>\n
Ent\u00e3o, primeiro os principais pontos:<\/p>\n