前書き

アプリケーションを展開する際のエラーを減らし、複雑さを整理するために、CI / CDシステムには、パッケージ管理/展開のための堅牢なツールと自動化されたテストを伴うパイプラインが含まれている必要があります。 しかし、現代の本番環境では、クラウドベースのインフラストラクチャの複雑さが増すため、信頼性の高いCI / CD環境をまとめる際に問題が生じる可能性があります。 この問題を解決するために開発された2つのKubernetes固有のツールは、https://helm.sh/ [Helm]パッケージマネージャーとhttps://jenkins-x.io/[Jenkins X]パイプライン自動化ツールです。

HelmはKubernetes用に特別に設計されたパッケージマネージャーであり、Microsoft、Google、Bitnami、およびHelm貢献者コミュニティと共同でhttps://www.cncf.io/[Cloud Native Computing Foundation](CNCF)によって管理されています。 高いレベルで、APTやYUMなどのLinuxシステムパッケージマネージャーと同じ目標を達成します。アプリケーションのインストールと依存関係をバックグラウンドで管理し、複雑さをユーザーから隠します。 しかし、Kubernetesでは、この種の管理の必要性がさらに顕著になります。アプリケーションのインストールには、YAMLファイルの複雑で退屈なオーケストレーションが必要であり、リリースのアップグレードまたはロールバックは、困難から不可能まで可能です。 この問題を解決するために、HelmはKubernetes上で実行され、アプリケーションを_charts_と呼ばれる事前構成済みのリソースにパッケージ化します。ユーザーは簡単なコマンドで管理でき、アプリケーションの共有と管理のプロセスをより使いやすくします。

Jenkins Xは、Kubernetesの生産パイプラインと環境を自動化するために使用されるCI / CDツールです。 Dockerイメージ、Helmチャート、およびhttps://jenkins.io/pipeline/getting-started-pipelines/[Jenkins pipeline engine]を使用して、Jenkins XはGitHubの環境間でリリースとバージョンを自動的に管理し、アプリケーションを促進できます。

*CI/CD with Kubernetes * seriesのこの2番目の記事では、次の2つのツールをプレビューします。

  • Helmを使用したKubernetesパッケージの管理、作成、展開。

  • Jenkins Xを使用したCI / CDパイプラインの構築。

さまざまなKubernetesプラットフォームでHelmおよびJenkins Xを使用できますが、このチュートリアルでは、ローカル環境にセットアップされたシミュレーションKubernetesクラスターを実行します。 これを行うには、https://github.com/kubernetes/minikube [Minikube]を使用します。これは、真のKubernetesクラスターをセットアップしなくても、ご使用のマシンでKubernetesツールを試すことができるプログラムです。

このチュートリアルの終わりまでに、これらのKubernetesネイティブツールがクラウドアプリケーションのCI / CDシステムの実装にどのように役立つかについての基本的な理解が得られます。

前提条件

このチュートリアルを実行するには、次のものが必要です。

  • 16 GB以上のRAMを搭載したUbuntu 16.04サーバー。 このチュートリアルはデモンストレーションのみを目的としているため、コマンドはルートアカウントから実行されます。 *このアカウントの制限されていない権限は、本番環境向けのベストプラクティスに準拠しておらず、システムに影響する可能性があります。*このため、仮想マシンやhttps:/などのテスト環境でこれらの手順に従うことをお勧めします。 /www.digitalocean.com/products/droplets/[DigitalOcean Droplet]。

  • GitHubアカウントおよびhttps://github.com/settings/tokens/new?scopes=repo,read:user,read:org,user:email,write:repo_hook,delete_repo [ GitHub APIトークン]。 このチュートリアルのJenkins Xの部分で入力できるように、このAPIトークンを記録してください。

  • Kubernetesの概念に精通している。 詳細については、記事https://www.digitalocean.com/community/tutorials/an-introduction-to-kubernetes[Kubernetesの概要]を参照してください。

手順1-Minikubeを使用したローカルKubernetesクラスターの作成

Minikubeをセットアップする前に、Kubernetesコマンドラインツールhttps://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl[kubectl](双方向データ転送リレー)を含む依存関係をインストールする必要があります。 socat、およびコンテナプログラムhttps://www.docker.com/[Docker]。

まず、システムのパッケージマネージャーがHTTPS経由で `+ apt-transport-https +`を使用してパッケージにアクセスできることを確認します。

apt-get update
apt-get install apt-transport-https

次に、kubectlのダウンロードが有効であることを確認するには、公式のGoogleリポジトリのGPGキーをシステムに追加します。

curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -

GPGキーを追加したら、テキストエディターでファイルを開いてファイル `+ / etc / apt / sources.list.d / kubernetes.list +`を作成します。

nano /etc/apt/sources.list.d/kubernetes.list

このファイルが開いたら、次の行を追加します。

/etc/apt/sources.list.d/kubernetes.list

deb http://apt.kubernetes.io/ kubernetes-xenial main

これにより、システムにkubectlをダウンロードするためのソースが表示されます。 行を追加したら、ファイルを保存して終了します。 nanoテキストエディターでは、 `+ CTRL + X `を押し、 ` y `を入力し、 ` ENTER +`を押すことでこれを行うことができます。

最後に、APTのソースリストを更新し、 + kubectl ++ socat +、および `+ docker.io +`をインストールします。

apt-get update
apt-get install -y kubectl socat docker.io

kubectlをインストールしたら、https://kubernetes.io/docs/tasks/tools/install-minikube/ [Minikubeのインストール]に進むことができます。 まず、 `+ curl +`を使用してプログラムのバイナリをダウンロードします。

curl -Lo minikube https://storage.googleapis.com/minikube/releases//minikube-linux-amd64

次に、ダウンロードしたファイルのアクセス許可を変更して、システムで実行できるようにします。

chmod +x minikube

最後に、 `+ minikube `ファイルを ` / usr / local / bin / +`の実行可能パスにコピーし、ホームディレクトリから元のファイルを削除します。

cp minikube /usr/local/bin/
rm minikube

マシンにMinikubeをインストールしたら、プログラムを開始できます。 Minikube Kubernetesクラスターを作成するには、次のコマンドを使用します。

minikube start --vm-driver none

