Call for cluster features :-)

[nupplaphil]

@valvin1 @ne20002 @scifijunk
I already noticed that you're using Friendica inside a cluster environment

Do you have any wishes for cluster environments?

I'm thinking about the following features:

• S3 Storage support (= prerequisite scalability)
• ELASTIC logging support
• daemon-less worker logic = no more locking with (local) PIDs (= prerequisite scalability)
• volume-less /var/www/html path = no configuration is needed at the filesystem (= prerequisite scalability)

Do you have any other suggestions?

[scifijunk]

Well, I use K3s as the cluster environment and Portainer to manage it so I can't think of anything right now since it just works for me. I am still fairly new to k3s so maybe down the road, I might think of something.

[ne20002]

I don't use any clusters. It's my very private instance which I indeed run in a Podman setup in my own VPS on my own virtual server host. It's Debian and therefor still Podman 3, as there is no newer version in backports. :(
I run my Friendica in a Pod with owasp:nginx, MariaDB (would prefer Postgres), Redis and CrowdSecurity.
Works pretty well so far.

[valvin1]

oh sorry didn't see the notification of this issue.

on my side I tested to run it in a cluster approach. i'm running k3s on 2 nodes. Database is running on a dedicated server.

• first is file storage which concerns app files and media files: main question is how to serve those files on different container which are not on the same node + keep good performance (ex: using nfs is a disaster with rsync on startup ;-) )
• second is scalability: actually we have two roles web and cron. but I'm not sure we can increase their numbers withtout running any issue
• third is how to upgrade database properly when we have different containers
• fourth how to define liveness / readiness probes

I had to rollback my various tests and now running on one node only to ease the file storage and have good perf.

I will take time to make a better answer with more details later.

[valvin1]

come back about this subject.

I'm not sure logs are directly link to the subject. Logs should be available on stdout in order other tools can grab/parse it. Usual recommendation for logs are they should be in json format to ease the categorization. Then tooling is more on admin side with the tools of his choice. for my usage I'm using kubectl logs -l app=friendica so current implementation is almost working (except the debug log file).

Storage is really important because friendica allowes database media storage (which is not so recommended) or file storage. A third option with S3 like storage will be welcomed and ease the setup/scalibility of web and cron containers. As mentioned using a remote storage like NFS is a nightmare on the actual implementation.

About database upgrade, I think we should have a dedicated script for that like cron.sh. It will allow on kubernetes based cluster to run an init container for that and avoid issue we actually have when database is upgrading and having liveness / readiness probes.

About upgrades there is also the /var/www/html which is updated using rsync. Bad thing of this folder is that there are files needed on web container and cron container. If we could find a way to not share files between containers on the software part it will ease the setup.