Os nós de contêiner no Cisco Modeling Labs (CML) 2.9 complementam as máquinas virtuais, oferecendo maior flexibilidade e eficiência. Os engenheiros se beneficiam de opções leves, programáveis e de implantação rápida em seus ambientes de simulação. Embora as máquinas virtuais (VMs) dominem os sistemas operacionais de rede, os contêineres adicionam flexibilidade, permitindo que ferramentas, injetores de tráfego, automação e aplicativos completos funcionem perfeitamente com sua topologia CML. As máquinas virtuais tradicionais ainda são eficazes, mas os contêineres personalizados apresentam uma agilidade transformadora.
Construir imagens que se comportem de maneira previsível e se integrem perfeitamente às redes simuladas é muito mais fácil com contêineres. Como qualquer pessoa que tentou inserir uma imagem padrão do Docker no CML descobre rapidamente, esse não é um processo simples. As imagens típicas do Docker não possuem os metadados compatíveis com CML, comportamentos de interface de rede e propriedades de ciclo de vida necessários. Usar contêineres com CML é o elemento que falta.
Esta postagem do weblog fornece um passo a passo prático e de engenharia para a construção de contêineres que estão realmente prontos para CML.
Nota sobre melhorias no CML: Quando os contêineres foram introduzidos, apenas uma imagem por definição de nó period permitida. Com a versão CML 2.10, esta restrição foi suspensa. Em explicit, serão adicionadas as seguintes melhorias:
- Por imagem definição, Docker marcação nomes como:
debian:bookworm, debian:buster and debian:trixie
Todas as tags são válidas para as mesmas definições de nó “debian-docker”—três definições de imagem válidas para uma definição de nó.
- Especificação de tags Docker como alternativa aos nomes de imagens (arquivos .tar.gz) e SHA256 possui somas. Nesse caso, o CML tentará baixar a imagem de um registro de contêiner, por exemplo, Docker Hub, se não for especificado de outra forma.
- Lógica de lançamento aprimorada para evitar “lançamentos perpétuos” caso a soma SHA256 da definição da imagem não corresponda à soma do hash actual na imagem.
Por que os contêineres personalizados no CML são importantes?
Os fluxos de trabalho CML tradicionais dependem de nós baseados em VM que executam IOSv, IOS-XRv, NX-OS, Ubuntu, Alpine e outros sistemas operacionais. Eles são excelentes para modelar o comportamento do sistema operacional de rede, mas são pesados para tarefas como integração de ferramentas CLI, navegadores da Internet, controladores efêmeros, aplicativos em contêineres, microsserviços e equipamentos de teste em suas simulações.
Os contêineres iniciam rapidamente, consomem menos recursos e integram-se perfeitamente aos fluxos de trabalho padrão de CI/CD do NetDevOps. Apesar de suas vantagens, a integração de imagens Docker padrão em CML apresenta seus desafios, cada um dos quais requer uma solução personalizada para funcionalidade perfeita.
Os desafios ocultos: por que uma imagem Docker não é suficiente
CML não executa contêineres da mesma forma que um Docker Engine básico. Em vez disso, ele agrupa contêineres em um ambiente de tempo de execução especializado que se integra ao seu mecanismo de simulação. Isso leva a várias armadilhas potenciais:
- Pontos de entrada e sistemas de inicialização
Muitas imagens básicas assumem que são as apenas processo em execução. Na CML, interfaces de rede, scripts de inicialização e preparação para inicialização devem ser fornecidos. Além disso, a CML espera um processo em primeiro plano de longa duração. Se o seu contêiner sair imediatamente, o CML tratará o nó como “com falha”. - Mapeamento de interface
Os contêineres geralmente usam eth0, mas o CML anexa interfaces sequencialmente com base na topologia (eth0, eth1, eth2…). Sua imagem deve lidar com interfaces adicionais adicionadas na inicialização, mapeando-as para configurações específicas do sistema operacional. - Capacidades e usuários
Alguns contêineres eliminam privilégios por padrão. O processo de inicialização do CML pode precisar de privilégios de acesso específicos para configurar a rede ou iniciar daemons. - Structure do sistema de arquivos
CML usa ativos de bootstrap opcionais injetados no sistema de arquivos do contêiner. Uma imagem Docker padrão não terá os diretórios, binários ou permissões corretos para isso. Se necessário, o CML pode “injetar” um conjunto completo de binários de linha de comando (“busybox”) em um contêiner para fornecer um ambiente CLI adequado. - Expectativas do ciclo de vida
Os contêineres devem enviar informações de log para o console para que a funcionalidade possa ser observada no CML. Por exemplo, um servidor internet deve mostrar o log de acesso.
Desalinhando qualquer um deles, você gastará horas solucionando problemas no que parece ser um cenário simples de “funciona com execução”.
Como a CML trata os contêineres: um modelo psychological para engenheiros
Os recursos de contêiner do CML giram em torno de um arquivo YAML de definição de nó que descreve:
- A imagem a ser carregada ou extraída
- O processo de inicialização
- Variáveis de ambiente
- Interfaces e como elas se ligam
- Comportamento de simulação (ordem de inicialização, CPU/memória, registro)
- Metadados da IU
Quando um laboratório é lançado, o CML:
- Implanta um nó de contêiner
- Extrai ou carrega a imagem do contêiner
- Aplica definições de rede
- Injeta metadados, endereço IP e scripts de inicialização
- Monitora a integridade do nó por meio de logs e estado do tempo de execução
Pense em CML como “Docker com restrições mais injeção de rede”. Compreender a abordagem do CML para contêineres é elementary, mas construí-los requer detalhes específicos. Aqui estão algumas dicas práticas para garantir que seus contêineres estejam prontos para CML.
Dicas para construir um contêiner pronto para CML
As imagens de contêiner criadas para CML 2.10 e posteriores são criadas no GitHub. Usamos um fluxo de trabalho GitHub Motion CI para automatizar totalmente o processo de construção. Na verdade, você pode usar o mesmo fluxo de trabalho para criar suas próprias imagens personalizadas, prontas para serem implantadas em CML. Há muita documentação e exemplos que você pode usar, fornecidos no repositório* e no Deep Wiki.**
Nota importante: O CML trata cada nó em uma topologia como um serviço ou aplicativo único e independente. Embora possa ser tentador implantar diretamente aplicativos de vários contêineres, geralmente definidos usando docker-compose , no CML, tentando dividi-los em nós CML individuais, essa abordagem geralmente não é recomendada e pode levar a complicações significativas.
1.) Escolha a base certa
Comece com uma definição de contêiner já existente, como:
- nginx (daemon de rede de propósito único usando uma imagem upstream vanilla).
- Firefox (interface gráfica do usuário, processo de construção personalizado).
- Ou uma base personalizada construída por CI com sua estrutura de automação padrão.
Evite usar imagens que dependam do SystemD, a menos que você o configure explicitamente; SystemD dentro de contêineres pode ser complicado.
2.) Defina um ponto de entrada adequado
Seu contêiner deve:
- Execute um processo de longa duração.
- Não daemonizar em segundo plano.
- Suporta registro previsível.
- Mantenha o contêiner “vivo” para LMC.
Aqui está um script de supervisor simples:
#!bin/sh echo "Container beginning..." tail -f /dev/null
Não é glamoroso, mas eficaz. Você pode substituir tail -f /dev/null pela sua cadeia de inicialização de serviço.
3.) Put together-se para múltiplas interfaces
CML pode anexar diversas interfaces à sua topologia. O CML executará um processo DHCP na primeira interface, mas a menos que a primeira interface seja adjacente a L2 a um conector externo no modo NAT, NÃO há garantia de que ele adquirirá um! Se não for possível adquirir um endereço IP, é responsabilidade do administrador do laboratório fornecer a configuração do endereço IP de acordo com a configuração do dia 0. Normalmente, comandos ip config… podem ser usados para essa finalidade.
Casos de uso avançados que você pode desbloquear
Depois de conquistar contêineres personalizados, o CML se torna dramaticamente mais flexível. Alguns casos de uso populares entre equipes avançadas de NetDevOps e SRE incluem:
Tráfego sintético e testes
Motores de automação
- Nós Nornir
- Contêineres de equipamento de teste pyATS/Genie
- Controladores de automação Ansible
Aplicativos distribuídos
- Experimentos básicos de malha de serviço
- Gateways e proxies de API
- Middleboxes baseadas em contêiner
Ferramentas de segurança
- Pote de mel
- Componentes IDS/IPS
- Estruturas de inspeção de pacotes
Trate o CML como um “laboratório completo”, aprimorando seus recursos além de um mero simulador de rede.
Faça do CML seu próprio laboratório
A criação de contêineres personalizados para CML transforma a plataforma de uma ferramenta de simulação em um ambiente de teste completo e programável. Esteja você validando fluxos de trabalho de automação, modelando sistemas distribuídos, prototipando funções de rede ou simplesmente construindo utilitários leves, os nós conteinerizados permitem que você adapte o CML às suas necessidades de engenharia, e não o contrário.
Se você estiver pronto para ampliar seu laboratório CML, a melhor maneira de começar é simples: crie um pequeno contêiner, copie e modifique uma definição de nó existente e coloque-a em uma topologia de dois nós. Depois de ver como ele funciona perfeitamente, você perceberá rapidamente até onde pode levar esse recurso.
Você gostaria de criar seu próprio contêiner personalizado para CML? Deixe-nos saber nos comentários!
* Repositório Github – Automação para construção de contêineres CML Docker
** DeepWiki – Contêineres Docker CML (CML 2.9+)
Inscreva-se para Cisco U. | Junte-se aoRede de aprendizagem Cisco hoje de graça.
Siga Aprenda com a Cisco
X|Tópicos| Fb|LinkedIn|Instagram|YouTube
Usar #CiscoU e#CiscoCertpara participar da conversa.