Menu Close
Settings Close

Language and Page Formatting Options

4.2. デプロイメントプロセスの管理

4.2.1. DeploymentConfig の管理

DeploymentConfig は、OpenShift Container Platform Web コンソールの Workloads ページからか、または oc CLI を使用して管理できます。以下の手順は、特に指定がない場合の CLI の使用法を示しています。

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

アプリケーションのデプロイメントプロセスを開始するために、ロールアウト を開始できます。

手順

  1. 既存の DeploymentConfig から新規デプロイメントプロセスを開始するには、以下のコマンドを実行します。

    $ oc rollout latest dc/<name>
    注記

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

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

アプリケーションの利用可能なすべてのリビジョンについての基本情報を取得するためにデプロイメントを表示できます。

手順

  1. 現在実行中のデプロイメントプロセスを含む、指定した DeploymentConfig についての最近作成されたすべての ReplicationController についての詳細を表示するには、以下を実行します。

    $ oc rollout history dc/<name>
  2. リビジョンに固有の詳細情報を表示するには、--revision フラグを追加します。

    $ oc rollout history dc/<name> --revision=1
  3. デプロイメント設定およびその最新バージョンの詳細については、oc describe コマンドを使用します。

    $ oc describe dc <name>

4.2.1.3. デプロイメントの再試行

現行リビジョンの DeploymentConfig がデプロイに失敗した場合、デプロイメントプロセスを再起動することができます。

手順

  1. 失敗したデプロイメントプロセスを再起動するには、以下を実行します。

    $ oc rollout retry dc/<name>

    最新リビジョンのデプロイメントに成功した場合には、このコマンドによりメッセージが表示され、デプロイメントプロセスはこれ以上試行されません。

    注記

    デプロイメントを再試行すると、デプロイメントプロセスが再起動され、新しいデプロイメントリビジョンは作成されません。再起動された ReplicationController は、失敗したときと同じ設定を使用します。

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

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

手順

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

    $ oc rollout undo dc/<name>

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

  2. ロールバックの完了直後に新規デプロイメントプロセスが誤って開始されないように、DeploymentConfig のイメージ変更トリガーがロールバックの一部として無効にされます。

    イメージ変更トリガーを再度有効にするには、以下を実行します。

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

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

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

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

手順

  1. command パラメーターを、DeploymentConfig の 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

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

手順

  1. 指定の DeploymentConfig に関する最新リビジョンのログをストリームするには、以下を実行します。

    $ oc logs -f dc/<name>

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

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

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

4.2.1.7. デプロイメントトリガー

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

警告

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

ConfigChange デプロイメントトリガー

ConfigChange トリガーにより、DeploymentConfig の Pod テンプレートで設定の変更が検出されるたびに、新規の ReplicationController が作成されます。

注記

ConfigChange トリガーが DeploymentConfig に定義されている場合は、DeploymentConfig 自体が作成された直後に、最初の ReplicationController が自動的に作成され、一時停止されません。

ConfigChange デプロイメントトリガー

triggers:
  - type: "ConfigChange"

ImageChange デプロイメントトリガー

ImageChange トリガーにより、イメージストリームタグの内容の変更時に常に新規 ReplicationController が生成されます (イメージの新規バージョンがプッシュされるタイミング)。

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 タグの値が変更され、新しいイメージの値が DeploymentConfig の helloworld コンテナーに指定されている現在のイメージと異なる場合に、helloworld コンテナーの新規イメージを使用して、新しい ReplicationController が作成されます。

注記

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

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

手順

  1. oc set triggers コマンドを使用して、DeploymentConfig にデプロイメントトリガーを設定することができます。たとえば、ImageChangeTrigger を設定するには、以下のコマンドを使用します。

    $ oc set triggers dc/<dc_name> \
        --from-image=<project>/<image>:<tag> -c <container_name>

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

注記

このリソースはクラスター管理者が一時ストレージのテクノロジープレビュー機能を有効にしている場合にのみ利用できます。この機能はデフォルトでは無効にされています。

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

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

