4.2. デプロイメントプロセスの管理
4.2.1. DeploymentConfig オブジェクトの管理
DeploymentConfig
オブジェクトは、OpenShift Container Platform Web コンソールの Workloads ページからか、または oc
CLI を使用して管理できます。以下の手順は、特に指定がない場合の CLI の使用法を示しています。
4.2.1.1. デプロイメントの開始
アプリケーションのデプロイメントプロセスを開始するために、ロールアウトを開始できます。
手順
既存の
DeploymentConfig
から新規デプロイメントプロセスを開始するには、以下のコマンドを実行します。$ oc rollout latest dc/<name>
注記デプロイメントプロセスが進行中の場合には、このコマンドを実行すると、メッセージが表示され、新規レプリケーションコントローラー はデプロイされません。
4.2.1.2. デプロイメントの表示
アプリケーションの利用可能なすべてのリビジョンについての基本情報を取得するためにデプロイメントを表示できます。
手順
現在実行中のデプロイメントプロセスを含む、指定した
DeploymentConfig
オブジェクトについての最近作成されたすべてのレプリケーションコントローラーについての詳細を表示するには、以下を実行します。$ oc rollout history dc/<name>
リビジョンに固有の詳細情報を表示するには、
--revision
フラグを追加します。$ oc rollout history dc/<name> --revision=1
DeploymentConfig
オブジェクトおよびその最新バージョンの詳細については、oc describe
コマンドを使用します。$ oc describe dc <name>
4.2.1.3. デプロイメントの再試行
現行リビジョンの DeploymentConfig
がデプロイに失敗した場合、デプロイメントプロセスを再起動することができます。
手順
失敗したデプロイメントプロセスを再起動するには、以下を実行します。
$ oc rollout retry dc/<name>
最新リビジョンのデプロイメントに成功した場合には、このコマンドによりメッセージが表示され、デプロイメントプロセスは試行されません。
注記デプロイメントを再試行すると、デプロイメントプロセスが再起動され、新しいデプロイメントリビジョンは作成されません。再起動されたレプリケーションコントローラーは、失敗したときと同じ設定を使用します。
4.2.1.4. デプロイメントのロールバック
ロールバックすると、アプリケーションを以前のリビジョンに戻します。この操作は、REST API、CLI または Web コンソールで実行できます。
手順
最後にデプロイして成功した設定のリビジョンにロールバックするには、以下を実行します。
$ oc rollout undo dc/<name>
DeploymentConfig
オブジェクトのテンプレートは、undo コマンドで指定されたデプロイメントのリビジョンと一致するように元に戻され、新規レプリケーションコントローラーが起動します。--to-revision
でリビジョンが指定されない場合には、最後に成功したデプロイメントのリビジョンが使用されます。ロールバックの完了直後に新規デプロイメントプロセスが誤って開始されないように、
DeploymentConfig
オブジェクトのイメージ変更トリガーがロールバックの一部として無効にされます。イメージ変更トリガーを再度有効にするには、以下を実行します。
$ oc set triggers dc/<name> --auto
デプロイメント設定は、最新のデプロイメントプロセスが失敗した場合の、設定の最後に成功したリビジョンへの自動ロールバックもサポートします。この場合、デプロイに失敗した最新のテンプレートはシステムで修正されないので、ユーザーがその設定の修正を行う必要があります。
4.2.1.5. コンテナー内でのコマンドの実行
コマンドをコンテナーに追加して、イメージの ENTRYPOINT
を却下してコンテナーの起動動作を変更することができます。これは、指定したタイミングでデプロイメントごとに 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. デプロイメントログの表示
手順
指定の
DeploymentConfig
オブジェクトに関する最新リビジョンのログをストリームするには、以下を実行します。$ oc logs -f dc/<name>
最新のリビジョンが実行中または失敗した場合には、コマンドが、Pod のデプロイを行うプロセスのログを返します。成功した場合には、アプリケーションの Pod からのログを返します。
以前に失敗したデプロイメントプロセスからのログを表示することも可能です。 ただし、これらのプロセス (以前のレプリケーションコントローラーおよびデプロイヤーの Pod) が存在し、手動でプルーニングまたは削除されていない場合に限ります。
$ oc logs --version=1 dc/<name>
4.2.1.7. デプロイメントトリガー
DeploymentConfig
オブジェクトには、クラスター内のイベントに対応する新規デプロイメントプロセスの作成を駆動するトリガーを含めることができます。
トリガーが DeploymentConfig
オブジェクトに定義されていない場合は、設定変更トリガーがデフォルトで追加されます。トリガーが空のフィールドとして定義されている場合には、デプロイメントは手動で起動する必要があります。
設定変更デプロイメントトリガー
設定変更トリガーにより、DeploymentConfig
オブジェクトの Pod テンプレートで設定の変更が検出されるたびに、新規のレプリケーションコントローラーが作成されます。
設定変更トリガーが DeploymentConfig
オブジェクトに定義されている場合は、DeploymentConfig
オブジェクト自体が作成された直後に、最初のレプリケーションコントローラーが自動的に作成され、一時停止されません。
設定変更デプロイメントトリガー
triggers: - type: "ConfigChange"
イメージ変更デプロイメントトリガー
イメージ変更トリガーにより、イメージストリームタグの内容が変更されるたびに、(イメージの新規バージョンがプッシュされるタイミングで) 新規レプリケーションコントローラーが作成されます。
イメージ変更デプロイメントトリガー
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
が指定される)、イメージ変更トリガーで参照されているイメージストリームタグがまだ存在していない場合、ビルドによりイメージがイメージストリームタグにインポートまたはプッシュされた直後に初回のデプロイメントプロセスが自動的に開始されます。
4.2.1.7.1. デプロイメントトリガーの設定
手順
oc set triggers
コマンドを使用して、DeploymentConfig
オブジェクトにデプロイメントトリガーを設定することができます。たとえば、イメージ変更トリガーを設定するには、以下のコマンドを使用します。$ oc set triggers dc/<dc_name> \ --from-image=<project>/<image>:<tag> -c <container_name>
4.2.1.8. デプロイメントリソースの設定
デプロイメントは、ノードでリソース (メモリーおよび一時ストレージ) を消費する Pod を使用して完了します。デフォルトで、Pod はバインドされていないノードのリソースを消費します。ただし、プロジェクトにデフォルトのコンテナー制限が指定されている場合には、Pod はその上限までリソースを消費します。
デプロイメントの最小メモリー制限は 12 MB です。Cannot allocate memory
Pod イベントのためにコンテナーの起動に失敗すると、メモリー制限は低くなります。メモリー制限を引き上げるか、またはこれを削除します。制限を削除すると、Pod は制限のないノードのリソースを消費できるようになります。
デプロイメントストラテジーの一部としてリソース制限を指定して、リソースの使用を制限することも可能です。デプロイメントリソースは、Recreate (再作成)、Rolling (ローリング) または Custom (カスタム) のデプロイメントストラテジーで使用できます。
手順
以下の例では、
resources
、cpu
、memory
、およびephemeral-storage
はそれぞれオプションです。type: "Recreate" resources: limits: cpu: "100m" 1 memory: "256Mi" 2 ephemeral-storage: "1Gi" 3
ただし、クォータがプロジェクトに定義されている場合には、以下の 2 つの項目のいずれかが必要です。
明示的な
requests
で設定したresources
セクション:type: "Recreate" resources: requests: 1 cpu: "100m" memory: "256Mi" ephemeral-storage: "1Gi"
- 1
requests
オブジェクトは、クォータ内のリソース一覧に対応するリソース一覧を含みます。
-
プロジェクトで定義される制限の範囲。
LimitRange
オブジェクトのデフォルト値がデプロイメントプロセス時に作成される Pod に適用されます。
デプロイメントリソースを設定するには、上記のいずれかのオプションを選択してください。それ以外の場合は、デプロイ Pod の作成は、クォータ基準を満たしていないことを示すメッセージを出して失敗します。
関連情報
- リソース制限および要求の詳細は、Understanding managing application memoryを参照してください。
4.2.1.9. 手動のスケーリング
ロールバック以外に、手動スケーリングにより、レプリカの数を詳細に管理できます。
Pod は oc autoscale
コマンドを使用して自動スケーリングすることも可能です。
手順
DeploymentConfig
オブジェクトを手動でスケーリングするには、oc scale
コマンドを使用します。たとえば、以下のコマンドは、frontend
DeploymentConfig
オブジェクトを3
に設定します。$ oc scale dc frontend --replicas=3
レプリカの数は最終的に、
DeploymentConfig
オブジェクトのfrontend
で設定した希望のデプロイメントの状態と現在のデプロイメントの状態に伝播されます。
4.2.1.10. DeploymentConfig オブジェクトからのプライベートリポジトリーへのアクセス
シークレットを DeploymentConfig
オブジェクトに追加し、プライベートリポジトリーからイメージにアクセスできるようにします。この手順では、OpenShift Container Platform Web コンソールを使用する方法を示します。
手順
- 新規プロジェクトを作成します。
- Workloads ページから、プライベートイメージリポジトリーにアクセスするための認証情報を含むシークレットを作成します。
-
DeploymentConfig
オブジェクトを作成します。 -
DeploymentConfig
エディターページで、Pull Secret を設定し、変更を保存します。
4.2.1.11. 特定のノードへの Pod の割り当て
ラベル付きのノードと合わせてノードセレクターを使用し、Pod の割り当てを制御することができます。
クラスター管理者は、プロジェクトに対して デフォルトのノードセレクターを設定して 特定のノードに Pod の配置を制限できます。開発者は、Pod
設定にノードセレクターを設定して、ノードをさらに制限することができます。
手順
Pod の作成時にセレクターを追加するには、
Pod
設定を編集し、nodeSelector
の値を追加します。これは、単一のPod
設定や、Pod
テンプレートに追加できます。apiVersion: v1 kind: Pod spec: nodeSelector: disktype: ssd ...
ノードセレクターが有効な場合に作成される Pod は指定されたラベルを持つノードに割り当てられます。ここで指定されるラベルは、クラスター管理者によって追加されるラベルと併用されます。
たとえば、プロジェクトに
type=user-node
とregion=east
のラベルがクラスター管理者により追加され、上記のdisktype: ssd
ラベルを Pod に追加した場合に、Pod は 3 つのラベルすべてが含まれるノードにのみスケジュールされます。注記ラベルには値を 1 つしか設定できないので、
region=east
が管理者によりデフォルト設定されているPod
設定にregion=west
のノードセレクターを設定すると、Pod が全くスケジュールされなくなります。
4.2.1.12. 異なるサービスアカウントでの Pod の実行
デフォルト以外のサービスアカウントで Pod を実行できます。
手順
DeploymentConfig
オブジェクトを編集します。$ oc edit dc/<deployment_config>
serviceAccount
とserviceAccountName
パラメーターをspec
フィールドに追加し、使用するサービスアカウントを指定します。spec: securityContext: {} serviceAccount: <service_account> serviceAccountName: <service_account>