Adventures in Automation, Part 4
This is the fourth article in a series documenting my quest to transform a $5/month VPS into a playground for experimenting with web programming technologies.
If you've been following along with Parts One through Three, you'll recall that I started out with a simple goal - creating a personal tech playground for very minimal cost (~$5/month). I managed to do this with a simple AWS VPS service (Lightsail), some Terraform wizardry, and an open-source project called Traefik. This set the stage for a plug-and-play system where each app was just a little "Lego brick" in a greater whole that could be rearranged and reconfigured as I pleased. But before I could do that, I had to "brickify" (convert into Docker containers, aka "containerize") my existing apps.
Containerizing my first React app was very simple overall, but I did struggle for an embarrassingly long time with the "homepage" setting in package.json. This setting tells the React build process where the app will be hosted for rendering various links and URLs. I wanted to keep the internal projects agnostic as to which project would be consuming them, in case I wanted to make them public someday. It's also a good design pattern - "loose coupling." But using a "/" for "homepage" wasn't working, and anything else I put in there would lock me into a particular URL. Finally a Stack Overflow article pointed out that "." for "homepage" was exactly what I was looking for! I don't want to admit how long it took me to figure that out.
With the React app containerized, I turned my attention to the PHP app, which was a far different experience. Containerizing this little two-page app was super simple. I generally had no struggles with this part, though I did need to learn a bit about how the build process works with PHP apps using "composer" for managing libraries, which then became part of the Docker file. All of my PHP apps in the past were standalone pages or maybe had a couple of file "includes" but nothing using libraries. PHP has grown up considerably in the past 20 years.
At this point, all of my existing apps were plugged together in a rough sort of way, and I felt like I could explore options for improving some individual apps. So I took a break from automation and infrastructure to expand my kids' virtual whiteboard React app. I wanted it to have a backend for temporarily storing board state in a very simple Postgres database. The idea was that they could "save" and "load" a whiteboard so we wouldn't forget who had what chore the instant someone walked away from the app. That took a little bit of creativity, as testing the three-service app (frontend, backend, database) needed a local docker-compose stack instead of just a single "docker run" command. But overall, developing and expanding new apps for our family has become super simple. I don't have to worry too much about where the app is going or how to integrate it into the overall site. I follow a template that includes Docker (for plugging in together) and GitHub (for automatically publishing) files.
What's next? Security! I start getting a little nervous about publishing full access to my family's internal apps and toys. Luckily there's a way to simplify and automate that, too…
Do you have your own experiences with Docker? Feel free to leave some comments on LinkedIn if you have "war stories" to share!