Vous souhaitez héberger votre application ou votre site internet mais perdus dans le nombre d'offres proposées, vous cherchez désespérément à comprendre et trouver la solution la plus adaptées à votre cas ? Cet article est fait pour vous.

Les 4 types d’hébergement

  • Mutualisé : Un hébergement avec une interface de gestion, un « panel ». Il est partagé entre plusieurs utilisateurs de façon à optimiser les coûts. Pas d’accès root, on ne peut donc pas installer ce que l’on veut mais c’est le plus simple à prendre en main. On peut l’utiliser sans aucune compétence technique.
  • Dédié : Un ordinateur complet avec accès root souvent puissant en location à distance. C’est assez cher puisqu’on paye en permanence un serveur dans son intégralité.
  • VPS : Une machine virtuelle dans un serveur avec accès root. Les ressources allouées sont également dédiées à l’utilisateur. Au final c’est comme acheter un bout de server dédié ou un petit serveur dédié a bon prix.
  • Cloud : Une infrastructure complète composée de plusieurs serveurs. Cela permet d’adapter en temps réel le nombre de serveurs et l’on paye à la seconde de consommation. Les avantages par rapport au dédié sont la scalabilité et la disponibilité.

Le mutualisé

La plupart des hébergements mutualisés sont basés sur C-Panel, une solution permettant d’effectuer différentes tâches sur son serveur via une interface graphique dans le navigateur sans nécessité de savoir maîtriser le terminal linux.

On peut gérer les fichiers avec une interface similaire à celle d’un Drive (en moins bien c’est vrai), créer et accéder à ses emails, héberger une application PHP, parfois lorsque c’est actif un application NodeJS ou Python (mais c’est galère, je déconseille le mutualisé pour ce type d’application), installer facilement un Wordpress, un Prestashop ou encore un Piwigo.

Je dirais que l’hébergement mutualisé est particulièrement adapté s’il s’agit d’un petit site Wordpress ou HTML/CSS/JS statique avec un budget restreint. Donc plutôt un blog ou un site vitrine mais pas vraiment une application.

Où trouver un hébergement mutualisé ?

Chez tous les hébergeurs, voici quelques exemples :

Sauvegardes

Pensez à sauvegarder régulièrement votre site internet pour ne pas risquer de tout perdre. Si vous n'êtes pas à l'aise avec cette idée, essayez de trouver un hébergeur qui propose lui même des sauvegardes et/ou de la redondance.

Le VPS et le serveur dédié

Étant donné qu'ils ont des caractéristiques similaires, je les regroupe dans la même partie.

VPS = Virtual Private Server = Machine virtuelle avec accès root accessible à distance en ligne de commande.
-> C’est comme un ordinateur sauf qu’il a pas d’interface mais il a donc comme n’importe quel PC un processeur, du stockage, de la RAM…

Où trouver un serveur VPS

On trouve des VPS chez tous les hébergeurs voici quelques exemples :

Souvent pour être tranquille avec deux ou trois applications je recommande au moins 2GO de RAM.

Après avoir acheté un VPS

Une fois votre VPS commandé, votre hébergeur vous enverra sous quelques heures par email votre adresse IP, votre identifiant et votre mot de passe, vous pourrez ainsi commencer à le contrôler à distance.

Accès à distance

Protocole SSH = Secure Shell = Commande à distance d’un serveur via le terminal
-> Pour se connecter via SSH on a besoin de l’adresse IP, l’identifiant et le mot de passe (parfois également le port s’il diffère). Ce sont les infos transmises par l’hébergeur après la mise en place.

Logiciels d’accès à distance

Termius / PuTTY = Client SSH = Logiciel qui permet de commande à distance un ordinateur via le terminal.

Connecter un nom de domaine à un serveur (dédié ou VPS)

-> Ajouter un enregistrement de type A avec l’adresse IP du serveur dans la zone DNS sur la plateforme qui a vendu le nom de domaine.

Exemple d’adresse IP : 172.145.80.60

Exemple d’enregistrement DNS :

www.retl.me 3600 IN A 172.145.80.60

Explication du Reverse Proxy

Un reverse proxy est une application qui permet de distribuer les requêtes entre les différentes applications installées sur un serveur et peut également gérer les certificats SSL (pour le HTTPS).

Fonctionnement

Quand un requête HTTP arrive sur le serveur, elle passe par le port 80 et avec HTTPS c’est le port 443.

