Gebruik het programmeerbare installatieprogramma

Het programmeerbare installatieprogramma is een specifiek automatiseringsplatform voor de implementatie en exploitatie van Cisco-softwarestacks, waaronder Network Services Orchestrator (NSO), Crosswork Network Controller (CNC), Crosswork Data Gateway (CDG) en Business Process Automation (BPA), op Enterprise Linux (RHEL-familie) en bijbehorende infrastructuur waar van toepassing (VMware vCenter, OpenShift, KVM, air-gapped Kubernetes). Het systeem scheidt declaratieve intentie (YAML-specificaties en optionele geleide intentiegeneratie) van uitvoering (Ansible-rollen en playbooks), met een Python-besturingsvlak dat artefacten verpakt, bundels verifieert voordat langlopende installaties worden geïnstalleerd, gecodeerde geheimen voorbereidt en validatiepoorten orkestreert.

In deze whitepaper worden de architectuurlagen, primaire gegevensstromen, implementatiepatronen (waaronder een hybride, gegevensgestuurd verificatiemodel voor artefacten), implementatiemodi (native, gecontaineriseerd, online, air-gapped) en de kaders voor validatie en registratie toegelicht. Voor leverings- en platformorganisaties heeft het platform als doel handmatige arbeid, verkeerde configuratie van oppervlakken en ontbrekende binaries vroegtijdig te verminderen en automatisering voor verschillende producten en topologieën te standaardiseren met behoud van omgevingsspecifieke parameterisatie.

Trefwoorden: infrastructuurautomatisering, declaratieve implementatie, Ansible, YAML-specificatie, air-gap-verpakking, artefactverificatie, kruiswerk, NSO, CNC, CDG, BPA, validatiebeleid, DevOps.

