Download the Ultimate Docker Cheat Sheet
Dockerfile: The first step in using Docker is writing a Dockerfile. It is an essential blueprint for constructing Docker images. It is a text file, is usually named “Dockerfile” without any extension, and contains a series of instructions. Each line in this file represents a new instruction, forming a stack of layers. Each layer is cache-able. When you build an image twice, it will use the cache. When you change a line in the file, it rebuilds all instructions after and including the change.
Image: Building a Dockerfile outputs a Docker image. You can think of an image like an executable. Just like clicking an icon (executable) on your desktop to launch an application. You can start an image to launch a container. The Docker image encapsulates your application code and all its dependencies. This includes the runtime and system libraries. It is a self-contained unit that ensures consistency and portability across various environments. For example, your development machine and your production server.
Container: This is a dynamic, running instance of a Docker image. An executed image spawns a container with the command in the Dockerfile. Important to note: one image can give life to many containers. If Linux is your operating system, the Docker container will run as a process on the host machine. If you have a Windows or macOS machine, docker will run in a virtual machine (VM). The container will use the same kernel, either the kernel of Linux or the VM on Windows or macOS. The container itself is not a virtual machine. The container cannot see other processes of the host and has its own file system. This is why it seems as it is a virtual machine. But in reality, it shares the kernel of the host machine (or the kernel of the VM).
A Dockerfile holds all the instructions to build, start and run your application. Every command that you otherwise need to execute manually is written in a single file. It starts by using a base image. This is usually a small Linux distribution like alpine. If you have to execute a binary, you should use
FROM [scratch](https://hub.docker.com/_/scratch/).
What Is A Multistage Dockerfile?
You can compose a Dockerfile with many stages. You can think of one stage, as one image. Furthermore, you can then use materials like files from one stage in another stage. A new stage always starts with the line FROM <base-image>. You name a stage using the as keyword.
A typical approach is to have a
builder stage, with a larger base image. This image holds all executables and libraries needed to build your source code.
The second stage is the serve stage and has a small base image. The benefit is fewer dependencies and libraries. Just enough to execute and serve your application.
With this approach, you make your final image both smaller and more secure. As the image size decreases and the image consists of fewer libraries. Fewer system libraries means it has a lower attack surface. Multistage Dockerfiles are not limited to this use case and can have more than two stages as well.
The Expose Instruction Does Not Actually Expose the Port 80 of This Image # This Is Documentation so That We Know Which Port We Need to Expose # We Do This When Starting the Container With the –Publish Flag Expose 80
Creating an image from a Dockerfile only requires the
docker buildcommand. Without specifying a name and tag, you can reference the image only by its image ID.
If You Want to Build Another Dockerfile in This Directory, Use the –File Flag # E.g., –File
$ Docker Build –File Dockerfile.client .
If you want to persist data between container starts, you need to use volumes.
There are two different volume types: named volumes and mounted volumes. Named volumes are completely handled by Docker, a mounted volume is managed by you. For a mounted volume, you need to specify the location on the host system where this data will be stored.