IBM Cloud Docs
Kustomize を使用して、複数環境で再利用するアプリをパッケージ化する

Kustomize を使用して、複数環境で再利用するアプリをパッケージ化する

12の要素からなるクラウドネイティブなアプリケーションの一部として、共通のバージョン管理されたコードベースソースを使用する継続的な開発およびデリバリーパイプラインを構築することで、 dev-to-prod の整合性を維持したいと考えるでしょう。 コードベースのリポジトリには、 Kubernetes リソース構成マニフェストファイルを保存します。多くの場合、YAML形式で保存します。 Kubernetes プロジェクトは、 Kustomize 複数の環境にまたがる展開を標準化およびカスタマイズする両方に使用できます。

例えば、 kustomization YAML ファイルをベースとして設定し、開発、テスト、および本番環境で共有されるデプロイメントや PVC などの Kubernetes オブジェクトを宣言することができます。 次に、各環境向けにカスタマイズされた構成を持つ個別の kustomization YAMLファイルを設定することができます。例えば、本番環境ではテスト環境よりもレプリカの数を増やすなどです。 これらのカスタマイズされたYAMLファイルは、共有ベースのYAMLファイルにオーバーレイしたり、その上に構築したりすることができます。これにより、ソース管理している一部のオーバーレイ構成の違いを除いて、ほとんど同一の環境を管理することができます。 Kustomize に関する用語集やFAQなどの詳細については、 Kustomize のドキュメントをご覧ください。

始める前に

Kustomize を使用して構成ファイルをセットアップするには、以下のようにします。

  1. kustomize ツールをインストールします。

    • MacOS の場合、brew パッケージ・マネージャーを使用できます。
      brew install kustomize
    • Windows の場合、chocolatey パッケージ・マネージャーを使用できます。
      choco install kustomize

  2. Git などのバージョン管理システムにアプリ用のディレクトリーを作成します。

    git init ~/<my_app>

  3. kustomize ディレクトリ用のレポジトリ構造を作成します。 baseディレクトリ、 overlayディレクトリ、およびstagingやproductionなどの環境ディレクトリを作成します。 以降のステップでは、kustomize で使用するこれらのリポジトリーをセットアップします。

    mkdir -p ~/<my_app>/base &&
mkdir -p ~/<my_app>/overlay &&
mkdir -p ~/<my_app>/overlay/staging &&
mkdir -p ~/<my_app>/overlay/prod

    リポジトリー構造の例

    .
├── base
└── overlay
    ├── prod
    └── staging

  4. base リポジトリーをセットアップします。

    1. base リポジトリーに移動します。

      cd ~/<my_app>/base

    2. アプリ・デプロイメント用の Kubernetes 構成 YAML ファイルの初期セットを作成します。 wasliberty YAML サンプルを使用して、デプロイメント、サービス、構成マップ、および永続ボリューム請求を作成できます。

    3. 環境全体に適用される基本構成を指定 する kustomization ファイルを作成します。 kustomization ファイルには、同じ base リポジトリーに保管されている Kubernetes リソース構成 YAML のリストが含まれている必要があります。 kustomization ファイルでは、すべてのリソース名に追加される接頭部や接尾部、ラベル、すべてのリソースが作成される既存の名前空間、シークレット、構成マップなど、base リポジトリー内のすべてのリソース YAML に適用される構成を追加することもできます。

      apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: wasliberty
namePrefix: kustomtest-
nameSuffix: -v2
commonLabels:
  app: kustomized-wasliberty
resources:
- deployment.yaml
- service.yaml
- pvc.yaml
- configmap.yaml
- secret.yaml

      resources YAML の名前は、base リポジトリー内の他のファイルの名前と一致する必要があります。 同じファイルに複数の構成を含める場合もありますが、この例では、構成は deployment.yaml、service.yaml、pvc.yaml などのファイルに分離されています。

    4. kustomization 基本 YAML ファイルで定義した構成を使用して、リソース YAML ファイルを作成します。 リソースは、kustomization YAML とリソース YAML の構成を結合して作成されます。 結合された YAML ファイルは、出力の stdout に返されます。 ラベルを追加するなど、kustomization YAML に行う以降の変更は、この同じコマンドを使用して作成します。

      kustomize build

  5. ステージングや実動などの環境ごとに、固有の kustomization YAML ファイルを使用して overlay リポジトリーをセットアップします。

    1. staging リポジトリーに kustomization.yaml ファイルを作成します。 ラベル、イメージ・タグ、テストする新規コンポーネントの YAML など、ステージングに固有の構成を追加します。

      apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namePrefix: staging-
commonLabels:
  env: staging
  owner: TeamA
