feat: add Docker Swarm support as a new deployment package

[asherAbecasiss]

This PR introduces a new Docker Swarm deployment package alongside the existing Docker Compose deployment.
The Swarm package enables running services in a Swarm cluster while keeping the current Compose-based workflow intact.

[kosmoz]

Hi Asher, thanks for contributing to Distr!! 🚀

I think the idea of supporting docker swarm deployments is great, however I have some concerns regarding the implementation at hand:

At a glance, it appears that there is a lot of overlap with the already existing docker compose agent. Only the code in docker_actions.go appears genuinely new. For this reason and because docker stack deploy seems like just another "mode" of docker deployment similar to docker compose, I think it would be preferable to have one agent support both and toggle between them using a new property in the agent resource response. A user could then decide between compose and swarm when creating a deployment target. Currently, I don't think there is a way for a user to use this feature so some kind support in the UI/backend would be needed in any case.

Also, we'd be happy to learn more about your use-case in order to fully understand the requirements here. 🙂

[kosmoz]

Parsing the env file and replacing variables like this seems kind of brittle. I think understand that docker stack doesn't support variable substitution directly, but a better way appears to be using docker compose config to perform variable substitution and other generators and run docker stack deploy with the output of that (source). Do you think that would work?

[asherAbecasiss]

Sure, let me look into this.

[asherAbecasiss]

I previously used this script, and it was incredibly helpful for managing env files with Docker Swarm. I just implemented it.

start_with_env_file() {
    
    stack=${1:-${PWD##*/}} # by default, the name of the cointaining folder
    compose_file=${2:-docker-compose.yml}

    if [ ! -f $compose_file ]; then
        echo "Misses compose file: $compose_file" >&2
        return 1
    fi

    # execute as a subcommand in order to avoid the variables remain set
    (
        # export variables excluding comments
        [ -f .env ] && export $(sed '/^#/d' .env)

        # Use dsd your_stack your_compose_file to override the defaults
        docker stack deploy --compose-file $compose_file "home"
    )
}

[pmig]

Hi @asherAbecasiss thanks again for creating this PR.

I quickly wanted to check in if you got docker swarm support working locally by building and re-tagging your docker-swarm agent.

In order for us to implement docker swarm (stack deploy) support into Distr, we would make a bigger refactoring of the pr and implementing the changes into the existing docker agent and adding the necessary changes in the UI and database to support docker swarm deployments nativley.

Let us know how your tests have been and if it make sense for us to build docker swarm support into upstream or you are happy with maintaining your fork with your custom agent.

I also created a discusion (#609) and shared it on Discord to see if anyone else is interested in Docker swarm support.

[asherAbecasiss]

Hi @pmig ,

Thanks for reviewing the PR and for the follow-up!

Yes, I was able to get Docker Swarm support working locally by building and re-tagging the Docker Swarm agent. The deployment process worked as expected, and I validated the stack deployment behavior in a Swarm environment.

I understand that integrating Docker Swarm support into Distr would require a broader refactoring to align with the existing Docker agent, UI, and database structure. If there is interest in upstream support, I’d be happy to collaborate and adjust the implementation accordingly.

[pmig]

I understand that integrating Docker Swarm support into Distr would require a broader refactoring to align with the existing Docker agent, UI, and database structure. If there is interest in upstream support, I’d be happy to collaborate and adjust the implementation accordingly.

The needed steps would be:

• Relabel the "Docker Compose" to "Docker" deployment method (also for file uploads).
• Introduce a "DockerType" similar to the "HelmChartType" that can be either "compose" or "swarm" (or "stack"?). "Compose" should be the default, and a migration should be performed.
• Use the same Docker agent in both cases and just adapt the execution based on that type (similar to how the Kubernetes agent does it).
• Adapt the environment parsing based on @kosmoz suggestion.

Let us know if you have any further questions. We are also able to assist you anytime or take over the PR if you run out of time :-)

[pmig]

closed in favor of: #645