Red Hat Training

A Red Hat training course is available for OpenShift Online

9.2. 基本のデプロイメント操作

9.2.1. デプロイメントの開始

Web コンソールまたは CLI を使用して手動で新規デプロイメントプロセスを開始できます。

$ oc rollout latest dc/<name>
注記

デプロイメントプロセスが進行中の場合には、このコマンドを実行すると、メッセージが表示され、新規レプリケーションコントローラーがデプロイされません。

9.2.2. デプロイメントの表示

アプリケーションで利用可能な全リビジョンの基本情報を取得します。

$ oc rollout history dc/<name>

このコマンドでは、現在実行中のデプロイメントプロセスなど、指定したデプロイメント設定用に、最近作成されたすべてのレプリケーションコントローラーの詳細を表示します。

--revision フラグを使用すると、リビジョン固有の詳細情報が表示されます。

$ oc rollout history dc/<name> --revision=1

デプロイメント設定および最新のリビジョンに関する詳細情報は、以下を実行してください。

$ oc describe dc <name>
注記

Web コンソールでは、Browse タブにデプロイメントが表示されます。

9.2.3. デプロイメントのロールバック

ロールバックすると、アプリケーションを以前のリビジョンに戻します。 この操作は、REST API、CLI または Web コンソールで実行できます。

最後にデプロイして成功した設定のリビジョンにロールバックするには以下を実行します。

$ oc rollout undo dc/<name>

デプロイメント設定のテンプレートは、undo コマンドで指定してデプロイメントのリビジョンと一致するように元に戻され、新しいレプリケーションコントローラーが起動します。--to-revision でリビジョンが指定されていない場合には、最後に成功したデプロイメントのバージョンが使用されます。

ロールバックの完了直後に新規デプロイメントプロセスが誤って開始されないように、ロールバックの一部として、デプロイメント設定のイメージ変更トリガーは無効になります。イメージ変更トリガーをもう一度有効にするには、以下を実行します。

$ oc set triggers dc/<name> --auto
注記

最新のデプロイメントプロセスに失敗した場合に、デプロイメント設定は、最後に成功したリビジョンの設定に自動的にロールバックする機能をサポートします。この場合に、デプロイに失敗した最新のテンプレートはシステムで修正されないので、設定の修正はユーザーが行う必要があります。

9.2.4. コンテナー内でのコマンドの実行

コンテナーにコマンドを追加して、イメージの ENTRYPOINT を却下して、コンテナーの起動動作を変更することができます。これは、指定したタイミングでデプロイメントごとに 1 回実行できるライフサイクルフックとは異なります。

command パラメーターを、デプロイメントの spec フィールドを追加します。commandコマンドを変更する args フィールドも追加できます (または command コマンドが存在しない場合には、ENTRYPOINT)。

...
spec:
  containers:
    -
    name: <container_name>
    image: 'image'
    command:
      - '<command>'
    args:
      - '<argument_1>'
      - '<argument_2>'
      - '<argument_3>'
...

たとえば、-jar および /opt/app-root/springboots2idemo.jar 引数を指定して、java コマンドを実行します。

...
spec:
  containers:
    -
    name: example-spring-boot
    image: 'image'
    command:
      - java
    args:
      - '-jar'
      - /opt/app-root/springboots2idemo.jar
...

9.2.5. デプロイメントログの表示

指定のデプロイメント設定に関する最新リビジョンのログをストリームします。

$ oc logs -f dc/<name>

最新のリビジョンが実行中または失敗した場合には、oc logs は、Pod のデプロイを行うプロセスのログが返されます。成功した場合には、oc logs は、アプリケーションの Pod からのログを返します。

以前に失敗したデプロイメントプロセスからのログを表示することも可能です。 ただし、これらのプロセス (以前のレプリケーションコントローラーおよびデプロイヤーの Pod) が存在し、手動でプルーニングまたは削除されていない場合に限ります。

$ oc logs --version=1 dc/<name>

ログの取得に関する他のオプションについては、以下を参照してください。

$ oc logs --help

9.2.6. デプロイメントトリガーの設定

デプロイメント設定には、クラスター内のイベントに対応する新規デプロイメントプロセスの作成を駆動するトリガーを含めることができます。

警告

トリガーがデプロイメント設定に定義されていない場合は、ConfigChange トリガーがデフォルトで追加されます。トリガーが空のフィールドとして定義されている場合には、デプロイメントは手動で起動する必要があります。

9.2.6.1. 設定変更トリガー

