Déployer ses applications Web sur un Cluster Docker Swarm

Vous avez plusieurs serveurs et vous souhaitez vous simplifier le travail de déploiement de vos services, et accessoirement la gestion d'un Load Balancer ? Alors Docker Swarm est fait pour vous et dans cet article nous allons non seulement voir comment mettre en place un Cluster avec Docker Swarm, mais aussi déconstruire certaines rumeurs à son propos.

Qu'est-ce que c'est un Cluster ?

Un Cluster est un groupement de plusieurs choses similaires. Cela peut être un regroupement d'oiseaux ou de mamifères. On parle aussi souvent de Cluster dans le milieu médical comme un Cluster de patient tous infectés par un même virus. C'est un terme assez générique finalement.

En informatique, on retrouve surtout ce terme pour désigner un regroupement d'appareils, souvent des ordinateurs, dont la puissance sera utilisée pour déployer des services, comme par exemple un site internet, une API HTTP, des services de gestion des identités, etc...

Pourquoi ais-je besoin d'un Cluster ?

La première raison évidente qui peut venir à l'esprit, c'est pour des questions de puissance.

Un serveur n'est ni plus ni moins qu'un ordinateur qui est maintenu par une entreprise qui en a la responsabilité. Elle s'occupe de la partie matérielle, c'est-à-dire remplacer une mémoire-vive défectueuse ou un disque dur endommagé, et de la partie réseau, c'est-à-dire faire communiquer l'ordinateur avec le réseau internet de manière cohérente et sécurisée.

Néanmoins, si l'on a de plus en plus d'utilisateurs qui arrivent sur notre site chaque jour, nous pourrions avoir envie d'augmenter la capacité à accueillir cette charge de travail sur notre serveur.

Nous pourrions donc demander à notre hébergeur d'augmenter sa capacité afin de satisfaire nos exigences et celles de nos clients.

La problématique qui se pose est qu'un ordinateur atteindra toujours une limite physique qui est celle du matériel : il ne sera plus possible de dépasser une certaine limite en terme de capacité de disque dur par exemple, ou de taille de mémoire-vive.

La solution serait donc d'utiliser la puissance de plusieurs ordinateurs à la fois, car depuis le début, nous ne parlions que d'un seul ordinateur. Et comme dans la théorie, nous pourrions avoir une infinité d'ordinateur possibles, il serait évident que cette solution soit la plus adaptée pour accueillir plus de charge utilisateur une fois la limite matériel atteinte.

En réalité, avant de pouvoir faire cela, la limite financière de certaines entreprises sera atteinte bien avant, mais cela reste un autre problème que nous aborderons dans la partie comparaison entre Kubernetes et Docker Swarm.

Une autre raison qui nous pousserait à vouloir déployer nos applications sur un Cluster est de pouvoir déployer des applications Web sans que les utilisateurs ne soient impactés par une mise à jour, ou bien un serveur qui ne serait plus disponible.

On parle alors de haute disponibilité, et cela est pratique si notre application a une mission qui est critique, comme par exemple un serveur de communication instantannée, où il n'est pas question pour les utilisateurs de se voir déconnecté de leur chat lors d'une mise-à-jour ou si le serveur est complètement endommagé, au risque d'impacter grandement l'expérience utilisateur.

Pour cela, il est alors bien pratique de pouvoir commencer à déployer sa mise-à-jour sur un premier serveur, puis un second, puis un troisième, mais pas tous en même temps, afin de conserver au moins une application active pendant qu'un serveur se met à jour.

Cependant, il existe plusieurs problématique à l'utilisation de plusieurs serveurs.

Il faut par exemple, s'assurer que notre application Web soit la même sur chaque serveur, car si un client essaie d'accéder à un serveur en Australie, qui n'a pas la même version qu'un serveur en France, il risque d'y avoir des incohérence, bien que cela puisse faire du sens dans certaines situation, notamment dans les jeux-vidéos qui vont souvent déployer des mises-à-jour différentes en fonction des saison, des coûtumes de chaque pays, des événements, etc...

