The host machine is the machine that Docker is running on. When Dockerizing for development, the host machine is typically the laptop that you’re working on. In a production environment, the host machine could be (for example) an AWS EC2 instance.
Images and containers
Images and containers are sufficiently interrelated that it makes sense to explain them together.
A Docker image is like a blueprint. A container is like the house that you build with that blueprint. You can build any number of houses off of the same blueprint. If you want to, you can even build a house today, demolish it tomorrow, change the blueprint, and build a new version of the house the next day.
Let’s take that analogy and make it concrete. A Docker image (which again is the blueprint) might specify something like “use the Ubuntu operating system, install PostgreSQL, and get PostreSQL running.”Using that image, you can then create a container which, according to the image, will run on Ubuntu, have PostgreSQL installed and have PostgreSQL running.
A container is like a computer inside your computer. If you have a container running, you can do things like shell into it or use a web browser to visit a website hosted on the container, for example.
Dockerfile is a specification for building an image.
For example, here’s a
Dockerfile that says “Use Ubuntu as the operating system, and install PHP”.
FROM ubuntu:20.04 RUN apt update && apt install -y php WORKDIR /usr/src
One of the defining characteristics of a Docker container is that it’s ephemeral. Containers can be started, stopped, created and deleted, and they often are. This creates a problem if you want to save any files or make permanent changes to existing files. Once your container gets deleted, anything you’ve done on the container’s filesystem is gone.
The solution to this problem is volumes. The idea is that instead of storing things on the container’s filesystem, you store things somewhere on the host machine’s filesystem.
To use volumes, you can tell Docker that a certain service should store its files in a certain location on the host machine. For example, you can say, “Hey Docker, whenever you need to store PostgreSQL data, store it in
/var/lib/postgresql/data on the host machine”.
This way your data can survive containers being stopped or deleted.
Docker Compose is a tool for composing an environment from one or more services.
For example, if my development environment needs PostgreSQL, Redis and Elasticsearch, I could tell Docker via a Docker Compose config file that it should install all three of these services and get them running for me. I can also tell Docker that my environment includes e.g. a custom Rails application.
In addition to specifying that all these services exist, I can use a Docker Compose file to specify how these services are supposed to be configured and how they are to talk to one another.
Docker Hub is a place where Docker images are stored. You can think of it analogously to open source libraries being hosted on GitHub.
If I want to use Redis, for example, I can tell Docker to grab me the
redis:4.0.14-alpine image and the default place that Docker will look for this image is on Docker Hub.