Please see these pages for more information:
https://docs.docker.com/reference/dockerfile/
https://docs.docker.com/build/building/best-practices/

Docker introduced new backend for builing images (buildkit) which doesn't expose intermediate containers.
To show intermediate containers, set the environment variable DOCKER_BUILDKIT before the docker build command: $ DOCKER_BUILDKIT=0 docker build [OPTIONS] PATH | URL | -

Dockerfile contains builds commands that are needed to create a Docker image. For each build command in the Dockerfile, Docker will generate a new filesystem layer. An image is a combination of all filesystem layers created by the build commands of the Dockerfile. Each layer is mapped to a specific build command in the Dockerfile.

For a new created image, Docker will execute all the build commands in the Dockerfile. When building an already built image, Docker will always execute all the build commands that are bellow a parent build command that was either changed or it generated a new filesystem layer. Otherwise Docker will use the filesystem layer from its cache.

Best practices: A build command that might create a new filesystem layer every time it's executed (e.g., update OS, library) should be placed at the bottom of the Dockerfile or placed in a parent Dockerfile and use the generated image as a parent image for the descendant Dockerfiles. The parent image can be re-built only when needed.

Best practices: If possible, multiple build commands should be combined in one single build command.

Example of a Dockerfile:
FROM ubuntu:20.04 RUN apt update RUN apt install -y curl RUN apt install -y nginx RUN groupadd -r mtitek --gid=1001 RUN useradd -r -g mtitek --uid=1001 mtitek
Build Dockerfile:
$ docker build -t ubuntu-nginx:20.04 . Sending build context to Docker daemon 2.048kB Step 1/6 : FROM ubuntu:20.04 20.04: Pulling from library/ubuntu 3ff22d22a855: Pull complete ... Digest: sha256:5d1d5407f353843ecf8b16524bc5565aa332e9e6a1297c73a92d3e754b8a636d Status: Downloaded newer image for ubuntu:20.04 ---> 1e4467b07108 Step 2/6 : RUN apt update ---> Running in 232b13119cfb ... Removing intermediate container 232b13119cfb ---> eb020e044f5a Step 3/6 : RUN apt install -y curl ---> Running in 6db1a5ce5418 ... Removing intermediate container 6db1a5ce5418 ---> cd922ddc54c1 Step 4/6 : RUN apt install -y nginx ---> Running in 43a520ceb080 ... Removing intermediate container 43a520ceb080 ---> aa834b9addb2 Step 5/6 : RUN groupadd -r mtitek --gid=1001 ---> Running in 4b12986513b1 Removing intermediate container 4b12986513b1 ---> 68bf80375948 Step 6/6 : RUN useradd -r -g mtitek --uid=1001 mtitek ---> Running in d4eb29e56387 Removing intermediate container d4eb29e56387 ---> 96b9b2a5d5bd Successfully built 96b9b2a5d5bd Successfully tagged ubuntu-nginx:20.04
Let's inspect the layers of the ubuntu image (ubuntu:20.04):
$ docker inspect --format '{{json .RootFS.Layers}}' ubuntu:20.04 [ "sha256:ce30112909569cead47eac188789d0cf95924b166405aa4b71fb500d6e4ae08d", "sha256:8eeb4a14bcb4379021c215017c94800a848a8203a8ce76aa1bd211d4c995f792", "sha256:a37e74863e723df4ddd599ef1b7d9a68e2301794a8c37c2370f8c2c8993ef72c", "sha256:095624243293a7dfdb582f8471d6e2d9d7772dd621bc57906b034c59f388ebac" ]
Let's inspect the layers of the new image (ubuntu-nginx:20.04):
$ docker inspect --format '{{json .RootFS.Layers}}' ubuntu-nginx:20.04 [ "sha256:ce30112909569cead47eac188789d0cf95924b166405aa4b71fb500d6e4ae08d", "sha256:8eeb4a14bcb4379021c215017c94800a848a8203a8ce76aa1bd211d4c995f792", "sha256:a37e74863e723df4ddd599ef1b7d9a68e2301794a8c37c2370f8c2c8993ef72c", "sha256:095624243293a7dfdb582f8471d6e2d9d7772dd621bc57906b034c59f388ebac", "sha256:990f9d12449d20d10e48e83a8882a69c25848a615c571d9702fbacc98ff08cf5", "sha256:12f4a1ff23cb6bc755ae3b28374d639d5381c4f775795ef02d2551bd2728a5ac", "sha256:b3f98fc07babfcad7f251a2aa105232d2b14c63948e48c3df8498377e179199b", "sha256:0af660f0ef73a30d73ffef848c11a3ab09f9cdcca51a86866f90952d041bc411", "sha256:7ad5b6cb70b0d2c21e3a922ba4d529e354b182d25af0b4fa57928105efebd6cb" ]
Note that the image 'ubuntu-nginx:20.04' inherit all the layers of the parent image 'ubuntu-nginx:20.04'.

The five new layers are the ones created by executing the build steps in the Dockerfile.

