Utilizzare il programma di installazione programmabile

Il Programmable Installer è una piattaforma di automazione guidata da specifiche per l'installazione e il funzionamento di stack di software Cisco, tra cui Network Services Orchestrator (NSO), Crosswork Network Controller (CNC), Crosswork Data Gateway (CDG) e Business Process Automation (BPA), su Enterprise Linux (famiglia RHEL) e sulle relative infrastrutture, ove applicabile (VMware vCenter, OpenShift, KVM, Kubernetes con aperture d'aria). Il sistema separa l'intento dichiarativo (specifiche YAML e generazione guidata opzionale) dall'esecuzione (ruoli Ansible e playbook), con un control plane Python che raccoglie gli artefatti, verifica i bundle prima di installazioni di lunga durata, prepara segreti criptati e organizza i gate di convalida.

Questo white paper spiega i livelli dell'architettura, i flussi di dati primari, i modelli di implementazione (incluso un modello di verifica degli artefatti basato su dati ibridi), le modalità di distribuzione (native, containerizzate, online, air-gapped) e i framework di convalida e registrazione. Per le organizzazioni di distribuzione e piattaforme, la piattaforma mira a ridurre gli sforzi manuali, la configurazione errata delle superfici e la mancanza di binari in anticipo, nonché a standardizzare l'automazione tra prodotti e topologie, preservando al contempo la parametrizzazione specifica dell'ambiente.

Parole chiave: automazione dell'infrastruttura, distribuzione dichiarativa, Ansible, specifica YAML, imballaggio air-gap, verifica degli artefatti, Crosswork, NSO, CNC, CDG, BPA, politica di convalida, DevOps.

L'installazione aziendale dei prodotti di orchestrazione e automazione della rete multi-tier è in genere un'operazione estremamente complessa: runbook lunghi, molti passaggi manuali, incertezze di versione tra i siti e guasti che superano le ore in un processo (terminazioni mancanti, percorsi degli OAV errati, set di immagini di air-gap incompleti). Questo modello aumenta i costi, allunga le finestre di modifica e rende più difficili le verifiche.

Il programma di installazione programmabile considera un'installazione come un programma con parametri in base a una specifica: topologia, versioni, scelta della piattaforma (vCenter vs OpenShift vs VM vanilla), percorsi di file e autorizzazioni. Ove possibile, l'automazione è idempotente, ripetibile tra i clienti e precaricata con controlli in modo che "non pronta" sia un risultato rapido ed esplicito prima dell'installazione del cluster o del prodotto.

• dichiarativo: gli operatori descrivono ciò che deve essere distribuito; i playbook implementano come.
• Verifica basata su dati: gli artifact previsti derivano da tabelle e regole anziché da script ad hoc per versione, quando i pattern sono stabili.
• Qualità basata su criteri: la convalida pre e post-distribuzione viene eseguita in base a criteri gerarchici, con report strutturati e integrazione opzionale di ticketing.
• Funzionamento multimodale: menu interattivi per i nuovi utenti; CLI e binari bloccati per la ripetizione di CI/CD; Flussi basati su Docker per immagini di runtime standardizzate.

1. le specifiche hanno un intento esplicito; possono fare riferimento a percorsi e parametri non segreti. I segreti devono passare attraverso i flussi di lavoro di Ansible Vault, non campi di specifiche in testo normale dove evitabile.
2. La conservazione degli artefatti deve essere protetta dall'integrità; la verifica è incentrata sulla presenza e sull'allineamento dei nomi con la specifica, estendendosi ai controlli organizzativi (checksum, bundle firmati) laddove richiesto dalla policy.
3. Il protocollo SSH da installatore a destinazione è un percorso con privilegi elevati; la compromissione dell'host del programma di installazione ha un impatto notevole. La protezione avanzata e il controllo degli accessi sono prerequisiti operativi.

