Hi, I'm opening this post just to chat about appwrite scaling. Later, if my project evolves and I have the need, I would like to set up a horizontal scaling.
I already had two questions:
- Will function deployment via Appwrite CLI still work? And systematically deploy to all instances of appwrite?
- Will updates be easy?
(poke @Binyamin )
How'd you like to do the horizontal scaling, using
- Docker Swarm or
- Manual?
I don't know yet, I don't know which one is better ^^
Doing it manually seemed easier to install, but for later I have a doubt.
First
First I would recommend to read the expanding part in the appread
book
https://book.appread.io/vertical-scaling
Second, it goes like that. for both use-case I'm recommending decentralizing the Databases and the storage https://book.appread.io/decentralization then:
Docker Swarm
https://book.appread.io/docker-swarm Docker Swarm is the easiest way (after you're getting familiar with it) to deploy scaleable services. In Docker Swarm you can easily add and remove nodes (servers), and, you can get a quick overview of all your Swarm services with few commands.
The difficult parts of using Swarm are:
- You must keep the managers quorum (more on that you can find in the Swarm chapter)
- Adding & removing nodes
- You can't scale automaticity not the nodes nor the services.
Manual horizontal scaling
https://book.appread.io/horizontal-scaling In this approach you will create a server that holds only the stateless containers and gather as-many-as-you-need servers behind load balancer.
This way gives you to most easiest way scale up and down, as you'll need to do is to add or remove replicas of the exact same server.
Appwrite executor
One of Appwrite containers is the appwrite-executor
which is an internal endpoint for creating and managing OpenRuntime (functions) containers.
This container is not exactly stateless.
In Docker Swarm you can't have more than one container of appwrite-executor
because this container holds in-RAM table that contained all the information of the running runtimes.
Meaning if you've replicated this container and function x
was created by container x
, then in the next time when container y
will try to execute function x
it will get unathorized
error.
In the manual approach, the one you're replicating the whole stateless containers, then, appwrite-executor
would work perfectly.
Regarding the main 2 questions
Will function deployment via Appwrite CLI still work? And systematically deploy to all instances of appwrite? Will updates be easy?
The deployment would be the same no matter what approach you would use. As for the upgrading check this π
Upgrading
When upgrading Appwrite cluster you have two tasks
- Upgrading the image versions.
- Running optional migrations.
For the first one in Docker Swarm it's very easy as you just need to deploy new stack file with all the new versions. For the Manual way you'll need to upgrade one of the instances docker-compose.yml
file and then replicate that one again.
For the second task it will be just the same as single-server Appwrite instance. Just run
docker compose exec appwrite migrate
# In swarm
docker compose exec appwrite-appwrite.1.faef23... migrate
Oh wow, thank you for this detailed explanation, I will look into each of the parts.
I also wanted to offer you a French translation for your book ^^
So if I understand correctly, the quorum managers cannot be modified (by which I mean moving it from one physical machine to another), is that correct?
π That sounds great
For example You have 3 managers
Then, if you removed them, then it's okay. But if one went down by because the server crashed then uou won't be able to run any commands without getting the quorum back.
I see, it's not as bad as I thought. Basically, the quoroms must be there (and all operational) to execute commands on the workers
Exactly
In the long term performence wise, Swarm will much faster then any other solution
Yes indeed, I saw the benchmarks and it's rather promising for swarm
I saw that you use the ''oha" tool for benchmarks, could you describe to me how you tested appwrite with this tool? I would also like to use it ^^
oha is a powerfull load-testing - as much as you can - tool.
At the end of this issue https://github.com/appwrite/appwrite/issues/5787
I've explained how I've used oha for load testing.
If it's not clear I would be able to write a detailed instructions later today.
This is exactly what I needed! Thank you ^^
Do I have to configure _APP_DOMAIN
and _APP_DOMAIN_TARGET
by putting the name of my domain? (with swarm)
It's not a must. But it's best to do so for SSL & cookies
That's my goal, but I didn't know whether to do it or not because of swarm ^^
Then, yes
Okay :p
There is an error on the commands, you have to remove the "s" from "services" ^^
Opps. Thanks
For the moment I have a problem of connection with the DB of the decentralized, I look why
Recommended threads
- Migrate from cloud to localhost
Hello everyone. I need to migrate my test project from cloud to localhost, however it seems that this is possible only if a self-hosted appwrite instance it's h...
- Realtime with multiple connections
I need the Realtime on multiple Collections for diffrent applicational logic. So my question is: Is there a way to have only 1 Websocket connection or do I need...
- Can't login or deploy functions in Appwr...
Hello, since i updatet to the appwrite cli 6.1.0 i can't login or deploy functions with the cli. When i call the command: "appwrite get account --verbose" i ge...