De bedrijfsinstallatie van multi-tier netwerkautomatiserings- en orkestratieproducten is van oudsher high-touch: lange runbooks, veel handmatige stappen, versiescheefheid tussen sites en fouten die uren in een proces opduiken (ontbrekende NED's, verkeerde OVA-paden, onvolledige air-gap-beeldsets). Dat patroon verhoogt de kosten, verlengt wijzigingsvensters en maakt audits moeilijker.

De programmeerbare installateur behandelt een installatie als een programma dat wordt geparametriseerd door een specificatie: topologie, versies, platformkeuze (vCenter vs OpenShift vs vanilla VM's), bestandspaden en rechten. Automatisering is idempotent waar mogelijk, herhaalbaar voor alle klanten en vooraf geladen met controles, zodat 'niet klaar' een snel, expliciet resultaat is voordat cluster of product wordt geïnstalleerd.

• Declaratief: operators beschrijven wat moet worden geïmplementeerd; playbooks implementeren hoe.
• Gegevensgestuurde verificatie: verwachte artefacten zijn afgeleid van tabellen en regels in plaats van ad-hocscripts per release, wanneer patronen stabiel zijn.
• Kwaliteit op basis van beleidsregels: validatie vóór en na implementatie verloopt volgens hiërarchisch beleid, met gestructureerde rapporten en optionele ticketintegratie.
• Multimodale werking: interactieve menu's voor nieuwe gebruikers; CLI en bevroren binaries voor herhalingen in CI/CD-stijl; Docker-gebaseerde flows voor gestandaardiseerde runtime-images.

1. Specificaties drukken intentie uit; ze kunnen verwijzen naar paden en niet-geheime parameters. Geheimen moeten door Ansible Vault-werkstromen stromen stromen en niet door tekstvelden waar vermijdbaar.
2. Artefact-opslag moet worden beschermd tegen integriteit; verificatie richt zich op aanwezigheid en naamgeving in overeenstemming met de specificatie - uitbreiden met organisatorische controles (cheques, ondertekende bundels) waar beleid vereist.
3. Installer-to-target SSH is een pad met hoge bevoegdheden; het compromitteren van de installatiehost heeft een grote impact. Verharding en toegangscontrole zijn operationele voorwaarden.

1. Declaratief eerst: Gebruikersintentie in YAML; automatisering interpreteert het consistent.
2. Scheiding van planning en uitvoering: Python plant, verifieert en orkestreert poorten; Ansible voert infrastructuur- en productstappen uit.
3. Composeerbare automatisering: playbooks op siteniveau importeren gerichte playbooks (vooraf installeren, Kubernetes-tracks, productinstallaties).
4. Progressieve openbaarmaking: interactieve installatie voor onboarding; vlaggen en scripts voor geavanceerde automatisering.
5. Dezelfde codebase, meerdere runtimes: Native AlmaLinux/RHEL-paden en op Docker gebaseerde paden delen één repository-lay-out.
6. Expliciete air-gap-ondersteuning: pakket op een verbonden machine; een bundel overdragen; vereisten installeren en implementeren zonder runtime-afhankelijkheid van openbare netwerken.

1. Pakketstroom: De vereiste tooling downloadt of brengt bestanden in een specifieke locatie, waarbij optioneel een overdraagbare tarball wordt geproduceerd voor offline installaties.
2. Stroom verifiëren: De orchestrator parseert de specificaties, lost verwachte artefacten op (inclusief platformfilters en rechtenlijsten) en rapporteert klaar / ontbrekend voordat de installatie wordt uitgevoerd.
3. Implementatiestroom: Spec plus vault (en optionele pre-validatiedrive) Ansible-playbooks tegen inventarissen die zijn afgeleid van de service.

Specificaties zijn YAML-documenten die platforms beschrijven (bijvoorbeeld vCenter, OCP, VM, KVM ), hosts, toepassingen met versies, topologie (bijvoorbeeld NSO CFS/RFS-lay-outs), rechten (NED's en add-on-pakketten) en bestandspaden voor OVA's, qcow2-afbeeldingen en tarballs op toepassingsniveau.

Een specifieke user_spec-toepassing levert standaardwaarden en padterugvalmogelijkheden voor CNC/CDG. De parser van de orchestrator behandelt de gebruikersspecificatie als bron van waarheid en gebruikt gemeenschappelijke spec-vermeldingen wanneer gebruikerstoetsen afwezig zijn.

De intentiegenerator ondersteunt het gericht verzamelen van vereisten via een set vragenlijsten, een regelengine (datumgestuurde logica), en schema-backed mapping naar intent.yaml. 

De orchestrator is de enige ingang voor scripted of interactieve genereren-intentie, verifiëren-bundel, en de coördinatie te installeren. Het ontwerp is expliciet hybride:

• ARTIFACT_DEFS: declareert artefacttypen en naamgevingspatronen per toepassing (NSO-installatieprogramma, NED-ondertekende pakketten, optionele pakketten; CNC OVA/qcow2/tier tarballs; CDG-afbeeldingen; BPA-diagrammen en air-gap-beeldtarballs).
• APP_CONFIG: Kaarten - CLI-app-waarden (nso, crossworksuite, bpa) aan specificatiemapnamen en standaardintentiebestandsnamen.
• Parser / Handlers: CNC / CDG-paden oplossen met behulp van gebruikersspecificaties en gemeenschappelijke specificaties; aangepaste handlers dekken niet-uniforme naamgeving (bijvoorbeeld TSDN / DLM) en BPA-versieformattering voor grafiek- en tarballepaden.

Gereedheid: AReportaaggregeert ontdekte artefacten; is_ready is true wanneer er geen vereiste bestanden ontbreken na het parseren van de specificaties. De module ondersteunt door PyInstaller bevroren binaries via sys.frozen path resolution.

Deze component biedt interactieve menu's en CLI-modi voor artefactverpakking en installatie van hostvereisten: online, air-gap of automatisch detecteren; verpakking voor meerdere toepassingen inclusief gecombineerde CNC_NSO. Het bevolkt de artefactboom die door Ansible wordt verwacht en door verificatie-bundellogica.

• Samenstelling: Dit illustreert het multi-track karakter van de stack: het importeert verschillende Kubernetes bootstrap paden – wat aangeeft dat verschillende producten zich richten op verschillende Kubernetes bootstrap paden.
• Rollen (representatieve families): voorinstallatie (SELinux, firewall, SSH, registerhelpers), k8s_install / rke2, deploy_nso, deploy_cnc, deploy_cdg, deploy_bpa, postinstall, verwijderen en helpers voor certificaatvernieuwing. Eigendom en testen kunnen het best worden beheerd op rolgrenzen; geneste taakmappen implementeren subworkflows (bijvoorbeeld NSO L3 HA).

Het framework biedt hiërarchische beleidscontrole (globale → app → fase → individuele controle), automatische detectie van controles, verbeterde rapportage aan gestructureerde logs en optionele JIRA-integratie. Exploitanten voeren pre- of post-implementatiefasen uit met dezelfde specificatie die wordt gebruikt voor installatie, waarbij automatisering wordt afgestemd op kwaliteitspoorten die geschikt zijn voor bedrijfsveranderingsdiscipline.

Indicatieve schaal op een typische tak: in de orde van dertig controles over BPA en NSO (tellingen worden bevestigd met make-list-validatie-controles bij uw kassa).

Hiermee worden de vereiste vaultvariabelen afgeleid van specificaties, worden wachtwoorden gevraagd of geaccepteerd onder het beleid en wordt gecodeerde group_vars/all_secrets.yaml plus een vaultwachtwoordbestand voor Ansible uitgezonden, waardoor ad-hocgeheime insluiting in afspeelboeken wordt verminderd.

• Geheimen: Geef de voorkeur aan gecodeerde groepsvariabelen van Ansible Vault; gebruik waar nodig strikte modi voor vaultbeheer.
• Installer host: behandelen als een controlevlak met een hoog vertrouwen; toegang en monitor beperken.
• Artefacten: Verkoopkanalen beschermen; organisatorische processen kunnen verificatie-bundel uitbreiden met cryptografische verificatie.
• Logboekregistratie: onderimplementatie/logs van toepassingen en Ansible-logs/ 

Voorbeeld aanroeping vóór implementatie:

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

 Dit is een model voor inner sourcing waarbij voor meer CISCO applicatie-installatie hetzelfde principe kan worden gevolgd door het forken van de repository. 

Kwantitatieve statistieken (installatieduur, defectpercentages) zijn organisatiespecifiek; teams moeten baselinewaarden vergelijken met bestaande runbooks over vergelijkbare topologieën.

1. Verleng ARTEFACT_DEFS (en labels indien nodig) incx_deploy_orchestrator.py.
2. Voeg aangepaste handlers toe wanneer naamgeving niet alleen door patronen kan worden vastgelegd.
3. Verpakkingslogica bijwerken insetup_cxinstaller_preqswanneer downloads worden geautomatiseerd.

Geef de voorkeur aan nieuwe taken binnen samenhangende rollen; introduceer nieuwe rollen wanneer grenzen duidelijk zijn. Draad playbooks via import_playbook of gedocumenteerde entry playbooks. Bewaar veilige standaardinstellingen in group_vars / vars.

Update YAML schema's underintent-generator / schema / en chatbot-ingangen; zorg ervoor dat gegenereerde bestanden overeenkomen met bestandsnamen die worden verwacht door APP_CONFIG.

• Diepere integratie van SBOM of verificatie van beeldhandtekeningen.
• Uitgebreide validatiedekking voor CNC/CDG-scenario's.
• CI referenties voor spec linting en Ansible syntax checks.

De CX Programmable Installer combineert declaratieve specificaties, een Python-besturingsvlak voor verpakking en verificatie en een Ansible-automatiseringsvlak voor schaalbare, herhaalbare implementaties van Crosswork-gerelateerde producten in verschillende infrastructuur- en connectiviteitsmodellen. De architectuur scheidt opzettelijk intentie van uitvoering, past datagestuurde artefactverwachtingen toe waar praktisch en integreert validatie- en vaultworkflows die geschikt zijn voor zakelijke levering. Zie de bijbehorende interne whitepaper voor volledige operationele bijlagen (afspeelboektabellen, matrices voor probleemoplossing, connectiviteitsmatrices en uitgebreide opdrachtverwijzingen).

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

Post-setup artefact focal points (typisch): ansible_playbooks/files/artefacts/, files/bin/, files/charts/, files/images/.

Script:cx_deploy_orchestrator.py

Omgeving (typische sessie):

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