Recently, I decided I wanted to take better notes on my own learning and hopefully help others in the process. Enter this blog.
I’ve been doing development for a while; I even have my own homelab running everything from Raspberry Pi to 24-thread Xeons. It’s handy because whenever I want to test out a new project, I can just rapidly set up a server for it. Since most of my projects are low-demand, I often just deploy them on a Raspberry Pi. There’s a problem with this though, while this usually works well, sometimes you end up with one of two problems:
- You need short, “burst” power. On a Raspberry Pi, you redline quickly (either due to the lack of processing power or due to the fact that you only have 1 gig of RAM).
- On the other end of the spectrum, most of the time it’s overkill to have a dedicated device for each individual service you intend on running. If your blog only gets a hundred visitors a month, it’s overkill to have an entire dedicated host serving up websites when it’s going to sit idle 99.9% of the time.
An excellent solution to this is Docker which you can sort of think about as a “VM Lite”. In a virtual machine, each VM gets its own dedicated resources assigned to it with its own associated overhead (namely that it has its own installed OS). In my setup though, I almost exclusively use a Debian OS (Ubuntu for most of the “heavy” servers and Raspbian on the Pi) so it’s silly to have such a duplication for each individual image to only run one service.
This is where Docker comes in. With Docker, instead of an individual virtual machine, you create a container which is its own “box” that shares kernel resources. In a lot of ways, it’s actually better, at least for my purposes.
So for this blog, I attempted to deploy WordPress as a docker image. What an absolute time sink. I sank two days attempting to deploy WordPress as a Docker image before ultimately making a strategic retreat.
Now admittedly, I think my biggest problem is that I broke my own rule and failed to stage my learning. I am not familiar with WordPress and I am not familiar with Docker. I wanted to learn both, but instead of learning WordPress by deploying it with a traditional install, and learning Docker by deploying a simple Docker container, I went straight for the moon shot and tried to deploy WordPress as a Docker container. For those of you who are uninitiated with WordPress, as I was, it turns out it’s an...eccentric application to say the least. It does things like specify absolute paths instead of relative ones, so if you don’t change the domain from the internal IP address your server sits on to the domain name you’re using it will actually pass your internal private IP back to the client, which probably isn’t sitting on your network.
Even despite this, I probably could’ve still pulled it off, but my setup is additionally complicated by the fact that my WordPress deployment sits behind a reverse proxy. Moral of the story: when learning something new, do it in stages.