Last week, I deployed my app! The backend is running in Docker on an AWS EC2 instance, and the frontend is on GitHub Pages. While the deployment process overall stayed in line with my initial intentions, there were a few smaller aspects I had to adjust.
I had planned to use Podman instead of Docker since Podman runs rootless and daemonless by default and is meant to be a drop-in replacement for Docker. However, I found that this is not really the case, especially when using Podman Compose or Docker Compose with Podman. For example, Podman Compose does not have profiles implemented, so I would need to use multiple YAML files instead. Even when using Docker Compose as the compose provider for Podman, Podman converts images into OCI format, which changes behavior. For example, I have a health check for my main backend app defined inside my Dockerfile, but this is stripped away by Podman. While I could just define the health check in docker-compose.yml instead, these are both examples of workarounds that would be necessary specifically for Podman. Podman definitely has its advantages, but if I wanted to use it in the future, I would need to consciously switch to the Podman way of doing things rather than expecting it to be a true drop-in replacement for Docker.
Consequently, I decided to take the extra steps to run the real Docker rootless. Since it’s meant to run as root by default, this inevitably complicates things. There are instructions and a script for running rootless provided in the Docker docs, which helped a lot, but I still ran into some issues. The provided script assumes systemd, which is not present on Alpine. Similar to the Podman situation, it would be possible to more manually get it working on Alpine, but it would be a workaround that is not how the script setup assumes you’re going to be doing things. I decided to switch to Ubuntu to make this aspect go more smoothly.
Some tasks that were surprisingly straightforward were setting up HTTPS and using custom domain names. I was also able to keep the deployment reproducible by automating what could be automated with shell scripting and clearly documenting what could not be automated.
Now that I’ve achieved my deployment goals, the next major category of tasks to turn to is documentation. Of course, I need to add more detail to the README about the platforms used for deployment and about the project overall.
Another concern is that since the project is both login based and social, there isn’t really any way to get a good sense of it by just clicking on the frontend link (spur.noahkawaguchi.com). It immediately requires an account, and even if someone was to create an account, they wouldn’t have any friends and wouldn’t be able to do much of anything. (If anyone actually clicks on that and makes an account, be warned that I may end up resetting the database as I record demos.)
Therefore, I will need to show off the features without expecting people to use them directly. The main two ways I’m thinking of approaching this are adding some sort of frontend splash screen that doesn’t immediately redirect to login and recording demo GIFs for the README demonstrating the features.
There isn’t really anything impeding me this week other than the end of the semester drawing near. While I can keep working on this project indefinitely, it will be over in the context of this course in only a few weeks. After getting over the hump of deployment, I’d say I’m in a good place to “finish” the project without being too hurried at the end.
While last week was a lot of trial and error, I’d say that I made improvements in some process-related areas I mentioned in previous posts. Namely, I was more readily able to make pragmatic decisions about technologies based on concrete resource use. For example, my initial plan using Alpine, Podman, and the smallest possible EC2 instance theoretically minimized resource and cost overhead. However, I decided that the developer overhead of setting up and maintaining that stack was significant enough to tip the scales in the direction of a more standard, heavier stack, especially after comparing some concrete numbers using the AWS pricing calculator. As I gain more experience moving forward, the developer overhead of some of the technologies I decided to forgo this time around may lessen enough for me to revisit them.