OnPremise / Self Hosted
Ce document décrit les conditions techniques pour l'exploitation de Campus Events dans un environnement Self-Hosted (OnPremise).
Exigences matérielles
Pour un fonctionnement stable et performant, le serveur doit au moins répondre aux exigences suivantes :
- Processeur : architecture multicœur (multi-core).
- Mémoire vive (RAM) : la quantité de mémoire vive nécessaire dépend du trafic attendu. Comme base, nous recommandons au moins 4 Go de RAM libre pour les services d'application.
- Espace mémoire : au moins 50 Go d'espace libre pour le code du programme, les données de l'application (téléchargements, etc.) et les sauvegardes locales.
Système d'exploitation et maintenance du système
- Responsabilité : la maintenance courante du système d'exploitation, y compris l'installation des mises à jour de sécurité pour le système et les services installés (PHP, Apache, base de données, etc.), est de la responsabilité de l'administrateur du serveur côté client.
- Synchronisation de l'heure : le serveur doit être synchronisé via NTP. Le fuseau horaire du système doit être réglé sur Europe/Berlin.
- Locales : la locale de_DE.UTF-8 doit être installée et disponible.
Configuration logicielle requise
PHP & base de données
Notre logiciel fait l'objet d'un développement continu. Le tableau suivant indique les versions nécessaires pour chaque version.
| Version | Version PHP | Modules PHP (extrait) | Base de données | Redis |
|---|---|---|---|---|
| 2.35 (alias 5.0) | 8.2-8.3 | ctype, gd, iconv, imap, intl, json, ldap | MariaDB 10.11 (MySQL 8.0) | Requis |
| 2.36 (alias 5.1) | 8.3 | ctype, gd, iconv, imap, intl, json, ldap | MariaDB 10.11 (MySQL 8.0) | Requis |
| 2.37 (alias 5.2) | 8.4 | ctype, gd, iconv, intl, json, ldap, redis | MariaDB 11.4 (MySQL 8.0) | Requis |
| 2.38 - 2.41 (alias 5.3 - 5.6) | 8.4 | ctype, gd, iconv, intl, json, ldap, redis | MariaDB 11.4 (MySQL 8.0) | Requis |
Modules PHP requis
Les modules suivants doivent être installés et activés pour PHP (aussi bien FPM que CLI) :
- bcmath, ctype, curl, gd, iconv, igbinary, imagick, intl, json, ldap, mbstring, mysql (pdo_mysql), opcache, readline, redis, soap, xml, xsl, zip
- Remarque concernant imap : Le module imap est nécessaire jusqu'à PHP 8.3, mais n'est plus nécessaire à partir de PHP 8.4.
Configuration PHP
Contrairement aux valeurs par défaut, les paramètres suivants doivent être définis :
- memory_limit = 512MB (ou plus)
- allow_url_fopen = true
- La commande php -v sur la console doit renvoyer la même version que celle utilisée par le serveur web. S'il y a plusieurs versions de PHP sur un serveur, la version de la CLI doit correspondre à l'environnement de production.
Changement de version de PHP
Notre logiciel est développé et testé pour une version spécifique de PHP. Il peut s'avérer nécessaire que la version PHP soit augmentée par l'administrateur du serveur pour le fonctionnement en direct ou pour une mise à jour. Nous l'annonçons et le coordonnons à temps.
Redis
- Nécessaire pour les Campus Events à partir de la version 2.35 (alias 5.0).
- Accessible via hôte/port ou socket Unix (par ex. /var/run/redis.sock).
- Un enregistrement persistant des données n'est pas nécessaire.
Serveur web (Apache)
Le logiciel est optimisé et testé exclusivement pour fonctionner avec Apache.
- Modules : mod_rewrite doit être actif.
- Configuration : FollowSymLinks doit être autorisé (les symlinks en dehors de la racine web doivent être accessibles).
- Logs : Les logs d'erreurs Apache doivent pouvoir être trouvés par l'utilisateur de l'application (idéalement par symlink dans le répertoire home).
Structure des fichiers & déploiement
Pour garantir un processus de déploiement sans problème, la structure suivante (basée sur Deployer) est supposée :
/var/www/html/campus-events/productive/
- backups/
- releases/ (contient les différentes versions du programme dans des sous-dossiers)
- shared/ (contient les données inter-releases comme les téléchargements ou les configurations)
- current (lien symbiotique vers la version actuellement active dans releases/)
La racine du document du serveur web doit pointer sur le répertoire public/ de la release actuelle :
/var/www/html/campus-events/productive/current/public
Nous recommandons de conserver la séparation entre production et staging dans le chemin, même s'il n'y a qu'un seul système.
Utilisateurs & autorisations
- L'utilisateur SSH pour le déploiement doit disposer de tous les droits d'écriture dans le répertoire du projet.
- Si cet utilisateur n'est pas identique à l'utilisateur du processus du serveur web (par ex. www-data), sudo doit fonctionner sans mot de passe pour cet utilisateur afin d'adapter les autorisations.
Partages du pare-feu
- Entrant : le port 443 (HTTPS) et le port 22 (SSH) doivent être accessibles depuis une liste définie de nos adresses IP.
- 109.90.104.82 (Brain Appeal Office - pour le support)
- 167.235.150.166 et 2a01:4f8:c2c:a670::/64 (serveur de déploiement)
- Sortie : la connexion directe sur le port 443 à notre système de suivi des bugs devrait être autorisée (whitelisting).
- 188.245.245.172 2a01:4f8:1c1b:a451::/64 (GlitchTip)
- 78.47.122.223 2a01:4f8:c0c:e3fd::/64 (Sentry - Supprimé à l'avenir)
- Une connexion VPN n'est pas supportée ; l'accès SSH se fait exclusivement directement et au moyen d'une paire de clés SSH.
Utilisation de services externes (par ex. prestataires de services de paiement, accès API)
Pour la connexion de services externes, le pare-feu doit être configuré de manière à ce que les systèmes soient accessibles sans détours.
Concrètement, cela signifie que nous n'avons pas prévu nos connexions pour une utilisation via des proxies ou autres détours.
Cronjobs
- L'application a actuellement besoin de deux tâches cron qui doivent être exécutées toutes les minutes.
- Ceux-ci devraient idéalement être inscrits dans /etc/crontab. En cas d'emplacements différents, un commentaire dans /etc/crontab est obligatoire.
Sauvegardes et restauration
- La responsabilité de la sauvegarde des données (base de données et fichiers) incombe au client.
- Recommandation : au moins une sauvegarde quotidienne avec un délai de conservation de 7 jours.
- En cas de besoin, la restauration (restore) doit pouvoir être effectuée rapidement par le client.
Envoi d'e-mail
Les données d'accès suivantes sont nécessaires pour l'envoi d'e-mails (par ex. confirmations, notifications système) :
- Envoi (SMTP) : une configuration SMTP fonctionnelle (hôte, port, utilisateur, mot de passe, cryptage) est impérative.
- Réception/vérification (IMAP) : Nous recommandons vivement la mise à disposition supplémentaire d'un accès IMAP (qui peut être la même boîte aux lettres que pour SMTP). Cela nous permet d'automatiser la vérification de l'envoi de courrier.