6.4. デプロイメントストラテジーの使用


デプロイメントストラテジー は、ユーザーが変更にほとんど気付かないように、ダウンタイムなしでアプリケーションを変更またはアップグレードするために使用されます。

ユーザーは通常、ルーターによって処理されるルートを介してアプリケーションにアクセスするため、デプロイメント戦略は DeploymentConfig オブジェクト機能またはルーティング機能に重点を置くことができます。DeploymentConfig オブジェクトの機能に焦点を当てた戦略は、アプリケーションを使用するすべてのルートに影響を与えます。ルーター機能を使用するストラテジーは個別のルートにターゲットを設定します。

デプロイメントストラテジーの多くは、DeploymentConfig オブジェクトでサポートされ、追加のストラテジーはルーター機能でサポートされます。

6.4.1. デプロイメントストラテジーの選択

デプロイメントストラテジーを選択する場合に、以下を考慮してください。

  • 長期間実行される接続は正しく処理される必要があります。
  • データベースの変換は複雑になる可能性があり、アプリケーションと共に変換し、ロールバックする必要があります。
  • アプリケーションがマイクロサービスと従来のコンポーネントを使用するハイブリッドの場合には、移行の完了時にダウンタイムが必要になる場合があります。
  • これを実行するためのインフラストラクチャーが必要です。
  • テスト環境が分離されていない場合は、新規バージョンと以前のバージョン両方が破損してしまう可能性があります。

デプロイメントストラテジーは、readiness チェックを使用して、新しい Pod の使用準備ができているかを判断します。readiness チェックに失敗すると、DeploymentConfig オブジェクトは、タイムアウトするまで Pod の実行を再試行します。デフォルトのタイムアウトは、10m で、値は dc.spec.strategy.*paramsTimeoutSeconds で設定します。

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 はどちらもライフサイクルフックです。

ローリングストラテジー:

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

手順

  1. Quay.io にあるデプロイメントイメージのサンプルに基づいてアプリケーションを作成します。

    $ oc new-app quay.io/openshifttest/deployment-example:latest
    注記

    このイメージはポートを公開しません。外部 LoadBalancer サービスでアプリケーションを公開するか、パブリックインターネット経由でアプリケーションにアクセスできるようにする必要がある場合は、この手順を完了した後に oc expose dc/deployment-example --port=<port> コマンドを使用してサービスを作成します。

  2. ルーターをインストールしている場合は、ルートを使用してアプリケーションを利用できるようにするか、サービス IP を直接使用してください。

    $ oc expose svc/deployment-example
  3. deployment-example.<project>.<router_domain> でアプリケーションを参照し、v1 イメージが表示されることを確認します。
  4. レプリカが最大 3 つになるまで、DeploymentConfig オブジェクトをスケーリングします。

    $ oc scale dc/deployment-example --replicas=3
  5. 新しいバージョンの例を latest とタグ付けして、新規デプロイメントを自動的にトリガーします。

    $ oc tag deployment-example:v2 deployment-example:latest
  6. ブラウザーで、v2 イメージが表示されるまでページを更新します。
  7. CLI を使用している場合は、以下のコマンドで、バージョン 1 に Pod がいくつあるか、バージョン 2 にはいくつあるかを表示します。Web コンソールでは、Pod が徐々に v2 に追加され、v1 から削除されます。

    $ oc describe dc deployment-example

デプロイメントプロセスで、新しいレプリケーションコントローラーが漸増的にスケールアップします。(rediness チェックをパスした後に) 新規 Pod に ready のマークが付けられると、デプロイメントプロセスは継続されます。

Pod が準備状態にならない場合、プロセスは中止し、デプロイメントは直前のバージョンにロールバックします。

6.4.2.3. 開発者パースペクティブを使用したデプロイメントの編集

Developer パースペクティブを使用して、デプロイメントのデプロイメントストラテジー、イメージ設定、環境変数、詳細オプションを編集できます。

