Docker-Compose

This is a comprehensive list and instruction guide on my Docker-Compose stacks that I run in the HomeLab. This is more for my own enjoyment and documentation, but others can utilize this as well if they would like.

Structure

The repository is structured in folders. The docker-compose file will be in the folder and a instructions.md file with instructions on installation and environment variables will be in there too. That way I can always go back no problem.

Best Practices

Docker compose is by far the easiest way to run a Docker container or multiple docker containers. You can run as many as your system can handle in 1 docker compose, the only problem being port compatibility and ENV files if you use them. If you have 1 powerful machine and you want 1 centralized docker compose file and a folder on a local system, I reccomend having a master docker-compose file that you run everything in. It can be harder to troubleshoot and you can bring the whole stack down pretty easily, but for testing and for homelab purposes, it can be nice. It is also nice to do that process when you have a list of docker containers that you want to expose to the internet and share with your friends. Create 2 stacks on 2 different machines, 1 for staging, 1 for prod. Both stacks could contain Caddy reverse proxy and a caddy file, where you can run an automatic script to add a reverse proxy entry for every new item added to the stack. The local one would use a local domain and docker sock, the prod one would use a public domain and the docker sock.

I do not do that process above. I tend to do multiple stacks over multiple systems for different purposes and/or domains. I like to keep things as segregated as possible in the network and I use routes and traffic rules to manage where everything goes and access between machines, applications, containers, and the internet. I also use Nginx Reverse Proxy Manager since it contains a very user friendly UI.


Another best practice that I practice myself is running a single, local database server with remote backups. This allows me to have a UI for my databases and not have so many separate databases that can clog up the storage of a Docker host, as well as more simplicity for management. Only my main jump box and the docker containers that need a database are allowed to access the database server. Any other requests are rejected and logged. I highly reccomend this. My database of choice is MariaDB with a MySQL extension. I also run Mongo, Postres, and MSSQL on the same machine for the handful of applications that only support a specific type of database. These are run on different ports than are standard for security reasons, also using 64 character randomized passwords that I only get to see once.


Use .env files whenever you can instead of putting all the environment variables in the Docker-Compose script. This adds a layer of security and protection for things like passwords, security keys, Database access strings, etc. That way, if someone reverse-engineers your application, you are protected by information stored in a different file.