Il y a également des problématiques liées au réseau et à l'infrastructure : comment s'assurer que lors d'une mise-à-jour, nos clients puissent toujours accéder à leur application ? Comment réparatir la charge de travail et selon quelle stratégie ? Devons-nous utiliser un Load Balancer ? Si oui lequel et comment ? Quelles règles de routages entre les différentes requêtes de nos utilisateurs ?

Comme vous pouvez le constater, cette solution soulève aussi plusieurs problématiques, bien que l'idée soit très intéressante une fois passé un certain cap dans notre développement.

Comment Docker Swarm répond à ces problématiques ?

Afin de pouvoir répondre aux questions précédentes, il existe une solution toute adaptée qui consiste à initialiser un Cluster Swarm sur un regroupement de serveurs, et de déployer notre application sous la forme d'un service.

Docker Swarm permet donc non seulement de répondre à une problématique d'infrastructure, qui est celle de la mise en relation de plusieurs serveurs dans un but commun, mais aussi une problématique de déploiement d'application, puisqu'il est possible de déployer des applications sans délai, sur plusieurs serveurs, avec la possibilité de revenir en arrière, en conservant une haute disponibilité, et en garantissant une répartition équitable de la charge de travail entre plusieurs serveurs.

Comment Docker Swarn se compare à Kubernetes ?

Kubernetes est une solution permettant également de pouvoir Clusteriser une application sur différents serveurs, et qui conserve les mêmes avantages que Docker Swarm.

Il existe cependant quelques différences.

La première est que Docker Swarm n'est pas une technologie très populaire, bien qu'elle est capable de faire quasiment autant de chose (plus à propos de cela plus bas) que Kubernetes, et est toujours une solution viable aujourd'hui.

Néanmoins, du fait de sa forte popularité, Kubernetes bénéficie d'un support de première classe au sein de différents hébergeurs comme Google Cloud, Amazon AWS ou encore Azure, et il est possible de déployer ses applications Web sur un Cluster de serveurs sans avoir à gérer la partie infrastructure.

Au contraire, Docker Swarm, du simple fait de son faible taux d'adoption, nécessitera un peu plus d'effort de la part d'un développeur afin de pouvoir déployer ses applications sur un Cluster de serveur puisqu'il sera nécessaire de gérer la partie infrastructure, c'est-à-dire à minima, ses serveurs.

Ce qui comprends la maintenance de ces derniers : effectuer les correctifs de sécurité, passer sur les versions supérieurs des systèmes d'exploitation régulièrement, faire les mise-à-jour logicielles, etc...

Et c'est en réalité un très gros point fort de Kubernetes puisqu'il s'adresse tout particulièrement aux développeurs qui souhaite tirer parti de cet avantage, tout en conservant leur rôle de développeur, ou à très petite echelle celui d'un DevOps.

Néanmoins, le coût de l'hébergement de ses applications sur un Cluster Kubernetes peut aller du double au triple, comparé à une offre avec plusieurs serveurs privées virtuels par exemple mis en communs à l'aide d'un cluster Docker Swarm.

Également, une chose qui manque à l'arsenal d'outils fournis par Docker Swarm est le fait de pouvoir faire de l'auto-scaling, c'est-à-dire de pouvoir automatiquement ajuster la charge de travail en fonction du traffic, chose qu'il est possible de faire avec Kubernetes.

Néamoins, cela s'adresse à des applications à très fort traffic, comme c'est le cas pour Discord par exemple. Il y a de fortes chances que les applications que vous développez pour vos clients ne nécessite pas une telle fonctionnalité, c'est donc un inconvénient que si vous vous positionnez d'un certain point de vue.

