Ce que le provisionnement installe et configure

Le provisionnement est le travail qui transforme un serveur Ubuntu neuf en serveur prêt pour vos applications. Vimonto Deploy le réalise juste après avoir créé un serveur chez votre fournisseur, ou après que vous avez connecté votre propre VPS. Il met à jour le système, crée l'utilisateur du serveur, sécurise SSH, active le pare-feu et les mises à jour de sécurité automatiques, et installe les logiciels dont le type de serveur a besoin.

Le provisionnement s'exécute sous forme d'une seule tâche, étape par étape, en SSH. Chaque étape est un script bash qui s'exécute en root, s'arrête à la première erreur et peut être relancé sans risque : un provisionnement échoué peut donc simplement être relancé. Il prend généralement 5 à 15 minutes.

Déroulement du provisionnement#

La tâche regroupe ses étapes en quatre phases : Démarrage, Sécurisation, Installation des logiciels et Finalisation.

Un VPS personnalisé saute les étapes liées au fournisseur et commence à Attendre que le serveur accepte SSH. Vous voyez la progression sur la page du serveur et sur la page Activité, avec la sortie complète de chaque commande sous Détails et log. Inutile de garder la page ouverte.

Pendant la mise en place du serveur (création, attente de sa commande de connexion, provisionnement, ou échec à ce stade), sa vue d'ensemble avec la progression est sa seule page : il n'y a pas de barre latérale, et toute autre page du serveur et de ses sites ramène à la vue d'ensemble. Ses Paramètres s'ouvrent toujours depuis la vue d'ensemble, pour pouvoir supprimer un serveur dont la mise en place a échoué. La barre latérale revient d'elle-même dès que le serveur est actif.

Préparer le système#

