Quelle est la caractéristique la plus importante de toute application Web? Il y en a beaucoup, mais pour moi la haute disponibilité est le plus important. C'est ce que Docker Swarm nous aide à réaliser! Cela aide l'application à être hautement disponible.
Dans mon blog précédent , J'ai expliqué le fonctionnement de Docker Compose. Ce blog sur Docker Swarm est une continuation du premier et ici les avantages de l'utilisation de Docker Swarm pour la conteneurisation de toute application multi-conteneurs ont été expliqués.
Dans le cas de ce blog, ce n’est qu’une application Angular qui sera Docker Swarm’ed.
Remarque : La méthode pour conteneuriser l'application MEAN Stack est la même.
Alors, qu'est-ce que Docker Swarm?
Essaim de dockers est une technique pour créer et maintenir un groupe de Moteurs Docker . Les moteurs Docker peuvent être hébergés sur différents nœuds, et ces nœuds qui se trouvent dans des emplacements distants forment un Grappe lorsqu'il est connecté en mode Swarm.
Pourquoi utiliser Docker Swarm?
Pour des raisons déjà mentionnées! Atteindre la haute disponibilité sans aucun temps d'arrêt est une priorité pour chaque fournisseur de services là-bas. La haute disponibilité impressionnera-t-elle vos clients? Eh bien, ils ne seront pas impressionnés s’ils font face à des temps morts. C'est une évidence.
Autres avantages de Docker Swarm
Comme beaucoup d'autres services, Docker Swarm fait de l'auto l'équilibrage de charge pour nous. Par conséquent, les ingénieurs DevOps n'ont pas besoin d'acheminer les demandes de traitement vers d'autres nœuds en cas d'échec. Le gestionnaire du cluster effectuera automatiquement l'équilibrage de charge pour nous.
Accès décentralisé est un autre avantage. Qu'est-ce que cela veut dire? Cela signifie que tous les nœuds sont facilement accessibles depuis le gestionnaire. Le gestionnaire invitera également régulièrement les nœuds et gardera une trace de son état de santé / état pour faire face aux temps d'arrêt. Cependant, les nœuds ne peuvent pas accéder ou suivre les services exécutés dans d'autres nœuds / gestionnaires.
Vous pouvez vérifier le non. de conteneurs s'exécutant dans un nœud, Augmenter le non. de conteneurs ou réduction le non. en fonction de nos besoins, en exécutant simplement une seule commande.
Même après le déploiement d'une application, nous pouvons émettre mises à jour progressives et assurez-vous que l'IC (intégration continue) est réalisée. Les mises à jour progressives sont émises sur un nœud après l'autre, garantissant ainsi qu'il n'y a pas de temps d'arrêt et que la charge est répartie entre les autres nœuds du cluster.
Quoi ensuite? Pour faire l'évidence. Démarrez avec Docker Swarm si vous avez déjà travaillé sur Docker ou si votre organisation souhaite conteneuriser un service Web fiable.
Remarque : Les moteurs Docker sont installés sur des hôtes / serveurs indépendants ou sur plusieurs VM d'un hôte.
Premiers pas avec le mode Swarm
Docker Swarm est initié par le gestionnaire, ou permettez-moi de le dire ainsi, l'instance qui démarre le cluster Swarm devient le gestionnaire. La commande pour démarrer le cluster est:
$ docker swarm init --adresse-annonce-adresse-IP
Ici, l'indicateur «–advertise-addr» est utilisé pour se faire connaître auprès d'autres nœuds qui souhaitent rejoindre le cluster. L'adresse IP du gestionnaire doit être spécifiée avec l'indicateur. Voici l'exemple de capture d'écran.
Lorsque le cluster Swarm est lancé, un jeton est généré à l'extrémité du gestionnaire. Ce jeton doit être utilisé par d'autres nœuds pour rejoindre le cluster swarm.
Comment est-ce exactement? Copiez l'intégralité du jeton généré sur le moteur Docker du gestionnaire, collez-le sur le moteur Docker du nœud et exécutez-le. La partie en surbrillance de la capture d'écran ci-dessus est un jeton. Lorsque le jeton est exécuté sur un nœud de travail, il ressemblera à la capture d'écran ci-dessous.
Tout nœud qui rejoint le cluster peut être promu ultérieurement en tant que gestionnaire. Si vous souhaitez qu’un moteur de menu fixe se joigne en tant que gestionnaire, exécutez la commande ci-dessous à la fin du gestionnaire:
$ docker swarm join-token manager
Et à un moment ultérieur, si vous souhaitez que le jeton d'un nœud rejoigne le cluster, exécutez la commande ci-dessous:
que sont les beans en java
$ docker swarm join-token node
Continuez et exécutez le jeton sur chaque nœud souhaité pour rejoindre le cluster. Lorsque tout cela est fait, vous pouvez exécuter une commande de liste de nœuds docker pour vérifier combien de nœuds ont rejoint le cluster ainsi que leur état. La commande est:
$ docker node ls
La capture d'écran est ci-dessous:
Création d'une image Docker pour l'application angulaire
Si tout va bien, nous pouvons démarrer notre service Swarm, à condition que l'image Docker soit créée. L'image Docker peut être créée à partir du Dockerfile. Le Dockerfile utilisé pour créer les applications est ci-dessous:
FROM node: 6 RUN mkdir -p / usr / src / app WORKDIR / usr / src / app COPY package.json / usr / src / app RUN npm cache clean RUN npm install COPY. / usr / src / app EXPOSE 4200 CMD ['npm', 'start']
Le Dockerfile est utilisé pour exécuter un ensemble de commandes ensemble pour créer une image Docker personnalisée à partir d'une image de base. Comme vous pouvez le voir, l’image de base que j’ai utilisée est «Nœud: 6». NodeJS est l'image I de Docker Hub qui est balisée avec la version 6.
Je crée ensuite un nouveau répertoire Docker à l'intérieur du conteneur et en fait le répertoire de travail dans mon conteneur.
Je suis en train de copier le fichier ‘package.json’ de ma machine locale vers le répertoire de travail du conteneur. Je spécifie ensuite les commandes «RUN npm cache clean» et «RUN npm install». npm installer La commande télécharge la version des dépendances mentionnées dans le fichier package.json.
Je copie ensuite tous les codes de projet de la machine locale vers le conteneur, exposant le numéro de port 4200 pour accéder à l'application Angular sur le navigateur et enfin, je spécifie la commande npm start qui conteneurise l'application.
Maintenant, pour créer l'image Docker basée sur ce Dockerfile, exécutez la commande ci-dessous:
$ docker build -t image-angulaire.
Remarque: Les images Docker doivent être intégrées à tous les nœuds du cluster. Sans cela, les conteneurs ne peuvent pas être lancés dans d'autres moteurs Docker.
Démarrage du service Docker Swarm
Étant donné que notre image Docker est créée, nous pouvons faire pivoter un conteneur hors de cette image. Mais nous ferons quelque chose de mieux: créer un service Docker Swarm à partir de celui-ci. La commande pour créer un service swarm est:
$ docker service create --name 'Angular-App-Container' -p 4200: 4200 angular-image
Ici, l'indicateur «name» est utilisé pour donner un nom à mon service et l'indicateur «p» est utilisé pour exposer le port du conteneur au port hôte. Dans le fichier package.json, j'ai spécifié le port de conteneur sur lequel l'application Angular doit être hébergée. Et le 4200 de cette commande permet de mapper le port 4200 du conteneur sur le port 4200 de l’hôte. «Angular-image» est le nom de l’image que j’ai créée précédemment.
Rappelles toi : Lorsque nous créons un service, il peut être hébergé sur n'importe quel moteur Docker du cluster. Le gestionnaire de l'essaim décidera où il sera hébergé. Mais, quel que soit le nœud dans lequel elle est hébergée, l'application est accessible sur localhost: 4200 à partir de l'un des nœuds connectés dans le cluster.
Comment est-ce possible? Parce que Swarm expose en interne les numéros de port pour qu'ils soient accessibles par tous les autres nœuds du cluster. Cela signifie, port no. 4200 sur n'importe quel nœud / gestionnaire du cluster rendrait l'application Angular.
Maintenant quoi? Le conteneur est-il actif?
Vous pouvez vérifier si le service est en conteneur en exécutant la commande docker service list. Mais le déploiement du conteneur peut prendre une minute. Voici la commande:
$ docker service ls
Cette commande listera tous les services gérés par le cluster Swarm. Dans notre cas, il devrait afficher un conteneur actif. Regardez la capture d'écran ci-dessous pour référence.
Ici, 'REPLICAS = 1/1' indique qu'il existe un seul 'service' de ce conteneur, dans le cluster. Et «MODE = répliqué» indique que le service est répliqué sur tous les nœuds du cluster.
Maintenant, pour identifier sur quel nœud / gestionnaire, l'application est hébergée, nous pouvons exécuter la commande docker service ps command suivie du nom du conteneur. La commande est:
$ docker service ps Angular-App-Container
La capture d'écran pour le même est ci-dessous.
Cela mentionne des détails sur le nœud sur lequel l'application est hébergée ainsi que la commande utilisée pour démarrer avec le service.
La commande 'docker ps' éclaire les détails du conteneur actif. La commande est:
$ docker ps
Regardez la capture d'écran ci-dessous pour référence.
Mais, cette commande ne fonctionnera que sur le gestionnaire de cluster et le nœud où le service est réellement hébergé.
Pour vérifier le nombre de nœuds en cours d'exécution, exécutez la commande de liste de nœuds. La commande est:
$ docker node ls
Pour vérifier les conteneurs s'exécutant sur un hôte particulier, exécutez la commande node ps. La commande est:
$ docker node ps
Si vous vous en souvenez, j'ai mentionné précédemment que le service s'exécute actuellement en MODE répliqué. Cela signifie que le service est répliqué sur tous les nœuds des clusters. Pensez-vous qu'il existe une alternative?
Absolument! Il y a quelque chose qui s'appelle le MODE global. Dans ce mode, il existe un service de ce conteneur en cours d'exécution sur chaque / manager du cluster. N'oubliez pas d'arrêter le service / conteneur en cours avant de lancer un autre ensemble de conteneurs.
La commande pour cela est:
$ docker service rm Angular-App-Container
La commande pour faire tourner le conteneur en mode global est:
$ docker service create --name 'Angular-App-Container' -p 4200: 4200 --mode global angular-image
Cela créerait 3 services sur les 3 nœuds de notre cluster. Vous pouvez le vérifier en exécutant la commande docker service list. La capture d'écran de ceci est ci-dessous.
Lorsque la commande docker service ps est exécutée, vous verrez quelque chose comme ceci:
Comme vous pouvez le voir, il est dit que le mode est répliqué et que les répliques de ce conteneur sont 3. Maintenant vient la meilleure partie de ce blog.
Pour avoir 2 répliques des services en cours d'exécution entre les trois conteneurs, nous pouvons utiliser l'indicateur de répliques. Regardez la commande ci-dessous:
$ docker service create --name 'Angular-App-Container' -p 4200: 4200 --replicas = 2 angular-image
Vous remarquerez que ces 2 services sont équilibrés en charge entre les trois nœuds du cluster. Exécutez la commande de processus de service docker pour vérifier dans quels nœuds les conteneurs sont actifs. Regardez la capture d'écran ci-dessous pour référence. Les conteneurs sont actifs dans un nœud de gestionnaire et un nœud de travail.
À partir du nœud Worker, vous pouvez vérifier que le conteneur est en cours d’exécution en exécutant la commande «docker ps».
Docker Swarm pour une haute disponibilité
Maintenant, pour vérifier réellement qu'il existe une haute disponibilité dans notre cluster, nous devons expérimenter un scénario dans lequel l'un des nœuds tombe en panne et d'autres nœuds du cluster le compensent. Nous pouvons réaliser ce scénario en arrêtant manuellement le conteneur de l'un des nœuds à l'aide de cette commande:
$ docker stop Angular-App-Container
Exécutez la commande ci-dessus sur le nœud: Worker-1 où le conteneur est en cours d'exécution.Depuis le gestionnaire, exécutez la commande:
$ docker service ps Angular-App-Container
Vous remarquerez maintenant que le conteneur est maintenant en cours d'exécution dans le nœud: Worker-2 et Manager. Cependant, il a été arrêté à partir du nœud: Worker-1. La même chose est visible sur la capture d'écran ci-dessous.
C'est ainsi Haute disponibilité Docker est accompli. jeBien que le conteneur soit inactif dans Worker-1, l'application peut être rendue au numéro de port 4200 sur ce nœud worker. En effet, il est connecté en interne à d'autres nœuds du cluster et il est capable de rendre l'application dans le navigateur.
Haute disponibilité après l'extension des services
Que ce soit en mode répliqué ou en mode global, nous pouvons augmenter le nombre de services exécutés dans notre cluster. Et même après la mise à l'échelle, nous serons en mesure de conserver une haute disponibilité. Génial n'est-ce pas?
type de données sql pour la date
Mais revenons à notre propos, voyons à quel point il est facile d'augmenter le nombre de services dans notre cluster. En supposant que nous ayons 2 ou 3 réplicas dans notre cluster, augmentons l'échelle des services à 5 en exécutant simplement une seule commande. La commande est:
$ docker service scale Angular-App-Container = 5
La capture d'écran de ceci est ci-dessous.
En exécutant la commande docker service list, vous pouvez remarquer que le nombre de répliques est maintenant 5. Et en exécutant la commande docker service ps avec le nom du service, vous pouvez voir comment les 5 services sont équilibrés en charge et répartis sur les 3 nœuds . Les commandes sont:
$ service docker ls $ service docker ps Angular-App-Container
Et enfin, dans une configuration Docker Swarm, si vous ne voulez pas que votre manager participe aux procédures et le garde occupé pour ne gérer que les processus, nous pouvons alors empêcher le manager d'héberger une application. Parce que c’est ainsi que cela fonctionne dans le monde, n’est-ce pas? Les managers sont uniquement pour gérer les autres travailleurs. Quoi qu'il en soit, la commande pour faire cela est:
$ docker node update - disponibilité drain Manager-1
Vous pouvez vérifier si le gestionnaire participe maintenant au cluster en exécutant la commande docker node list et la commande docker service ps:
$ docker node ls $ service docker ps Angular-App-Container
Vous pouvez maintenant remarquer que les services de conteneur ont été divisés entre les nœuds Worker et que le nœud Manager a en fait été vidé de la conteneurisation de tout service. La capture d'écran est ci-dessous.
Donc, cela met fin à ce blog sur Docker Swarm. J'espère que ce blog a expliqué à quel point il est important d'implémenter le mode Swarm pour atteindre une haute disponibilité. Restez à l'écoute pour plus de blogs dans cette série de tutoriels Docker.
Vous pouvez également regarder la vidéo ci-dessous pour comprendre le fonctionnement de Docker Swarm. Tous les concepts expliqués ci-dessus ont été traités dans la vidéo.
Docker Swarm pour une haute disponibilité | Tutoriel Docker | Tutoriel DevOps
Maintenant que vous avez découvert Docker, consultez le par Edureka, une entreprise d'apprentissage en ligne de confiance avec un réseau de plus de 250 000 apprenants satisfaits répartis dans le monde entier. Ce cours de formation à la certification Edureka Docker aide les apprenants à acquérir une expertise dans la mise en œuvre de Docker et sa maîtrise.
Vous avez une question pour nous? Veuillez le mentionner dans la section commentaires et nous vous recontacterons.