Container-based deployments

Key Concepts of Container-Based Deployments in OpenShift

Container-based deployments in OpenShift are centered around running your own pre-built container images (from Dockerfile or other image build systems), rather than relying on Source-to-Image (S2I). In practice this means:

• You bring a container image (from a registry).
• You define how that image should be run (environment, resources, storage, networking).
• OpenShift schedules and manages pods based on this image using its Kubernetes-native primitives (e.g. Deployments/DeploymentConfigs, ReplicaSets, Pods).

This chapter focuses on how to work with existing container images in OpenShift, not on how to build them or on the general application deployment concepts already covered elsewhere.

Image Sources and Registries

In a container-based deployment you typically pull images from:

• Public registries: e.g. quay.io, docker.io, ghcr.io.
• Private registries: enterprise registry, vendor-specific registries.
• Internal OpenShift registry: the cluster’s own image registry.

Typical reference forms:

• Public: docker.io/library/nginx:1.25
• Quay: quay.io/org/app:latest
• Internal: image-registry.openshift-image-registry.svc:5000/<project>/<image>:tag (or via image stream references).

For private registries, you usually need:

• Image pull secrets (Secret of type kubernetes.io/dockerconfigjson).
• Association of that secret with the service account used by your pods (e.g. default or a custom service account).

This enables OpenShift to authenticate when pulling images for your pods.

Pods from Container Images

The most basic container-based deployment in OpenShift is a pod that directly references an image.

Example minimal pod spec:

apiVersion: v1
kind: Pod
metadata:
  name: my-nginx
spec:
  containers:
  - name: nginx
    image: quay.io/example/my-nginx:1.0
    ports:
    - containerPort: 80

In practice you rarely deploy “bare” Pods for real applications. Instead, you typically use higher-level controllers (Deployments or DeploymentConfigs) that manage pod lifecycles and scaling. However, understanding that these controllers ultimately run pods from container images is crucial.

Creating Container-Based Apps via `oc` and Web Console

OpenShift offers streamlined flows to deploy a container from an image without manually writing YAML.

Using `oc new-app` with an Image

oc new-app can create the full set of resources (Deployment/DeploymentConfig, Service, optionally Route) based on a container image:

• From an external registry:

  oc new-app quay.io/example/myapi:1.0 --name=myapi

• From the internal OpenShift registry:

  oc new-app image-registry.openshift-image-registry.svc:5000/myproj/myimage:latest \
    --name=myapp

Useful flags:

• --env KEY=VALUE – set environment variables.
• --strategy=docker or others – when used with a source repository; for pure image deployments, new-app just references the image.
• --labels key=value – add labels to generated resources.

oc new-app infers:

• Container port(s) from the image (if declared in the Dockerfile).
• The type of controller to generate (Deployment or DeploymentConfig, depending on OpenShift version and configuration).

Using the Web Console

The web console provides workflows such as:

• “Deploy Image” / “Container Image”:
• Choose image source: external registry, internal registry, or image stream.
• Specify image name, tag, and optional image pull secret.
• Set basic configuration (environment variables, ports, scaling).
• Optionally create a Route for external access.

This is a convenient way for beginners to deploy a container-based app without writing YAML or using the CLI.

Image Configuration vs OpenShift Configuration

Container images encode some defaults:

• Default command (CMD), entrypoint (ENTRYPOINT).
• Exposed ports (EXPOSE).
• Default user (USER).
• Environment variables (ENV).

OpenShift configuration can override or extend these defaults at deployment time.

Key distinctions:

• Image-level settings (baked into Dockerfile) are immutable once the image is built.
• Pod-level settings in OpenShift (YAML manifests) can:
• Override the command (command / args).
• Add or override environment variables.
• Add resource requests/limits, volumes, security context, etc.

This separation allows one image to be reused in multiple deployments with different runtime configurations (e.g. staging vs production).

Core Pod Settings for Container-Based Deployments

When deploying a container image in OpenShift, you typically configure several pod-level properties. These are configured in the pod template of your Deployment/DeploymentConfig and are specific to container-based deployments.

Container Ports and Services

Define which ports your container listens on so that Services and Routes can be created correctly:

spec:
  containers:
  - name: myapp
    image: quay.io/example/myapp:1.0
    ports:
    - name: http
      containerPort: 8080

• If you deploy using oc new-app, it may infer ports from the image; explicitly specifying ports gives you control and clarity.
• Named ports (e.g. name: http) make it easier for Services and Routes to target the correct port.

Environment Variables

Environment variables configure the container at runtime:

env:
- name: APP_ENV
  value: "production"
- name: DB_HOST
  valueFrom:
    configMapKeyRef:
      name: db-config
      key: host

For container-based deployments, it is common to parameterize the image using environment variables rather than rebuilding the image for each environment.

Resource Requests and Limits

Resource settings control scheduling and help prevent resource contention:

