プログラマブルインストーラの使用

Programmable Installerは、Ciscoソフトウェアスタック(Network Services Orchestrator(NSO)、Crosswork Network Controller(CNC)、Crosswork Data Gateway(CDG)、Business Process Automation(BPA)など)を、Enterprise Linux（RHELファミリ）および該当する関連インフラストラクチャ（VMware vCenter、OpenShift、KVM、エアギャップのKubernetes）に導入して運用するための仕様駆動の自動化プラットフォームです。 システムは、宣言的インテント（YAML仕様およびオプションのガイド付きインテント生成）を実行（Ansibleロールおよびプレイブック）から分離し、アーティファクトのパッケージ化、長時間実行されるインストール前のバンドルの検証、暗号化されたシークレットの準備、検証ゲートのオーケストレーションを行うPythonコントロールプレーンを使用します。

このホワイトペーパーでは、アーキテクチャ層、主要なデータフロー、実装パターン（ハイブリッドのデータ駆動型アーティファクト検証モデルを含む）、導入モード（ネイティブ、コンテナ化、オンライン、エアギャップ）、および検証とロギングのフレームワークについて説明します。デリバリおよびプラットフォーム組織にとって、このプラットフォームの目的は、手動による作業を減らし、設定ミスやバイナリの不足を早期に解消し、環境固有のパラメータ設定を維持しながら、製品とトポロジ全体で自動化を標準化することです。

キーワード：インフラストラクチャ自動化、宣言型導入、Ansible、YAML仕様、エアギャップパッケージ、アーティファクト検証、Crosswork、NSO、CNC、CDG、BPA、検証ポリシー、DevOps

企業による多層ネットワークの自動化およびオーケストレーション製品の導入は、従来から手間のかかる作業でした。長いランブック、多くの手動ステップ、サイト間のバージョンのずれや、数時間のうちにプロセスが発生する障害（NEDの欠落、OVAパスの誤り、不完全なエアギャップイメージセット）などです。 このパターンでは、コストが増加し、変更ウィンドウが長くなり、監査が困難になります。

プログラマブルインストーラは、インストールを仕様(トポロジ、バージョン、プラットフォームの選択（vCenterとOpenShiftとVanilla VM）、ファイルパス、エンタイトルメント)によってパラメータ化されたプログラムとして扱います。自動化は、可能な限り強力で、お客様を越えて繰り返し可能です。また、クラスタまたは製品をインストールする前に、「準備不可」を明確に示す結果として迅速に処理できるように、事前にチェックが行われます。

• 宣言型：事業者は導入すべき内容を説明し、プレイブックはその方法を実装します。
• データ駆動型の検証：パターンが安定している場合、リリースごとのアドホックスクリプトではなく、テーブルとルールから予想されるアーティファクトが生成されます。
• ポリシーに基づく品質：階層ポリシーに基づいて、導入前および導入後の検証が実行されます。階層ポリシーには、構造化されたレポートとオプションのチケット作成機能の統合が含まれます。
• マルチモーダル操作：初めてのユーザ用のインタラクティブメニュー、CI/CDスタイルの反復用のCLIおよびフリーズバイナリ、標準化されたランタイムイメージ用のDockerベースのフロー。

1. 仕様は意図を表し、パスと非シークレットパラメータを参照できます。シークレットは、Ansible Vaultワークフローを通過する必要があります。プレーンテキストのスペックフィールドは使用できません。
2. アーティファクト・ストレージは整合性が保護されている必要があります。検証では、仕様に従ったプレゼンスと命名の調整に重点を置き、ポリシーで必要な場合は組織の管理（チェックサム、署名付きバンドル）を拡張します。
3. インストーラからターゲットへのSSHは特権の高いパスであり、インストーラホストの侵害は大きな影響を与えます。強化とアクセス制御は運用上の前提条件です。

