Docker, Nginx et déploiement

Bonsoir !

Je m’exerce sur le déploiement d’applications NodeJS et VueJS sur un serveur Linux avec Docker. J’ai un serveur de test sur DigitalOcean que j’utilise pour mes tests.

Pour le moment, je m’en sort plutôt très bien.

J’ai un docker-compose qui contient mon API, mon Frontend et mon "Reverse Proxy" qui permet de rediriger les URLs sur les bonnes applications (par exemple, monsite.com sur l’app Vue et api.monsite.com sur l’API).

Grâce au Webhook, je peux lancer un script SH pour déployer une applications indépendamment de l’autre, juste en faisant un git push du code sur une certaine branche, qui va exécuter le script, qui :

• Stoppera le container de l’application
• Le supprimera
• Le recréera.

Tout ça fonctionne bien (à part que 1) je ne sais pas encore comment faire que mon Webhook se lance tout seul, je suis obligé de lancer la commande "Webhook -hooks Hook.json" manuellement depuis mon serveur avant chaque déploiement et 2) Le GitHub action dit que le déploiement est OK car il n’attend pas le retour du Webhook et donc forcément, s’arrêt sur "Succès" dès qu’il à réussi à exécuter le Webhook - mais sans attendre le retour donc).

Cependant, j’aimerais aller un peu plus loins. J’ai deux choses en tête :

• Le Load Balancing
• Le déploiement sans intéruption

Je vais commencer par le deuxième point : Aujourd’hui, quand je déploie une application, celle-ci deviens indisponible de l’arrêt du container jusqu’à sa recréation. Existe-t-il un moyen de déployer l’application sur un nouveau container, et une fois fait, rediriger l’ancien container vers le nouveau avant de le supprimer ? Comme ça, pas d’interruption.

Pour le premier point maintenant, j’avoue avoir très peu de connaissance. Dejà, je n’ai pas bien saisi si, pour le Load Balancing, il fallait plusieurs serveur ou un seul ?

J’ai cru comprendre (et ça paraît logique) que le Load Balancing c’est quand on à plusieurs serveur, pour répartir les demandes entre ceux-ci. Mais j’ai pu lire ici et là que c’était possible avec un seul serveur, mais plusieurs container (si je me souviens bien). Avez-vous plus de détails ? Ou des lien à me donner ? J’arrive assez bien à comprendre l’anglais, mais si j’avais des ressources en français, ce serait beaucoup mieux, car là, j’ai vraiment besoin de comprendre en détail (et de comprendre les petits détails), car c’est un domaine assez compliqué pour moi, donc autant ne pas ajouter la difficulté de la langue.

Aussi, comment mettre ça en place ? Parce que j’ai vu le mot "Load Balancing" associé à plusieurs techno : Docker, Kubernetes, PM2 et Nginx. Ça veut dire quoi ? Que je peux choisir si je veut le mettre en place en utilisant uniquement Nginx, PM2 ou Docker par exemple ? Au pif, si je prend PM2 : Si j’arrive à l’atteindre, c’est que je suis déjà sur mon container qui exécute PM2, donc comment ça peut faire du "Load Balancing" ?.

Bref, c’est surtout cette partie que je trouve assez compliqué, et je n’arrive pas à trouver de ressource en français qui pourrait vraiment m’aider.

Si vous avez des liens, voir des cours gratuit ou payant (pas plus de 15€ au total, mais pour le moment, je privilégierais le gratuit), n’hésitez surtout pas !

Merci !

Hello,

Tu peux faire ton load-balancing à différents niveaux en fait :

• entre plusieurs machines ;
• entre plusieurs conteneurs/VM si tu en as ;
• entre plusieurs processus de ton serveur applicatif.

Si tu veux utiliser une seule machine et que tu as un seul processus Node par conteneur, alors tu peux mettre plusieurs conteneurs et équilibrer entre eux (ça aura l’avantage que si l’un d’eux plante un autre prendra le relais). Attention toutefois à ce que ton application soit prévue pour fonctionner avec plusieurs instances en parallèle : il faudra probablement partager des données entre elles pour que tout fonctionne bien.

