ウェビナーシリーズ

この記事は、Kubernetesを使用したCI/CDの実行に関するウェビナーシリーズを補足するものです。 このシリーズでは、リリース管理、クラウドネイティブツール、サービスメッシュ、Kubernetesで使用できるCI / CDツールについて説明し、アプリケーションの構築、テスト、デプロイにクラウドネイティブアプローチを採用する方法について説明します。 これは、CI/CDのベストプラクティスとKubernetesをワークフローに統合することに関心のある開発者や企業を支援するように設計されています。

このチュートリアルには、シリーズの2番目のセッションであるHelmを使用したKubernetesパッケージ管理とJenkinsXを使用したCI/CDの概念とコマンドが含まれています。

警告:このチュートリアルの手順は、デモンストレーションのみを目的としています。 その結果、本番環境での展開に必要なベストプラクティスとセキュリティ対策に準拠していません。

序章

アプリケーションを展開する際のエラーを減らし、複雑さを整理するために、CI / CDシステムには、パッケージ管理/展開用の堅牢なツールと、自動テストを備えたパイプラインが含まれている必要があります。 しかし、最新の本番環境では、クラウドベースのインフラストラクチャの複雑さが増すと、信頼性の高いCI/CD環境を構築する際に問題が発生する可能性があります。 この問題を解決するために開発された2つのKubernetes固有のツールは、HelmパッケージマネージャーとJenkinsXパイプライン自動化ツールです。

Helmは、Kubernetes用に特別に設計されたパッケージマネージャーであり、 Cloud Native Computing Foundation (CNCF)が、Microsoft、Google、Bitnami、およびHelmコントリビューターコミュニティと協力して管理しています。 大まかに言えば、APTやYUMなどのLinuxシステムパッケージマネージャーと同じ目標を達成します。つまり、アプリケーションのインストールと依存関係をバックグラウンドで管理し、ユーザーから複雑さを隠すことです。 しかし、Kubernetesでは、この種の管理の必要性がさらに顕著になります。アプリケーションのインストールには、複雑で面倒なYAMLファイルのオーケストレーションが必要であり、リリースのアップグレードやロールバックは困難なものから不可能なものまであります。 この問題を解決するために、HelmはKubernetes上で実行され、アプリケーションを charts と呼ばれる事前構成されたリソースにパッケージ化します。これにより、ユーザーは簡単なコマンドで管理できるため、アプリケーションの共有と管理のプロセスがよりユーザーになります。フレンドリー。

Jenkins Xは、Kubernetesの本番パイプラインと環境を自動化するために使用されるCI/CDツールです。 Dockerイメージ、Helmチャート、および Jenkinsパイプラインエンジンを使用して、Jenkins Xはリリースとバージョンを自動的に管理し、GitHub上の環境間でアプリケーションをプロモートできます。

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

  • Helmを使用したKubernetesパッケージの管理、作成、デプロイ。

  • JenkinsXを使用してCI/CDパイプラインを構築します。

さまざまなKubernetesプラットフォームでHelmとJenkinsXを使用できますが、このチュートリアルでは、ローカル環境でセットアップされたシミュレートされたKubernetesクラスターを実行します。 これを行うには、 Minikube を使用します。これは、真のKubernetesクラスターをセットアップしなくても、自分のマシンでKubernetesツールを試すことができるプログラムです。

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

前提条件

このチュートリアルに従うには、次のものが必要です。

  • 16GB以上のRAMを搭載したUbuntu16.04サーバー。 このチュートリアルはデモンストレーションのみを目的としているため、コマンドはrootアカウントから実行されます。 このアカウントの制限のない特権は、本番環境に対応したベストプラクティスに準拠しておらず、システムに影響を与える可能性があることに注意してください。このため、仮想マシンや DigitalOceanDroplet

  • GitHubアカウントおよびGitHubAPIトークン。 このチュートリアルのJenkinsXの部分で入力できるように、このAPIトークンを必ず記録してください。

  • Kubernetesの概念に精通していること。 詳細については、記事Kubernetesの概要を参照してください。

ステップ1—Minikubeを使用してローカルKubernetesクラスターを作成する

Minikubeを設定する前に、Kubernetesコマンドラインツール kubectl 、双方向データ転送リレー socat 、コンテナプログラムDockerなどの依存関係をインストールする必要があります。 ]。

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

  1. apt-get update
  2. apt-get install apt-transport-https

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

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

GPGキーを追加したら、ファイルを作成します /etc/apt/sources.list.d/kubernetes.list テキストエディタで開くと、次のようになります。

  1. 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:

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