bases:
- ../../base
patchesStrategicMerge:
- configmap.yaml
- new_staging_resource.yaml
resources:
- new_staging_resource.yaml
      YAMLコンポーネントを理解する
      コンポーネント 説明
      namePrefix ステージングの kustomization ファイルで作成する各リソースの名前に付加する接頭部を指定します (staging- など)。
      commonLabels ステージング環境や担当チームなど、ステージング・オブジェクトに固有のラベルを追加します。
      bases 基本の kustomization ファイルが保管されるリモート・リポジトリーのディレクトリーまたは URL の相対パスを追加します。 この例では、相対パスは、先ほど作成した kustomization リポジトリー内の基本の base ファイルを指しています。 このフィールドは、オーバーレイ kustomization では必須です。
      patchesStrategicMerge 基本 kustomization にマージするリソース構成 YAML ファイルをリストします。 また、これらのファイルは、kustomization ファイルと同じリポジトリー (overlay/staging など) に追加する必要があります。 これらのリソース構成ファイルには、パッチと同じ名前の基本構成ファイルにマージされる少量の変更を含めることができます。 リソースには、base 構成ファイルに指定されたすべてのコンポーネントに加えて、overlay 構成ファイルに指定した追加のコンポーネントが与えられます。 構成が base に存在しない新規ファイルである場合は、resources フィールドにそのファイルの名前も追加する必要があります。
      resources staging リポジトリーに固有で、base リポジトリーに含まれていないリソース構成 YAML ファイルをすべてリストします。 これらのファイルは、patchesStrategicMerge フィールドにも含め、kustomization ファイルと同じリポジトリー (overlay/staging など) にも追加する必要があります。
      その他の設定可能な構成 ファイルに追加できるその他の構成については 、「 kustomization ファイルの作成」 を参照してください。

    2. ステージングのオーバーレイ構成ファイルを作成します。

      kustomize build overlay/staging

    3. これらのステップを繰り返して、実動のオーバーレイ kustomization およびその他の構成 YAML ファイルを作成します。 例えば、deployment.yaml でレプリカの数を増やすと、実稼働環境でより多くのユーザー要求を処理できます。

    4. kustomize リポジトリー構造を調べて、すべての必要な YAML 構成ファイルが含まれていることを確認します。 構造は、以下の例のようになります。

      ├── base
│   ├── configmap.yaml
│   ├── deployment.yaml
│   ├── kustomization.yaml
│   ├── pvc.yaml
│   ├── secret.yaml
│   └── service.yaml
└── overlay
    ├── prod
    │   ├── deployment.yaml
    │   ├── kustomization.yaml
    │   └── new_prod_resource.yaml
    └── staging
        ├── configmap.yaml
        ├── kustomization.yaml
        └── new_staging_resource.yaml

  6. デプロイする環境の Kubernetes リソースを適用します。 以下の例では、staging リポジトリーを使用します。

    1. ステージングのオーバーレイ・ディレクトリーに移動します。 前のステップでリソースを作成していない場合は、ここで作成します。
      cd overlay/staging && kustomize build
    2. クラスターに Kubernetes リソースを適用します。 -k オプションと、 kustomization ファイルが保存されているディレクトリを含めます。 例えば、既にステージング・ディレクトリーで作業している場合は、../staging を含めてディレクトリーへのパスをマークします。
      kubectl apply -k ../staging
      出力例 
      configmap/staging-kustomtest-configmap-v2 created
secret/staging-kustomtest-secret-v2 created
service/staging-kustomtest-service-v2 created
deployment.apps/staging-kustomtest-deployment-v2 created
job.batch/staging-pi created
persistentvolumeclaim/staging-kustomtest-pvc-v2 created
    3. ステージング固有の変更が適用されていることを確認します。 例えば、staging- 接頭部を追加した場合、作成されるポッドおよびその他のリソースの名前にはこの接頭部が含まれます。
      kubectl get -k ../staging
      出力例 
      NAME                                        DATA   AGE
configmap/staging-kustomtest-configmap-v2   2      90s

NAME                                  TYPE     DATA   AGE
secret/staging-kustomtest-secret-v2   Opaque   2      90s

NAME                                    TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
service/staging-kustomtest-service-v2   NodePort   172.21.xxx.xxx   <none>        9080:30200/TCP   90s

NAME                                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/staging-kustomtest-deployment-v2   0/3     3            0           91s

NAME                   COMPLETIONS   DURATION   AGE
job.batch/staging-pi   1/1           41s        2m37s

NAME                                              STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS       AGE
persistentvolumeclaim/staging-kustomtest-pvc-v2   Pending                                      ibmc-file-bronze   90s
    4. 作成する環境ごとにこれらのステップを繰り返します。

  7. オプション: Kustomize で適用したすべてのリソースを削除して、環境をクリーンアップします。

    kubectl delete -k <directory>

    出力例

    configmap "staging-kustomtest-configmap-v2" deleted
secret "staging-kustomtest-secret-v2" deleted
service "staging-kustomtest-service-v2" deleted
deployment.apps "staging-kustomtest-deployment-v2" deleted
job.batch "staging-pi" deleted
persistentvolumeclaim "staging-kustomtest-pvc-v2" deleted