アプリケーションのビルド

手順

1. Home → Projects に移動します。
2. Create Project をクリックします。
3. プロジェクトの詳細を入力します。
4. Create をクリックします。

1. Project ドロップダウンメニューをクリックし、利用可能なすべてのプロジェクトのリストを表示します。Create Project を選択します。

   図2.1 Create project

   
2. Create Project ダイアログボックスで、Name フィールドに、myproject などの一意の名前を入力します。
3. オプション: プロジェクトの Display Name および Description の詳細を追加します。
4. Create をクリックします。
5. 左側のナビゲーションパネルを使用して Project ビューに移動し、プロジェクトのダッシュボードを確認します。

6. オプション。

   • 画面上部の Project ドロップダウンメニューで、all projects を選択し、クラスターのすべてのプロジェクトをリスト表示します。
   • Details タブを使用してプロジェクトの詳細を表示します。
   • プロジェクトに対する適切なパーミッションがある場合は、Project Access タブを使用して、プロジェクトの administrator、edit、および view 権限を提供するか、取り消します。

手順

1. Home → Projects に移動します。

2. 表示するプロジェクトを選択します。

   このページで、Workloads をクリックして、プロジェクトのワークロードを確認します。

手順

1. プロジェクトのリストを表示するには、以下を実行します。

   $ oc get projects

2. CLI 操作について現在のプロジェクトから別のプロジェクトに切り換えることができます。その後の操作についてはすべて指定のプロジェクトが使用され、プロジェクトスコープのコンテンツの操作が実行されます。

   $ oc project <project_name>

1. Developer パースペクティブで、Project ビューに移動します。
2. Project ページで、Project Access タブを選択します。

3. Add Access をクリックして、パーミッションの新規の行をデフォルトパーミッションに追加します。

   図2.2 プロジェクトパーミッション

   
4. ユーザー名を入力し、Select a role ドロップダウンリストをクリックし、適切なロールを選択します。
5. Save をクリックして新規パーミッションを追加します。

1. Search ビューで、Resources ドロップダウンリストを使用して Console を検索します。

2. 利用可能なオプションから、Console operator.openshift.io/v1 を選択します。

   図2.3 コンソールリソースの検索

   
3. Name リストで cluster を選択します。
4. YAML タブに移動し、YAML コードを表示し、編集します。

5. spec の YAML コードで、availableClusterRoles の一覧を追加または編集し、変更を保存します。

   spec:
     customization:
       projectAccess:
         availableClusterRoles:
         - admin
         - edit
         - view

手順

1. Web コンソールのナビゲーションメニューの上部にあるコンテキストセレクターから Developer を選択します。
2. +Add をクリックします。
3. ページの上部で、追加するプロジェクトの名前を選択します。
4. プロジェクトに追加する方法をクリックし、ワークフローに従います。

手順

1. Home → Projects に移動します。
2. ステータスを確認するプロジェクトを選択します。

手順

1. 以下を実行します。

   $ oc status

   このコマンドは、コンポーネントとそれらの各種の関係を含む現在のプロジェクトの概要を示します。

手順

1. Home → Projects に移動します。
2. プロジェクトの一覧から削除するプロジェクトを見つけます。
3. プロジェクトリストの右側にある Options メニュー から Delete Project を選択します。
4. Delete Project ペインが開いたら、フィールドから削除するプロジェクトの名前を入力します。
5. Delete をクリックします。

手順

1. 以下を実行します。

   $ oc delete project <project_name>

手順

1. cluster-admin 権限を持つユーザーとしてログインしている。

2. デフォルトのプロジェクトテンプレートを生成します。

   $ oc adm create-bootstrap-project-template -o yaml > template.yaml

3. オブジェクトを追加するか、既存オブジェクトを変更することにより、テキストエディターで生成される template.yaml ファイルを変更します。

4. プロジェクトテンプレートは、openshift-config namespace に作成される必要があります。変更したテンプレートを読み込みます。

   $ oc create -f template.yaml -n openshift-config

5. Web コンソールまたは CLI を使用し、プロジェクト設定リソースを編集します。

   • Web コンソールの使用

     1. Administration → Cluster Settings ページに移動します。
     2. Configuration をクリックし、すべての設定リソースを表示します。
     3. Project のエントリーを見つけ、Edit YAML をクリックします。

   • CLI の使用

     1. project.config.openshift.io/cluster リソースを編集します。

        $ oc edit project.config.openshift.io/cluster

6. spec セクションを、projectRequestTemplate および name パラメーターを組み込むように更新し、アップロードされたプロジェクトテンプレートの名前を設定します。デフォルト名は project-request です。

   カスタムプロジェクトテンプレートを含むプロジェクト設定リソース

   apiVersion: config.openshift.io/v1
   kind: Project
   metadata:
     ...
   spec:
     projectRequestTemplate:
       name: <template_name>

7. 変更を保存した後、変更が正常に適用されたことを確認するために、新しいプロジェクトを作成します。

手順

1. cluster-admin 権限を持つユーザーとしてログインしている。

2. 以下のコマンドを実行して、self-provisioners クラスターロールバインディングの使用を確認します。

   $ oc describe clusterrolebinding.rbac self-provisioners

   出力例

   Name:		self-provisioners
   Labels:		<none>
   Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
   Role:
     Kind:	ClusterRole
     Name:	self-provisioner
   Subjects:
     Kind	Name				Namespace
     ----	----				---------
     Group	system:authenticated:oauth

   self-provisioners セクションのサブジェクトを確認します。

3. self-provisioner クラスターロールをグループ system:authenticated:oauth から削除します。

   • self-provisioners クラスターロールバインディングが self-provisioner ロールのみを system:authenticated:oauth グループにバインドする場合、以下のコマンドを実行します。

     $ oc patch clusterrolebinding.rbac self-provisioners -p '{"subjects": null}'

   • self-provisioners クラスターロールバインディングが self-provisioner ロールを system:authenticated:oauth グループ以外のユーザー、グループまたはサービスアカウントにバインドする場合、以下のコマンドを実行します。

     $ oc adm policy \
         remove-cluster-role-from-group self-provisioner \
         system:authenticated:oauth

