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.
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.
Top comments (21)
I cannot tell you how many times I have tried to "Dockerize" my side projects ... this will be a great talk! Thank you @nickpalenchar ! 🔥
So glad to see a talk like this. All new devs should know about containers and their portability for cloud-native development. KUDOS, Nick.
I did not know about the layer hashes. Really useful!
Agreed! Super underrated!
Hi Nick! Docker is definitely well known nowadays; are there are container technologies that you've tried or heard of?
Hey Andy, I haven't tried any other container technologies--Docker has always suited my needs so I've never felt the need to explore alternatives. Although I have heard of rkt, and the Open Container Initiative Standard also looks interesting as a concept, though I know nothing of either.
What a great Docker introduction! Loved the ocean/whale metaphor, and a great walkthrough of some of the basic concepts, commands, and errors. Great talk!
Hey Nick! Awesome talk; I actually wanted to ask you what inspired you to make the transition from acting/directing to tech? I'm someone who's in between those two worlds, working a full tech job while enjoying the acting bits here and there. I'm curious about what your story is?
Great question Nic. I have a strong arts background and even went to a performing arts high school--it's where I got a lot of foundational leadership skills and of course plenty of practice in public speaking. Lesser known though was that I did some small time video game programming but never could fathom understanding computer science formally, so I avoided it for the greater part of my upbringing. I discovered freeCodeCamp after graduating college and helped form meetups in New York City. It eventually inspired me to complete a Coding Bootcamp and break into the industry. My theatre skills have helped me tremendously with leadership and team morale, which anyone would agree are important parts to the software collaboration process!
Wow, that's awesome Nick. I can relate, that theater has helped with both team morale and leadership. Thanks for sharing (: I'll have to also start learning Docker 😅👏🏿
Awesome talk @nickpalenchar ! What are some of the benefits of using a container such as Docker when you are building software? What do you primarily use it for in your day to day job?
Thanks Molly! There are many key benefits but in one way or another it all comes back to portability, and that's useful at any phase in development.
For sandbox/prototyping, I might want to try out a new thing without muddling my local environment. I'll search docker hub for a container (say python3), and run the tag on my machine with
docker run <tag_name>, and boom--I have all the correct binaries installed in the container without having to install anything myself. When I'm done with it, I can remove the container. My local environment never gets cluttered at any point in thisFor production, it's often said containers helps eliminate the "runs on my computer" type of surprises. Running a container creates an isolated environment that's identical rather its in your computer or a remote server.
is Docker free to run? Do we need to to have a linux system running on a server service like aws?
Hi Paul,
Docker is free to run and you can install it on your Window, MacOS and Linux machine.
Thank you, @scooterphoenix . I tried it on windows and it got difficult to set up, which I then abandoned. It's much straight forward in setting it up in a Linux system. After creating a simple container, I just didn't know where or how to deploy. I will have to try it once again from scratch.
Sorry you had a bum time with Docker on Windows. Maybe we should have a container chat in one of the chat rooms. Once you create your app and create an image from it, you can share that image with others to build upon and use or you can deploy your image to AWS Fargate or if your app requires high availability, then some sort of container orchestration is what you'd look at, like EKS.
Great talk Nick! Love learning a bit more about Docker. What's the best use case for using Docker containers? Is it mainly used to deploy to production? Or can we use it for development as well?
As someone who has used docker, but mostly through cut and paste this is really interesting. Curious what people who haven't used docker before think.