Un autre avantage à Docker Swarm est qu'il dispose automatiquement, une fois que tous les serveurs ont rejoint le Cluster, d'un mode réseau Mesh. Cela consiste, une fois un service déployé, comme une application Web par exemple, d'être disponible en accédant à l'adresse IP (ou au nom de domaine) de n'importe lequel de ces serveurs, même si ce serveur n'est pas responsable d'accueillir la tâche de lancer un conteneur pour cette application Web ! Et cela simplifie grandement le travail de création d'un Load Balancer, avec des règles de routage particulières.

Enfin, un des atouts majeurs de Kubernetes est sa grande communauté, et ses opérateurs, qui permet de packager et de déployer un ensemble de ressources Kubernetes et de les proposer à plusieurs utilisateurs afin de réduire considérablement la charge de travail nécessaire pour déployer de telle applications.

Mais nous verrons que créer un Cluster Docker Swarm est si simple dans sa syntaxe, qu'il n'est quasiment pas nécessaire d'avoir ce genre d'outils dans l'ecosystème Docker.

Mais on m'a dit que Docker Swarm est mort, pourquoi devrais-je continuer à l'utiliser ?

Non, Docker Swarm n'est pas mort. C'est d'ailleurs la première idée de titre d'article que j'avais à l'origine, mais je me suis rabattu sur celui que vous avez aujourd'hui.

Effectivement, le projet Docker Swarm est mort. Et un nouveau projet a vu le jour et qui s'intitule : Docker Swarm. Non ce n'est pas une faute de recopie, les ingénieurs de chez Docker on une créativité débordante !

En réalité, il existait bien un projet qui s'intitulait Docker Swarm et qui était intégré à la suite d'outils Docker, tout comme Docker Compose par exemple.

Néanmoins, cet outil comportait de nombreux inconvénient par rapport à Kubernetes, et il est aujourd'hui déprécié, c'est ce que vous pouvez voir sur la page d'accueil du dépôt GitHub de ce dernier.

Mais, si on observe bien, on peut y lire justement une petite ligne qui dit ceci.

Swarm Classic: a container clustering system. Not to be confused with Docker Swarm which is at https://github.com/docker/swarmkit

L'imaginaire étant tellement développé chez Docker, ils ont été contraint de renommer le projet Docker Swarm en Swarm Classic.

Et comme vous avez pu le constater, il n'est plus du tout maintenu, bien que son archive existe toujours à des fins historiques.

Mais aucune crainte, puisque l'équipe Docker travaille toujours sur ce projet, qui s'intitule Swarmkit.

Vous avez pu remarquer que c'est l'organisation Moby qui détient ce dépôt. Moby est une organisation créée par Docker afin de pouvoir développer des outils, qui sont plus tard intégrés dans l'écosystème Docker sous la forme de plugins, certains optionnels, d'autres inclus directement lors de l'installation de Docker.

Avec un peu de recherche, on constate donc que Docker Swarm existe toujours, sous un autre nom, certes, mais le projet est loin d'être mort et fait toujours partie de Docker.

Il est donc tout à fait possible de continuer aujourd'hui à déployer ses Cluster avec Docker Swarm, même en à l'heure où j'écris ces lignes, et c'est même plutôt simple comme nous le verrons juste après.

Comment créer mon premier Cluster ?

SI vous avez l'habitude d'utiliser Docker, vous n'aurez aucune difficulté à utiliser Docker Swarm puisque vous avez déjà cet outil installé sur votre ordinateur.

À noter qu'il est aussi tout à fait possible d'utiliser swarmctl en ligne de commande afin de pouvoir utiliser Swarmkit sans directement utiliser la ligne de commande Docker, bien que ce dernier soit intégré à Docker.

Si vous souhaitez transformer votre environnement local en Cluster Swarm, parce que oui, bien que sans intérêt, nous pouvons tout à fait avoir un Cluster composé d'un seul ordinateur, il vous suffit de taper la commande suivante.