4. ロールへの自動更新を防ぐには、self-provisioners クラスターロールバインディングを編集します。自動更新により、クラスターロールがデフォルトの状態にリセットされます。

   • CLI を使用してロールバインディングを更新するには、以下を実行します。

     1. 以下のコマンドを実行します。

        $ oc edit clusterrolebinding.rbac self-provisioners

     2. 表示されるロールバインディングで、以下の例のように rbac.authorization.kubernetes.io/autoupdate パラメーター値を false に設定します。

        apiVersion: authorization.openshift.io/v1
        kind: ClusterRoleBinding
        metadata:
          annotations:
            rbac.authorization.kubernetes.io/autoupdate: "false"
          ...

   • 単一コマンドを使用してロールバインディングを更新するには、以下を実行します。

     $ oc patch clusterrolebinding.rbac self-provisioners -p '{ "metadata": { "annotations": { "rbac.authorization.kubernetes.io/autoupdate": "false" } } }'

5. 認証されたユーザーとしてログインし、プロジェクトのセルフプロビジョニングを実行できないことを確認します。

   $ oc new-project test

   出力例

   Error from server (Forbidden): You may not request a new project via this API.

   組織に固有のより有用な説明を提供できるようこのプロジェクト要求メッセージをカスタマイズすることを検討します。

手順

1. Web コンソールまたは CLI を使用し、プロジェクト設定リソースを編集します。

   • Web コンソールの使用

     1. Administration → Cluster Settings ページに移動します。
     2. Configuration をクリックし、すべての設定リソースを表示します。
     3. Project のエントリーを見つけ、Edit YAML をクリックします。

   • CLI の使用

     1. cluster-admin 権限を持つユーザーとしてログインしている。

     2. project.config.openshift.io/cluster リソースを編集します。

        $ oc edit project.config.openshift.io/cluster

2. spec セクションを、projectRequestMessage パラメーターを含むように更新し、値をカスタムメッセージに設定します。

   カスタムプロジェクト要求メッセージを含むプロジェクト設定リソース

   apiVersion: config.openshift.io/v1
   kind: Project
   metadata:
     ...
   spec:
     projectRequestMessage: <message_string>

   以下に例を示します。

   apiVersion: config.openshift.io/v1
   kind: Project
   metadata:
     ...
   spec:
     projectRequestMessage: To request a project, contact your system administrator at projectname@example.com.

3. 変更を保存した後に、プロジェクトをセルフプロビジョニングできない開発者またはサービスアカウントとして新規プロジェクトの作成を試行し、変更が正常に適用されていることを確認します。

手順

1. +Add ビューで、Samples タイルをクリックし、Samples ページを表示します。
2. Samples ページで、利用可能なサンプルアプリケーションの 1 つを選択し、Create Sample Application フォームを表示します。

3. Create Sample Application Form:

   • Name フィールドには、デフォルトでデプロイメント名が表示されます。この名前は必要に応じて変更することができます。
   • Builder Image Version では、ビルダーイメージがデフォルトで選択されます。Builder Image Version ドロップダウンリストを使用してイメージバージョンを変更できます。
   • Git リポジトリー URL のサンプルは、デフォルトで追加されます。
4. Create をクリックしてサンプルアプリケーションを作成します。サンプルアプリケーションのビルドステータスが Topology ビューに表示されます。サンプルアプリケーションの作成後、デプロイメントがアプリケーションに追加されていることを確認できます。

手順

1. +Add ビューで、View all quick starts リンクをクリックして、クイックスタート ページを表示します。
2. Quick Starts ページで、使用するクイックスタートのタイルをクリックします。
3. Start をクリックして、クイックスタートを開始します。

手順

1. +Add ビューで、Git Repository タイルの From Git をクリックし、Import from git フォームを表示します。
2. Git セクションで、アプリケーションの作成に使用するコードベースの Git リポジトリー URL を入力します。たとえば、このサンプル nodejs アプリケーションの URL https://github.com/sclorg/nodejs-ex を入力します。その後、URL は検証されます。

3. オプション: Show Advanced Git Options をクリックし、以下のような詳細を追加できます。

   • Git Reference: アプリケーションのビルドに使用する特定のブランチ、タグ、またはコミットのコードを参照します。
   • Context Dir: アプリケーションのビルドに使用するアプリケーションのソースコードのサブディレクトリーを指定します。
   • Source Secret: プライベートリポジトリーからソースコードをプルするための認証情報で Secret Name を作成します。

4. オプション: Git リポジトリーを使用して devfile、Dockerfile、またはビルダーイメージをインポートして、デプロイメントをさらにカスタマイズできるようになりました。

   • Git リポジトリーに devfile、Dockerfile、またはビルダーイメージが含まれる場合には、これらは自動的に検出され、それぞれのパスフィールドに設定されます。devfile、Dockerfile、およびビルダーイメージが同じリポジトリーで検出されると、devfile はデフォルトで選択されます。
   • ファイルのインポートタイプを編集して、別のストラテジーを選択し、Edit import strategy オプションをクリックします。
   • 複数の devfile、Dockerfile、またはビルダーイメージを検出された場合に、特定の devfile、Dockerfile、またはビルダーイメージをインポートするにはコンテキストディレクトリーを起点とした相対パスを指定します。

5. Git URL の検証後に、推奨されるビルダーイメージが選択されて星マークが付けられます。ビルダーイメージが自動検出されていない場合は、ビルダーイメージを選択します。https://github.com/sclorg/nodejs-ex Git URL の場合、Node.js ビルダーイメージがデフォルトで選択されます。

   1. オプション:Builder Image Version ドロップダウンリストを使用してバージョンを指定します。
   2. オプション:Edit import strategy を使用して、別のストラテジーを選択します。
   3. オプション:Node.js ビルダーイメージの場合、Run command フィールドを使用して、アプリケーションを実行するためにコマンドを上書きします。

6. General セクションで、以下を実行します。

   1. Application フィールドに、アプリケーションを分類するために一意の名前 (myapp など) を入力します。アプリケーション名が namespace で一意であることを確認します。

   2. Name フィールドで、既存のアプリケーションが存在しない場合に、このアプリケーション用に作成されたリソースが Git リポジトリー URL をベースとして自動的に設定されることを確認します。既存のアプリケーションがある場合には、既存のアプリケーション内でそのコンポーネントをデプロイしたり、新しいアプリケーションを作成したり、またはコンポーネントをいずれにも割り当てない状態にしたりすることができます。

      注記

      リソース名は namespace で一意である必要があります。エラーが出る場合はリソース名を変更します。

