Usar o instalador programável

O Programmable Installer é uma plataforma de automação orientada por especificações para implantar e operar pilhas de software da Cisco, incluindo Network Services Orchestrator (NSO), Crosswork Network Controller (CNC), Crosswork Data Gateway (CDG) e Business Process Automation (BPA), no Linux corporativo (família RHEL) e na infraestrutura associada onde aplicável (VMware vCenter, OpenShift, KVM, Kubernetes com isolamento de ar). O sistema separa a intenção declarativa (especificações YAML e geração de intenção guiada opcional) da execução (funções e manuais de atividades Ansible), com um plano de controle Python que empacota artefatos, verifica pacotes antes de instalações de longa execução, prepara segredos criptografados e orquestra portas de validação.

Este white paper explica as camadas de arquitetura, os fluxos de dados primários, os padrões de implementação (inclusive um modelo híbrido de verificação de artefatos orientados por dados), os modos de implantação (nativo, em contêineres, on-line, com isolamento de ar) e as estruturas de validação e registro. Para organizações de plataforma e fornecimento, a plataforma tem como objetivo reduzir o trabalho manual, a configuração incorreta da superfície e a ausência de binários no início, além de padronizar a automação em produtos e topologias, preservando a parametrização específica do ambiente.

Palavras-chave: automação de infraestrutura, implantação declarativa, Ansible, especificação YAML, embalagem de air-gap, verificação de artefatos, Crosswork, NSO, CNC, CDG, BPA, política de validação, DevOps.

A instalação corporativa de produtos de automação e orquestração de rede de vários níveis é tradicionalmente de alto envolvimento: runbooks longos, muitos passos manuais, desvio de versão entre sites e falhas que trazem horas para dentro de um processo (ausência de NEDs, caminhos OVA errados, conjuntos de imagens de air-gap incompletos). Esse padrão aumenta os custos, alonga as janelas de mudança e torna as auditorias mais difíceis.

O instalador programável trata uma instalação como um programa parametrizado por uma especificação: topologia, versões, escolha de plataforma (vCenter vs OpenShift vs VMs baunilha), caminhos de arquivos e direitos. A automação é idempotente onde for possível, pode ser repetida entre clientes e recebe verificações para que "não está pronto" seja um resultado rápido e explícito antes da instalação do cluster ou do produto.

• Declarativo: os operadores descrevem o que deve ser utilizado; os manuais de atividades implementam como.
• Verificação orientada por dados: os artefatos esperados são derivados de tabelas e regras, em vez de scripts ad-hoc por versão, quando os padrões são estáveis.
• Qualidade por políticas: a validação pré e pós-implantação é executada sob políticas hierárquicas, com relatórios estruturados e integração de tíquetes opcional.
• Operação multimodal: menus interativos para usuários iniciantes; Binários congelados e CLI para repetição do estilo CI/CD; Fluxos baseados em docker para imagens de tempo de execução padronizadas.

1. Especificações intenção expressa; eles podem fazer referência a caminhos e parâmetros não secretos. Segredos devem fluir através dos fluxos de trabalho do Ansible Vault e não campos de especificação de texto simples onde for possível evitá-los.
2. O armazenamento de artefatos deve ser protegido contra a integridade; a verificação concentra-se no alinhamento de presença e nomenclatura com as especificações — amplie com controles organizacionais (checksums, pacotes assinados) onde a política exigir.
3. O SSH do instalador para o destino é um caminho de alto privilégio; o comprometimento do host do instalador é de alto impacto. Fortalecer e controlar o acesso são pré-requisitos operacionais.

1. Primeiro declarativo: Intenção do usuário em YAML; a automação a interpreta de forma consistente.
2. Separação de planejamento e execução: Python planeja, verifica e orquestra portões; O Ansible executa etapas de infraestrutura e produto.
3. Automação combinável: Livros de reprodução em nível de site importam livros de reprodução focados (pré-instalação, faixas do Kubernetes, instalações de produtos).
4. Divulgação progressiva: Configuração interativa para integração; sinalizadores e scripts para automação avançada.
5. Mesma base de código, vários tempos de execução: caminhos nativos AlmaLinux/RHEL e caminhos baseados em Docker compartilham um layout de repositório.
6. Suporte explícito a air-gap: pacote em uma máquina conectada; transferir um pacote; instalar pré-requisitos e implantar sem dependência de tempo de execução em redes públicas.

