Docker-Compose
URL: https://docs.docker.com/compose
My recent experiences in deploying services has led me to realise I whole-heartedly recommend looking into using docker-compose in the first instance. The advantage of this is for a sufficiently large server you can run and orchestrate multiple containers on the same machine.
As with all awesome technologies/tools there’s ways of shooting yourself in the foot with them.
I’ve included some of the biggest “lessons” I’ve learned using this below. This isn’t to say I’m using it perfectly, but as they say “it works on my machine”.
Hostnames:
- Hostnames
Set hostnames for all containers. (You’d be shocked how many applications use the hostname for some persistence or security) - Underscores in hostnames
Don’t add an underscore for hostnames. (_
is not a valid character for a DNS record, and the hostname is kinda supposed to be in DNS, sorta.) - Access via host OS
Add the hostnames to your/etc/hosts
or equivalent. (All of the containers on the same bridge can see/talk to each other via host names, you might as well be able to do this from your host-os for debugging as the host is always on the bridge as well in some way)
If you want to automate this I strongly recommend investigating the container: `iamluc/docker-hostmanager:latest` https://github.com/iamluc/docker-hostmanager
This allows for containers to by dynamically added/removed from /etc/hosts
in a way which makes access via ssh or other protocols otherwise.
Networking:
- Docker Bridge Networks
It’s a nice idea to have 1 network per ‘cluster’ of containers. This keeps a nice separation of tools from each other effectively via different vlans but also makes life easier in trying to visualise where the data flows. - External Access
Just use nginx to broker external port forwarding to containers on bridges.
Seriously, nginx is better, more flexible, more configurable. - IPv6
This doesn’t really work well.
There are solutions to supporting this for older file-format versions, but IPv6 support is flaky around many container orchestration systems still as of (mid-2021)
Variables:
Use a .env
file. Just make this flat text file as-if you’re storing a big last of “bash” style variables and store it alongside the docker-compose.yml
and it gets magically picked up 🙂
This isn’t described in enough places imo and it’s a really good way of capturing all of the environmental variables in a way which reduces repetition and makes a docker-compose recipe more portable/flexible.
This makes updating, rolling-back, modifying things much easier. Especially for say managing 8 OpenSearch containers which are almost identical.
I’ll probably come back and update this at some point in the future but for now this is most of the things I’ve run into recently.