1. Prima dichiarazione: intento dell'utente in YAML; l'automazione lo interpreta in modo coerente.
2. Separazione della pianificazione e dell'esecuzione: Python pianifica, verifica e organizza le porte; Ansible esegue fasi di infrastruttura e prodotto.
3. Automazione componibile: i playbook a livello di sito importano playbook mirati (preinstallazione, tracce Kubernetes, installazioni di prodotti).
4. Divulgazione progressiva: configurazione interattiva per l'onboarding; flag e script per l'automazione avanzata.
5. Stessa codebase, più runtime: i percorsi AlmaLinux/RHEL nativi e i percorsi basati su Docker condividono un layout repository.
6. Supporto esplicito di air-gap: pacchetto su una macchina collegata; trasferire un fascio; installare i prerequisiti e distribuire senza dipendenza di runtime dalle reti pubbliche.

1. Flusso di package: il prerequisito per l'utilizzo degli utensili consente di scaricare o posizionare i file in una posizione specifica, producendo facoltativamente una pallina da terra trasferibile per le installazioni offline.
2. Verifica del flusso: Orchestrator analizza la specifica, risolve gli elementi previsti (inclusi i filtri della piattaforma e gli elenchi dei diritti) e segnala gli elementi pronti o mancanti prima dell'installazione.
3. Flusso di distribuzione: Spec plus vault (e pre-convalida opzionale) per l'unità Ansible playbooks a fronte di inventari derivati dall'impegno.

Le specifiche sono documenti YAML che descrivono le piattaforme (ad esempio vCenter, OCP, VM, KVM ), gli host, le applicazioni con versioni, la topologia (ad esempio i layout NSO CFS/RFS), i diritti (NED e pacchetti aggiuntivi) e i percorsi di file per gli OAV, le immagini qws2 e le matrici di livello applicazione.

Un'applicazione specifica user_spec fornisce valori predefiniti e fallback di percorso per CNC/CDG. Il parser dell'orchestrator tratta la specifica dell'utente come fonte di verità e utilizza le voci delle specifiche comuni quando le chiavi utente sono assenti.

Il generatore di intento supporta la raccolta guidata dei requisiti tramite un insieme di questionari, un motore delle regole (la logica basata sulla data) e il mapping basato su schema a intent.yaml. 

L'orchestrator è la singola voce per la generazione di intenti interattivi, la verifica del bundle e la coordinazione dell'installazione. Il suo design è esplicitamente ibrido:

• ARTIFACT_DEFS: dichiara tipi di artifact e modelli di denominazione per applicazione (programma di installazione NSO, pacchetti firmati END, pacchetti facoltativi; CNC OVULI/qvacs2/palle di articolazione; immagini CDG; Grafici BPA e tarball immagine air-gap).
• APP_CONFIG: esegue il mapping dei valori CLI —app (nso, crossworksuite, bpa) ai nomi di cartella di specifica e ai nomi di file intento predefiniti.
• Parser/Handler: consente di risolvere i percorsi CNC/CDG utilizzando le specifiche utente e le specifiche comuni. I gestori personalizzati coprono la denominazione non uniforme (ad esempio, TSDN/DLM) e la formattazione della versione BPA per i percorsi dei grafici e dei traiettori.

Preparazione:AReportaggregates ha individuato elementi; is_readyis true quando non mancano file necessari dopo l'analisi delle specifiche. Il modulo supporta i file binari bloccati da PyInstaller tramite la risoluzione dei percorsi sys.froed.

Questo componente fornisce menu interattivi e modalità CLI per il packaging degli artifact e l'installazione dei prerequisiti dell'host: online, air-gap o auto-detect; packaging di più applicazioni, incluso CombinedCNC_NSO. Popola l'albero degli artefatti previsto dalla logica Ansible e verify-bundle.

• Composizione: illustra la natura a più tracce dello stack: importa diversi percorsi di bootstrap Kubernetes, riflettendo il fatto che prodotti diversi sono destinati a percorsi di bootstrap Kubernetes diversi.
• Ruoli (famiglie rappresentative): helper di preinstallazione (SELinux, firewall, SSH, registro di sistema), k8s_install / rke2, deploy_nso, deploy_cnc, deploy_cdg, deploy_bpa, postinstall, uninstall e rinnovo del certificato. La proprietà e il collaudo sono gestiti al meglio in funzione dei limiti dei ruoli; le cartelle di attività nidificate implementano flussi di lavoro secondari (ad esempio NSO L3 HA).

