Muitos equipamentos do mesmo tipo
Trinta switches de acesso ou vinte concentradores iguais recebem a mesma mudança várias vezes por ano.
Ansible · Provedores
Inventário, variáveis e playbooks que levam a mesma configuração a todos os roteadores, OLTs e switches, com simulação antes de aplicar.
Automação com Ansible é descrever em arquivos de texto como cada equipamento da rede deve estar e deixar a ferramenta levar essa configuração a dezenas ou centenas de roteadores, OLTs e switches de uma vez. É para o provedor com muitos equipamentos parecidos, que hoje recebem a mesma mudança um por um. O resultado é uma rede que volta ao padrão com um comando, e um histórico de cada alteração.
É usar o Ansible, uma ferramenta de código aberto, para aplicar configuração em muitos equipamentos a partir de arquivos que dizem como cada um deve ficar. Em vez de entrar em cada caixa, a equipe muda o arquivo e roda de novo.
O Ansible não pede programa instalado no equipamento. Ele conecta de um servidor do provedor por SSH, NETCONF ou API, conforme o que cada marca aceita, e usa módulos próprios para cada sistema [CONFIRMAR módulos e versões na documentação].
Na automação de redes, a vantagem dele é a idempotência: rodar o mesmo playbook duas vezes não duplica nada. Se o equipamento já está como o arquivo pede, nada muda; se fugiu do padrão, volta.
Numa migração de rede, os mesmos arquivos geram a configuração do equipamento novo e conferem o antigo. Um projeto Ansible tem quatro partes:
A lista de equipamentos, separada em grupos: por POP, por função (borda, concentrador, OLT) e por marca. Um comando pode mirar só um grupo.
O que muda de um equipamento para outro: IPs, VLANs, nome, servidores de log. Ficam separadas do playbook, que continua o mesmo para todos.
A sequência de tarefas, como criar usuário, ajustar SNMP ou copiar o backup. Roles agrupam tarefas que se repetem e podem ser reaproveitadas em outros playbooks.
Senhas e chaves cifradas com o Ansible Vault ou num cofre externo, nunca em texto puro no repositório [CONFIRMAR na documentação].
Seis situações indicam que o Ansible resolve melhor que digitar equipamento por equipamento. Se a rede tem dezenas de caixas parecidas, a conta já fecha.
Trinta switches de acesso ou vinte concentradores iguais recebem a mesma mudança várias vezes por ano.
Um técnico saiu e a senha de gerência precisa mudar em toda a rede ainda hoje, sem esquecer nenhum equipamento.
Fechar Telnet, limitar o acesso à gerência ou trocar a comunidade SNMP em todos os roteadores de uma vez.
Saber quais equipamentos estão fora do padrão antes de mexer, sem abrir um por um.
A rede cresce e cada POP novo precisa nascer com a mesma configuração dos outros.
Gerar a configuração do aparelho novo a partir das variáveis do antigo, sem copiar linha a linha.
São cinco etapas, e o primeiro playbook só lê a rede. A escrita começa depois que o inventário e a simulação estão conferidos.
Instalação do Ansible num servidor da rede de gerência e montagem do inventário por grupos, com acesso testado em cada equipamento.
Prazo: [PREENCHER]
Primeiro playbook coleta configurações e versões. Mostra que o acesso funciona e revela o que está fora do padrão.
Prazo: [PREENCHER]
Escrita dos playbooks das tarefas combinadas, com variáveis por grupo e senhas no cofre.
Prazo: [PREENCHER]
Execução em modo de simulação, com a diferença mostrada, e depois em lotes pequenos, com backup antes de cada um.
Prazo: [PREENCHER]
Repositório entregue, documentação de cada playbook e sessão prática com a equipe rodando uma mudança real.
Prazo: [PREENCHER]
O serviço cobre o servidor, o inventário, os playbooks combinados e o repasse. O que fica de fora tem página própria, e a lista de playbooks vai escrita na proposta.
O preço depende principalmente do número de marcas na rede e de quantos playbooks serão escritos. O valor exato sai por escrito, depois do levantamento.
| Fator | Como influencia | Exemplo |
|---|---|---|
| Marcas e sistemas | Cada sistema tem módulos e respostas próprios para testar | RouterOS, VRP da Huawei e DmOS da Datacom na mesma rede |
| Número de playbooks | Cada tarefa pede playbook, variáveis e teste | Coleta, troca de senha, SNMP e VLAN somam quatro |
| Tamanho do inventário | Mais equipamentos pedem mais grupos e mais lotes na aplicação | 300 equipamentos em 12 POPs |
| Padrão existente | Sem padrão escrito, ele precisa ser definido antes | Cada concentrador configurado por um técnico |
| Interface gráfica | Painel web para rodar playbooks aumenta a instalação | Equipe que prefere botão a terminal |
Faixa de preço para começar com coleta e dois playbooks de mudança: [PREENCHER faixa aprovada pela Táquion Tech]. O Ansible em si é de código aberto [CONFIRMAR licença na documentação]; plataformas comerciais em volta dele têm preço próprio.
Antes de assinar, confira os erros que mais aparecem em projetos Ansible de rede, as formas de rodar a ferramenta e o que pedir ao fornecedor. A lista serve para avaliar qualquer empresa, inclusive a Táquion Tech.
Falhas que fazem o Ansible ser abandonado depois de poucos meses. Pergunte como o fornecedor evita cada uma.
Mandar linhas de comando cruas, sem conferir o estado antes, perde a idempotência. Rodar duas vezes pode duplicar regra ou apagar o que não devia.
O modo de simulação mostra o que mudaria sem aplicar. Nem todo módulo de rede aceita esse modo, por isso o teste em poucos equipamentos continua obrigatório [CONFIRMAR na documentação].
Equipamento que saiu da rede trava a execução; o que entrou fica sem a mudança. O inventário precisa ser revisado a cada POP novo.
Coleções e módulos mudam de comportamento entre versões. Sem fixar as versões usadas, o playbook que funcionava hoje pode falhar no mês que vem [CONFIRMAR na documentação].
O Ansible pode rodar de três formas. A escolha muda o custo e quem consegue usar.
| Forma | Para quem | Custo de licença |
|---|---|---|
| Linha de comando | Equipe confortável com terminal | Nenhum [CONFIRMAR licença na documentação] |
| Painel web aberto (AWX) | Equipe que prefere botão e histórico na tela | Nenhum, mas pede servidor mais robusto [CONFIRMAR na documentação] |
| Plataforma comercial | Empresa que quer suporte do fabricante | Assinatura anual [CONFIRMAR na documentação] |
Poucas pessoas rodando playbooks e mudanças planejadas em janela.
O registro de quem rodou o quê depende de disciplina e do repositório.
Vários técnicos rodando tarefas prontas, com permissão por pessoa e histórico na tela.
É mais um sistema para atualizar e fazer backup.
As respostas mostram se o projeto foi pensado para a sua equipe continuar sozinha.
Peça a lista por marca e versão de sistema. Onde não há módulo, a tarefa vira envio de comando com conferência manual, e isso precisa estar escrito.
Peça para ver uma execução simulada com a diferença mostrada. Se o fornecedor não mostra, a equipe vai aplicar no escuro.
A resposta certa é cofre cifrado ou gerenciador de senhas. Senha em arquivo de inventário aberto é sinal de alerta.
Com estes itens em mãos, o levantamento é mais curto.
Marca, modelo, versão do sistema e IP de gerência de cada um, mesmo que numa planilha.
Um usuário só para a automação, com acesso a partir do servidor de gerência.
As mudanças que a equipe mais repete, para virarem os primeiros playbooks.
Porque os playbooks são escritos por quem configura essas marcas no dia a dia e ficam legíveis para a sua equipe. Seis compromissos valem para todo projeto Ansible.
Quem escreve o playbook sabe o que a mudança faz no roteador, não só na ferramenta.
[PREENCHER: anos de experiência com Ansible da equipe]
Toda mudança mostra o que vai mudar em cada equipamento antes de ser aplicada.
Simulação registrada antes de cada lote
Primeiro poucos equipamentos, depois grupos maiores. Um erro fica contido no primeiro lote.
Ordem dos lotes escrita na proposta
Inventário, variáveis e playbooks ficam no seu repositório, com histórico e documentação.
Entregue no fim do projeto [CONFIRMAR termos de propriedade no contrato]
A versão aberta resolve a maior parte dos casos. Plataforma comercial só entra se você quiser.
Nenhuma ferramenta indicada por comissão
MikroTik, Huawei, Cisco, Juniper e Datacom no mesmo inventário, cada uma com o módulo certo.
[PREENCHER: marcas já automatizadas pela equipe]
A automação com Ansible é feita à distância para provedores de todo o Brasil. A visita presencial fica para o litoral de Santa Catarina, quando o servidor precisa ser montado no POP.
Servidor instalado por acesso remoto, playbooks testados à distância e repasse por videochamada.
Para montar o servidor no POP ou fazer o repasse com a equipe na mesma sala. [CONFIRMAR área de atendimento]
As dúvidas que mais aparecem quando um provedor pensa em usar Ansible. Se a sua não estiver aqui, pergunte no WhatsApp.
Sim, há coleção de módulos para RouterOS mantida pela comunidade [CONFIRMAR módulos e versões na documentação]. Para tarefas que rodam dentro do roteador, os scripts para MikroTik podem ser mais simples.
Há módulos para várias dessas marcas, com níveis de suporte diferentes [CONFIRMAR na documentação]. O levantamento confere cada marca e versão da sua rede antes da proposta.
Não. O Ansible roda num servidor da rede de gerência e conecta por SSH, NETCONF ou API. Basta liberar o acesso e criar um usuário para a automação.
Depende das marcas, do número de playbooks e do tamanho do inventário. A faixa para começar é [PREENCHER], e o valor exato sai depois do levantamento.
O prazo típico para servidor, inventário e os primeiros playbooks é [PREENCHER]. Rede sem padrão escrito leva mais, porque o padrão vem antes.
Para rodar playbooks prontos, não. Para escrever novos, basta entender arquivos YAML e a lógica de tarefas, o que o repasse cobre no básico.
Ansible para aplicar a mesma configuração em muitos equipamentos; Python para lógica e integração com outros sistemas. Muitos provedores usam os dois, e a automação de rede ajuda a decidir.
Pode, se for aplicado sem simulação em todos os equipamentos de uma vez. Por isso cada mudança passa por simulação, lote pequeno e backup antes.
Ele pode coletar as configurações, mas backup completo inclui retenção, cópia fora do POP e teste de restauração. Isso é o backup de configurações.
A ferramenta de linha de comando é de código aberto [CONFIRMAR licença na documentação]. Paga-se apenas se você escolher uma plataforma comercial com suporte do fabricante.
Três serviços que costumam vir antes ou junto do Ansible. Cada um cobre uma parte que o playbook não resolve sozinho.
O padrão escrito de cada equipamento, que os playbooks passam a aplicar e conferir.
Ver a padronização de configurações
Cópia diária de cada configuração, com histórico e teste de restauração.
Ver o backup de configurações de rede
Scripts e integrações sob medida quando a tarefa pede lógica além dos módulos.
Ver a automação com PythonDois guias para entender a ideia por trás dos playbooks.
Como tratar a configuração da rede como arquivo versionado.
Como medir a rede para saber se a mudança aplicada surtiu efeito.
Orçamento
Diga quantos equipamentos e quais marcas você tem. Um Especialista devolve escopo, prazo e valor por escrito.
Falar com o André Comercial, no WhatsApp