Utilizar el instalador programable

El instalador programable es una plataforma de automatización basada en especificaciones para implementar y utilizar pilas de software de Cisco, incluidos Network Services Orchestrator (NSO), Crosswork Network Controller (CNC), Crosswork Data Gateway (CDG) y Business Process Automation (BPA), en Linux empresarial (familia RHEL) y la infraestructura asociada donde corresponda (VMware vCenter, OpenShift, KVM, Air-Gap Kubernetes). El sistema separa la intención declarativa (especificaciones YAML y generación de intención guiada opcional) de la ejecución (roles y cuadernos Ansible), con un plano de control Python que empaqueta artefactos, verifica paquetes antes de instalaciones de larga duración, prepara secretos cifrados y organiza puertas de validación.

En este informe técnico se explican las capas arquitectónicas, los flujos de datos primarios, los patrones de implementación (incluido un modelo híbrido de verificación de artefactos impulsado por datos), los modos de implementación (nativos, en contenedores, online y con espacios entre nodos) y los marcos de validación y registro. En el caso de las organizaciones de plataforma y de distribución, la plataforma pretende reducir el trabajo manual, la configuración incorrecta de la superficie y la ausencia temprana de binarios, así como estandarizar la automatización en los productos y las topologías al tiempo que se conserva la parametrización específica del entorno.

Palabras clave: automatización de infraestructuras, implementación declarativa, Ansible, especificación YAML, empaquetado Air-Gap, verificación de artefactos, Crosswork, NSO, CNC, CDG, BPA, política de validación, DevOps.

Tradicionalmente, la instalación empresarial de productos de automatización y orquestación de redes multinivel ha sido muy sencilla: runbooks largos, muchos pasos manuales, desviación de versiones entre sitios y fallos que superan horas en un proceso (falta de NED, rutas de OVA erróneas, conjuntos de imágenes con huecos de aire incompletos). Ese patrón aumenta los costos, alarga las ventanas de cambio y dificulta las auditorías.

El Instalador programable trata una instalación como un programa parametrizado por una especificación: topología, versiones, elección de plataforma (vCenter frente a OpenShift frente a VM virtuales), rutas de archivo y derechos. La automatización es idempotente siempre que sea posible, se puede repetir entre los clientes y se carga de forma frontal con comprobaciones, de modo que "no preparado" es un resultado rápido y explícito antes de la instalación del clúster o del producto.

• Declarativo: los operadores describen lo que debe implementarse; los cuadernos de campaña implementan cómo.
• Verificación basada en datos: los artefactos esperados se derivan de tablas y reglas en lugar de scripts ad-hoc por versión, cuando los patrones son estables.
• Calidad controlada por políticas: la validación previa y posterior a la implementación se ejecuta bajo políticas jerárquicas, con informes estructurados e integración de notificaciones opcional.
• Funcionamiento multimodal: menús interactivos para usuarios principiantes; CLI y binarios congelados para la repetición estilo CI/CD; Flujos basados en Docker para imágenes de tiempo de ejecución estandarizadas.