7. Resources セクションで、以下を選択します。

   • Deployment: 単純な Kubernetes スタイルのアプリケーションを作成します。
   • Deployment Config: OpenShift Container Platform スタイルのアプリケーションを作成します。

   • Serverless Deployment: Knative サービスを作成します。

     注記

     Serverless Deployment オプションは、Serverless Operator がクラスターにインストールされている場合にのみ、Import from git フォームに表示されます。詳細は、OpenShift Serverless のドキュメントを参照してください。

8. Pipelines セクションで、 Add Pipeline を選択してから Show Pipeline Visualization をクリックし、アプリケーションのパイプラインを表示します。デフォルトのパイプラインが選択されますが、アプリケーションで利用可能なパイプラインのリストから必要なパイプラインを選択できます。

9. オプション: Advanced Options セクションでは、Target port および Create a route to the application がデフォルトで選択されるため、公開されている URL を使用してアプリケーションにアクセスできます。

   アプリケーションがデフォルトのパブリックポート 80 でデータを公開しない場合は、チェックボックスの選択を解除し、公開する必要のあるターゲットポート番号を設定します。

10. オプション: 以下の高度なオプションを使用してアプリケーションをさらにカスタマイズできます。

手順

1. Topology ビューで、任意の場所を右クリックして Add to Project メニューを表示します。
2. Add to Project メニューにカーソルを置いてメニューオプションを表示し、Upload JAR file オプションを選択して Upload JAR file フォームを確認します。または、JAR ファイルを Topology ビューにドラッグできます。
3. JAR file フィールドで、ローカルマシンで必要な JAR ファイルを参照し、これをアップロードします。または、JAR ファイルを フィールドにドラッグできます。互換性のないタイプのファイルが Topology ビューにドラッグされると、トーストアラートが右側に表示されます。互換性のないファイルタイプがアップロードフォームのフィールドにドロップされると、フィールドエラーが表示されます。
4. デフォルトで、ランタイムアイコンとビルダーイメージが選択されています。ビルダーイメージが自動検出されていない場合は、ビルダーイメージを選択します。必要に応じて、Builder Image Version のドロップダウンリストを使用してバージョンを変更できます。
5. オプション: Application Name フィールドに、リソースのラベル付けに使用する一意のアプリケーション名を入力します。
6. Name フィールドに、関連付けられたリソースに名前を付けるために一意のコンポーネント名を入力します。
7. Resources フィールドで、アプリケーションのリソースタイプを選択します。
8. Advanced options メニューで Create a Route to the Application をクリックし、デプロイされたアプリケーションのパブリック URL を設定します。
9. Create をクリックしてアプリケーションをデプロイします。JAR ファイルがアップロードされたことを通知するトースト通知が表示されます。トースト通知には、ビルドログを表示するリンクも含まれます。

手順

1. Developer Perspective → +Add → Developer Catalog → All Services に移動します。Developer Catalog で利用可能なすべてのサービスの一覧が表示されます。
2. All Services セクションで Devfiles を選択し、特定の言語またはフレームワークをサポートする devfile を参照します。あるいは、キーワードフィルターを使用して、名前、タグ、または説明を使用して特定の devfile を検索できます。
3. アプリケーションの作成に使用する devfile をクリックします。devfile タイルに、devfile の名前、説明、プロバイダー、および ドキュメントなど、devfile の詳細が表示されます。
4. Create をクリックしてアプリケーションを作成し、Topology ビューでアプリケーションを表示します。

手順

1. Developer パースペクティブで、+Add に移動して、Developer Catalog タイルから All Services をクリックし、Developer Catalog で利用可能なすべてのサービスを表示します。
2. All Services で、サービスの種類またはプロジェクトに追加する必要のあるコンポーネントを選択します。この例では、Databases を選択してすべてのデータベースサービスを一覧表示し、MariaDB をクリックしてサービスの詳細を表示します。

3. Instantiate Template をクリックして、MariaDB サービスの詳細情報を含む自動的に設定されたテンプレートを表示し、Create をクリックして Topology ビューで MariaDB サービスを作成し、これを表示します。

   図3.1 トポロジーの MariaDB

   

手順

1. この手順を実行するために OpenShift Container Platform Web コンソールで新規プロジェクトを作成します。この例では、my-etcd というプロジェクトを使用します。

2. Operators → Installed Operators ページに移動します。クラスター管理者によってクラスターにインストールされ、使用可能にされた Operator がクラスターサービスバージョン (CSV) のリストとしてここに表示されます。CSV は Operator によって提供されるソフトウェアを起動し、管理するために使用されます。

   ヒント

   以下を使用して、CLI でこのリストを取得できます。

   $ oc get csv

3. Installed Operators ページで、etcd Operator をクリックして詳細情報および選択可能なアクションを表示します。

   Provided APIs に表示されているように、この Operator は 3 つの新規リソースタイプを利用可能にします。これには、etcd クラスター (EtcdCluster リソース) のタイプが含まれます。これらのオブジェクトは、Deployment または ReplicaSet などの組み込み済みのネイティブ Kubernetes オブジェクトと同様に機能しますが、これらには etcd を管理するための固有のロジックが含まれます。

4. 新規 etcd クラスターを作成します。

   1. etcd Cluster API ボックスで、Create instance をクリックします。
   2. 次の画面では、クラスターのサイズなど EtcdCluster オブジェクトのテンプレートを起動する最小条件への変更を加えることができます。ここでは Create をクリックして確定します。これにより、Operator がトリガーされ、Pod、サービス、および新規 etcd クラスターの他のコンポーネントが起動します。

5. example etcd クラスターをクリックしてから Resources タブをクリックして、プロジェクトに Operator によって自動的に作成され、設定された数多くのリソースが含まれることを確認します。

   Kubernetes サービスが作成され、プロジェクトの他の Pod からデータベースにアクセスできることを確認します。

6. 所定プロジェクトで edit ロールを持つすべてのユーザーは、クラウドサービスのようにセルフサービス方式でプロジェクトにすでに作成されている Operator によって管理されるアプリケーションのインスタンス (この例では etcd クラスター) を作成し、管理し、削除することができます。この機能を持つ追加のユーザーを有効にする必要がある場合、プロジェクト管理者は以下のコマンドを使用してこのロールを追加できます。

   $ oc policy add-role-to-user edit <user> -n <target_project>

手順

1. Web コンソールの Administrator パースペクティブで、Operators → OperatorHub に移動します。
2. Filter by keywordボックスを使用して、カタログで Service Binding Operator を検索します。Service Binding Operator タイルをクリックします。
3. Service Binding Operator ページで Operator についての簡単な説明を参照してください。Install をクリックします。