ConfigChange トリガーにより、デプロイメント設定の Pod テンプレートに変更があると検出されるたびに、新規のレプリケーションコントローラーが作成されます。

注記

ConfigChange トリガーがデプロイメント設定に定義されている場合は、デプロイメント設定自体が作成された直後に、最初のレプリケーションコントローラーは自動的に作成され、一時停止されません。

例9.1 ConfigChange トリガー

triggers:
  - type: "ConfigChange"

9.2.6.2. ImageChange トリガー

ImageChange トリガーにより、イメージストリームタグ の内容が変更されるたびに、(イメージの新規バージョンがプッシュされるタイミングで) 新規レプリケーションコントローラーが作成されます。

例9.2 ImageChange トリガー

triggers:
  - type: "ImageChange"
    imageChangeParams:
      automatic: true 1
      from:
        kind: "ImageStreamTag"
        name: "origin-ruby-sample:latest"
        namespace: "myproject"
      containerNames:
        - "helloworld"
1
imageChangeParams.automatic フィールドが false に設定されると、トリガーが無効になります。

上記の例では、origin-ruby-sample イメージストリームの latest タグの値が変更され、新しいイメージの値がデプロイメント設定の helloworld コンテナーに指定されている現在のイメージと異なる場合に、helloworld コンテナーの新規イメージを使用して、新しいレプリケーションコントローラーが作成されます。

注記

ImageChange トリガーがデプロイメント設定 (ConfigChange トリガーと automatic=false、または automatic=true) で定義されていて、ImageChange トリガーで参照されている ImageStreamTag がまだ存在していない場合には、ビルドにより、イメージが、ImageStreamTag にインポートまたはプッシュされた直後に初回のデプロイメントプロセスが自動的に開始されます。

9.2.6.2.1. コマンドラインの使用

oc set triggers コマンドは、デプロイメント設定のデプロイメントトリガーを設定するために使用できます。上記の例では、次のコマンドを使用して ImageChangeTrigger を設定できます。

$ oc set triggers dc/frontend --from-image=myproject/origin-ruby-sample:latest -c helloworld

詳細は、以下を参照してください。

$ oc set triggers --help

9.2.7. デプロイメントリソースの設定

デプロイメントは、ノードでリソース (メモリーおよび CPU) を消費する Pod を使用して完了します。デフォルトで、Pod はバインドされていないノードのリソースを消費します。ただし、プロジェクトにデフォルトのコンテナー制限が指定されている場合には、Pod はその上限までリソースを消費します。

デプロイメントストラテジーの一部としてリソース制限を指定して、リソースの使用を制限することも可能です。デプロイメントリソースは、Recreate (再作成)、Rolling (ローリング) または Custom (カスタム) のデプロイメントストラテジーで使用できます。

以下の例では、recourcescpu、および memory はそれぞれ任意です。

type: "Recreate"
resources:
  limits:
    cpu: "100m" 1
    memory: "256Mi" 2
1
cpu は CPU のユニットで、100m は 0.1 CPU ユニット (100 * 1e-3) を表します。
2
memory はバイト単位です。 256Mi は 268435456 バイトを表します (256 * 2 ^ 20)。

ただし、クォータがプロジェクトに定義されている場合には、以下の 2 つの項目のいずれかが必要です。

  • 明示的な requests で設定した resources セクション:

      type: "Recreate"
      resources:
        requests: 1
          cpu: "100m"
          memory: "256Mi"
    1
    requests オブジェクトは、クォータ内のリソース一覧に対応するリソース一覧を含みます。

コンピュートリソースや、要求と制限の相違点についての詳しい情報は、「クォータと制限の範囲」を参照してください。

  • プロジェクトで定義される制限の範囲。LimitRange オブジェクトのデフォルト値がデプロイメントプロセス時に作成される Pod に適用されます。

適用されない場合は、クォータ基準を満たさないために失敗したというメッセージが出され、デプロイメントの Pod 作成は失敗します。

9.2.8. 手動のスケーリング

ロールバック以外に、Web コンソールまたは oc scale コマンドを使用して、レプリカの数を細かく管理できます。たとえば、以下のコマンドは、デプロイメント設定の frontend を 3 に設定します。

$ oc scale dc frontend --replicas=3

レプリカの数は最終的に、デプロイメント設定の frontend で設定した希望のデプロイメントの状態と現在のデプロイメントの状態に伝搬されます。

注記

Pod は oc autoscale コマンドを使用して自動スケーリングすることも可能です。詳細は「Pod の自動スケーリング」を参照してください。