🛠️ What I Worked On

The past week has been mostly focused on finishing the deploy process for new and existing containers.

🏗 Deployments

When an Application is deployed, either manually or from a Github event, a job is queued to either redeploy the container, or rebuild the image first and then redeploy the container.

This sounds simple on the surface but there's actually a lot of moving parts to it. The flow of the job goes like so:

• Job is triggered
• Deployment is created in the database to track the process
• Get the latest Github commit ID for the application branch
• If the job is a rebuild, request Tugboat to pull the latest Repository changes and rebuild the docker image
• Request Tugboat to create a new container from the image and wait for it to start.
• Once started, request Tugboat to stop and remove the old container.
• Deployment is updated with build time, status and other metadata.

Initially, the repository was being cloned into a path that wasn't mounted correctly from the host, as Tugboat is a docker container, causing the build context to fail as it couldn't find source files. After a few trial and errors, I managed to mount the volumes correctly so the process would find the source files and stop failing.

⚓ Tugboat Auth

One key part of Tugboat that I'd been skipping so far is authentication. As Tugboat is capable of controlling a server's docker instance, it's paramount that only actors we want are allowed to communicate to Tugboat's endpoint.

For this, I had Tugboat check for a TUGBOAT_SECRET_KEY in it's environment. If one isn't set, it generates a new random secret, persists it to the .env file and sends it to Serversinc. All future requests to Tugboat's API are then authenticated using the secret key in the header.

Next, I plan to restrict access to Tugboat even further by configuring UFW to only allow incoming requests from approved IP addresses (e.g., the main ServerSinc server). This adds a network-level safeguard in case the secret key were ever compromised.

✅ Wins

• Rebuilding and redeploying containers now works flawlessy
• Requests to Tugboat now require a secret key

⚠️ Challenges

• Mounted Volumes, paths and absolute paths - Getting the cloning and building of a repository working whilst inside a container took quite a few goes to get working. I faced a similar challenge when writing Tugboat's authentication as it has to write to a .env file.

💡 What I Learned

• Working inside containers requires extra care with file paths and volumes – It’s easy to overlook how containerized environments handle filesystem access. I learned to always double-check mount points, working directories, and how absolute paths behave differently inside vs. outside containers.

🔜 Next Up

• Installing Traefik to make containers accessible over the web