Serveurs

Qu'est-ce qu'un serveur ?

Un serveur est une machine Linux qui vous appartient, sur laquelle tourne le Pierrr Agent, un petit programme qui discute en HTTPS avec votre hub. Chaque serveur enrôlé apparaît comme une carte dans la page Serveurs ; c'est lui qui exécute les conteneurs des projets que vous y déployez.

Un serveur à vous n'a rien d'obligatoire : par défaut, un projet est déployé sur l'infrastructure de Pierrr. Vous ne passez par un agent que si vous voulez faire tourner vos conteneurs sur votre propre machine, ce que le projet appelle le mode self-hosted.

Licences Pierrr Agent

Chaque serveur consomme un siège de licence Pierrr Agent, un add-on facturé par serveur et indépendant de votre plan principal. Un compteur affiche en permanence le nombre de sièges utilisés sur ceux dont vous disposez, et la page propose de souscrire une unité supplémentaire quand le quota est atteint.

Le bouton « J'ai un code » sert à utiliser un voucher Pierrr Agent remis par l'équipe Pierrr : il crée un serveur dans l'organisation sans consommer de siège.

Enrôler un nouveau serveur

Connecter un serveur génère un jeton d'enrôlement à usage unique et la commande d'installation à coller sur la machine cible. Vous pouvez donner un nom au serveur au passage ; son nom d'hôte réel est récupéré à la première connexion de l'agent. Le jeton n'est affiché qu'une seule fois : s'il est perdu, révoquez l'entrée et générez-en une autre. Le détail de l'installation vit sur la page Installer Pierrr Agent ; la machine apparaît dans la liste une trentaine de secondes après une installation réussie.

Finaliser l'installation d'un serveur

Tant qu'un serveur fraîchement enrôlé n'est pas finalisé, un assistant remplace sa vue d'ensemble. Il fait le point sur l'état de la machine et vous laisse la préparer avant d'y créer votre premier projet. Il demande l'agent 0.77.0-beta ou plus récent ; les serveurs déjà configurés n'y repassent pas.

La base de données partagée est la seule étape bloquante : « Provisionner » la prépare sur le serveur, avec une instance unique par serveur et une base isolée par projet self-hosted. Tant qu'elle n'est pas prête, le bouton « Finaliser l'installation » reste inactif et en donne la raison.

Les autres vérifications sont informatives et ne bloquent jamais la finalisation :

• Ports 80 et 443 : libres, ou, s'ils sont occupés par un autre programme, signalés avec leur numéro, car vos domaines ne fonctionneront pas tant qu'ils le restent.
• Edge et certificats : indique si l'accès public de vos projets et leurs certificats sont configurés sur l'agent.
• Espace disque : l'espace libre sur le total, avec une jauge qui passe à l'ambre au-delà de 90 % d'occupation.
• IP publique détectée : l'adresse par laquelle le serveur est joint depuis Internet, celle que vos domaines devront viser.
• Outils de sécurité : installés sur le serveur, ou, à défaut, les analyses tourneront dans un conteneur, un peu plus lentement.

« Rafraîchir » relit l'état du serveur après une correction. Si l'agent est hors ligne ou trop ancien pour répondre, l'assistant l'indique et reprend à sa prochaine connexion. Une fois « Finaliser l'installation » confirmé, la vue d'ensemble habituelle du serveur, avec ses onglets, prend la place de l'assistant.

Réinitialiser un serveur

Dans l'onglet Réglages, « Réinitialiser le serveur » rouvre l'assistant à la prochaine visite de la page. La boîte de dialogue vous fait choisir entre conserver la base de données et la supprimer aussi, puis demande de saisir le nom du serveur pour confirmer. La réinitialisation est refusée tant qu'un projet self-hosted utilise encore la base de données locale de ce serveur.

La liste des serveurs

La page Serveurs présente chaque agent sous forme de carte : icône, nom (qui ouvre le détail), nom d'hôte, indicateur d'état, version de l'agent avec son badge, dernier contact et date d'enrôlement. Des onglets filtrent la liste : tous, en ligne, hors ligne, révoqués et supprimés.

Chaque carte garde des actions visibles pour tout le monde : les instructions d'installation, la mise à jour de l'agent, un menu « Plus d'actions » (Renommer, Révoquer, Supprimer) et « Ouvrir ». Une action que votre rôle ne permet pas reste affichée, grisée, avec la raison au survol. Il en va de même pour « J'ai un code » et « Connecter un serveur ».

États d'un serveur

Le statut d'un agent reflète sa connectivité au hub :