フラグ「+-vm-driver none +」は、仮想マシンではなくコンテナを使用してローカルホストでKubernetesを実行するようにMinikubeに指示します。 この方法でMinikubeを実行すると、VMドライバーをダウンロードする必要がなくなりますが、Kubernetes APIサーバーがルートとして安全に実行されなくなります。

Minikubeを起動したら、次のコマンドを使用してクラスターが実行されていることを確認してください。

minikube status

`++`の代わりにIPアドレスを使用して、次の出力を受け取ります。

minikube: Running
cluster: Running
kubectl: Correctly Configured: pointing to minikube-vm at

Minikubeを使用してシミュレートされたKubernetesクラスターをセットアップしたので、クラスター上にHelmパッケージマネージャーをインストールして構成することにより、Kubernetesパッケージ管理の経験を積むことができます。

手順2-クラスターでのHelm Package Managerのセットアップ

Kubernetesクラスターへのアプリケーションのインストールを調整するために、Helmパッケージマネージャーをインストールします。 Helmは、クラスターの外部で実行される「+ helm 」クライアントと、クラスター内からアプリケーションのリリースを管理する「 tiller +」サーバーで構成されます。 クラスターでHelmを正常に実行するには、両方をインストールして構成する必要があります。

Helmバイナリをインストールするには、まず `+ curl `を使用して次のhttps://raw.githubusercontent.com/helmをダウンロードします/ helm / master / scripts / get [インストールスクリプト]を公式のHelm GitHubリポジトリから ` get_helm.sh +`という名前の新しいファイルに:

curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get > get_helm.sh

このスクリプトにはルートアクセスが必要なため、ファイルの所有者(この場合はルート)が読み取り、書き込み、実行できるように、 `+ get_helm.sh +`のアクセス許可を変更します。

chmod 700 get_helm.sh

次に、スクリプトを実行します。

./get_helm.sh

スクリプトが終了すると、 `+ / usr / local / bin / helm `に ` helm `がインストールされ、 ` / usr / local / bin / tiller `に ` tiller +`がインストールされます。

+ tiller +`がインストールされましたが、Kubernetesクラスター内の必要なリソースにアクセスするための正しいロールとパーミッションがまだありません。 これらのロールと権限を「+ tiller +」に割り当てるには、「+ tiller +」という名前のhttps://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/[service account]を作成する必要があります。 Kubernetesでは、サービスアカウントはポッドで実行されるプロセスのIDを表します。 プロセスは、サービスアカウントを介して認証された後、APIサーバーに接続してクラスターリソースにアクセスできます。 ポッドに特定のサービスアカウントが割り当てられていない場合、デフォルトのサービスアカウントを取得します。 また、 `+ tiller +`サービスアカウントを承認するhttps://kubernetes.io/docs/reference/access-authn-authz/rbac/[Role-Based access control](RBAC)ルールを作成する必要があります。

Kubernetes RBAC APIの_role_には、アクセス許可のセットを決定するルールが含まれています。 ロールは、「+ namespace 」または「 cluster 」のスコープで定義でき、単一のネームスペース内のリソースへのアクセスのみを許可できます。 ` ClusterRole `はクラスターレベルで同じ権限を作成し、ノードなどのクラスタースコープのリソースやポッドなどの名前空間付きリソースへのアクセスを許可できます。 ` tiller `サービスアカウントに適切なロールを割り当てるには、 ` rbac_helm.yaml +`というYAMLファイルを作成し、テキストエディターで開きます。

nano rbac_helm.yaml

ファイルに次の行を追加して、 `+ tiller +`サービスアカウントを設定します。

rbac_helm.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
 name: tiller
 namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
 name: tiller
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: ClusterRole
 name: cluster-admin
subjects:
 - kind: ServiceAccount
   name: tiller
   namespace: kube-system

 - kind: User
   name: "admin"
   apiGroup: rbac.authorization.k8s.io

 - kind: User
   name: "kubelet"
   apiGroup: rbac.authorization.k8s.io

 - kind: Group
   name: system:serviceaccounts
   apiGroup: rbac.authorization.k8s.io

上記のファイルでは、 `+ ServiceAccount `により、 ` tiller `プロセスが認証済みサービスアカウントとしてapiserverにアクセスできます。 「 ClusterRole 」は特定の権限をロールに付与し、「 ClusterRoleBinding 」はそのロールを「 tiller 」サービスアカウント、「 admin 」および「 kubelet 」ユーザーを含む「 subjects 」のリストに割り当てます。 ` system:serviceaccounts +`グループ。

次に、次のコマンドで設定を `+ rbac_helm.yaml +`にデプロイします:

kubectl apply -f rbac_helm.yaml

`+ tiller `設定がデプロイされたら、設定したサービスアカウントを使用するように `-service-acount +`フラグでHelmを初期化できます:

helm init --service-account tiller

初期化が成功したことを表す次の出力が表示されます。

OutputCreating /root/.helm
Creating /root/.helm/repository
Creating /root/.helm/repository/cache
Creating /root/.helm/repository/local
Creating /root/.helm/plugins
Creating /root/.helm/starters
Creating /root/.helm/cache/archive
Creating /root/.helm/repository/repositories.yaml
Adding stable repo with URL: https://kubernetes-charts.storage.googleapis.com
Adding local repo with URL: http://127.0.0.1:8879/charts
$HELM_HOME has been configured at /root/.helm.

Tiller (the Helm server-side component) has been installed into your Kubernetes Cluster.

Please note: by default, Tiller is deployed with an insecure 'allow unauthenticated users' policy.
To prevent this, run `helm init` with the --tiller-tls-verify flag.
For more information on securing your installation see: https://docs.helm.sh/using_helm/#securing-your-helm-installation
Happy Helming!

これにより、 + kube-system`名前空間に + tiller`ポッドが作成されます。 また、 + $ HOME +`ディレクトリに `+ .helm +`デフォルトリポジトリを作成し、 `+ https:// kubernetes-charts.storage.googleapis.com +`にデフォルトのHelm安定チャートリポジトリを設定し、ローカルにHelmリポジトリを設定します+ http://127.0.0.1:8879 / charts +`。

+ tiller`ポッドが + kube-system`名前空間で実行されていることを確認するには、次のコマンドを入力します。

kubectl --namespace kube-system get pods

次の出力に示すように、ポッドのリストに、「+ tiller-deploy +」が表示されます。

