CN2パイプラインのインストール
概要 このセクションでは、CN2パイプラインのインストールについて説明します。
CN2パイプラインをダウンロード
CN2パイプラインファイルをダウンロードして、インストール前に必要なトークンでファイルを更新します。
CN2パイプラインタールファイルをダウンロードするには:
- ジュニパーネットワークスのダウンロードからCN2パイプライン導入ファイルをダウンロードします。
- ダウンロードしたファイルを管理サーバーに untar します。
CN2パイプラインのステアリングチャートをインストールする
CN2パイプラインのヘルムチャートは、CN2パイプライン管理クラスターのインストールと設定に使用されます。
管理クラスターにCN2パイプラインヘルムチャートをインストールするには、次の手順にしたがっています。
CN2パイプラインのステアリングチャートのインストールを確認する
CN2パイプラインのステアリングチャートのインストールを確認するには、以下のコマンドを実行します。
Argo CD および Helm Configuration
このトピックでは、CN2パイプラインのヘルムチャートインストールの一環として自動化されるArgoコンポーネントと設定を一覧表示します。
-
Argo CD 外部サービス — サービス タイプを NodePort または LoadBalancer として Kubernetes サービスを作成します。これにより、Argo CD API サーバーと Argo CD GUI へのアクセスを提供する Argo CD 外部サービスが作成されます。
-
CN2設定でGitリポジトリを登録 — リポジトリの認証情報を設定し、GitリポジトリをArgo CDに接続します。Argo CDは、Gitリポジトリから設定変更を見てプルするために、Gitリポジトリに設定されています。この Git リポジトリには Kubernetes リソースのみを含める必要があります。Argo CDは、他のタイプのYAMLやファイルを理解していません。
-
Kubernetes クラスタの登録 — Kubernetes クラスタを Argo CD に登録します。このプロセスでは、Argo CD を構成して、Kubernetes クラスター内の Kubernetes リソースをプロビジョニングします。Argo CD では、複数の Kubernetes クラスタを設定できます。
-
Argo CD アプリケーションの作成 — Argo CD GUI を使用してアプリケーションを作成します。Argo CDで作成されたアプリケーションは、Gitリポジトリと1つのKubernetesクラスターに関連付ける必要があります。
Argo のログイン
CN2パイプラインヘルムチャートをインストールすると、ArgoワークフローGUIとArgo CD GUIにアクセスできます。
Argo ワークフロー UI へのアクセス
Argo CD GUIにアクセスするには、NodePortサービスを使用してGUIにアクセスするために、管理クラスターからの接続が必要です。Argo CD GUI には、管理サーバーの IP アドレスとポート 30550 を使用してアクセスします。
-
ブラウザから Argo CD GUI にアクセスします。
https://<management-server-ip-address>:30550
-
管理ノードで、次のコマンドを実行してトークンを受信します。
kubectl -n argo exec $(kubectl get pod -n argo -l 'app=argo-server' -o jsonpath='{.items[0].metadata.name}') -- argo auth token
アルゴCD GUIへのアクセス
Argo CD GUIにアクセスするには、NodePortサービスを使用してGUIにアクセスするために、管理クラスターからの接続が必要です。Argo CD GUI には、管理サーバーの IP アドレスとポート 30551 を使用してアクセスします。
-
ブラウザから Argo CD GUI にアクセスします。
https://<management-server-ip-address>:30550
-
管理ノードで、次のコマンドを実行してトークンを受信します。ユーザー名は admin.
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d
CN2とワークフロー
Argo Workflowsは、Kubernetes上で並列ジョブをオーケストレーションするためのオープンソースコンテナネイティブワークフローエンジンです。ワークフロー内の各ステップがコンテナであるワークフローを定義できます。また、複数ステップのワークフローを一連のタスクとしてモデル化したり、指定非環グラフ(DAG)を使用してタスク間の依存関係をキャプチャしたりできます。
ワークフローが必要な理由
ワークフローは、GitOpsエンジンを使用してCN2リソースをプロビジョニングした後、CN2テストケースを呼び出して実行するために使用されます。これらのワークフローは、CN2アプリケーションの設定を評価し、導入されている設定のテスト結果を生成します。
ワークフローの仕組みとCN2がワークフローを使用する方法
ワークフローは、CN2リソースがGitOpsエンジンによってプロビジョニングされるたびにトリガーされます。CN2リソースまたはCN2リソースのグループはそれぞれ、特定のワークフローテストDAGにマッピングされます。これらのテストスイートが正常に完了すると、CN2構成はステージング環境またはテスト環境から実稼働環境にプロモートされる資格があります。
CN2パイプラインサービス
パイプライン サービスは、Kubernetes リソースの変更に関する Argo イベントからの通知をリッスンします。パイプラインサービスは、Argoイベントが適用したCN2設定に関連するデータでサービスを消費してトリガーするために使用されるサービスを公開します。CN2パイプラインサービスは、適用したCN2設定のタイプに対してトリガーされるテストワークフローを特定する必要があります。ワークフローは、通知されるオブジェクトに応じて動的に変化します。CN2パイプラインリスナーサービスは、適用されるCN2設定に依存するワークフローを呼び出します。
CN2パイプライン構成
このトピックでは、CN2パイプライン設定の例を示します。
パイプラインの設定
パイプライン構成はパイプラインエンジンで使用され、以下が含まれます。
-
パイプラインコミットのしきい値
-
構成マップ:
cn2pipeline-configs -
名前 空間：
argo-events
CN2パイプラインの設定例:
apiVersion: v1
data:
testcase_trigger_threshold: "10"
kind: ConfigMap
labels:
app.kubernetes.io/managed-by: Helm
name: cn2pipeline-configs
namespace: argo-events
テスト ワークフロー テンプレート パラメーターの構成
すべてのワークフロー テンプレート入力は、構成マップとして保存されます。これらの構成マップは、パイプライン サービスによって実行中に動的に選択されます。
種類マップへのワークフロー
このマッピング設定には、CN2リソース kind マッピングへのワークフローテンプレートが含まれています。実行するテンプレートは 1 つだけ選択され、一致する最初のマップの優先度が高くなります。の kind: ['*'] アスタリスク(*)は、テンプレートの優先度が他 kind のどのマッチよりも高いことを示し、すべてのマッピングを上書きします。
CN2リソース種類マッピングテンプレートのワークフローテンプレートには、以下が含まれます。
-
構成マップ:
cn2tmpl-to-kind-map -
名前 空間：
argo-events
次に、CN2リソース kind マッピングへのワークフローテンプレートの設定例を示します。kindmapのアスタリスク(*)を kind: ['*'] メモします。
apiVersion: v1
data:
kindmap: |
- workflow: it-cloud-arch1-sre2
kind: ['*']
- workflow: custom-cnf-sample-test
kind: ['namespace']
- workflow: it-cloud-arch1-sre1
kind: ['service']
- workflow: it-cloud-arch2-sre3
kind: ['service']
- workflow: it-cloud-arch2-sre4
kind: ['service']
- workflow: it-cloud-arch2-sre5
kind: ['namespace']
kind: ConfigMap
metadata:
labels:
app.kubernetes.io/managed-by: Helm
name: cn2tmpl-to-kind-map
namespace: argo-events
CN2クラスター向けKuberconfigシークレット
CN2クラスター用のbase64エンコードされたkuberconfigが作成され、秘密として使用されます。Kubeconfig は、クラスターを認証するための Kubernetes クラスターの詳細、証明書、シークレット トークンをすべて含む YAML ファイルです。
-
秘密：
cn2-cluster-kubeconfig -
名前 空間：
argo-events
名前は cn2-cluster-kubeconfig 変更しないでください。
CN2クラスターのkuberconfigシークレットの例を次に示します。
apiVersion: v1 kind: Secret metadata: name: cn2-cluster-kubeconfig namespace: argo-events data: config: <base64 value of your cn2cluster kubeconfig> type: Opaque
CN2パイプラインのカスタムワークフローを作成する
カスタムワークフローテストを作成して、コンテナネットワーク機能(CNF)をテストできます。
カスタムワークフローを作成するには、CN2パイプラインファイルに付属するカスタムテストワークフローテンプレートの例を使用できます。すべてのワークフローには、一連の入力パラメーター、ボリュームマウント、コンテナの作成などが含まれます。ワークフロー テンプレートの作成を理解するには、 Argo ワークフローを参照してください。
次のカスタム テスト ワークフロー テンプレートの例を示します。
-
ワークフローへの入力パラメーター
-
ボリュームのマウント
-
ワークフローを使用してKubernetesリソースを作成する(テンプレート名:
create-cnf-tf and create-cnf-service-tf -
ワークフローに埋め込まれたコード(テンプレート名:
test-access-tf -
外部コードをプルし、コンテナ内で実行します(テンプレート名:
test-service-tf
パイプラインの実行中にワークフローへの入力を自動化するために、ワークフローの入力を含むワークフロー パラメーター構成マップが作成されます。構成マップの名前は、ワークフロー テンプレートと同じにする必要があります。
次の例では、テンプレート名は. custom-cnf-sample-test設定マップは、同じ名前で自動的に作成されます。パイプラインの実行の一環として、パイプラインサービスはテンプレート名を含む構成マップを探し、入力を取得します。入力はパイプラインがワークフローをトリガーしたときに自動的にワークフローに追加されます。
カスタム ワークフローをトリガーするテスト ケースで発生するもう 1 つの更新プログラムは、構成マップ名を に変更することです <cn2tmpl-to-kind-map>。
- workflow: custom-cnf-sample-test
kind: ['namespace']
テンプレートのワークフロー設定の例を次に custom-cnf-sample-test示します。
apiVersion: argoproj.io/v1alpha1
kind: WorkflowTemplate # new type of k8s spec
metadata:
name: custom-cnf-sample-test # name of the workflow spec
namespace: argo-events
spec:
serviceAccountName: operate-workflow-sa
entrypoint: cnf-test-workflow # invoke the workflows template
hostNetwork: true
arguments:
parameters:
- name: image # the path to a test docker image
value: not_provided
- name: kubeconfig_secret # eg: kubeconfig-989348
value: not_provided
- name: report_dir # eg: /root/SolutionReports
value: not_provided
volumes:
- name: kubeconfig
secret:
secretName: "{{ `{{workflow.parameters.kubeconfig_secret}}` }}"
- name: reportdir
hostPath:
path: "{{ `{{workflow.parameters.report_dir}}` }}"
templates:
- name: create-cnf-tf
resource:
action: apply
#successCondition: status.succeeded > 0
#failureCondition: status.failed > 3
manifest: |
apiVersion: v1
kind: Pod
metadata:
name: webapp-cnf
namespace: argo-events
labels:
app.kubernetes.io/name: proxy
spec:
containers:
- name: nginx
image: {{ .Values.global.docker_image_repo }}/nginx:stable
ports:
- containerPort: 80
name: http-web-svc
- name: create-cnf-service-tf
resource:
action: apply
#successCondition: status.succeeded > 0
#failureCondition: status.failed > 3
manifest: |
apiVersion: v1
kind: Service
metadata:
name: webapp-service
namespace: argo-events
spec:
selector:
app.kubernetes.io/name: proxy
ports:
- name: webapp-http
protocol: TCP
port: 80
targetPort: http-web-svc
- name: test-access-tf
script:
image: "{{ `{{workflow.parameters.image}}` }}"
command: [python]
source: |
import time
print('--Test access to CNF--')
url = 'webapp-service.argo-events.svc.cluster.local'
retry_max = 3
retry_cnt = 0
while retry_cnt < retry_max:
print('Response status code: {}','200')
time.sleep(1)
retry_cnt += 1
print('Monitoring access count: {}',retry_cnt)
print('Completed')
- name: test-service-tf
inputs:
artifacts:
- name: pyrunner
path: /usr/local/src/cn2_py_runner.py
mode: 0755
http:
url: https://raw.githubusercontent.com/roshpr/argotest/main/cn2-experiments/cn2_py_runner.py
script:
image: "{{ `{{workflow.parameters.image}}` }}"
command: [python]
args: ["/usr/local/src/cn2_py_runner.py", "4"]
- name: cnf-test-workflow
dag:
tasks:
- name: create-cnf
template: create-cnf-tf
- name: create-cnf-service
template: create-cnf-service-tf
- name: test-connectivity
template: test-access-tf
dependencies: [create-cnf-service]
- name: test-load
template: test-service-tf
dependencies: [create-cnf-service]