La struttura fornisce il controllo gerarchico delle policy (globale → app → stage → single check), l'auto-discovery dei controlli, la creazione di report avanzati per i log strutturati e l'integrazione opzionale di JIRA. Gli operatori eseguono le fasi di pre o post-distribuzione sulla base della stessa specifica utilizzata per l'installazione, allineando l'automazione con i gate di qualità adatti al cambiamento della disciplina aziendale.

Scala indicativa su un ramo tipico: nell'ordine di trenta controlli tra BPA e NSO (conteggi da confermare con creazione elenco-convalida-controlli all'estrazione).

Deriva le variabili di archivio richieste dalle specifiche, richiede o accetta le password in base ai criteri ed emette un file di password di archivio crittografato group_vars/all_secrets.yaml più un file di password di archivio per Ansible, riducendo l'incorporamento di segreti ad hoc nei playbook.

• Secrets:Preferire le variabili di gruppo crittografate di Ansible Vault; utilizzare le modalità rigorose di vault manager, se necessario.
• Host installatore:da trattare come un control plane ad alta affidabilità; limitare l'accesso e il monitoraggio.
• Artifact:Proteggi canali di acquisizione; i processi organizzativi possono aumentare verify-bundle con la verifica crittografica.
• Registrazione:log delle applicazioni e analizzabili sottodistribuzione/log/ 

Esempio di chiamata pre-distribuzione:

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

 Si tratta di un modello per l'origine interna in cui per un numero maggiore di applicazioni CISCO è possibile seguire lo stesso principio biforcando il repository. 

Le metriche quantitative (durata dell'installazione, percentuali di difetti) sono specifiche dell'organizzazione; i team devono basarsi su runbook legacy su topologie confrontabili.

1. ExtendARTIFACT_DEFS(e le etichette se necessarie) incx_deploy_orchestrator.py.
2. Aggiungere un gestore personalizzato quando la denominazione non può essere acquisita dai soli modelli.
3. Aggiornare la logica di creazione pacchetti installetup_cxinstaller_prereqsquando i download sono automatizzati.

Preferire nuovi compiti all'interno di ruoli coesivi; introdurre nuovi ruoli quando i limiti sono chiari. Playbook su filo viaimport_playbook o playbook in entrata documentati. Mantenete le impostazioni di default sicure in group_vars / vars.

Aggiornare gli schemi YAML sottointent-generator/schema/ e gli input chatbot; assicurarsi che i file generati corrispondano ai nomi file previsti da APP_CONFIG.

• Integrazione più approfondita della verifica della firma dell'immagine o della distinta base.
• Ampliamento della copertura di convalida per gli scenari CNC/CDG.
• Riferimenti CI per il plinting delle specifiche e i controlli della sintassi Ansible.

Il programma di installazione programmabile CX combina specifiche dichiarative, un control plane Python per il packaging e la verifica e un piano di automazione Ansible per installazioni scalabili e ripetibili di prodotti correlati a Crosswork su infrastrutture e modelli di connettività diversi. La sua architettura separa intenzionalmente l'intento dall'esecuzione, applica le aspettative degli artifact basati sui dati, ove fattibile, e incorpora i flussi di lavoro di convalida e vaulting adatti alla distribuzione aziendale. Per gli allegati operativi completi (tabelle di playbook, matrici per la risoluzione dei problemi, matrici di connettività e riferimenti a comandi estesi), consultare il white paper interno.

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

Punti focali artefatto post-installazione (tipici):playbooks_andibili/file/artefatti/, file/bin/, file/grafici/, file/immagini/.

Script:cx_deploy_orchestrator.py

Ambiente (sessione tipica):

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