The things you can do with Docker Compose!

I learned some super cool stuff I should probably have known, but sometimes it's just easier to come up with your own tooling than it is to learn how to do things properly! I have this requirement for some projects, that my local copy of the site is slightly different. Maybe I mount upload directories from an external drive to save hard drive space on my laptop, or maybe I have Kibana installed, as well as Elasticsearch because it makes it so much easier to explore your index. We also have some people on ARM CPUs and some on Intel, and some images (older MySQL being the main one, yes we still have people on older MySQL, no I don't like it but there's not tonnes I can do about it! Those projects use MariaDB 10.3 for local development on ARM because they do have compatible images). Stuff like that.

So I made a little fish function which checks to see if there's a docker-compose.arm.yml file in there (that's our standard naming convention for this), and use that if we do. That then grew to incorporate a file called docker-compose.jt.yml which is the one that's specific to me, obviously. The annoying thing about this is you end up with potentially 3 docker-compose.yml files, maybe more. There's probably no need for me to commit my overrides, but then if they get lost or something it's just easier if they're in the repo. I don't care if my colleagues know what my external drive is called, so there's not a security thing in there that I'm worried about. The main problem is that I have to duplicate the entire file to make my edits. This bugged me but I was in the middle of something and didn't have time to worry about it until a few days ago where I started to think about how I'd solve all of this using my own command-line tool.

On the off-chance, I thought I'd see if someone else had solved this, because I was feeling a bit lazy and of course they have! Docker have! And it's pretty nice. I'm doing this using a combination of their merging concept, and their COMPOSE_FILE environment variable. This allows me to control everything the way I want, so for projects that have full support for ARM and Intel, I would just create a file called docker-compose.override.yml and do all my overrides in there, then put it on .gitignore so that it doesn't affect anyone else. And for projects where we have a docker-compose.arm.yml file, I can use the COMPOSE_FILE environment variable to specify my files in a .env file, which also goes on .gitignore. For standard projects that looks like:

COMPOSE_FILE=docker-compose.arm.yml

And then if I need overrides I can do it like this:

COMPOSE_FILE=docker-compose.arm.yml:docker-compose.override.yml

I love this solution as it doesn't require anyone changes anything about how they work. Actually it makes a lot of people's lives easier because they don't need to type docker compose -f ./docker-compose.arm.yml... for every compose command. And I can remove my command that does that automatically, and replace it with a fish abbreviation, which is a lot shorter. Although it is weird how it automatically expands it in the terminal as you type. I'll get used to it!

Then, for things like Kibana, where it works fine on any platform, but it takes a tonne of configuration that I cannot be bothered to deal with for everyone when they don't really need it, I assign a profile to that in my compose file, then it doesn't come up unless you specify that you want that named profile to come up. Or, because there's no possible way I'll ever remember which profiles I need for these projects, I can put that in my .env file as well:

COMPOSE_PROFILES=kibana

What I really want to do is make it so that docker-compose.arm.yml is an override of the base docker-compose.yml file and only contains image overrides. I don't know if that's even possible, and it only affects legacy projects at this point so it's probably not worth the effort.

Score +1 for reading the manual a little more thoroughly, but I'd be lying if I said I didn't enjoy making my janky little tools for doing stuff like this. I should just not live with them as long as I do before thinking about, and doing things properly.