Mi a legfontosabb jellemzője egy webalapú alkalmazásnak? Sokan vannak, de nekem magas rendelkezésre állás a legfontosabb. Ezt segíti a Docker raj elérése! Segít abban, hogy az alkalmazás rendkívül elérhető legyen.
Az én előző blog , Elmagyaráztam a Docker Compose működését. Ez a blog a Docker Swarm-on az előbbi folytatása, és itt megmagyarázták a Docker Swarm használatának előnyeit bármelyik konténeres alkalmazás tárolásához.
Ebben a blogban csak egy Angular alkalmazásról lesz szó, amely Docker Swarm’ed lesz.
jegyzet : A MEAN Stack alkalmazás tárolásának módja ugyanaz.
Szóval, mi a Docker raj?
Docker Raj a klaszter létrehozásának és fenntartásának technikája Docker motorok . A Docker motorok különböző csomópontokon tárolhatók, és ezek a távoli helyeken lévő csomópontok a Fürt ha Swarm módban csatlakozik.
Miért érdemes használni a Docker Swarmot?
Már említett okokból! Elérés magas rendelkezésre állás minden leállás nélkül minden kint lévő szolgáltató elsőbbséget élvez. Lenyűgözi az ügyfelek magas rendelkezésre állása? Nos, nem lesznek lenyűgözve, ha leállással kell szembenézniük. Ez nem okoskodás.
A Docker Swarm egyéb előnyei
Mint sok más szolgáltatás, a Docker Swarm is automatikus terhelés elosztás nekünk. Ezért nincs szükség a DevOps mérnökeinek arra, hogy a feldolgozási kérelmeket más csomópontokra irányítsák, amikor az egyik nem sikerül. A klaszter menedzsere automatikusan elvégzi számunkra a terheléselosztást.
Decentralizált hozzáférés egy másik előny. Az mit jelent? Ez azt jelenti, hogy az összes csomópont könnyen elérhető a kezelőtől. A menedzser rendszeresen felszólítja a csomópontokat, és nyomon követi azok állapotát / állapotát, hogy megbirkózzon a leállásokkal. A csomópontok azonban nem férhetnek hozzá és nem követhetik a többi csomópontban / kezelőben futó szolgáltatásokat.
Ellenőrizheti a nem. csomópontban futó konténerek, felkerekítés, fokozás a nem. konténerekből vagy arányosan lecsökkent a nem. követelményünk alapján egyetlen parancs végrehajtásával.
Még egy alkalmazás telepítése után is kiadhatjuk gördülő frissítések és ügyeljen arra, hogy a CI (folyamatos integráció) megvalósuljon. A gördülő frissítéseket az egyik csomópont a másik után adja ki, így biztosítva, hogy nincs leállás és a terhelés el van osztva a fürt többi csomópontja között.
És mi lesz ezután? Hogy tegyük a nyilvánvalót. Kezdje el a Docker Swarm használatát, ha már dolgozott a Docker alkalmazással, vagy ha szervezete megbízható webszolgáltatást kíván tárolni.
jegyzet : A dokkoló motorok független gazdagépekre / kiszolgálókra vagy egy gazdagép több virtuális gépére vannak telepítve.
A raj üzemmódjának megkezdése
A Docker Swarmot a menedzser kezdeményezi, vagy hadd fogalmazzak úgy, hogy a Swarm fürtöt elindító példány lesz a manager. A fürt elindításához a következő parancs szükséges:
$ docker raj init --advertise-addr ip-cím
Itt a ’–advertise-addr’ jelzőt használják arra, hogy más csomópontoknak reklámozza magát, akik csatlakozni akarnak a fürthöz. A kezelő IP-címét meg kell adni a zászlóval együtt. Az alábbiakban látható a képernyőkép.
A Swarm-fürt elindításakor egy token jön létre a kezelő végén. Ezt a tokent más csomópontoknak kell használniuk a raj fürtbe való belépéshez.
Hogy van pontosan? Másolja át a kezelő dokkoló motorjánál létrehozott teljes tokent, illessze be a csomópont dokkoló motorjába, és hajtsa végre. A fenti képernyőkép kiemelt része token. Amikor a token végrehajtásra kerül egy dolgozói csomóponton, az alábbi képernyőképnek tűnik.
Bármely csomópont, amely csatlakozik a fürthöz, később előléptethető kezelővé. Ha azt szeretné, hogy dokkoló motor csatlakozzon menedzserként, hajtsa végre az alábbi parancsot a kezelő végén:
$ docker raj csatlakozási token menedzsere
És egy későbbi időpontban, ha azt szeretné, hogy egy csomópont tokenje csatlakozzon a fürthöz, futtassa az alábbi parancsot:
$ docker raj csatlakozási token csomópontja
Folytassa, és hajtsa végre a tokent minden kívánt csomóponton, hogy csatlakozzon a fürthöz. Ha mindez megtörtént, futtathat egy docker csomópontlista parancsot annak ellenőrzésére, hogy hány csomópont csatlakozott a fürthöz állapotuk mellett. A parancs a következő:
$ dokkoló csomópont ls
A képernyőkép a következő:
Docker kép létrehozása a szögletes alkalmazáshoz
Ha minden rendben van, akkor megkezdhetjük a Swarm szolgáltatásunkat, feltéve, hogy a Docker Image felépül. A Docker kép a Dockerfile fájlból építhető fel. Az alkalmazások létrehozásához használt Dockerfile az alábbiakban található:
FROM csomópont: 6 RUN mkdir -p / usr / src / app WORKDIR / usr / src / app COPY package.json / usr / src / app RUN npm gyorsítótár tiszta RUN npm install COPY. / usr / src / app EXPOSE 4200 CMD ['npm', 'start']
A Dockerfile egy parancssor végrehajtására szolgál egy egyedi Docker-kép felépítéséhez egy alapképből. Amint láthatja, az általam használt alapkép ’Node: 6’. A NodeJS a Docker Hub I képe, amely a 6-os verzióval van ellátva.
Ezután létrehozok egy új Docker könyvtárat a konténer belsejében, és a tárolómban lévő munkakönyvtárgá teszem.
Másolom a ’package.json’ fájlt a helyi gépemről a konténer munkakönyvtárába. Ezután megadom a „RUN npm cache clean” és a „RUN npm install” parancsokat. npm telepítés A parancs letölti a package.json fájlban említett függőségek verzióját.
Ezután átmásolom az összes projektkódot a helyi számítógépről a konténerbe, kiteszem a 4200-as portot az Angular alkalmazás eléréséhez a böngészőben, végül pedig megadom az npm start parancsot, amely tárolja az alkalmazást.
Most a Docker kép ezen Docker fájl alapján történő létrehozásához futtassa az alábbi parancsot:
egy számjegyek összege a java-ban a ciklushoz
$ docker build -t szögletes kép.
Jegyzet: A Docker képeket a fürt összes csomópontjában ki kell építeni. Enélkül a konténerek nem pörgethetők más Docker motorokban.
A Docker Swarm szolgáltatás elindítása
Tekintettel arra, hogy a Docker képünk fel van építve, ebből a képből tárolót forgathatunk ki. De csinálunk valami jobbat: létrehozunk belőle egy Docker Swarm szolgáltatást. Parancs egy raj szolgáltatás létrehozására:
$ docker service create --name 'Angular-App-Container' -p 4200: 4200 angular-image
Itt a „név” zászlóval nevet adok a szolgáltatásomnak, a „p” jelzőt pedig arra használjuk, hogy a tároló portot kiszolgáltassuk a gazdagép portjának. A package.json fájlban megadtam azt a konténer portot, amelyen az Angular alkalmazást tárolni kell. És ebben a parancsban szereplő 4200 segít a konténer 4200-as portjának feltérképezésében a 4200-as port befogadására. Az „angular-image” az a kép neve, amelyet korábban építettem.
Emlékezik : Amikor létrehozunk egy szolgáltatást, a fürt bármely dokkoló motorján tárolható. A raj menedzsere dönti el, hol fogják látni. De függetlenül attól, hogy melyik csomópontban van tárolva, az alkalmazás a localhost: 4200-on érhető el a fürt bármelyik csomópontjáról.
Hogyan lehetséges ez? Mivel a Swarm belsőleg kiteszi a portszámokat, hogy a fürt minden más csomópontja hozzáférhető legyen. Ez azt jelenti, hogy a kikötő nem. A fürt bármely csomópontján / kezelőjén található 4200 az Angular alkalmazást jeleníti meg.
Most mi? Aktív a tároló?
A docker szolgáltatáslista parancs futtatásával ellenőrizheti, hogy a szolgáltatás tárolva van-e. De eltarthat egy percig, amíg a konténer ki lesz telepítve. Az alábbiakban található a parancs:
$ dokkoló szolgáltatás ls
Ez a parancs felsorolja a Swarm-fürt által kezelt összes szolgáltatást. Esetünkben egy aktív tárolót kell megjelenítenie. Nézze meg az alábbi képernyőképet.
Itt a „REPLICAS = 1/1” azt jelzi, hogy az adott konténernek egyetlen „szolgáltatása” van a fürtben. A „MODE = replikálva” azt jelzi, hogy a szolgáltatás replikálódik a fürt összes csomópontján.
Most, hogy meghatározzuk, melyik csomóponton / kezelőn, az alkalmazáson van ház, futtathatjuk a docker service ps parancsot, amelyet a tároló neve követ. A parancs a következő:
$ docker service ps Angular-App-Container
Az ugyanezről készült képernyőkép az alábbiakban látható.
Ez megemlíti a csomópont részleteit, amelyen az alkalmazást tárolják, valamint a szolgáltatás indításához használt parancsot.
A „dokkoló ps” parancs rávilágít az aktív tároló részleteire. A parancs a következő:
$ dokkoló ps
Nézze meg az alábbi képernyőképet.
De ez a parancs csak a fürtkezelőn és azon a csomóponton fog működni, ahol a szolgáltatást ténylegesen tárolják.
Annak ellenőrzéséhez, hogy hány csomópont fut, futtassa a csomópontlista parancsot. A parancs:
$ dokkoló csomópont ls
Egy adott gazdagépen futó tárolók ellenőrzéséhez futtassa a node ps parancsot. A parancs:
$ dokkoló csomópont ps
Ha emlékszel, korábban említettem, hogy a szolgáltatás jelenleg replikált módban fut. Ez azt jelenti, hogy a szolgáltatás replikálódik a fürtök összes csomópontján. Szerinted van alternatíva?
Teljesen! Van valami, amit Global MODE-nak hívnak. Ebben a módban a tároló szolgáltatása fut a fürt minden egyes kezelőjénél. Ne felejtse el leállítani az aktuális szolgáltatást / konténert, mielőtt újabb konténerkészletet forgatna.
A parancs erre:
$ docker service rm Angular-App-Container
A tároló globális módban történő forgatására szolgáló parancs a következő:
$ docker service create --name 'Angular-App-Container' -p 4200: 4200 --mode global angular-image
Ez 3 szolgáltatást hozna létre a fürtünk 3 csomópontján. A docker szolgáltatáslista parancs futtatásával ellenőrizheti. Ennek képernyőképe az alábbiakban látható.
A docker service ps parancs végrehajtásakor valami ilyesmit fog látni:
Amint láthatja, azt mondja, hogy az üzemmód replikálva van, és ennek a tárolónak a másolatai 3. Most jön ennek a blognak a legjobb része.
Ahhoz, hogy a szolgáltatások két példánya futhasson a három konténer között, használhatjuk a replikák zászlót. Nézze meg az alábbi parancsot:
$ docker service create --name 'Angular-App-Container' -p 4200: 4200 --replicas = 2 szögletes kép
Észre fogja venni, hogy ez a 2 szolgáltatás a terhelés kiegyensúlyozott a fürt három csomópontja között. Futtassa a docker szolgáltatás folyamat parancsát annak ellenőrzésére, hogy mely csomópontokban vannak aktívak a tárolók. Nézze meg az alábbi képernyőképet. A tárolók egy kezelő csomópontban és egy munkás csomópontban aktívak.
A Worker csomópontból a ’docker ps’ parancs végrehajtásával ellenőrizheti, hogy a tároló fut-e.
Docker raj magas rendelkezésre állás érdekében
Most, hogy valóban ellenőrizzük, hogy magas rendelkezésre áll-e a fürtünkben, meg kell tapasztalnunk egy olyan forgatókönyvet, amikor az egyik csomópont lemegy, és a fürt többi csomópontja ezt pótolja. Ezt a forgatókönyvet úgy valósíthatjuk meg, hogy manuálisan leállítjuk a tárolót az egyik csomópontról a következő paranccsal:
$ docker stop Angular-App-Container
Futtassa a fenti parancsot a csomóponton: Worker-1, ahol a tároló fut.A kezelőtől futtassa a következő parancsot:
$ docker service ps Angular-App-Container
Most észreveszi, hogy a tároló most fut a csomópontban: Worker-2 és Manager. A csomópontból azonban leállt: Worker-1. Ugyanez látható az alábbi képernyőképen.
Így Docker magas rendelkezésre állás elért. énn annak ellenére, hogy a konténer inaktív a Worker-1-ben, az alkalmazás a 4200-as számú porton jeleníthető meg az adott munkavállalói csomóponton. Ez azért van, mert belsőleg kapcsolódik a fürt többi csomópontjához, és képes megjeleníteni az alkalmazást a böngészőben.
Magas rendelkezésre állás a szolgáltatások bővítése után
Legyen szó replikált vagy globális módról, növelhetjük a fürtünkben futó szolgáltatások számát. És még a nagyítás után is képesek vagyunk megtartani a magas rendelkezésre állást. Félelmetes, nem?
mi az applet a java-ban példával
Visszatérve a lényegünkhöz, nézzük meg, milyen egyszerű növelni a fürtünk szolgáltatásainak számát. Ha feltételezzük, hogy a fürtünkben 2 vagy 3 másolat van, akkor egyetlen parancs futtatásával bővítsük a szolgáltatásokat 5-re. A parancs a következő:
$ docker szolgáltatási skála Angular-App-Container = 5
Ennek képernyőképe az alábbiakban látható.
A docker szolgáltatáslista parancs futtatásával észreveheti, hogy a replikák száma most 5. A futtatásával a docker service ps parancsot a szolgáltatás nevével együtt láthatja, hogy az 5 szolgáltatás kiegyensúlyozott-e és hogyan oszlik el a 3 csomóponton. . A parancsok:
$ docker szolgáltatás ls $ docker szolgáltatás ps Angular-App-Container
És végül: a Docker Swarm beállításaiban, ha nem szeretné, hogy a menedzsere részt vegyen az eljárásokban, és hogy csak a folyamatok irányításáért legyen elfoglalva, akkor le tudjuk üríteni a menedzsert minden alkalmazás tárolásától. Mert a világon így működik, nem? A vezetők csak más munkavállalók irányítására szolgálnak. Mindenesetre a parancs erre:
$ docker csomópont-frissítés - elérhetőség-menedzser Manager-1
A docker csomópont lista parancs és a docker service ps parancs futtatásával ellenőrizheti, hogy a kezelő részt vesz-e a fürtben:
$ docker csomópont ls $ docker szolgáltatás ps Angular-App-Container
Most észreveheti, hogy a konténerszolgáltatásokat felosztották a Munkavállaló csomópontjai között, és a Kezelő csomópontot valóban kiszüntették bármely szolgáltatás konténerezéséből. A képernyőkép alatt van.
Tehát ezzel véget ér a blog a Docker Swarm-on. Remélem, hogy ez a blog elmagyarázta, mennyire fontos a Swarm mód megvalósítása a magas rendelkezésre állás elérése érdekében. Figyeljen további blogokat ebben a Docker oktatósorozatban.
Alternatív megoldásként megnézheti az alábbi videót, hogy megértse a Docker Swarm működését. A fentiekben ismertetett összes fogalmat a videó lefedte.
Docker raj magas rendelkezésre állás érdekében Docker bemutatója DevOps bemutató
Most, hogy megtudta a Docker-t, nézze meg a az Edureka, egy megbízható online tanulási vállalat, amelynek több mint 250 000 elégedett tanulóval rendelkező hálózata elterjedt az egész világon. Ez az Edureka Docker tanúsító tanfolyam segít a tanulóknak szaktudást szerezni a Docker megvalósításában és elsajátításában.
Van egy kérdésünk? Kérjük, említse meg a megjegyzések részben, és mi kapcsolatba lépünk Önnel.