Why is everyone excited?
Docker is, simply put, a container. How is this at all exciting? Think about any time you set up a system, and how long you spend setting it up. No matter if it's a web server, a build environment or any other system service. Do you want to do that all over again when you move systems? What about updating your operating system under it, and having to deal with config file changes, and the other cruft that gets left behind, and causes problems over time? Not having to deal with any of this is why people like docker.
What docker is, and more importantly, what it's not.
Some people assume that docker is just another container like a virtual machine. While it is true that docker will spin up a minimal Linux environment, it does this every single time that the docker instance is started, and when stopped, it throws it all away. This seems like it would be a massive pain to update every single time you wanted to add new content to it, but this wasn't overlooked when Docker was designed.
Getting started with Docker
The getting started link for Docker is here so you can install it properly no matter what platform you are on. Once docker is up and running, feel free to come back. Otherwise, let's see what docker can do for you.
Basic example
Give this command a run in a terminal/command prompt, then navigate a web
browser to http://127.0.0.1 and you should see a web browser running.
docker run -d -p 80:80 docker/getting-started
Lets break down what that command is doing. You docker is the basic command to
directly control Docker. run tells it that you want to run something inside of
docker. -d tells docker to run it in the background, as a daemon. -p 80:80
forwards the port 80 from your local machine, where docker is running on, to
port 80 in the container. This is the standard HTTP web port that allows you to
access that server. The url could have been typed http://127.0.0.1:80, but 80
is implied for HTTP, so it didn't need typed. docker/getting-started is the
docker image that is running inside of the container, and that image starts the
web server that you see when you load the web page.
Docker-compose
Typing commands can get very confusing, especially as things get more complex,
so I would recommend learning docker-compose early. You may need to install it
separately on your system. The same
command as above would be saved as a file called docker-compose.yml and is
yaml formatted as the filename implies.
---
version "2.3"
services:
getting-started:
image: docker/getting-started
ports:
80:80
Make it useful
Docker compose files can be brought up by running docker-compose up -d. The
-d will run it in the background. If you omit this, you can see what's going
on, and stop it with ctrl c like any normal command.
---
version: "3" # Specifies the compose version
services: # The list of services are below
nginxBlog: # The only service will be this blog, running on nginx
image: nginx # Runs on the nginx official image
container_name: blog # Sets the name of the container to keep track easier
ports:
- 80:80 # opens up port 80 to let you access the blog
volumes:
# Passes through /mnt/data/blog from the host to where nginx expects a web page to be
- /mnt/data/blog:/usr/share/nginx/html # passes through /mnt/data/blog from the host to where nginx expects
restart: unless-stopped # Automatically restarts the service on restart of docker, or host reboot, ect
This is how this blog gets to you (partially). What happens if I start this docker container on another machine? I have to upload my blog to all of them and keep them in sync? Not at all. It just takes an edit to how docker has access to data.
---
version: "3" # Specifies the compose version
services: # The list of services are below
nginxBlog: # The only service will be this blog, running on nginx
image: nginx # Runs on the nginx official image
container_name: blog # Sets the name of the container to keep track easier
ports:
- 80:80 # opens up port 80 to let you access the blog
volumes:
# This time we will pass the volume from below through to the container.
- blog:/usr/share/nginx/html # passes through /mnt/data/blog from the host to where nginx expects
restart: unless-stopped # Automatically restarts the service on restart of docker, or host reboot, ect
volumes:
blog:
driver: local
driver_opts:
type:nfs
o: "addr=192.168.25.51"
device: ":/mnt/data/blog"
This will let docker manage a mount though NFS (assuming it's available on that machine). This means that you can use use this file with any computer that has access to that NFS mount.
Docker swarm
Speaking of managing multiple computers with docker, why bother choose what goes where for things you don't care about what machine hosts it? Docker swarm has you covered. I'll link the getting started guide here as reference, but I'll highlight some of the things I was confused about going in, as well as some other benefits to running a swarm.
Short list of upsides
- High reliability services. Can run multiple instances in case one is restarting/crashing/overloaded
- Automatically can use any node that joins the swarm with little to no effort after joining
- Can easily reboot machines for updates, and docker containers stay up, or automatically come back up on another machine
Questions I and others have/had
Q: How do I know what IP address to access?
A: Docker swarm includes a load balancer. You can access any machine in the swarm on the port you want, and it will serve it to you properly.
Q: What if I need something specific for the container?
A: Docker swarm includes concepts of tagging. You may want to separate things that need ARM or x86_64 CPU's. You may also tag a system as "low_ram" for things like a raspberry pi so a minecraft server doesn't decide to try to start there. Tags are arbitrary, so you can craft it to your needs.
Q: How do I update the container?
A: You don't think about it most of the time. The implied tag for containers is
:latest, which will automatically pull down the latest version of the
container every time it's restarted. If you lock a version, you know when to
change the version tag, but docker does the rest for you.
Other uses for docker
Docker isn't limited to running services for servers. You can use it as a container to test applications without installing them on your system directly. This is also great for dev environments as there's no more "works on my system" bugs due to the nature of everything inside of the container always being the same on all systems. I'll link an article on how to do this with Rust, but it should translate to most projects well.
Conclusion
Docker is a great way to carry around services, build environments, and many other things that help you think less about the "how do I get there" and more about whatever your goal is. When I wanted to spin this blog up, I didn't care that I had to use a web server, or how it went together. I just started an nginx instance in docker, and I am done forever. Hopefully this has helped you see what's so great about docker. Feel free to reach out with questions, and I'll update the page with any common ones.