• Vérifie que le serveur tourne sous Ubuntu 24.04 ou 26.04, et s'arrête sinon.
• Attend la fin de cloud-init, si le fournisseur l'utilise.
• Définit le hostname sur le nom du serveur (sauf si l'environnement gère lui-même le hostname) et le fuseau horaire sur UTC.
• Exécute apt-get update et apt-get upgrade.
• Installe les paquets de base : software-properties-common, ca-certificates, curl, gnupg, lsb-release, unzip, zip, git, jq, acl, rsync, ufw, fail2ban, unattended-upgrades, cron, logrotate et htop.
• Crée un swap si le serveur n'en a pas : la moitié de la mémoire, au moins 1 Go et au plus 4 Go, dans /swapfile. Les hôtes qui n'autorisent pas le swap (certains conteneurs) continuent sans.
• Règle le noyau : vm.swappiness = 10, fs.inotify.max_user_watches = 524288 et net.core.somaxconn = 65535.

L'utilisateur du serveur et SSH#

Chaque serveur a un utilisateur système, vimonto par défaut. Vos sites, déploiements, queue workers et tâches planifiées tournent sous cet utilisateur (un site créé comme isolé reçoit son propre utilisateur Linux ; consultez créer un site).

• L'utilisateur est créé avec un répertoire personnel dans /home/vimonto et rejoint les groupes sudo et www-data.
• Son mot de passe sudo est généré pour ce serveur : 24 lettres et chiffres aléatoires. Il est affiché une seule fois à la création du serveur (consultez conserver les mots de passe du serveur).
• ~/.ssh/authorized_keys reçoit la clé de Vimonto Deploy pour ce serveur, les clés de compte choisies à la création du serveur, les clés de l'organisation et les clés que la page Clés SSH du serveur affiche déjà pour cet utilisateur. Root accepte les mêmes clés.
• L'utilisateur reçoit sa propre clé Ed25519 (~/.ssh/id_ed25519), la clé publique du serveur affichée dans sa vue d'ensemble, qu'il peut utiliser pour cloner des dépôts. Les clés d'hôte SSH de GitHub, GitLab et Bitbucket sont ajoutées à son known_hosts.
• SSH est durci : les connexions par mot de passe et keyboard-interactive sont désactivées, et root ne peut se connecter qu'avec une clé (PermitRootLogin prohibit-password).

Les déploiements peuvent recharger PHP-FPM et Nginx et piloter Supervisor sans mot de passe ; pour tout le reste, l'utilisateur a besoin de sudo avec le mot de passe sudo.

La clé SSH du serveur dans Vimonto Deploy#

Par ailleurs, chaque serveur reçoit à sa création sa propre paire de clés Ed25519 dans Vimonto Deploy. Vimonto Deploy l'utilise pour se connecter lors du provisionnement, des déploiements et de tout le reste ; la clé privée est stockée chiffrée et n'est jamais partagée entre serveurs. La première connexion enregistre la clé d'hôte SSH du serveur, et Vimonto Deploy refuse de se connecter si cette clé change un jour.

Pare-feu et fail2ban#

Le pare-feu ufw est réinitialisé et configuré pour refuser tout le trafic entrant et autoriser tout le trafic sortant. Il autorise :

• le port SSH (22, ou le port saisi pour un VPS personnalisé), ainsi que le port sur lequel sshd écoute réellement s'il est différent (pour les serveurs derrière un NAT) ;
• les ports 80 et 443 sur les serveurs d'application, les serveurs web et les load balancers ;
• sur les serveurs de base de données, de cache et Meilisearch dans un réseau privé, leurs ports de service, uniquement depuis la plage d'adresses de ce réseau : 3306 (MySQL, MariaDB) ou 5432 (PostgreSQL) sur un serveur de base de données, 6379 (Redis) et 11211 (Memcached) sur un serveur de cache, et 7700 sur un serveur Meilisearch. Sans réseau privé, aucune règle de ce type n'est ajoutée et ces ports restent fermés.

fail2ban est activé pour bloquer les adresses qui échouent à répétition à se connecter en SSH. Gérez ensuite les règles de pare-feu sur la page réseau du serveur, où sont listées les règles issues du provisionnement. Pour déplacer SSH sur un autre port plus tard, changez le Port SSH dans les paramètres du serveur : la règle de pare-feu et fail2ban suivent.

Mises à jour de sécurité automatiques#

unattended-upgrades est activé : les listes de paquets sont mises à jour et les mises à jour de sécurité installées chaque jour, et les anciens paquets sont nettoyés chaque semaine.

Nginx#

Sur les serveurs d'application, les serveurs web et les load balancers :

• Nginx tourne sous l'utilisateur du serveur et masque sa version (server_tokens off).
• Les requêtes jusqu'à 64 Mo sont acceptées (client_max_body_size 64M), et la compression gzip est activée pour le texte, le CSS, le JavaScript, le JSON, le XML et le SVG.
• Le site par défaut est supprimé. Un serveur fourre-tout répond aux requêtes pour des noms d'hôte inconnus par rien du tout (statut 444), plutôt que d'afficher le premier site.
• La configuration est vérifiée avec nginx -t avant le redémarrage de Nginx.

Chaque site reçoit ensuite sa propre configuration ; consultez Nginx.

PHP#

Sur les serveurs d'application, web et worker, la version de PHP choisie (8.1 à 8.5) est installée depuis le dépôt ondrej/php, avec PHP-FPM et ces extensions : bcmath, cli, curl, fpm, gd, igbinary, imagick, intl, mbstring, memcached, msgpack, mysql, pgsql, readline, redis, soap, sqlite3, xml et zip.

• PHP-FPM tourne sous l'utilisateur du serveur, avec jusqu'à 5 processus.
• Réglages de PHP-FPM : memory_limit 512 Mo, uploads jusqu'à 64 Mo, max_execution_time 60 secondes, max_input_vars 1000, OPcache activé, expose_php désactivé, fuseau horaire UTC.
• La ligne de commande reçoit memory_limit = 1G.
• Composer est installé dans /usr/local/bin/composer, après vérification de la signature de son installateur.

Modifiez ces réglages et installez d'autres versions sur la page PHP.

Node.js#

Les serveurs d'application et web reçoivent Node.js 22 avec npm, depuis NodeSource, pour compiler les assets front-end pendant les déploiements.

Base de données#

Les serveurs d'application (sauf si vous avez choisi Aucun) et les serveurs de base de données reçoivent la base de données choisie :

Pour chaque base de données :

• Un utilisateur de base de données nommé d'après l'utilisateur du serveur (vimonto) est créé avec tous les droits et le mot de passe de la base de données : 32 lettres et chiffres aléatoires, affiché une seule fois. Une base de données du même nom est également créée.
• MySQL et MariaDB utilisent utf8mb4 avec utf8mb4_unicode_ci, UTC et jusqu'à 300 connexions. L'utilisateur root n'a pas de mot de passe et ne peut se connecter que depuis le serveur lui-même.
• PostgreSQL utilise UTC et jusqu'à 300 connexions, et accepte les connexions par mot de passe (scram-sha-256) ; c'est le pare-feu qui décide qui peut se connecter.
• Sur un serveur d'application, la base de données n'écoute que sur le serveur lui-même. Sur un serveur de base de données, elle écoute sur toutes les adresses pour que vos autres serveurs puissent s'y connecter : dans un réseau privé, le pare-feu les autorise déjà (voir plus haut), sinon une fois que vous avez ajouté une règle pour eux.

Le provisionnement vérifie aussi que la version installée est bien celle choisie. Gérez les bases de données et les utilisateurs sur la page bases de données.

Redis et Memcached#

Les serveurs d'application et les serveurs de cache reçoivent Redis et Memcached. Sur un serveur d'application, ils n'écoutent que sur le serveur lui-même. Sur un serveur de cache, ils écoutent sur toutes les adresses et Redis tourne sans protected mode, pour vos autres serveurs ; dans un réseau privé, le pare-feu n'autorise leurs ports que depuis ce réseau.

Meilisearch#

Un serveur Meilisearch reçoit le dernier binaire Meilisearch, qui tourne sous son propre utilisateur système meilisearch via systemd, en mode production sur le port 7700, avec ses données dans /var/lib/meilisearch. La master key est le mot de passe généré affiché une seule fois comme Clé maître Meilisearch.

Supervisor#

Les serveurs d'application, web et worker reçoivent Supervisor, qui maintient en marche vos queue workers et vos autres processus.

Finalisation et agent de monitoring#

Les dernières étapes :

• ajoutent deux tâches planifiées standard qui s'exécutent en root : Mettre à jour Composer (chaque nuit) et Nettoyer les paquets inutilisés (chaque semaine) ;
• suppriment les paquets devenus inutiles et nettoient le cache des paquets ;
• enregistrent la version d'Ubuntu et la clé publique du serveur ;
• installent l'agent de monitoring : un petit script bash que cron exécute chaque minute. Il mesure le CPU, la charge, la mémoire, le disque et le réseau, et les envoie à Vimonto Deploy. Rien n'écoute sur le serveur pour lui. Consultez monitoring.

Si seule l'installation de l'agent échoue, le serveur reste actif ; vous pouvez réinstaller l'agent sur la page Monitoring.

Une fois tout terminé, le serveur passe à Actif et ce qui a été installé apparaît sur ses pages : les règles de pare-feu, la version de PHP, la base de données et son utilisateur, les clés SSH et les tâches planifiées.

Les membres qui voient le serveur reçoivent une notification Serveur prêt, ou Échec de la configuration d'un serveur si le provisionnement s'arrête sur une erreur, par les canaux qu'ils ont choisis dans les notifications.

Que faire si le provisionnement échoue ?#

Quand une étape échoue, la tâche s'arrête, le serveur prend le statut Échoué et sa page affiche Échec du provisionnement avec l'étape et son code de sortie. La sortie sous Détails et log montre ce qui s'est mal passé.

1. Lisez la sortie de l'étape échouée. Causes courantes : un miroir de paquets temporairement injoignable, un serveur qui ne démarre pas ou n'accepte pas SSH dans les 15 minutes, un pare-feu chez le fournisseur qui bloque SSH, ou un système qui n'est pas Ubuntu 24.04 ou 26.04.
2. Corrigez la cause, si elle se trouve de votre côté.
3. Choisissez Réessayer sur la page du serveur. Cela nécessite la permission de créer des serveurs.

Le provisionnement repart alors depuis le début. C'est sans risque : un serveur déjà créé chez le fournisseur n'est pas recréé, chaque étape vérifie ce qui est déjà fait, et apt-get attend et réessaie quand des verrous sont détenus par les mises à jour automatiques. Si vous aviez déjà confirmé les mots de passe, de nouveaux mots de passe sudo et de base de données sont générés et affichés une nouvelle fois. Les mêmes clés SSH sont installées qu'à la première tentative, même si une clé de compte a été supprimée entre-temps.

Questions fréquentes#

Combien de temps dure le provisionnement ?#

Généralement 5 à 15 minutes au total. La mise à jour d'Ubuntu et l'installation de la base de données prennent l'essentiel du temps ; un serveur de cache ou un load balancer est plus rapide qu'un serveur d'application.

Puis-je voir les commandes exécutées ?#

Oui. La sortie de chaque étape se trouve dans la tâche, sous Détails et log sur la page du serveur ou sur la page Activité.

Quel est le nom de l'utilisateur système ?#

vimonto par défaut. Le nom est enregistré pour chaque serveur à sa création.

Le provisionnement modifie-t-il mon serveur une fois terminé ?#

Non. Après le provisionnement, les modifications n'ont lieu que lorsque vous ou un déploiement les effectuez, en plus des mises à jour de sécurité automatiques d'Ubuntu et des tâches planifiées standard.