Support Docker Swarm

[jerrac]

Name and Version

bitnami/everything

What is the problem this feature will solve?

No official support for using Bitnami containers on Docker Swarm.

What is the feature you are proposing to solve the problem?

Add support for Docker Swarm based deployments to Bitnami's container library.

Docker Swarm is an excellent alternative to Kubernetes for smaller teams. Bitnami's containers are amazingly easy to use and configure. It would be very very helpful if Bitnami supported Docker Swarm.

I couldn't find an existing issue asking for Docker Swarm support in general, I thought I'd create one. I'm hoping it will at least give Bitnami a way to gauge interest in Docker Swarm.

Since this would require significant investment on Bitnami's part, I'm not expecting this to go anywhere anytime soon. Unless there's a company out there willing to fund the project? :) Anyway, let's keep this issue clean and polite.

@bitnami devs, how would you like people to express support for this idea? I don't think you can see how many people subscribe to an issue, can you?

What alternatives have you considered?

Using Kubernetes

So, I did a thorough evaluation of Kube before choosing Docker Swarm. To keep this short, Kubernetes is overkill for a small community college like where I work. There are too many pieces to keep track of for a small team. A lot of things seem to work like magic (Helm charts...), and when something goes wrong, there are so many different things to check that troubleshooting is not fun. We felt like we'd need enough people on our team that each person could specialize in one part of Kube. (Storage, network, etc.)

Docker Swarm is much simpler. No need to pick a networking plugin, you can mostly reuse existing docker-compose files, and it's all installed with Docker. No extra stuff to install. Configuration is really easy. I had a cluster running in a third, or less, of the time it took me to set up a Kube cluster.

It has it's issues, but so far what I've run into wasn't impossible to diagnose. Unlike when I kept having to switch networking plugins on the Kube cluster...

Anyway, that's why we chose Docker Swarm instead of Kube.

Thanks in advance for any consideration you give this request. :)

[carrodher]

Thanks for the suggestion. At this moment, not officially supported means Docker Swarm is not integrated into our test & release pipeline so we can't guarantee the different containers work out of the box in Docker Swarm that's why there is not an official statement about supporting this platform.

Being said that, the different Bitnami containers could work out of the box in Docker Swarm. Are you facing any specific issues?

Since this would require significant investment on Bitnami's part

In order to properly evaluate it, do you have an overview of what's required to change/add in the Bitnami containers to work on this platform?

[jerrac]

I'm sure a lot of Bitnami's containers do work out of the box. Any that don't require dependencies and can be deployed in any order would work just fine.

In my case, I've been trying to set up MariaDB Galera using your image as a replicated Docker Swarm service. Since you need the first instance to start up before any other instances, I have had issues.
I ended up wrapping your entrypoint script in my own to deal with them.

First, Swarm deploys new stacks all at once. There is no way to tell it to do things in a certain order, or to deploy replicas one at a time. So I had to script a way to pick one replica as the first one, and then make the other replicas wait for it to finish initializing.

Then I found that Docker (I don't think this is specific to Swarm) won't finish setting up DNS until healthchecks have passed. Which made my entrypoint script have issues when I was using the healthcheck script that comes with your image. Since I was looking up sibling replicas via tasks.servicename. So now I'm running things without healthchecks. (At least until I figure out my own.)

The latest issue I ran into is that you can't tell Docker Swarm to kill a replica before it replaces it with an updated replica. You have to let the new replica fully initialize before the old one will be removed. That means I am going to run into issues with the fact I've been using a storage volume per worker node. When an update comes through, I'm going to have two containers using the same data.... That one I haven't had time to figure out yet.

Anyway, that all sounds like a lot of reasons to not use Swarm, but I really do like how well non-stateful/non-cluster apps run on it. If I wasn't trying to set things up for high availability, where each of my web apps have their own MariaDB cluster, I'd be pretty much done. And if I can figure out how to deal with the issues I mentioned, I will be set up very nicely.

In order to properly evaluate it, do you have an overview of what's required to change/add in the Bitnami containers to work on this platform?

Er, honestly, I'm not sure what all would be involved. If there's an actual interest in my idea, maybe someone with more experience could chime in?

I can make a couple guesses based on my MariaDB Galera work.

Any app that requires another service to be up before it can go up would need some kind of tweaking to account for Swarms lack of dependency configuration. If said work around involved dns (like mine), the healthcheck scripts would need to pass before things are actually initialized. Figuring out a way to deal with shared volume mounts when updating a service on the same worker node as the running service would need to happen.

Anyway, all that said, I realize I'm basically asking for Bitnami to cover for my own lack of expertise... I'll be doing my best to fix that issue. In the meantime, maybe this issue can help show if people are actually interested in Docker Swarm. I know there's at least some interest from searching for an existing issue about this.

Thanks for your time. :)

[carrodher]

Thanks for the detailed information! At this moment and due to other priorities that the team has, there are no plans to work on supporting Docker Swarm in the short term.

As you rightly said, keeping this issue open is a good solution to measure the traction that this initiative has and also share some workarounds with other users that would like to work with Docker Swarm.

That's why I will add the on-hold label, on this way we can keep the issue open preventing the Stale bot from closing it

[jerrac]

That's why I will add the on-hold label, on this way we can keep the issue open preventing the Stale bot from closing it

Awesome. Thanks!

[carrodher]

Unfortunately, this suggestion was added some time ago and although there is an internal task to evaluate it, it was not planned as something to address in the short/mid term. It's not a technical reason but something related to the capacity since we're a small team.

Being said that, although closed, the issue will be kept here so we can still measure reactions and comments as well as reopen it in the future if needed.