6.3. デプロイメントプロセスの管理
6.3.1. DeploymentConfig オブジェクトの管理
Red Hat OpenShift Service on AWS 4.14 では、DeploymentConfig
オブジェクトは非推奨になりました。DeploymentConfig
オブジェクトは引き続きサポートされていますが、新規インストールには推奨されません。セキュリティー関連の重大な問題のみが修正されます。
代わりに、Deployment
オブジェクトまたは別の代替手段を使用して、Pod の宣言的更新を提供します。
DeploymentConfig
オブジェクトは、Red Hat OpenShift Service on AWS Web コンソールの Workloads ページからか、または oc
CLI を使用して管理できます。以下の手順は、特に指定がない場合の CLI の使用法を示しています。
6.3.1.1. デプロイメントの開始
アプリケーションのデプロイメントプロセスを開始するために、ロールアウトを開始できます。
手順
既存の
DeploymentConfig
から新規デプロイメントプロセスを開始するには、以下のコマンドを実行します。$ oc rollout latest dc/<name>
注記デプロイメントプロセスが進行中の場合には、このコマンドを実行すると、メッセージが表示され、新規レプリケーションコントローラーはデプロイされません。
6.3.1.2. デプロイメントの表示
アプリケーションの利用可能なすべてのリビジョンに関する基本情報を取得するためにデプロイメントを表示できます。
手順
現在実行中のデプロイメントプロセスを含む、指定した
DeploymentConfig
オブジェクトに関する最近作成されたすべてのレプリケーションコントローラーの詳細を表示するには、以下を実行します。$ oc rollout history dc/<name>
リビジョンに固有の詳細情報を表示するには、
--revision
フラグを追加します。$ oc rollout history dc/<name> --revision=1
DeploymentConfig
オブジェクトおよびその最新バージョンの詳細は、oc describe
コマンドを使用します。$ oc describe dc <name>
6.3.1.3. デプロイメントの再試行
現行リビジョンの DeploymentConfig
がデプロイに失敗した場合、デプロイメントプロセスを再起動することができます。
手順
失敗したデプロイメントプロセスを再起動するには、以下を実行します。
$ oc rollout retry dc/<name>
最新リビジョンのデプロイメントに成功した場合には、このコマンドによりメッセージが表示され、デプロイメントプロセスは試行されません。
注記デプロイメントを再試行すると、デプロイメントプロセスが再起動され、新しいデプロイメントリビジョンは作成されません。再起動されたレプリケーションコントローラーは、失敗したときと同じ設定を使用します。
6.3.1.4. デプロイメントのロールバック
ロールバックすると、アプリケーションを以前のリビジョンに戻します。この操作は、REST API、CLI または Web コンソールで実行できます。
手順
最後にデプロイして成功した設定のリビジョンにロールバックするには、以下を実行します。
$ oc rollout undo dc/<name>
DeploymentConfig
オブジェクトのテンプレートは、undo コマンドで指定されたデプロイメントのリビジョンと一致するように元に戻され、新規レプリケーションコントローラーが起動します。--to-revision
でリビジョンが指定されない場合には、最後に成功したデプロイメントのリビジョンが使用されます。ロールバックの完了直後に新規デプロイメントプロセスが誤って開始されないように、
DeploymentConfig
オブジェクトのイメージ変更トリガーがロールバックの一部として無効にされます。イメージ変更トリガーを再度有効にするには、以下を実行します。
$ oc set triggers dc/<name> --auto
デプロイメント設定は、最新のデプロイメントプロセスが失敗した場合の、設定の最後に成功したリビジョンへの自動ロールバックもサポートします。この場合、デプロイに失敗した最新のテンプレートはシステムで修正されないので、ユーザーがその設定の修正を行う必要があります。
6.3.1.5. コンテナー内でのコマンドの実行
コマンドをコンテナーに追加して、イメージの ENTRYPOINT
を却下してコンテナーの起動動作を変更することができます。これは、指定したタイミングでデプロイメントごとに 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 # ...
6.3.1.6. デプロイメントログの表示
手順
指定の
DeploymentConfig
オブジェクトに関する最新リビジョンのログをストリームするには、以下を実行します。$ oc logs -f dc/<name>
最新のリビジョンが実行中または失敗した場合には、コマンドが、Pod のデプロイを行うプロセスのログを返します。成功した場合には、アプリケーションの Pod からのログを返します。
以前に失敗したデプロイメントプロセスからのログを表示することも可能です。 ただし、これらのプロセス (以前のレプリケーションコントローラーおよびデプロイヤーの Pod) が存在し、手動でプルーニングまたは削除されていない場合に限ります。
$ oc logs --version=1 dc/<name>
6.3.1.7. デプロイメントトリガー
DeploymentConfig
オブジェクトには、クラスター内のイベントに対応する新規デプロイメントプロセスの作成を駆動するトリガーを含めることができます。
トリガーが DeploymentConfig
オブジェクトに定義されていない場合は、設定変更トリガーがデフォルトで追加されます。トリガーが空のフィールドとして定義されている場合には、デプロイメントは手動で起動する必要があります。
設定変更デプロイメントトリガー
設定変更トリガーにより、DeploymentConfig
オブジェクトの Pod テンプレートで設定の変更が検出されるたびに、新規のレプリケーションコントローラーが作成されます。
設定変更トリガーが DeploymentConfig
オブジェクトに定義されている場合は、DeploymentConfig
オブジェクト自体が作成された直後に、最初のレプリケーションコントローラーが自動的に作成され、一時停止されません。
設定変更デプロイメントトリガー
kind: DeploymentConfig apiVersion: apps.openshift.io/v1 metadata: name: example-dc # ... spec: # ... triggers: - type: "ConfigChange"
イメージ変更デプロイメントトリガー
イメージ変更トリガーにより、イメージストリームタグの内容が変更されるたびに、(イメージの新規バージョンがプッシュされるタイミングで) 新規レプリケーションコントローラーが作成されます。
イメージ変更デプロイメントトリガー
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
が指定される)、イメージ変更トリガーで参照されているイメージストリームタグがまだ存在していない場合、ビルドによりイメージがイメージストリームタグにインポートまたはプッシュされた直後に初回のデプロイメントプロセスが自動的に開始されます。
6.3.1.7.1. デプロイメントトリガーの設定
手順
oc set triggers
コマンドを使用して、DeploymentConfig
オブジェクトにデプロイメントトリガーを設定することができます。たとえば、イメージ変更トリガーを設定するには、以下のコマンドを使用します。$ oc set triggers dc/<dc_name> \ --from-image=<project>/<image>:<tag> -c <container_name>
6.3.1.8. デプロイメントリソースの設定
デプロイメントは、ノードでリソース (メモリーおよび一時ストレージ) を消費する Pod を使用して完了します。デフォルトで、Pod はバインドされていないノードのリソースを消費します。ただし、プロジェクトにデフォルトのコンテナー制限が指定されている場合には、Pod はその上限までリソースを消費します。
デプロイメントの最小メモリー制限は 12 MB です。Cannot allocate memory
Pod イベントのためにコンテナーの起動に失敗すると、メモリー制限は低くなります。メモリー制限を引き上げるか、これを削除します。制限を削除すると、Pod は制限のないノードのリソースを消費できるようになります。
デプロイメントストラテジーの一部としてリソース制限を指定して、リソースの使用を制限することも可能です。デプロイメントリソースは、Recreate、Rolling または Custom のデプロイメントストラテジーで使用できます。
手順
以下の例では、
resources
、cpu
、memory
、およびephemeral-storage
はそれぞれオプションです。kind: Deployment apiVersion: apps/v1 metadata: name: hello-openshift # ... spec: # ... type: "Recreate" resources: limits: cpu: "100m" 1 memory: "256Mi" 2 ephemeral-storage: "1Gi" 3
ただし、クォータがプロジェクトに定義されている場合には、以下の 2 つの項目のいずれかが必要です。
明示的な
requests
で設定したresources
セクション: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 の作成は、クォータ基準を満たしていないことを示すメッセージを出して失敗します。
6.3.1.9. 手動のスケーリング
ロールバック以外に、手動スケーリングにより、レプリカの数を詳細に管理できます。
Pod は oc autoscale
コマンドを使用して自動スケーリングすることも可能です。
手順
DeploymentConfig
オブジェクトを手動でスケーリングするには、oc scale
コマンドを使用します。たとえば、以下のコマンドは、frontend
DeploymentConfig
オブジェクトを3
に設定します。$ oc scale dc frontend --replicas=3
レプリカの数は最終的に、
DeploymentConfig
オブジェクトのfrontend
で設定した希望のデプロイメントの状態と現在のデプロイメントの状態に伝播されます。
6.3.1.10. DeploymentConfig オブジェクトからのプライベートリポジトリーへのアクセス
シークレットを DeploymentConfig
オブジェクトに追加し、プライベートリポジトリーからイメージにアクセスできるようにします。この手順では、Red Hat OpenShift Service on AWS Web コンソールを使用する方法を示します。
手順
- 新しいプロジェクトを作成する。
-
Workloads
Secrets に移動します。 - プライベートのイメージリポジトリーにアクセスするための認証情報が含まれるシークレットを作成します。
-
Workloads
DeploymentConfigs に移動します。 -
DeploymentConfig
オブジェクトを作成します。 -
DeploymentConfig
オブジェクトエディターページで、Pull Secret を設定し、変更を保存します。
6.3.1.11. 異なるサービスアカウントでの Pod の実行
デフォルト以外のサービスアカウントで Pod を実行できます。
手順
DeploymentConfig
オブジェクトを編集します。$ oc edit dc/<deployment_config>
serviceAccount
とserviceAccountName
パラメーターをspec
フィールドに追加し、使用するサービスアカウントを指定します。apiVersion: apps.openshift.io/v1 kind: DeploymentConfig metadata: name: example-dc # ... spec: # ... securityContext: {} serviceAccount: <service_account> serviceAccountName: <service_account>