Pull a Docker image and you may see several downloads rather than one large file. Each download is an image layer. Docker stores the layers separately, then assembles them into the filesystem a container sees. An image can therefore be one thing to use while consisting of many layers underneath. section 3.1
Layers make sharing practical. An application image built FROM a Node.js base image uses that base image’s layers, including its runtime, rather than needing a separate copy for every image or container. Run `docker image history web-ping` to see the build history and the instructions associated with its layers; use `docker system df` to check physical disk usage. section 3.4 section 17.1
A Dockerfile builds layers in sequence. A `COPY` instruction can add application files; a build-time command saves its filesystem changes in a layer. If an instruction and its inputs match an earlier build, Docker can reuse the cached layer. Change a file copied midway through the Dockerfile, though, and Docker rebuilds that layer and the instructions after it. section 3.5 section 4.0
Listing 3.2 The optimized web-ping Dockerfile
FROM diamol/node:2e
CMD ["node", "/web-ping/app.js"]
ENV TARGET="blog.sixeyed.com" \
METHOD="HEAD" \
INTERVAL="3000"
WORKDIR /web-ping
COPY app.js .
Notice that the optimized Dockerfile places the application’s `COPY app.js .` after instructions less likely to change. Editing the JavaScript file then leaves more earlier layers eligible for cache reuse. section 3.5
Layers also explain a size trap: copying an unneeded directory and deleting it in a later `RUN` instruction hides it from the merged filesystem, but does not remove its earlier layer from the image. Copy only the files needed at runtime instead. Shared layers save downloads and disk space, but old, unused layers can still accumulate; inspect usage with `docker system df`. section 17.1
Two containers, different files
Run `docker container run --name rn1 diamol/ch06-random-number:2e` and repeat with `--name rn2`. Copy `/random/number.txt` from each container with `docker container cp` and compare the results. Both start from the same image layers, but each container’s file changes remain separate. A container also has its own writable layer; removing it loses data kept there. section 6.1 section 6.5
Think of image layers as the reusable starting filesystem, not a place for persistent application data. Docker combines them with a container’s writable layer and, when configured, mounts into one visible filesystem. A volume is an option when data must survive replacement of the container. section 6.5
