Images
Images für Container werden durch den Kunden selbst erstellt. Dies kann außerhalb von OpenShift (externe Imageregistries) oder mithilfe von build-Pipelines innerhalb von OpenShift passieren. Eine eigene Registry in der externe oder selbst gebaute Images gespeichert und abgerufen werden können, wird in OpenShift bereitgestellt.
OpenShift spezifische Anforderungen
Da OpenShift im Vergleich zu Kubernetes deutlich striktere Sicherheitsrichtlinien anwendet muss der Kunde sicherstellen, dass seine Applikation mit OpenShift kompatibel ist. Hier ist folgendes Dokument zu empfehlen.
Pods werden mit einem Security Context Constraint verknüpft - die Auflistung der Security Context Constraints findet man hier. Per Default wird der Security Context Constraint restricted-v2 verwendet - hier können im Ausnahmefall auch andere Security Context Constraints verwendet werden, dies muss jedoch von Fall zu Fall entschieden werden. Auf einem Multitenantcluster ist die Security Context Constraint „anyuid“ jedenfalls ausgeschlossen.
Source 2 Image (S2I)
In OpenShift gibt es die Möglichkeit, Programmcode ohne vorherige Containerisierung direkt in Images zu verpacken (Source 2 Image (S2I)). Hierfür gibt es eigene, von Red Hat unterstützte Images, das Konzept wird hier erklärt.
Base Images
Dem Kunden steht es frei jedes beliebige Base Image für seine Container zu verwenden. Mit der Verwendung von OpenShift ist es jedoch auch möglich von Red Hat gewartete rhel-Images abzurufen - siehe catalog.redhat.com.
Um das Lizenzthema rund um Container-Images zu lösen, bietet Red Hat das Universal Base Image an, das frei (auch ohne Red Hat Lizenz) verwendet werden kann. Siehe dazu auch den folgenden Blogbeitrag. Der Vorteil in der Verwendung eines Universal Base Image im Zusammenhang mit TopContainer liegt im Support durch Red Hat.