Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

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

7.2.1. DeploymentConfig オブジェクトの管理

重要

OpenShift Container Platform 4.14 以降、DeploymentConfig オブジェクトは非推奨になりました。DeploymentConfig オブジェクトは引き続きサポートされていますが、新規インストールには推奨されません。セキュリティー関連の重大な問題のみが修正されます。

代わりに、Deployment オブジェクトまたは別の代替手段を使用して、Pod の宣言的更新を提供します。

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

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

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

手順

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

    Copy to Clipboard Toggle word wrap 
    $ oc rollout latest dc/<name>
    注記

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

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

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

手順

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

    Copy to Clipboard Toggle word wrap 
    $ oc rollout history dc/<name>

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

    Copy to Clipboard Toggle word wrap 
    $ oc rollout history dc/<name> --revision=1

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

    Copy to Clipboard Toggle word wrap 
    $ oc describe dc <name>

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

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

手順

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

    Copy to Clipboard Toggle word wrap 
    $ oc rollout retry dc/<name>

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

    注記

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

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

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

手順

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

    Copy to Clipboard Toggle word wrap 
    $ oc rollout undo dc/<name>

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

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

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

    Copy to Clipboard Toggle word wrap 
    $ oc set triggers dc/<name> --auto
注記

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

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

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

手順

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

    Copy to Clipboard Toggle word wrap 
    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 コマンドを実行するには、以下を実行します。

    Copy to Clipboard Toggle word wrap 
    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
# ...

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

手順

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

    Copy to Clipboard Toggle word wrap 
    $ oc logs -f dc/<name>

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

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

    Copy to Clipboard Toggle word wrap 
    $ oc logs --version=1 dc/<name>

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

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

警告

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

設定変更デプロイメントトリガー

設定変更トリガーにより、DeploymentConfig オブジェクトの Pod テンプレートで設定の変更が検出されるたびに、新規のレプリケーションコントローラーが作成されます。

注記

設定変更トリガーが DeploymentConfig オブジェクトに定義されている場合は、DeploymentConfig オブジェクト自体が作成された直後に、最初のレプリケーションコントローラーが自動的に作成され、一時停止されません。

設定変更デプロイメントトリガー

Copy to Clipboard Toggle word wrap 
kind: DeploymentConfig
apiVersion: apps.openshift.io/v1
metadata:
  name: example-dc
# ...
spec:
# ...
  triggers:
    - type: "ConfigChange"

イメージ変更デプロイメントトリガー

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

イメージ変更デプロイメントトリガー

Copy to Clipboard Toggle word wrap 
kind: DeploymentConfig
apiVersion: apps.openshift.io/v1
metadata:
  name: example-dc
# ...
spec:
# ...
  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 コンテナーの新規イメージを使用して、新しいレプリケーションコントローラーが作成されます。

注記

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

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

手順

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

    Copy to Clipboard Toggle word wrap 
    $ oc set triggers dc/<dc_name> \
    --from-image=<project>/<image>:<tag> -c <container_name>

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

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

注記

デプロイメントの最小メモリー制限は 12 MB です。Cannot allocate memory Pod イベントのためにコンテナーの起動に失敗すると、メモリー制限は低くなります。メモリー制限を引き上げるか、これを削除します。制限を削除すると、Pod は制限のないノードのリソースを消費できるようになります。

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

手順

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

    Copy to Clipboard Toggle word wrap 
    kind: Deployment
apiVersion: apps/v1
metadata:
  name: hello-openshift
# ...
spec:
# ...
  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 セクション:

      Copy to Clipboard Toggle word wrap 
      kind: Deployment
apiVersion: apps/v1
metadata:
  name: hello-openshift
# ...
spec:
# ...
  type: "Recreate"
  resources:
    requests:
      1 
      
      cpu: "100m"
      memory: "256Mi"
      ephemeral-storage: "1Gi"
      1
      requests オブジェクトは、クォータ内のリソースリストに対応するリソースリストを含みます。
    • プロジェクトで定義される制限の範囲。LimitRange オブジェクトのデフォルト値がデプロイメントプロセス時に作成される Pod に適用されます。

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

関連情報

7.2.1.9. 手動のスケーリング

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

注記

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

手順

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

    Copy to Clipboard Toggle word wrap 
    $ oc scale dc frontend --replicas=3

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

7.2.1.10. DeploymentConfig オブジェクトからのプライベートリポジトリーへのアクセス

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

手順

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

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

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

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

手順

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

    Copy to Clipboard Toggle word wrap 
    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 が全くスケジュールされなくなります。

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

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

手順

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

    Copy to Clipboard Toggle word wrap 
    $ oc edit dc/<deployment_config>

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

    Copy to Clipboard Toggle word wrap 
    apiVersion: apps.openshift.io/v1
kind: DeploymentConfig
metadata:
  name: example-dc
# ...
spec:
# ...
  securityContext: {}
  serviceAccount: <service_account>
  serviceAccountName: <service_account>
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat, Inc.