resources:
  requests:
    cpu: "100m"
    memory: "256Mi"
  limits:
    cpu: "500m"
    memory: "512Mi"

With pre-built images, you often do not control how resource-efficient the code is; appropriate requests and limits are important to ensure stability.

Command and Arguments Overrides

If the image’s default command is not suitable, you can override it:

command: ["python", "app.py"]
args: ["--log-level=info"]

Typical use cases:

• Running a different entrypoint for debugging.
• Switching between different modes of the same image (e.g. worker vs web process).
• Doing minimal “sidecar-like” functionality with a generic image.

Probes (Liveness/Readiness/Startup)

For container-based deployments, probes are critical to integrate the generic container with the OpenShift platform’s health model.

Example readiness and liveness probes:

livenessProbe:
  httpGet:
    path: /healthz
    port: http
  initialDelaySeconds: 20
  periodSeconds: 10
readinessProbe:
  httpGet:
    path: /ready
    port: http
  initialDelaySeconds: 10
  periodSeconds: 5

When you bring your own image, you must ensure the application exposes suitable endpoints or behaviors for these probes to work (HTTP endpoints, TCP ports, or command-based checks).

Image Pull Policy and Tag Strategy

How and when OpenShift pulls images affects rollout behavior and reproducibility.

Image Pull Policy

Common pull policies:

• IfNotPresent (default for tagged images): pull once per node then reuse.
• Always: pull on every pod start; suitable when using mutable tags like :latest but may slow down restarts and introduce unpredictability.
• Never: only use local images; rarely used in OpenShift clusters.

Example:

imagePullPolicy: IfNotPresent

Best practice for container-based deployments:

• Use immutable tags or image digests (e.g. app@sha256:...) for production.
• Prefer IfNotPresent with immutable tags to ensure reproducible deployments and faster pod startup.

Image Tags vs Digests

• Tags (e.g. 1.0, latest) are convenient but can be moved to point at different image versions.
• Digests (e.g. @sha256:...) uniquely identify an image version.

In OpenShift deployments:

• Use tags for human-friendly references but manage them carefully via your release process.
• For maximum stability, use image stream tags that track a specific digest, or reference digests directly.

Image Pull Secrets and Private Registries

For private registries, you need credentials to allow the cluster to pull your images.

Typical workflow:

1. Create a pull secret:

   oc create secret docker-registry my-regcred \
     --docker-server=registry.example.com \
     --docker-username=myuser \
     --docker-password=mypassword \
     --docker-email=me@example.com

2. Attach the secret to a service account:

   oc secrets link default my-regcred --for=pull

3. Ensure your deployment uses that service account (or default):

   spec:
     serviceAccountName: default

The pods using that service account will be able to pull from the configured registry during deployment.

Sidecar and Multi-Container Pods

Container-based deployments often use multiple containers in a single pod to extend or adapt a base image without rebuilding it.

Common patterns:

• Log sidecar: a container responsible for log shipping/processing.
• Proxy sidecar: an HTTP/TCP proxy (e.g. for mTLS, caching).
• Init container: pre-run setup tasks (e.g. database migrations, file downloads).

Example with a sidecar container:

spec:
  containers:
  - name: app
    image: quay.io/example/webapp:2.3
    ports:
    - containerPort: 8080
  - name: log-forwarder
    image: quay.io/example/log-sender:1.0
    args: ["--source=/var/log/app.log"]
    volumeMounts:
    - name: applogs
      mountPath: /var/log
  volumes:
  - name: applogs
    emptyDir: {}

This allows you to keep a standard “vanilla” app image but enrich its behavior within OpenShift by adding containers around it.

Integrating with OpenShift Services, Routes, and Storage

Container-based deployments in OpenShift are typically part of a larger platform configuration:

• Services: expose your pods internally (cluster IP) using the ports you defined in the pod spec.
• Routes/Ingress: expose HTTP/HTTPS endpoints to external clients.
• Persistent Volumes & Claims: attach storage for stateful parts (log directories, data directories, etc.).

From the perspective of a container-based deployment:

• Your image must read/write data at paths you mount from PVCs.
• The app must listen on the port and path that Services and Routes expect.
• Resource, probe, and configuration decisions must match the behavior and requirements of the image.

Best Practices for Container-Based Deployments in OpenShift

Specific to using “bring-your-own-image” style deployments:

• Design images for configuration via env vars: avoid rebuilding images for each environment.
• Expose health endpoints in your application to support probes.
• Use non-root, unprivileged containers where possible to align with OpenShift’s security model.
• Avoid mutable tags in production: use versioned tags or digests, and couple them with your release process.
• Keep images generic, customize in OpenShift:
• Use ConfigMaps/Secrets for config.
• Use environment variables, volumes, and sidecars for operational integration.
• Test image compatibility with OpenShift’s restrictions (Security Context Constraints, network model, etc.) early in your development process.

These practices ensure that your container-based deployments behave predictably in OpenShift and integrate smoothly with the platform’s orchestration, security, and observability features.