Le déploiement sans interruption peut se faire de plusieurs façons, mais globalement le principe est simple : tu coupes les instances non utilisées pour les remplacer par la nouvelle version, puis tu rediriges tes utilisateurs vers ces nouvelles instances jusqu’à libérer les anciennes pour les remplacer à leur tour. Ensuite il faut voir si tu fais ça une instance à la fois, par groupe (suivant le nombre que tu as), ou toutes à la fois (en doublant donc temporairement le nombre d’instances, le temps que tout le monde passe sur les nouvelles puis purger les anciennes).

Je n’ai pas spécialement de ressources à te conseiller, j’ai appris sur le tas pour ma part et la méthode que tu vas utiliser va dépendre de ta stack actuelle et de tes besoins.

Aussi, comment mettre ça en place ? Parce que j’ai vu le mot "Load Balancing" associé à plusieurs techno : Docker, Kubernetes, PM2 et Nginx. Ça veut dire quoi ? Que je peux choisir si je veut le mettre en place en utilisant uniquement Nginx, PM2 ou Docker par exemple ? Au pif, si je prend PM2 : Si j’arrive à l’atteindre, c’est que je suis déjà sur mon container qui exécute PM2, donc comment ça peut faire du "Load Balancing" ?.

Je vois que tu mentionnes Kubernetes. Je ne pense pas que ça réponde à ton besoin immédiat (faire les trucs un peu à la main pour toucher à ces problématiques), mais je pense que c’est pas mal de te situer le truc parce que tu vas forcément très souvent tomber dessus dans tes recherches.

Kubernetes est un orchestrateur. Tu peux le visualiser comme une techno qui va prendre un nombre arbitraire de machines, et balancer tes conteneurs en les équilibrant sur ces machines, en réagissant en temps réel quand une machine tombe ou que tu en ajoutes de nouvelles. Autrement dit, pour garder une idée simple en tête, tu peux te dire que ça remplit le rôle de docker-compose sur un cluster variable de machines, en gérant automatiquement les problématiques que tu décris (load balancing, mise à jour à chaud sans interruption, etc.).

Merci pour ta réponse !

Je vais me renseigner sur tout ça. Mais avant, je vais faire trois pas en arrière…

Le truc du Webhook m’énerve un peu. Et c’est fou, ça fait bien 3 ou 4 heures que je fait des recherches, et je ne trouve AUCUN tuto pour déployer une application Docker.

Ça doit exister forcément !

J’aimerais juste :

• Push mon code sur une certaine branche GitHub
• Le déploiement se fait sur mon serveur DigitalOcean

Même ça je n’y arrive plus…

J’ai cette structure de projet :

• api (projet git)
  • …
• frontend (projet git)
  • …
• docker-compose.prod.yml
• docker-compose.dev.yml

Moi je veux juste me rendre dans un des projet git, et faire un "git push" pour déployer cette app. N’existe-t-il pas des cours sur comment faire ça ?

Pour utiliser les webhooks sans outils, il te suffit de créer un mini serveur HTTP dans le langage que tu veux qui écoute sur un port et attend une adresse particulière. Puis sur ce bout de code, tu exécutes tes instructions de déploiement. Un script bash à côté ou même directement en faisant des appels bash. Ensuite dans ton projet GIT, tu saisis ton URL en le rattachant à une branche et roule ! rien de plus simple

Après si tu suis cette logique, tu peux même affiner tes choix en utilisant par exemple Node RED pour écouter et exécuter tes instructions. Ou prendre un outil de CI tout fait mais je n’ai pas assez de recul ; mes apps je préfère en général les mettre à jour à la main pour suivre le déroulement et corriger les potentiels bugs de build.

Sinon en solution intermédiaire plutôt cool pour gérer le load balancing tu as Docker Swarm.

mes apps je préfère en général les mettre à jour à la main pour suivre le déroulement et corriger les potentiels bugs de build.

En ce qui me concerne, c’est aussi l’approche que je favorise.

Sur le papier il faudrait tout automatiser jusqu’au déploiement des nouvelles versions en prod, mais dans la réalité, sur un projet un tant soit peu compliqué, déployer ça veut aussi souvent dire que des migrations de base de données vont être appliquées, des scripts de mise à jour s’exécuter, etc. Et dans ce genre de cas, je préfère aussi garder la main sur le moment où je déploie, ne serait-ce que pour être là et surveiller que tout se passe bien.

