6.4. デプロイメントストラテジーの使用
デプロイメントストラテジー は、ユーザーが変更にほとんど気付かないように、ダウンタイムなしでアプリケーションを変更またはアップグレードするために使用されます。
ユーザーは通常、ルーターによって処理されるルートを介してアプリケーションにアクセスするため、デプロイメント戦略は DeploymentConfig
オブジェクト機能またはルーティング機能に重点を置くことができます。DeploymentConfig
オブジェクトの機能に焦点を当てた戦略は、アプリケーションを使用するすべてのルートに影響を与えます。ルーター機能を使用するストラテジーは個別のルートにターゲットを設定します。
デプロイメントストラテジーの多くは、DeploymentConfig
オブジェクトでサポートされ、追加のストラテジーはルーター機能でサポートされます。
6.4.1. デプロイメントストラテジーの選択
デプロイメントストラテジーを選択する場合に、以下を考慮してください。
- 長期間実行される接続は正しく処理される必要があります。
- データベースの変換は複雑になる可能性があり、アプリケーションと共に変換し、ロールバックする必要があります。
- アプリケーションがマイクロサービスと従来のコンポーネントを使用するハイブリッドの場合には、移行の完了時にダウンタイムが必要になる場合があります。
- これを実行するためのインフラストラクチャーが必要です。
- テスト環境が分離されていない場合は、新規バージョンと以前のバージョン両方が破損してしまう可能性があります。
デプロイメントストラテジーは、readiness チェックを使用して、新しい Pod の使用準備ができているかを判断します。readiness チェックに失敗すると、DeploymentConfig
オブジェクトは、タイムアウトするまで Pod の実行を再試行します。デフォルトのタイムアウトは、10m
で、値は dc.spec.strategy.*params
の TimeoutSeconds
で設定します。
6.4.2. ローリングストラテジー
ローリングデプロイメントは、以前のバージョンのアプリケーションインスタンスを、新しいバージョンのアプリケーションインスタンスに徐々に置き換えます。ローリングストラテジーは、DeploymentConfig
オブジェクトにストラテジーが指定されていない場合に使用されるデフォルトのデプロイメントストラテジーです。
ローリングデプロイメントは通常、新規 Pod が readiness チェックによって ready
になるのを待機してから、古いコンポーネントをスケールダウンします。重大な問題が生じる場合、ローリングデプロイメントは中止される場合があります。
ローリングデプロイメントの使用のタイミング
- ダウンタイムを発生させずに、アプリケーションの更新を行う場合
- 以前のコードと新しいコードの同時実行がアプリケーションでサポートされている場合
ローリングデプロイメントとは、以前のバージョンと新しいバージョンのコードを同時に実行するという意味です。これは通常、アプリケーションで N-1 互換性に対応する必要があります。
ローリングストラテジー定義の例
kind: DeploymentConfig apiVersion: apps.openshift.io/v1 metadata: name: example-dc # ... spec: # ... strategy: type: Rolling rollingParams: updatePeriodSeconds: 1 1 intervalSeconds: 1 2 timeoutSeconds: 120 3 maxSurge: "20%" 4 maxUnavailable: "10%" 5 pre: {} 6 post: {}
- 1
- 各 Pod が次に更新されるまで待機する時間。指定されていない場合、デフォルト値は
1
となります。 - 2
- 更新してからデプロイメントステータスをポーリングするまでの間待機する時間。指定されていない場合、デフォルト値は
1
となります。 - 3
- イベントのスケーリングを中断するまでの待機時間。この値はオプションです。デフォルトは
600
です。ここでの 中断 とは、自動的に以前の完全なデプロイメントにロールバックされるという意味です。 - 4
maxSurge
はオプションで、指定されていない場合には、デフォルト値は25%
となります。以下の手順の次にある情報を参照してください。- 5
maxUnavailable
はオプションで、指定されていない場合には、デフォルト値は25%
となります。以下の手順の次にある情報を参照してください。- 6
pre
およびpost
はどちらもライフサイクルフックです。
ローリングストラテジー:
-
pre
ライフサイクルフックを実行します。 - サージ数に基づいて新しいレプリケーションコントローラーをスケールアップします。
- 最大利用不可数に基づいて以前のレプリケーションコントローラーをスケールダウンします。
- 新しいレプリケーションコントローラーが希望のレプリカ数に到達して、以前のレプリケーションコントローラーの数がゼロになるまで、このスケーリングを繰り返します。
-
post
ライフサイクルフックを実行します。
スケールダウン時には、ローリングストラテジーは Pod の準備ができるまで待機し、スケーリングを行うことで可用性に影響が出るかどうかを判断します。Pod をスケールアップしたにもかかわらず、準備が整わない場合には、デプロイメントプロセスは最終的にタイムアウトして、デプロイメントに失敗します。
maxUnavailable
パラメーターは、更新時に利用できない Pod の最大数です。maxSurge
パラメーターは、元の Pod 数を超えてスケジュールできる Pod の最大数です。どちらのパラメーターも、パーセント (例: 10%
) または絶対値 (例: 2
) のいずれかに設定できます。両方のデフォルト値は 25%
です。
以下のパラメーターを使用して、デプロイメントの可用性やスピードを調整できます。以下に例を示します。
-
maxUnavailable*=0
およびmaxSurge*=20%
が指定されていると、更新時および急速なスケールアップ時に完全なキャパシティーが維持されるようになります。 -
maxUnavailable*=10%
およびmaxSurge*=0
が指定されていると、追加のキャパシティーを使用せずに更新を実行します (インプレース更新)。 -
maxUnavailable*=10%
およびmaxSurge*=10%
の場合は、キャパシティーが失われる可能性がありますが、迅速にスケールアップおよびスケールダウンします。
一般的に、迅速にロールアウトする場合は maxSurge
を使用します。リソースのクォータを考慮して、一部に利用不可の状態が発生してもかまわない場合には、maxUnavailable
を使用します。
Red Hat OpenShift Service on AWS のすべてのマシン設定プールにおける maxUnavailable
のデフォルト設定は 1
です。この値を変更せず、一度に 1 つのコントロールプレーンノードを更新することを推奨します。コントロールプレーンプールのこの値を 3
に変更しないでください。
6.4.2.1. カナリアデプロイメント
Red Hat OpenShift Service on AWS におけるすべてのローリングデプロイメントは カナリアデプロイメント です。新規バージョン (カナリア) はすべての古いインスタンスが置き換えられる前にテストされます。readiness チェックが成功しない場合、カナリアインスタンスは削除され、DeploymentConfig
オブジェクトは自動的にロールバックされます。
readiness チェックはアプリケーションコードの一部であり、新規インスタンスが使用できる状態にするために必要に応じて高度な設定をすることができます。(実際のユーザーワークロードを新規インスタンスに送信するなどの) アプリケーションのより複雑なチェックを実装する必要がある場合、カスタムデプロイメントや blue-green デプロイメントストラテジーの実装を検討してください。
6.4.2.2. ローリングデプロイメントの作成
ローリングデプロイメントは Red Hat OpenShift Service on AWS のデフォルトタイプです。CLI を使用してローリングデプロイメントを作成できます。
手順
Quay.io にあるデプロイメントイメージのサンプルに基づいてアプリケーションを作成します。
$ oc new-app quay.io/openshifttest/deployment-example:latest
注記このイメージはポートを公開しません。外部 LoadBalancer サービスでアプリケーションを公開するか、パブリックインターネット経由でアプリケーションにアクセスできるようにする必要がある場合は、この手順を完了した後に
oc expose dc/deployment-example --port=<port>
コマンドを使用してサービスを作成します。ルーターをインストールしている場合は、ルートを使用してアプリケーションを利用できるようにするか、サービス IP を直接使用してください。
$ oc expose svc/deployment-example
-
deployment-example.<project>.<router_domain>
でアプリケーションを参照し、v1
イメージが表示されることを確認します。 レプリカが最大 3 つになるまで、
DeploymentConfig
オブジェクトをスケーリングします。$ oc scale dc/deployment-example --replicas=3
新しいバージョンの例を
latest
とタグ付けして、新規デプロイメントを自動的にトリガーします。$ oc tag deployment-example:v2 deployment-example:latest
-
ブラウザーで、
v2
イメージが表示されるまでページを更新します。 CLI を使用している場合は、以下のコマンドで、バージョン 1 に Pod がいくつあるか、バージョン 2 にはいくつあるかを表示します。Web コンソールでは、Pod が徐々に v2 に追加され、v1 から削除されます。
$ oc describe dc deployment-example
デプロイメントプロセスで、新しいレプリケーションコントローラーが漸増的にスケールアップします。(rediness チェックをパスした後に) 新規 Pod に ready
のマークが付けられると、デプロイメントプロセスは継続されます。
Pod が準備状態にならない場合、プロセスは中止し、デプロイメントは直前のバージョンにロールバックします。
6.4.2.3. 開発者パースペクティブを使用したデプロイメントの編集
Developer パースペクティブを使用して、デプロイメントのデプロイメントストラテジー、イメージ設定、環境変数、詳細オプションを編集できます。
前提条件
- Web コンソールの Developer パースペクティブを使用している。
- アプリケーションを作成している。
手順
- Topology ビューに移動します。
- アプリケーションをクリックして、Details パネルを表示します。
- Actions ドロップダウンメニューで Edit Deployment を選択し、Edit Deployment ページを表示します。
デプロイメントの以下の Advanced options を編集できます。
オプション: Pause rollouts をクリックして Pause rollouts for this deployment チェックボックスを選択すると、ロールアウトを一時停止できます。
ロールアウトを一時停止すると、ロールアウトをトリガーせずにアプリケーションを変更できます。ロールアウトはいつでも再開できます。
- オプション: Scaling をクリックし、Replicas のカズを変更することでイメージのインスタンス数を変更できます。
- Save をクリックします。
6.4.2.4. 開発者パースペクティブを使用したローリングデプロイメントの開始
ローリングデプロイメントを開始することで、アプリケーションをアップグレードできます。
前提条件
- Web コンソールの Developer パースペクティブを使用している。
- アプリケーションを作成している。
手順
- Topology ビューでアプリケーションノードをクリックすると、サイドパネルに Overview タブが表示されます。Update Strategy がデフォルトの Rolling ストラテジーに設定されていることに注意してください。
Actions ドロップダウンメニューで、Start Rollout を選択し、ローリング更新を開始します。ローリングデプロイメントは、新しいバージョンのアプリケーションを起動してから、古いバージョンを終了します。
図6.1 ローリング更新
6.4.3. 再作成ストラテジー
再作成ストラテジーは、基本的なロールアウト動作で、デプロイメントプロセスにコードを挿入するためのライフサイクルフックをサポートします。
再作成ストラテジー定義の例
kind: Deployment apiVersion: apps/v1 metadata: name: hello-openshift # ... spec: # ... strategy: type: Recreate recreateParams: 1 pre: {} 2 mid: {} post: {}
再作成ストラテジー:
-
pre
ライフサイクルフックを実行します。 - 以前のデプロイメントをゼロにスケールダウンします。
-
任意の
mid
ライフサイクルフックを実行します。 - 新規デプロイメントをスケールアップします。
-
post
ライフサイクルフックを実行します。
スケールアップ中に、デプロイメントのレプリカ数が複数ある場合は、デプロイメントの最初のレプリカが準備できているかどうかが検証されてから、デプロイメントが完全にスケールアップされます。最初のレプリカの検証に失敗した場合には、デプロイメントは失敗とみなされます。
再作成デプロイメントの使用のタイミング:
- 新規コードを起動する前に、移行または他のデータの変換を行う必要がある場合
- 以前のバージョンと新しいバージョンのアプリケーションコードの同時使用をサポートしていない場合
- 複数のレプリカ間での共有がサポートされていない、RWO ボリュームを使用する場合
再作成デプロイメントでは、短い期間にアプリケーションのインスタンスが実行されなくなるので、ダウンタイムが発生します。ただし、以前のコードと新しいコードは同時には実行されません。
6.4.3.1. 開発者パースペクティブを使用したデプロイメントの編集
Developer パースペクティブを使用して、デプロイメントのデプロイメントストラテジー、イメージ設定、環境変数、詳細オプションを編集できます。
前提条件
- Web コンソールの Developer パースペクティブを使用している。
- アプリケーションを作成している。
手順
- Topology ビューに移動します。
- アプリケーションをクリックして、Details パネルを表示します。
- Actions ドロップダウンメニューで Edit Deployment を選択し、Edit Deployment ページを表示します。
デプロイメントの以下の Advanced options を編集できます。
オプション: Pause rollouts をクリックして Pause rollouts for this deployment チェックボックスを選択すると、ロールアウトを一時停止できます。
ロールアウトを一時停止すると、ロールアウトをトリガーせずにアプリケーションを変更できます。ロールアウトはいつでも再開できます。
- オプション: Scaling をクリックし、Replicas のカズを変更することでイメージのインスタンス数を変更できます。
- Save をクリックします。
6.4.3.2. 開発者パースペクティブを使用した再作成デプロイメントの開始
Web コンソールの Developer パースペクティブを使用して、デプロイメントストラテジーをデフォルトのローリング更新から再作成更新に切り替えることができます。
前提条件
- Web コンソールの Developer パースペクティブにいることを確認します。
- Add ビューを使用してアプリケーションを作成し、これが Topology ビューにデプロイされていることを確認します。
手順
再作成更新ストラテジーに切り替え、アプリケーションをアップグレードするには、以下を実行します。
- アプリケーションをクリックして、Details パネルを表示します。
- Actions ドロップダウンメニューで、Edit Deployment Config を選択し、アプリケーションのデプロイメント設定の詳細を確認します。
-
YAML エディターで
spec.strategy.type
をRecreate
に変更し、Save をクリックします。 - Topology ビューでノードを選択し、サイドパネルの Overview タブを表示します。これで、Update Strategy は Recreate に設定されます。
Actions ドロップダウンメニューを使用し、Start Rollout を選択し、再作成ストラテジーを使用して更新を開始します。再作成ストラテジーはまず、アプリケーションの古いバージョンの Pod を終了してから、新規バージョンの Pod を起動します。
図6.2 再作成更新
6.4.4. カスタムストラテジー
カスタムストラテジーでは、独自のデプロイメントの動作を提供できるようになります。
カスタムストラテジー定義の例
kind: DeploymentConfig apiVersion: apps.openshift.io/v1 metadata: name: example-dc # ... spec: # ... strategy: type: Custom customParams: image: organization/strategy command: [ "command", "arg1" ] environment: - name: ENV_1 value: VALUE_1
上記の例では、organization/strategy
コンテナーイメージにより、デプロイメントの動作が提供されます。オプションの command
配列は、イメージの Dockerfile
で指定した CMD
ディレクティブを上書きします。指定したオプションの環境変数は、ストラテジープロセスの実行環境に追加されます。
さらに、Red Hat OpenShift Service on AWS は以下の環境変数をデプロイメントプロセスに提供します。
環境変数 | 説明 |
---|---|
| 新規デプロイメント名 (レプリケーションコントローラー) |
| 新規デプロイメントの namespace |
新規デプロイメントのレプリカ数は最初はゼロです。ストラテジーの目的は、ユーザーのニーズに最適な仕方で対応するロジックを使用して新規デプロイメントをアクティブにすることにあります。
または customParams
オブジェクトを使用して、カスタムのデプロイメントロジックを、既存のデプロイメントストラテジーに挿入します。カスタムのシェルスクリプトロジックを指定して、openshift-deploy
バイナリーを呼び出します。カスタムのデプロイヤーコンテナーイメージを用意する必要はありません。ここでは、代わりにデフォルトの Red Hat OpenShift Service on AWS デプロイヤーイメージが使用されます。
kind: DeploymentConfig apiVersion: apps.openshift.io/v1 metadata: name: example-dc # ... spec: # ... strategy: type: Rolling customParams: command: - /bin/sh - -c - | set -e openshift-deploy --until=50% echo Halfway there openshift-deploy echo Complete
この設定により、以下のようなデプロイメントになります。
Started deployment #2 --> Scaling up custom-deployment-2 from 0 to 2, scaling down custom-deployment-1 from 2 to 0 (keep 2 pods available, don't exceed 3 pods) Scaling custom-deployment-2 up to 1 --> Reached 50% (currently 50%) Halfway there --> Scaling up custom-deployment-2 from 1 to 2, scaling down custom-deployment-1 from 2 to 0 (keep 2 pods available, don't exceed 3 pods) Scaling custom-deployment-1 down to 1 Scaling custom-deployment-2 up to 2 Scaling custom-deployment-1 down to 0 --> Success Complete
カスタムデプロイメントストラテジーのプロセスでは、Red Hat OpenShift Service on AWS API または Kubernetes API へのアクセスが必要な場合には、ストラテジーを実行するコンテナーは、認証用のコンテナーで利用可能なサービスアカウントのトークンを使用できます。
6.4.4.1. 開発者パースペクティブを使用したデプロイメントの編集
Developer パースペクティブを使用して、デプロイメントのデプロイメントストラテジー、イメージ設定、環境変数、詳細オプションを編集できます。
前提条件
- Web コンソールの Developer パースペクティブを使用している。
- アプリケーションを作成している。
手順
- Topology ビューに移動します。
- アプリケーションをクリックして、Details パネルを表示します。
- Actions ドロップダウンメニューで Edit Deployment を選択し、Edit Deployment ページを表示します。
デプロイメントの以下の Advanced options を編集できます。
オプション: Pause rollouts をクリックして Pause rollouts for this deployment チェックボックスを選択すると、ロールアウトを一時停止できます。
ロールアウトを一時停止すると、ロールアウトをトリガーせずにアプリケーションを変更できます。ロールアウトはいつでも再開できます。
- オプション: Scaling をクリックし、Replicas のカズを変更することでイメージのインスタンス数を変更できます。
- Save をクリックします。
6.4.5. ライフサイクルフック
ローリングおよび再作成ストラテジーは、ストラテジーで事前に定義したポイントでデプロイメントプロセスに動作を挿入できるようにする ライフサイクルフック またはデプロイメントフックをサポートします。
pre
ライフサイクルフックの例
pre:
failurePolicy: Abort
execNewPod: {} 1
- 1
execNewPod
は Pod ベースのライフサイクルフックです。
フックにはすべて、フックに問題が発生した場合にストラテジーが取るべきアクションを定義する 失敗ポリシー が含まれます。
| フックに失敗すると、デプロイメントプロセスも失敗とみなされます。 |
| フックの実行は、成功するまで再試行されます。 |
| フックの失敗は無視され、デプロイメントは続行されます。 |
フックには、フックの実行方法を記述するタイプ固有のフィールドがあります。現在、フックタイプとしてサポートされているのは Pod ベースのフックのみで、このフックは execNewPod
フィールドで指定されます。
Pod ベースのライフサイクルフック
Pod ベースのライフサイクルフックは、DeploymentConfig
オブジェクトのテンプレートをベースとする新しい Pod でフックコードを実行します。
以下のデプロイメントの例は簡素化されており、この例ではローリングストラテジーを使用します。簡潔にまとめられるように、トリガーおよびその他の詳細は省略しています。
kind: DeploymentConfig apiVersion: apps.openshift.io/v1 metadata: name: frontend spec: template: metadata: labels: name: frontend spec: containers: - name: helloworld image: openshift/origin-ruby-sample replicas: 5 selector: name: frontend strategy: type: Rolling rollingParams: pre: failurePolicy: Abort execNewPod: containerName: helloworld 1 command: [ "/usr/bin/command", "arg1", "arg2" ] 2 env: 3 - name: CUSTOM_VAR1 value: custom_value1 volumes: - data 4
この例では、pre
フックは、helloworld
コンテナーからの openshift/origin-ruby-sample
イメージを使用して新規 Pod で実行されます。フック Pod には以下のプロパティーが設定されます。
-
フックコマンドは
/usr/bin/command arg1 arg2
です。 -
フックコンテナーには、
CUSTOM_VAR1=custom_value1
環境変数が含まれます。 -
フックの失敗ポリシーは
Abort
で、フックが失敗するとデプロイメントプロセスも失敗します。 -
フック Pod は、
DeploymentConfig
オブジェクト Pod からdata
ボリュームを継承します。
6.4.5.1. ライフサイクルフックの設定
CLI を使用してデプロイメント用に、ライフサイクルフックまたはデプロイメントフックを設定できます。
手順
oc set deployment-hook
コマンドを使用して、必要なフックのタイプを設定します (--pre
、--mid
、または--post
)。たとえば、デプロイメント前のフックを設定するには、以下を実行します。$ oc set deployment-hook dc/frontend \ --pre -c helloworld -e CUSTOM_VAR1=custom_value1 \ --volumes data --failure-policy=abort -- /usr/bin/command arg1 arg2