Intro to Docker

Docker has made my life so much easier when trying to set up things to test in my homelab. Rather than having to manage multiple VMs (updates, managing resources, etc) I just manage one OS and run as many containers in it as the system can handle. Ricky, this post is for you.

Docker is a step up from running VMs. You can run applications with only the necessary components required for the application to run. These applications run in what is called a container. Those containers then run on top of an OS (VM or physical).

One of the biggest pros in my opinion is the fact that I don't really need to manage individual operating systems to run multiple applications. I run one operating system (typically Ubuntu Server) and then run the containers on top of that.

Here's a quick YouTube video about VMs vs Containers from PowerCert Animated Videos.

As you can see from the video, typically a container will utilize hardware more efficiently which allows you to run more applications on the same hardware. Whether it's your own computer or the cloud (aka "someone else's computer). Also, you can run Docker on ANY operating system. Windows, Mac, Linux... it doesn't matter!

via GIPHY

Let's dig deeper into what a container is. A container is essentially software that bundles up an application's code as well as any components/dependencies that it requires to run. This includes libraries, settings (that typically can be modified using environmental variables), and any other system tools.

Because a container is meant to be as lean as possible you may not find any utilities not required for the application. One problem I typically run into is trying to edit files inside of containers because I'm so used to vim and nano. But depending on the container you can typically just run an update/install using something like "apt".

Containers also have their own networks and storage that can either be destroyed with the container, or persist if you set it up to. For most containers that you can find on Docker Hub they'll have pretty decent documentation on what you can put into persistent storage volumes. Typically you would want to keep settings and content on the actual OS so that if you have to recreate the container, you'll still have your important files so that you don't have to build the application completely from scratch.

Setting up a container is very easy and there's even a tutorial on the Docker website on creating a simple container. If you want an actual step-by-step tutorial their documentation is a great read. I may or may not do a step-by-step tutorial on how to do it. Depends on how I'm feeling I guess.

Now because I love GUIs for things I have to spend a lot of time in, I use a container manager called Portainer. This software can also run in a container so you're using Docker to run a website that lets you manage itself.

Right now I'm running 17 containers including game servers, like Minecraft and Valheim, and just other things I wanted to mess around with. This website is also being hosted in a container in my homelab!

The interface is fairly easy to navigate once you get used to it and learn more about the different parts that make up a container (storage volumes, networks, ports, etc). The biggest benefit for me is being able to create, recreate, and delete containers directly from Portainer instead of doing it through the terminal.

Now that we know what a container is and how to create them, let's take a look at why you wouldn't want to run something in a container. In my personal experience, nothing that I've been wanting to tinker with works better outside of a container (unless I can't figure out how to make the container run).

The main thing in not wanting to run an application in a container is if it's too resource heavy so it wouldn't really be more efficient in turning them into a microservice, which is basically what Docker is all about. Sometimes it's just better to run it directly on the OS so it can use all of the host resources instead of having to share.

Another major thing is that running containers usually cannot be moved between different operating systems. The earlier comment about being able to run Docker on any operating system is true, but when you need to move running containers to a different machine then you need to have the same OS. You can, however, just create a new image and then move that over to the new OS and then install it on there, but the point was for high availability in case one of your Docker servers were to die or something and you need to move it to another host.

Speaking of high availability, you can also run containers in a cluster of hosts that are tied together. With Docker it's called Docker Swarm, but there are other ways to manage this as well. Kubernetes is another container orchestration software that is widely used in the community.

So there you have it, a very brief introduction to Docker and containers. There are more things to learn about them (Docker Swarm, Kubernetes, etc.) but that can be another post (maybe...). I hope you learned something, Ricky. OK BYE!