1. 最初に宣言型：YAMLでのユーザーの意図。自動化により一貫して解釈されます。
2. 計画と実行の分離：Pythonはゲートを計画、検証、およびオーケストレーションします。Ansibleはインフラストラクチャと製品ステップを実行します。
3. 構成可能な自動化：サイトレベルのプレイブックは、焦点を絞ったプレイブック（プレインストール、Kubernetesトラック、製品インストール）をインポートします。
4. 先進的な情報開示：オンボーディングのためのインタラクティブなセットアップ、高度な自動化のためのフラグとスクリプト。
5. 同じコードベース、複数のランタイム：ネイティブのAlmaLinux/RHELパスとDockerベースのパスは、1つのリポジトリレイアウトを共有します。
6. 明確なエアギャップのサポート：接続されたマシン上のパッケージ、バンドルの転送、前提条件のインストール、パブリックネットワークへの実行時の依存のない導入。

1. パッケージフロー：前提条件のツールは、ファイルを特定の場所にダウンロードまたはステージングします。オプションで、オフラインインストール用に転送可能なtarballを作成します。
2. フローの確認：オーケストレータが仕様を解析し、予期されるアーティファクト（プラットフォームフィルタとエンタイトルメントリストを含む）を解決し、インストール前に準備状況または不足をレポートします。
3. 導入フロー：SpecとVault（およびオプションの事前検証）により、Ansibleプレイブックをエンゲージメントから得られたインベントリと比較して活用できます。

仕様は、プラットフォーム（vCenter、OCP、VM、KVMなど）、ホスト、バージョン付きアプリケーション、トポロジ（NSO CFS/RFSレイアウトなど）、エンタイトルメント（NEDおよびアドオンパッケージ）、およびOVA、qcow2イメージ、アプリケーション層のtarballのファイルパスを説明するYAMLドキュメントです。

特定のアプリケーションuser_specは、CNC/CDGのデフォルトとパスフォールバックを提供します。オーケストレータのパーサーは、ユーザの仕様を正しいソースとして扱い、ユーザのキーが存在しないときに共通の仕様エントリを使用します。

インテント・ジェネレータは、一連の質問表、ルール・エンジン(日付駆動型ロジック)、およびintent.yamlへのスキーマバックマッピング。 

オーケストレータは、スクリプトまたはインタラクティブな生成インテント、検証バンドル、およびインストールの調整を行うための単一のエントリです。その設計は明らかにハイブリッドです。

• ARTIFACT_DEFS：アプリケーションごとのアーティファクト・タイプと命名パターンを宣言します（NSOインストーラ、NED署名付きパッケージ、オプション・パッケージ、CNC OVA/qcow2/tier tarballs、CDGイメージ、BPAチャート、エアギャップ・イメージtarballs）。
• APP_CONFIG: CLI —app値(nso、crossworksuite、bpa)を仕様フォルダ名とデフォルトのインテント・ファイル名にマップします。
• パーサ/ハンドラ：ユーザ仕様および共通仕様を使用してCNC/CDGパスを解決します。カスタムハンドラは、チャートおよびtarballパスの不統一な命名（TSDN/DLMなど）およびBPAバージョンのフォーマットを対象とします。

Readiness:AReportaggregates discovered artifacts; is_readyis trueは、仕様の解析後に必要なファイルが欠落していない場合に適用されます。このモジュールは、sys.frozenパス解決を介してPyInstaller-frozenバイナリをサポートします。

このコンポーネントは、アーティファクトのパッケージングとホストの前提条件のインストール（オンライン、エアギャップ、自動検出）のためのインタラクティブメニューとCLIモード、およびcombinedCNC_NSOを含むマルチアプリケーションパッケージングを提供します。Ansibleおよびverify-bundleロジックで期待されるアーティファクトツリーを生成します。