Exemple de port : 3000
IP + port : 172.145.80.60:3000
IP locale de votre machine : localhost
Application sur le port 3000 de votre machine : localhost:3000

Le reverse proxy prend toute les requêtes et le redirige au bon endroit en fonction d’un fichier de configuration par exemple :

timtiret.com {
    reverse_proxy localhost:3000
}

test.timtiret.com {
    reverse_proxy localhost:8080
}

Ici mon reverse proxy va rediriger les requêtes qui proviennent du nom de domaine timtiret.com vers le port 3000 et celles du nom de domaine test.timtiret.com vers le port 8080.

Différents outils de serveur web (reverse proxy)

L’outil de serveur web le plus connu est Apache mais il existe également NGINX, Caddy et d’autres encore que je ne connais pas forcément.

Personnellement j’apprécie l’usage de Caddy car il est simple et gère automatiquement le HTTPS en plus d’être performant et de disposer d’une API Rest. L’API Rest signifie que l’on peut le controler en envoyant des requêtes HTTP depuis une application sur le serveur.

Vous pouvez le tester, c’est aussi simple que ça

Faire tourner son application

Si c’est une application PHP, vous pouvez directement configurer son dossier et le nom de domaine via votre serveur Web.

Si votre application tourne sous Python ou NodeJS, vous aurez besoin un « process manager » tel que PM2 ou PYPM pour faire tourner votre application, la monitorer et la redémarrer automatiquement en cas d’erreur.

Vous n’avez qu’à la lancer sur un port inutilisé de votre machine et configurer votre reverse proxy pour qu’il fasse la redirection des ports 80 et 443 vers votre application lorsque le bon nom de domaine est à l’initiative de la requête.

Sauvegardes VPS

Plusieurs solutions s'offrent à vous. Certaines offres VPS proposent des snapshots, ce sont des instantanées du serveur qui peuvent être restaurés en cas de problème ou d'erreur, réduisant ainsi le risque de perdre ses données.

Je conseille tout de même dans tous les cas de mettre en place un script pour sauver notamment vos bases de données de façon régulière mais cela dépend souvent du type d'application que vous hébergez. ChatGPT est souvent votre meilleur allié pour la création d'un script, attention tout de même à bien tester dans un environnement de test avant de risquer un script dangereux sur votre serveur de production.

Le cloud

Le cloud est un hébergement qui ne dépend pas d'une seule machine. Un fournisseur cloud nous met à disposition un ensemble de services qui tournent sur des machines distinctes.

Avantages et inconvénients

Ce système a beaucoup d'avantages mais aussi des inconvénients.

Dans un premier temps, il nécessite une expertise importante et est assez coûteux ce qui se rattrape par le fait qu'on ne paye que ce dont on a besoin à la seconde près.

L'avantage principal est la scalabilité : je peux démarrer autant de machines que je le souhaite si j'en ai besoin et adapter la taille de machines au nombre d'utilisateurs présents sur mon application. Cette redondance des machines vient aussi avec un autre avantage qui est la haute disponibilité. En effet, lorsqu'un serveur tombe en panne, ce n'est pas grave puisqu'un autre prend le relais automatiquement et immédiatement.

Schéma de fonctionnement du cloud

Voici un schéma simplifié du fonctionnement du cloud. Chaque élément coloré est un serveur distinct. Je vous explique en dessous l'utilité de chacun.

Schéma explicatif du cloud avec load balancer, application (stateless), base de données (statefull) et réplica de cette base de données (statefull également)

Quand vous souhaitez faire tourner une application dans les autres types d'hébergement, vous avez souvent une base de données et votre application qui travaillent conjointement sur le même serveur. Dans le cloud, pour répondre aux contraintes de scalabilité de de disponibilité, on sépare chaque service dans des machines distinctes que l'on réplique de sorte à pouvoir les remplacer facilement sans temps d'arrêt du service (downtime).

Le cas le plus simple serait de ne garder qu'une application (carré vert) et une base de données (carré rouge). L'avantage de séparer la base de données est que l'application peut être "stateless", c'est à dire sans état. Cela signifie qu'elle ne contient aucune données et qu'elle délègue cette partie à la base de données. Le gros avantage est que comme elle n'a pas d'état spécifique ou d'options à enregistrer, elle est interchangeable à l'infini de façon totalement transparente pour l'utilisateur qui retrouve de toute façon ses données peu importe sur quel serveur d'application il est arrivé.