• En attente, l'agent a été créé mais ne s'est pas encore enregistré : le jeton d'enrôlement n'a pas encore servi.
• En ligne, l'agent envoie ses signaux de présence ; il peut recevoir des déploiements.
• Hors ligne, aucun signal récent (réseau coupé, machine éteinte, agent arrêté). Remonté comme un point d'attention sur le tableau de bord.
• Révoqué, l'accès de l'agent a été coupé ; il ne peut plus se connecter et n'envoie plus de métriques.
• Supprimé, l'entrée a été retirée de la liste active ; l'agent est déconnecté et ne peut plus jamais se reconnecter.

Détail d'un serveur

Ouvrir un serveur affiche son en-tête puis des onglets, comme la page d'un projet. L'onglet ouvert s'inscrit dans l'adresse de la page : un lien ou un rechargement retombe dessus.

• L'en-tête, avec le bouton de retour vers Serveurs, le nom, le nom d'hôte copiable, l'état, le bouton « Mettre à jour l'agent » et le menu « Plus d'actions » (Renommer, Révoquer, Supprimer). Renommer ne touche pas au nom d'hôte réel de la machine.
• Vue d'ensemble : la carte Machine, avec l'identité de l'agent (hôte, système, architecture, version, date d'enrôlement, dernier contact) et, à droite, trois jauges Processeur, Mémoire et Disque (ambre au-delà de 75 %, rouge au-delà de 90 %), l'âge du dernier relevé et le nombre de conteneurs, tous sains ou en alerte. Tant qu'aucun relevé n'est arrivé, les jauges restent vides et un message l'indique. Après une réinstallation sur la même machine, l'encart de reprise des projets s'affiche en tête de cet onglet.
• Toujours dans la vue d'ensemble, les Tendances : trois graphiques Processeur, Mémoire et Disque sur les cinq dernières minutes, avec la valeur actuelle, la moyenne, le pic et les seuils à 75 % et 90 %.
• Puis le Détail par conteneur, une carte repliable avec la consommation de chaque conteneur dans le temps et sa part dans le total courant.
• En bas de la vue d'ensemble, les Projets liés, une carte par projet déployé sur ce serveur, avec sa santé, ses conteneurs et ses déploiements. Sans projet, un état vide l'indique.
• Conteneurs : un tableau paginé, avec un champ de recherche : application et réplique, projet, état, démarrage, processeur et mémoire. Les conteneurs en alerte passent en premier.
• Sauvegardes et Base de données, sur un serveur à vous : la clé de chiffrement des sauvegardes et la copie hors site d'un côté, le moteur des bases de vos projets et sa montée de version de l'autre, décrits plus bas.
• Réglages : l'interrupteur « Relevés en direct », la clé du serveur, « Analyses en résumé seul », « Mises à jour par l'équipe Pierrr » et, quand un changement est proposé, l'adresse par laquelle le serveur joint Pierrr. Un réglage que votre rôle ne permet pas de changer reste affiché, grisé, avec la raison au survol.
• Journal : les commandes envoyées au serveur, avec leur origine, leur état et leur durée.

Quand l'agent n'a pas été vu récemment, la dernière fenêtre enregistrée reste affichée et les relevés reprennent au premier signal de présence suivant. Pour un agent révoqué, la page indique qu'il n'envoie plus de métriques et ne garde que la vue d'ensemble et le journal.

Le trafic réseau par conteneur (données reçues et envoyées) demande un agent à jour : il s'affiche dans l'onglet Topologie d'un projet, décrit sur la page Projets. Un serveur dont l'agent n'est pas encore mis à jour continue de fonctionner, mais l'onglet indique qu'aucun trafic n'est mesuré.

Mettre à jour l'agent

L'agent ne se met jamais à jour tout seul. Un badge de version indique « À jour » ou « Mise à jour disponible » ; le bouton « Mettre à jour l'agent », dans l'en-tête de la page et sur la carte, déclenche la mise à jour. Il est grisé, avec la raison, si votre rôle ne le permet pas (demandez à un owner ou un admin) ou si l'agent est hors ligne : il doit être en ligne pour l'accepter.

Une barre de progression suit les quatre étapes : téléchargement, vérification, installation puis redémarrage. Le binaire est vérifié avant d'être installé, et l'ancien est conservé pour permettre un retour en arrière si le démarrage échoue.

Ce que fait l'agent sur votre machine