docker swarm init --advertise-addr 127.0.0.1

Une fois la commande exécutée dans votre terminal, vous devriez avoir quelque chose qui ressemble à ceci.

Swarm initialized: current node (mfm13tane2frtagln04phwjg3) is now a manager.

To add a worker to this swarm, run the following command:

    docker swarm join --token SWMTKN-1-2z4kka6s13rb9gijrhfz26m253ifc84g126vqxqtpabpp0gdza-28qyitp24k5uxxegsh246mgra 127.0.0.1:2377

To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.

C'est tout ! Vous avez désormais créé votre premier Cluster, et pour 0€. Pas mal non ?

Bien qu'il n'y ait, encore une fois, qu'un seul nœud (ordinateur) dans ce Cluster, nous pouvons quand même lister tous les nœuds qui sont attachés au Cluster à l'aide de la commande suivante.

docker node ls

Vous devriez avoir quelque chose de similaire à ce que j'ai.

ID                            HOSTNAME    STATUS    AVAILABILITY   MANAGER STATUS   ENGINE VERSION
mfm13tane2frtagln04phwjg3 *   archlinux   Ready     Active         Leader           26.1.3

Nous avons ici les noms d'hôtes, les statuts (s'ils sont prêts à recevoir des commandes) leur disponibilité (s'ils sont disponibles pour travailler, s'ils sont en mode maintenance, etc...) et s'ils sont responsable du Cluster ou non.

Il existe deux types de nœuds sur un Cluster Docker Swarm, similaire à un Cluster Kubernetes.

Un nœud dit manager, qui est en fait responsable du Cluster. Nous pouvons avoir plusieurs nœuds manager, est c'est d'ailleurs recommandé afin de s'assurer qu'il y ait toujours un serveur qui est capable de donner des ordres.

Comme je viens de le dire, un manager donne des ordres. Ces ordres peuvent être par exemple de déployer un service, de faire monter en charge un service, de supprimer un service, de changer la disponibilité d'un nœud, etc...

De l'autre côté nous retrouvons des nœuds travailleurs, ou worker dans le jargon Docker Swarm. Ces worker vont être disponible pour travailler tout simplement. Ce sont eux qui seront responsables de créer les conteneurs nécessaires en fonction de la charge de travail demandée, et de répondre aux requêtes des clients.

À noter que par défaut, un manager participe aussi aux travaux du Cluster, donc il est aussi capable de pouvoir travailler, tout comme un worker. Si cela n'est pas nécessaire, car il y a déjà assez de nœud worker par exemple, il est tout à fait possible d'exécuter la commande suivante (ne la lancez pas, c'est pour l'exemple).

docker node update --availability drain archlinux

Si vous faites cela, dans ce contexte, plus aucun service ne pourra se lancer, c'est évidemment ce que nous ne souhaitons pas faire, mais cela peut être intéressant de rendre un nœud indisponible, par exemple si nous avons besoin de faire une mise à jour du système d'exploitation, opération qui peut s'avérer assez coûteuse en temps de CPU et de mémoire-vive.

Tout ça est très bien, mais nous n'avons pas vu encore comment déployer un service, c'est ce que nous allons faire maintenant.

docker service create --name nginx --publish 8000:80 nginx:latest

Aussi simple que cela, pas besoin de définir un long et pénible fichier YAML pour pouvoir déployer un service, tout peut se faire avec la ligne de commande, et nous verrons que nous pouvons également utiliser la syntaxe avec laquelle nous sommes déjà familiers afin de pouvoir faire quelque chose de similaire.

Comme vous vous en doutez, nous avons déployé un service NGINX, qui s'expose sur le port 8000 afin de pouvoir accéder à la page d'accueil de NGINX.

Attention à bien accéder à http://127.0.0.1:8000 et non pas http://localhost:8000 ! L'option --advertise-addr ici est très importante car elle devient la seule URL qui permettra d'accéder à nos conteneurs depuis l'extérieur du réseau Mesh Swarm.

