Need a colleague to run an application without installing its tools and dependencies first? Package them in a container image. Docker uses the image to start a container: it supplies the application files and instructions for launching it. An image is the package; a container is a running instance made from that package. section 2.3 section 2.1
Run an existing image
Run `docker run diamol/ch02-hello-diamol:2e`. If the image is not available locally, Docker pulls it, then starts a container that prints a greeting and exits. For a separately managed pull, use `docker image pull diamol/ch03-web-ping:2e`; Docker Hub is the default registry for that image. section 2.1 section 3.1
An image is logically one package, but Docker stores it in layers. Pulled layers are assembled into the container’s filesystem. An image also holds metadata, including its build history. Layers can be shared by different images and containers, so applications built on the same runtime need not each store a separate copy of it. section 3.1 section 3.4
Listing 3.1 The web-ping Dockerfile
FROM diamol/node:2e ENV TARGET="blog.sixeyed.com" ENV METHOD="HEAD" ENV INTERVAL="3000" WORKDIR /web-ping COPY app.js . CMD ["node", "/web-ping/app.js"]
This Dockerfile packages a Node.js application with a base image, default environment values, a working directory, an application file, and a startup command. section 3.2
To make and check your own image:
- Write a Dockerfile. `FROM` selects a starting image; `COPY` adds files; `CMD` specifies what runs when a container starts. `ENV` and `WORKDIR` set defaults and a working directory. section 3.2
- In the application directory, build with `docker image build -t web-ping:v2 .`. Run a container from the resulting image, then inspect its behavior—for example, use `docker container logs` for the web-ping application. section 3.5 section 3.1
- Use `docker image history web-ping` to inspect build layers and `docker image ls` to compare image sizes. section 3.4
Build order matters. When a Dockerfile instruction or its copied input changes, Docker creates a new layer and reruns later instructions rather than reusing their cached layers. Put rarely changing instructions before frequently changing ones. For compiled applications, a multi-stage Dockerfile can build with tools such as Maven in one stage and copy the packaged application into a separate runtime image. section 3.5 section 4.2
Keep unnecessary files out of the image. Deleting files in a later layer can hide them from the container filesystem without reducing image size; copying only what is needed avoids that trap. Check disk use with `docker system df`: Docker does not automatically remove old images when you update containers. section 17.1
The same tested image can move through test and production while Docker Compose supplies different configuration for each environment. That keeps the packaged software unchanged; environment-specific behavior comes from the container platform. section 10.5
Try it yourself
Build an image for a small app, change one source file, and rebuild under a new tag. Compare `docker image history` before and after to see which layers changed. Then consider whether moving the frequently changed instruction later would improve cache reuse. section 3.5 section 3.4