Let's optimize a bit the Dockerfile we used above:
FROM ubuntu:20.04 RUN groupadd -r mtitek --gid=1001 && useradd -r -g mtitek --uid=1001 mtitek RUN apt update && apt install -y curl && apt install -y nginx && rm -rf /var/lib/apt/lists/*
Build Dockerfile:
$ docker build -t ubuntu-nginx:20.04 . Sending build context to Docker daemon 3.072kB Step 1/3 : FROM ubuntu:20.04 20.04: Pulling from library/ubuntu 3ff22d22a855: Pull complete ... Digest: sha256:5d1d5407f353843ecf8b16524bc5565aa332e9e6a1297c73a92d3e754b8a636d Status: Downloaded newer image for ubuntu:20.04 ---> 1e4467b07108 Step 2/3 : RUN groupadd -r mtitek --gid=1001 && useradd -r -g mtitek --uid=1001 mtitek ---> Running in 0c2873dba86c Removing intermediate container 0c2873dba86c ---> 72509963272b Step 3/3 : RUN apt update && apt install -y curl && apt install -y nginx && rm -rf /var/lib/apt/lists/* ---> Running in 7cf20dc973f0 ... ---> 863c3eccbaad Successfully built 863c3eccbaad Successfully tagged ubuntu-nginx:20.04
Let's inspect the layers of the new image:
$ docker inspect --format '{{json .RootFS.Layers}}' ubuntu-nginx:20.04 [ "sha256:ce30112909569cead47eac188789d0cf95924b166405aa4b71fb500d6e4ae08d", "sha256:8eeb4a14bcb4379021c215017c94800a848a8203a8ce76aa1bd211d4c995f792", "sha256:a37e74863e723df4ddd599ef1b7d9a68e2301794a8c37c2370f8c2c8993ef72c", "sha256:095624243293a7dfdb582f8471d6e2d9d7772dd621bc57906b034c59f388ebac", "sha256:c17d2b5a59c3fd4513eedbe4f93b42d076185d0c62d82049aca9c9b8a4fc9695", "sha256:234f21cc6c8c5b9dc81ffc447ab9fefae9b8ee8751ea1cd93ad4df9da6897ab4" ]
First note that the build steps were reduced to only three steps. This result to only two new layers created for the new image instead of five with the 'non-optimized' Dockerfile.

Note that the steps, in the Dockerfile, to create the mtitek group and user are placed before the installation instructions of curl and nginx. This is to show that the instructions that are more likely to generate the same exact result, no matter how many time they are executed, should be placed at the top of the Docker file. This will save time when building the image frequently.

Note also the instruction rm -rf /var/lib/apt/lists/*, which is helpful to save some space disk on the final image.

The USER instruction set the user that will be used to run the processes inside the container. By default, if the USER instruction is not set, docker run all processes as root.

Let's check the current user running on the Docker host:
$ id uid=1000(mtitek) gid=1000(mtitek) groups=1000(mtitek)
Let's first try a Dockerfile without the USER instruction:
FROM ubuntu:20.04
Let's build the Dockerfile:
$ docker build -t ubuntu-withoutuser:20.04 .
Let's check the user within the container:
$ docker run --rm -ti ubuntu-withoutuser:20.04 /bin/bash -c 'id' uid=0(root) gid=0(root) groups=0(root)
Let's try now a Dockerfile with the USER instruction:
FROM ubuntu:20.04 RUN groupadd -r tek --gid=1000 && useradd -r -g tek --uid=1000 mti USER mti
Let's build the Dockerfile:
$ docker build -t ubuntu-withuser:20.04 .
Let's check the user within the container:
$ docker run --rm -ti ubuntu-withuser:20.04 /bin/bash -c 'id' uid=1000(mti) gid=1000(tek) groups=1000(tek)
Note that the Dockerfile create the group "tek" with the group id (gid) "1000". It also create the user "mti" with the user id (uid) "1000" and the group id (gid) "1000". The image that we create from this Dockerfile will run with the user "mti".

Note that the group and user names are, more or less, just friendly names. The important part is the uid and gid. These two elements will map the container's user uid and group gid to the host's user uid and group gid. So, in the above example, the container will be running using the same uid and gid that match the ones of the Docker host. In the host I am using the uid 1000 and gid=1000 are mapped to the user and group "mtitek". This means that the container's user will get the same privileges that the user "mtitek" has.

Let's create a Dockerfile that will use the VOLUME instruction to mount a local directory. I will adapt a bit the nginx Dockerfie to print the logs in a directory.

Here's the Dockerfile (this is for demo purposes only):
FROM nginx:1.19.1 #removing the redirection to stdout/stderr to allow writing logs to directory RUN rm -f /var/log/nginx/access.log && rm -f /var/log/nginx/error.log VOLUME /var/log/nginx
Let's build the Dockerfile:
$ docker build -t nginx-mounted-log-dir:1.19.1 .
Let's create a local directroy:
$ mkdir ~/nginx-loc-dir
Let's run the nginx image (the host's directory ~/nginx-loc-dir is mounted to the container's directory /var/log/nginx):
$ docker run -d -P -v /home/mtitek/nginx-loc-dir:/var/log/nginx nginx-mounted-log-dir:1.19.1 0a6ea9efbc1f264287aa2b146d77423fd5d8e9070b7aebd0a4d36d148631c16c
Check the nginx process:
$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 8491a320ecd8 nginx-mounted-log-dir:1.19.1 "/docker-entrypoint.…" 8 seconds ago Up 6 seconds 0.0.0.0:32770->80/tcp zen_shtern
Let's access nginx at the published port 8080:
$ curl http://localhost:32770
Check the nginx logs:
$ ls -al ~/nginx-loc-dir/ -rw-r--r-- 1 root root 91 access.log -rw-r--r-- 1 root root 0 error.log
$ cat ~/nginx-loc-dir/access.log 172.17.0.1 - - [03/Aug/2020:03:22:16 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.58.0" "-"

The WORKDIR instruction set the working directory for the remaining build instructions.
This working directory will also be the default directory for all processes running inside the container.

Let's try a Dockerfile with the WORKDIR instruction set a '/tmp':
FROM ubuntu:20.04 WORKDIR /tmp
Let's build the Dockerfile:
$ docker build -t ubuntu-withworkdir:20.04 .
Let's check the working directory within the container:
$ docker run --rm -ti ubuntu-withworkdir:20.04 /bin/bash -c 'pwd' /tmp