OpenShift DeploymentConfig Deprecation

TL;DR
- Alle DeploymentConfig (DC) Manifeste müssen demnächst in Deployment Manifeste migriert werden.
- DC ohne spezielle Anforderungen können einfach in Standard-Deployment geändert werden.
- Erweiterte Features sollten durch GitOps und Continuous Delivery Tools umgesetzt werden.
- Wir analysieren gerne eure Deployments, helfen bei der Migration und geben Hinweise zu Best Practices.

DeploymentConfig Manifeste bestimmen, wie Applikationen auf OpenShift ausgerollt werden. Sie definieren das Template für den Pod, welcher das Applikations-Container-Image als Container startet. Das DeploymentConfig gibt es seit der Version 3 von OpenShift. Es hat den Fokus auf ein schnelles Onboarding der Entwickler*in auf die OpenShift Container Plattform. Oft wurde es automatisch erzeugt, z.B. bei der Verwendung von der OpenShift CLI (oc new-app ...). Es war auch ein wichtiger Bestandteil der OpenShift Source-To-Image (S2I) Funktionalität, welche aus Sourcecode laufende Applikationen auf OpenShift erstellt hat.

Seit der OpenShift Version 4.1 wird empfohlen, anstatt der DeploymentConfig das Kubernetes Deployment Manifest zu verwenden. Das ist auch eine Best Practice für alle neu entwickelten Applikations-Deployments.

Wieso sollte ich migrieren?

Red Hat wird die DeploymentConfigs-API nicht mehr weiterentwickeln, weil sie auf veralteten Objekten basiert. Daher werden keine neuen Funktionen bereitgestellt und die Wartung ist auf sicherheitsrelevante und kritische Fehlerbehebung beschränkt. Langfristig werden die DeploymentConfig ganz aus OpenShift entfernt. Wir empfehlen seit OpenShift 4 immer die Kubernetes nativen Manifeste zu benutzen, wenn es keine triftigen Gründe für den Einsatz der OpenShift Alternative gibt. So können wir die Abhängigkeit auf eine Kubernetes Distribution auf ein Minimum beschränken oder gar auflösen.

Was muss ich bei der Migration beachten?

Bei Puzzle waren ca. 90% der DeploymentConfig generiert oder es wurden nur Basic Funktionalitäten verwendet.
Da ist meist ausreichend apiVersion, kind und selector anzupassen:

• apiVersion: v1 oder apiVersion: apps.openshift.io/v1 zu apiVersion: apps/v1
• kind: DeploymentConfig zu kind: Deployment
• spec.selector: zu spec.selector.matchLabels

apiVersion: apps.openshift.io/v1
kind: DeploymentConfig
metadata:
  name: pitc-demo
...
spec:
  selector:
    name: pitc-demo
...

Ändere zu:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: pitc-demo
...
spec:
  selector:
    matchLabels:
      name: pitc-demo
...

Wichtig ist auch die Service Manifeste anzupassen, welche auf dieses Deployment zeigen.

In spec.selector.deploymentconfig in spec.selector.name ändern.

apiVersion: v1
kind: Service
metadata:
  labels:
    app: pitc-demo
  name: pitc-demo
  namespace: pitc-demo
spec:
  selector:
    deploymentconfig: pitc-demo
...

apiVersion: v1
kind: Service
metadata:
  labels:
    app: pitc-demo
  name: pitc-demo
  namespace: pitc-demo
spec:
  selector:
    name: pitc-demo
...

Triggers

Über Triggers können in OpenShift Deployments automatisch gestartet werden. Das wird über das spec.triggers Feld vom Manifest konfiguriert. Heutzutage werden Deployments mit GitOps ausgelöst und Triggers sind somit hinfällig. Wer diese Funktionalität trotzdem noch benutzen möchte, kann das auf OpenShift weiterhin tun. Neu werden Trigger über Annotations konfiguriert.

Hier unser Beispiel mit einer Trigger Annotation:

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    image.openshift.io/triggers: '[{"from":{"kind":"ImageStreamTag","name":"my-app:latest"},"fieldPath":"spec.template.spec.containers[?(@.name==\"my-app\")].image"}]'
  name: my-app

Pro Tipp:

Das OpenShift CLI unterstützt uns weiterhin mit dem Hinzufügen von Triggers. Mit oc set triggers ... können Triggers auf DeploymentConfig oder Deployment Objekte gesetzt werden. Das Objekt müssen wir nicht direkt im OpenShift Cluster verändern, mit dem Parameter --dry-run -o yaml wird nur die resultierende Definition ausgegeben, welche wir in GitOps verwenden können.

Deployment Strategien

Die häufigsten Deployment-Strategien (spec.strategy.type) der DeploymentConfig werden auch vom Deployment unterstützt. Rolling oder Recreate Strategien können weiterhin verwendet werden.

Für die Custom Strategy gibt es keinen eins zu eins Ersatz. Wir empfehlen es mit dem Continuous Delivery Tool, wie z.B. Argo CD umzusetzen. Das Gleiche gilt für die Lifecycle Hooks.

Wer kann mich dabei unterstützen?

Wir von Puzzle ITC schauen uns gerne eure Deployments an und helfen bei der Migration. Dabei können wir auch Best Practices in den Bereichen von Application Deployment, Config Management und Delivery Pipelines weitergeben.

Auf der Red Hat Knowledgebase, welche auch mit einem gratis Account erreichbar ist, ist ein entsprechender Artikel zu finden: DeploymentConfig API is being deprecated in Red Hat OpenShift Container Platform 4.14.

Zusammenfassung

Wie bereits erwähnt, muss aktuell noch nichts überstürzt werden. Es ist jedoch sinnvoll, jetzt mit der Planung der Migration zu beginnen. Dabei kann auch geklärt werden, ob bereits GitOps im Einsatz ist oder ob dieser Schritt noch gemacht werden muss.

Wir können euch dabei unterstützen und gerne geben wir euch im ganzen Themengebiet der Deployments und der Delivery Pipeline Inputs zu Best Practices.