Quina és la característica més important de qualsevol aplicació basada en web? N’hi ha molts, però per a mi alta disponibilitat és el més important. Això és el que ens ajuda Docker Swarm. Ajuda a que l'aplicació estigui molt disponible.
En el meu bloc anterior , Vaig explicar com funciona Docker Compose. Aquest bloc de Docker Swarm és una continuació del primer i aquí s’han explicat els avantatges d’utilitzar Docker Swarm per contenir qualsevol aplicació de diversos contenidors.
En el cas d’aquest bloc, només es tracta d’una aplicació Angular que serà Docker Swarm’ed.
Nota : El mètode per contenir l’aplicació MEAN Stack és el mateix.
Llavors, què és Docker Swarm?
Esquadró Docker és una tècnica per crear i mantenir un clúster de Motors Docker . Els motors Docker es poden allotjar en diferents nodes, i aquests nodes que es troben en ubicacions remotes formen un Clúster quan es connecta en mode Swarm.
Per què utilitzar Docker Swarm?
Per les raons esmentades ja! Aconseguir alta disponibilitat sense cap temps d'inactivitat és una prioritat per a tots els proveïdors de serveis que hi hagi. La gran disponibilitat impressionarà els vostres clients? Bé, no s’impressionaran si s’enfronten als temps d’aturada. Això és una obvietat.
Altres avantatges de Docker Swarm
Com molts altres serveis, Docker Swarm és automàtic equilibri de càrrega Per a nosaltres. Per tant, no és necessari que els enginyers de DevOps encaminin les sol·licituds de processament a altres nodes quan un falla. El gestor del clúster realitzarà automàticament un equilibri de càrrega.
Accés descentralitzat és un altre benefici. Què vol dir això? Significa que es pot accedir fàcilment a tots els nodes des del gestor. El gestor també demanarà als nodes regularment i farà un seguiment del seu estat / estat per fer front al temps d'inactivitat. Tot i això, els nodes no poden accedir ni fer un seguiment dels serveis que s’executen en altres nodes / gestors.
Podeu consultar el núm. de contenidors que s’executen en un node, augmentar proporcionalment el núm. de contenidors o reduir el núm. basat en el nostre requisit, només executant una sola ordre.
Fins i tot després de desplegar una aplicació, podem emetre-la actualitzacions continuades i assegureu-vos que s’aconsegueix CI (Integració contínua). Les actualitzacions continuades s’emeten a un node rere l’altre, de manera que s’assegura que no hi ha temps d’inactivitat i que la càrrega es distribueix entre altres nodes del clúster.
Què passa després? Per fer el que és obvi. Comenceu a utilitzar Docker Swarm si ja heu treballat a Docker o si la vostra organització vol contenir un servei web fiable.
Nota : Els motors Docker s’instal·len en servidors o servidors independents o en diverses màquines virtuals d’un host.
Introducció al mode Swarm
Docker Swarm és iniciat pel gestor, o permeteu-me dir-ho així, la instància que inicia el clúster Swarm es converteix en el gestor. L'ordre per iniciar el clúster és:
diferència entre final i final a java
$ docker swarm init --advertise-addr adreça IP
Aquí, el senyalador ‘–advertise-addr’ s’utilitza per anunciar-se a altres nodes que vulguin unir-se al clúster. Cal especificar l'adreça IP del gestor juntament amb el senyalador. A continuació es mostra la captura de pantalla de mostra.
Quan s’inicia el clúster Swarm, es genera un testimoni al final del gestor. Aquest testimoni ha de ser utilitzat per altres nodes per unir-se al clúster d'eixam.
Com és exactament? Copieu tot el testimoni generat al motor de connexió del gestor, enganxeu-lo al motor de connexió del node i executeu-lo. La part ressaltada de la captura de pantalla anterior és un testimoni. Quan el testimoni s’executa en un node de treballador, semblarà la captura de pantalla següent.
Qualsevol node que s’uneixi al clúster es pot promocionar posteriorment a gestor. En cas que vulgueu que s'uneixi un motor docker com a gestor, executeu l'ordre següent al final del gestor:
$ docker swarm join-token manager
I en un moment posterior, si voleu que el testimoni d’un node s’uneixi al clúster, executeu l’ordre següent:
$ nocker swarm join-token node
Seguiu endavant i executeu el testimoni a cada node que vulgueu per unir-vos al clúster. Quan tot això estigui fet, podeu executar una ordre de llista de nodes d'acoblament per comprovar quants nodes s'han unit al clúster juntament amb el seu estat. L'ordre és:
$ docker node ls
La captura de pantalla es mostra a continuació:
Creació d’una imatge Docker per a una aplicació angular
Si tot està bé, podem iniciar el nostre servei Swarm, sempre que es construeixi la Docker Image. La imatge Docker es pot crear des del fitxer Docker. A continuació es mostra el fitxer Docker utilitzat per crear les aplicacions:
FROM node: 6 RUN mkdir -p / usr / src / app WORKDIR / usr / src / app COPY package.json / usr / src / app RUN npm caché net RUN npm instal·la COPY. / usr / src / app EXPOSE 4200 CMD ['npm', 'start']
El fitxer Dockerfile s'utilitza per executar un conjunt d'ordres junts per crear una imatge Docker personalitzada a partir d'una imatge base. Com podeu veure, la imatge base que he fet servir és 'Node: 6'. NodeJS és la imatge I de Docker Hub que està etiquetada amb la versió 6.
Llavors estic creant un directori Docker nou dins del contenidor i el converteixo en el directori de treball dins del contenidor.
Copio el fitxer ‘package.json’ del meu equip local al directori de treball del contenidor. A continuació, especificaré les ordres 'RUN npm cache clean' i 'RUN npm install'. Instal·lació de npm L'ordre descarrega la versió de les dependències esmentades al fitxer package.json.
A continuació, copio tots els codis del projecte de la màquina local al contenidor, exposant el número de port 4200 per accedir a l’aplicació Angular al navegador i, finalment, especifico l’ordre npm start que conté l’aplicació.
Ara, per crear la imatge Docker basada en aquest fitxer Docker, executeu l'ordre següent:
$ docker build -t angular-image.
Nota: Les imatges Docker s'han de construir a tots els nodes del clúster. Sense ella, els contenidors no es poden filar en altres motors Docker.
S’inicia el servei Docker Swarm
Tenint en compte que la nostra imatge Docker està construïda, podem fer girar un contenidor fora d’aquesta imatge. Però farem alguna cosa millor: crear-ne un servei Docker Swarm. L’ordre per crear un servei d’eixam és:
$ docker service create --name 'Angular-App-Container' -p 4200: 4200 angular-image
Aquí, s’utilitza el senyalador ‘nom’ per donar un nom al meu servei i el senyalador ‘p’ per exposar el port del contenidor al port amfitrió. Al fitxer package.json, he especificat el port del contenidor on s’hauria d’allotjar l’aplicació Angular. I el 4200 d’aquesta ordre ajuda a assignar el port 4200 del contenidor al port 4200 de l’amfitrió. ‘Angular-image’ és el nom de la imatge que vaig crear anteriorment.
Recordeu : Quan creem un servei, es pot allotjar a qualsevol motor de connexió del clúster. El gerent de l’eixam decidirà on s’allotjarà. Però, independentment del node allotjat, es pot accedir a l'aplicació a localhost: 4200 des de qualsevol dels nodes connectats al clúster.
Com és possible això? Com que Swarm exposa internament els números de port perquè tots els altres nodes del clúster els puguin accedir. Això vol dir que el port núm. 4200 en qualsevol node / gestor del clúster representaria l'aplicació Angular.
Ara que? El contenidor està actiu?
Podeu verificar si el servei està contenit mitjançant l'execució de l'ordre de llista de serveis docker. Però pot trigar un minut a desplegar-se el contenidor. A continuació es mostra l'ordre:
$ docker service ls
Aquesta ordre enumerarà tots els serveis gestionats pel clúster Swarm. En el nostre cas, hauria de mostrar un contenidor actiu. Mireu la captura de pantalla següent com a referència.
Aquí, 'REPLICAS = 1/1' indica que hi ha un únic 'servei' d'aquest contenidor, al clúster. I 'MODE = replicated' indica que el servei es replica a tots els nodes del clúster.
Ara, per identificar el node / gestor on s’allotja l’aplicació, podem executar l’ordre docker command ps service seguida del nom del contenidor. L'ordre és:
$ docker service ps Angular-App-Container
A continuació es mostra la captura de pantalla del mateix.
Es mencionen detalls sobre el node on s’allotja l’aplicació juntament amb l’ordre que s’utilitza per iniciar el servei.
L’ordre ‘docker ps’ il·lumina els detalls sobre el contenidor actiu. L'ordre és:
$ docker ps
Mireu la captura de pantalla següent com a referència.
Però aquesta ordre només funcionarà al gestor de clústers i al node on realment s’allotja el servei.
Per comprovar quants nodes s'estan executant, executeu l'ordre de llista de nodes. L'ordre és:
$ docker node ls
Per comprovar els contenidors que s’executen en un host concret, executeu l’ordre node ps. L'ordre és:
$ docker node ps
Si recordeu, abans he esmentat que el servei s’executa actualment en MODE replicat. Això significa que el servei es replica a tots els nodes dels clústers. Creus que hi ha una alternativa?
Absolutament! Hi ha alguna cosa que s’anomena Global MODE. En aquest mode, hi ha un servei d’aquest contenidor que s’executa a tots els administradors del clúster. Recordeu aturar el servei / contenidor actual abans de fer girar un altre conjunt de contenidors.
L'ordre per a això és:
$ docker service rm Angular-App-Container
L'ordre per fer girar el contenidor en mode global és:
$ docker service create --name 'Angular-App-Container' -p 4200: 4200 --mode global angular-image
Això crearia 3 serveis als 3 nodes del nostre clúster. Podeu verificar-ho executant l'ordre de llista de serveis docker. A continuació es mostra la captura de pantalla.
Quan s’executa l’ordre ps del servei d’acoblament, veureu alguna cosa així:
Com podeu veure, diu que el mode es replica i que les rèpliques d’aquest contenidor són 3. Ara ve la millor part d’aquest bloc.
Per tenir 2 rèpliques dels serveis que s’executen entre els tres contenidors, podem utilitzar el senyal de rèpliques. Mireu l'ordre següent:
$ docker service create --name 'Angular-App-Container' -p 4200: 4200 --replicas = 2 angular-image
Notareu que aquests 2 serveis estan equilibrats en càrrega entre els tres nodes del clúster. Executeu l'ordre de procés del servei de connexió per verificar en quins nodes estan actius els contenidors. Mireu la captura de pantalla següent com a referència. Els contenidors estan actius en un node gestor i un node treballador.
Des del node Worker, podeu verificar que el contenidor s’executa executant l’ordre ‘docker ps’.
Docker Swarm per a una alta disponibilitat
Ara, per verificar que hi hagi una alta disponibilitat al nostre clúster, hem d’experimentar un escenari en què un dels nodes caigui i altres nodes del clúster ho compensin. Podem aconseguir aquest escenari aturant manualment el contenidor d’un dels nodes mitjançant aquesta ordre:
$ docker stop Angular-App-Container
Executeu l'ordre anterior al node: Worker-1 on s'executa el contenidor.Des del gestor, executeu l'ordre:
$ docker service ps Angular-App-Container
Ara notareu que el contenidor s’executa ara al node: Worker-2 i Manager. Tot i això, s'ha tancat des del node: Worker-1. El mateix es pot veure a la captura de pantalla següent.
Així és com Docker Alta Disponibilitat s’aconsegueix. Jon Tot i que el contenidor està inactiu a Worker-1, l'aplicació es pot representar al número de port 4200 d'aquest node de treballador. Això es deu al fet que està connectat internament a altres nodes del clúster i és capaç de representar l'aplicació al navegador.
Alta disponibilitat després d’ampliar els serveis
Ja sigui en mode replicat o global, podem ampliar el nombre de serveis que s’executen al nostre clúster. I fins i tot després d’ampliar la mida, podrem conservar l’alta disponibilitat. Increïble no?
Però tornant al nostre punt, vegem com és de fàcil ampliar el nombre de serveis del nostre clúster. Suposant que tenim 2 o 3 rèpliques al nostre clúster, escalem els serveis a 5 simplement executant una sola ordre. L'ordre és:
$ docker service scale Angular-App-Container = 5
A continuació es mostra la captura de pantalla.
En executar l'ordre de llista de serveis de docker, podeu notar que el nombre de rèpliques és ara de 5. I, executant l'ordre de servei de docker ps juntament amb el nom del servei, podeu veure com els cinc serveis estan equilibrats de càrrega i es distribueixen als 3 nodes. . Els ordres són:
$ docker service ls $ docker service ps Angular-App-Container
I, finalment, en una configuració de Docker Swarm, si no voleu que el vostre gestor participi en els procediments i el mantingueu ocupat només per gestionar els processos, podem eliminar el gestor d’allotjar qualsevol aplicació. Perquè així funciona al món, oi? Els gerents només serveixen per gestionar altres treballadors. De totes maneres, l'ordre per fer-ho és:
Actualització del node $ docker - drenatge de disponibilitat Administrador-1
Podeu verificar si el gestor participa ara al clúster executant l'ordre docker node list i l'ordre docker service ps:
$ docker node ls $ docker service ps Angular-App-Container
Ara podeu notar que els serveis de contenidors s’han dividit entre nodes de treballadors i que el node de gestor s’ha eliminat realment de contenir cap servei. La captura de pantalla es mostra a continuació.
Per tant, això posa fi a aquest bloc de Docker Swarm. Espero que aquest blog expliqui la importància d’implementar el mode Swarm per aconseguir una alta disponibilitat. Estigueu atents a més blocs d’aquesta sèrie de tutorials de Docker.
Alternativament, podeu veure el vídeo següent per entendre com funciona Docker Swarm. Tots els conceptes explicats anteriorment s’han tractat al vídeo.
Docker Swarm per a una alta disponibilitat | Tutorial Docker | Tutorial DevOps
Ara que heu après sobre Docker, consulteu el fitxer per Edureka, una empresa d'aprenentatge en línia de confiança amb una xarxa de més de 250.000 estudiants satisfets repartits per tot el món. Aquest curs de formació en certificació Edureka Docker ajuda els estudiants a adquirir experiència en la implementació de Docker i el seu domini.
Tens alguna pregunta? Esmenta’l a la secció de comentaris i et respondrem.