[Feature] - Adding Docker Swarm adapter

[byawitz]

⚡ The Idea

Adding Docker Swarm CLI adapter to Utopia-PHP orchestration module.

The adapter will be able to deploy containers to an existing swarm.

📃 Checklist

Implementing Adapter functions.

• [x] createNetwork
• [x] removeNetwork
• [x] networkConnect
• [x] networkDisconnect
• [x] listNetworks
• [ ] getStats
• [x] pull
• [x] list
• [x] run
• [ ] execute
• [x] remove

👀 Have you spent some time to check if this issue has been raised before?

• [X] I checked and didn't find similar issue
• [X] I checked and didn't find any active branch.

🏢 Have you read the Code of Conduct?

• [X] I have read the Code of Conduct

[byawitz]

The main difference would be that the adapter would have some Swarm config. For example, the run() function in the adapter will update to something like this

    /**
     * Run Container
     *
     * Creates and runs a new container, On success, it will return a string containing the container ID.
     * On fail it will throw an exception.
     *
     * @param  string[]  $command
     * @param  string[]  $volumes
     * @param  array<string, string>  $vars
     */
    abstract public function run(
        string $image,
        string $name,
        array $command = [],
        string $entrypoint = '',
        string $workdir = '',
        array $volumes = [],
        array $vars = [],
        string $mountFolder = '',
        array $labels = [],
        string $hostname = '',
        bool $remove = false,
        string $network = '',
        int $replicas = 1): string;

By adding the $replicas variable it would be easier to let the adapter run into scalable solutions.

[johan-sv]

+1

[byawitz]

In case this gets approved I can create the PR for it.

[stnguyen90]

@byawitz, thanks for raising this issue! 🙏 This is an interesting idea! I'm a little worried about adding this because it would make this adapter behave differently compared to the others 🧐 How would we be able to use these extra parameters or methods if the interface was the Adapter?

[byawitz]

Thanks for your replay @stnguyen90.

For the Extra method parameter: The added method parameters will have a default to maintain the current behavior.

For the Extra methods: Those can be omitted for now.

The main idea would be

1. Change a few of the function signature codes. while making sure the current adapters, CLI & API still work the same.
2. Adding the Docker Swarm adapter for deploying new containers into the current Swarm.

From what I'm seeing right now, the only function signature that will be changed will be the run one for adding the $replicas variable defaulted to 1.

Then, in the Appwrite environment that value can be set from the .env file for example

_APP_FUNCTIONS_CPUS=0
_APP_FUNCTIONS_MEMORY=0
_APP_FUNCTIONS_REPLICAS=1

[byawitz]

The main changes in the new PR are: Adding the replicas variable to the run command.

The function run ignores the $remove and $mountFolder as they are not available in Docker Swarm.

The functions getStats and execute are not relevant as Docker Swarm accesses the container by services, and those two functions require container access. Maybe: A good workaround would be to build another container appwrite-swarm-executor for example that will be deployed globally and will have access to each node docker and be able to get state and execute in the container level.

After working on that adapter, I realized that upfront it's not the best solution but with what Docker Swarm offers and the current structure of the adapter it should work.

[byawitz]

For the getStats and execute function I've kept them the same as in DockerCLI as they can still work, but, not for Docker Swarm services.