OutputNAME                                    READY   STATUS    RESTARTS   AGE
etcd-minikube                           1/1     Running   0          2h
kube-addon-manager-minikube             1/1     Running   0          2h
kube-apiserver-minikube                 1/1     Running   0          2h
kube-controller-manager-minikube        1/1     Running   0          2h
kube-dns-86f4d74b45-rjql8               3/3     Running   0          2h
kube-proxy-dv268                        1/1     Running   0          2h
kube-scheduler-minikube                 1/1     Running   0          2h
kubernetes-dashboard-5498ccf677-wktkl   1/1     Running   0          2h
storage-provisioner                     1/1     Running   0          2h

`+ tiller `ポッドのステータスが ` Running +`の場合、Helmに代わってクラスター内からKubernetesアプリケーションを管理できるようになりました。

Helmアプリケーション全体が動作していることを確認するには、HelmパッケージリポジトリでMongoDBなどのアプリケーションを検索します。

helm search mongodb

出力には、検索用語に適合する可能性のあるアプリケーションのリストが表示されます。

OutputNAME                                    CHART VERSION   APP VERSION     DESCRIPTION
stable/mongodb                          5.4.0           4.0.6           NoSQL document-oriented database that stores JSON-like do...
stable/mongodb-replicaset               3.9.0           3.6             NoSQL document-oriented database that stores JSON-like do...
stable/prometheus-mongodb-exporter      1.0.0           v0.6.1          A Prometheus exporter for MongoDB metrics
stable/unifi                            0.3.1           5.9.29          Ubiquiti Network's Unifi Controller

KubernetesクラスターにHelmをインストールしたので、サンプルHelmチャートを作成し、そこからアプリケーションをデプロイすることにより、パッケージマネージャーの詳細を学ぶことができます。

ステップ3-チャートの作成とHelmを使用したアプリケーションのデプロイ

Helmパッケージマネージャーでは、個々のパッケージは_charts_と呼ばれます。 チャート内では、一連のファイルがアプリケーションを定義します。アプリケーションは、ポッドから構造化されたフルスタックアプリまで複雑さが異なります。 Helmリポジトリからチャートをダウンロードするか、 `+ helm create +`コマンドを使用して独自のチャートを作成できます。

Helmの機能をテストするには、次のコマンドで「+ demo +」という名前の新しいHelmチャートを作成します。

helm create demo

ホームディレクトリには、「+ demo +」という新しいディレクトリがあり、その中に独自のチャートテンプレートを作成および編集できます。

`+ demo `ディレクトリに移動し、 ` ls +`を使用してその内容を一覧表示します。

cd demo
ls

次のファイルとディレクトリが `+ demo +`にあります。

demo

charts  Chart.yaml  templates  values.yaml

テキストエディターを使用して、 `+ Chart.yaml +`ファイルを開きます:

nano Chart.yaml

内部には、次の内容があります。

demo / Chart.yaml

apiVersion: v1
appVersion: "1.0"
description: A Helm chart for Kubernetes
name: demo
version: 0.1.0

この「+ Chart.yaml 」ファイルには、「 apiVersion 」などのフィールドがあります。これは常に「 v1 」である必要があり、「 description 」は「 demo 」とは何か、「 name +」チャートの 、およびHelmがリリースマーカーとして使用する + version + `番号。 ファイルの調査が完了したら、テキストエディターを閉じます。

次に、 `+ values.yaml +`ファイルを開きます:

nano values.yaml

このファイルには、次の内容が含まれています。

demo / values.yaml

# Default values for demo.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.

replicaCount: 1

image:
 repository: nginx
 tag: stable
 pullPolicy: IfNotPresent

nameOverride: ""
fullnameOverride: ""

service:
 type: ClusterIP
 port: 80

ingress:
 enabled: false
 annotations: {}
   # kubernetes.io/ingress.class: nginx
   # kubernetes.io/tls-acme: "true"
 paths: []
 hosts:
   - chart-example.local
 tls: []
 #  - secretName: chart-example-tls
 #    hosts:
 #      - chart-example.local

resources: {}
 # We usually recommend not to specify default resources and to leave this as a conscious
 # choice for the user. This also increases chances charts run on environments with little
 # resources, such as Minikube. If you do want to specify resources, uncomment the following
 # lines, adjust them as necessary, and remove the curly braces after 'resources:'.
 # limits:
 #  cpu: 100m
 #  memory: 128Mi
 # requests:
 #  cpu: 100m
 #  memory: 128Mi

nodeSelector: {}

tolerations: []

affinity: {}

`+ values.yaml `の内容を変更することにより、チャート開発者はチャートで定義されたアプリケーションのデフォルト値を提供し、レプリカ数、画像ベース、イングレスアクセス、シークレット管理などを制御できます。 チャートユーザーは、 ` helm install `を使用して、カスタムYAMLファイルでこれらのパラメーターに独自の値を提供できます。 ユーザーがカスタム値を提供すると、これらの値はグラフの ` values.yaml +`ファイルの値を上書きします。

+ values.yaml`ファイルを閉じて、次のコマンドで + templates`ディレクトリの内容を一覧表示します:

ls templates

ここには、チャートのさまざまな側面を制御できるさまざまなファイルのテンプレートがあります。

テンプレート

deployment.yaml  _helpers.tpl  ingress.yaml  NOTES.txt  service.yaml  tests

`+ demo `チャートを確認したので、 ` demo +`をインストールしてHelmチャートのインストールを試すことができます。 次のコマンドでホームディレクトリに戻ります。

cd

+ helm install`で + web`という名前で `+ demo`ヘルムチャートをインストールします。

helm install --name  ./demo

次の出力が得られます。

OutputNAME:   web
LAST DEPLOYED: Wed Feb 20 20:59:48 2019
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/Service
NAME      TYPE       CLUSTER-IP     EXTERNAL-IP  PORT(S)  AGE
web-demo  ClusterIP  10.100.76.231  <none>       80/TCP   0s

==> v1/Deployment
NAME      DESIRED  CURRENT  UP-TO-DATE  AVAILABLE  AGE
web-demo  1        0        0           0          0s

==> v1/Pod(related)
NAME                       READY  STATUS             RESTARTS  AGE
web-demo-5758d98fdd-x4mjs  0/1    ContainerCreating  0         0s


NOTES:
1. Get the application URL by running these commands:
 export POD_NAME=$(kubectl get pods --namespace default -l "app.kubernetes.io/name=demo,app.kubernetes.io/instance=web" -o jsonpath="{.items[0].metadata.name}")
 echo "Visit http://127.0.0.1:8080 to use your application"
 kubectl port-forward $POD_NAME 8080:80

この出力では、アプリケーションの「+ STATUS」に加えて、クラスター内の関連リソースのリストが見つかります。

次に、次のコマンドを使用して、 `+ demo +`ヘルムチャートによって作成されたデプロイメントを一覧表示します。

kubectl get deploy

これにより、アクティブなデプロイメントをリストする出力が生成されます。

OutputNAME       DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
web-demo   1         1         1            1           4m

コマンド `+ kubectl get pods `でポッドを一覧表示すると、 ` web +`アプリケーションを実行しているポッドが表示され、次のようになります。

OutputNAME                        READY   STATUS    RESTARTS   AGE
web-demo-5758d98fdd-nbkqd   1/1     Running   0          4m

Helmチャートの変更がアプリケーションのさまざまなバージョンをリリースする方法を示すには、テキストエディターで「+ demo / values.yaml 」を開き、「 replicaCount:」を「+3」と「+ image:tag」に変更します:+ から + stable + から + latest + `へ。 次のコードブロックでは、変更が強調表示された状態で、変更が完了した後のYAMLファイルの外観を確認できます。

