Коя е най-важната характеристика на всяко уеб-базирано приложение? Има много, но за мен висока наличност е най-важното. Това е, което Docker Swarm ни помага да постигнем! Помага приложението да е високо достъпно.
В моето предишен блог , Обясних как работи Docker Compose. Този блог за Docker Swarm е продължение на първия и тук са обяснени предимствата от използването на Docker Swarm за контейнериране на всяко приложение с няколко контейнера.
В случая на този блог това е само приложение Angular, което ще бъде Docker Swarm’ed.
Забележка : Методът за съдържание на приложението MEAN Stack е същият.
И така, какво е Docker Swarm?
Докер рояк е техника за създаване и поддържане на клъстер от Докер двигатели . Двигателите на Docker могат да бъдат хоствани на различни възли и тези възли, които са на отдалечени места, образуват a Клъстер когато е свързан в режим Рояк.
Защо да използвам Docker Swarm?
По споменатите вече причини! Постигане висока наличност без прекъсвания е приоритет за всеки доставчик на услуги там. Ще впечатли ли високата наличност вашите клиенти? Е, те няма да бъдат впечатлени, ако са изправени пред престой. Това е невъзможно.
Други предимства на Docker Swarm
Подобно на много други услуги, Docker Swarm прави автоматично балансиране на натоварването за нас. Следователно не е необходимо инженерите на DevOps да насочват заявките за обработка към други възли, когато някой не успее. Мениджърът на клъстера автоматично ще извърши балансиране на натоварването за нас.
Децентрализиран достъп е друга полза. Какво означава това? Това означава, че всички възли могат да бъдат лесно достъпни от мениджъра. Мениджърът също така ще подканя редовно възлите и ще следи състоянието му / състоянието му, за да се справи с престоя. Въпреки това, възлите не могат да имат достъп или да проследяват услугите, изпълнявани в други възли / мениджъри.
Можете да проверите не. на контейнери, работещи във възел, мащабиране не. на контейнери или намаляване на мащаба не. въз основа на нашето изискване, само с изпълнение на една команда.
Дори след като приложението е внедрено, можем да издадем подвижни актуализации и се уверете, че е постигната CI (Непрекъсната интеграция). Подвижните актуализации се издават на един възел след другия, като по този начин се гарантира, че няма престой и натоварването се разпределя между други възли в клъстера.
И така, какво следва? За да направите очевидното. Започнете с Docker Swarm, ако вече сте работили с Docker или ако вашата организация иска да съдържа надеждна уеб услуга.
Забележка : Докер двигателите са инсталирани на независими хостове / сървъри или в множество виртуални машини в хост.
Първи стъпки с режим Рояк
Docker Swarm се инициира от мениджъра, или нека го кажа по този начин, екземплярът, който стартира клъстера Swarm, се превръща в мениджър. Командата за стартиране на клъстера е:
$ docker swarm init --advertise-addr ip-адрес
Тук флагът „–advertise-addr“ се използва за реклама на други възли, които искат да се присъединят към клъстера. IP адресът на мениджъра трябва да бъде посочен заедно с флага. По-долу е примерната екранна снимка.
Когато се инициира клъстерът Swarm, в края на мениджъра се генерира маркер. Този маркер трябва да се използва от други възли, за да се присъедини към клъстера рояк.
Как е точно? Копирайте целия токен, генериран в механизма за докер на мениджъра, поставете го в механизма за докер на възела и го изпълнете. Откроената част на екранната снимка по-горе е символ. Когато маркерът се изпълни на работен възел, той ще изглежда като скрийншота по-долу.
Всеки възел, който се присъединява към клъстера, може по-късно да бъде повишен до мениджър. В случай, че искате докер двигател да се присъедини като мениджър, изпълнете командата по-долу в края на мениджъра:
$ docker рояк мениджър за присъединяване
И по-късно, ако искате маркерът за възел да се присъедини към клъстера, изпълнете командата по-долу:
$ docker роячен възел за присъединяване-маркер
Продължете и изпълнете маркера на всеки възел, който искате, за да се присъедините към клъстера. Когато всичко това е направено, можете да стартирате команда за списък с възли на докер, за да проверите колко възли са се присъединили към клъстера заедно със състоянието им. Командата е:
$ docker възел ls
Екранната снимка е по-долу:
Създаване на изображение на Docker за ъглово приложение
Ако всичко е наред, тогава можем да стартираме нашата услуга Swarm, при условие че е изграден Docker Image. Образът на Docker може да бъде изграден от Dockerfile. Dockerfile, използван за изграждане на приложения, е по-долу:
ОТ възел: 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']
Dockerfile се използва за изпълнение на набор от команди заедно за изграждане на персонализирано изображение на Docker от основно изображение. Както можете да видите, основното изображение, което използвах, е „Node: 6“. NodeJS е изображението I от Docker Hub, което е маркирано с версия 6.
След това създавам нова директория на Docker вътре в контейнера и я превръщам в работна директория вътре в моя контейнер.
Копирам файла ‘package.json’ от локалната си машина в работната директория на контейнера. След това посочвам командите „RUN npm cache clean“ и „RUN npm install“. npm инсталиране команда изтегля версията на зависимостите, спомената във файла package.json.
След това копирам всички кодове на проекти от локалната машина в контейнера, излагам номер на порт 4200 за достъп до приложението Angular в браузъра и накрая посочвам командата npm start, която контейнерира приложението.
Сега, за да създадете изображение на Docker въз основа на този Dockerfile, изпълнете командата по-долу:
разлика между хвърляне и хвърляния в java
$ docker build -t ъглово изображение.
Забележка: Изображенията на Docker трябва да бъдат вградени във всички възли в клъстера. Без него контейнерите не могат да се въртят в други двигатели на Docker.
Стартиране на услугата за роене на Docker
Като се има предвид, че нашето изображение на Docker е изградено, можем да извадим контейнер от това изображение. Но ние ще направим нещо по-добро: създайте услуга Docker Swarm от нея. Командата за създаване на роева услуга е:
$ docker услуга create --name 'Angular-App-Container' -p 4200: 4200 ъглово изображение
Тук флагът „name“ се използва за даване на име на моята услуга, а флагът „p“ се използва за излагане на порта на контейнера на порта на хоста. Във файла package.json посочих порта на контейнера, на който трябва да се хоства приложението Angular. И 4200 в тази команда помага да се картографира портът на контейнера 4200 към порта на хоста 4200. „angular-image“ е името на изображението, което по-рано изградих.
Помня : Когато създаваме услуга, тя може да бъде хоствана на всеки докер двигател в клъстера. Управителят на роя ще реши къде ще бъде домакин. Но, без значение в кой възел се хоства, приложението може да бъде достъпно на localhost: 4200 от всеки от възлите, свързани в клъстера.
Как е възможно това? Тъй като Swarm вътрешно излага номерата на портовете, за да бъдат достъпни от всеки друг възел в клъстера. Това означава, порт №. 4200 на всеки възел / мениджър в клъстера ще изобрази приложението Angular.
Сега какво? Активен ли е контейнерът?
Можете да проверите дали услугата е контейнеризирана, като изпълните командата на списъка с услуги на докер. Но може да отнеме минута, докато контейнерът бъде разположен. По-долу е командата:
$ docker услуга ls
Тази команда ще изброи всички услуги, управлявани от клъстера Swarm. В нашия случай той трябва да показва един активен контейнер. Погледнете екранната снимка по-долу за справка.
Тук „REPLICAS = 1/1“ показва, че в клъстера има една единствена „услуга“ на този контейнер. И “MODE = реплициран” показва, че услугата се репликира на всички възли в клъстера.
Сега, за да идентифицираме на кой възел / мениджър се хоства приложението, можем да стартираме командата ps docker service команда, последвана от името на контейнера. Командата е:
$ docker услуга ps Angular-App-Container
Снимката на екрана за същото е по-долу.
Това споменава подробности за възела, на който се хоства приложението, заедно с командата, използвана за стартиране на услугата.
Командата ‘docker ps’ хвърля светлина върху подробностите за активния контейнер. Командата е:
$ docker ps
Погледнете екранната снимка по-долу за справка.
Но тази команда ще работи само върху мениджъра на клъстери и възела, където всъщност се хоства услугата.
За да проверите колко възли работят, изпълнете командата списък с възли. Командата е:
$ docker възел ls
За да проверите контейнерите, работещи в определен хост, изпълнете командата node ps. Командата е:
$ docker възел ps
Ако си спомняте, по-рано споменах, че услугата в момента работи в репликиран РЕЖИМ. Това означава, че услугата се репликира във всички възли в клъстерите. Мислите ли, че има алтернатива?
Абсолютно! Има нещо, наречено Global MODE. В този режим има услуга на този контейнер, работеща при всеки един / мениджър в клъстера. Не забравяйте да спрете текущата услуга / контейнер, преди да завъртите друг набор от контейнери.
Командата за това е:
$ docker услуга rm Angular-App-Container
Командата за завъртане на контейнера в глобален режим е:
$ docker service create --name 'Angular-App-Container' -p 4200: 4200 --mode global angular-image
Това би създало 3 услуги на 3-те възли в нашия клъстер. Можете да го проверите, като изпълните командата на списъка с услуги на докер. Екранната снимка на това е по-долу.
Когато се изпълни командата на докер услугата ps, ще видите нещо подобно:
Както можете да видите, той казва, че режимът е репликиран и репликите на този контейнер са 3. Сега идва най-добрата част от този блог.
За да имаме 2 реплики на услугите, работещи между трите контейнера, можем да използваме флага на репликите. Погледнете командата по-долу:
$ docker услуга create --name 'Angular-App-Container' -p 4200: 4200 --replicas = 2 ъглово изображение
Ще забележите, че тези 2 услуги са балансирани натоварване между трите възли в клъстера. Изпълнете командата за процес на услугата на докер, за да проверите, в кои възли са активни контейнерите. Погледнете екранната снимка по-долу за справка. Контейнерите са активни в един мениджърски възел и един работен възел.
От възела Worker можете да проверите дали контейнерът работи, като изпълните командата ‘docker ps’.
Докер рой за висока наличност
Сега, за да проверим дали има голяма наличност в нашия клъстер, трябва да изпитаме сценарий, при който един от възлите се срива, а други възли в клъстера го компенсират. Можем да осъществим този сценарий чрез ръчно спиране на контейнера от един от възлите с помощта на тази команда:
$ docker stop Angular-App-Container
Изпълнете горната команда на възела: Worker-1, където контейнерът работи.От мениджъра изпълнете командата:
$ docker услуга ps Angular-App-Container
Сега ще забележите, че контейнерът вече работи в node: Worker-2 и Manager. Той обаче е изключен от възел: Worker-1. Същото се вижда от екрана по-долу.
Ето как Висока наличност на Docker е постигнат. Азn въпреки че контейнерът е неактивен в Worker-1, приложението може да бъде изобразено на номер на порт 4200 на този работен възел. Това е така, защото той е вътрешно свързан с други възли в клъстера и е в състояние да изобрази приложението в браузъра.
Висока наличност след мащабиране на услугите
Било то в репликиран режим или глобален режим, ние можем да увеличим броя на услугите, изпълнявани в нашия клъстер. И дори след мащабиране, ще можем да запазим висока наличност. Страхотно, нали?
каква е ползата от сериализацията в java
Но като се върнем към нашата гледна точка, нека видим колко лесно е да се увеличи броят на услугите в нашия клъстер. Ако приемем, че имаме или 2 или 3 реплики в нашия клъстер, нека мащабираме услугите до 5, като просто изпълним една команда. Командата е:
$ docker сервизна скала Angular-App-Container = 5
Екранната снимка на това е по-долу.
Изпълнявайки командата на списъка с услуги на докер, можете да забележите, че броят на репликите вече е 5. И като изпълните командата на докер услугата ps заедно с името на услугата, можете да видите как 5-те услуги са балансирани натоварване и разпределени на 3 възли . Командите са:
$ docker service ls $ docker service ps Angular-App-Container
И накрая, в настройка на Docker Swarm, ако не искате вашият мениджър да участва в процедурата и да я заема само за управление на процесите, тогава можем да източим мениджъра от хостване на всяко приложение. Защото така работи в света, нали? Мениджърите са само за управление на други работници. Както и да е, командата за това е:
$ docker възел актуализация - наличност изтичане Manager-1
Можете да проверите дали мениджърът сега участва в клъстера, като стартирате командата на списъка с възлови докери и командата ps на docker service:
$ docker възел ls $ docker услуга ps Angular-App-Container
Вече можете да забележите, че контейнерните услуги са разделени между работни възли и възелът на мениджъра всъщност е източен от контейнеризиране на която и да е услуга. Екранната снимка е по-долу.
И така, това слага край на този блог на Docker Swarm. Надявам се този блог да обясни колко е важно да се приложи режимът Swarm за постигане на висока наличност. Следете за повече блогове в тази поредица с уроци на Docker.
Можете алтернативно да гледате видеото по-долу, за да разберете как работи Docker Swarm. Всички обяснени по-горе концепции са разгледани във видеото.
Докер рой за висока наличност | Урок за Docker | Урок за DevOps
След като научихте за Docker, разгледайте от Edureka, доверена компания за онлайн обучение с мрежа от над 250 000 доволни учащи, разпространени по целия свят. Този курс за сертифициране на Edureka Docker помага на обучаващите се да придобият опит в прилагането на Docker и овладяването му.
Имате въпрос към нас? Моля, споменете го в раздела за коментари и ние ще се свържем с вас.