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”.
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/hostsor 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.
- 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.
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)
.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.