4. Install Operator ページで以下を行います。

   1. Installation Mode で All namespaces on the cluster (default) を選択します。このモードは、デフォルトの openshift-operators namespace に Operator をインストールします。これにより、Operator はクラスター内のすべての namespace を監視し、これらの namespace に対して利用可能になります。
   2. Approval Strategy で Automatic を選択します。これにより、Operator への今後のアップグレードは Operator Lifecycle Manager (OLM) によって自動的に処理されます。Manual 承認ストラテジーを選択すると、OLM は更新要求を作成します。クラスター管理者は、Operator を新規バージョンに更新できるように OLM 更新要求を手動で承認する必要があります。

   3. Update Channel を選択します。

      • デフォルトでは、stable チャネルでは、サービスバインディング Operator の安定した最新版のリリースをインストールできます。

5. Install をクリックします。

   注記

   Operator は openshift-operators namespace に自動的にインストールされます。

6. Installed operator - ready for use ペインで、View Operator をクリックします。Operator が Installed Operators ページに一覧表示されます。
7. Status が Succeeded に設定されており、サービスバインディング Operator のインストールが正常に行われたことを確認します。

手順

1. シェルで以下のコマンドを実行して、my-petclinic namespace に PostgresCluster CR を作成します。

   $ oc apply -n my-petclinic -f - << EOD
   ---
   apiVersion: postgres-operator.crunchydata.com/v1beta1
   kind: PostgresCluster
   metadata:
     name: hippo
   spec:
     image: registry.developers.crunchydata.com/crunchydata/crunchy-postgres-ha:centos8-13.4-0
     postgresVersion: 13
     instances:
       - name: instance1
         dataVolumeClaimSpec:
           accessModes:
           - "ReadWriteOnce"
           resources:
             requests:
               storage: 1Gi
     backups:
       pgbackrest:
         image: registry.developers.crunchydata.com/crunchydata/crunchy-pgbackrest:centos8-2.33-2
         repos:
         - name: repo1
           volume:
             volumeClaimSpec:
               accessModes:
               - "ReadWriteOnce"
               resources:
                 requests:
                   storage: 1Gi
         - name: repo2
           volume:
             volumeClaimSpec:
               accessModes:
               - "ReadWriteOnce"
               resources:
                 requests:
                   storage: 1Gi
     proxy:
       pgBouncer:
         image: registry.developers.crunchydata.com/crunchydata/crunchy-pgbouncer:centos8-1.15-2
   EOD

   この PostgresCluster CR に追加されたアノテーションは、サービスバインディング接続を有効にし、Operator の調整をトリガーします。

   この出力では、データベースインスタンスが作成されていることを検証します。

   出力例

   postgrescluster.postgres-operator.crunchydata.com/hippo created

2. データベースインスタンスを作成したら、my-petclinic namespace のすべての Pod が実行されていることを確認します。

   $ oc get pods -n my-petclinic

   出力 (表示に数分かかる) で、データベースが作成され設定されていることを検証できます。

   出力例

   NAME                               READY   STATUS    RESTARTS   AGE
   hippo-backup-nqjg-2rq94            1/1     Running   0          35s
   hippo-instance1-nw92-0             3/3     Running   0          112s
   hippo-pgbouncer-57b98f4476-znsk5   2/2     Running   0          112s
   hippo-repo-host-0                  1/1     Running   0          112s

   データベースを設定したら、サンプルアプリケーションをデプロイしてデータベースサービスに接続できます。

手順

1. シェルで以下のコマンドを実行して、spring-petclinic アプリケーションを PostgresCluster カスタムリソース (CR) でデプロイします。

   $ oc apply -n my-petclinic -f - << EOD
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: spring-petclinic
     labels:
       app: spring-petclinic
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: spring-petclinic
     template:
       metadata:
         labels:
           app: spring-petclinic
       spec:
         containers:
           - name: app
             image: quay.io/service-binding/spring-petclinic:latest
             imagePullPolicy: Always
             env:
             - name: SPRING_PROFILES_ACTIVE
               value: postgres
             ports:
             - name: http
               containerPort: 8080
   ---
   apiVersion: v1
   kind: Service
   metadata:
     labels:
       app: spring-petclinic
     name: spring-petclinic
   spec:
     type: NodePort
     ports:
       - port: 80
         protocol: TCP
         targetPort: 8080
     selector:
       app: spring-petclinic
   EOD

   この出力では、Spring PetClinic サンプルアプリケーションが作成され、デプロイされていることを確認します。

   出力例

   deployment.apps/spring-petclinic created
   service/spring-petclinic created

   注記

   Web コンソールの Developer パースペクティブでコンテナーイメージ を使用してアプリケーションをデプロイする場合は、Advanced options の Deployment セクションで以下の環境変数を入力する必要があります。

   • Name: SPRING_PROFILES_ACTIVE
   • Value: postgres

2. 以下のコマンドを実行して、アプリケーションがまだデータベースサービスに接続されていないことを確認します。

   $ oc get pods -n my-petclinic

   出力にCrashLoopBackOff ステータスが表示されるまで、数分かかります。

   出力例

   NAME                                READY   STATUS             RESTARTS      AGE
   spring-petclinic-5b4c7999d4-wzdtz   0/1     CrashLoopBackOff   4 (13s ago)   2m25s

   この段階では、Pod は起動に失敗します。アプリケーションとの対話を試みると、エラーが返されます。

手順

1. ServiceBinding CR を作成し、バインディングデータにパッチを適用します。

   $ oc apply -n my-petclinic -f - << EOD
   ---
   apiVersion: binding.operators.coreos.com/v1alpha1
   kind: ServiceBinding
   metadata:
     name: spring-petclinic-pgcluster
   spec:
     services: 1
       - group: postgres-operator.crunchydata.com
         version: v1beta1
         kind: PostgresCluster 2
         name: hippo
     application: 3
       name: spring-petclinic
       group: apps
       version: v1
       resource: deployments
   EOD

   1

   サービスリソースのリストを指定します。

   2

   データベースの CR。

   3

   Deployment または PodSpec が組み込まれた同様のリソースを参照するサンプルアプリケーション。

   この出力では、バインディングデータをサンプルアプリケーションにプロジェクションする ServiceBinding CR が作成されていることを確認します。

   出力例

   servicebinding.binding.operators.coreos.com/spring-petclinic created