• Composition：これはスタックのマルチトラック特性を示しています。異なるKubernetesブートストラップパスをインポートします。これは、異なる製品が異なるKubernetesブートストラップパスをターゲットにしていることを反映しています。
• ロール（代表ファミリ）:preinstall（SELinux、ファイアウォール、SSH、レジストリヘルパー）、k8s_install / rke2、deploy_nso、deploy_cnc、deploy_cdg、deploy_bpa、postinstall、uninstall、証明書更新ヘルパー。所有権とテストはロールの境界で管理するのが最適です。ネストされたタスクフォルダはサブワークフローを実装します（NSO L3 HAなど）。

このフレームワークでは、階層型ポリシー制御(Global → App → Stage → Individual Check)、チェックの自動検出、構造化ログに対する拡張レポート、およびオプションのJIRA統合が提供されます。オペレータは、導入前または導入後のフェーズを、導入に使用した仕様と同じ仕様に基づいて実行し、自動化を企業の変更の規律に適した品質ゲートに合わせます。

一般的な支店の指標スケール：BPAおよびNSO全体で30回のチェックの順序(list-validation-checksonで確認する必要があります)。

仕様から必要なボルト変数を導出し、ポリシーに基づいてパスワードをプロンプトまたは受け入れ、暗号化されたgroup_vars/all_secrets.yamlとAnsible用のボールトパスワードファイルを生成します。これにより、プレイブックへのアドホックな秘密の埋め込みが削減されます。

• シークレット：Ansible Vaultで暗号化されたグループ変数を使用します。必要に応じてVault Managerのストリクトモードを使用します。
• インストーラホスト：信頼性の高いコントロールプレーンとして扱い、アクセスを制限して監視します。
• アーティファクト：取得チャネルの保護。組織のプロセスは、暗号化検証によって検証バンドルを強化できます。
• ロギング：ApplicationおよびAnsibleのログはunderdeploy/logs/ 

配置前の呼び出しの例：

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

 これは内部ソーシングのモデルであり、より多くのシスコアプリケーションをインストールする場合は、同じ原則に従ってリポジトリを分岐できます。 

定量的なメトリック(インストール期間、不具合率)は組織に固有です。比較可能なトポロジの従来のランブックに対して基準を設定する必要があります。

1. ExtendARTIFACT_DEFS（および必要に応じてラベル） incx_deploy_orchestrator.py。
2. パターンだけでは名前を取得できない場合に、精度ハンドラを追加します。
3. ダウンロードが自動化されると、パッケージロジックinsetup_cxinstaller_prereqswhenが更新されます。

統合的な役割の中で新しいタスクを好む。境界が明確な場合は新しい役割を導入する。Wireプレイブックviaimport_playbookorドキュメント化されたエントリプレイブックgroup_vars / varsで安全なデフォルトを維持します。

YAMLスキーマのunderintent-generator/schema/およびchatbot入力を更新します。生成されたファイルがAPP_CONFIGで予期されるファイル名と一致することを確認します。

• より詳細なSBOMまたはイメージ署名検証の統合
• CNC/CDGシナリオの検証範囲の拡大
• スペックリンティングおよびAnsible構文チェックのCIリファレンス。

CX Programmable Installerは、宣言仕様、パッケージングと検証用のPythonコントロールプレーン、およびCrosswork関連製品のスケーラブルで反復可能な展開を実現するAnsible自動化プレーンを、さまざまなインフラストラクチャと接続モデルに組み合わせています。このアーキテクチャは、意図的に意図を実行から切り離し、データに基づくアーティファクトの期待を実用的な場所に適用し、エンタープライズ配信に適した検証およびVaultワークフローを組み込みます。運用に関する付属書（プレイブックテーブル、トラブルシューティングマトリクス、接続マトリクス、拡張コマンドリファレンス）については、このアドバイザリに関連する社内用ホワイトペーパーを参照してください。

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

セットアップ後のアーティファクトの焦点（標準）:ansible_playbooks/files/artifacts/、files/bin/、files/charts/、files/images/。

スクリプト：cx_deploy_orchestrator.py

環境（標準セッション）:

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