Quitte à devoir surveiller ce qui se passe, autant être celui qui tape la commande pour déployer, puisque de toute façon ça sera à moi de lancer la commande pour rollback si un problème survient. Et c’est pour ça que ma CI s’arrête à la publication des images de conteneurs sur le registry.

Donc vous voulez dire que vous vous connectez au serveur en SSH, et que vous faite le reste à la main ? Récupération du code, recréation du container etc ?

Pour une de mes applications, je fais seulement deux commandes git pull et npm run docker-rebuild. La dernière commande est custom dans le fichier package.json :

{
  "scripts": {
    "docker-rebuild": "docker-compose -f deploy/docker-compose.yml up -d --build"
  }
}

Ensuite c’est docker-compose qui se charge de build les différents Dockerfile et/ou de monter directement les containers.

Sur d’autres projets avec une stack plus légère, j’ai fait la CI avec Netlify ; la branche master définit comme celle de production et il me suffit de merge depuis la branche dev.

Oulà, non.

Quand je veux faire une release : je pousse un nouveau tag sur ma branche master, disons 0.12.3.

Ma CI détecte qu’elle est en train de construire un tag, elle va s’occupper de construire et pousser l’image de mes conteneurs dans mon registry. En gros elle fait l’équivalent de :

docker build -t mon/app:0.12.3 -f images/monapp.Dockerfile .
docker push mon/app:0.12.3

Partant de là, je n’ai plus à me soucier du code, celui-ci est packagé dans ses conteneurs dans un registre. Ensuite, c’est là que ça va différer par rapport à toi, parce que j’utilise Kubernetes et son gestionnaire de paquets "standard de facto" (helm), et je déploie en faisant, depuis mon laptop :

helm upgrade monapp --set 'image.tag=0.12.3' helm/monapp

Et à ce moment-là, j’ai fini. C’est déployé.

Pour transposer ça à ton contexte, cette commande revient en très très gros à modifier le tag de l’image pour le positionner sur ma release (0.12.3) dans un docker-compose.yml (ou plutôt son équivalent Kubernetes), puis à faire docker-compose up -d ¹. Autrement dit, mon environnement de prod n’a absolument pas besoin de savoir comment sont construites mes images de conteneurs, ni même en quel langage c’est fait, il a juste besoin de les tirer sur dockerhub ou équivalent. Il n’y a pas de npm (ni de pip, ni quoi que ce soit d’équivalent) sur mes machines de prod.

Même sans utiliser Kubernetes, je pense que c’est important de faire cette distinction et de suivre un schéma similaire parce que c’est pour être utilisées comme ça qu’ont été pensées ces technos. Un déploiement, pour moi, ça consiste "bêtement" à faire un bump du tag de version des images de conteneur, et à le propager sur la prod qui va tirer les nouvelles images.

D’accord, je vois.

En fait, c’est parce que je n’utilise pas le Docker Hub de mon côté pour publier mon image.

Il me semble que c’est payant d’avoir des images privées, et j’ai peur que mon code source soit rendu publique.

Donc en fait, il faudrait que :

• Je build l’image depuis mon poste local
• Je push l’image sur le Docker Hub (en privé)
• Depuis mon serveur, je récupère l’image
• Je lance l’image dans un container

Actuellement ce que je fait, c’est :

• Je push mon code sur une branche sur GitHub
• Un Webhook se lance sur mon serveur
• Ça fait un git pull
• Puis un docker-compose up.

L’inconvénient avec ma méthode actuelle, c’est que je n’ai aucun log durant le déploiement.

Il me semble que c’est payant d’avoir des images privées, et j’ai peur que mon code source soit rendu publique.

Oui, les solutions gratuites favorisent les apps open-source. Pour faire du closed source tu devras utiliser un registry privé.

Je ne sais plus trop quelle est la politique de dockerhub, mais je sais que tu peux par exemple avoir un registry avec Gitlab, ou bien héberger ton propre registry aussi (c’est juste une image docker à tirer). C’est une problématique à part entière. Dans mon cas, au boulot, c’est GCP qui nous fournit un registre privé.

L’inconvénient avec ma méthode actuelle, c’est que je n’ai aucun log durant le déploiement.

Ça aussi c’est quelque chose qui devient très compliqué avec les conteneurs. Enfin, très compliqué pour les ops, parce que côté dev c’est au contraire simplifié : on logge sur stdout et stderr.

Côté ops, si t’es pas sur un cloud avec une solution d’aggrégation de logs intégrée, ça revient à mettre en place une solution comme la stack EFK (Elasticsearch, Fluentd, Kibana), ce qui peut vite devenir un joli foutoir. Ou bien te tourner vers un service externe qui va se charger de maintenir ça pour toi…

Ok, donc même si j’utilise Docker Hub pour publier mon image. Il me reste une dernière étape dont je ne trouve pas d’info sur internet.

J’ai mon Docker Compose qui contient mes deux Apps plus le Reverse Proxy.

A ce moment là, disons que je souhaite déployer l’application Vue : Je build l’image de mon application Vue (mais dans ce cas, je suppose que je me servirais jamais du Docker Compose hormis pour lancer mes container lors du développement), et je fait un push sur le Docker Hub. Ok.

Maintenant, sans utiliser Kubernetes, existe-t-il un moyen de lancer une commande (donc laquelle ?) pour faire en sorte que mon serveur récupère l’image et la lance ?

Donc voici mes questions sous forme de liste :

• Avec cette solution, je n’utilise pas de Docker Compose ?
• Comment faire pour que depuis mon poste local ça récupère l’image que je viens de push pour la lancer (sans Kubernetes) ?

Désolé de ces questions, mais je n’arrive pas à aller plus loin que ça.

D’après cette réponse stackoverflow (https://stackoverflow.com/questions/37685581/how-to-get-docker-compose-to-use-the-latest-image-from-repository), je dirais que le plus simple est de tout le temps tagger ton image avec latest.

Puis de faire :

docker-compose down
docker-compose pull
docker-compose up -d

Mon dieu que je suis perdu…

C’est beaucoup trop compliqué. Quand je développais avec PHP il a quelques temps, c’était plus simple : J’ouvre Filezilla, je met mes fichiers en ligne, hop c’est fait.

Là, Docker c’est très bien, mais c’est beaucoup trop compliqué.

Ce que je comprend pas, c’est pourquoi il n’y à pas le moindre tutoriel sur comment faire.

Je veux dire, moi je veux juste prendre mon mes container et les mettre sur mon serveur automatiquement.

Avant j’utilisais Dokku. Avec ça, c’est ultra simple : Je l’installe sur mon serveur, puis j’ajoute un repo git avec "git remote add dokku URL" puis je faisais un "git push dokku master" et hop, mon application se déploie et j’ai les logs du déploiement dans mon terminal.

J’aimerais faire ça sans Dokku (qui ne supporte pas le Load Balancing), et qu’est ce que c’est galère.

Je comprend rien du tout…

N’y à t-il donc aucun moyen de simplement push mon code sur une branche pour que ça déploie tout seul en me retournant les logs ? Même avec un Github Action ?

Edit : J’arrive à faire en sorte que lorsque je push mon code sur master, ça appel une URL de mon serveur qui va alors lancer un script Shell qui va récupérer le code et lancer le Docker Compose (je pourrais donc à la place récupérer l’image du Docker Hub et la lancer), mais je n’ai aucun retour sur ce qu’il se passe… d’autant plus que cette façon de faire me parraît trop manuelle à mettre en place. Docker n’a rien prévu sur le déploiement ? Il n’y à pas un truc plus simple à mettre en place ?

Il faut bien voir que ton projet ne justifie peut-être pas d’utiliser des conteneurs aussi.

Si ton application est monolithique (en gros, tu fais tourner un site unique), alors tu peux très bien t’en sortir sans, avec dokku, comme tu le mentionnes.

Ce qui va justifier d’utiliser des conteneurs, c’est quand ton application commence à avoir plein de petits composants distincts, pas seulement "le site, sa BDD, et le reverse proxy" : mais plutôt "mes 10 microservices de backend, le site qui sert les vues, une ou deux bases de données, un cache distribué, ma solution de logging, un prometheus pour le monitoring et un grafana pour mes dashboards".

Quand tu en arrives à ce niveau de complexité dans un projet, forcément tu commences à revoir ton workflow et notamment la façon dont il se déploie et si tu veux continuer à fonctionner en gitops ou en continuous delivery comme avec dokku, tu as des compromis à faire.

Dans toute cette problématique, Docker et docker-compose aujourd’hui sont un entre-deux un peu bâtard qui permettent de déployer des applis déjà packagées sur des VPS. Ça ne m’étonnerait pas qu’il existe des outils et des techniques pour bosser avec, mais ça reste un bricolage : perso, avant de troquer entièrement Docker contre podman, je n’utilisais docker-compose que sur mon laptop en local pendant le développement, justement parce que mon projet est éclaté en une dizaine de composants et que mon docker-compose.yaml était à ce moment le moyen le plus simple de garder la complexité sous contrôle.

Si je mentionne Kubernetes plus haut, c’est parce que tu semblais t’intéresser à ce qui se passe quand tu commences à vouloir faire tourner une prod conteneurisée, mais ce qu’il ne faut surtout pas perdre de vue, c’est que ce genre de techniques et d’architecture n’a d’intérêt que lorsque ton système a déjà un certain niveau de complexité, avec des problématiques de passage à l’échelle (soit de la charge de travail, soit de l’équipe qui développe et maintient le système, soit parce que tu veux faire tourner tes serveurs un peu partout dans le monde pour qu’ils restent proches des utilisateurs, soit les trois à la fois) ou de haute disponibilité. Dans ces conditions, ce n’est plus de docker-compose que tu as besoin, mais d’un véritable orchestrateur. Et quand tu fais une mise en prod, tu n’as pas juste un log à surveiller : ça va se passer sur une dashboard qui fait clignoter en rouge les composants qui pètent, avec l’orchestrateur qui te dit "oulà, j’ai démarré une nouvelle instance de X, mais il m’a pas donné de signe de bonne santé alors j’ai mis en pause le déploiement et c’est toujours la vieille version qui tourne, va y jeter un oeil".

Du coup, pour conclure ce gros pavé, je pense que la question la plus importante à te poser, c’est : qu’est-ce que tu cherches à faire, fonctionnellement ? Si c’est distribuer un site monolithique en plusieurs instances avec du load balancing en façade, tu peux le faire sans conteneuriser ton application avec une conf nginx, et c’est peut-être ça que tu as intérêt à faire.

En réalité, là j’ai pris l’exemple d’un truc simple : Une API et une application Vue.

Mais au travail, je suis en charge du déploiement des applications, qui comprennent plusieurs micro services, plusieurs bases de données et plusieurs frontend.

Je devrait mettre en place du Load Balancing car il y aura un nombre très important d’utilisateur de plusieurs pays différents.

Sauf que bon, j’ai réussi à mettre un truc en place qui tient bien la route pour les tests, mais j’ai très peur du moment au passage en prod.

Dans tout les cas, je pense que j’en parlerais pour dire que je ne suis pas capable de m’en occuper (à la base, je suis juste développeur ).

Par contre, je développais toujours avec PHP. Là, pour ce travail, je suis sur du JavaScript. Mais je n’ai jamais regardé comment déployer du JS.

Et même, un déploiement avec Docker m’intéresse, ne serais-ce que parce que je n’y arrive pas (et que quand j’arrive pas à faire quelque chose, ça m’énerve jusqu’à ce que j’y arrive : Et je suis têtu pour ça).

Donc j’aimerais vraiment savoir déployer un truc simple, juste pour que je sois tranquille dans mon esprit.

Après j’avoue que je n’ai jamais vraiment déployer quelque chose de plus compliqué que de simples fichiers PHP sur Filezilla.

Mais en vrai, je sais que c’est pas juste "mettre un truc sur un serveur". Il y à aussi toute la partie pour s’assurer que le site est toujours là, que tout se passe bien, de savoir si il y à eu des erreurs, avoir des alertes, des logs, des stats et tout ça. Et là aussi je n’ai aucune connaissance sur comment mettre en place tout ça.

Ce qui m’enerve le plus, c’est que je suis capable de développer une application web de A à Z, mais pas de la mettre en ligne… après je sais que mettre en place une application en production, c’est tout un métier.

Si ça peut te rassurer, je suis moi aussi un développeur à la base, et même pas dev web.

Ce qui fait que je m’occupe de tout ça à mon travail, c’est que je suis plus ou moins le seul à m’y intéresser. Mais là où j’ai de la chance, c’est que ma boîte étant toute petite, le CTO était chaud dès le départ pour adopter une offre Kubernetes managée dans le cloud, solution que ce que tu me décris semblerait largement justifier, ne serait-ce que parce que ça automatise une grande partie du travail tout en le rendant trivial sur plein d’aspects (le load balancing et le déploiement sans interruption de service y sont des non-problèmes, par exemple).

De mon point de vue, si tu commences à multiplier les zones, les pays et les services, et que tu t’attends à une charge très importante dès le départ, c’est là qu’il faut regarder. En tout cas je ne saurais pas comment faire autrement, alors qu’avec kubernetes ça ne me fait pas peur de gérer ça seul. Mais il faut savoir aussi que ça vient avec une courbe d’apprentissage, et que ça n’a plus grand chose à voir avec docker-compose. Je crois que c’est clairement une discussion à poser sur la table à ton boulot, à moins que vous n’ayez les moyens d’embaucher une équipe dédiée.

Le souci c’est qu’on est une très petite équipe (une dizaine de personne, mais seulement 4 devs). Et je suis le seul qui puisse m’occuper de tout ça… mais je n’en ai pas les compétences.

Ça ne me dérange pas d’apprendre, mais encore faut-il s’y retrouver et savoir quoi apprendre.

Entre Docker, Kubernetes, Swarm et autre, je n’y comprend pas grand chose… ça va être difficile le passage en prod.

Je vais me renseigner plus sur Kubernetes, mais est ce que tu peux m’expliquer rapidement à quoi ça consiste et comment ça peut m’aider ?

Je demande pas un cours mais juste une rapide explication de ce que c’est pour que je puisse orienter mes recherches.

En tout cas merci pour tes réponses !

Le souci c’est qu’on est une très petite équipe (une dizaine de personne, mais seulement 4 devs). Et je suis le seul qui puisse m’occuper de tout ça… mais je n’en ai pas les compétences.

Je suis dans un cas très similaire au tien. On est moins d’une quinzaine, on développe un MMORPG, et je suis tout seul pour m’occuper du développement backend et de l’infrastructure. Et il y a un peu plus un an et demi, je n’y connaissais absolument rien.

Je vais me renseigner plus sur Kubernetes, mais est ce que tu peux m’expliquer rapidement à quoi ça consiste et comment ça peut m’aider ?

C’est la plate-forme standard (c’est aussi libre et open-source…) pour faire tourner tes systèmes (conteneurisés) dans un cloud. Autrement dit, quel que soit ton fournisseur de cloud (GCP, AWS, Azure ou même RedHat avec OpenShift), ils ont tous une offre où ils managent un Kubernetes pour toi.

Concrètement, c’est une abstraction qui se situe entre tes charges de travail (tes conteneurs) d’un côté, et les machines sur lesquelles ils tournent de l’autre. Autrement dit, tu ne te ssh plus directement sur tes machines (tu peux toujours le faire, hein, mais t’as juste plus aucun intérêt à le faire), c’est lui qui va décider tout seul où faire tourner quoi en temps réel. Tu peux lui rajouter 50 machines préemptibles dans la tronche, ou bien il peut y en avoir 5 qui tombent en panne : il le détecte et se débrouille pour rééquilibrer.

Il te permet de décrire ton système sous forme d’une configuration : tu vas par exemple dire que tu veux un deployment, qui est constitué de 10 instances de tel conteneur, et devant ce deployment, tu vas coller un service qui va faire office de load balancer entre les 10 instances de ce conteneur. En gros, c’est comme si tu maintenais en permanence une configuration docker-compose qui décrit ton système de façon déclarative, logique et abstraite.

Ce qu’il fait pour toi, c’est ni plus ni moins "se démerder pour que ça tourne comme tu veux" : par exemple, si tu mets à jour un déploiement en lui disant que tu ne veux plus, disons, "monapp:1.12" mais "monapp:1.13", alors il va réconcilier la réalité avec ce que tu veux :

• il va démarrer une instance de "monapp:1.13" en tirant l’image depuis le registry,
• il va s’assurer que la nouvelle instance est en bonne santé (tu lui décris comment faire, souvent c’est en appelant une URL de ton conteneur, mais ça peut être en lançant une petite commande dans le conteneur directement, qui doit retourner sans code d’erreur),
• une fois qu’il est sûr que l’instance tourne, il va supprimer une vieille instance et lancer encore une nouvelle.
• etc. jusqu’à ce qu’il ait remplacé les 10 instances.

Autre exemple, tu as un nom de domaine pour ton site, et tu veux qu’il soit accessible en https : tu peux décrire une ressource abstraite qu’on appelle un ingress qui définit les routes de ton reverse-proxy ("le path /user est géré par le service qui s’appelle "users", etc.), et lui dire que ça correspond à www.tondomaine.com, et que tu veux que ça soit exposé en https, et il va se débrouiller pour réserver une IP publique auprès du fournisseur de cloud, démarrer un proxy (Nginx ou autre) avec la configuration qu’il aura généré tout seul, et générer pour toi le certificat SSL, le mettre à jour quand il est sur le point d’expirer, etc. tout ça en coulisse pour que ça "juste marche" : la seule chose que tu as à faire manuellement, c’est faire pointer ton nom de domaine sur l’IP publique qu’il t’a donné.

Bref, ce que ça fait pour toi c’est que ça rend tout ça automatique et facile, et presque entièrement indépendant du fournisseur de cloud qu’il y a derrière, et de l’échelle réelle de ton système. Que ton système soit scalé pour une charge de 10 visiteurs par jour (sur deux machines) ou 1 million (sur 500 machines réparties dans plusieurs datacenters), ça se gère exactement de la même façon, au même endroit, avec le même bout de configuration.

Tu gardes toujours tout le contrôle sur ce que tu veux : si tu veux surcharger un clé de config nginx de ton ingress, tu peux le faire en précisant ce que tu veux dans la conf de l’objet kubernetes, mais le plus souvent tu n’en as même pas besoin.

Je comprend mieux.

Je suis dans un cas très similaire au tien. On est moins d’une quinzaine, on développe un MMORPG, et je suis tout seul pour m’occuper du développement backend et de l’infrastructure. Et il y a un peu plus un an et demi, je n’y connaissais absolument rien.

Moi ça m’intéresse d’apprendre, mais c’est juste que je trouve la porte d’entrée difficile.

Actuellement, on à juste un serveur VPS chez OVH. Mais je crois (si j’ai bien compris) qu’on restera pas chez eux.

Par contre, les offres comme GCP, AWS et autre nous font pas mal peur, car on ne maîtrise pas les coût, et il me semble que les prix peuvent monter en flèche en un claquement de doigt (surtout quand on à un nombre d’utilisateur très important).

Ça peut effectivement arriver si tu configures un autoscaling un peu violent ou des lambdas, mais quand tu bosses avec GKE, par exemple, ta facture est parfaitement détaillée et tu peux déterminer où la dépense a été trop forte, et ainsi t’adapter pour maîtriser les choses. Par exemple, faire tourner tes services majoritairement sur des machines préemptibles pas chères, sachant que kubernetes se débrouille pour que ton service ne soit pas interrompu quand une machine disparait, le temps qu’elle soit remplacée par une nouvelle… Ou encore, dé-commissionner 90% de ton cluster pour ne les provisionner, à chaud, que pendant les heures de pointe.

Je saurais pas trop te conseiller sur la maîtrise des coûts parce que je suis moi-même en plein apprentissage là-dessus. Ce que je sais c’est que GCP, notamment, a une campagne de soutien aux startups, et que tu peux bénéficier de 100K$ de crédits cloud gratuits à dépenser en un an¹, ce qui te laisse une très grande marge de manœuvre pour apprendre à contrôler et optimiser ton cluster, justement pour maîtriser ta facture de cloud : si tu te plantes, c’est des crédits "gratuits" qui se retrouvent dépensés, et ça te laisse le temps de t’adapter. C’est ce genre de truc dont bénéficie ma boîte à l’heure actuelle, et ça peut s’accompagner de consulting pour qu’un expert audite ton archi et te conseille, sans débourser un rond.

Et même sans se diriger forcément vers GCP, il y a des tas de fournisseurs qui proposent du kubernetes en IaaS.