1. Especificaciones, intención expresa; pueden hacer referencia a rutas y parámetros no secretos. Los secretos deben fluir por los flujos de trabajo de Ansible Vault, no por campos de texto sin formato donde se puedan evitar.
2. El almacenamiento de artefactos debe estar protegido contra la integridad; la verificación se centra en la alineación de la presencia y los nombres con las especificaciones (amplíe con los controles organizativos (sumas de comprobación, paquetes firmados) donde la política lo requiera.
3. El SSH del instalador al destino es una trayectoria de alto privilegio; el riesgo del host del instalador es de gran impacto. La consolidación y el control de acceso son requisitos previos operativos.

1. Declarativo primero: intención del usuario en YAML; la automatización lo interpreta de forma coherente.
2. Separación de la planificación y la ejecución: Python planifica, verifica y organiza las puertas; Ansible ejecuta pasos de productos e infraestructura.
3. Automatización componible: los cuadernos de campaña a nivel de sitio importan cuadernos centrados (preinstalación, pistas de Kubernetes, instalaciones de productos).
4. Divulgación progresiva: configuración interactiva para la incorporación; indicadores y scripts para automatización avanzada.
5. Misma base de código, varios tiempos de ejecución: las rutas nativas de AlmaLinux/RHEL y las rutas basadas en Docker comparten un diseño de repositorio.
6. Soporte explícito del vacío de aire: paquete en una máquina conectada; transferir un paquete; instalar requisitos previos e implementar sin dependencia de tiempo de ejecución en redes públicas.

1. Flujo de paquetes: la herramienta de requisitos previos descarga o almacena en zona intermedia los archivos en una ubicación específica, produciendo opcionalmente un archivo comprimido transferible para las instalaciones sin conexión.
2. Verificación del flujo: el orquestador analiza las especificaciones, resuelve los artefactos esperados (incluidos los filtros de la plataforma y las listas de derechos) e informa de que están listos o no se han instalado antes de la instalación.
3. Implemente el flujo: la espec. más la caja fuerte (y la prevalidación opcional) impulsan los cuadernos de campaña Ansible frente a los inventarios derivados del compromiso.

Las especificaciones son documentos YAML que describen plataformas (por ejemplo, vCenter, OCP, VM, KVM ), hosts, aplicaciones con versiones, topología (por ejemplo, diseños CFS/RFS de NSO), derechos (paquetes NED y complementarios) y rutas de archivos para OVA, imágenes qcow2 y tarballs de capa de aplicación.

Una aplicación específica user_spec suministra valores por defecto y rutas de reserva para CNC/CDG. El analizador del orquestador trata las especificaciones del usuario como fuente de veracidad y utiliza entradas de especificaciones comunes cuando no hay claves de usuario.

El generador de intents admite la recopilación guiada de requisitos mediante un conjunto de cuestionarios, un motor de reglas (lógica controlada por fecha) y asignación respaldada por esquema a intent.yaml. 

El orquestador es la única entrada para la coordinación de la instalación, la verificación de agrupamiento y la intención de generar con scripts o interactiva. Su diseño es explícitamente híbrido:

• ARTIFACT_DEFS: declara tipos de artefactos y patrones de denominación por aplicación (instalador NSO, paquetes firmados NED, paquetes opcionales; CNC OVA/qcow2/tier tarballs; imágenes CDG; gráficos BPA y tarballs de imágenes Air-Gap).
• APP_CONFIG: Asigna los valores de CLI —app (nso, crossworksuite, bpa) a los nombres de carpeta de especificación y a los nombres de archivo de intent predeterminados.
• Analizador/Manejadores: Resuelva las rutas CNC/CDG utilizando especificaciones de usuario y especificaciones comunes; los controladores personalizados cubren la nomenclatura no uniforme (por ejemplo, TSDN/DLM) y el formato de versión BPA para las rutas de gráficos y tarball.

Readiness:AReportaggregates detected artifacts; is_readyis true cuando no faltan archivos requeridos después del análisis de especificaciones. El módulo admite binarios congelados por PyInstaller mediante la resolución de ruta sys.locked.

Este componente proporciona menús interactivos y modos CLI para empaquetar artefactos e instalar requisitos previos del host: online, air-gap o auto-detect; empaquetado multiaplicación, incluido combinadoCNC_NSO. Rellena el árbol de artefactos esperado por Ansible y por la lógica verify-bundle.

• Composición: ilustra la naturaleza multipista de la pila: importa diferentes rutas de arranque de Kubernetes, lo que refleja que los diferentes productos se dirigen a diferentes rutas de arranque de Kubernetes.
• Funciones (familias representativas): preinstalación (SELinux, firewall, SSH, ayudantes de registro), k8s_install / rke2, deploy_nso, deploy_cnc, deploy_cdg, deploy_bpa, postinstall, uninstall y ayudantes de renovación de certificados. La propiedad y las pruebas se administran mejor en los límites de las funciones; las carpetas de tareas anidadas implementan subflujos de trabajo (por ejemplo, NSO L3 HA).

El marco proporciona un control jerárquico de políticas (global → app → stage → individual check), detección automática de comprobaciones, informes mejorados a registros estructurados e integración opcional de JIRA. Los operadores ejecutan las fases anteriores y posteriores a la implementación con las mismas especificaciones utilizadas para la instalación, alineando la automatización con puertas de calidad adecuadas para la disciplina de cambio empresarial.

Escala indicativa en una sucursal típica: en el orden de treinta comprobaciones a través de BPA y NSO (recuentos que se confirmarán confeccionar comprobaciones de validación de listas en su pago).

Deriva las variables de depósito necesarias de las especificaciones, solicita o acepta contraseñas en virtud de la política y emite group_vars/all_secrets.yaml cifrado más un archivo de contraseña de depósito para Ansible, lo que reduce la incrustación de secretos ad-hoc en los cuadernos.

• Secretos:Prefiera las variables de grupo cifradas de Ansible Vault; utilice los modos estrictos de vault manager cuando corresponda.
• Host del instalador:tratar como un plano de control de alta confianza; restringir el acceso y supervisar.
• Artefactos:Proteger los canales de adquisición; los procesos organizativos pueden aumentar verify-bundle con la verificación criptográfica.
• Registro:Registros de aplicaciones y de Ansible subimplementados/registros/ 

Ejemplo de invocación previa a la implementación:

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

 Se trata de un modelo de abastecimiento interno en el que para más instalaciones de aplicaciones de CISCO se puede seguir el mismo principio bifurcando el repositorio. 

Las métricas cuantitativas (duración de la instalación, tasas de defectos) son específicas de cada organización; los equipos deben comparar los runbooks heredados con topologías comparables.

1. ExtendARTIFACT_DEFS(y etiquetas si es necesario) incx_deploy_orchestrator.py.
2. Agregue un controlador personalizado cuando los patrones solos no puedan capturar la nomenclatura.
3. Actualice la lógica de empaquetado insetup_cxinstaller_prereqscuando las descargas estén automatizadas.

Preferir nuevas tareas dentro de roles cohesionados; introducir nuevos roles cuando los límites estén claros. Cuadernos de hilo viaimport_playbooko cuadernos de entrada documentados. Mantenga los valores predeterminados seguros en group_vars / vars.

Actualizar esquemas YAML con entradas de generación/esquema/subintencional y chatbot; asegúrese de que los archivos generados coincidan con los nombres de archivo esperados por APP_CONFIG.

• SBOM más profunda o integración de verificación de firma de imagen.
• Cobertura de validación ampliada para escenarios CNC/CDG.
• Referencias de CI para linting de especificaciones y comprobaciones de sintaxis de Ansible.

El instalador programable CX combina especificaciones declarativas, un plano de control Python para empaquetado y verificación y un plano de automatización Ansible para implementaciones escalables y repetibles de productos relacionados con Crosswork en diversos modelos de infraestructura y conectividad. Su arquitectura separa intencionadamente la intención de la ejecución, aplica expectativas de artefactos impulsados por datos cuando es práctico e integra flujos de trabajo de validación y depósito adecuados para la entrega empresarial. Para ver los anexos operativos completos (tablas del cuaderno de campaña, matrices de resolución de problemas, matrices de conectividad y referencias de comandos ampliadas), consulte el informe técnico interno complementario.

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

Puntos focales de artefactos de configuración posterior (típico):ansible_playbooks/files/artifacts/, files/bin/, files/charts/, files/images/.

Script:cx_deploy_orchestrator.py

Entorno (sesión típica):

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