Kustomize を使用して、複数環境で再利用するアプリをパッケージ化する
12の要素からなるクラウドネイティブなアプリケーションの一部として、共通のバージョン管理されたコードベースソースを使用する継続的な開発およびデリバリーパイプラインを構築することで、 dev-to-prod の整合性を維持したいと考えるでしょう。 コードベースのリポジトリには、 Kubernetes リソース構成マニフェストファイルを保存します。多くの場合、YAML形式で保存します。
Kubernetes プロジェクトは、 Kustomize 複数の環境にまたがる展開の標準化とカスタマイズの両方に使用できます。
例えば、 kustomization YAML ファイルをベースとして設定し、開発、テスト、および本番環境で共有されるデプロイメントや PVC などの Kubernetes オブジェクトを宣言することができます。 次に、各環境向けにカスタマイズした構成を持つ個別の kustomization YAMLファイルを設定します。例えば、本番環境ではテスト環境よりもレプリカを多くするなどです。 これらのカスタマイズされたYAMLファイルは、共有ベースのYAMLファイルにオーバーレイしたり、その上に構築したりすることができます。これにより、ソース管理している一部のオーバーレイ構成の違いを除いて、ほとんど同一の環境を管理することができます。
Kustomize に関する用語集やFAQなどの詳細については、 Kustomize のドキュメントをご覧ください。
始める前に、Red Hat OpenShift クラスターにアクセスします。
Kustomize を使用して構成ファイルをセットアップするには、以下のようにします。
-
- MacOS の場合、
brewパッケージ・マネージャーを使用できます。brew install kustomize - Windows の場合、
chocolateyパッケージ・マネージャーを使用できます。choco install kustomize
- MacOS の場合、
-
Git などのバージョン管理システムにアプリ用のディレクトリーを作成します。
git init ~/<my_app> -
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 -
baseリポジトリーをセットアップします。-
base リポジトリーに移動します。
cd ~/<my_app>/base -
アプリ・デプロイメント用の Kubernetes 構成 YAML ファイルの初期セットを作成します。
waslibertyYAML サンプルを使用して、デプロイメント、サービス、構成マップ、および永続ボリューム請求を作成できます。 -
環境全体に適用される基本構成を指定 する
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.yamlresourcesYAML の名前は、baseリポジトリー内の他のファイルの名前と一致する必要があります。 同じファイルに複数の構成を含める場合もありますが、この例では、構成はdeployment.yaml、service.yaml、pvc.yamlなどのファイルに分離されています。 -
kustomization基本 YAML ファイルで定義した構成を使用して、リソース YAML ファイルを作成します。 リソースは、kustomizationYAML とリソース YAML の構成を結合して作成されます。 結合された YAML ファイルは、出力のstdoutに返されます。 ラベルを追加するなど、kustomizationYAML に行う以降の変更は、この同じコマンドを使用して作成します。kustomize build
-
-
ステージングや実動などの環境ごとに、固有の
kustomizationYAML ファイルを使用して overlay リポジトリーをセットアップします。-
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.yamlYAMLコンポーネントを理解する コンポーネント 説明 namePrefixステージングの kustomizationファイルで作成する各リソースの名前に付加する接頭部を指定します (staging-など)。commonLabelsステージング環境や担当チームなど、ステージング・オブジェクトに固有のラベルを追加します。 bases基本の kustomizationファイルが保管されるリモート・リポジトリーのディレクトリーまたは URL の相対パスを追加します。 この例では、相対パスは、先ほど作成したkustomizationリポジトリー内の基本のbaseファイルを指しています。 このフィールドは、オーバーレイkustomizationでは必須です。patchesStrategicMerge基本 kustomizationにマージするリソース構成 YAML ファイルをリストします。 また、これらのファイルは、kustomizationファイルと同じリポジトリー (overlay/stagingなど) に追加する必要があります。 これらのリソース構成ファイルには、パッチと同じ名前の基本構成ファイルにマージされる少量の変更を含めることができます。 リソースには、base構成ファイルに指定されたすべてのコンポーネントに加えて、overlay構成ファイルに指定した追加のコンポーネントが与えられます。 構成が base に存在しない新規ファイルである場合は、resourcesフィールドにそのファイルの名前も追加する必要があります。resourcesstaging リポジトリーに固有で、base リポジトリーに含まれていないリソース構成 YAML ファイルをすべてリストします。 これらのファイルは、 patchesStrategicMergeフィールドにも含め、kustomizationファイルと同じリポジトリー (overlay/stagingなど) にも追加する必要があります。その他の設定可能な構成 ファイルに追加できるその他の構成については 、「 kustomizationファイルの作成」 を参照してください。 -
ステージングのオーバーレイ構成ファイルを作成します。
kustomize build overlay/staging -
これらのステップを繰り返して、実動のオーバーレイ
kustomizationおよびその他の構成 YAML ファイルを作成します。 例えば、deployment.yamlでレプリカの数を増やすと、実稼働環境でより多くのユーザー要求を処理できます。 -
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
-
-
デプロイする環境の Kubernetes リソースを適用します。 以下の例では、staging リポジトリーを使用します。
- ステージングのオーバーレイ・ディレクトリーに移動します。 前のステップでリソースを作成していない場合は、ここで作成します。
cd overlay/staging && kustomize build - クラスターに Kubernetes リソースを適用します。
-kオプションと、kustomizationファイルが保存されているディレクトリを含めます。 例えば、既にステージング・ディレクトリーで作業している場合は、../stagingを含めてディレクトリーへのパスをマークします。
出力例oc apply -k ../stagingconfigmap/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 - ステージング固有の変更が適用されていることを確認します。 例えば、
staging-接頭部を追加した場合、作成されるポッドおよびその他のリソースの名前にはこの接頭部が含まれます。
出力例oc get -k ../stagingNAME 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 - 作成する環境ごとにこれらのステップを繰り返します。
- ステージングのオーバーレイ・ディレクトリーに移動します。 前のステップでリソースを作成していない場合は、ここで作成します。
-
オプション: Kustomize で適用したすべてのリソースを削除して、環境をクリーンアップします。
oc 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