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

手順

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

   $ oc rollout latest dc/<name>

   注記

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

手順

1. 現在実行中のデプロイメントプロセスを含む、指定した DeploymentConfig オブジェクトに関する最近作成されたすべてのレプリケーションコントローラーの詳細を表示するには、以下を実行します。

   $ oc rollout history dc/<name>

2. リビジョンに固有の詳細情報を表示するには、--revision フラグを追加します。

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

3. DeploymentConfig オブジェクトおよびその最新バージョンの詳細は、oc describe コマンドを使用します。

   $ oc describe dc <name>

手順

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

   $ oc rollout retry dc/<name>

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

   注記

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

手順

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

   $ oc rollout undo dc/<name>

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

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

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

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

   注記

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

手順

1. command パラメーターを、DeploymentConfig オブジェクトの spec フィールドを追加します。command コマンドを変更する args フィールドも追加できます (または command が存在しない場合には、ENTRYPOINT)。

   kind: DeploymentConfig
   apiVersion: apps.openshift.io/v1
   metadata:
     name: example-dc
   # ...
   spec:
     template:
   # ...
       spec:
        containers:
        - name: <container_name>
          image: 'image'
          command:
            - '<command>'
          args:
            - '<argument_1>'
            - '<argument_2>'
            - '<argument_3>'

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

   kind: DeploymentConfig
   apiVersion: apps.openshift.io/v1
   metadata:
     name: example-dc
   # ...
   spec:
     template:
   # ...
       spec:
         containers:
           - name: example-spring-boot
             image: 'image'
             command:
               - java
             args:
               - '-jar'
               - /opt/app-root/springboots2idemo.jar
   # ...

手順

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

   $ oc logs -f dc/<name>

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

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

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

手順

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

   kind: Deployment
   apiVersion: apps/v1
   metadata:
     name: hello-openshift
   # ...
   spec:
   # ...
     type: "Recreate"
     resources:
       limits:
         cpu: "100m"
         memory: "256Mi"
         ephemeral-storage: "1Gi"

   • spec.resources.limits.cpu は CPU ユニットを指定します。100m は、0.1 CPU ユニット (100 * 1e-3) を表します。
   • spec.resources.limits.memory はメモリーのバイト数を指定します。256Mi は、268435456 バイト (256 * 2 ^ 20) を表します。

   • spec.resources.limits.ephemeral-storage は、一時ストレージのバイト数を指定します。1Gi は 1073741824 bytes (2 ^ 30) を表します。

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

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

       kind: Deployment
       apiVersion: apps/v1
       metadata:
         name: hello-openshift
       # ...
       spec:
       # ...
         type: "Recreate"
         resources:
           requests:
             cpu: "100m"
             memory: "256Mi"
             ephemeral-storage: "1Gi"

       spec.resources.requests オブジェクトには、クォータ内のリソースのリストに対応するリソースのリストが含まれています。

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

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

手順

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

   $ oc scale dc frontend --replicas=3

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

手順

1. 新しいプロジェクトを作成する。
2. Workloads Secrets に移動します。
3. プライベートのイメージリポジトリーにアクセスするための認証情報が含まれるシークレットを作成します。
4. Workloads DeploymentConfigs に移動します。
5. DeploymentConfig オブジェクトを作成します。
6. DeploymentConfig エディターページで、Pull Secret を設定し、変更を保存します。

手順

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

   apiVersion: v1
   kind: Pod
   metadata:
     name: my-pod
   # ...
   spec:
     nodeSelector:
       disktype: ssd
   # ...

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

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

   注記

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

手順

1. DeploymentConfig オブジェクトを編集します。

   $ oc edit dc/<deployment_config>

2. serviceAccount と serviceAccountName パラメーターを spec フィールドに追加し、使用するサービスアカウントを指定します。

   apiVersion: apps.openshift.io/v1
   kind: DeploymentConfig
   metadata:
     name: example-dc
   # ...
   spec:
   # ...
     securityContext: {}
     serviceAccount: <service_account>
     serviceAccountName: <service_account>