4.3. デプロイメントストラテジーの使用
デプロイメントストラテジー は、アプリケーションを変更またはアップグレードする 1 つの方法です。この目的は、ユーザーには改善が加えられていることが分からないように、ダウンタイムなしに変更を加えることにあります。
エンドユーザーは通常ルーターによって処理されるルート経由でアプリケーションにアクセスするため、デプロイメントストラテジーは、 DeploymentConfig オブジェクト機能またはルーティング機能に重点を置きます。デプロイメントに重点を置くストラテジーは、アプリケーションを使用するすべてのルートに影響を与えます。ルーター機能を使用するストラテジーは個別のルートにターゲットを設定します。
デプロイメントストラテジーの多くは、DeploymentConfig オブジェクトでサポートされ、追加のストラテジーはルーター機能でサポートされます。このセクションでは、デプロイメントストラテジーについて説明します。
デプロイメントストラテジーの選択
デプロイメントストラテジーを選択する場合に、以下を考慮してください。
- 長期間実行される接続は正しく処理される必要があります。
- データベースの変換は複雑になる可能性があり、アプリケーションと共に変換し、ロールバックする必要があります。
- アプリケーションがマイクロサービスと従来のコンポーネントを使用するハイブリッドの場合には、移行の完了時にダウンタイムが必要になる場合があります。
- これを実行するためのインフラストラクチャーが必要です。
- テスト環境が分離されていない場合は、新規バージョンと以前のバージョン両方が破損してしまう可能性があります。
デプロイメントストラテジーは、readiness チェックを使用して、新しい Pod の使用準備ができているかを判断します。readiness チェックに失敗すると、DeploymentConfig オブジェクトは、タイムアウトするまで Pod の実行を再試行します。デフォルトのタイムアウトは、10m で、値は dc.spec.strategy.*params の TimeoutSeconds で設定します。
4.3.1. ローリングストラテジー
ローリングデプロイメントは、以前のバージョンのアプリケーションインスタンスを、新しいバージョンのアプリケーションインスタンスに徐々に置き換えます。ローリングストラテジーは、DeploymentConfig オブジェクトにストラテジーが指定されていない場合に使用されるデフォルトのデプロイメントストラテジーです。
ローリングデプロイメントは通常、新規 Pod が readiness チェックによって ready になるのを待機してから、古いコンポーネントをスケールダウンします。重大な問題が生じる場合、ローリングデプロイメントは中止される場合があります。
ローリングデプロイメントの使用のタイミング
- ダウンタイムを発生させずに、アプリケーションの更新を行う場合
- 以前のコードと新しいコードの同時実行がアプリケーションでサポートされている場合
ローリングデプロイメントとは、以前のバージョンと新しいバージョンのコードを同時に実行するという意味です。これは通常、アプリケーションで N-1 互換性に対応する必要があります。
ローリングストラテジー定義の例
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 を使用します。
4.3.1.1. カナリアデプロイメント
OpenShift Container Platform におけるすべてのローリングデプロイメントは カナリアデプロイメント です。新規バージョン (カナリア) はすべての古いインスタンスが置き換えられる前にテストされます。readiness チェックが成功しない場合、カナリアインスタンスは削除され、DeploymentConfig オブジェクトは自動的にロールバックされます。
readiness チェックはアプリケーションコードの一部であり、新規インスタンスが使用できる状態にするために必要に応じて高度な設定をすることができます。(実際のユーザーワークロードを新規インスタンスに送信するなどの) アプリケーションのより複雑なチェックを実装する必要がある場合、カスタムデプロイメントや blue-green デプロイメントストラテジーの実装を検討してください。
4.3.1.2. ローリングデプロイメントの作成
ローリングデプロイメントは OpenShift Container Platform のデフォルトタイプです。CLI を使用してローリングデプロイメントを作成できます。
手順
Docker Hub にあるデプロイメントイメージの例を基にアプリケーションを作成します。
$ oc new-app openshift/deployment-example
ルーターをインストールしている場合は、ルートを使用してアプリケーションを利用できるようにするか、または、サービス 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 が準備状態にならない場合、プロセスは中止し、デプロイメントは直前のバージョンにロールバックします。
4.3.1.3. 開発者パースペクティブを使用したローリングデプロイメントの開始
前提条件
- Web コンソールの Developer パースペクティブにいることを確認します。
- Add ビューを使用してアプリケーションを作成し、これが Topology ビューにデプロイされていることを確認します。
手順
ローリングデプロイメントを開始し、アプリケーションをアップグレードするには、以下を実行します。
- Developer パースペクティブの Topology ビューで、アプリケーションノードをクリックし、Overview タブをパネル内に表示します。Update Strategy がデフォルトの Rolling ストラテジーに設定されていることに注意してください。
Actions ドロップダウンメニューで、Start Rollout を選択し、ローリング更新を開始します。ローリングデプロイメントは、新しいバージョンのアプリケーションを起動してから、古いバージョンを終了します。
図4.1 ローリング更新