2. サービスバインディングのリクエストが正常に完了したことを確認します。

   $ oc get servicebindings -n my-petclinic

   出力例

   NAME                         READY   REASON              AGE
   spring-petclinic-pgcluster   True    ApplicationsBound   7s

   デフォルトでは、データベースサービスのバインディングデータからの値は、サンプルアプリケーションを実行するワークロードコンテナーにファイルとしてプロジェクションされます。たとえば、Secret リソースからの値はすべて bindings/spring-petclinic-pgcluster ディレクトリーに反映されます。

   注記

   オプションとして、ディレクトリーの内容を出力して、アプリケーションのファイルに反映されたバインディングデータが含まれることを確認することもできます。

   $ for i in username password host port type; do oc exec -it deploy/spring-petclinic -n my-petclinic -- /bin/bash -c 'cd /tmp; find /bindings/*/'$i' -exec echo -n {}:" " \; -exec cat {} \;'; echo; done

   出力例: シークレットリソースからのすべての値

   /bindings/spring-petclinic-pgcluster/username: <username>
   /bindings/spring-petclinic-pgcluster/password: <password>
   /bindings/spring-petclinic-pgcluster/host: hippo-primary.my-petclinic.svc
   /bindings/spring-petclinic-pgcluster/port: 5432
   /bindings/spring-petclinic-pgcluster/type: postgresql

3. アプリケーションポートからポート転送を設定し、ローカル環境からサンプルアプリケーションにアクセスします。

   $ oc port-forward --address 0.0.0.0 svc/spring-petclinic 8080:80 -n my-petclinic

   出力例

   Forwarding from 0.0.0.0:8080 -> 8080
   Handling connection for 8080

4. http://localhost:8080/petclinic にアクセスします。

   localhost:8080 で Spring PetClinic サンプルアプリケーションにリモートでアクセスできるようになり、アプリケーションがデータベースサービスに接続されていることを確認できます。

手順

1. my-petclinic namespace に Dev4Devs PostgreSQL Operator をデプロイするには、シェルで以下のコマンドを実行します。

検証

1. Operator のインストール後に、openshift-operators namespace の Operator サブスクリプションを一覧表示します。

   $ oc get subs -n openshift-operators

   出力例

   NAME                               PACKAGE                            SOURCE                  CHANNEL
   postgresql-operator-dev4devs-com   postgresql-operator-dev4devs-com   ibm-multiarch-catalog   alpha
   rh-service-binding-operator        rh-service-binding-operator        redhat-operators        stable

手順

1. シェルで以下のコマンドを実行して、my-petclinic namespace に Database CR を作成します。

   $ oc apply -f - << EOD
   apiVersion: postgresql.dev4devs.com/v1alpha1
   kind: Database
   metadata:
     name: sampledatabase
     namespace: my-petclinic
     annotations:
       host: sampledatabase
       type: postgresql
       port: "5432"
       service.binding/database: 'path={.spec.databaseName}'
       service.binding/port: 'path={.metadata.annotations.port}'
       service.binding/password: 'path={.spec.databasePassword}'
       service.binding/username: 'path={.spec.databaseUser}'
       service.binding/type: 'path={.metadata.annotations.type}'
       service.binding/host: 'path={.metadata.annotations.host}'
   spec:
     databaseCpu: 30m
     databaseCpuLimit: 60m
     databaseMemoryLimit: 512Mi
     databaseMemoryRequest: 128Mi
     databaseName: "sampledb"
     databaseNameKeyEnvVar: POSTGRESQL_DATABASE
     databasePassword: "samplepwd"
     databasePasswordKeyEnvVar: POSTGRESQL_PASSWORD
     databaseStorageRequest: 1Gi
     databaseUser: "sampleuser"
     databaseUserKeyEnvVar: POSTGRESQL_USER
     image: registry.redhat.io/rhel8/postgresql-13:latest
     databaseStorageClassName: nfs-storage-provisioner
     size: 1
   EOD

   この Database CR に追加されたアノテーションは、サービスバインディング接続を有効にし、Operator の調整をトリガーします。

   この出力では、データベースインスタンスが作成されていることを検証します。

   出力例

   database.postgresql.dev4devs.com/sampledatabase created

2. データベースインスタンスを作成したら、my-petclinic namespace のすべての Pod が実行されていることを確認します。

   $ oc get pods -n my-petclinic

   出力 (表示に数分かかる) で、データベースが作成され設定されていることを検証できます。

   出力例

   NAME                                     READY    STATUS      RESTARTS   AGE
   sampledatabase-cbc655488-74kss            0/1     Running        0       32s

手順

1. シェルで以下のコマンドを実行して、spring-petclinic アプリケーションを PostgresCluster カスタムリソース (CR) でデプロイします。

   $ oc apply -n my-petclinic -f - << EOD
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: spring-petclinic
     labels:
       app: spring-petclinic
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: spring-petclinic
     template:
       metadata:
         labels:
           app: spring-petclinic
       spec:
         containers:
           - name: app
             image: quay.io/service-binding/spring-petclinic:latest
             imagePullPolicy: Always
             env:
             - name: SPRING_PROFILES_ACTIVE
               value: postgres
             - name: org.springframework.cloud.bindings.boot.enable
               value: "true"
             ports:
             - name: http
               containerPort: 8080
   ---
   apiVersion: v1
   kind: Service
   metadata:
     labels:
       app: spring-petclinic
     name: spring-petclinic
   spec:
     type: NodePort
     ports:
       - port: 80
         protocol: TCP
         targetPort: 8080
     selector:
       app: spring-petclinic
   EOD

   この出力では、Spring PetClinic サンプルアプリケーションが作成され、デプロイされていることを確認します。

   出力例

   deployment.apps/spring-petclinic created
   service/spring-petclinic created

   注記

   Web コンソールの Developer パースペクティブでコンテナーイメージ を使用してアプリケーションをデプロイする場合は、Advanced options の Deployment セクションで以下の環境変数を入力する必要があります。

   • Name: SPRING_PROFILES_ACTIVE
   • Value: postgres

2. 以下のコマンドを実行して、アプリケーションがまだデータベースサービスに接続されていないことを確認します。

   $ oc get pods -n my-petclinic

   CrashLoopBackOff ステータスが表示されるまで数分かかります。

   出力例

   NAME                                READY   STATUS             RESTARTS      AGE
   spring-petclinic-5b4c7999d4-wzdtz   0/1     CrashLoopBackOff   4 (13s ago)   2m25s

   この段階では、Pod は起動に失敗します。アプリケーションとの対話を試みると、エラーが返されます。

