I’ve written a couple of times about GitHub Actions, and a key component of that ecosystem is Docker. It’s kind of a big topic, as its a powerful tool that can do a lot, or be as complicated as you need it to be—but ultimately, not everyone needs to learn Docker’s ins-and-outs.
This post will talk about the basics of Docker, with a focus on configuring Docker containers for GitHub Actions—but the fundamentals can be used for any project.
One note: I’m intentionally simplifying certain things here. I firmly believe in avoiding information overload, and bombarding people with more knowledge than is necessary is harmful to their learning experience. If you’re a Docker expert thinking “well yeah but“—remember that building amazing things using a technology does not require one to be an expert in it!
That’s an important question, isn’t it? Docker is a tool for running applications in isolated containers. You declare, by writing a
Dockerfile, what your container needs to run and what code it’s running. Docker has great documentation, and I highly suggest you poke around there; my goal here is to give you some practical advice, but the docs are way better at filling in areas that I intentionally skim over.
Here’s an example: I’m building my Node.js application, and I want it to run on a Ubuntu machine (because I know that’s where I’m deploying it). I have two options: install Ubuntu on my Macbook (no thanks) or use Docker to run the application inside of a Ubuntu container. By using Docker, I get a local development environment that is 100% the same as where I’m deploying my application, despite being on a MacBook (or Windows for that matter).
For the sake of clarity, I want to call out this word. It’s used often in the Docker ecosystem.
A container is an isolated environment in which your code can be run.
You can have thousands of containers, and unless instructed otherwise they will not be able to interact with each other. They’re “run” from an “image” (see below). They can be started, stopped or restarted. They’re (often) ephemeral, so if a container dies you can start up a new one and pick up where the last one left off.
Containers can be run on your computer, or on some cloud service (more about this later).
This one’s fairly straightforward. Docker is some software you can install on your machine—if I’m running Docker from my Macbook and I spin up some containers, my MacBook is the host. Communication between a container and its host is a common topic of conversation, so we’ll get into that later on.