1. Fluxo do pacote: o pré-requisito de download de ferramentas ou transfere arquivos para um local específico, produzindo opcionalmente um tarball transferível para instalações off-line.
2. Verificar fluxo: o orquestrador analisa a especificação, resolve os artefatos esperados (incluindo filtros de plataforma e listas de direitos) e relata os relatórios prontos/ausentes antes da instalação.
3. Fluxo de implantação: Spec mais vault (e pré-validação opcional) direcionam os manuais de atividades Ansible em relação aos inventários derivados do compromisso.

As especificações são documentos YAML que descrevem plataformas (por exemplo, vCenter, OCP, VM, KVM ), hosts, aplicativos com versões, topologia (por exemplo, layouts NSO CFS/RFS), direitos (NEDs e pacotes complementares) e caminhos de arquivos para OVAs, imagens qcow2 e tarballs da camada de aplicativo.

Um aplicativo específico user_spec fornece padrões e fallbacks de caminho para CNC/CDG. O analisador do orquestrador trata a especificação do usuário como fonte de verdade e usa entradas de especificação comuns quando as chaves do usuário estão ausentes.

O gerador de intenção suporta a coleta guiada de requisitos por meio de um conjunto de questionários, um mecanismo de regras (lógica orientada por data) e mapeamento apoiado por esquema para intent.yaml. 

O orquestrador é a única entrada para a coordenação de script ou de geração de intenção interativa, verificação de pacote e instalação. Seu design é explicitamente híbrido:

• ARTIFACT_DEFS: Declara tipos de artefatos e padrões de nomenclatura por aplicativo (instalador NSO, pacotes assinados NED, pacotes opcionais; Alcatrões CNC OVA/qcow2/tier; Imagens CDG; gráficos BPA e tarballs para imagens de air-gap).
• APP_CONFIG: Mapeia valores CLI — app (nso, crossworksuite, bpa) para nomes de pastas de especificação e nomes de arquivos de intenção padrão.
• Analisador / Manipuladores: Resolva caminhos CNC/CDG usando especificação do usuário e especificação comum; manipuladores personalizados cobrem nomeação não uniforme (por exemplo, TSDN/DLM) e formatação de versão BPA para caminhos de gráfico e tarball.

Preparação:AReportaggregates discovered artifacts; is_readyis true quando nenhum arquivo necessário está faltando após a análise das especificações. O módulo oferece suporte a binários congelados do PyInstaller via resolução de caminho sys.locked.

Este componente fornece menus interativos e modos CLI para empacotamento de artefatos e instalação de pré-requisitos de host: on-line, air-gap ou detecção automática; embalagem multiaplicação, incluindo combineCNC_NSO. Ele preenche a árvore de artefatos esperada pelo Ansible e pela lógica verify-bundle.

• Composição: Isso ilustra a natureza de várias trilhas da pilha: importa diferentes caminhos de bootstrap do Kubernetes — refletindo que diferentes produtos têm como alvo diferentes caminhos de bootstrap do Kubernetes.
• Funções (famílias representativas): pré-instalação (SELinux, firewall, SSH, auxiliares de registro), k8s_install / rke2, deploy_nso, deploy_cnc, deploy_cdg, deploy_bpa, postinstall, uninstall e auxiliares de renovação de certificado. A propriedade e os testes são mais bem gerenciados nos limites de função; pastas de tarefas aninhadas implementam subfluxos de trabalho (por exemplo, HA NSO L3).

A estrutura oferece controle de política hierárquico (aplicativo de → global → etapa → verificação individual), descoberta automática de cheques, relatórios aprimorados para logs estruturados e integração JIRA opcional. Os operadores executam fases de pré ou pós-implantação com base na mesma especificação usada para a instalação, alinhando a automação com portões de qualidade adequados para a disciplina de alteração da empresa.

