GlossaryContainer Image

Container Image

A container image is an immutable, packaged file containing application code, libraries, runtime, and configuration needed to start a container.

Table of Contents

Table of Contents

Further Reading

No items found.
No items found.
No items found.
No items found.
No items found.
No items found.

What Does Container Image Mean?

A container image is a packaged file containing everything needed to create a container. It includes application code, libraries, system tools, runtime, and configuration.

When a runtime executes the image, it becomes a live container. Images are immutable, so containers from the same image behave consistently everywhere.

Container Image vs. Container

Aspect Container Image Container
What it is A static blueprint A running instance
Changes Immutable once built Has a writable layer at runtime
Stored in Registries like Docker Hub or ECR Running on a host or node
Created by Building from a Dockerfile Running an image

How Container Images Work

  1. Build: a Dockerfile defines layers for the base OS, dependencies, and app code.
  2. Tag: versions get tags or digests for traceability.
  3. Push: images go to a registry such as Docker Hub, Amazon ECR, or Google Artifact Registry.
  4. Pull and run: runtimes pull the image and start containers from it.

Why Container Images Matter

  • Consistency: every container starts from the same source
  • Portability: laptops, CI/CD, and clusters run identical images
  • Traceability: registries version and tag every build
  • Automation: reproducible environments spin up on demand
  • Reproducible tests: tools always run with the same dependencies

Real-World Examples

  • B2B SaaS delivery: a SaaS team builds an image on every commit and promotes the same image through each environment
  • Test tools: JMeter, Postman, or Cypress packaged as images for repeatable runs
  • CI/CD workflows: images built, tagged, and deployed automatically
  • Security scanning: images checked for vulnerabilities before deployment

How Container Images Work with Testkube

Testkube runs tests from container images. Load testing with JMeter, API testing with Postman, and UI testing with Cypress each run from an image.

  • Pull from registries: public or private images come into your clusters
  • Run isolated pods: each execution uses its own pod from the image
  • Stay consistent: tests behave the same in every cluster
  • Bring your own: use custom images with specialized tools or dependencies

Best Practices for Container Images

  • Pin versions: reference tags or digests, not latest
  • Keep images lean: use minimal base images and multi-stage builds
  • Scan regularly: catch vulnerabilities in CI and registries
  • Sign images: verify trusted sources before running
  • Rebuild often: pick up patched base images

Frequently Asked Questions (FAQs)

What is the difference between a container image and a container?

A container image is the static blueprint. A container is the running instance created from it.

Where are container images stored?

In registries such as Docker Hub, Amazon ECR, Google Artifact Registry, or private registries.

Can container images be customized?

Yes. Teams build images with the tools, libraries, and settings their testing and deployments need.

Why are container images important for testing?

They make test tools run with the same dependencies every time, which reduces flakiness and improves reproducibility.

Does Testkube support custom images?

Yes. You can build your own images and reference them in Testkube workflows.

Related Terms and Concepts

No items found.