A container image is a built package for running an application with its dependencies. A Dockerfile supplies the build instructions; a container builder turns those instructions and the application code into an image. A container runtime runs the image as a container. This packaging makes applications easier to share and deploy across machines. section 1.4
Try an existing image before building one: `docker run nginx` runs the NGINX image. If it is not on your machine, Docker pulls it from Docker Hub, a container registry. To reach the running web server from your browser, you also need a port-mapping flag. section 5.1.1
To make an image for your own application:
- Choose a base image and version tag, such as `python:3.11.4` or `node:18.17.0`. Use that image in the Dockerfile’s `FROM` instruction. section 5.3.1 section 5.4
- Copy in the application, install its dependencies, and specify how it starts. Build the image with `docker build`, give it a tag, then run that tag with `docker run`. section 5.4.2
- Push a tagged image to Docker Hub when another machine needs it. You can publish both a version tag and `latest`; a GitHub Actions workflow can automate the build and push. section 5.5.1 section 7.3.1
Listing 5.13 Node.js Dockerfile
# Using the official Node.js image for the LTS version FROM node:18.17.0 # Set our app's working directory WORKDIR /app # copy the primary source code COPY ./src /app/src/ # copy the package.json and package-lock.json to # ensure we use the same dependencies COPY package.json /app/ COPY package-lock.json /app/ # copy the entrypoint.sh for running the app COPY conf/entrypoint.sh /app/ # install dependencies RUN npm install # make the entrypoint.sh executable RUN chmod +x entrypoint.sh # run our app CMD ["./entrypoint.sh"]
The Node.js Dockerfile shows the build recipe together: a versioned base image, copied source and dependency files, `npm install`, and the command that starts the app. section 5.4.2
A successful build does not guarantee that the container will run correctly. Test it before deployment. Dockerfile instructions also produce cached layers, which can speed later builds and transfers. If you build on an ARM machine for an x86 cloud server, check the build platform rather than assuming the image will run there. section 1.5 section 5.5.1
An image is the deployable package, not the whole deployment system. Docker can run one on a virtual machine; Kubernetes can deploy built images using a YAML manifest. Updating versions, scaling, and recovering from failures become harder when managing containers without Kubernetes. section 7.1 section 8.0 section 1.5