注: MinikubeでKubernetesクラスターをシミュレートするには、 docker.io 新しいものではなくパッケージ docker-ce リリース。 本番環境に対応した環境の場合、 docker-ce 公式のDockerリポジトリでより適切に維持されるため、より適切な選択になります。

kubectlをインストールしたので、Minikubeのインストールに進むことができます。 まず、 curl プログラムのバイナリをダウンロードするには:

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

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

  1. chmod +x minikube

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

  1. cp minikube /usr/local/bin/
  2. rm minikube

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

  1. minikube start --vm-driver none

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

警告:ルート権限を持つAPIサーバーはローカルホストに無制限にアクセスできるため、Minikubeを使用してMinikubeを実行することはお勧めしません。 none パーソナルワークステーション上のドライバー。

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

  1. minikube status

次の出力が表示されます。代わりにIPアドレスが使用されます your_IP_address:

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

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

ステップ2—クラスターでのHelmPackageManagerのセットアップ

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

Helmバイナリインストールするには、最初に curl 次のインストールスクリプトを公式のHelmGitHubリポジトリから名前の付いた新しいファイルにダウンロードします get_helm.sh:

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

このスクリプトにはrootアクセスが必要なため、 get_helm.sh ファイルの所有者(この場合はroot)がファイルの読み取り、書き込み、および実行を行えるようにするには、次のようにします。

  1. chmod 700 get_helm.sh

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

  1. ./get_helm.sh

スクリプトが終了すると、次のようになります。 helm にインストール /usr/local/bin/helmtiller にインストール /usr/local/bin/tiller.

けれど tiller がインストールされましたが、Kubernetesクラスタ内の必要なリソースにアクセスするための適切な役割と権限がまだありません。 これらの役割と権限をに割り当てるには tillerサービスアカウントという名前を作成する必要があります tiller. Kubernetesでは、サービスアカウントはポッドで実行されるプロセスのIDを表します。 プロセスがサービスアカウントを介して認証された後、プロセスはAPIサーバーに接続し、クラスターリソースにアクセスできます。 ポッドに特定のサービスアカウントが割り当てられていない場合、ポッドはデフォルトのサービスアカウントを取得します。 また、ロールベースのアクセス制御(RBAC)ルールを作成して、 tiller サービスアカウント。

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

  1. 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 その役割をのリストに割り当てます subjects、 含んでいる tiller サービスアカウント、 adminkubelet ユーザー、および system:serviceaccounts グループ。

次に、構成をで展開します rbac_helm.yaml 次のコマンドを使用します。

  1. kubectl apply -f rbac_helm.yaml

とともに tiller 構成がデプロイされたら、Helmを初期化できます。 --service-acount 設定したサービスアカウントを使用するためのフラグ:

  1. helm init --service-account tiller

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

Output
Creating /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!

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

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

  1. kubectl --namespace kube-system get pods

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

Output
NAME 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などのアプリケーションを検索します。

  1. helm search mongodb

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

Output
NAME 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の機能をテストするには、次の名前の新しいHelmチャートを作成します。 demo 次のコマンドを使用します。

  1. helm create demo

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

に移動します demo ディレクトリと使用 ls その内容を一覧表示するには:

  1. cd demo
  2. ls

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

デモ
charts  Chart.yaml  templates  values.yaml

テキストエディタを使用して、 Chart.yaml ファイル:

  1. 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、常にする必要があります v1description それは何についての追加情報を与えます demo それは name チャートの、そして version Helmがリリースマーカーとして使用する番号。 ファイルの調査が終了したら、テキストエディタを閉じます。

次に、 values.yaml ファイル:

  1. 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、チャート開発者は、チャートで定義されたアプリケーションのデフォルト値を提供し、レプリカカウント、イメージベース、入力アクセス、シークレット管理などを制御できます。 チャートユーザーは、これらのパラメーターに独自の値をカスタムYAMLファイルで提供できます。 helm install. ユーザーがカスタム値を指定すると、これらの値はグラフの値を上書きします values.yaml ファイル。

を閉じます values.yaml ファイルを作成し、その内容を一覧表示します templates 次のコマンドを使用してディレクトリを作成します。

  1. ls templates

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

テンプレート
deployment.yaml  _helpers.tpl  ingress.yaml  NOTES.txt  service.yaml  tests

これで、 demo チャート、インストールすることでヘルムチャートのインストールを試すことができます demo. 次のコマンドを使用して、ホームディレクトリに戻ります。

  1. cd

をインストールします demo 名前の下のヘルムチャート webhelm install:

  1. helm install --name web ./demo

次の出力が得られます。

Output
NAME: 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 次のコマンドを使用したヘルムチャート:

  1. kubectl get deploy

