opened
zulhfreelancer
username_0
As per the title, I’m curious to know if this project supports horizontal auto-scaling out of the box i.e. when all physical servers couldn’t hold new replicas demand by the master/controller.

If it’s supported, where is the doc/reference for it?
Does swarmlet has auto-scaling feature?
issue
created
woudsma
username_1
Thanks for asking!
As of right now Swarmlet does not have any functionality to enable auto-scaling.

Everything is still WIP, to enable auto-scaling we would have to add a feature/service that communicates with the API of your cloud provider (AWS/DigitalOcean/Vultr/...), to create/destroy resources.
I'm sure it's possible to do this.
The first thing that comes to mind is how to setup auto-scaling from a user perspective.

How would you like to configure auto-scaling? You will need to enter and save the cloud provider API key somewhere in the swarm. Maybe via a service with UI hosted on the swarm? I haven't really worked with auto-scaling setups before, but I assume you would want to configure the scaling behaviour as well. This might actually be possible by creating a service, `autoscaler` for example.

The built-in services that run after installation are the `deployments`, `loadbalancer`, `swarmpit` and `matomo` services. `autoscaler` could theoretically work in that template.
Check out the `deployments` service for example:
https://github.com/swarmlet/swarmlet/tree/master/services

Let me know what you think, or if you have comments/suggestions!
PR's are most welcome as well.
comment
created
zulhfreelancer
username_0
Thank you for the clarification, @username_1. To answer the question, since swarmlet doesn't has CLI on client side (correct me if I'm wrong), I think the options are:

- Configure the cloud secrets using web console
- Or, by providing a flat file (YAML?) during cluster setup

WRT configuring the scaling behaviour, I'm not sure if _docker-compose.yml_ supports min and max replicas or not. If it does, I think we can take those values. Otherwise, maybe we need to require another file to be provided for service that needs to be auto-scaled.

As for the number of replicas, min and max is just an example here. I'm proposing that for those who are on tight budget and paranoid if their cloud provider will burn their wallet fast. Maybe another possible value would be `auto` where the minimum should always be one container and there is no maximum — ideal for those running production workload.

In terms of triggers, I think avg CPU and RAM usage would be nice to start. Disk ops, network, I/O & others can be in later phase.
comment
created
woudsma
username_1
This definitely sounds like a good idea, thanks for your input.

With configuration in web console, do you mean a web console / UI hosted on the swarm itself?
It might be worth doing some quick research if there already exists a framework (with UI) dedicated to managing and configuring autoscaling. If such a tool exists (think of something like Portainer or Sentry), it would be really easy to deploy it on the swarm.

You can give a service as much control over the swarm as you want by making the Docker socket available to the service container(s) for example. And if this imaginary autoscaling service already has a Docker image, we can just define the `autoscaler` app stack in a single `docker-compose.yml`. For example something like this: https://hub.docker.com/r/bitnami/cluster-autoscaler/

I'm not sure if the user wants to mess with YAML configuration files during cluster setup. I kind of like a single command (with optional options) to install Swarmlet. I'd like to avoid adding complexity during/before the initial setup.

As for the details you mentioned such as triggers and min/max replicas, I have to do some research. No experience on that topic yet.
comment
closed
woudsma
username_1
issue
created
woudsma
username_1
Closing this issue, as there are no plans to implement this feature.
comment