# Types de serveurs : application, web, worker, cache et plus

> Comparez les types de serveurs : application, web, worker, base de données, cache, Meilisearch et load balancer, ce que chacun installe et ses pages.

Un type de serveur est le rôle que vous donnez à un serveur quand vous le [créez](https://ops.vimonto.com/docs/fr/servers/create-a-server). Le type détermine ce que Vimonto Deploy installe pendant le [provisionnement](https://ops.vimonto.com/docs/fr/servers/provisioning), les ports que le pare-feu ouvre et les pages dont le serveur dispose dans Vimonto Deploy. Vous ne savez pas lequel choisir ? Prenez un **Serveur d'application** : il fait tout tourner sur une seule machine et convient à la plupart des applications.

Les autres types vous permettent de répartir une application sur plusieurs serveurs à mesure qu'elle grandit : des serveurs web derrière un load balancer, des workers séparés pour les files d'attente, et des serveurs dédiés de base de données, de cache et de recherche, reliés par un [réseau privé](https://ops.vimonto.com/docs/fr/servers/network).

![La vue d'ensemble d'un serveur avec la barre latérale des pages propres à son type](https://ops.vimonto.com/docs-media/fr/server-overview.webp?v=161e760d "Les pages de la barre latérale d'un serveur dépendent de son type")

## Quel type de serveur choisir ?

| Type | Usage | Installe |
| --- | --- | --- |
| **Serveur d'application** | Tout sur un seul serveur. Convient à la plupart des applications. | Nginx, PHP, une base de données (facultative), Redis, Memcached, Node.js, Supervisor |
| **Serveur web** | Servir votre application, avec la base de données et le cache sur d'autres serveurs. | Nginx, PHP, Node.js, Supervisor |
| **Serveur worker** | Les queue workers et autres processus PHP de longue durée. Non accessible en HTTP. | PHP, Supervisor |
| **Serveur de base de données** | Une base de données pour vos serveurs d'application, web et worker. | MySQL, MariaDB ou PostgreSQL |
| **Serveur de cache** | Redis et Memcached pour vos serveurs d'application, web et worker. | Redis, Memcached |
| **Serveur Meilisearch** | Un moteur de recherche rapide pour votre application, accessible via le réseau privé. | Meilisearch |
| **Load balancer** | Répartir le trafic d'un domaine entre vos serveurs d'application et serveurs web. | Nginx |

Chaque type reçoit aussi la même base : mises à jour d'Ubuntu, utilisateur du serveur, durcissement SSH, pare-feu `ufw`, fail2ban, mises à jour de sécurité automatiques, swap, tâches planifiées standard et agent de monitoring.

## Quelles pages chaque type propose-t-il ?

Un serveur n'affiche que les pages qui ont du sens pour ce qui y est installé.

| Page | Application | Web | Worker | Base de données | Cache | Meilisearch | Load balancer |
| --- | :-: | :-: | :-: | :-: | :-: | :-: | :-: |
| Vue d'ensemble | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Sites | ✓ | ✓ | – | – | – | – | ✓ |
| Bases de données | ✓¹ | – | – | ✓ | – | – | – |
| Sauvegardes | ✓¹ | – | – | ✓ | – | – | – |
| PHP | ✓ | ✓ | ✓ | – | – | – | – |
| Processus | ✓ | ✓ | ✓ | – | – | – | – |
| Planificateur | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Monitoring | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Terminal | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Réseau | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Clés SSH | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Services | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Paramètres | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |

¹ Uniquement si le serveur d'application a été créé avec une base de données, et non avec **Aucun**.

## Serveur d'application

Le serveur d'application a tout : Nginx, PHP (la version de votre choix, avec Composer), Node.js et npm, une base de données, Redis, Memcached et Supervisor pour les queue workers. Les ports 80 et 443 sont ouverts pour vos sites. La base de données, Redis et Memcached n'écoutent que sur le serveur lui-même (`localhost`) : ils ne sont donc pas accessibles depuis l'extérieur.

Vous pouvez créer un serveur d'application sans base de données en choisissant **Aucun** sous **Base de données**, par exemple si vous utilisez un serveur de base de données séparé. Il n'a alors pas de pages **Bases de données** ni **Sauvegardes**.

## Serveur web

Un serveur web fait tourner vos sites comme un serveur d'application, avec Nginx, PHP, Node.js et Supervisor, mais sans base de données ni cache. Reliez-le à un serveur de base de données et à un serveur de cache via un réseau privé. Utilisez plusieurs serveurs web derrière un load balancer pour absorber plus de trafic.

## Serveur worker

Un serveur worker a PHP et Supervisor pour les queue workers et autres [processus](https://ops.vimonto.com/docs/fr/servers/processes), et pas de Nginx. Le pare-feu n'autorise que SSH : il n'est donc pas accessible en HTTP. Utilisez-le pour décharger vos serveurs web du travail lourd des files d'attente.

## Serveur de base de données

Un serveur de base de données fait tourner uniquement MySQL (8.4 LTS ou 8.0), MariaDB (11.4 LTS ou 10.11 LTS) ou PostgreSQL (18, 17 ou 16) ; une base de données est obligatoire pour ce type. Contrairement à un serveur d'application, la base de données écoute sur toutes les adresses, pour que vos autres serveurs puissent s'y connecter. Si le serveur est dans un [réseau privé](https://ops.vimonto.com/docs/fr/servers/server-types#serveurs-dans-un-réseau-privé), le provisionnement autorise le port 3306 (MySQL et MariaDB) ou 5432 (PostgreSQL) depuis ce réseau uniquement. Sans réseau privé, le pare-feu refuse tout le trafic entrant vers la base de données jusqu'à ce que vous ajoutiez une règle pour les adresses de vos autres serveurs sur la page [réseau](https://ops.vimonto.com/docs/fr/servers/network) du serveur.

Le provisionnement crée un utilisateur de base de données portant le nom de l'utilisateur du serveur (`vimonto` par défaut), avec tous les droits et le mot de passe de la base de données affiché une seule fois, ainsi qu'une base de données du même nom. Gérez les bases de données et les utilisateurs sur la page [bases de données](https://ops.vimonto.com/docs/fr/servers/databases) et planifiez des [sauvegardes](https://ops.vimonto.com/docs/fr/servers/backups) vers votre propre stockage.

## Serveur de cache

Un serveur de cache fait tourner uniquement Redis et Memcached. Ils écoutent sur toutes les adresses pour que vos autres serveurs puissent les utiliser. Redis tourne ici sans mot de passe : seul le pare-feu le protège d'internet. Si le serveur est dans un [réseau privé](https://ops.vimonto.com/docs/fr/servers/server-types#serveurs-dans-un-réseau-privé), le provisionnement autorise les ports 6379 (Redis) et 11211 (Memcached) depuis ce réseau uniquement. Sans réseau privé, rien ne peut les joindre tant que vous n'ajoutez pas une règle pour les adresses de vos autres serveurs sur la page [réseau](https://ops.vimonto.com/docs/fr/servers/network).

> [!WARNING]
> N'autorisez jamais le port Redis ou Memcached depuis **Tout le monde** sur un serveur de cache. N'importe qui sur internet pourrait alors lire et modifier votre cache.

## Serveur Meilisearch

Un serveur Meilisearch fait tourner le moteur de recherche [Meilisearch](https://www.meilisearch.com/) comme service système sur le port 7700, en mode production. Sa master key est générée à la création du serveur et affichée une seule fois, avec le mot de passe sudo, comme **Clé maître Meilisearch**. Si le serveur est dans un [réseau privé](https://ops.vimonto.com/docs/fr/servers/server-types#serveurs-dans-un-réseau-privé), le provisionnement autorise le port 7700 depuis ce réseau uniquement ; sinon, ajoutez une règle sur la page [réseau](https://ops.vimonto.com/docs/fr/servers/network). Renseignez l'adresse privée du serveur et la clé dans votre application (pour Laravel Scout : `MEILISEARCH_HOST` et `MEILISEARCH_KEY`).

## Serveurs dans un réseau privé

Les serveurs de base de données, de cache et Meilisearch que vous créez dans un réseau privé reçoivent immédiatement des règles de pare-feu pour leurs services. Vos serveurs d'application, web et workers du même réseau peuvent alors s'y connecter sans autre configuration :

| Type | Ports autorisés depuis le réseau privé |
| --- | --- |
| Serveur de base de données | 3306 (MySQL, MariaDB) ou 5432 (PostgreSQL) |
| Serveur de cache | 6379 (Redis), 11211 (Memcached) |
| Serveur Meilisearch | 7700 |

Les règles autorisent la plage d'adresses du réseau, par exemple `10.0.0.0/16`. Si Vimonto Deploy ne connaît pas la plage, il utilise le `/16` autour de l'adresse IP privée du serveur. Les règles se trouvent sur la page [réseau](https://ops.vimonto.com/docs/fr/servers/network) du serveur, marquées **Par défaut** ; vous pouvez les supprimer ou ajouter les vôtres. Internet reste bloqué : le pare-feu refuse tout autre trafic entrant.

Les serveurs sans réseau privé, y compris un [VPS personnalisé](https://ops.vimonto.com/docs/fr/servers/custom-vps), ne reçoivent pas ces règles : ajoutez vous-même une règle pour chaque serveur qui doit y accéder.

## Load balancer

Un load balancer fait tourner uniquement Nginx, avec les ports 80 et 443 ouverts, et répartit le trafic d'un domaine entre vos serveurs d'application et serveurs web. Il n'a pas de PHP. Le seul type de site que vous pouvez y créer est un site **Load balancer** (sous **Nouveau site**), et ce type de site ne peut se trouver que sur un serveur load balancer.

Sur la page **Répartition de charge** du site, vous choisissez :

- la **Méthode** : **Tourniquet** (chaque serveur à tour de rôle, selon son poids), **Moins de connexions** (le serveur qui a le moins de connexions ouvertes) ou **Hachage IP** (chaque visiteur reste sur un même serveur, selon son adresse IP) ;
- les serveurs vers lesquels il envoie le trafic : avec **Ajouter un serveur**, vous choisissez un serveur d'application ou serveur web actif de votre organisation, avec un **Port**, un **Poids** (plus il est élevé, plus le serveur reçoit de trafic) et, si vous le souhaitez, comme **Serveur de secours**, qui ne reçoit du trafic que lorsque les autres serveurs sont hors service (pas avec **Hachage IP**, que Nginx ne combine pas avec des serveurs de secours). **Modifier** change ensuite le port, le poids et le réglage de secours. Le trafic passe par le réseau privé lorsque les deux serveurs sont dans le même.

Chaque serveur d'application a besoin d'un site pour le même domaine. Le load balancer transmet aux serveurs d'application l'adresse IP du visiteur et le fait qu'il est arrivé en HTTPS ou non, et les sites de ces serveurs ne font confiance à ces informations que lorsqu'elles viennent de ce load balancer. Le site à charge répartie a besoin d'un domaine à vous avant que vous ajoutiez des serveurs d'application, car ceux-ci ne peuvent pas répondre pour son adresse `on-deploy.link`. Tant qu'aucun serveur d'application n'a été ajouté, les visiteurs reçoivent une erreur 503. Toute la mise en place est décrite dans [répartition de charge](https://ops.vimonto.com/docs/fr/sites/load-balancing).

## Questions fréquentes

### Faut-il commencer avec un serveur d'application ou des serveurs séparés ?

Commencez avec un serveur d'application. C'est la configuration la plus simple et la moins chère, et elle supporte beaucoup de trafic. Séparez un serveur de base de données, un serveur de cache ou des serveurs worker quand un seul serveur ne suffit plus, ou quand vous voulez faire évoluer les serveurs web séparément.

### Comment des serveurs séparés communiquent-ils entre eux ?

Placez-les dans le même réseau privé à leur création. Les serveurs de base de données, de cache et Meilisearch autorisent alors déjà leurs ports depuis ce réseau (voir [serveurs dans un réseau privé](https://ops.vimonto.com/docs/fr/servers/server-types#serveurs-dans-un-réseau-privé)) ; pour le reste, autorisez le port depuis la plage d'adresses du réseau sur la page **Réseau** du serveur destinataire. Utilisez l'adresse IP privée affichée dans la vue d'ensemble de chaque serveur dans les réglages de votre application.

### Puis-je ajouter plus tard une base de données à un serveur web ?

Le provisionnement installe ce dont le type a besoin à la création du serveur. Choisissez un serveur d'application si vous voulez une base de données sur la même machine, ou créez un serveur de base de données et connectez-vous-y.