これにより、アクティブな展開を一覧表示する出力が生成されます。

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

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

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

Helmチャートの変更により、アプリケーションのさまざまなバージョンがどのようにリリースされるかを示すには、を開きます。 demo/values.yaml テキストエディタで変更します replicaCount:3image:tag: から stablelatest. 次のコードブロックでは、YAMLファイルの変更が完了した後、変更が強調表示された状態で、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リリースを現在の状態で一覧表示します。

  1. helm list

前に作成した1つのデプロイメントで、次の出力が表示されます。

Output
NAME 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 応用。

を展開するには web 最新の変更が加えられたアプリケーション demo/values.yaml、次のコマンドを使用してアプリケーションをアップグレードします。

  1. helm upgrade web ./demo

ここで、Helmリリースをもう一度リストします。

  1. helm list

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

Output
NAME 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、以下を使用します。

  1. 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、次のコマンドを入力します。

  1. helm rollback web 1

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

Output
Rollback was a success! Happy Helming!

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

  1. helm history web

次のリストが届きます。

Output
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 SUPERSEDED demo-0.1.0 Upgrade complete 3 Wed Feb 20 21:28:48 2019 DEPLOYED demo-0.1.0 Rollback to 1

ロールバックすることにより web アプリケーション、リビジョンと同じ設定を持つ3番目のリビジョンを作成しました 1. 覚えておいてください、あなたはいつでもどのリビジョンがアクティブであるかを見つけることができます DEPLOYED 下のアイテム STATUS.

次のセクションの準備として、テスト領域を削除してクリーンアップします。 web でリリース helm delete 指図:

  1. helm delete web

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

  1. helm history web

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

Output
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 SUPERSEDED demo-0.1.0 Upgrade complete 3 Wed Feb 20 21:28:48 2019 DELETED demo-0.1.0 Deletion complete

The STATUS 為に REVISION 3 に変更されました DELETED、デプロイされたインスタンスが web 削除されました。 ただし、これによりリリースは削除されますが、ストアからは削除されません。 リリースを完全に削除するには、 helm delete とのコマンド --purge 国旗。

  1. helm delete web --purge

このステップでは、Helmを使用してKubernetesでアプリケーションリリースを管理しました。 Helmについてさらに詳しく知りたい場合は、 An Introduction to Helm、Kubernetesのパッケージマネージャーチュートリアルを確認するか、公式のHelmドキュメントを確認してください。

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

ステップ4—JenkinsX環境のセットアップ

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