手順

  1. 以下の例では、resourcescpumemory、および ephemeral-storage はそれぞれオプションです。

    type: "Recreate"
    resources:
      limits:
        cpu: "100m" 1
        memory: "256Mi" 2
        ephemeral-storage: "1Gi" 3
    1
    cpu は CPU のユニットで、100m は 0.1 CPU ユニット (100 * 1e-3) を表します。
    2
    memory はバイト単位です。256Mi は 268435456 バイトを表します (256 * 2 ^ 20)。
    3
    ephemeral-storage はバイト単位です。1Gi は 1073741824 バイト (2 ^ 30) を表します。この項目は、クラスター管理者が一時ストレージのテクノロジープレビュー機能を有効にしている場合のみ該当します。

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

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

        type: "Recreate"
        resources:
          requests: 1
            cpu: "100m"
            memory: "256Mi"
            ephemeral-storage: "1Gi"
      1
      requests オブジェクトは、クォータ内のリソース一覧に対応するリソース一覧を含みます。
    • プロジェクトで定義される制限の範囲。LimitRange オブジェクトのデフォルト値がデプロイメントプロセス時に作成される Pod に適用されます。

    デプロイメントリソースを設定するには、上記のいずれかのオプションを選択してください。それ以外の場合は、デプロイ Pod の作成は、クォータ基準を満たしていないことを示すメッセージを出して失敗します。

4.2.1.9. 手動のスケーリング

ロールバック以外に、手動スケーリングにより、レプリカの数を詳細に管理できます。

注記

Pod は oc autoscale コマンドを使用して自動スケーリングすることも可能です。

手順

  1. DeploymentConfig を手動でスケーリングするには、oc scale コマンドを使用します。たとえば、以下のコマンドは、frontend DeploymentConfig のレプリカを 3 に設定します。

    $ oc scale dc frontend --replicas=3

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

4.2.1.10. DeploymentConfig からのプライベートリポジトリーへのアクセス

シークレットを DeploymentConfig に追加し、プライベートリポジトリーからイメージにアクセスできるようにします。この手順では、OpenShift Container Platform Web コンソールを使用する方法を示します。

手順

  1. 新規プロジェクトを作成します。
  2. Workloads ページから、プライベートイメージリポジトリーにアクセスするための認証情報を含むシークレットを作成します。
  3. DeploymentConfig を作成します。
  4. DeploymentConfig エディターページで、Pull Secret を設定し、変更を保存します。

4.2.1.11. 特定のノードへの Pod の割り当て

ラベル付きのノードと合わせてノードセレクターを使用し、Pod の配置を制御することができます。

クラスター管理者は、プロジェクトに対して デフォルトのノードセレクターを設定して 特定のノードに Pod の配置を制限できます。開発者は、Pod 設定にノードセレクターを設定して、ノードをさらに制限することができます。

手順

  1. Pod の作成時にノードセレクターを追加するには、Pod 設定を編集し、nodeSelector の値を追加します。これは、単一の Pod 設定や、Pod テンプレートに追加できます。

    apiVersion: v1
    kind: Pod
    spec:
      nodeSelector:
        disktype: ssd
    ...

    ノードセレクターが有効な場合に作成される Pod は指定されたラベルを持つノードに割り当てられます。ここで指定されるラベルは、クラスター管理者によって追加されるラベルと併用されます。

    たとえば、プロジェクトに type=user-noderegion=east のラベルがクラスター管理者により追加され、上記の disktype: ssd ラベルを Pod に追加した場合に、Pod は 3 つのラベルすべてが含まれるノードにのみスケジュールされます。

    注記

    ラベルには値を 1 つしか設定できないので、region=east が管理者によりデフォルト設定されている Pod 設定に region=west のノードセレクターを設定すると、Pod が全くスケジュールされなくなります。

4.2.1.12. 異なるサービスアカウントでの Pod の実行

デフォルト以外のサービスアカウントで Pod を実行できます。

手順

  1. DeploymentConfig を編集します。

    $ oc edit dc/<deployment_config>
  2. serviceAccountserviceAccountName パラメーターを spec フィールドに追加し、使用するサービスアカウントを指定します。

    spec:
      securityContext: {}
      serviceAccount: <service_account>
      serviceAccountName: <service_account>