Building and Inspecting a Docker Image
A Docker image is an immutable application package; a container is a running instance. Build from a reviewed Dockerfile or use a trusted pinned image, then inspect configuration, privileges, persistence, and health before production.
What You Will Be Able to Decide
- Explain the role of building and inspecting a docker image in a self-hosted system.
- Apply the procedure to a real open-source deployment.
- Recognise unsafe defaults and verify the resulting control.
- Record enough evidence for another operator to repeat or recover the work.
Containers make an application portable by packaging its runtime and dependencies. They do not make unfamiliar code trustworthy or persistent data safe.
A Dockerfile describes how an image is assembled. Each build receives a context: the files made available to its instructions. Careless contexts can include secrets or unnecessary data even when the final application does not need them.
The production question is not simply whether the container starts. It is whether the image is identifiable, runs with proportionate privileges, exposes the expected process, and stores state outside its disposable filesystem.
Technical term
Container image
A versioned, read-only package containing an application filesystem, runtime, metadata, and default process.
An image is a sealed machine template; a container is one powered-on machine created from that template.
The Working Model
Prefer official project images or a transparent build from the upstream source. Pin a release, inspect its Dockerfile and entrypoint, and check whether the registry publishes provenance, signatures, or vulnerability information.
Use `.dockerignore` to keep `.git`, `.env`, backups, and local artefacts out of the build context. Build-time credentials must use BuildKit secret or SSH mounts; build arguments and environment variables are not appropriate secret stores because they can persist in image metadata or layers.
Run the application as a non-root user where the project supports it. Add a meaningful health check and declare only the container ports the process actually listens on. Health is evidence about application readiness, not merely evidence that a process exists.
Implementation Procedure
- Read the upstream Dockerfile, entrypoint, supported tags, architecture, and expected data paths.
- Create a `.dockerignore` before building locally.
- Build with a specific tag and record the resulting image identifier.
- Inspect the image configuration, user, entrypoint, environment names, and exposed ports.
- Run it with no production data, review logs and health, then stop and recreate it to prove the container itself is disposable.
docker build --pull -t example-app:1.0.0 .
docker image inspect example-app:1.0.0
docker run --rm --name example-app-test -p 127.0.0.1:8080:3000 example-app:1.0.0
docker logs example-app-testControlled Practice and Fragile Practice
Verification and Recovery Evidence
- The image tag and digest are recorded.
- The container reaches healthy state without privileged mode or unnecessary host mounts.
- Recreating the container preserves only the state deliberately stored in volumes or external services.
Warning Signs
- The image source and version cannot be traced.
- The container requires the Docker socket without a documented reason.
- A restart appears to delete user-created data.
Questions to Ask a Consultant
- Who publishes the image and which source revision produced it?
- Which paths contain persistent application data?
- What does the health check prove beyond process existence?
Key takeaway
Key Takeaway
Containers package software, not trust or continuity. Inspect the image, minimise privilege, and move every durable byte outside the disposable container.