Skip to content

Docker

Role in the Platform

Docker images package exporters and supporting services with their runtime dependencies. Exporter repositories own their Dockerfiles; Harness builds and tags the images, an approved registry stores them, and Helm values select the version deployed to Kubernetes.

graph LR
    Repo["Service Repository"] --> Build["Harness Build and Scan"]
    Build --> Image["Immutable Image"]
    Image --> Registry["ECR / Artifactory"]
    Registry --> Values["Helm Environment Values"]
    Values --> K8s["Webex Kubed"]

Image Identification

The historical Harness convention combines the short Git commit SHA with the pipeline build number, for example <short-sha>-<build-number>. Treat the registry digest as the immutable identity when proving exactly what ran.

Record all three during a deployment:

  • source commit;
  • image tag;
  • image digest deployed by Kubernetes.

Local Validation

Use the owning repository's build command. A typical non-production validation is:

docker build --tag <service>:local .
docker image inspect <service>:local
docker run --rm --env-file <non-secret-test-env> <service>:local

Do not bake credentials, inventory files, private certificates, or customer data into an image or build layer. Use a minimal approved base image, pin dependencies according to repository policy, run as a non-root user where supported, and preserve health endpoints expected by the Helm chart.

Release and Rollback

  1. Merge tested source code.
  2. Confirm the Harness pipeline produced and scanned the intended image.
  3. Confirm the image exists in the expected registry and capture its digest.
  4. Change the environment image tag through the Helm configuration repository.
  5. Verify the Kubernetes rollout and telemetry.
  6. Roll back by restoring the last known-good tag through source control.

Avoid mutable tags such as latest for production because they prevent reliable audit and rollback.

Troubleshooting

Symptom Check
ImagePullBackOff Registry path, tag, pull credentials, and network access
Starts locally but fails in Kubed Architecture, user permissions, mounted config, probes, resource limits
Old code still running Deployed digest, image pull policy, and environment values revision
Image rejected Vulnerability/license scan and approved base-image policy
Build unexpectedly large Build context, copied artifacts, and multi-stage build boundaries

See Harness, Artifactory, and Helm for the surrounding delivery stages.