手順

1. ServiceBinding CR を作成し、バインディングデータにパッチを適用します。

   $ oc apply -n my-petclinic -f - << EOD
   ---
   apiVersion: binding.operators.coreos.com/v1alpha1
   kind: ServiceBinding
   metadata:
       name: spring-petclinic-pgcluster
   spec:
     services: 1
       - group: postgresql.dev4devs.com
         kind: Database 2
         name: sampledatabase
         version: v1alpha1
     application: 3
       name: spring-petclinic
       group: apps
       version: v1
       resource: deployments
   EOD

   1

   サービスリソースのリストを指定します。

   2

   データベースの CR。

   3

   Deployment または PodSpec が組み込まれた同様のリソースを参照するサンプルアプリケーション。

   この出力では、バインディングデータをサンプルアプリケーションにプロジェクションする ServiceBinding CR が作成されていることを確認します。

   出力例

   servicebinding.binding.operators.coreos.com/spring-petclinic created

2. サービスバインディングのリクエストが正常に完了したことを確認します。

   $ oc get servicebindings -n my-petclinic

   出力例

   NAME                          READY   REASON              AGE
   spring-petclinic-postgresql   True    ApplicationsBound   47m

   デフォルトでは、データベースサービスのバインディングデータからの値は、サンプルアプリケーションを実行するワークロードコンテナーにファイルとしてプロジェクションされます。たとえば、Secret リソースからの値はすべて bindings/spring-petclinic-pgcluster ディレクトリーに反映されます。

3. これが作成されたら、トポロジーに移動し、接続を視覚的に確認できます。

   図6.1 spring-petclinic のサンプルデータベースへの接続

   

4. アプリケーションポートからポート転送を設定し、ローカル環境からサンプルアプリケーションにアクセスします。

   $ oc port-forward --address 0.0.0.0 svc/spring-petclinic 8080:80 -n my-petclinic

   出力例

   Forwarding from 0.0.0.0:8080 -> 8080
   Handling connection for 8080

5. http://localhost:8080 にアクセスします。

   localhost:8080 で Spring PetClinic サンプルアプリケーションにリモートでアクセスできるようになり、アプリケーションがデータベースサービスに接続されていることを確認できます。

1. ファイルとして (デフォルト)。
2. 環境変数として。(ServiceBinding リソースから .spec.bindAsFiles パラメーターを設定した後)。

手順

1. ファイルとしてバインディングデータをプロジェクションするには、既存の SERVICE_BINDING_ROOT 環境変数がワークロードが実行されるコンテナーで存在することを確認して、宛先フォルダーを決定します。
2. バインドデータを環境変数としてプロジェクションするには、カスタムリソース (CR) の ServiceBinding リソースから、 .spec.bindAsFiles パラメーターの値を false に設定します。

手順

1. Spring PetClinic サンプルアプリケーションにカーソルを合わせ、ノード上の矢印を確認します。

   図6.2 ビジュアルコネクター

   
2. 矢印をクリックして hippo-pgbouncer デプロイメントに向かってドラッグし、Spring PetClinic サンプルアプリケーションを接続します。
3. spring-petclinic デプロイメントをクリックし、Overview パネルを表示します。Details タブで Annotations セクションの編集アイコンをクリックして、Key = app.openshift.io/connects-to と Value = [{"apiVersion":"apps/v1","kind":"Deployment","name":"hippo-pgbouncer"}] アノテーションがデプロイメントに追加されていることを確認します。

手順

1. Developer パースペクティブに切り替え、my-petclinic などの適切なプロジェクトにいることを確認します。Topology ビューで、Spring PetClinic サンプルアプリケーションにカーソルを合わせてノードの矢印を確認します。

2. 矢印をクリックして Postgres クラスターの hippo データベースに向かってドラッグし、Spring PetClinic サンプルアプリケーションとのバインディング接続を確立します。Create Service Binding ダイアログボックスが表示されます。

   1. 名前を入力し、Create をクリックします。

      図6.4 サービスバインディングモーダル

      

1. Helm バイナリーをダウンロードし、これをパスに追加します。

   • Linux (x86_64, amd64)

     # curl -L https://mirror.openshift.com/pub/openshift-v4/clients/helm/latest/helm-linux-amd64 -o /usr/local/bin/helm

   • Linux on IBM Z and LinuxONE (s390x)

     # curl -L https://mirror.openshift.com/pub/openshift-v4/clients/helm/latest/helm-linux-s390x -o /usr/local/bin/helm

   • Linux on IBM Power (ppc64le)

     # curl -L https://mirror.openshift.com/pub/openshift-v4/clients/helm/latest/helm-linux-ppc64le -o /usr/local/bin/helm

2. バイナリーファイルを実行可能にします。

   # chmod +x /usr/local/bin/helm

3. インストールされたバージョンを確認します。

   $ helm version

   出力例

   version.BuildInfo{Version:"v3.0", GitCommit:"b31719aab7963acf4887a1c1e6d5e53378e34d93", GitTreeState:"clean", GoVersion:"go1.13.4"}

1. 最新の .exe ファイル をダウンロードし、希望のディレクトリーに配置します。
2. Start を右クリックし、Control Panel をクリックします。
3. System and Security を選択してから System をクリックします。
4. 左側のメニューから、Advanced systems settings を選択し、下部にある Environment Variables をクリックします。
5. Variable セクションから Path を選択し、Edit をクリックします。
6. New をクリックして、 .exe ファイルのあるフォルダーへのパスをフィールドに入力するか、Browse をクリックし、ディレクトリーを選択して OK をクリックします。

1. 最新の .exe ファイル をダウンロードし、希望のディレクトリーに配置します。
2. Search クリックして、env または environment を入力します。
3. Edit environment variables for your account を選択します。
4. Variable セクションから Path を選択し、Edit をクリックします。
5. New をクリックし、exe ファイルのあるディレクトリーへのパスをフィールドに入力するか、Browse をクリックし、ディレクトリーを選択して OK をクリックします。

1. Helm バイナリーをダウンロードし、これをパスに追加します。

   # curl -L https://mirror.openshift.com/pub/openshift-v4/clients/helm/latest/helm-darwin-amd64 -o /usr/local/bin/helm