demo / values.yaml

# Default values for demo.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.

replicaCount:

image:
 repository: nginx
 tag:
 pullPolicy: IfNotPresent

nameOverride: ""
fullnameOverride: ""

service:
 type: ClusterIP
 port: 80
. . .

ファイルを保存して終了します。

この新しいバージョンの `+ web +`アプリケーションをデプロイする前に、次のコマンドを使用してHelmリリースをリストします。

helm list

前に作成した1つのデプロイメントとともに、次の出力を受け取ります。

OutputNAME    REVISION        UPDATED                         STATUS          CHART           APP VERSION     NAMESPACE

`+ REVISION `が ` 1 `としてリストされており、これが ` web +`アプリケーションの最初のリビジョンであることを示しています。

`+ demo / values.yaml `に加えられた最新の変更で ` web +`アプリケーションをデプロイするには、次のコマンドでアプリケーションをアップグレードします:

helm upgrade web ./demo

次に、Helmリリースを再度リストします。

helm list

次の出力が表示されます。

OutputNAME    REVISION        UPDATED                         STATUS          CHART           APP VERSION     NAMESPACE
web                    Wed Feb 20 21:18:12 2019        DEPLOYED        demo-0.1.0      1.0             default

`+ REVISION `が ` 2 +`に変更され、これが2番目のリビジョンであることを示しています。

`+ web +`のHelmリリースの履歴を見つけるには、次を使用します:

helm history web

これにより、 `+ web +`アプリケーションの両方のリビジョンが表示されます。

出力

REVISION        UPDATED                         STATUS          CHART           DESCRIPTION
1               Wed Feb 20 20:59:48 2019        SUPERSEDED      demo-0.1.0      Install complete
2               Wed Feb 20 21:18:12 2019        DEPLOYED        demo-0.1.0      Upgrade complete

アプリケーションをリビジョン「1」にロールバックするには、次のコマンドを入力します。

helm rollback web 1

これにより、次の出力が生成されます。

OutputRollback was a success! Happy Helming!

次に、Helmのリリース履歴を表示します。

helm history web

次のリストが表示されます。

OutputREVISION        UPDATED                         STATUS          CHART           DESCRIPTION
1               Wed Feb 20 20:59:48 2019        SUPERSEDED      demo-0.1.0      Install complete
2               Wed Feb 20 21:18:12 2019        SUPERSEDED      demo-0.1.0      Upgrade complete
3               Wed Feb 20 21:28:48 2019                demo-0.1.0      Rollback to 1

`+ web `アプリケーションをロールバックすることで、リビジョン ` 1 `と同じ設定を持つ3番目のリビジョンを作成しました。 ` STATUS `の下にある ` DEPLOYED +`アイテムを見つけることで、いつどのリビジョンがアクティブであるかを知ることができます。

次のセクションの準備をするために、 + helm delete`コマンドで + web`リリースを削除してテスト領域をクリーンアップします:

helm delete web

Helmのリリース履歴をもう一度調べます。

helm history web

次の出力が表示されます。

OutputREVISION        UPDATED                         STATUS          CHART           DESCRIPTION
1               Wed Feb 20 20:59:48 2019        SUPERSEDED      demo-0.1.0      Install complete
2               Wed Feb 20 21:18:12 2019        SUPERSEDED      demo-0.1.0      Upgrade complete
3               Wed Feb 20 21:28:48 2019                 demo-0.1.0      Deletion complete

「+ REVISION 3+」の「+ STATUS 」が「 DELETED 」に変更され、デプロイされた「 web 」のインスタンスが削除されたことを示します。 ただし、これによりリリースは削除されますが、ストアからは削除されません。 リリースを完全に削除するには、 `-purge`フラグを指定して` + helm delete`コマンドを実行します。

helm delete web --purge

このステップでは、Helmを使用してKubernetesのアプリケーションリリースを管理しました。 Helmをさらに学習したい場合は、https://www.digitalocean.com/community/tutorials/an-introduction-to-helm-the-package-manager-for-kubernetes [Helmの紹介、 Kubernetesのパッケージマネージャー]チュートリアル、または公式のhttps://docs.helm.sh/helm/[Helm documentation]を確認してください。

次に、 + jx + CLIを使用してCI / CD対応Kubernetesクラスターを作成し、パイプライン自動化ツールJenkins Xをセットアップしてテストします。

ステップ4-Jenkins X環境のセットアップ

Jenkins Xを使用すると、パイプライン自動化とCI / CDソリューションが組み込まれた状態でKubernetesクラスターをゼロから作成できます。 + jx + CLIツールをインストールすることにより、アプリケーションのリリース、Dockerイメージ、およびHelmチャートを効率的に管理できるだけでなく、GitHubの環境全体でアプリケーションを自動的にプロモートできます。

`+ jx +`を使用してクラスターを作成するため、最初に、すでにあるMinikubeクラスターを削除する必要があります。 これを行うには、次のコマンドを使用します。