Nous pouvons bien entendu avoir des informations sur ce service, comme par exemple s'il a bien été lancé avec la commande suivante.

docker service ls

Nous devrions obtenir quelque chose qui ressemble à ceci.

ID             NAME      MODE         REPLICAS   IMAGE          PORTS
6yyxlybhq897   nginx     replicated   1/1        nginx:latest   *:8000->80/tcp

Cela nous permet de nous assurer que le service a bien été démarré, et que les requêtes vers le port 8000 sont bien redirigées sur le port 80 du conteneur.

Assurons-nous également de savoir si le serveur NGINX en lui-même écoute sur le port 80 en lançant la commande suivante.

docker service logs nginx

Ça ne vous rappelle rien ?

docker logs nginx

Oui, c'est exactement la même commande que vous connaissez déjà, elle est simplement appliquée à notre Cluster avec le préfix service.

Nous devrions voir ceci dans notre terminal.

[...]
nginx.1.6i82ptholra5@archlinux    | /docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
nginx.1.6i82ptholra5@archlinux    | /docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
nginx.1.6i82ptholra5@archlinux    | /docker-entrypoint.sh: Configuration complete; ready for start up
[...]
nginx.1.6i82ptholra5@archlinux    | 2024/06/03 19:35:13 [notice] 1#1: start worker process 42
nginx.1.6i82ptholra5@archlinux    | 2024/06/03 19:35:13 [notice] 1#1: start worker process 43
nginx.1.6i82ptholra5@archlinux    | 2024/06/03 19:35:13 [notice] 1#1: start worker process 44

Bon, TL;DR, ça a bien fonctionné. Si par ailleurs nous avons des soucis avec ce conteneur, nous pourrons toujours utiliser cette commande pour en savoir plus.

Essayons maintenant de répliquer notre application.

Quel est l'intérêt de lancer plusieurs instances de NGINX à la fois, vous pourriez vous demander ?

L'idée est la suivante : si jamais j'ai besoin d'effectuer une tâche de mise-à-jour de NGINX, par exemple passer sur la version supérieur, je n'aurais pas besoin de stopper le conteneur, de récupérer la dernière version depuis le dépôt Docker Hub, et de relancer le conteneur.

Tout peut se faire sans que les clients n'ait besoin d'avoir de temps d'arrêt de l'application en répliquant notre application autant de fois que l'on souhaite, et nous pourrions par exemple indiquer à notre Cluster que nous souhaitons qu'il y ait à chaque fois 2 conteneurs par 2 conteneurs qui se mettent à jour en simultannée, sur une 10aine de conteneurs par exemple.

Essayons de créer pour l'exercice 5 conteneurs pour commencer. Pour cela rien de plus simple, il suffit de taper la commande suivante.

docker service scale nginx=5

Et nous devrions avoir une sortie dans notre terminal qui ressemble à ceci.

nginx scaled to 5
overall progress: 5 out of 5 tasks 
1/5: running   [==================================================>] 
2/5: running   [==================================================>] 
3/5: running   [==================================================>] 
4/5: running   [==================================================>] 
5/5: running   [==================================================>] 
verify: Service nginx converged

C'est tout, aussi simple que ça.

Désormais, nous pouvons voir le résultat de notre commande en tapant la commande qui suit.

docker service ls

Cette commande nous donne la liste entière de tous les services que nous pourrons créer. On a un apperçu rapide du nombre de réplicas actuellement affectés à ce service.

ID             NAME      MODE         REPLICAS   IMAGE          PORTS
6yyxlybhq897   nginx     replicated   5/5        nginx:latest   *:8000->80/tcp

Mais nous pouvons aller plus loin, surtout si nous avons un Cluster composé de plusieurs serveurs. Nous pouvons taper la commande suivante afin de savoir qui est responsable du travail de lancer NGINX.