使用するので jx クラスタを作成するには、まず、既存のMinikubeクラスタを削除する必要があります。 これを行うには、次のコマンドを使用します。

  1. minikube delete

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

  1. rm -rf ~/.kube
  2. rm -rf ~/.minikube
  3. rm -rf /etc/kubernetes/*
  4. rm -rf /var/lib/minikube/*

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

まず、圧縮されたものをダウンロードします jx 公式JenkinsXGitHubリポジトリからのファイル curl コマンドを実行し、 tar 指図:

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

次に、ダウンロードしたものを移動します jx で実行可能パスへのファイル /usr/local/bin:

  1. mv jx /usr/local/bin

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

  1. nano /etc/docker/daemon.json

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

/etc/docker/daemon.json
{
  "insecure-registries" : ["0.0.0.0/0"]
}

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

  1. systemctl restart docker

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

  1. docker info

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

Output
Containers: 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 CI /CD機能を備えたMinikubeKubernetesクラスターを作成するためのCLIツール:

  1. 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は堅牢ですが大規模なプログラムであるため、これらの仕様により、このデモンストレーションでJenkinsXが問題なく動作することが保証されます。 また、あなたは使用しています --default-admin-password=admin JenkinsXパスワードを次のように設定します admin--vm-driver=none 手順1で行ったように、クラスターをローカルにセットアップします。

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

まず、次のプロンプトが表示されます。

Output
? disk-size (MB) 150GB

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

次に、JenkinsXはGitHubAPIトークンを入力するように求めます。

Output
To 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を使用して、適切な権限で新しいトークンを作成します。

次に、JenkinsXは次のように質問します。

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 両方の質問に対して。

この後、JenkinsXは次のように回答するように求めます。

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のユーザー名を選択します。

最後に、次の出力が表示されます。これは、インストールが成功したことを確認し、JenkinsX管理者パスワードを提供します。

Output
Creating 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のリストを受信するコマンド:

  1. 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環境に関するJenkinsXデータを表示できます。 この場合、これは両方の「管理者」になります。

次に、名前空間のサービスアカウントを確認するために jx, jx-staging、 と jx-production 管理者権限を持っている場合は、次のコマンドを使用してRBACポリシーを変更します。

  1. kubectl create clusterrolebinding jx-staging1 --clusterrole=cluster-admin --user=admin --user=expose --group=system:serviceaccounts --serviceaccount=jx-staging:expose --namespace=jx-staging
  1. kubectl create clusterrolebinding jx-staging2 --clusterrole=cluster-admin --user=admin --user=expose --group=system:serviceaccounts --serviceaccount=jx-staging:default --namespace=jx-staging
  1. kubectl create clusterrolebinding jx-production1 --clusterrole=cluster-admin --user=admin --user=expose --group=system:serviceaccounts --serviceaccount=jx-production:expose --namespace=jx-productions
  1. kubectl create clusterrolebinding jx-production2 --clusterrole=cluster-admin --user=admin --user=expose --group=system:serviceaccounts --serviceaccount=jx-production:default --namespace=jx-productions
  1. kubectl create clusterrolebinding jx-binding1 --clusterrole=cluster-admin --user=admin --user=expose --group=system:serviceaccounts --serviceaccount=jx:expose --namespace=jx
  1. 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機能をテストし、JenkinsXパイプラインを体験できます。

ステップ5—JenkinsX環境でテストアプリケーションを作成する

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

このチュートリアルでは、デモンストレーションの目的で、CloudYugaチームによって作成されたサンプルRSVPアプリケーションを使用します。 このアプリケーションは、他のウェビナー資料とともに、DO-CommunityGitHubリポジトリにあります。

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

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

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

  1. cd rsvpapp
  2. rm -r .git/

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

  1. jx import

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

サンプルRSVPアプリケーションはポートで実行されるため 5000 そのコンテナの、あなたの変更 charts/rsvpapp/values.yaml これに一致するファイル。 を開きます charts/rsvpapp/values.yaml テキストエディタで:

  1. 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を使用しているため、 charts/preview/requirements.yaml MongoDBを依存関係としてリストするファイル。 次のコマンドを使用して、テキストエディタでファイルを開きます。

  1. nano charts/preview/requirements.yaml

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

チャート/プレビュー/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

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

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

  1. nano charts/rsvpapp/requirements.yaml

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

チャート/rsvpapp/requirements.yaml

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

これで、 mongodb-replicaset あなたの依存関係としてのチャート rsvpapp チャート。

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

  1. nano charts/rsvpapp/templates/deployment.yaml

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

チャート/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をデータベースとして使用してアプリケーションをデプロイできるようになります。

次に、 Jenkinsfile アプリケーションのホームディレクトリからファイルを開くことにより、JenkinsXによって生成されます。

  1. nano Jenkinsfile

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

これを実証するために、置き換えてカスタマイズされたテストケースを追加します sh "python -m unittest"stage('CI Build and push snapshot')stage('Build Release') の中に 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 "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にプッシュします。

  1. git add *
  2. git commit -m update
  3. git push

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

Output
. . . Finished: SUCCESS

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

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

  1. jx get app

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

Output
APPLICATION STAGING PODS URL rsvpapp 0.0.2 1/1 http://rsvpapp.jx-staging.your_IP_address.nip.io

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

次に、次のコマンドを使用してアプリケーションのアクティビティを確認します。

  1. jx get activity -f rsvpapp

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

Output
STEP 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

ここでは、フィルターを適用してRSVPアプリケーションのJenkinsXアクティビティを取得しています。 -f rsvpapp.

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

  1. 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アプリケーションをにプロモートしてCI/CDプロセスを完了します。 jx-production 名前空間。

まず、 jx promote 次のコマンドで:

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

これは促進します rsvpapp で実行されているアプリケーション version=0.0.2 実稼働環境に。 ビルドプロセス全体を通じて、JenkinsXはGitHubアカウント情報を入力するように求めます。 これらのプロンプトに、表示された個々の応答で答えてください。

プロモーションが成功したら、アプリケーションのリストを確認してください。

  1. jx get app

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

Output
APPLICATION 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 情報、JenkinsXがプロモートしたことを確認できます rsvpapp 実稼働環境に。 詳細な確認については、本番URLにアクセスしてください http://rsvpapp.jx-production.your_IP_address.nip.io ブラウザで。 「本番環境」から実行されている、動作中のアプリケーションが表示されます。

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

  1. 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の詳細については、 Helmの概要、Kubernetesのパッケージマネージャーおよび HelmPackageManagerを使用してKubernetesクラスターにソフトウェアをインストールする方法の記事をご覧ください。 。 KubernetesのCI/CDツールをさらに詳しく調べるには、このウェビナーシリーズの次のチュートリアルでIstioサービスメッシュについて読むことができます。