2. バイナリーファイルを実行可能にします。

   # chmod +x /usr/local/bin/helm

3. インストールされたバージョンを確認します。

   $ helm version

   出力例

   version.BuildInfo{Version:"v3.0", GitCommit:"b31719aab7963acf4887a1c1e6d5e53378e34d93", GitTreeState:"clean", GoVersion:"go1.13.4"}

手順

1. 新規プロジェクトを作成します。

   $ oc new-project vault

2. Helm チャートのリポジトリーをローカルの Helm クライアントに追加します。

   $ helm repo add openshift-helm-charts https://charts.openshift.io/

   出力例

   "openshift-helm-charts" has been added to your repositories

3. リポジトリーを更新します。

   $ helm repo update

4. サンプルの HashiCorp Vault をインストールします。

   $ helm install example-vault openshift-helm-charts/hashicorp-vault

   出力例

   NAME: example-vault
   LAST DEPLOYED: Fri Mar 11 12:02:12 2022
   NAMESPACE: vault
   STATUS: deployed
   REVISION: 1
   NOTES:
   Thank you for installing HashiCorp Vault!

5. チャートが正常にインストールされたことを確認します。

   $ helm list

   出力例

   NAME         	NAMESPACE	REVISION	UPDATED                                	STATUS  	CHART       	APP VERSION
   example-vault	vault    	1       	2022-03-11 12:02:12.296226673 +0530 IST	deployed	vault-0.19.0	1.9.2

1. Developer パースペクティブで、+Add ビューに移動し、プロジェクトを選択します。次に、Helm Chart オプションをクリックし、Developer Catalog にすべての Helm チャートを表示します。
2. チャートを選択し、チャートの説明、README、チャートについてのその他の詳細を確認します。

3. Install Helm Chart をクリックします。

   図7.1 Developer カタログの Helm チャート

   

4. Install Helm Chart ページで以下を行います。

   1. リリースの固有の名前を Release Name フィールドに入力します。
   2. Chart Version ドロップダウンリストから必要なチャートのバージョンを選択します。

   3. Form View または YAML View を使用して Helm チャートを設定します。

      注記

      利用可能な場合は、YAML View と Form View 間で切り替えることができます。ビューの切り替え時に、データは永続化されます。

   4. Install をクリックして Helm リリースを作成します。リリースが表示される Topology ビューにリダイレクトされます。Helm チャートにリリースノートがある場合、チャートは事前に選択され、右側のパネルにそのリリースのリリースノートが表示されます。

手順

1. 新規プロジェクトを作成します。

   $ oc new-project nodejs-ex-k

2. OpenShift Container Platform オブジェクトが含まれる Node.js チャートのサンプルをダウンロードします。

   $ git clone https://github.com/redhat-developer/redhat-helm-charts

3. サンプルチャートを含むディレクトリーに移動します。

   $ cd redhat-helm-charts/alpha/nodejs-ex-k/

4. Chart.yaml ファイルを編集し、チャートの説明を追加します。

   apiVersion: v2 1
   name: nodejs-ex-k 2
   description: A Helm chart for OpenShift 3
   icon: https://static.redhat.com/libs/redhat/brand-assets/latest/corp/logo.svg 4
   version: 0.2.1 5

   1

   チャート API バージョン。これは、Helm 3 以上を必要とする Helm チャートの場合は v2 である必要があります。

   2

   チャートの名前。

   3

   チャートの説明。

   4

   アイコンとして使用するイメージへの URL。

   5

   Semantic Versioning (SemVer) 2.0.0 仕様に準拠したチャートのバージョン。

5. チャートが適切にフォーマットされていることを確認します。

   $ helm lint

   出力例

   [INFO] Chart.yaml: icon is recommended
   
   1 chart(s) linted, 0 chart(s) failed

6. 直前のディレクトリーレベルに移動します。

   $ cd ..

7. チャートをインストールします。

   $ helm install nodejs-chart nodejs-ex-k

8. チャートが正常にインストールされたことを確認します。

   $ helm list

   出力例

   NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
   nodejs-chart nodejs-ex-k 1 2019-12-05 15:06:51.379134163 -0500 EST deployed nodejs-0.1.0  1.16.0

手順

1. 新規の Helm Chart リポジトリーを追加するには、Helm Chart Repository カスタムリソース (CR) をクラスターに追加する必要があります。

   Helm チャートリポジトリー CR のサンプル

   apiVersion: helm.openshift.io/v1beta1
   kind: HelmChartRepository
   metadata:
     name: <name>
   spec:
    # optional name that might be used by console
    # name: <chart-display-name>
     connectionConfig:
       url: <helm-chart-repository-url>

   たとえば、Azure サンプルチャートリポジトリーを追加するには、以下を実行します。

   $ cat <<EOF | oc apply -f -
   apiVersion: helm.openshift.io/v1beta1
   kind: HelmChartRepository
   metadata:
     name: azure-sample-repo
   spec:
     name: azure-sample-repo
     connectionConfig:
       url: https://raw.githubusercontent.com/Azure-Samples/helm-charts/master/docs
   EOF

2. Web コンソールで Developer Catalog に移動し、チャートリポジトリーの Helm チャートが表示されることを確認します。

   たとえば、Chart リポジトリー フィルターを使用して、リポジトリーから Helm チャートを検索します。

   図7.2 チャートリポジトリーのフィルター

   
   注記

   クラスター管理者がすべてのチャートリポジトリーを削除する場合は、+Add ビュー、Developer Catalog、および左側のナビゲーションパネルで Helm オプションを表示できません。

手順

1. 新規の namespace スコープの Helm Chart Repository を追加するには、Helm Chart Repository カスタムリソース (CR) を namespace に追加する必要があります。

   namespace スコープの Helm Chart Repository CR のサンプル

   apiVersion: helm.openshift.io/v1beta1
   kind: ProjectHelmChartRepository
   metadata:
     name: <name>
   spec:
     url: https://my.chart-repo.org/stable
   
     # optional name that might be used by console
     name: <chart-repo-display-name>
   
     # optional and only needed for UI purposes
     description: <My private chart repo>
   
     # required: chart repository URL
     connectionConfig:
       url: <helm-chart-repository-url>

   たとえば、my-namespace namespace スコープの Azure サンプルチャートリポジトリーを追加するには、以下を実行します。

   $ cat <<EOF | oc apply --namespace my-namespace -f -
   apiVersion: helm.openshift.io/v1beta1
   kind: ProjectHelmChartRepository
   metadata:
     name: azure-sample-repo
   spec:
     name: azure-sample-repo
     connectionConfig:
       url: https://raw.githubusercontent.com/Azure-Samples/helm-charts/master/docs
   EOF

   この出力から、namespace スコープの Helm Chart Repository CR が作成されていることが分かります。

   出力例

   projecthelmchartrepository.helm.openshift.io/azure-sample-repo created

