Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature] - Adding Docker Swarm adapter #35

Open
12 of 14 tasks
byawitz opened this issue Jan 30, 2024 · 7 comments
Open
12 of 14 tasks

[Feature] - Adding Docker Swarm adapter #35

byawitz opened this issue Jan 30, 2024 · 7 comments

Comments

@byawitz
Copy link
Member

byawitz commented Jan 30, 2024

⚑ 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.

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

πŸ‘€ Have you spent some time to check if this issue has been raised before?

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

🏒 Have you read the Code of Conduct?

@byawitz
Copy link
Member Author

byawitz commented Jan 30, 2024

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
Copy link

johan-sv commented Feb 1, 2024

+1

@byawitz
Copy link
Member Author

byawitz commented Feb 14, 2024

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

@stnguyen90
Copy link

@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
Copy link
Member Author

byawitz commented Feb 14, 2024

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
Copy link
Member Author

byawitz commented Feb 21, 2024

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
Copy link
Member Author

byawitz commented Feb 21, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants