Je suis en train de refondre complètement mon hébergement web self-hosté. Je disposais jusqu’à il y a peu d’un serveur dédié Dedibox, mais force est de constater que le processeur de ces machines est vraiment léger par rapport aux pics de trafic que je reçois.
Alors oui que le premier réflexe face à un machine qui souffre, c’est 1. optimiser et 2. mettre en cache. Oui, sauf que… tout ça, j’ai déjà fait. Mes sites sont derrière Cloudflare, j’ai un cache Nginx, un cache Redis, j’ai cherché à cacher les requêtes Mysql, et malgré ça…
Je me suis donc amusé à comparer les offres. Repartir sur une Dedibox qu’il faudra changer dans deux ans, moyen. Les processeurs Intel Xeon E3 sont définitivement low cost pour cet usage, et malgré un prix plutôt élevé (environ 70 euros par mois) la qualité n’est vraiment pas là.
En fouillant un peu, je suis tombé sur un hébergeur Allemand, Hetzner. Il pratique des tarifs de serveurs dédiées très proches de Dedibox, mais base sa gamme sur des AMD Ryzen™ 5 3600. Et niveau performances sur le papier des benchmarks, c’est autre chose. Quasiment trois fois plus puissant !
Ni une ni deux, j’ai donc commandé un serveur dédié chez eux. 64 Go DDR4, 3x 512 Go SSD. Les prix sont très corrects. Celui que j’ai choisi me coûte environ 60 euros par mois, avec un peu plus de stockage SSD que la version standard. L’intérêt aussi chez Hetzner c’est que les serveurs sont disponibles immédiatement pour la plupart, mais surtout il n’y a pas de frais de mise en service, contrairement à d’autres (suivez mon regard).
Mon objectif c’est donc de disposer de plus de puissance, et tant qu’à migrer, en profiter pour rationaliser. Je dispose en effet de deux Dedibox, une pour héberger un site gros consommateur de ressources, et un second qui héberge d’autres sites web plus modestes (dont celui-ci). L’idée c’est de tout regrouper sur un seul serveur tout en conservant de l’agilité quant à l’affectation des ressources.
J’ai donc choisi d’installer Proxmox sur ce gros serveur, et de faire tourner des VMs à l’intérieur. Les premiers tests sont concluants. En gros voici comment ça s’est passé.
- Installation d’une Debian puis de Proxmox.
Facile.
2. Installation d’un client OpenVPN qui se connecte sur le routeur de la maison. La GUI de management Proxmox est bindée sur l’adresse IP du VPN, ainsi je peux donc l’atteindre sans l’exposer sur Internet.
3. Là ca devient technique geek. Mise en place d’un bridge pour que toutes les VMs puissent communiquer entre elles et avec le host. Il faut aussi penser à paramétrer des règles de NAT / Masquerading pour que les VMs puissent sortir sur Internet.
4. Installation de Nginx Proxy Manager en frontend. J’ai testé ce tuto qui préconise l’installation sur une Alpine Linux 3.16 dans un conteneur LXC mais ça ne fonctionnait pas correctement, il me fallait OpenVPN et c’était une vraie galère d’installer les interfaces réseaux, les modules, etc. En m’inspirant du tuto, j’ai donc installé une Alpine Linux 3.16 standard dans une VM, puis j’ai installé NPM avec ce script. De là, la configuration du VPN a été un jeu d’enfant. Juste, bien penser à lancer les scripts setup-alpine et setup-bootable une fois l’ISO Alpine démarrée. Ca déroute un peu.
L’adressage est le suivant : le host Proxmox récupère une IP publique (celle de l’hébergeur), il possède aussi une IP en 172.16.0.1 par exemple. Les VMs prennent une IP sur cette plage privée. Ainsi, mon Nginx Proxy Manager est installé au chaud dans une VM (IP 172.16.0.103), il faut penser à appliquer la règle de NAT qui va bien sur le host pour rediriger les ports 80 et 443 sur cette IP.
5. Configurer ensuite Nginx Proxy Manager avec les bonnes redirections par nom d’hôte, vers la VM qui héberge les sites.
5. bis Pensez à générer de nouveaux certificats SSL. Nginx proxy Manager permet de gérer ça en deux clics !
6. Une fois que vous en êtes là, vous êtes bon pour migrer vos sites un à un. J’utilise Wordops pour faciliter la gestion de mes sites WordPress et leur configuration. Wordops installe aussi un backend avec Phpmyadmin, Netdata, etc. Vraiment top !
7. Attention avec cette configuration, vos WordPress vont paniquer et se lancer dans une boucle infinie de redirections 302. En réalité, comme votre WordPress voit arriver une URL en HTTP, il s’empresse de demander à votre navigateur la page correspondante en HTTPS. Votre navigateur demande alors au Nginx Proxy. Qui redirige sur le WordPress sur une page HTTP. Et ainsi de suite… Pour contourner ce problème, c’est très simple. Ajoutez cette directive dans la config Nginx de votre serveur WordPress, fichier fastcgi_params (ou section Location de votre configuration de vhost).
Explications détaillées ici et là.
Voilà. Je vais donc démarrer la migration avec de petits sites web, voir comment la machine réagit. Avantage, si je ne suis pas content de cette configuration, j’aurai juste à exporter ma configuration Proxmox sur un autre serveur.
A suivre !