本記事は、Red Hat Advent Calendar 2023 の4日目です。
はじめに
2023/11 に GA された OpenShift 4.14 [1] から、DeploymentConfig リソースの利用が非推奨 (Deprecated) となりました。[2]
OpenShift 4 がリリースされた頃から Deployment の利用が推奨されていたため、最近になって OpenShift を利用し始めたユーザーの場合 DeploymentConfig を利用していないことが多いと思いますが、ミドルウェアの Template にて DeploymentConfig が利用されていたり、以前は oc new-app コマンドにて DeploymentConfig リソースが生成されていたため、OpenShift 3 の頃から OpenShift を利用しているユーザーの場合には DeploymentConfig を利用していることもあると思います。
本記事では、そもそも DeploymentConfig とは何かの説明から、現在 DeploymentConfig を利用している場合の対処案までを記載したと思います。
Deployment と DeploymentConfig の違い
そもそも DeploymentConfig とは何かから簡単に説明します。
DeploymentConfig とは、Kubernetes における Deployment よりも先行して開発されていましたが、アップストリームに取り込まれなかったため OpenShift 固有となってしまったリソースです。
基本的には Deployment と似たような機能を持っており、spec.template に Pod template を記載し、spec.replicas に指定した数のレプリカ数の Pod を起動します。
apiVersion: apps.openshift.io/v1
kind: DeploymentConfig
metadata:
name: frontend
spec:
replicas: 5
selector:
name: frontend
template: { ... }
triggers:
- type: ConfigChange 1
- imageChangeParams:
automatic: true
containerNames:
- helloworld
from:
kind: ImageStreamTag
name: hello-openshift:latest
type: ImageChange 2
strategy:
type: Rolling
しかし、内部挙動にはいくつかの違いがあり、Deployment リソースを適用すると ReplicaSet が生成されるのに対して、DeploymentConfig リソースを適用すると ReplicationController が生成されます。
また、Deployment では Pod のロールアウトが Kubernetes Controller から実行されるのに対して、DeploymentConfig ではデプロイ用の Pod が起動してロールアウトの管理を行います。(以下のコマンド実行例では eap-app-1-deploy がデプロイ用の Pod です。)
$ oc get deploymentconfig
NAME REVISION DESIRED CURRENT TRIGGERED BY
eap-app 1 1 1 config,image(eap-app:latest)
$ oc get replicationcontroller
NAME DESIRED CURRENT READY AGE
eap-app-1 1 1 1 92s
$ oc get deploymentconfig eap-app -o=jsonpath='{.spec.replicas}'
1
$ oc get pod
NAME READY STATUS RESTARTS AGE
eap-app-1-deploy 0/1 Completed 0 104s
eap-app-1-fbjhb 1/1 Running 0 93s
eap-app-2-build 0/1 Completed 0 3m2s
eap-app-build-artifacts-1-build 0/1 Completed 0 9m2s
また、Deployment には存在せず DeploymentConfig のみに存在する機能がいくつか存在するため、DeploymentConfig から Deployment への移行時にはこれらの機能を利用しているかにより移行の難易度が変わります。[3]
- デプロイに失敗した場合の自動ロールバック機能
- spec.template の設定変更による自動デプロイの実行
- デプロイに失敗したときなどのフック (Lifecycle Hooks) の設定
- デプロイ戦略のカスタマイズ
Deployment の利用が推奨
前述した通り、OpenShift 4.14 以降、DeploymentConfig リソースの利用は非推奨となりました。DeploymentConfig は引き続きサポートされますが、新規インストールでの DeploymentConfig の利用は推奨されません。
DeploymentConfig では、今後セキュリティ関連の重大な問題のみ修正され、新しい機能が追加されることもなくなります。
本記事の執筆時点 (2023/11) において、非推奨となった DeploymentConfig を削除する計画はありませんが、前述した様々な理由により Deployment の利用が推奨されるという状況です。[4]
DeploymentConfig を利用している場合の対処案
前述した通り、DeploymentConfig のみに存在する機能を利用しているかにより、DeploymentConfig を利用している場合の対処方法は異なります。
DeploymentConfig では ImageStream の変更を検知して自動的にデプロイを実行することができますが、これと同等の機能を Deployment においても実現することが可能です。[5]
Deployment の metadata.annotations に以下のように設定することにより、Deployment においても ImageStream の変更をトリガにデプロイを自動実行することができます。
apiVersion: apps/v1
kind: Deployment
metadata:
annotations:
image.openshift.io/triggers: '[{"from":{"kind":"ImageStreamTag","name":"example:latest"},"fieldPath":"spec.template.spec.containers[?(@.name==\"container\")].image"}]'
# ...
もしくは、上記のマニフェストの編集が難しい場合には、以下のコマンドを実行することで同等の設定を行うことも可能です。
$ oc set triggers deploy/example --from-image=example:latest -c web
また、自動デプロイ実行以外の DeploymentConfig にのみ存在する機能 (自動ロールバック機能、Lifecycle Hooks 機能、カスタム戦略) は、残念ながら Deployment だけで同等の機能を実現する方法をありません。
OpenShift GitOps や Helm を使ってマニフェストを管理することが増えていますので、これらの他のツールと組み合わせることで同等の機能を実現するか、この際に Kubernetes の標準ではない DeploymentConfig 固有の機能の利用を辞めることを推奨します。
さいごに
本記事では、DeploymentConfig が OpenShift 4.14 以降では非推奨となったことや、DeploymentConfig を利用している場合の対処案などについて説明しました。
前述の通り、非推奨となったからといってサポートは継続しますしすぐに削除される予定もありませんが、計画的な Deployment への移行をご検討ください。
参考
[1] https://cloud.redhat.com/blog/red-hat-openshift-4.14-is-now-available
[2] https://docs.openshift.com/container-platform/4.14/release_notes/ocp-4-14-release-notes.html#ocp-4-14-deployment-config-deprecated
[3] https://access.redhat.com/documentation/ja-jp/openshift_container_platform/4.14/html/building_applications/deployments#deployments-comparing-deploymentconfigs_what-deployments-are
[4] https://access.redhat.com/articles/7041372
[5] https://access.redhat.com/documentation/ja-jp/openshift_container_platform/4.14/html/images/images-triggering-updates-imagestream-changes-kubernetes-cli_triggering-updates-on-imagestream-changes