Une fois connecté, l'agent construit et lance vos conteneurs, réalise les sauvegardes de vos projets, gardées sur ce serveur, et supprime les archives arrivées à expiration. Après chaque build réussi, il ne garde que les deux derniers builds d'une application, sans toucher aux autres. Les secrets de vos conteneurs ne sont pas écrits en clair dans leur configuration. Vous pouvez plafonner les ressources qu'il utilise, voir la page d'installation. Ce qui reste sur le serveur et ce qui passe par Pierrr est détaillé dans la FAQ de l'agent.

Pour servir vos domaines, l'agent a besoin des ports 80 et 443 de la machine, libres et ouverts à vos visiteurs. Si un autre programme les occupe, il nomme les ports concernés au lieu d'échouer sans explication.

Les données de vos projets

L'agent crée sur le serveur la base de données de chaque projet qui y est hébergé, et elle y reste : Pierrr n'héberge pas de base pour ces projets, et ne conserve, chiffré, que ce qu'il faut pour la brancher à vos applications. Ces bases ne comptent pas dans votre quota de stockage. Le cache et les volumes d'un projet sur votre serveur sont inclus, sans achat : ajoutez-les depuis le projet.

Les logs de vos applications sont lus sur le serveur, auprès de l'agent, quand vous ouvrez l'onglet Logs d'un projet : ils ne sont jamais stockés chez Pierrr.

Les applications d'un projet sur votre serveur envoient leurs e-mails transactionnels par Pierrr comme sur notre hébergement : l'agent installe un petit relais qui n'écoute que sur les réseaux de vos projets, sans port ouvert sur Internet, et transmet chaque message par sa connexion chiffrée.

Au moment d'une construction, l'agent lit les fichiers de configuration de votre application (Dockerfile, manifeste de paquets, modèle de variables) dans sa propre copie du dépôt et y fait les vérifications d'avant construction : Pierrr n'en reçoit que le résultat, jamais le contenu. Les images construites restent sur le serveur, sauf si vous choisissez, dans l'onglet Déploiements du projet, de les publier dans le registre de votre organisation.

Le panneau et l'import de base de données passent par l'agent : l'import est vérifié puis restauré sur le serveur, avec les droits du projet, et le panneau s'ouvre depuis la console sans qu'aucun port ne soit ouvert sur la machine. Les pages du panneau transitent par Pierrr sans y être conservées, et les identifiants de la base restent sur le serveur (agent 0.71.0-beta ou plus récent, la console vous le signale sinon). Les analyses de sécurité, conteneurs et code, tournent sur votre serveur : l'image de vos applications n'en sort pas, et seul le rapport remonte à Pierrr, sans extrait de votre code (agent 0.66.0-beta ou plus récent, la console vous le signale sinon). Les sites WordPress, eux, fonctionnent sur votre serveur : choisissez-le à la création du site, et l'agent crée sa base sur la machine.

Une montée de version majeure de la base de données n'est jamais automatique : lancez-la depuis l'onglet Base de données de la page du serveur, après confirmation. Chaque base est copiée vers la nouvelle version et chaque table recomptée avant la bascule ; au moindre échec, la version précédente est remise en service. Les bases sont inaccessibles pendant l'opération, qui demande au moins deux fois la taille des données en espace libre, et les données de l'ancienne version restent sur le serveur.

Chiffrer les sauvegardes pour votre clé

Dans l'onglet Sauvegardes de la page d'un serveur, la carte « Clé de chiffrement des sauvegardes » reçoit votre clé publique de chiffrement. Dès qu'elle est enregistrée, chaque sauvegarde qui quitte le serveur, téléchargée depuis la console ou copiée hors site, est chiffrée pour elle sur le serveur : Pierrr ne voit plus leur contenu, et seule votre clé privée les ouvre. La console affiche l'empreinte de la clé et sa date d'ajout ; une clé privée collée par erreur est refusée et jamais enregistrée. Retirer la clé redonne des téléchargements non chiffrés et arrête la copie hors site.

L'archive gardée sur le serveur reste lisible par l'agent : la restauration depuis la console fonctionne comme avant. Une archive téléchargée arrive chiffrée, à ouvrir avec votre clé privée. Dans l'onglet Sauvegardes d'un projet, chaque sauvegarde porte les badges « Chiffrée pour votre clé » et « Copie hors site », ou la raison d'une copie qui n'a pas eu lieu. Il faut l'agent 0.67.0-beta ou plus récent.

