[。注意]##
ウェビナーシリーズ
この記事はwebinar series on doing CI/CD with Kubernetesを補足します。 このシリーズでは、Kubernetesで使用できるリリース管理、クラウドネイティブツール、サービスメッシュ、CI / CDツールなど、アプリケーションを構築、テスト、およびデプロイするクラウドネイティブアプローチの方法について説明します。 CI / CDのベストプラクティスをKubernetesとワークフローに統合することに関心のある開発者や企業を支援するように設計されています。
このチュートリアルには、シリーズの第2セッションであるHelmを使用したKubernetesパッケージ管理とJenkins Xを使用したCI / CDの概念とコマンドが含まれています。
[.warning]#Warning:このチュートリアルの手順は、デモンストレーションのみを目的としています。 その結果、本番環境に対応した導入に必要なベストプラクティスとセキュリティ対策に準拠していません。
#
前書き
アプリケーションを展開する際のエラーを減らし、複雑さを整理するために、CI / CDシステムには、パッケージ管理/展開のための堅牢なツールと自動化されたテストを伴うパイプラインが含まれている必要があります。 しかし、現代の本番環境では、クラウドベースのインフラストラクチャの複雑さが増すため、信頼性の高いCI / CD環境をまとめる際に問題が生じる可能性があります。 この問題を解決するために開発された2つのKubernetes固有のツールは、HelmパッケージマネージャーとJenkins Xパイプライン自動化ツールです。
Helmは、Kubernetes用に特別に設計されたパッケージマネージャーであり、Microsoft、Google、Bitnami、およびHelmコントリビューターコミュニティと協力してCloud Native Computing Foundation(CNCF)によって管理されています。 高いレベルで、APTやYUMなどのLinuxシステムパッケージマネージャーと同じ目標を達成します。アプリケーションのインストールと依存関係をバックグラウンドで管理し、複雑さをユーザーから隠します。 しかし、Kubernetesでは、この種の管理の必要性がさらに顕著になります。アプリケーションのインストールには、YAMLファイルの複雑で退屈なオーケストレーションが必要であり、リリースのアップグレードまたはロールバックは、困難から不可能まで可能です。 この問題を解決するために、HelmはKubernetes上で実行され、アプリケーションをchartsと呼ばれる事前構成されたリソースにパッケージ化します。これは、ユーザーが簡単なコマンドで管理できるため、アプリケーションの共有と管理のプロセスがよりユーザーフレンドリーになります。
Jenkins Xは、Kubernetesの生産パイプラインと環境を自動化するために使用されるCI / CDツールです。 Jenkins Xは、Dockerイメージ、Helmチャート、およびJenkins pipeline engineを使用して、リリースとバージョンを自動的に管理し、GitHub上の環境間でアプリケーションをプロモートできます。
CI/CD with Kubernetes seriesのこの2番目の記事では、次の方法でこれら2つのツールをプレビューします。
-
Helmを使用したKubernetesパッケージの管理、作成、展開。
-
Jenkins Xを使用したCI / CDパイプラインの構築。
さまざまなKubernetesプラットフォームでHelmおよびJenkins Xを使用できますが、このチュートリアルでは、ローカル環境にセットアップされたシミュレーションKubernetesクラスターを実行します。 これを行うには、Minikubeを使用します。これは、真のKubernetesクラスターをセットアップしなくても、自分のマシンでKubernetesツールを試すことができるプログラムです。
このチュートリアルの終わりまでに、これらのKubernetesネイティブツールがクラウドアプリケーションのCI / CDシステムの実装にどのように役立つかについての基本的な理解が得られます。
前提条件
このチュートリアルを実行するには、次のものが必要です。
-
16 GB以上のRAMを搭載したUbuntu 16.04サーバー。 このチュートリアルはデモンストレーションのみを目的としているため、コマンドはルートアカウントから実行されます。 Note that the unrestrained privileges of this account do not adhere to production-ready best practices and could affect your system.このため、仮想マシンやDigitalOcean Dropletなどのテスト環境でこれらの手順を実行することをお勧めします。
-
GitHub accountおよびGitHub API token。 このチュートリアルのJenkins Xの部分で入力できるように、このAPIトークンを必ず記録してください。
-
Kubernetesの概念に精通している。 詳細については、記事An Introduction to Kubernetesを参照してください。
[[step-1 -—- creating-a-local-kubernetes-cluster-with-minikube]] ==ステップ1—Minikubeを使用してローカルKubernetesクラスターを作成する
Minikubeを設定する前に、Kubernetesコマンドラインツールkubectl、双方向データ転送リレーsocat、コンテナプログラムDockerなどの依存関係をインストールする必要があります。
まず、システムのパッケージマネージャーがapt-transport-https
を使用して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
[.note]#Note: MinikubeでKubernetesクラスターをシミュレートするには、新しいdocker-ce
リリースではなく、docker.io
パッケージをダウンロードする必要があります。 本番環境に対応した環境では、docker-ce
がより適切な選択になります。これは、公式のDockerリポジトリでより適切に維持されるためです。
#
kubectlをインストールしたので、installing Minikubeに進むことができます。 まず、curl
を使用してプログラムのバイナリをダウンロードします。
curl -Lo minikube https://storage.googleapis.com/minikube/releases/v0.28.0/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サーバーがルートとして安全に実行されなくなります。
[.warning]#Warning: root権限を持つAPIサーバーはローカルホストに無制限にアクセスできるため、パーソナルワークステーションでnone
ドライバーを使用してMinikubeを実行することはお勧めしません。
#
Minikubeを起動したら、次のコマンドを使用してクラスターが実行されていることを確認してください。
minikube status
your_IP_address
の代わりにIPアドレスを使用して、次の出力が表示されます。
minikube: Running
cluster: Running
kubectl: Correctly Configured: pointing to minikube-vm at your_IP_address
Minikubeを使用してシミュレートされたKubernetesクラスターをセットアップしたので、クラスター上にHelmパッケージマネージャーをインストールして構成することにより、Kubernetesパッケージ管理の経験を積むことができます。
[[step-2 -—- setting-up-the-helm-package-manager-on-your-cluster]] ==ステップ2—クラスターでのHelm PackageManagerのセットアップ
Kubernetesクラスターへのアプリケーションのインストールを調整するために、Helmパッケージマネージャーをインストールします。 Helmは、クラスターの外部で実行されるhelm
クライアントと、クラスター内からのアプリケーションリリースを管理するtiller
サーバーで構成されます。 クラスターでHelmを正常に実行するには、両方をインストールして構成する必要があります。
install the Helm binariesにするには、最初にcurl
を使用して、次のinstallation scriptを公式のHelm GitHubリポジトリからget_helm.sh
という名前の新しいファイルにダウンロードします。
curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get > get_helm.sh
このスクリプトにはルートアクセスが必要なため、ファイルの所有者(この場合はroot)が読み取り、書き込み、および実行できるように、get_helm.sh
のアクセス許可を変更します。
chmod 700 get_helm.sh
次に、スクリプトを実行します。
./get_helm.sh
スクリプトが終了すると、helm
が/usr/local/bin/helm
にインストールされ、tiller
が/usr/local/bin/tiller
にインストールされます。
tiller
がインストールされましたが、Kubernetesクラスター内の必要なリソースにアクセスするための適切なロールと権限がまだありません。 これらの役割と権限をtiller
に割り当てるには、tiller
という名前のservice accountを作成する必要があります。 Kubernetesでは、サービスアカウントはポッドで実行されるプロセスのIDを表します。 プロセスは、サービスアカウントを介して認証された後、APIサーバーに接続してクラスターリソースにアクセスできます。 ポッドに特定のサービスアカウントが割り当てられていない場合、デフォルトのサービスアカウントを取得します。 また、tiller
サービスアカウントを承認する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
、admin
を含むsubjects
のリストに割り当てます。 t7)sユーザー、およびsystem:serviceaccounts
グループ。
次に、次のコマンドを使用して、構成をrbac_helm.yaml
にデプロイします。
kubectl apply -f rbac_helm.yaml
tiller
構成がデプロイされたら、Helmを--service-acount
フラグで初期化して、設定したサービスアカウントを使用できるようになります。
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安定チャートリポジトリを構成し、http://127.0.0.1:8879/charts
にローカルHelmリポジトリを構成します。
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-deploy-689d79895f-bggbk 1/1 Running 0 5m
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チャートを作成し、そこからアプリケーションをデプロイすることにより、パッケージマネージャーの詳細を学ぶことができます。
[[step-3 -—- creating-a-chart-and-deploying-an-application-with-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
である必要があり、demo
とは何かに関する追加情報を提供するdescription
です。チャートの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 web ./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 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
Helmチャートによって作成されたデプロイメントを一覧表示します。
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
に変更します。 )sからlatest
。 次のコードブロックでは、変更が強調表示された状態で、変更が完了した後のYAMLファイルの外観を確認できます。
demo/values.yaml
# Default values for demo.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.
replicaCount: 3
image:
repository: nginx
tag: latest
pullPolicy: IfNotPresent
nameOverride: ""
fullnameOverride: ""
service:
type: ClusterIP
port: 80
. . .
ファイルを保存して終了します。
この新しいバージョンのweb
アプリケーションをデプロイする前に、次のコマンドを使用して、Helmリリースを現在の状態で一覧表示します。
helm list
前に作成した1つのデプロイメントとともに、次の出力を受け取ります。
OutputNAME REVISION UPDATED STATUS CHART APP VERSION NAMESPACE
web 1 Wed Feb 20 20:59:48 2019 DEPLOYED demo-0.1.0 1.0 default
REVISION
が1
としてリストされていることに注意してください。これは、これがweb
アプリケーションの最初のリビジョンであることを示しています。
demo/values.yaml
に最新の変更を加えてweb
アプリケーションをデプロイするには、次のコマンドを使用してアプリケーションをアップグレードします。
helm upgrade web ./demo
さて、Helmリリースをもう一度リストします。
helm list
次の出力が表示されます。
OutputNAME REVISION UPDATED STATUS CHART APP VERSION NAMESPACE
web 2 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 DEPLOYED 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 DELETED demo-0.1.0 Deletion complete
REVISION 3
のSTATUS
がDELETED
に変更され、デプロイされたweb
のインスタンスが削除されたことを示します。 ただし、これによりリリースは削除されますが、ストアからは削除されません。 リリースを完全に削除するには、--purge
フラグを指定してhelm delete
コマンドを実行します。
helm delete web --purge
このステップでは、Helmを使用してKubernetesのアプリケーションリリースを管理しました。 Helmについてさらに学習したい場合は、An Introduction to Helm, the Package Manager for Kubernetesチュートリアルを確認するか、公式のHelm documentationを確認してください。
次に、jx
CLIを使用してパイプライン自動化ツールJenkinsXをセットアップしてテストし、CI / CD対応のKubernetesクラスターを作成します。
[[step-4 -—- setting-up-the-jenkins-x-environment]] ==ステップ4— JenkinsX環境のセットアップ
Jenkins Xを使用すると、パイプライン自動化とCI / CDソリューションが組み込まれた状態でKubernetesクラスターをゼロから作成できます。 jx
CLIツールをインストールすることで、GitHubの環境全体でアプリケーションを自動的にプロモートするだけでなく、アプリケーションリリース、Dockerイメージ、Helmチャートを効率的に管理できるようになります。
jx
を使用してクラスターを作成するため、最初に、既存のMinikubeクラスターを削除する必要があります。 これを行うには、次のコマンドを使用します。
minikube delete
これにより、シミュレートされたローカルのKuberneteクラスターが削除されますが、Minikubeを最初にインストールしたときに作成されたデフォルトのディレクトリは削除されません。 これらをマシンから削除するには、次のコマンドを使用します。
rm -rf ~/.kube
rm -rf ~/.minikube
rm -rf /etc/kubernetes/*
rm -rf /var/lib/minikube/*
マシンからMinikubeを完全にクリアしたら、Jenkins Xバイナリのインストールに進むことができます。
まず、curl
コマンドを使用して公式のJenkins X GitHub repositoryから圧縮されたjx
ファイルをダウンロードし、tar
コマンドを使用して解凍します。
curl -L https://github.com/jenkins-x/jx/releases/download/v1.3.781/jx-linux-amd64.tar.gz | tar xzv
次に、ダウンロードしたjx
ファイルを/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:
0.0.0.0/0
127.0.0.0/8
Live Restore Enabled: false
Jenkins XをダウンロードしてDockerレジストリを構成したので、jx
CLIツールを使用して、CI / CD機能を備えたMinikubeKubernetesクラスターを作成します。
jx create cluster minikube --cpu=5 --default-admin-password=admin --vm-driver=none --memory=13314
ここでは、Minikubeを使用してKubernetesクラスターを作成しています。フラグ--cpu=5
は5つのCPUを設定し、--memory=13314
はクラスターに13314MBのメモリを割り当てます。 Jenkins Xは堅牢ですが大きなプログラムであるため、これらの仕様により、このデモでJenkins Xが問題なく動作することが保証されます。 また、手順1で行ったように、--default-admin-password=admin
を使用してJenkins Xパスワードをadmin
として設定し、--vm-driver=none
を使用してクラスターをローカルにセットアップしています。
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 https://github.com/settings/tokens/new?scopes=repo,read:user,read:org,user:email,write:repo_hook,delete_repo
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 your_GitHub_username 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 Workloads: Automated CI+CD with GitOps Promotion
を選択します。 環境リポジトリの組織を選択するように求められたら、GitHubユーザー名を選択します。
最後に、次の出力を受け取ります。これは、インストールが成功したことを確認し、Jenkins X管理者パスワードを提供します。
OutputCreating GitHub webhook for your_GitHub_username/environment-horsehelix-production for url http://jenkins.jx.your_IP_address.nip.io/github-webhook/
Jenkins X installation completed successfully
********************************************************
NOTE: Your admin password is: admin
********************************************************
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
次に、jx get
コマンドを使用して、アプリケーションに関する情報を示すURLのリストを受け取ります。
jx get urls
このコマンドは、次のようなリストを生成します。
Name URL
jenkins http://jenkins.jx.your_IP_address.nip.io
jenkins-x-chartmuseum http://chartmuseum.jx.your_IP_address.nip.io
jenkins-x-docker-registry http://docker-registry.jx.your_IP_address.nip.io
jenkins-x-monocular-api http://monocular.jx.your_IP_address.nip.io
jenkins-x-monocular-ui http://monocular.jx.your_IP_address.nip.io
nexus http://nexus.jx.your_IP_address.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パイプラインを体験できます。
[[step-5 -—- creating-a-test-application-in-your-jenkins-x-environment]] ==ステップ5— JenkinsX環境でのテストアプリケーションの作成
KubernetesクラスターにJenkins X環境をセットアップすると、テストパイプラインの自動化に役立つCI / CDインフラストラクチャが整います。 この手順では、動作中のJenkins Xパイプラインにテストアプリケーションをセットアップして、これを試してみます。
デモンストレーションの目的で、このチュートリアルでは、CloudYugaチームによって作成されたサンプルRSVPアプリケーションを使用します。 このアプリケーションは、他のウェビナー資料とともに、DO-Community GitHub repositoryにあります。
まず、次のコマンドを使用して、リポジトリからサンプルアプリケーションのクローンを作成します。
git clone https://github.com/do-community/rsvpapp.git
リポジトリのクローンを作成したら、rsvpapp
ディレクトリに移動し、gitファイルを削除します。
cd rsvpapp
rm -r .git/
新しいアプリケーション用にgitリポジトリとJenkinsXプロジェクトを初期化するには、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: 5000
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ファイルであり、開発者はチャートの依存関係を、チャートの場所と目的のバージョンとともに宣言できます。 サンプルアプリケーションはデータベースの目的でMongoDBを使用するため、MongoDBを依存関係としてリストするようにcharts/preview/requirements.yaml
ファイルを変更する必要があります。 次のコマンドを使用して、テキストエディターでファイルを開きます。
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
- name: mongodb-replicaset
repository: https://kubernetes-charts.storage.googleapis.com/
version: 3.5.5
# !! "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バックエンドに接続するために、MONGODB_HOST
環境変数をcharts/rsvpapp/templates/
のdeployment.yaml
ファイルに追加します。 このファイルをテキストエディターで開きます。
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 }}"
env:
- name: MONGODB_HOST
value: "mongodb://{{.Release.Name}}-mongodb-replicaset-0.{{.Release.Name}}-mongodb-replicaset,{{.Release.Name}}-mongodb-replicaset-1.{{.Release.Name}}-mongodb-replicaset,{{.Release.Name}}-mongodb-replicaset-2.{{.Release.Name}}-mongodb-replicaset:27017"
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')
の下のsh "python -m unittest"
とJenkinsfile
のstage('Build Release')
を次の強調表示された行に置き換えて、カスタマイズされたテストケースを追加します。
/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 "pip install -r requirements.txt"
sh "python -m pytest tests/test_rsvpapp.py"
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 "pip install -r requirements.txt"
sh "python -m pytest tests/test_rsvpapp.py"
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.your_IP_address.nip.io
に移動し、ユーザー名とパスワードに「admin」と入力してJenkins UIを開くと、新しいビルドに関する情報が表示されます。 ページの左側にあるメニューから[ビルド履歴]をクリックすると、コミットされたビルドの履歴が表示されます。 ビルドの横にある青いアイコンをクリックして、左側のメニューから「コンソール出力」を選択すると、パイプラインの自動化されたステップのコンソール出力が表示されます。 この出力の最後までスクロールすると、次のメッセージが表示されます。
Output. . .
Finished: SUCCESS
これは、アプリケーションがカスタマイズされたテストに合格し、正常にデプロイされたことを意味します。
Jenkins Xがアプリケーションリリースをビルドすると、アプリケーションがstaging
環境にプロモートされます。 アプリケーションが実行されていることを確認するには、次のコマンドを使用してKubernetesクラスターで実行されているアプリケーションを一覧表示します。
jx get app
次のような出力が表示されます。
OutputAPPLICATION STAGING PODS URL
rsvpapp 0.0.2 1/1 http://rsvpapp.jx-staging.your_IP_address.nip.io
このことから、Jenkins Xがアプリケーションをバージョン0.0.2
としてjx-staging
環境にデプロイしたことがわかります。 出力には、アプリケーションへのアクセスに使用できるURLも表示されます。 このURLにアクセスすると、サンプルのRSVPアプリケーションが表示されます。
次に、次のコマンドを使用してアプリケーションのアクティビティをチェックアウトします。
jx get activity -f rsvpapp
次のような出力が表示されます。
OutputSTEP STARTED AGO DURATION STATUS
your_GitHub_username/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/your_GitHub_username/environment-horsehelix-staging/pull/1 Merge SHA: dc33d3747abdacd2524e8c22f0b5fbb2ac3f6fc7
Update 3h39m13s 1m20s Succeeded Status: Success at: http://jenkins.jx.your_IP_address.nip.io/job/your_GitHub_username/job/environment-horsehelix-staging/job/master/2/display/redirect
Promoted 3h39m13s 1m20s Succeeded Application is at: http://rsvpapp.jx-staging.your_IP_address.nip.io
Clean up 3h37m33s 1s Succeeded
your_GitHub_username/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/your_GitHub_username/environment-horsehelix-staging/pull/2 Merge SHA: 976bd5ad4172cf9fd79f0c6515f5006553ac6611
Update 25m49s 2m56s Succeeded Status: Success at: http://jenkins.jx.your_IP_address.nip.io/job/your_GitHub_username/job/environment-horsehelix-staging/job/master/3/display/redirect
Promoted 25m49s 2m56s Succeeded Application is at: http://rsvpapp.jx-staging.your_IP_address.nip.io
Clean up 22m40s 0s Succeeded
ここでは、-f rsvpapp
を使用してフィルターを適用することにより、RSVPアプリケーションのJenkinsXアクティビティを取得しています。
次に、次のコマンドを使用して、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パイプラインを介してテストアプリケーションを実行したので、このアプリケーションを実稼働環境に昇格してみてください。
[[step-6 -—- promoting-your-test-application-to-a-different-namespace]] ==ステップ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.your_IP_address.nip.io 0.0.2 1/1 http://rsvpapp.jx-production.your_IP_address.nip.io
このPRODUCTION
情報を使用して、Jenkins Xがrsvpapp
を実稼働環境にプロモートしたことを確認できます。 さらに確認するには、ブラウザで本番URLhttp://rsvpapp.jx-production.your_IP_address.nip.io
にアクセスしてください。 「プロダクション」から実行されているのではなく、動作中のアプリケーションが表示されるはずです。
最後に、ポッドを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について詳しく知りたい場合は、An Introduction to Helm, the Package Manager for KubernetesとHow To Install Software on Kubernetes Clusters with the Helm Package Managerの記事をご覧ください。 KubernetesでさらにCI / CDツールを調べるには、このウェビナーシリーズの次のチュートリアルでIstioサービスメッシュについて読むことができます。