Images

Images für Container werden vom Kunden selber erstellt. Dies passiert entweder außerhalb von OpenShift (externe Imageregistries) oder mithilfe von build-Pipelines innerhalb von OpenShift. Eine eigene Registry in der externe oder selbst gebaute Images gespeichert und abgerufen werden können, wird automatisch in OpenShift bereitgestellt.

OpenShiftspezifische Anforderungen

Da OpenShift einige Sicherheitsfeatures verwendet muss der Kunde sicherstellen, dass seine Applikation mit einem OpenShiftCluster 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 in Images zu verpacken - dies geschieht durch von Red Hat unterstützte S2I-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 auch das freie Universal Base Image an. Dieses kann frei verteilt werden, auch ohne Red Hat Lizenz. Siehe den folgenden Blogbeitrag Der Vorteil in der Verwendung der Universal Base Image im Zusammenhang mit TopContainer liegt im Support durch Red Hat.

Von Interesse ist eventuell auch die öffentlich erreichbare Seite quay.io welche das Red Hat Gegenstück zu Dockerhub ist.