CN2パイプライン
概要 ジュニパークラウドネイティブのContrail® Networking™(CN2)パイプラインは、CI/CDツールで、GitOpsベースのワークフローでCN2の設定、テスト、条件の自動化を可能にします。CN2パイプラインは、CN2リリース23.1以降、CN2クラスターと並行して動作します。
CN2パイプラインの概要
GitOps は Git リポジトリを中心に一元化された導入方法で、GitOps ワークフローはテスト、ステージング、本番稼働を通じて設定をプッシュします。多くのお客様は、ステージング環境またはステージングクラスターを実行しています。GitOpsプロセスは、テストケースYAMLファイルを使用してCN2ネットワーク設定を展開およびテストするための自動構成をサポートしています。
(管理者)がCN2パイプラインとGitOpsを設定すると、CN2パイプラインは以下を実行します。
-
GitOpsリポジトリと同期し、複数のKubernetesクラスターでCN2設定を自動プロビジョニングします。
-
CN2設定をプロビジョニングし、各Kubernetesクラスタに導入されたCN2設定をテストおよび検証する機能を備えています。
-
自動改訂監視と更新を提供します。
CN2の設定
CN2は、YAMLまたはJSON形式で記述されたKubernetesカスタムリソース定義(CRD)設定を使用します。これらの CRD は Git リポジトリに保存され、管理されるため、Git リポジトリはすべてのネットワーク構成の真実のソースになります。
GitOps
「GitOps は、開発者が通常 IT 運用の視点に基づくタスクを実行するためのパラダイムまたは一連のプラクティスです。GitOpsでは、宣言的な仕様でシステムを記述し、監視する必要があり、最終的には継続的なすべてのものの基礎となります。」見積もりは CloudBeesからです。
GitOps の動作モードを実現するには、Argo CD アプリケーションが使用されます。CN2 Gitリポジトリは、Argo CDアプリケーションとして使用するように構成されています。Argo CD は、Kubernetes 向けの宣言型 GitOps 継続的配信ツールです。 図 1 を参照してください。
GitOps エンジンは、Git リポジトリからすべてのアプリケーション ファイルをキャッシュするリポジトリ サーバーも実行します。これらのファイルは、Gitリポジトリに受信したCN2設定変更について検証および監視されます。
CN2およびGitOps
CN2向けGitOpsをサポートする主なメリットは、CN2ネットワーク設定の自動設定導入とテストを達成することです。CN2設定は、Gitリポジトリで維持されるカスタムリソース定義(CRD)です。これらのCRDは、GitリポジトリのCN2設定に変更が発生するたびにCN2クラスターに適用されます。これらの変更をテストして適用するために、GitOps アプリケーション Argo CD と Argo Workflows が利用されています。
CN2パイプラインの設定フロー
CN2設定はCN2 Gitリポジトリで管理されています。CN2 Gitリポジトリは、Argo CDアプリケーションとして使用するように構成されています。CN2パイプラインの設定フローは次のとおりです。
- CN2設定は、最初にあなた(管理者)によってステージングリポジトリにプッシュされます。
-
リポジトリ内の設定を変更すると、GitOps サーバーへの Git 同期がトリガーされます。
-
GitOpsサーバーは、現在の設定とCN2 Gitリポジトリから取得した新しい設定を比較して、変更を探します。
-
新しい変更がプッシュされた場合、GitOpsサーバーはこれらの変更をCN2環境に適用します。
GitOps サーバー
GitOpsサーバーは、CN2環境の設定が常にGitリポジトリと同期していることを確認します。CN2パイプラインは、2つの支店をサポートしています。
- 1 つはステージング環境用です。
- 1 つは実稼働環境用です。
多くのお客様は、ステージング環境またはステージングクラスターを実行しています。ステージングブランチは、ステージングCN2クラスターにプッシュする必要がある設定を(管理者)がプッシュする場所です。これらの構成は、構成が実稼働ブランチにマージされる前に、ワークフロー エンジンによってテストされます。
ワークフローとテスト
GitOpsサーバーは、次のようにすべての設定変更をCN2セットアップにプッシュします。
-
このプッシュにより、テスト ケースを実行するワークフロー サイクルがトリガーされます。これらのテストケースでは、CN2設定をステージング設定で適用した構成と照らして検証します。
-
テスト ケースが成功すると、テスト完了が通知され、マージ要求が実稼働ブランチに表示されます。
-
次に、マージ要求の変更を検証し、実稼働ブランチにマージする変更を承認する必要があります。
-
新しい設定が実稼働ブランチにマージされた後、GitOpsサーバーは設定を同期して、設定をCN2本番クラスターに適用します。
前提 条件
CN2パイプラインをインストールする前に、以下があることを確認します。
-
GitLab
-
管理Kubernetesクラスタ(CN2パイプラインをインストールする場所)
-
CN2 Kubernetesクラスタ
-
ヘルム 3.2.0
-
管理KubernetesクラスタからCN2クラスタへの接続
-
サンプルConfigMapファイルを持つCN2設定フォルダを持つGitLabリポジトリ
Git Server フォルダーでのサンプル構成マップの作成を参照してください。
-
MountPath フォルダー
- 管理Kubernetesクラスターから外部への接続、Argo CD、Argoワークフロー、テスト結果へのアクセスが必要
OpenShift のみの追加の前提条件
CN2パイプラインでRed Hat OpenShiftを使用している場合は、次の前提条件も必要です。
-
ホストに OpenShift クラスターからのエントリーが含まれていることを確認します。
-
OpenShiftクラスターに /ingress/openshift/publicファイルからのイングレス をインストールする
CN2パイプラインのインストールと設定
コンポーネント
CN2パイプラインは、以下のコンポーネントをインストールおよび設定します。
-
Argo CD
-
Argoワークフロー
-
アルゴイベント
-
CN2パイプラインサービス
-
CN2テストワークフローの設定、アップロード、トリガー
-
顧客のコンテナネットワーク機能(CNF)をサポート
CN2コンポーネント
すべてのCN2パイプラインコンポーネントは、CN2パイプラインのステアリングチャートインストールの一部としてインストールおよび設定されます。Argo CDはCN2パイプラインのコンポーネントの1つで、管理クラスターにインストールされています。
Argo CD は初期設定時に以下の詳細で構成されます。
-
CN2クラスタ環境の詳細
-
Gitリポジトリのアクセス詳細
-
CN2 GitOpsエンジンアプリケーション設定
Kubernetes
CN2またはその他のコンテナネットワークインターフェイス(CNI)を使用して、ネイティブのKubernetesまたはRed Hat OpenShiftを使用して、CN2パイプラインをプロビジョニングできます。