minikube delete

これにより、シミュレートされたローカルのKuberneteクラスターが削除されますが、Minikubeを最初にインストールしたときに作成されたデフォルトのディレクトリは削除されません。 これらをマシンから削除するには、次のコマンドを使用します。

rm -rf ~/.kube
rm -rf ~/.minikube
rm -rf /etc/kubernetes/*
rm -rf /var/lib/minikube/*

マシンからMinikubeを完全にクリアしたら、Jenkins Xバイナリのインストールに進むことができます。

最初に、公式のhttps://github.com/jenkins-x[Jenkins X GitHubリポジトリ]から `+ curl `コマンドで圧縮された ` jx `ファイルをダウンロードし、 ` tar +`コマンドで解凍します。

curl -L https://github.com/jenkins-x/jx/releases/download/v1.3.781/jx-linux-amd64.tar.gz | tar xzv

次に、ダウンロードした + js`ファイルを + / usr / local / bin`の実行可能パスに移動します。

mv jx /usr/local/bin

Jenkins Xには、Kubernetesクラスター内で実行されるDockerレジストリが付属しています。 これは内部要素であるため、自己署名証明書などのセキュリティ対策がプログラムに問題を引き起こす可能性があります。 これを修正するには、ローカルIP範囲に安全でないレジストリを使用するようにDockerを設定します。 これを行うには、ファイル `+ / etc / docker / daemon.json`を作成し、テキストエディターで開きます。

nano /etc/docker/daemon.json

ファイルに次の内容を追加します。

/etc/docker/daemon.json

{
 "insecure-registries" : ["0.0.0.0/0"]
}

ファイルを保存して終了します。 これらの変更を有効にするには、次のコマンドでDockerサービスを再起動します。

systemctl restart docker

安全でないレジストリでDockerを設定したことを確認するには、次のコマンドを使用します。

docker info

出力の最後に、次の強調表示された行が表示されます。

OutputContainers: 0
Running: 0
Paused: 0
Stopped: 0
Images: 15
Server Version: 18.06.1-ce
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: true

. . .

Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:

127.0.0.0/8
Live Restore Enabled: false

Jenkins XをダウンロードしてDockerレジストリを設定したら、 + jx + CLIツールを使用してCI / CD機能を備えたMinikube Kubernetesクラスターを作成します。

jx create cluster minikube --cpu=5 --default-admin-password=admin --vm-driver=none --memory=13314

ここでは、Minikubeを使用してKubernetesクラスターを作成しています。フラグ「-cpu = 5 +」を使用して5 CPUを設定し、「-memory = 13314 」を使用してクラスターに13314 MBのメモリを割り当てます。 Jenkins Xは堅牢ですが大きなプログラムであるため、これらの仕様により、このデモでJenkins Xが問題なく動作することが保証されます。 また、 `-default-admin-password = admin `を使用してJenkins Xパスワードを ` admin `として設定し、 `-vm-driver = none +`を使用してクラスターをローカルで設定します。ステップ1。

Jenkins Xがクラスターをスピンアップすると、クラスターのパラメーターを設定し、本番環境を管理するためにGitHubと通信する方法を決定するプロセス全体を通して、さまざまな時点でさまざまなプロンプトが表示されます。

最初に、次のプロンプトが表示されます。

Output? disk-size (MB) 150GB

続行するには、「+ ENTER」を押します。 次に、gitで使用する名前、gitで使用するメールアドレス、およびGitHubユーザー名の入力を求められます。 プロンプトが表示されたらこれらのそれぞれを入力し、「+ ENTER」を押します。

次に、Jenkins XはGitHub APIトークンの入力を求めます:

OutputTo be able to create a repository on GitHub we need an API Token
Please click this URL

Then COPY the token and enter in into the form below:

? API Token:

ここにトークンを入力するか、前のコードブロックで強調表示されたURLを使用して、適切な権限で新しいトークンを作成します。

次に、ジェンキンスXは尋ねます:

Output? Do you wish to use GitHub as the pipelines Git server: (Y/n)

? Do you wish to use  as the pipelines Git user for GitHub server: (Y/n)

両方の質問に「+ Y +」を入力します。

この後、Jenkins Xは次の質問に答えるよう促します。

Output? Select Jenkins installation type:   [Use arrows to move, type to filter]
>Static Master Jenkins
 Serverless Jenkins

? Pick workload build pack:   [Use arrows to move, type to filter]
> Kubernetes Workloads: Automated CI+CD with GitOps Promotion
 Library Workloads: CI+Release but no CD

前者については、「+ Static Master Jenkins 」を選択し、後者については「 Kubernetesワークロード:GitOps Promotion +を使用したCI + CDの自動化」を選択します。 環境リポジトリの組織を選択するように求められたら、GitHubユーザー名を選択します。

最後に、インストールが成功したことを確認し、Jenkins X管理者パスワードを提供する次の出力を受け取ります。

OutputCreating GitHub webhook for /environment-horsehelix-production for url http://jenkins.jx..nip.io/github-webhook/

Jenkins X installation completed successfully


       ********************************************************

            NOTE: Your admin password is:

       ********************************************************



Your Kubernetes context is now set to the namespace: jx
To switch back to your original namespace use: jx namespace default
For help on switching contexts see: https://jenkins-x.io/developing/kube-context/

To import existing projects into Jenkins:       jx import
To create a new Spring Boot microservice:       jx create spring -d web -d actuator
To create a new microservice from a quickstart: jx create quickstart

次に、 `+ js get`コマンドを使用して、アプリケーションに関する情報を表示するURLのリストを受信します。

jx get urls

このコマンドは、次のようなリストを生成します。

Name                      URL
jenkins                   http://jenkins.jx..nip.io
jenkins-x-chartmuseum     http://chartmuseum.jx..nip.io
jenkins-x-docker-registry http://docker-registry.jx..nip.io
jenkins-x-monocular-api   http://monocular.jx..nip.io
jenkins-x-monocular-ui    http://monocular.jx..nip.io
nexus                     http://nexus.jx..nip.io

URLを使用して、ブラウザにアドレスを入力し、ユーザー名とパスワードを入力することにより、UIを介してCI / CD環境に関するJenkins Xデータを表示できます。 この場合、これは両方の「管理者」になります。

次に、名前空間 + jx ++ jx-staging +、および `+ jx-production +`のサービスアカウントに管理者権限があることを確認するには、次のコマンドでRBACポリシーを変更します。

kubectl create clusterrolebinding jx-staging1 --clusterrole=cluster-admin --user=admin --user=expose --group=system:serviceaccounts --serviceaccount=jx-staging:expose --namespace=jx-staging
kubectl create clusterrolebinding jx-staging2 --clusterrole=cluster-admin --user=admin --user=expose --group=system:serviceaccounts --serviceaccount=jx-staging:default --namespace=jx-staging
kubectl create clusterrolebinding jx-production1 --clusterrole=cluster-admin --user=admin --user=expose --group=system:serviceaccounts --serviceaccount=jx-production:expose --namespace=jx-productions
kubectl create clusterrolebinding jx-production2 --clusterrole=cluster-admin --user=admin --user=expose --group=system:serviceaccounts --serviceaccount=jx-production:default --namespace=jx-productions
kubectl create clusterrolebinding jx-binding1 --clusterrole=cluster-admin --user=admin --user=expose --group=system:serviceaccounts --serviceaccount=jx:expose --namespace=jx
kubectl create clusterrolebinding jx-binding2 --clusterrole=cluster-admin --user=admin --user=expose --group=system:serviceaccounts --serviceaccount=jx:default --namespace=jx

Jenkins Xの機能が組み込まれたローカルKubernetesクラスターを作成したので、プラットフォームでアプリケーションを作成して、CI / CD機能をテストし、Jenkins Xパイプラインを体験できます。

手順5-Jenkins X環境でのテストアプリケーションの作成

KubernetesクラスターにJenkins X環境をセットアップすると、テストパイプラインの自動化に役立つCI / CDインフラストラクチャが整います。 この手順では、動作中のJenkins Xパイプラインにテストアプリケーションをセットアップして、これを試してみます。

デモンストレーションのために、このチュートリアルではhttps://cloudyuga.guru/explore[CloudYuga]チームによって作成されたサンプルRSVPアプリケーションを使用します。 このアプリケーションは、他のウェビナー資料とともに、https://github.com/do-community/rsvpapp [DO-Community GitHub repository]で見つけることができます。

まず、次のコマンドを使用して、リポジトリからサンプルアプリケーションのクローンを作成します。

git clone https://github.com/do-community/rsvpapp.git

リポジトリのクローンを作成したら、 `+ rsvpapp +`ディレクトリに移動して、gitファイルを削除します。

cd rsvpapp
rm -r .git/

新しいアプリケーション用にgitリポジトリとJenkins Xプロジェクトを初期化するには、 `+ jx create `を使用してスクラッチまたはテンプレートから開始するか、 ` jx import +`を使用してローカルプロジェクトまたはgitリポジトリから既存のアプリケーションをインポートします。 このチュートリアルでは、アプリケーションのホームディレクトリ内から次のコマンドを実行して、サンプルRSVPアプリケーションをインポートします。

jx import

Jenkins Xは、GitHubのユーザー名、gitの初期化、コミットメッセージ、組織、およびリポジトリの名前の入力を求めます。 yesと答えてgitを初期化し、残りのプロンプトに個々のGitHub情報と設定を提供します。 Jenkins Xがアプリケーションをインポートすると、アプリケーションのホームディレクトリにHelmチャートとJenkinsfileが作成されます。 これらのチャートとJenkinsfileは、要件に応じて変更できます。

サンプルRSVPアプリケーションはコンテナのポート「5000」で実行されるため、これに合わせて「+ charts / rsvpapp / values.yaml 」ファイルを変更します。 テキストエディターで ` charts / rsvpapp / values.yaml +`を開きます。

nano charts/rsvpapp/values.yaml

この「+ values.yaml 」ファイルで、「 service:internalPort:」を「+5000」に設定します。 この変更を行うと、ファイルは次のようになります。

charts / rsvpapp / values.yaml

# Default values for python.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.
replicaCount: 1
image:
 repository: draft
 tag: dev
 pullPolicy: IfNotPresent
service:
 name: rsvpapp
 type: ClusterIP
 externalPort: 80
 internalPort:
 annotations:
   fabric8.io/expose: "true"
   fabric8.io/ingress.annotations: "kubernetes.io/ingress.class: nginx"
resources:
 limits:
   cpu: 100m
   memory: 128Mi
 requests:
   cpu: 100m
   memory: 128Mi
ingress:
 enabled: false

ファイルを保存して終了します。

次に、 `+ charts / preview / requirements.yaml `をアプリケーションに合わせて変更します。 ` requirements.yaml `は、開発者がチャートの場所と目的のバージョンとともにチャートの依存関係を宣言できるYAMLファイルです。 サンプルアプリケーションではhttps://www.mongodb.com/[MongoDB]をデータベースの目的に使用しているため、 ` charts / preview / requirements.yaml +`ファイルを変更して、MongoDBを依存関係としてリストする必要があります。 次のコマンドを使用して、テキストエディターでファイルを開きます。

nano charts/preview/requirements.yaml

次のコードブロックで強調表示されているように、 `+ alias:cleanup `エントリの後に ` mongodb-replicaset +`エントリを追加して、ファイルを編集します。

charts / preview / requirements.yaml

# !! File must end with empty line !!
dependencies:
- alias: expose
 name: exposecontroller
 repository: http://chartmuseum.jenkins-x.io
 version: 2.3.92
- alias: cleanup
 name: exposecontroller
 repository: http://chartmuseum.jenkins-x.io
 version: 2.3.92




 # !! "alias: preview" must be last entry in dependencies array !!
 # !! Place custom dependencies above !!
- alias: preview
 name: rsvpapp
 repository: file://../rsvpapp

ここでは、 `+ preview `チャートの依存関係として ` mongodb-replicaset +`チャートを指定しました。

次に、 `+ rsvpapp `チャートに対してこのプロセスを繰り返します。 ` charts / rsvpapp / requirements.yaml +`ファイルを作成し、テキストエディターで開きます。

nano charts/rsvpapp/requirements.yaml

ファイルが開いたら、次の行を追加し、移入された行の前後に1行の空きスペースがあることを確認します。

charts / rsvpapp / requirements.yaml

dependencies:
- name: mongodb-replicaset
 repository: https://kubernetes-charts.storage.googleapis.com/
 version: 3.5.5

これで、 `+ rsvpapp `チャートの依存関係として ` mongodb-replicaset +`チャートを指定しました。

次に、サンプルRSVPアプリケーションのフロントエンドをMongoDBバックエンドに接続するには、 `+ charts / rsvpapp / templates / `の ` deployment.yaml `ファイルに ` MONGODB_HOST +`環境変数を追加します。 このファイルをテキストエディターで開きます。

nano charts/rsvpapp/templates/deployment.yaml

ファイルの上部にある1つの空白行と、ファイルの下部にある2つの空白行に加えて、次の強調表示された行をファイルに追加します。 YAMLファイルが機能するには、これらの空白行が必要であることに注意してください。

charts / rsvpapp / templates / deployment.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
 name: {{ template "fullname" . }}
 labels:
   draft: {{ default "draft-app" .Values.draft }}
   chart: "{{ .Chart.Name }}-{{ .Chart.Version | replace "+" "_" }}"
spec:
 replicas: {{ .Values.replicaCount }}
 template:
   metadata:
     labels:
       draft: {{ default "draft-app" .Values.draft }}
       app: {{ template "fullname" . }}
{{- if .Values.podAnnotations }}
     annotations:
{{ toYaml .Values.podAnnotations | indent 8 }}
{{- end }}
   spec:
     containers:
     - name: {{ .Chart.Name }}
       image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"



       imagePullPolicy: {{ .Values.image.pullPolicy }}
       ports:
       - containerPort: {{ .Values.service.internalPort }}
       resources:
{{ toYaml .Values.resources | indent 12 }}

これらの変更により、HelmはデータベースとしてMongoDBを使用してアプリケーションをデプロイできるようになります。

次に、アプリケーションのホームディレクトリからファイルを開いて、Jenkins Xによって生成された `+ Jenkinsfile +`を調べます。

nano Jenkinsfile

この `+ Jenkinsfile +`は、アプリケーションのバージョンをGitHubリポジトリにコミットするたびにトリガーされるパイプラインを定義します。 パイプラインがトリガーされるたびにテストがトリガーされるようにコードテストを自動化する場合は、このドキュメントにテストを追加します。

これを実証するには、「+ stage( ‘CI Build and push snapshot’)+ 」および「+ stage( 'Build Release')+」の下の「+ sh “python -m unittest” + 次の行が強調表示された `+ Jenkinsfile +

/ rsvpapp / Jenkinsfile

. . .
 stages {
   stage('CI Build and push snapshot') {
     when {
       branch 'PR-*'
     }
     environment {
       PREVIEW_VERSION = "0.0.0-SNAPSHOT-$BRANCH_NAME-$BUILD_NUMBER"
       PREVIEW_NAMESPACE = "$APP_NAME-$BRANCH_NAME".toLowerCase()
       HELM_RELEASE = "$PREVIEW_NAMESPACE".toLowerCase()
     }
     steps {
       container('python') {


         sh "export VERSION=$PREVIEW_VERSION && skaffold build -f skaffold.yaml"
         sh "jx step post build --image $DOCKER_REGISTRY/$ORG/$APP_NAME:$PREVIEW_VERSION"
         dir('./charts/preview') {
           sh "make preview"
           sh "jx preview --app $APP_NAME --dir ../.."
         }
       }
     }
   }
   stage('Build Release') {
     when {
       branch 'master'
     }
     steps {
       container('python') {

         // ensure we're not on a detached head
         sh "git checkout master"
         sh "git config --global credential.helper store"
         sh "jx step git credentials"

         // so we can retrieve the version in later steps
         sh "echo \$(jx-release-version) > VERSION"
         sh "jx step tag --version \$(cat VERSION)"


         sh "export VERSION=`cat VERSION` && skaffold build -f skaffold.yaml"
         sh "jx step post build --image $DOCKER_REGISTRY/$ORG/$APP_NAME:\$(cat VERSION)"
       }
     }
   }
. . .

追加された行により、Jenkins Xパイプラインは依存関係をインストールし、アプリケーションに変更をコミットするたびにPythonテストを実行します。

サンプルのRSVPアプリケーションを変更したので、次のコマンドを使用してこれらの変更をGitHubにコミットしてプッシュします。

git add *
git commit -m update
git push

これらの変更をGitHubにプッシュすると、アプリケーションの新しいビルドがトリガーされます。 `+ http:// jenkins.jx..nip.io +`に移動してJenkins UIを開き、ユーザー名とパスワードに「admin」と入力すると、新しいビルドに関する情報が表示されます。 ページの左側にあるメニューから[ビルド履歴]をクリックすると、コミットされたビルドの履歴が表示されます。 ビルドの横にある青いアイコンをクリックして、左側のメニューから「コンソール出力」を選択すると、パイプラインの自動化されたステップのコンソール出力が表示されます。 この出力の最後までスクロールすると、次のメッセージが表示されます。

Output. . .
Finished: SUCCESS

これは、アプリケーションがカスタマイズされたテストに合格し、正常にデプロイされたことを意味します。

Jenkins Xはアプリケーションリリースをビルドすると、アプリケーションを `+ staging +`環境にプロモートします。 アプリケーションが実行されていることを確認するには、次のコマンドを使用してKubernetesクラスターで実行されているアプリケーションを一覧表示します。

jx get app

次のような出力が表示されます。

OutputAPPLICATION STAGING PODS URL
rsvpapp     0.0.2   1/1  http://rsvpapp.jx-staging..nip.io

このことから、Jenkins Xがアプリケーションをバージョン+。0.0.2+として ` jx-staging +`環境にデプロイしていることがわかります。 出力には、アプリケーションへのアクセスに使用できるURLも表示されます。 このURLにアクセスすると、サンプルのRSVPアプリケーションが表示されます。

image:https://assets.digitalocean.com/articles/cart_64885/Sample_App_jx-staging.png [ステージング環境のサンプルRSVPアプリケーション]

次に、次のコマンドを使用してアプリケーションのアクティビティをチェックアウトします。

jx get activity -f rsvpapp

次のような出力が表示されます。

OutputSTEP                                        STARTED      AGO DURATION STATUS
/rsvpappv/master #1    3h42m23s    4m51s Succeeded Version: 0.0.1
 Checkout Source                          3h41m52s       6s Succeeded
 CI Build and push snapshot               3h41m46s          NotExecuted
 Build Release                            3h41m46s      56s Succeeded
 Promote to Environments                  3h40m50s    3m17s Succeeded
 Promote: staging                         3h40m29s    2m36s Succeeded
   PullRequest                            3h40m29s    1m16s Succeeded  PullRequest: https://github.com//environment-horsehelix-staging/pull/1 Merge SHA: dc33d3747abdacd2524e8c22f0b5fbb2ac3f6fc7
   Update                                 3h39m13s    1m20s Succeeded  Status: Success at: http://jenkins.jx..nip.io/job//job/environment-horsehelix-staging/job/master/2/display/redirect
   Promoted                               3h39m13s    1m20s Succeeded  Application is at: http://rsvpapp.jx-staging..nip.io
 Clean up                                 3h37m33s       1s Succeeded
/rsvpappv/master #2      28m37s    5m57s Succeeded Version: 0.0.2
 Checkout Source                            28m18s       4s Succeeded
 CI Build and push snapshot                 28m14s          NotExecuted
 Build Release                              28m14s      56s Succeeded
 Promote to Environments                    27m18s    4m38s Succeeded
 Promote: staging                           26m53s     4m0s Succeeded
   PullRequest                              26m53s     1m4s Succeeded  PullRequest: https://github.com//environment-horsehelix-staging/pull/2 Merge SHA: 976bd5ad4172cf9fd79f0c6515f5006553ac6611
   Update                                   25m49s    2m56s Succeeded  Status: Success at: http://jenkins.jx..nip.io/job//job/environment-horsehelix-staging/job/master/3/display/redirect
   Promoted                                 25m49s    2m56s Succeeded  Application is at: http://rsvpapp.jx-staging..nip.io
 Clean up                                   22m40s       0s Succeeded

ここでは、 `+ -f rsvpapp +`を使用してフィルターを適用することにより、RSVPアプリケーションのJenkins Xアクティビティを取得しています。

次に、次のコマンドを使用して、 `+ jx-staging +`名前空間で実行されているポッドを一覧表示します。

kubectl get pod -n jx-staging

次のような出力が表示されます。

NAME                                 READY     STATUS    RESTARTS   AGE
jx-staging-mongodb-replicaset-0      1/1       Running   0          6m
jx-staging-mongodb-replicaset-1      1/1       Running   0          6m
jx-staging-mongodb-replicaset-2      1/1       Running   0          5m
jx-staging-rsvpapp-c864c4844-4fw5z   1/1       Running   0          6m

この出力は、アプリケーションが `+ jx-staging +`名前空間で実行されており、バックエンドMongoDBデータベースの3つのポッドとともに、YAMLファイルに以前に加えた変更を順守していることを示しています。

Jenkins Xパイプラインを介してテストアプリケーションを実行したので、このアプリケーションを実稼働環境に昇格してみてください。

手順6-テストアプリケーションを別の名前空間に昇格させる

このデモンストレーションを完了するには、サンプルRSVPアプリケーションを「+ jx-production +」名前空間に昇格させて、CI / CDプロセスを完了します。

まず、次のコマンドで `+ jx promote +`を使用します。

jx promote rsvpapp --version=0.0.2 --env=production

これにより、 `+ version = 0.0.2 `で実行されている ` rsvpapp +`アプリケーションが本番環境に昇格します。 ビルドプロセス全体を通して、Jenkins XはGitHubアカウント情報の入力を求めます。 表示された個々の応答でこれらのプロンプトに答えてください。

昇格が成功したら、アプリケーションのリストを確認します。

jx get app

次のような出力が表示されます。

OutputAPPLICATION STAGING PODS URL                                             PRODUCTION PODS URL
rsvpapp     0.0.2   1/1  http://rsvpapp.jx-staging..nip.io 0.0.2      1/1  http://rsvpapp.jx-production..nip.io

この「+ PRODUCTION」情報により、Jenkins Xが「+ rsvp app」を本番環境に昇格させたことを確認できます。 さらに確認するには、ブラウザの本番URL `+ http:// rsvpapp.jx-production..nip.io +`にアクセスしてください。 「プロダクション」から実行されているのではなく、動作中のアプリケーションが表示されるはずです。

image:https://assets.digitalocean.com/articles/cart_64885/Sample_App_jx-production.png [本番環境のサンプルRSVPアプリケーション]

最後に、ポッドを `+ jx-production +`名前空間にリストします。

kubectl get pod -n jx-production

`+ rsvpapp +`とMongoDBバックエンドポッドが次のネームスペースで実行されていることがわかります。

NAME                                     READY     STATUS    RESTARTS   AGE
jx-production-mongodb-replicaset-0       1/1       Running   0          1m
jx-production-mongodb-replicaset-1       1/1       Running   0          1m
jx-production-mongodb-replicaset-2       1/1       Running   0          55s
jx-production-rsvpapp-54748d68bd-zjgv7   1/1       Running   0          1m

これは、RSVPサンプルアプリケーションを実稼働環境に正常に昇格させ、CI / CDパイプラインの最後にアプリケーションの実稼働対応デプロイメントをシミュレートしたことを示しています。

結論

このチュートリアルでは、Helmを使用して、シミュレートされたKubernetesクラスター上のパッケージを管理し、Helmチャートをカスタマイズして、独自のアプリケーションをパッケージ化してデプロイしました。 また、KubernetesクラスターにJenkins X環境をセットアップし、CI / CDパイプラインを介して最初から最後までサンプルアプリケーションを実行します。

これで、独自のKubernetesクラスターでCI / CDシステムを構築するときに使用できるこれらのツールの経験ができました。 Helmの詳細については、https://www.digitalocean.com/community/tutorials/an-introduction-to-helm-the-package-manager-for-kubernetes [Helmの概要]をご覧ください。 、Kubernetesのパッケージマネージャー]およびhttps://www.digitalocean.com/community/tutorials/how-to-install-software-on-kubernetes-clusters-with-the-helm-package-manager [ソフトウェアのインストール方法] Helm Package Managerを使用したKubernetes Clustersの記事]。 KubernetesでさらにCI / CDツールを調べるには、このウェビナーシリーズの次のチュートリアルでIstioサービスメッシュについて読むことができます。