Un load balancer (ici en bleu) est un répartiteur de charge. Ce serveur est celui sur lequel l'on fait pointer notre nom de domaine et à chaque fois qu'il reçoit une requête, il se contente de l'a distribuer sur l'un des serveurs applicatifs. Il ne fait aucun traitement, juste une répartition, ce qui ne demande aucune puissance et lui permet alors de recevoir du traffic dans des quantités colossales.

Quand une requête arrive, elle passe donc par le répartiteur de charge (load balancer) puis est redirigée aléatoirement vers l'un des serveurs d'application qui s'occupe de la logique et d'héberger le contenu statique (qui ne change pas). Si nécessaire il interroge la base de données et génère un réponse qu'il renvoie au load balancer qui le renvoie à l'ordinateur de l'utilisateur via le réseau internet.

Sauvegardes

Une base de données critique (importante) possède souvent un réplica. C'est une copie conforme de la base de données qui est faite en temps réel. Cela permet d'avoir à tout moment une sauvegarde et une autre base de données au cas où la première tomberait en panne et dans le cas où les requêtes en lectures sont importantes, elles peuvent également être réparties entre plusieurs réplicas. Seule l'écriture doit rester sur une seule machine car sinon cela pourrait créer des collisions et incohérence dans les bases de données par exemple si qu'un connecte une ressource à un élément qui a été supprimé par un autre utilisateur sans que le réplica ne soit déjà au courant. Cela ne génère pas d'erreur pour l'utilisateur mais crée une incohérence dangereuse dans la base de données qui peut être difficile voire impossible à résoudre.

Les bases de données sont aussi souvent un service managé (DBaaS : Database as a Service), cela signifie qu'il est géré par l'hébergeur et qu'il est de sa responsabilité d'en faire des sauvegardes. Pour autant cela ne devrais pas vous en dispensez en vue de la criticité de cet élément.

Autres services

Beaucoup d'autres services sont proposés par les fournisseurs de cloud comme des Object Storages qui sont des espace permettant de gérer des fichiers de façon redondée, scalable et sécurisée. Il existe aussi des services de files d'attente : quand par exemple notre base de données ne peut supporter un nombre de requêtes plus important et qu'il faut alors une file tampon pour absorber les pics de charge. Cela peut aussi être utile dans le cas de serveurs de traitement de données dont les tâches prennent un certain temps pour temporiser et traiter au fur et à mesure les demandes en étalant les demandes sur le temps nécessaire.

La solution SaaS

Une autre façon d'utiliser le cloud sans compétences techniques est d'utiliser une solution SaaS (Software as a Service) pour créer son site tel qu'un Wordpress managé, un Shopify ou encore un Wix. Ici, vous payez un abonnement tous les mois qui inclus un nombre de visites souvent illimité et c'est le service qui s'occupe de gérer votre hébergement quasiment exclusivement avec une infrastructure cloud.

Fournisseurs cloud

Parmi les fournisseurs cloud il y a principalement les PaaS (Plateform as a Service) et les IaaS (Infrastructure as a Service).

Les PaaS s'occupent de tout gérer pour vous et vous n'avez qu'à leur donner votre application. C'est par exemple le cas de ceux-ci :

Les IaaS sont ceux qui font tourner la plupart des grosses applications et sites de nos jours. En voici quelques uns :

Le CDN (Content Delivery Network)

Un réseau de distribution de contenu est un ensemble de serveur répartis au 4 coins du monde qui permet de distribuer votre application sans latence et au plus proche de l'utilisateur. Cela fonctionne particulièrement bien quand il s'agit de sites statiques car l'avantage de la latence et la scalabilité infinie vient avec un temps de propagation relativement long et l'impossibilité d'afficher en temps réel des données dynamiques rendues côté serveur.

Le CDN s'installe sur n'importe quel hébergement et permet de bénéficier des avantages du cloud sur un site statique pour tout le monde et à moindre coût (voire gratuitement). Il agit en tant qu'intermédiaire entre l'utilisateur et le serveur. On fait donc pointer le nom de domaine sur le CDN qui lui pointe sur notre serveur web tout simplement.

Moyennant quelques compétences techniques et avec les offres gratuites des gros fournisseurs de cloud (AWS/GCP ou Azure) vous pouvez mettre en place gratuitement un site statique ultra scalable avec très haute disponibilité.

Voici les plus connus :

Et oui, tous les gros fournisseurs de cloud ont leur CDN...

Introduction à l’hébergement et l’administration système (SysAdmin)