前提条件

  • Web コンソールの Developer パースペクティブを使用している。
  • アプリケーションを作成している。

手順

  1. Topology ビューに移動します。
  2. アプリケーションをクリックして、Details パネルを表示します。
  3. Actions ドロップダウンメニューで Edit Deployment を選択し、Edit Deployment ページを表示します。
  4. デプロイメントの以下の Advanced options を編集できます。

    1. オプション: Pause rollouts をクリックして Pause rollouts for this deployment チェックボックスを選択すると、ロールアウトを一時停止できます。

      ロールアウトを一時停止すると、ロールアウトをトリガーせずにアプリケーションを変更できます。ロールアウトはいつでも再開できます。

    2. オプション: Scaling をクリックし、Replicas のカズを変更することでイメージのインスタンス数を変更できます。
  5. Save をクリックします。

6.4.2.4. 開発者パースペクティブを使用したローリングデプロイメントの開始

ローリングデプロイメントを開始することで、アプリケーションをアップグレードできます。

前提条件

  • Web コンソールの Developer パースペクティブを使用している。
  • アプリケーションを作成している。

手順

  1. Topology ビューでアプリケーションノードをクリックすると、サイドパネルに Overview タブが表示されます。Update Strategy がデフォルトの Rolling ストラテジーに設定されていることに注意してください。
  2. Actions ドロップダウンメニューで、Start Rollout を選択し、ローリング更新を開始します。ローリングデプロイメントは、新しいバージョンのアプリケーションを起動してから、古いバージョンを終了します。

    図6.1 ローリング更新

    odc rolling update

6.4.3. 再作成ストラテジー

再作成ストラテジーは、基本的なロールアウト動作で、デプロイメントプロセスにコードを挿入するためのライフサイクルフックをサポートします。

再作成ストラテジー定義の例

kind: Deployment
apiVersion: apps/v1
metadata:
  name: hello-openshift
# ...
spec:
# ...
  strategy:
    type: Recreate
    recreateParams: 1
      pre: {} 2
      mid: {}
      post: {}

1
recreateParams はオプションです。
2
premid、および post はライフサイクルフックです。

再作成ストラテジー:

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

スケールアップ中に、デプロイメントのレプリカ数が複数ある場合は、デプロイメントの最初のレプリカが準備できているかどうかが検証されてから、デプロイメントが完全にスケールアップされます。最初のレプリカの検証に失敗した場合には、デプロイメントは失敗とみなされます。

再作成デプロイメントの使用のタイミング:

  • 新規コードを起動する前に、移行または他のデータの変換を行う必要がある場合
  • 以前のバージョンと新しいバージョンのアプリケーションコードの同時使用をサポートしていない場合
  • 複数のレプリカ間での共有がサポートされていない、RWO ボリュームを使用する場合

再作成デプロイメントでは、短い期間にアプリケーションのインスタンスが実行されなくなるので、ダウンタイムが発生します。ただし、以前のコードと新しいコードは同時には実行されません。

6.4.3.1. 開発者パースペクティブを使用したデプロイメントの編集

Developer パースペクティブを使用して、デプロイメントのデプロイメントストラテジー、イメージ設定、環境変数、詳細オプションを編集できます。

前提条件

  • Web コンソールの Developer パースペクティブを使用している。
  • アプリケーションを作成している。

手順

  1. Topology ビューに移動します。
  2. アプリケーションをクリックして、Details パネルを表示します。
  3. Actions ドロップダウンメニューで Edit Deployment を選択し、Edit Deployment ページを表示します。
  4. デプロイメントの以下の Advanced options を編集できます。

    1. オプション: Pause rollouts をクリックして Pause rollouts for this deployment チェックボックスを選択すると、ロールアウトを一時停止できます。

      ロールアウトを一時停止すると、ロールアウトをトリガーせずにアプリケーションを変更できます。ロールアウトはいつでも再開できます。

    2. オプション: Scaling をクリックし、Replicas のカズを変更することでイメージのインスタンス数を変更できます。
  5. Save をクリックします。

