Can you please help me understand the use case?
Is this so that if you have multiple docker-compose files that you want deployed to a single machine this makes that easier?
When I saw the initial blurb I got excited thinking this might help me deploy docker-compose apps to different machines in my cluster, but I didn’t get a sense of that from the README?
Yes, this is for deploying multiple Compose apps on a single machine. Is your use case for something more like Kubernetes?
You might consider explicitly mentioning this fact in your project README so it’s clear to prospective users what you’re offering.
Thanks for the response and for open sourcing your project!
Kubernetes always felt incredibly heavyweight for my simple needs. I ran it here for a while but since I do zero clustering
I have a couple of machines in my ‘homelab’ running ProxMox. Those machines host various VMs which themselves host Docker containers for the apps I want to run.
If anything, perhaps something like Ansible would be a better choice, I just haven’t invested the time and energy to encode the various docker-compose files I have into Ansible playbooks.
I’ll definitely mention that, thanks! I think Harbormaster can still help you, what I didn’t like about the various other solutions was that there was no discoverability. None of them had a canonical list of apps that ran on a machine, whereas with Harbormaster you know what’s running where.
If you aren’t running the same app on N machines, you can just set up one Harbormaster config per machine and that’s it!
Look into Nomad if you haven’t already.
You’re easily the 3rd or fourth person to suggest that. I will absolutely get on it!
Why not use Docker Swarm?
It’s easy to setup, it’s compatible with Compose and it’s working fine with simple workload.
You just need to deploy multiple stack.
Does Swarm work with repositories (rather than published images)? I generally prefer that workflow as it’s simpler, but if you already build images, Swarm is a great choice.
What I’ve used in the past, which somehow overlaps with this, is to split the services in many files, then list them in the COMPOSE_FILE variable in a .env file.
Example: in my folder, I have a docker-compose.db.yml, a docker-compose.app.yaml and a docker-compose.telemetry.yml . I then set this in the .env
# env file
This allows to spin up any service cross stack with a single compose up or to deal with them one by one as usual.