1. Changing users and working directory
Let's look at a new type of interaction between Dockerfile instructions.
2. Dockerfile instruction interaction
The FROM, RUN, and COPY instructions only affect the file system, not each other. If we copy a start dot sh file from our local file system into an image, we can then use the RUN instruction to execute this file. The two instructions didn't change each other's behavior directly, but both used and changed the file system.
However, some instructions can influence other instructions directly. The WORKIDR instruction changes the working directory instructions are executed in, and the USER instruction changes which user is executing the following instructions.
3. WORKDIR - Changing the working directory
When using a Dockerfile instruction where we have to specify a path, we can always use a full path. For example, a path that starts at the root of the file system, like in the first example on the slide. When working with long paths, this can quickly become hard to read.
The alternative to using full paths is the WORKDIR instruction, which allows us to change the directory inside the image from which all subsequent instructions will be executed.
For the COPY instruction, we change the current path on which relative paths will be based.
4. RUN in the current working directory
Like with the COPY instruction, other Dockerfile instructions are influenced when the working directory is changed with WORKDIR. This includes the RUN and CMD instructions.
The effect on the RUN instruction is straightforward. The shell commands executed by the RUN instruction will be run in the directory set by WORKDIR.
This allows us to make the RUN instructions more readable and removes any unclarity about where the files we are running are located.
5. Changing the startup behavior with WORKDIR
The WORKDIR instruction also changes the working directory in which the shell command of the CMD instruction is run.
If a user of the image overrides the CMD, their replacement start command will also be run in the path set with WORKDIR.
6. Linux permissions
What you can do in a Linux operating system or OS depends on your permissions. Your permissions, in turn, are set by assigning you a user. For example, a data science user could be allowed to access the datasets folder while other users are not.
There is a unique user called the root user, which has all permissions on the system. Best practice is to use the root user to create one or more new users and only give these users the permissions required for specific tasks. Then we should stop using the root user and use these better-scoped users instead.
7. Changing the user in an image
When writing Dockerfiles, we should follow this best practice and not run everything as root.
The image we start our Dockerfile from will determine the user. For example, the ubuntu image uses the root user by default. Any RUN instructions we put in a Dockerfile starting from ubuntu will be run as root. This has the advantage that all folders are accessible, and we won't get errors about permissions when installing anything. However, it is unsafe as all instructions will run with full permissions.
The USER Dockerfile instruction allow us to change the user in the image. Any following instructions will be run as the user set by the USER instruction. It can be used multiple times, and the latest instruction will determine the user executing the following instructions.
8. Changing the user in a container
The USER instruction changes the user with which the following instructions in the image are run. The last USER instruction in a Dockerfile will also control the user in any containers started from the image of this Dockerfile.
9. Summary
Here are the two new instructions for you to refer back to when completing the exercises.
10. Time for practice!
We only saw two new instructions, but with some pretty complex interactions with other instructions. Let's cement them with practice.