Last week, I successfully Dockerized my app! I had been running the PostgreSQL development database in Docker, so I had an existing docker-compose.yml for that, but I hadn’t created any of my own images for the app itself. I’ve now added three more services, all connected with a network: one for the backend server, one for database migrations, and one for database seeding. This also involved writing code for two more small binaries: one for migrations and one for health checks.
A lot of what I learned centers around my newly created Dockerfile. I’m using a multi-stage build where the first stage compiles my server, migration, seeding, and health check binaries, and the second stage copies them over and runs the app. It seems like the conventional wisdom is to use heavier Debian or Ubuntu images when getting started, but I’m finding that my project is working well with an Alpine builder stage and a FROM scratch runtime stage. It also looks like I’ll be able to keep things simple (and power efficient) by sticking with ARM64 throughout development and production.
As I’ve done throughout the project, I updated the backend justfile to automate and document all the relevant commands now that the app is running in Docker.
I also added a .env.example file to keep a record of all the required environment variables under version control without committing secrets.
This week, I will start into the process of AWS deployment. It seems like this can be approached via the GUI console, CloudFormation YAML, or a general purpose programming language via the AWS CDK (Cloud Development Kit). I’ve sometimes found that what is usually considered the easiest way is not the easiest way for me, and I may end up touching all or a subset of these in my learning. For the CDK, Rust is not one of the officially supported languages, but Go is. My previous AWS deployment using the AWS SAM (Serverless Application Model) was a Go project, although a lot of the config was in YAML.
This may necessitate some further changes to my code and/or Docker setup, but hopefully not too many, since portability is one of the main goals of Docker.
While I am not really impeded by anything other than time constraints, I do expect to face some specific challenges this week. Getting Docker going was a lot to learn, but I think this next stage with AWS will involve significantly more possibilities and concepts. However, I expect to be able to use a similar learning process between Docker and AWS, which was not so much the case when going from writing the app code to Docker.
Accordingly, determining how to apply last week’s process to other domains is a worthwhile task. While I did go in with a general sense of how Docker and Dockerfiles work, I did not have any real sense of the specifics of how to actually set things up for this project or previous experience writing my own Dockerfiles. While tutorials and other resources can be helpful for getting a general overview of a topic, I’ve found that I prefer to learn using the details of my specific use case as early as possible. Therefore, the approach I took this week was starting by having ChatGPT generate a general solution to the problem, but then continuing to push until I understood every detail and felt confident that I was making the best decisions for my project to the best of my abilities. This involved a lot of online investigation on Docker Hub and GitHub as well as a lot of experimentation with different combinations of commands and configurations. I found that in some situations, ChatGPT was suggesting that I do a lot of things that would probably run fine, but were not necessary. Other times, it seemed completely incapable of debugging an issue directly, so I had to switch to asking how to perform debugging strategies that I thought of separately, which proved to be eventually effective. Overall, I feel like I now understand what I’m doing with Docker rather thoroughly, and expect to be able to succeed with a similar approach to AWS.