Nick is a former Actor/Director turned coder who has been working as a software engineer for 4 years. With particular interest in DevOps tools and Automation, he has worked in large corporations and small startups alike, and maintains open source projects and teaches coding in his spare time.

Click to download as PDF

I. Intro - Defining Docker

A. Imagine a new engineer asks you, ""What is Docker?"". How would you answer
B. For any engineer in the stack, Docker can be powerful, simplifying development setup and ensuring higher deployment confidence.
C. But there's not many clear resources to help understand the eco-system and what it means for running, building, and debugging.
D. Today we will examine the subtle ways Docker goes about building and running containers.
E. Docker is more than a container. There is a Docker daemon (the ""whale"") which assembles the container, and it lives in your computer ""the ocean"", which is the environment it has to work with. Let's explore how these areas relate to each other.

II. From the Computer to the Docker Daemon.

A. (Visual: A ""box"" (the container) sits on top of the ""whale"" (docker daemon), who floats above an ""ocean"" (computer (filesystem)).
B. !Important distinction! Docker daemon does not see your filesystem. It only sees the context that you the developer sets for it (commonly ""."").
C. That dot is small but important. It's the common unix character for the current directory. When running docker build, you often use this to set the context to the location where you're runinng the cli from.
D. Specifying a directory (""."") copies everything within it to the Docker Daemon (""whale""). The only thing it sees is the subset of your file system.
i. (image of an abridged filesystem in a tree layout, with a section selected in red that corrosponds to the terminal command. That section is copied to the whale. The result is the whale has a smaller file system, and the ""root"" of it is ""."")
ii. from here a few examples how things work:
a. A Dockerfile ""COPY .. /someplace"" doesn't work. While the computer has a parent directory from its working directory, the daemon is already at the top level directory, and directories above it weren't copied to the daemon. Take away is: wherever you set the build context, you can't go higher than it during buildtime.
b A `docker build ./project-with-tons-of-node_modules in it, to show that builds can significantly slow down if your context is too large (reminding that everything first needs to be copied to the daemon before even starting the build process).
E. Overview of dockerignore
i. (visual, demonstrating the same thing as above but with some diretories ""redacted"" out, as specified by the .dockerignore file, leaving a leaner filesystem for the docker daemon's context)
ii. More than size, it would be a mistake to copy node_modules or generated builds into the container.
iii. Your computer might be running a different version of a process than the container might have, introducing inconsistency with builds. We'll talk about RUN commands to better handle this next.

III. From the Docker Daemon to the Container.

A. Section title: You've sent things to the Docker Daemon, but where it's going looks different still.
B. Isolated visual of the box, this time with the lid open and a disk hovering over (the ""image"")
C. Points on how during buildtime (going through the Dockerfile), is the only time content can be added to a container to get it working (footnote that this is oversimplification)
D. A look at some Dockerfile commands and how they relate between the docker context and the container.
i. WORKDIR - setting the working directory in the container (just like how there's a default working directory on your computer's shell)
ii. COPY - again, this is sourcing from the Docker Daemon and moving to the container
a. Important to note, there is no access to your computers files at this point.
iii. RUN - executes commands inside the container.
a. Important note is not the context (The run command ""already doesn't"" run on your computer
iv. ENTRYPOINT/CMD - these are ""saved"" rather than ran, as defaults, and can be overridden for customization or debugging.
E. Final tips for successful building and debugging.
i. Selecting the right amount of ""context"" can speed up build time, but be sure it encompasses all files you need.
ii. Files generated from build processes or installs (npm) should happen in the container (rather than your computer) to ensure consistency.
iii. Errors around files not found (common) is because the file wasnt copied or copied to the wrong place. Identify where in the container the process is starting from, and try to connect it to where the file may be.

This talk will be presented as part of CodeLand:Distributed on July 23. After the talk is streamed as part of the conference, it will be added to this post as a recorded video.