Maintenance des serveurs

Mises à jour du système d’exploitation

La page de chaque serveur a une carte Operating system. Railyard signale les mises à jour en attente dans la demi-heure suivant la connexion du serveur, puis chaque jour : le nombre total, combien sont des mises à jour de sécurité, et si un redémarrage est nécessaire.

• Install all updates ou Install security updates and restart. La mise à jour peut redémarrer Docker, donc les applications peuvent clignoter quelques secondes; un redémarrage coupe les applications du serveur pendant environ une minute.
• Nightly security updates s’appliquent sans surveillance; un redémarrage n’est jamais fait automatiquement.
• Le badge disparaît une fois le serveur redémarré.

Mises à niveau majeures de Postgres

Un Postgres géré peut passer de la 16 à la 17 ou 18 depuis sa carte. Railyard vérifie d’abord la compatibilité, prend une sauvegarde, met à niveau sur place et vérifie le nombre de tables. L’ancienne version est gardée pendant sept jours pour permettre un retour arrière. Les nouveaux serveurs de base de données utilisent Postgres 17 par défaut.

Restauration à un point dans le temps

Maintenance → Point-in-time recovery → Turn on archive chaque segment WAL et une sauvegarde de base du Postgres du serveur vers le dépôt de sauvegardes de votre équipe, afin que toute base de données qui y est hébergée puisse être reconstruite à n’importe quelle seconde des 7 derniers jours.

Pour restaurer, ouvrez la console de la base de données (App → Resources → Database card → Console) et utilisez l’onglet Restore to a time : choisissez une seconde dans la fenêtre archivée, puis soit Into a new copy (<db>_at_YYYYMMDDHHMM, inspectez-la et recopiez ce dont vous avez besoin), soit Replace the live database (tout ce qui vient après cette heure est perdu). La restauration nécessite le même dépôt de sauvegardes que celui utilisé pour les sauvegardes habituelles.

Instantanés

Avant un redimensionnement ou une mise à niveau du système, prenez un instantané chez le fournisseur depuis la page du serveur, et restaurez-le si quelque chose va mal. Les instantanés sont gardés par votre fournisseur cloud et facturés par lui.

Isolation renforcée (bêta)

Sur Settings → General d’une application, deux réglages facultatifs, désactivés par défaut, renforcent la frontière du conteneur entre les applications qui partagent un serveur :

• Hardened isolation : le conteneur de l’application tourne avec son propre uid non root, les capabilities retirées, et son propre réseau Docker, donc il ne peut ni joindre ni être joint par une autre application du serveur. Testez-le d’abord; cela peut casser une image qui a besoin de root.
• Read-only filesystem : monte le système de fichiers racine du conteneur en lecture seule, avec un /tmp modifiable. Activez-le seulement une fois que vous avez vérifié que l’application n’écrit nulle part ailleurs.

Les deux prennent effet au prochain déploiement. Chaque serveur partage encore un seul noyau; l’isolation par environnement d’exécution en bac à sable (gVisor) est sur la feuille de route, mais n’est pas construite.

Score de sécurité

Settings → Security note l’équipe de 0 à 100 selon une liste de vérification, avec un lien de correction pour chaque élément; voir Équipes, SSO et accès pour la liste complète. Chaque connexion à votre serveur est authentifiée par TLS avec des identifiants propres à ce serveur.