On refait à nouveau tout mais on fait ça bien !

On va ENCORE discuter architecture de services et de serveur, mais promis, ça ne sera pas de la redite :’D.

J’ai dû changer de serveur. Pas parce qu’il a brûlé un an auparavant, néanmoins, c'est lié à l’incendie.

Dans une volonté d’amélioration de la résilience de ses datacenters de Strasbourg, OVH a décidé d’également démolir le datacenter SBG4, bien que non touché par l’incendie (celui-ci ne répondant plus aux nouveaux critères de sécurité incendie en train d’être instaurés par l’hébergeur).
La nouvelle est tombée courant novembre 2021, et j’allais avoir jusqu’à fin février 2022 pour migrer sur un nouveau serveur dédié avant d’être résilié de force. J’ai donc un peu procrastiné, mais début janvier, j'ai pris mon courage à deux mains. Alors, j'ai migré vers un nouveau serveur, un peu plus cher, mais doté d'une meilleure configuration (donc je m’y retrouve largement).

J'ai au passage profité de ma procrastination pour quand même commencer à réfléchir à ce que j’allais faire, et comment. Je voulais en profiter pour me forcer à relancer ce blog, même si je me souvenais des écueils rencontrés. Du coup, j’ai voulu essayer de les éviter à la source.

Ce qui nous amène à une partie de la solution : la conteneurisation.

Si je veux pouvoir déployer différents services sur un même serveur, tout en ayant un niveau de résilience cohérent, mais également limiter les impacts croisés et les problèmes de configuration parce que tel et tel services veulent utiliser le même port sans me laisser la possibilité de changer ça, la conteneurisation (via Docker, je spoile la suite) semble être une solution en même temps pratique, assez facile et challengeante pour mes compétences.

Enormément de logiciels/services modernes qui sont distribués et installables en natif ou en exécutant un script d’installation, ont aussi une procédure d’installation via des images Docker, voire ne sont distribués que de cette manière ! Il n’y a qu’à voir tout ce que l'on trouve sur Docker Hub. Ou tout ce que l’on peut trouver si l’on accole docker à n’importe quel nom de service ou application que l’on souhaite installer sur un serveur. C’est énormément utilisé dans le monde professionnel, la communauté est énorme : tout est là pour choisir cette solution.

Maintenant, on gère ça comment ? Tout à la main en notant sur un bloc-notes les lignes de commandes (potentiellement de trois pieds de long) nécessaires à lancer chaque conteneur ? Ou alors on utilise des solutions de déploiement complexes qu’utilisent beaucoup d’entreprises (mais vlà la galère pour se lancer là-dedans de zéro) ?

Dans les alternatives entre ces deux extrêmes, on a Docker Compose. C’est une solution hyper intéressante qui se base sur des fichiers de configuration au format .yml dans lequel on va écrire de façon simple à prendre en main et à comprendre comment déployer un ou des conteneurs.

Maaaaiiiissss on peut encore un peu se simplifier la vie, rendre la gestion de ces fichiers de configuration plus facile via l’utilisation d’une application web dédiée, Portainer et c’est la solution que j’ai choisie. Mais j’y reviendrai plus tard.

Déployer ses applications via Docker c’est bien, cependant ça ne me suffit pas. Je voulais pouvoir y accéder simplement, via un sous-domaine qui m’appartient. Alors j’ai dû mettre en place un reverse proxy, et sur les conseils d’un ami j’ai jeté mon dévolu sur Nginx Proxy Manager.

L’intérêt d’un reverse proxy, c’est de pouvoir mettre à disposition une ressource (une application ou une API) derrière un sous-domaine plus simple à retenir. Cela a aussi comme effet secondaire, associé à des conteneurs Docker, de se simplifier la gestion des ports ouverts sur le serveur.

En effet, le reverse proxy servant de barrière à l’entrée, plus besoin d’ouvrir de multiples ports du serveur vers l’extérieur. Le trafic pour une ressource est récupéré via le port 80 ou le port 443 et automatiquement transféré au bon endroit selon le sous-domaine utilisé. Un bonus sur le plan sécurité !

Avec tout ça, j’ai alors une bonne base pour pouvoir simplement et rapidement déployer de nouveaux services, tester de nouvelles applications. Le tout depuis un navigateur (parce que si je suis à l’aise dans un terminal Linux, je suis aussi feignant).

Et j’ai PPPPPLLLLLLLLEEEEIIIIINNNNN d’idées de services que j’aimerais tester et dont je pourrais vous parler ! À commencer par ceux déjà mit en place pour soutenir ce blog.