La copie hors site s'appuie sur une destination configurée sur le serveur avec sudo pierrr-agent backups set-remote : un dossier de la machine (disque ou partage monté) ou un stockage objet. La carte « Destination hors site » ci-dessous prépare cette commande pour vous. Ses identifiants restent sur le serveur. La carte de la console montre si une destination est configurée, telle que le serveur la rapporte, et deux réglages s'y changent sans toucher à la clé : suspendre la copie hors site, et refuser tout téléchargement qui ne pourrait pas être chiffré pour votre clé (agent 0.68.0-beta ou plus récent). Voir la FAQ de l'agent.

Dans l'onglet Sauvegardes, la carte « Destination hors site » vous guide sans quitter la console. Choisissez « Stockage S3 » (bucket, puis, si besoin, dossier, adresse du stockage et région, et l'identifiant de clé d'accès) ou « Dossier local » (le chemin absolu d'un disque ou d'un partage monté). La carte prépare la commande à coller dans un terminal du serveur : les clés d'accès ne passent jamais par Pierrr, la clé secrète d'un stockage S3 se saisit sur le serveur, au moment d'exécuter la commande. Rechargez ensuite la page pour voir l'état à jour. Une fois une destination en place, la carte propose aussi la commande pour la retirer ; les copies déjà faites restent où elles sont.

Réinstaller l'agent sur la même machine

Désinstaller l'agent garde les projets, leurs sauvegardes et leurs bases sur la machine. Après une nouvelle installation, la vue d'ensemble du nouveau serveur affiche un encart « Même machine que » l'ancien : le bouton Reprendre les projets rattache à ce serveur les projets de l'ancien agent, retrouve leurs bases et leurs fichiers, puis remet chaque projet en route. L'ancien agent doit être hors ligne (désinstallé ou révoqué) et le nouveau en ligne ; sans le rôle qui permet de gérer les serveurs, le bouton est grisé avec la raison.

Une base introuvable sur la machine est signalée, projet par projet, et n'est jamais recréée vide : restaurez une sauvegarde. Un projet dont la remise en route échoue se redéploie depuis sa page.

Mises à jour du système de votre serveur

Pierrr relève, depuis l'agent, la version du système de votre serveur, la date de fin de son support, le nombre de mises à jour en attente (dont celles de sécurité) et si un redémarrage est nécessaire. Ce relevé ne modifie rien. Il s'affiche dans la carte « Mises à jour du système » de la page du serveur.

Quand une mise à jour mérite votre attention, Pierrr peut vous la proposer : installer les mises à jour en attente, ou passer à la version suivante du système. Vous recevez une notification, et la proposition apparaît dans la carte. Rien n'est installé tant que vous ne l'avez pas acceptée, et seuls le propriétaire et les mainteneurs de l'organisation peuvent répondre. Une proposition sans réponse expire au bout de 30 jours.

Une fois acceptée, la mise à jour s'exécute sur votre serveur et continue même si la liaison avec la console est coupée ; l'avancement s'affiche dans la carte, et le détail d'un échec aussi. L'agent ne redémarre jamais votre serveur : le redémarrage nécessaire, signalé dans la carte, se fait quand cela vous convient. Un changement de version redémarre des services du serveur, conteneurs compris, et peut durer longtemps : choisissez le moment.

Ce que Pierrr voit de votre serveur

L'agent crée sa propre clé de chiffrement sur le serveur. Les variables de vos projets, et le jeton de votre registre quand vos images y sont publiées, lui parviennent chiffrés pour cette clé, et c'est lui qui les remet en place : ils ne circulent plus lisibles jusqu'au serveur. L'identifiant de la clé s'affiche dans l'onglet Réglages de la page du serveur, sous « Clé du serveur » ; pierrr-agent status affiche le même sur la machine.

Le réglage « Analyses en résumé seul », dans l'onglet Réglages de la page du serveur et désactivé par défaut, réduit ce que les analyses de sécurité font remonter à l'identifiant et à la gravité de chaque constat : ni chemin de fichier, ni paquet, ni message. Le propriétaire du serveur peut aussi l'imposer depuis la politique locale de l'agent.

Révoquer ou supprimer un serveur

Ces deux actions se trouvent dans le menu « Plus d'actions » du serveur, et chacune est confirmée par la saisie du nom d'hôte :

• Révoquer coupe immédiatement les identifiants de l'agent et ferme sa session. La machine devra être ré-enrôlée pour revenir. Ses projets restent rattachés à ce serveur, avec leurs données : ils ne se déploient plus tant qu'un agent réinstallé sur la même machine ne les reprend pas.
• Supprimer retire l'entrée de la liste active et déconnecte l'agent définitivement, sans retour possible depuis la console. Comme pour une révocation, ses projets restent rattachés à ce serveur, avec leurs données.