Apply suggestions from code review

Co-authored-by: Hypolite Petovan <hypolite@mrpetovan.com>
This commit is contained in:
Philipp 2024-03-02 09:29:47 +01:00 committed by GitHub
parent 5417ffaa00
commit 4b63f12927
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 19 additions and 20 deletions

View File

@ -1,49 +1,48 @@
# Opensocial.at setup
This example of the current opensocial.at configuration has to be seen as a possible "production-ready" environment.
The focus of this configuration is on performance and scalability.
This configuration running at https://opensocial.at is an example of "production-ready" environment.
It focuses on performance and scalability.
## Prerequisites
This setup needs some configuration first to be fully usable.
This setup needs some configuration first to be usable as-is.
1. It uses an external, dedicated database, which is not included here (you can just add a `mariadb` service directly)
2. avatar caching needs to be enabled
1. Enable the system-config `system.avatar_cache`
2. Set `avatar_cache_path` to `/var/www/avatar`
3. It uses a traefik docker service as overall reverse proxy for the whole docker environment
1. Otherwise, adaptations of the two services `web` and `avatar` are necessary
1. It uses an external, dedicated database, which is not included here (you can just add a `mariadb` service directly).
2. Avatar caching needs to be enabled
1. Enable the system-config `system.avatar_cache`.
2. Set `avatar_cache_path` to `/var/www/avatar`.
3. It uses a Traefik Docker service as overall reverse proxy for the whole Docker environment.
1. Otherwise, adaptations of the two services `web` and `avatar` are necessary.
## The setup
The setup splits Friendica in as much (micro)services as possible.
The setup splits Friendica in as many services as possible.
### Split Frontend & Daemon
This setup splits the frontend services from the background Daemon.
So it's possible to scale different aspect from the frontend without harming states of the cronjob forks of the Daemon.
This setup splits the frontend services from the background daemon so that it's possible to scale the different aspects of the frontend without harming the state of the cronjob forks of the daemon.
### Redis
Redis is a highly optimized, in-memory key-value storage.
The current setup uses redis for two use-cases:
- Redis as PHP overall session handler
- Redis for Friendica specific session-state handling
The current setup uses Redis for two features:
- PHP native session handling.
- Friendica-specific session handling.
### [app](./app) (php-fpm)
The frontend logic of each user-request is computed by a php-fpm instance.
Because of the distributed session handling, it's possible to scale as much php-fpm app-instances as you need.
Each incoming HTTP request is processed by a php-fpm instance.
Thanks to the distributed session handling, it's possible to spawn as many `app` instances as you need.
### [web](./web) (nginx)
This nginx instance is a reverse proxy for the frontend logic to avoid direct access to the php-fpm.
And it delivers static resources directly without passing the request to the php-fpm instance.
This nginx instance is a reverse proxy for incoming HTTP requests.
It serves static resources directly and passes the script requests to the php-fpm instance.
### [avatar](./avatar) (nginx)
This stateless nginx instance delivers all avatar-pictures of this instance.
This stateless nginx instance serves all avatar pictures of this Friendica node.
### [cron](./app) (php-fpm)