Escala indicativa em uma filial típica: na ordem de trinta verificações no BPA e no NSO (contagens a serem confirmadas comfazer verificações de validação de lista no seu check-out).

Deriva as variáveis de cofre necessárias de especificações, solicita ou aceita senhas sob política e emite group_vars/all_secrets.yaml criptografado mais um arquivo de senha de cofre para Ansible, reduzindo a incorporação de segredos ad-hoc nos manuais de atividades.

• Segredos:Preferem variáveis de grupo criptografadas do Ansible Vault; use os modos restritos do gerenciador de cofre, quando apropriado.
• Host do instalador:Tratar como um plano de controle de alta confiança; restringir o acesso e monitorar.
• Artefatos:Proteger canais de aquisição; os processos organizacionais podem aumentar o verify-bundle com verificação criptográfica.
• Registro em log:Logs de aplicativo e Ansible subimplantados/logs/ 

Exemplo de chamada pré-implantação:

cd /opt/cx-installer
python3 validation_checks/run_validation_checks.py -t pre -s specification/your_spec.yaml

 Este é um modelo de aprovisionamento interno onde, para mais instalação de aplicativos da CISCO, o mesmo princípio pode ser seguido pela bifurcação do repositório. 

As métricas quantitativas (duração da instalação, taxas de defeito) são específicas da organização; as equipes devem basear-se em runbooks legados em topologias comparáveis.

1. ExtendARTIFACT_DEFS (e rótulos, se necessário) incx_deploy_orchestrator.py.
2. Adicionar manipulador personalizado quando a nomeação não pode ser capturada apenas por padrões.
3. Atualize a lógica de empacotamento insetup_cxinstaller_prereqsquando os downloads forem automatizados.

Preferem novas tarefas dentro de funções coesas; introduza novas funções quando os limites estiverem claros. Livros de reprodução com fios viaimport_playbook ou livros de jogos de entrada documentados. Mantenha padrões seguros em group_vars / vars.

Atualizar os esquemas YAML nas entradas underintent-generate/schema/ e chatbot; verifique se os arquivos gerados correspondem aos nomes de arquivo esperados por APP_CONFIG.

• SBOM mais profunda ou integração de verificação de assinatura de imagem.
• Cobertura de validação expandida para cenários CNC/CDG.
• Referências de CI para linhas de especificações e verificações de sintaxe Ansible.

O CX Programmable Installer combina especificações declarativas, um plano de controle Python para empacotamento e verificação e um plano de automação Ansible para implantações escaláveis e repetíveis de produtos relacionados ao Crosswork em diversos modelos de infraestrutura e conectividade. Sua arquitetura intencionalmente separa a intenção da execução, aplica as expectativas de artefatos orientados por dados onde for prático e incorpora fluxos de trabalho de validação e compartimento adequados para entrega corporativa. Para obter os anexos operacionais completos (tabelas do manual de atividades, matrizes de solução de problemas, matrizes de conectividade e referências de comandos estendidos), consulte o white paper interno complementar.

cx-installer/
├── ansible_playbooks/     # ansible.cfg, files/, group_vars/, playbooks/, roles/, vars/
├── apps/                  # App-specific supporting content
├── deploy/                # Python deploy helpers, logging utilities
├── docs/                  # Technical documentation
├── intent-generator/      # Chatbot, rule engine, schemas, output/
├── scripts/               # Docker setup/start, vault_secrets_manager.py, ...
├── specification/         # User specs, samples, common fragments
├── validation_checks/     # Policies, runners, reports
├── cx_deploy_orchestrator.py
├── setup_cxinstaller_prereqs*
├── requirements.txt
└── README.md

Pontos focais de artefato pós-configuração (típico):ansible_playbooks/files/artifacts/, files/bin/, files/charts/, files/images/.

Script:cx_deploy_orchestrator.py

Ambiente (sessão típica):

export PYTHONPATH=$(pwd)
export ANSIBLE_CONFIG=$(pwd)/ansible_playbooks/ansible.cfg