6.4.3.2. 開発者パースペクティブを使用した再作成デプロイメントの開始

Web コンソールの Developer パースペクティブを使用して、デプロイメントストラテジーをデフォルトのローリング更新から再作成更新に切り替えることができます。

前提条件

  • Web コンソールの Developer パースペクティブにいることを確認します。
  • Add ビューを使用してアプリケーションを作成し、これが Topology ビューにデプロイされていることを確認します。

手順

再作成更新ストラテジーに切り替え、アプリケーションをアップグレードするには、以下を実行します。

  1. アプリケーションをクリックして、Details パネルを表示します。
  2. Actions ドロップダウンメニューで、Edit Deployment Config を選択し、アプリケーションのデプロイメント設定の詳細を確認します。
  3. YAML エディターで spec.strategy.typeRecreate に変更し、Save をクリックします。
  4. Topology ビューでノードを選択し、サイドパネルの Overview タブを表示します。これで、Update StrategyRecreate に設定されます。
  5. Actions ドロップダウンメニューを使用し、Start Rollout を選択し、再作成ストラテジーを使用して更新を開始します。再作成ストラテジーはまず、アプリケーションの古いバージョンの Pod を終了してから、新規バージョンの Pod を起動します。

    図6.2 再作成更新

    odc recreate update

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 は以下の環境変数をデプロイメントプロセスに提供します。

環境変数説明

OPENSHIFT_DEPLOYMENT_NAME

新規デプロイメント名 (レプリケーションコントローラー)

OPENSHIFT_DEPLOYMENT_NAMESPACE

新規デプロイメントの 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 パースペクティブを使用している。
  • アプリケーションを作成している。

手順

  1. Topology ビューに移動します。
  2. アプリケーションをクリックして、Details パネルを表示します。
  3. Actions ドロップダウンメニューで Edit Deployment を選択し、Edit Deployment ページを表示します。
  4. デプロイメントの以下の Advanced options を編集できます。

    1. オプション: Pause rollouts をクリックして Pause rollouts for this deployment チェックボックスを選択すると、ロールアウトを一時停止できます。

      ロールアウトを一時停止すると、ロールアウトをトリガーせずにアプリケーションを変更できます。ロールアウトはいつでも再開できます。

    2. オプション: Scaling をクリックし、Replicas のカズを変更することでイメージのインスタンス数を変更できます。
  5. Save をクリックします。

6.4.5. ライフサイクルフック

ローリングおよび再作成ストラテジーは、ストラテジーで事前に定義したポイントでデプロイメントプロセスに動作を挿入できるようにする ライフサイクルフック またはデプロイメントフックをサポートします。

pre ライフサイクルフックの例

pre:
  failurePolicy: Abort
  execNewPod: {} 1

1
execNewPod は Pod ベースのライフサイクルフックです。

フックにはすべて、フックに問題が発生した場合にストラテジーが取るべきアクションを定義する 失敗ポリシー が含まれます。

Abort

フックに失敗すると、デプロイメントプロセスも失敗とみなされます。

Retry

フックの実行は、成功するまで再試行されます。

Ignore

フックの失敗は無視され、デプロイメントは続行されます。

フックには、フックの実行方法を記述するタイプ固有のフィールドがあります。現在、フックタイプとしてサポートされているのは 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
1
helloworld の名前は spec.template.spec.containers[0].name を参照します。
2
この command は、openshift/origin-ruby-sample イメージで定義される ENTRYPOINT を上書きします。
3
env は、フックコンテナーの環境変数です (任意)。
4
volumes は、フックコンテナーのボリューム参照です (任意)。

この例では、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 を使用してデプロイメント用に、ライフサイクルフックまたはデプロイメントフックを設定できます。

手順

  1. 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
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.