2. Web コンソールで Developer Catalog に移動し、チャートリポジトリーの Helm チャートが my-namespace namespace に表示されることを確認します。

   たとえば、Chart リポジトリー フィルターを使用して、リポジトリーから Helm チャートを検索します。

   図7.3 namespace のチャートリポジトリーフィルター

   

   あるいは、以下のコマンドを実行します。

   $ oc get projecthelmchartrepositories --namespace my-namespace

   出力例

   NAME                     AGE
   azure-sample-repo        1m

   注記

   クラスター管理者または適切な RBAC パーミッションを持つ通常ユーザーが特定の namespace のすべてのチャートリポジトリーを削除すると、その特定の namespace の +Add ビュー、Developer Catalog、および左側のナビゲーションパネルで Helm オプションを表示することはできません。

1. openshift-config namespace で、PEM でエンコードされた形式のカスタム CA 証明書で ConfigMap を作成し、これを設定マップ内の ca-bundle.crt キーに保存します。

   $ oc create configmap helm-ca-cert \
   --from-file=ca-bundle.crt=/path/to/certs/ca.crt \
   -n openshift-config

2. openshift-config namespace で、クライアント TLS 設定を追加するために Secret オブジェクトを作成します。

   $ oc create secret tls helm-tls-configs \
   --cert=/path/to/certs/client.crt \
   --key=/path/to/certs/client.key \
   -n openshift-config

   クライアント証明書とキーは PEM でエンコードされた形式であり、それぞれ tls.crt および tls.key キーに保存される必要があります。

3. 以下のように Helm リポジトリーを追加します。

   $ cat <<EOF | oc apply -f -
   apiVersion: helm.openshift.io/v1beta1
   kind: HelmChartRepository
   metadata:
     name: <helm-repository>
   spec:
     name: <helm-repository>
     connectionConfig:
       url: <URL for the Helm repository>
       tlsConfig:
           name: helm-tls-configs
       ca:
   	name: helm-ca-cert
   EOF

   ConfigMap および Secret は、tlsConfig および ca フィールドを使用して HelmChartRepository CR で使用されます。これらの証明書は、Helm リポジトリー URL への接続に使用されます。

4. デフォルトでは、認証されたユーザーはすべて設定済みのチャートにアクセスできます。ただし、証明書が必要なチャートリポジトリーの場合は、以下のように openshift-config namespace で helm-ca-cert 設定マップおよび helm-tls-configs シークレットへの読み取りアクセスを提供する必要があります。

   $ cat <<EOF | kubectl apply -f -
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     namespace: openshift-config
     name: helm-chartrepos-tls-conf-viewer
   rules:
   - apiGroups: [""]
     resources: ["configmaps"]
     resourceNames: ["helm-ca-cert"]
     verbs: ["get"]
   - apiGroups: [""]
     resources: ["secrets"]
     resourceNames: ["helm-tls-configs"]
     verbs: ["get"]
   ---
   kind: RoleBinding
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     namespace: openshift-config
     name: helm-chartrepos-tls-conf-viewer
   subjects:
     - kind: Group
       apiGroup: rbac.authorization.k8s.io
       name: 'system:authenticated'
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: helm-chartrepos-tls-conf-viewer
   EOF

手順

1. Developer パースペクティブで、+Add ビューに移動し、プロジェクトを選択します。
2. Developer Catalog タイルから、Helm Chart オプションを選択して Developer Catalog ですべての Helm チャートを表示します。

3. Helm チャートのリストの左側にあるフィルターを使用して、必要なチャートをフィルターします。

   • Chart Repositories フィルターを使用して、Red Hat Certification Charts または OpenShift Helm Charts が提供したチャートをフィルターします。
   • Source フィルターを使用して、Partners、Community または Red Hat から提供されるチャートをフィルターします。認定チャートはアイコン ( ) で表示されます。

手順

1. Topology ビューで Helm リリースを選択し、サイドパネルを表示します。
2. Actions → Upgrade Helm Release をクリックします。
3. Upgrade Helm Release ページで、アップグレード先とする Chart Version を選択してから Upgrade をクリックし、別の Helm リリースを作成します。Helm Releases ページには 2 つのリビジョンが表示されます。

1. Developer パースペクティブで Helm ビューに移動し、namespace の Helm Releases を表示します。
2. リスト表示されているリソースに隣接する Options メニュー をクリックし、Rollback を選択します。
3. Rollback Helm Release ページで、ロールバックする Revision を選択し、 Rollback をクリックします。
4. Helm Releases ページで、チャートをクリックし、リリースの詳細およびリソースを表示します。

5. Revision History タブに移動し、チャートのすべてのリビジョンを表示します。

   図7.4 Helm リビジョン履歴

   
6. 必要な場合は、さらに特定のリビジョンに隣接する Options メニュー を使用して、ロールバックするリビジョンを選択します。

手順

1. Topology ビューで、 Helm リリースを右クリックし、Uninstall Helm Release を選択します。
2. 確認プロンプトでチャートの名前を入力し、Uninstall をクリックします。

1. ReplicationController 定義の要素。
2. 新規デプロイメントの自動作成のトリガー。
3. デプロイメント間の移行ストラテジー。
4. ライフサイクルフック。

1. pre ライフサイクルフックを実行します。
2. サージ数に基づいて新しいレプリケーションコントローラーをスケールアップします。
3. 最大利用不可数に基づいて以前のレプリケーションコントローラーをスケールダウンします。
4. 新しいレプリケーションコントローラーが希望のレプリカ数に到達して、以前のレプリケーションコントローラーの数がゼロになるまで、このスケーリングを繰り返します。
5. post ライフサイクルフックを実行します。

1. pre ライフサイクルフックを実行します。
2. 以前のデプロイメントをゼロにスケールダウンします。
3. 任意の mid ライフサイクルフックを実行します。
4. 新規デプロイメントをスケールアップします。
5. post ライフサイクルフックを実行します。