{"id":34841,"date":"2019-10-31T22:00:43","date_gmt":"2019-10-31T19:00:43","guid":{"rendered":"https:\/\/prohoster.info\/blog\/avtomatizatsiya-zameny-diskov-s-pomoshhyu-ansible\/"},"modified":"2019-10-31T22:00:43","modified_gmt":"2019-10-31T19:00:43","slug":"avtomatizatsiya-zameny-diskov-s-pomoshhyu-ansible","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/avtomatizatsiya-zameny-diskov-s-pomoshhyu-ansible","title":{"rendered":"Automatiza\u00e7\u00e3o da troca de discos usando Ansible","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Automatiza\u00e7\u00e3o da troca de discos usando Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/c60a2326ab13e7766eafda3ae5ac39c5.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOl\u00e1 a todos. Trabalho como administrador de sistemas s\u00eanior na OK e sou respons\u00e1vel pela opera\u00e7\u00e3o est\u00e1vel do portal. Quero compartilhar como estabelecemos o processo de troca autom\u00e1tica de discos e, em seguida, como removemos o administrador desse processo e o substitu\u00edmos por um bot.<\/p>\n<p>Este artigo \u00e9 uma esp\u00e9cie de translitera\u00e7\u00e3o <noindex><a rel=\"nofollow\" href=\"https:\/\/www.youtube.com\/watch?v=5WhbG3FQveE&amp;list=FLKN7KW1sxju7fWJvKuyKxEQ\">da apresenta\u00e7\u00e3o<\/a><\/noindex> no HighLoad+ 2018<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Estabelecimento do processo de troca de discos<\/h2>\n<p><\/p>\n<h3>Primeiro, alguns n\u00fameros<\/h3>\n<p>\nA OK \u00e9 um gigante servi\u00e7o utilizado por milh\u00f5es de pessoas. Contamos com cerca de 7.000 servidores, localizados em 4 data centers diferentes. Esses servidores cont\u00eam mais de 70.000 discos. Se empilh\u00e1ssemos todos, obter\u00edamos uma torre com mais de 1 km de altura. <\/p>\n<p>Discos r\u00edgidos s\u00e3o o componente do servidor que mais falha. Com esse volume, precisamos trocar cerca de 30 discos por semana, e esse procedimento se tornou uma rotina bastante desagrad\u00e1vel.<\/p>\n<p><img decoding=\"async\" alt=\"Automatiza\u00e7\u00e3o da troca de discos usando Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/5e915e9077994efcc4e74a26fc6286fa.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Incidentes<\/h3>\n<p>\nEm nossa empresa, implementamos uma gest\u00e3o de incidentes completa. Registramos cada incidente no Jira, depois o resolvemos e analisamos. Se o incidente tiver efeito para os usu\u00e1rios, nos reunimos para pensar em como reagir mais rapidamente em tais casos, como reduzir o impacto e, claro, como prevenir recorr\u00eancias.<\/p>\n<p>Os drives n\u00e3o s\u00e3o exce\u00e7\u00e3o. Seu estado \u00e9 monitorado pelo Zabbix. Monitoramos mensagens no Syslog em busca de erros de leitura\/escrita, analisamos o estado de RAID HW\/SW, e monitoramos o SMART, calculando o desgaste para SSDs. <\/p>\n<h3>Como os discos eram trocados antes<\/h3>\n<p>\nQuando um determinado gatilho acende no Zabbix, um incidente \u00e9 criado no Jira e automaticamente designado para os engenheiros correspondentes nos data centers. Fazemos isso para todos os incidentes de hardware, ou seja, aqueles que exigem algum trabalho f\u00edsico com o equipamento no data center. <br \/>\nO engenheiro do data center \u00e9 a pessoa que resolve quest\u00f5es relacionadas ao hardware, respons\u00e1vel pela instala\u00e7\u00e3o, manuten\u00e7\u00e3o e desmontagem de servidores. Ao receber um ticket, o engenheiro inicia o trabalho. Nas estantes de discos, ele troca os discos por conta pr\u00f3pria. Mas se n\u00e3o tiver acesso ao dispositivo necess\u00e1rio, o engenheiro solicita aux\u00edlio aos administradores de sistemas de plant\u00e3o. Primeiro, \u00e9 necess\u00e1rio retirar o disco da rota\u00e7\u00e3o. Para isso, s\u00e3o feitas as altera\u00e7\u00f5es necess\u00e1rias no servidor, param-se os aplicativos e desmonta-se o disco.<\/p>\n<p>O administrador de sistema de plant\u00e3o durante o turno de trabalho \u00e9 respons\u00e1vel pelo funcionamento de todo o portal. Ele investiga incidentes, realiza reparos e ajuda os desenvolvedores a executar pequenas tarefas. Ele n\u00e3o cuida apenas dos discos r\u00edgidos.<\/p>\n<p>Anteriormente, os engenheiros do data center se comunicavam com o administrador de sistema pelo chat. Os engenheiros enviavam links para tickets do Jira, o administrador os revisava e mantinha um log de trabalho em algum caderno. Por\u00e9m, para essas tarefas, os chats s\u00e3o inconvenientes: as informa\u00e7\u00f5es n\u00e3o s\u00e3o estruturadas e se perdem rapidamente. Al\u00e9m disso, o administrador poderia se afastar do computador e demorar a responder \u00e0s solicita\u00e7\u00f5es, enquanto o engenheiro aguardava ao lado do servidor com uma pilha de discos.<\/p>\n<p>Mas o pior era que os administradores n\u00e3o conseguiam ver o panorama geral: quais eram os incidentes de disco existentes e onde poderiam surgir problemas potenciais. Isso ocorre porque transferimos todos os incidentes de hardware para os engenheiros. Sim, era poss\u00edvel exibir todos os incidentes no dashboard do administrador. Mas eram muitos, e o administrador era envolvido apenas em alguns deles.<\/p>\n<p>Al\u00e9m disso, o engenheiro n\u00e3o conseguia definir corretamente as prioridades, pois n\u00e3o sabe a finalidade dos servidores espec\u00edficos, nem como as informa\u00e7\u00f5es est\u00e3o distribu\u00eddas entre os dispositivos de armazenamento.<\/p>\n<h3>Novo procedimento de substitui\u00e7\u00e3o<\/h3>\n<p>\nA primeira coisa que fizemos foi criar um novo tipo de incidente de disco, chamado 'HW-disco', e adicionamos campos para 'nome do dispositivo de bloco', 'tamanho' e 'tipo de disco', para que essas informa\u00e7\u00f5es fossem salvas no ticket, evitando a necessidade de troc\u00e1-las constantemente pelo chat. <\/p>\n<p><img decoding=\"async\" alt=\"Automatiza\u00e7\u00e3o da troca de discos usando Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/c4526bf668e31d90e0fbd061de44f1a7.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nAl\u00e9m disso, concordamos que, dentro de um \u00fanico incidente, mudar\u00edamos apenas um disco. Isso simplificou significativamente o processo de automa\u00e7\u00e3o, a coleta de estat\u00edsticas e o trabalho futuro. <\/p>\n<p>Al\u00e9m disso, adicionamos um campo para 'administrador respons\u00e1vel'. Esse campo \u00e9 automaticamente preenchido com o administrador de sistema de plant\u00e3o. Isso \u00e9 muito conveniente, pois agora o engenheiro sempre sabe quem \u00e9 o respons\u00e1vel. N\u00e3o \u00e9 mais necess\u00e1rio consultar o calend\u00e1rio e procurar. Esse campo permitiu que os tickets que poderiam necessitar de sua ajuda fossem exibidos no dashboard do administrador.<\/p>\n<p><img decoding=\"async\" alt=\"Automatiza\u00e7\u00e3o da troca de discos usando Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/5097e5dcca1fddd68d1e5f296c09f60a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nPara que todos os participantes se beneficiem ao m\u00e1ximo das inova\u00e7\u00f5es, criamos filtros e pain\u00e9is e os apresentamos \u00e0 equipe. Quando as pessoas compreendem as mudan\u00e7as, n\u00e3o se distanciam delas como se fossem desnecess\u00e1rias. \u00c9 importante que o engenheiro saiba o n\u00famero do rack onde o servidor est\u00e1 localizado, bem como o tamanho e tipo do disco. Para o administrador, \u00e9 fundamental entender, em primeiro lugar, que grupo de servidores se trata e qual pode ser o efeito da substitui\u00e7\u00e3o do disco.<\/p>\n<p>A disponibilidade de campos e sua exibi\u00e7\u00e3o \u00e9 conveniente, mas isso n\u00e3o nos isentou da necessidade de usar chats. Para isso, tivemos que alterar o fluxo de trabalho. <\/p>\n<p>Antes, ele era assim:<\/p>\n<p><img decoding=\"async\" alt=\"Automatiza\u00e7\u00e3o da troca de discos usando Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/2b79cdb7ec88b5ae3d2917ad8b164c6d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nHoje, os engenheiros continuam a trabalhar assim, quando n\u00e3o precisam da ajuda do administrador.<\/p>\n<p>A primeira coisa que fizemos foi introduzir um novo status <b>Investigate<\/b>. Neste status, o ticket permanece enquanto o engenheiro ainda n\u00e3o decidiu se precisar\u00e1 do administrador ou n\u00e3o. Atrav\u00e9s deste status, o engenheiro pode transferir o ticket para o administrador. Al\u00e9m disso, usamos esse status para marcar tickets que requerem a substitui\u00e7\u00e3o de um disco, mas o disco em si n\u00e3o est\u00e1 dispon\u00edvel no local. Isso pode ocorrer no caso de CDN e locais remotos.<\/p>\n<p>N\u00f3s tamb\u00e9m adicionamos o status <b>Pronto<\/b>. O ticket \u00e9 transferido para este status ap\u00f3s a substitui\u00e7\u00e3o do disco. Ou seja, tudo j\u00e1 foi feito, mas o RAID HW\/SW no servidor ainda est\u00e1 sendo sincronizado. Isso pode levar bastante tempo.<\/p>\n<p>Se um administrador \u00e9 envolvido no trabalho, o esquema se torna um pouco mais complicado.<\/p>\n<p><img decoding=\"async\" alt=\"Automatiza\u00e7\u00e3o da troca de discos usando Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/5b6aacbb0d4049e62e7cb9ee28eb6498.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nA partir do status <b>Abrir<\/b> , o ticket pode ser transferido tanto pelo administrador do sistema quanto pelo engenheiro. No status <b>In progress<\/b> , o administrador remove o disco da rota\u00e7\u00e3o, para que o engenheiro possa simplesmente remov\u00ea-lo: ativa a ilumina\u00e7\u00e3o, desmonta o disco, para aplica\u00e7\u00f5es, dependendo do grupo espec\u00edfico de servidores.<\/p>\n<p>Em seguida, o ticket \u00e9 transferido para <b>Ready to change<\/b>: isso sinaliza ao engenheiro que o disco pode ser removido. Todos os campos no Jira j\u00e1 est\u00e3o preenchidos, e o engenheiro sabe qual \u00e9 o tipo e o tamanho do disco. Essas informa\u00e7\u00f5es s\u00e3o preenchidas automaticamente no status anterior ou pelo administrador.<\/p>\n<p>Ap\u00f3s a substitui\u00e7\u00e3o do disco, o ticket \u00e9 transferido para o status <b>Changed<\/b>. Verifica-se se o disco correto foi instalado, realiza-se a configura\u00e7\u00e3o, o aplicativo \u00e9 iniciado e algumas tarefas de recupera\u00e7\u00e3o de dados s\u00e3o executadas. Al\u00e9m disso, o ticket pode ser transferido para o status <b>Pronto<\/b>, nesse caso, o respons\u00e1vel continuar\u00e1 sendo o administrador, pois ele introduziu o disco na rota\u00e7\u00e3o. O esquema completo \u00e9 o seguinte.<\/p>\n<p><img decoding=\"async\" alt=\"Automatiza\u00e7\u00e3o da troca de discos usando Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/32f8d488e2ff6a28a3341114b66de0a3.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nA adi\u00e7\u00e3o de novos campos facilitou bastante a nossa vida. A equipe come\u00e7ou a trabalhar com informa\u00e7\u00f5es estruturadas, ficou claro o que e em que etapa era necess\u00e1rio fazer. As prioridades tornaram-se muito mais relevantes, pois agora s\u00e3o definidas pelo administrador.<\/p>\n<p>A necessidade de chats desapareceu. Claro, o administrador pode enviar uma mensagem para o engenheiro dizendo '\u00e9 necess\u00e1rio substituir isso mais rapidamente' ou 'j\u00e1 \u00e9 noite, voc\u00ea consegue substituir?'. Mas j\u00e1 n\u00e3o conversamos diariamente nos chats sobre essas quest\u00f5es.<\/p>\n<p>Os discos come\u00e7aram a ser trocados em lotes. Se o administrador chega ao trabalho um pouco mais cedo e tem algum tempo livre, e nada ocorreu at\u00e9 ent\u00e3o, ele pode preparar uma s\u00e9rie de servidores para substitui\u00e7\u00e3o: marcar os campos, remover os discos da rota\u00e7\u00e3o e passar a tarefa para o engenheiro. O engenheiro chega um pouco mais tarde ao data center, v\u00ea a tarefa, pega os dispositivos necess\u00e1rios do estoque e realiza a troca imediatamente. Como resultado, a velocidade de substitui\u00e7\u00e3o aumentou.<\/p>\n<h3>Experi\u00eancia adquirida na constru\u00e7\u00e3o de Workflow<\/h3>\n<p><\/p>\n<ul>\n<li><b>Ao construir o procedimento, \u00e9 necess\u00e1rio coletar informa\u00e7\u00f5es de diferentes fontes.<\/b><br \/>\nAlguns dos nossos administradores n\u00e3o sabiam que o engenheiro trocava os discos sozinho. Alguns achavam que a sincroniza\u00e7\u00e3o do MD RAID era acompanhada pelos engenheiros, embora alguns deles nem tivessem acesso para isso. Alguns engenheiros seniores faziam isso, mas nem sempre, porque o processo n\u00e3o estava documentado em lugar algum.<\/li>\n<li><b>O procedimento deve ser simples e claro.<\/b><br \/>\n\u00c9 dif\u00edcil para uma pessoa manter muitos passos na cabe\u00e7a. Os status mais importantes e vizinhos no Jira devem ser destacados na tela principal. Podemos renome\u00e1-los, por exemplo, chamamos 'In progress' de 'Pronto para mudar'. E os outros status podem ser escondidos em um menu suspenso, para que n\u00e3o fiquem chamando aten\u00e7\u00e3o. Mas \u00e9 melhor n\u00e3o limitar as pessoas, dar a oportunidade de fazer a transi\u00e7\u00e3o.<br \/>\nExplique o valor das inova\u00e7\u00f5es. Quando as pessoas entendem, elas aceitam melhor o novo procedimento. Para n\u00f3s, era muito importante que as pessoas n\u00e3o apenas clicassem em todo o processo, mas seguissem por ele. Depois, constru\u00edmos a automa\u00e7\u00e3o com base nisso.<\/li>\n<li><b>Aguarde, analise, compreenda.<\/b><br \/>\nLevamos cerca de um m\u00eas para estabelecer o procedimento, a implementa\u00e7\u00e3o t\u00e9cnica, reuni\u00f5es e discuss\u00f5es. E a implementa\u00e7\u00e3o levou mais de tr\u00eas meses. Vi como as pessoas come\u00e7aram a usar a nova funcionalidade aos poucos. Nos primeiros est\u00e1gios, houve muito negativismo. Mas isso n\u00e3o dependia do procedimento em si, nem da sua implementa\u00e7\u00e3o t\u00e9cnica. Por exemplo, um administrador usava n\u00e3o o Jira, mas o plugin Jira no Confluence, e algumas coisas n\u00e3o estavam dispon\u00edveis para ele. Mostramos o Jira para ele, e a produtividade do administrador aumentou tanto nas tarefas gerais quanto nas substitui\u00e7\u00f5es de discos.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Automa\u00e7\u00e3o da substitui\u00e7\u00e3o de discos<\/h2>\n<p>\nTentamos v\u00e1rias vezes automatizar a substitui\u00e7\u00e3o de discos. J\u00e1 t\u00ednhamos desenvolvido alguns scripts, mas todos funcionavam de forma interativa ou manual, exigindo execu\u00e7\u00e3o. E s\u00f3 depois da implementa\u00e7\u00e3o do novo procedimento percebemos que era exatamente isso que nos faltava.<\/p>\n<p>Como agora o processo de substitui\u00e7\u00e3o est\u00e1 dividido em etapas, cada uma com um respons\u00e1vel e uma lista de a\u00e7\u00f5es, podemos implementar a automa\u00e7\u00e3o gradualmente, e n\u00e3o tudo de uma vez. Por exemplo, a etapa mais simples \u2014 Ready (verifica\u00e7\u00e3o de sincroniza\u00e7\u00e3o RAID\/dados) \u2014 pode ser facilmente delegada a um bot. Quando o bot se familiarizar um pouco, podemos lhe dar uma tarefa mais importante \u2014 inserir discos na rota\u00e7\u00e3o, entre outras.<\/p>\n<h3>Zool\u00f3gico de configura\u00e7\u00f5es<\/h3>\n<p>\nAntes de falarmos sobre o bot, faremos uma breve excurs\u00e3o pelo nosso zool\u00f3gico de instala\u00e7\u00f5es. Em primeiro lugar, isso se deve ao enorme tamanho da nossa infraestrutura. Em segundo lugar, tentamos adaptar a configura\u00e7\u00e3o de hardware ideal para cada servi\u00e7o. Temos cerca de 20 modelos de RAID de hardware, principalmente LSI e Adaptec, mas tamb\u00e9m encontramos HP e DELL de v\u00e1rias vers\u00f5es. Cada controlador RAID tem sua pr\u00f3pria utilidade de gerenciamento. O conjunto de comandos e as sa\u00eddas podem variar de vers\u00e3o para vers\u00e3o em cada controlador RAID. Onde n\u00e3o se usa HW-RAID, pode haver mdraid.<\/p>\n<p>Praticamente todas as novas instala\u00e7\u00f5es que fazemos s\u00e3o sem redund\u00e2ncia de disco. Tentamos n\u00e3o usar mais RAID de hardware e software, pois fazemos a redund\u00e2ncia dos nossos sistemas a n\u00edvel de data centers e n\u00e3o de servidores. Mas, claro, h\u00e1 muitos servidores legados que precisam ser mantidos.<\/p>\n<p>Em algum lugar, os discos em controladores RAID geram dispositivos raw, enquanto em outros, s\u00e3o usados JBOD. Existem configura\u00e7\u00f5es com um disco do sistema no servidor e, se ele precisar ser substitu\u00eddo, \u00e9 necess\u00e1rio reinstalar o servidor com o sistema operacional e aplicativos, inclusive as mesmas vers\u00f5es, depois adicionar arquivos de configura\u00e7\u00e3o e executar os aplicativos. Tamb\u00e9m h\u00e1 muitos grupos de servidores onde a redund\u00e2ncia \u00e9 feita n\u00e3o no n\u00edvel da subsistema de disco, mas diretamente nos pr\u00f3prios aplicativos.<\/p>\n<p>No total, temos mais de 400 grupos \u00fanicos de servidores, onde cerca de 100 aplicativos diferentes est\u00e3o em funcionamento. Para cobrir essa enorme variedade de op\u00e7\u00f5es, precis\u00e1vamos de uma ferramenta de automa\u00e7\u00e3o multifuncional. Preferencialmente com um DSL simples, para que pudesse ser mantido n\u00e3o apenas por quem o escreveu.<\/p>\n<p>Escolhemos o Ansible porque \u00e9 agentless: n\u00e3o era necess\u00e1rio preparar a infraestrutura, e a configura\u00e7\u00e3o inicial \u00e9 r\u00e1pida. Al\u00e9m disso, ele \u00e9 escrito em Python, que \u00e9 considerado padr\u00e3o pela equipe.<\/p>\n<h3>Esquema geral<\/h3>\n<p>\nVamos analisar o esquema geral de automa\u00e7\u00e3o usando um exemplo de um incidente. O Zabbix detecta que o disco sdb falhou, um trigger \u00e9 acionado e um ticket \u00e9 criado no Jira. O administrador verifica, percebe que n\u00e3o \u00e9 um duplicado nem um falso positivo, ou seja, o disco precisa ser trocado, e move o ticket para In progress.<\/p>\n<p><img decoding=\"async\" alt=\"Automatiza\u00e7\u00e3o da troca de discos usando Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/673df0fe9600bc65633841222f436d37.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nO aplicativo DiskoBot, escrito em Python, consulta periodicamente o Jira em busca de novos tickets. Ele nota que um novo ticket In progress foi criado, um thread correspondente \u00e9 acionado, que executa o playbook no Ansible (isso \u00e9 feito para cada status no Jira). Neste caso, o Prepare2change \u00e9 acionado.<\/p>\n<p>O Ansible \u00e9 enviado para o host, retira o disco da rota\u00e7\u00e3o e reporta o status ao aplicativo atrav\u00e9s de Callbacks. <\/p>\n<p><img decoding=\"async\" alt=\"Automatiza\u00e7\u00e3o da troca de discos usando Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/8bfc13129f8deca640eb63ea81f616c7.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nComo resultado, o bot automaticamente muda o ticket para Ready to change. O engenheiro recebe uma notifica\u00e7\u00e3o e vai substituir o disco, ap\u00f3s o que muda o ticket para Changed. <\/p>\n<p><img decoding=\"async\" alt=\"Automatiza\u00e7\u00e3o da troca de discos usando Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/eeda06b6966f435e2172d3f9c61b341e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nDe acordo com o esquema descrito, o ticket volta para o bot, que aciona outro playbook, vai at\u00e9 o host e reintegra o disco na rota\u00e7\u00e3o. O bot fecha o ticket. Ura!<\/p>\n<p><img decoding=\"async\" alt=\"Automatiza\u00e7\u00e3o da troca de discos usando Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/51b8c7050b0c10c16ad6a6d4974c3ebf.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nAgora vamos conversar sobre alguns componentes do sistema.<\/p>\n<h3>Diskobot<\/h3>\n<p>\nEste aplicativo \u00e9 escrito em Python. Ele seleciona tickets do Jira com base em JQL. Dependendo do status do ticket, este \u00e9 direcionado ao correspondente handler, que, por sua vez, aciona o playbook do Ansible correspondente ao status.<\/p>\n<p>JQL e os intervalos de pesquisa s\u00e3o definidos no arquivo de configura\u00e7\u00e3o do aplicativo.<\/p>\n<pre><code class=\"plaintext\">jira_states:\n  investigate:\n    jql: '\u2026 status = Open and \"Disk Size\" is EMPTY'\n    interval: 180\n\n  inprogress:\n    jql: '\u2026  and \"Disk Size\" is not EMPTY and \"Device Name\" is not EMPTY'\n \n  ready:\n    jql: '\u2026 and (labels not in (\"dbot_ignore\") or labels is EMPTY)'\n    interval: 7200\n<\/code><\/pre>\n<p>\nPor exemplo, entre os tickets no status Em progresso, s\u00e3o selecionados apenas aqueles nos quais os campos Disk size e Device name est\u00e3o preenchidos. Device name \u00e9 o nome do dispositivo de bloco necess\u00e1rio para a execu\u00e7\u00e3o do playbook. Disk size \u00e9 necess\u00e1rio para que o engenheiro saiba qual o tamanho do disco requerido.<\/p>\n<p>J\u00e1 entre os tickets com status Pronto, s\u00e3o filtrados os tickets com o r\u00f3tulo dbot_ignore. Por falar nisso, usamos r\u00f3tulos do Jira tanto para esse tipo de filtragem quanto para marcar duplicatas de tickets e coletar estat\u00edsticas.<\/p>\n<p>Em caso de falha do playbook, o Jira atribui o r\u00f3tulo dbot_failed, para que se possa investigar posteriormente. <\/p>\n<h3>Intera\u00e7\u00e3o com o Ansible<\/h3>\n<p>\nO aplicativo interage com o Ansible atrav\u00e9s do <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.ansible.com\/ansible\/latest\/dev_guide\/developing_api.html\">Ansible Python API<\/a><\/noindex>. No playbook_executor, passamos o nome do arquivo e um conjunto de vari\u00e1veis. Isso permite manter o projeto Ansible na forma de arquivos yml normais, em vez de descrev\u00ea-lo em c\u00f3digo Python. <\/p>\n<p>Al\u00e9m disso, no Ansible, atrav\u00e9s de *extra_vars*, s\u00e3o passados o nome do dispositivo de bloco, o status do ticket e tamb\u00e9m o callback_url, no qual est\u00e1 embutido o issue key \u2014 usado para callback em HTTP.<\/p>\n<p>Para cada execu\u00e7\u00e3o, gera-se um invent\u00e1rio tempor\u00e1rio, composto por um \u00fanico host e um grupo do qual esse host faz parte, para que se apliquem os group_vars.<\/p>\n<p>Aqui est\u00e1 um exemplo de tarefa, na qual \u00e9 implementado o callback HTTP.<\/p>\n<p>Recebemos o resultado da execu\u00e7\u00e3o dos playbooks atrav\u00e9s de callback(-s). Eles s\u00e3o de dois tipos:<\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/docs.ansible.com\/ansible\/latest\/plugins\/callback.html\">Ansible callback plugin<\/a><\/noindex>, que fornece dados sobre os resultados da execu\u00e7\u00e3o do playbook. Nele est\u00e3o descritas as tarefas que foram iniciadas, executadas com sucesso ou n\u00e3o. Esse callback \u00e9 chamado ao final da execu\u00e7\u00e3o do playbook.<\/li>\n<li>HTTP callback para obter informa\u00e7\u00f5es durante a execu\u00e7\u00e3o do playbook. Na tarefa do Ansible, realizamos uma solicita\u00e7\u00e3o POST\/GET em dire\u00e7\u00e3o ao nosso aplicativo.<\/li>\n<\/ul>\n<p>\nAtrav\u00e9s dos HTTP callback(-s) s\u00e3o passadas as vari\u00e1veis que foram definidas durante a execu\u00e7\u00e3o do playbook e que desejamos armazenar e usar em execu\u00e7\u00f5es posteriores. Esses dados s\u00e3o gravados em sqlite.<\/p>\n<p>Al\u00e9m disso, atrav\u00e9s do HTTP callback, deixamos coment\u00e1rios e modificamos o status do ticket.<\/p>\n<p><b class=\"spoiler_title\">HTTP callback<\/b><\/p>\n<pre><code class=\"plaintext\"># Make callback to Diskobot App\n# Variables:\n#    callback_post_body: # A dict with follow keys. All keys are optional\n#       msg: If exist it would be posted to Jira as comment\n#       data: If exist it would be saved in Incident.variables\n#       desire_state: Set desire_state for incident\n#       status: If exist Proceed issue to that status\n\n  - name: Callback to Diskobot app (jira comment\/status)\n    uri:\n      url: \"{{ callback_url }}\/{{ devname }}\"\n      user: \"{{ diskobot_user }}\"\n      password: \"{{ diskobot_pass }}\"\n      force_basic_auth: True\n      method: POST\n      body: \"{{ callback_post_body | to_json }}\"\n      body_format: json\n    delegate_to: 127.0.0.1\n<\/code><\/pre>\n<p>Como muitas tarefas similares, n\u00f3s a transferimos para um arquivo comum e inclu\u00edmos quando necess\u00e1rio, para n\u00e3o repetir constantemente nos playbooks. Aqui figura o callback_url, onde est\u00e3o embutidos o issue key e o host name. Quando o Ansible executa essa requisi\u00e7\u00e3o POST, o bot entende que ela foi enviada dentro de determinado incidente.<\/p>\n<p>Aqui est\u00e1 um exemplo de um playbook, no qual desmontamos um disco de um dispositivo MD:<\/p>\n<pre><code class=\"plaintext\">  # Save mdadm configuration\n  - include: common\/callback.yml\n    vars:\n      callback_post_body:\n        status: 'Ready to change'\n        msg: \"Removed disk from mdraid {{ mdadm_remove_disk.msg | comment_jira }}\"\n        data:\n          mdadm_data: \"{{ mdadm_remove_disk.removed }}\"\n          parted_info: \"{{ parted_info | default() }}\"\n    when:\n      - mdadm_remove_disk | changed\n      - mdadm_remove_disk.removed\n<\/code><\/pre>\n<p>\nEssa tarefa transforma o ticket do Jira no status \"Pronto para altera\u00e7\u00e3o\" e adiciona um coment\u00e1rio. Al\u00e9m disso, na vari\u00e1vel mdam_data \u00e9 mantida uma lista de dispositivos MD dos quais o disco foi removido, e em parted_info \u2014 um dump da parti\u00e7\u00e3o do parted. <\/p>\n<p>Quando o engenheiro inserir um novo disco, poderemos usar essas vari\u00e1veis para restaurar o dump das parti\u00e7\u00f5es, al\u00e9m de adicionar o disco nos dispositivos MD de onde ele foi removido.<\/p>\n<h3>Modo de verifica\u00e7\u00e3o do Ansible<\/h3>\n<p>\nAtivar a automa\u00e7\u00e3o foi assustador. Portanto, decidimos executar todos os playbooks no modo <br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/docs.ansible.com\/ansible\/latest\/user_guide\/playbooks_checkmode.html\">dry run<\/a><\/noindex>, no qual o Ansible n\u00e3o executa nenhuma a\u00e7\u00e3o nos servidores, apenas as emula. <\/p>\n<p>Esse tipo de execu\u00e7\u00e3o passa por um m\u00f3dulo de callback separado, e o resultado da execu\u00e7\u00e3o do playbook \u00e9 salvo no Jira como um coment\u00e1rio.<\/p>\n<p><img decoding=\"async\" alt=\"Automatiza\u00e7\u00e3o da troca de discos usando Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/b02d7f1dc428f2797ae8556cd496b115.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEm primeiro lugar, isso permitiu validar o funcionamento do bot e dos playbooks. Em segundo lugar, aumentou a confian\u00e7a dos administradores no bot. <\/p>\n<p>Quando conseguimos a valida\u00e7\u00e3o e entendemos que poder\u00edamos executar o Ansible n\u00e3o apenas no modo dry run, fizemos um bot\u00e3o Run Diskobot no Jira para executar o mesmo playbook com as mesmas vari\u00e1veis no mesmo host, mas no modo normal. <\/p>\n<p>Al\u00e9m disso, o bot\u00e3o \u00e9 usado para reiniciar o playbook em caso de falha.<\/p>\n<h3>Estrutura dos Playbooks<\/h3>\n<p>\nJ\u00e1 mencionei que, dependendo do status do ticket do Jira, o bot executa diferentes playbooks.<\/p>\n<p>Em primeiro lugar, isso torna a organiza\u00e7\u00e3o de entrada muito mais simples. <br \/>\nEm segundo lugar, em alguns casos isso \u00e9 simplesmente necess\u00e1rio. <\/p>\n<p>Por exemplo, ao substituir o disco do sistema, \u00e9 necess\u00e1rio primeiro ir ao sistema de implanta\u00e7\u00e3o, criar uma tarefa e, ap\u00f3s a implanta\u00e7\u00e3o correta, o servidor se tornar\u00e1 acess\u00edvel via ssh, e podemos instalar o aplicativo nele. Se fiz\u00e9ssemos tudo isso em um \u00fanico playbook, o Ansible n\u00e3o conseguiria execut\u00e1-lo devido \u00e0 indisponibilidade do host.<\/p>\n<p>Usamos fun\u00e7\u00f5es do Ansible para cada grupo de servidores. Aqui podemos ver como os playbooks est\u00e3o organizados em um deles. <\/p>\n<p><img decoding=\"async\" alt=\"Automatiza\u00e7\u00e3o da troca de discos usando Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/7a14035392b33f01d3182d5fff779321.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n\u00c9 conveniente, pois \u00e9 imediatamente claro onde est\u00e3o localizadas as tarefas. No arquivo main.yml, que \u00e9 a entrada para o papel Ansible, podemos ter apenas uma inclus\u00e3o pelo status do ticket ou tarefas gerais necess\u00e1rias para todos, como passar por uma identifica\u00e7\u00e3o ou obter um token.<\/p>\n<h4>Investigation.yml<\/h4>\n<p>\nExecutado para tickets nos status Investigation e Open. O mais importante para este playbook \u00e9 o nome do dispositivo de bloco. Esta informa\u00e7\u00e3o nem sempre est\u00e1 dispon\u00edvel. <\/p>\n<p>Para obt\u00ea-la, analisamos o resumo do Jira, o \u00faltimo valor do trigger do Zabbix. Pode conter o nome do dispositivo de bloco \u2014 a\u00ed temos sorte. Pode conter o ponto de montagem, \u2014 ent\u00e3o precisamos ir ao servidor, fazer um parsing e calcular o disco necess\u00e1rio. O trigger tamb\u00e9m pode transmitir um endere\u00e7o SCSI ou alguma outra informa\u00e7\u00e3o. Mas pode acontecer que n\u00e3o haja nenhuma pista, e temos que analisar.<\/p>\n<p>Depois de descobrir o nome do dispositivo de bloco, coletamos informa\u00e7\u00f5es sobre o tipo e o tamanho do disco para preencher os campos no Jira. Tamb\u00e9m coletamos dados sobre o fornecedor, modelo, firmware, ID, SMART, e tudo isso \u00e9 inserido no coment\u00e1rio no ticket do Jira. Agora o administrador e o engenheiro n\u00e3o precisam procurar esses dados. \ud83d\ude42<\/p>\n<p><img decoding=\"async\" alt=\"Automatiza\u00e7\u00e3o da troca de discos usando Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/259bf8712c013ee00d238f111b4280fb.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<h4>prepare2change.yml<\/h4>\n<p>\nRetirando o disco da rota\u00e7\u00e3o, prepara\u00e7\u00e3o para substitui\u00e7\u00e3o. A etapa mais complicada e cr\u00edtica. \u00c9 aqui que podemos parar um aplicativo quando n\u00e3o deve ser parado. Ou retirar um disco que n\u00e3o tinha as r\u00e9plicas, afetando assim os usu\u00e1rios e perdendo alguns dados. Aqui temos mais verifica\u00e7\u00f5es e notifica\u00e7\u00f5es no chat.<\/p>\n<p>No caso mais simples, trata-se da remo\u00e7\u00e3o do disco do HW\/MD RAID. <\/p>\n<p>Em situa\u00e7\u00f5es mais complexas (nos nossos sistemas de armazenamento), quando a redund\u00e2ncia \u00e9 realizada no n\u00edvel do aplicativo, \u00e9 necess\u00e1rio acessar o aplicativo via API, informar sobre a remo\u00e7\u00e3o do disco, desativ\u00e1-lo e iniciar a recupera\u00e7\u00e3o.<\/p>\n<p>Atualmente estamos migrando em massa para <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/odnoklassniki\/blog\/346868\">a nuvem<\/a><\/noindex>, e se o servidor \u00e9 em nuvem, o Diskobot se comunica com a API da nuvem, informa que est\u00e1 prestes a trabalhar com este min\u00fasculo \u2014 servidor onde os cont\u00eaineres est\u00e3o rodando \u2014 e pede \"migre todos os cont\u00eaineres deste min\u00fasculo\". E ao mesmo tempo ativa a ilumina\u00e7\u00e3o do disco, para que o engenheiro veja imediatamente qual deve ser retirado.<\/p>\n<h4>changed.yml<\/h4>\n<p>\nAp\u00f3s a substitui\u00e7\u00e3o do disco, primeiro verificamos sua disponibilidade. <\/p>\n<p>Os engenheiros nem sempre instalam novos discos, por isso adicionamos uma verifica\u00e7\u00e3o dos valores SMART que nos satisfazem.<\/p>\n<p><b class=\"spoiler_title\">Quais atributos estamos observando<\/b>Contagem de Setores Re alocados (5) &lt; 100<br \/>\nContagem de Setores Pendentes Atuais (107) == 0<\/p>\n<p>Se o disco n\u00e3o passar na verifica\u00e7\u00e3o, o engenheiro \u00e9 informado sobre a necessidade de troca. Se tudo estiver em ordem, a ilumina\u00e7\u00e3o se apaga, a marca\u00e7\u00e3o \u00e9 feita e o disco \u00e9 colocado em rota\u00e7\u00e3o.<\/p>\n<h4>ready.yml<\/h4>\n<p>\nO caso mais simples: verifica\u00e7\u00e3o da sincroniza\u00e7\u00e3o de RAID HW\/SW ou o t\u00e9rmino da sincroniza\u00e7\u00e3o de dados no aplicativo.<\/p>\n<h3>API de aplicativos<\/h3>\n<p>\nMencionei v\u00e1rias vezes que frequentemente um bot acessa a API de aplicativos. Claro, nem todos os aplicativos tinham os m\u00e9todos necess\u00e1rios, ent\u00e3o foi preciso desenvolv\u00ea-los. Aqui est\u00e3o os m\u00e9todos mais importantes que utilizamos:<\/p>\n<ul>\n<li>Status. Status do cluster ou disco, para entender se \u00e9 poss\u00edvel trabalh\u00e1-lo;\n<\/li>\n<li>Iniciar\/parar. Ativa\u00e7\u00e3o-desativa\u00e7\u00e3o do disco;\n<\/li>\n<li>Migrar\/restaurar. Migra\u00e7\u00e3o e recupera\u00e7\u00e3o de dados durante e ap\u00f3s a substitui\u00e7\u00e3o.\n<\/li>\n<\/ul>\n<p><\/p>\n<h3>Experi\u00eancia adquirida com Ansible<\/h3>\n<p>\nEu realmente gosto do Ansible. Mas frequentemente, ao olhar para diferentes projetos de c\u00f3digo aberto e ver como as pessoas escrevem playbooks, fico um pouco assustado. Interliga\u00e7\u00f5es l\u00f3gicas complexas de when\/loop, falta de flexibilidade e idempot\u00eancia devido ao uso frequente de shell\/comando.<\/p>\n<p>Decidimos simplificar ao m\u00e1ximo, aproveitando a modularidade do Ansible. No n\u00edvel mais alto est\u00e3o os playbooks, que podem ser escritos por qualquer administrador ou desenvolvedor externo que saiba um pouco sobre Ansible.<\/p>\n<pre><code class=\"plaintext\">- name: Piscar disco\n  become: True\n  register: locate_action\n  disk_locate:\n      locate: '{{ locate }}'\n      devname: '{{ devname }}'\n      ids: '{{ locate_ids | default(pd_id) | default(omit) }}'\n<\/code><\/pre>\n<p>Se alguma l\u00f3gica for dif\u00edcil de implementar em playbooks, a extra\u00edmos em um m\u00f3dulo ou filtro do Ansible. Os scripts podem ser escritos em Python ou em qualquer outro idioma. <\/p>\n<p>Eles s\u00e3o f\u00e1ceis e r\u00e1pidos de escrever. Por exemplo, o m\u00f3dulo de ilumina\u00e7\u00e3o do disco, cujo exemplo de uso foi dado acima, consiste em 265 linhas.<\/p>\n<p><img decoding=\"async\" alt=\"Automatiza\u00e7\u00e3o da troca de discos usando Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/08e0384bfad24f3ee61e0643ca087852.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNo n\u00edvel mais baixo est\u00e1 a biblioteca. Para este projeto, escrevemos um aplicativo separado, uma esp\u00e9cie de abstra\u00e7\u00e3o sobre RAID de hardware e software, que executa as solicita\u00e7\u00f5es correspondentes. <\/p>\n<p><img decoding=\"async\" alt=\"Automatiza\u00e7\u00e3o da troca de discos usando Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/0edda3182026ce6279bd84c99613e3d6.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOs pontos fortes do Ansible s\u00e3o a simplicidade e os playbooks compreens\u00edveis. Acredito que devemos aproveitar isso e n\u00e3o gerar arquivos yaml assustadores e uma enorme quantidade de condi\u00e7\u00f5es, c\u00f3digo em shell e loops.<\/p>\n<p>Se voc\u00ea quiser repetir nossa experi\u00eancia com a API do Ansible, tenha em mente duas coisas:<\/p>\n<ul>\n<li>Com o Playbook_executor, n\u00e3o \u00e9 poss\u00edvel definir um timeout para o playbook. Existe um timeout para sess\u00f5es SSH, mas n\u00e3o h\u00e1 timeout para o playbook. Se tentarmos desmontar um disco que n\u00e3o existe mais no sistema, o playbook ser\u00e1 executado indefinidamente, por isso foi necess\u00e1rio envolv\u00ea-lo em um wrapper separado e finaliz\u00e1-lo pelo timeout.\n<\/li>\n<li>O Ansible funciona com base em processos fork, portanto sua API n\u00e3o \u00e9 thread-safe. Executamos todos os nossos playbooks de forma single-thread.\n<\/li>\n<\/ul>\n<p>\nComo resultado, conseguimos automatizar a substitui\u00e7\u00e3o de cerca de 80% dos discos. No geral, a velocidade de substitui\u00e7\u00e3o dobrou. Hoje, o administrador apenas observa o incidente e decide se \u00e9 necess\u00e1rio trocar o disco ou n\u00e3o, e ent\u00e3o faz um \u00fanico clique.<\/p>\n<p>Mas agora come\u00e7amos a enfrentar outro problema: alguns dos novos administradores n\u00e3o sabem como trocar os discos. \ud83d\ude42<br \/>\n<br \/>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/odnoklassniki\/blog\/452110\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442. \u042f \u0440\u0430\u0431\u043e\u0442\u0430\u044e \u0432\u0435\u0434\u0443\u0449\u0438\u043c \u0441\u0438\u0441\u0442\u0435\u043c\u043d\u044b\u043c \u0430\u0434\u043c\u0438\u043d\u0438\u0441\u0442\u0440\u0430\u0442\u043e\u0440\u043e\u043c \u0432 \u041e\u041a \u0438 \u043e\u0442\u0432\u0435\u0447\u0430\u044e \u0437\u0430 \u0441\u0442\u0430\u0431\u0438\u043b\u044c\u043d\u0443\u044e \u0440\u0430\u0431\u043e\u0442\u0443 \u043f\u043e\u0440\u0442\u0430\u043b\u0430. \u0425\u043e\u0447\u0443 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u0442\u044c \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u043c\u044b \u0432\u044b\u0441\u0442\u0440\u043e\u0438\u043b\u0438 \u043f\u0440\u043e\u0446\u0435\u0441\u0441 \u0430\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0447\u0435\u0441\u043a\u043e\u0439 \u0437\u0430\u043c\u0435\u043d\u044b \u0434\u0438\u0441\u043a\u043e\u0432, \u0430 \u0437\u0430\u0442\u0435\u043c, \u043a\u0430\u043a \u0438\u0441\u043a\u043b\u044e\u0447\u0438\u043b\u0438 \u0438\u0437 \u044d\u0442\u043e\u0433\u043e \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0430 \u0430\u0434\u043c\u0438\u043d\u0438\u0441\u0442\u0440\u0430\u0442\u043e\u0440\u0430 \u0438 \u0437\u0430\u043c\u0435\u043d\u0438\u043b\u0438 \u0435\u0433\u043e \u0431\u043e\u0442\u043e\u043c. \u042d\u0442\u0430 \u0441\u0442\u0430\u0442\u044c\u044f \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0441\u0432\u043e\u0435\u0433\u043e \u0440\u043e\u0434\u0430 \u0442\u0440\u0430\u043d\u0441\u043b\u0438\u0442\u0435\u0440\u0430\u0446\u0438\u0435\u0439 \u0432\u044b\u0441\u0442\u0443\u043f\u043b\u0435\u043d\u0438\u044f \u043d\u0430 HighLoad+ 2018 \u041f\u043e\u0441\u0442\u0440\u043e\u0435\u043d\u0438\u0435 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0430 \u043f\u043e \u0437\u0430\u043c\u0435\u043d\u0435 \u0434\u0438\u0441\u043a\u043e\u0432 \u0421\u043d\u0430\u0447\u0430\u043b\u0430 \u043d\u0435\u043c\u043d\u043e\u0433\u043e [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26233,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-34841","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/avtomatizatsiya-zameny-diskov-s-pomoshhyu-ansible\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"pt_PT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0410\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0437\u0430\u0446\u0438\u044f \u0437\u0430\u043c\u0435\u043d\u044b \u0434\u0438\u0441\u043a\u043e\u0432 \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e Ansible | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/avtomatizatsiya-zameny-diskov-s-pomoshhyu-ansible\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:00:43+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:00:43+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Automa\u00e7\u00e3o da substitui\u00e7\u00e3o de discos com Ansible | ProHoster","description":"Ol\u00e1 a todos.","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/avtomatizatsiya-zameny-diskov-s-pomoshhyu-ansible","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0410\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0437\u0430\u0446\u0438\u044f \u0437\u0430\u043c\u0435\u043d\u044b \u0434\u0438\u0441\u043a\u043e\u0432 \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e Ansible | ProHoster","og:description":"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442.","og:url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/avtomatizatsiya-zameny-diskov-s-pomoshhyu-ansible","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:00:43+00:00","article:modified_time":"2019-10-31T19:00:43+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"34841","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 20:48:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:14:05","updated":"2026-01-21 20:48:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/34841","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=34841"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/34841\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/26233"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=34841"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=34841"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=34841"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}