docker service ps nginx

Cette commande devrait nous ressortir l'ensemble des serveurs qui travaillent sur cette tâche.

ID             NAME      IMAGE          NODE        DESIRED STATE   CURRENT STATE            ERROR     PORTS
6i82ptholra5   nginx.1   nginx:latest   archlinux   Running         Running 10 minutes ago             
uor41ay38ehc   nginx.2   nginx:latest   archlinux   Running         Running 2 minutes ago              
vlfpn27whrp4   nginx.3   nginx:latest   archlinux   Running         Running 2 minutes ago              
oy3h9o6zpl0k   nginx.4   nginx:latest   archlinux   Running         Running 2 minutes ago              
iyi2323yf90v   nginx.5   nginx:latest   archlinux   Running         Running 2 minutes ago

En réalité, la sortie n'est pas une surprise, et on peut voir que sur la colonne node, il n'y a que archlinux (mon ordinateur) qui est responsable de cette tâche.

Si vous essayez de créer un Cluster avec plusieurs ordinateurs, vous pourrez probablement vous appercevoir que différents serveurs se sont répartis le travail.

Il existe des règles de répartition du travail bien précises qui sont par défaut affectées à un Cluster Docker Swarm, mais nous pouvons aller plus loin et définir nos propres règles, comme par exemple un service Windows qui ne doit tourner que sur des nœuds dont le système d'exploitation est Windows, ou un service d'intelligence artificielle qui ne doit tourner que si le nœud est doté d'un GPU Nvidia avec la librairie CUDA. Les possibilités sont très grandes ici.

Enfin, si l'on souhaite supprimer un service, il suffit de lancer la commande suivante.

docker service rm nginx

Et si vous êtes assez rapide et que vous tapez la commande docker node ps, vous devriez voir que le service en question est dans un état de suppression.

Il est d'ailleurs tout à fait possible, après avoir augmenté la réplication de notre service, de pouvoir le mettre à jour comme discuté plus haut.

Si NGINX se met à jour sur une version, disons 1.2.3, il nous suffira de lancer la commande suivante.

docker service update --image nginx:1.2.3 --update-parallelism 2 nginx

C'est tout ce qu'il faut pour mettre à jour NGINX, en gardant toujours 3 conteneurs sur 5 avec l'ancienne version (toujours disponible pour nos clients) et en mettant à jour NGINX 2 conteneurs par 2 conteneurs à la fois.

Cela permettra de conserver une haute disponibilité de notre service, très pratique si nous ne souhaitons pas afficher de page de maintenance par exemple ou si nous ne pouvons pas nous permettre de stopper le service momentanément.

Docker Compose & Docker Swarm

Un des inconvénients majeurs à l'utilisation de Kubernetes, spécialement pour des personnes qui ne travaillent pas directement dans le service Réseaux & Infrastructures, et qu'il est composé d'un très grand nombre, voir trop grand nombre, de composants, de services et d'opérateurs, qui rend le travail de Clusterisation d'une application par un développeur très difficile puisqu'il faut tout réapprendre et Docker Compose ne s'interface pas automatiquement avec Kubernetes, bien qu'il est aujourd'hui possible d'utiliser un plugin officiel Docker afin de créer tous les fichiers de configuration YAML nécessaires à la traduction d'une infrastructure sur Docker Compose en Kubernetes.

Néanmoins, ce que l'on peut faire en plusieurs fichiers et plusieurs lignes sur Kubernetes, nous pouvons le faire en très peu de lignes, et sans changer beaucoup de choses à ce que l'on connait déjà.

Reprenons notre exemple, c'est-à-dire le déploiement d'un conteneur NGINX, mais cette fois-ci, faisons-le avec un fichier Docker Compose.

services:
  nginx:
    image: nginx:latest
    ports:
      - 8000:80
    deploy:
      replicas: 5

Non, je ne me suis pas trompé, c'est literallement ce que nous avons fait tout à l'heure. Plutôt court, n'est-ce pas ?

Le plus gros avantage à Docker Swarm est que la barrière cognitive à l'apprentissage de Docker Swarm est très limité pour quelqu'un qui connait déjà les fondamentaux de Docker, et il n'y a finalement que très peu de briques à rajouter en plus, comme cette nouvelle propriété deploy qui permet de gérer ce service dans un Cluster Swarm.

Si nous souhaitons déployer tout cela dans un Cluster Docker Swarm, il faudra changer légèrement notre commande de toute à l'heure.

docker stack deploy -c compose.yml nginx-stack

Ici nous pouvons voir que c'est la commande stack qui nous permet de déployer un fichier compose.yaml, nous avons également donné un nom à notre stack car il est tout à fait possible de déployer plusieurs stacks, pour plusieurs projets par exemple, intéressant si nous souhaitons mutualiser notre Cluster de serveur et le rentabiliser au maximum avec des projets de plusieurs clients à la fois !

Les mêmes commandes nous permettent d'administrer le Cluster. Nous pouvons de nouveau nous assurer que notre service NGINX s'est bien déployé avec les bons réplicas avec la commande suivante.

docker service ls
ID             NAME                MODE         REPLICAS   IMAGE          PORTS
x54ewdwa3hqn   nginx-stack_nginx   replicated   5/5        nginx:latest   *:8000->80/tcp

Rien ne change à partir de là, c'est vraiment très classique. Et c'est ce qu'on veut ! Ne pas avoir à réapprendre tout une syntaxe particulière au déploiement de nos application sur un Cluster, comme c'est le cas pour Kubernetes.

Pour comparaison, sur Kubernetes, nous aurions été obligé de commencer par créer un fichier de déploiement.

# deployment.yml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 5
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

Puis un fichier de service.

# service.yml
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 8000
      targetPort: 80
  type: NodePort

Pour enfin pouvoir lancer les commandes suivantes.

kubectl apply -f deployment.yml
kubectl apply -f service.yml

On voit bien ici que pour arriver au même résultat, le développeur a la nécessité de maîtriser bien plus de choses, pour un résultat similaire, et un coût bien plus élevé. Sans compter le fait qu'il faille installer kubectl sur son ordinateur qui n'est pas inclu par défaut avec docker.

En parlant de coût, si vous souhaitez par exemple déployer un Managed Kubernetes Cluster avec Google Cloud, c'est-à-dire de ne pas vous embêter avec la partie infrastructure, il est nécessaire de débourser la coquette de somme de 80€ par mois, pour des serveurs relativement modestes, quand l'équivalent chez Digital Ocean vous aurait coûté que 20€ par mois. Ce qui fait plus d'argent pour payer des sauvegardes, des volumes supplémentaires voir des serveurs bien plus puissants qu'avec Google Cloud par exemple.

Dois-je migrer tous mes Cluster Kubernetes vers Docker Swarm ?

Non, et ce post n'est pas une incitation à la haîne pour Kubernetes non plus.

Ces deux technologies sont très intéressantes, toutes les unes que les autres, et il n'existe d'ailleurs pas que Docker Swarm et Kubernetes dans ce marché, vous pouvez par exemple utiliser OpenShift, qui est un framework par dessus Kubernetes et qui vous permet également de déployer des applications dans un Cluster de la même façon.

Cet article est surtout ici pour démystifier toutes les idées préconçues et apporter plus de visibilité à ce projet qui mérite clairement le détour.

Si vous souhaitez en savoir plus, je ne peux vous recommander que la documentation officielle Docker Swarm qui est très riche en information et saura vous guider dans vos projets futurs.

J'espère que ce post vous aura aidé à y voir un peu plus clair, et que vous êtes désormais capable de déployer vos applications dans un Cluster de serveurs !