Ако сте контейнеризирали работния си процес на разработка, ще се съгласите, че Docker е един от най-добрите избори за контрол на версиите. Въпреки това, Docker Swarm е една от функциите на Docker, използвани за оркестриране на сложни приложения.
Работният механизъм на Docker Swarm може да бъде труден за разбиване в началото. Но не се притеснявайте, ще го разбием в тази статия. И така, какво е Docker Swarm? Защо да го използвате? И как работи?
Какво е Docker Swarm и как работи?
Docker Swarm се отнася до група Docker хостове (компютри), свързани в мрежа като клъстер за изпълнение на определени задачи. Всеки Docker хост в този клъстер е възел, наричан още работен възел.
За да осигурите ефективно разпределение на задачите, имате нужда от мениджърски възел. В идеалния случай инициализацията на режим Docker Swarm започва с мениджърския възел, а следващите възли стават работни.
Като оператор вие трябва само да взаимодействате с мениджърския възел, който предава инструкции на работниците. Неизменно работните възли получават разпределението на задачите от мениджърския възел и ги изпълняват съответно.
Мениджърският възел обаче може също да участва в изпълнението на задачата (като работник) или директно да управлява лицето. Можете да предотвратите планирането на задачи в мениджъра, като превключите състоянието му от активен да се източване. Но решението ви да присвоите тази двойна функция може да зависи от няколко фактора. По същество искате да сте сигурни, че има достатъчно ресурси, за да се справи с няколко роли, преди да го направите.
Възлите се провалят. Така мениджърският възел активно следи състоянието на всеки работен възел и активира механизъм, устойчив на откази, за да пренасрочи задачата от неуспешен възел към друг.
Но какво ще стане, ако мениджърският възел също се срине? Интересното е, че роякът продължава да работи. Единственият капан е, че вече няма да можете да комуникирате с мениджърския възел, за да контролирате клъстера.
Общият безопасен подход за предотвратяване на това е да се присвои ролята на мениджър на много възли (Docker препоръчва максимум седем на клъстер). След това можете да изберете основния мениджърски възел от тях. Когато основният мениджър се срине, един от резервните мениджъри поема ролята.
Въпреки това, не е нужно да се притеснявате за превключване на роли между възли или поддръжка на състояние в клъстер. Алгоритъмът за консенсус на сала (метод, устойчив на грешки), вграден в Docker SwarmKit, се грижи за това.
Защо да използвате Docker Swarm?
Docker Swarm е удобен за внедряване на сложни приложения с големи перспективи за мащабируемост. Един от основните му случаи на използване е да децентрализира микроуслуги. След това всяка микроуслуга споделя подобен контейнер с тези на други работни възли.
Друга причина да използвате Docker Swarm е, че множество хостове изпълняват задачи едновременно в клъстер. Това е в контраст с Docker Compose, който ви позволява само да стартирате множество контейнери на един Docker двигател.
Този мащабируем атрибут на Docker Swarm позволява на приложенията да бъдат постоянно достъпни с нулево забавяне. Дори е една от причините да искате изберете Docker пред други инструменти за виртуализация.
И какво още? За разлика от единичните Docker контейнери, където контейнерът спира, когато се повреди, Docker Swarm автоматично преразпределя задачите между наличните работни възли, когато един от тях се повреди.
Docker Swarm също поддържа резервно копие на всяко състояние. Така че винаги можете да върнете новите конфигурации на рояк към състоянието на предишния. Да кажем, че мениджърският възел на предишен рояк се провали; можете да стартирате нов клъстер с повече мениджърски възли и да го върнете, за да адаптирате конфигурацията на предишния.
Също така е важно да споменем, че взаимодействието между мениджърския възел и работните възли е защитено.
Docker има много алтернативи, а един от най-близките е Kubernetes. Въпреки това, Docker Swarm е лесен за използване и по-автоматизиран. Например, докато може да се наложи да балансирате натоварването ръчно в някои други инструменти за оркестрация като Kubernetes, Docker Swarm разполага с автоматично балансиране на натоварването, което улеснява живота на DevOps.
Архитектурата на Docker Swarm
Архитектурата на Docker Swarm се върти около услуги, възли и задачи. Въпреки това, всеки има роля за успешното управление на стека.
Услуги
Услугата Docker Swarm описва подробно конфигурацията на изображението на Docker, което управлява всички контейнери в рояк. Той включва информация за задачите в клъстер. Например услуга може да опише a Настройка на Dockerized SQL сървър.
Когато стартирате услуга, тя принуждава мениджърския възел да се синхронизира с нейните конфигурации. След това мениджърският възел изпълнява останалите работни възли въз основа на посочените настройки в услугата.
Услугите в Docker Swarm могат да бъдат глобални или репликирани.
Разликата между тях е, че докато глобалните услуги дефинират само една задача за всички възли в клъстера, репликираните услуги определят броя задачи на възел.
Възли
Възел в Docker Swarm е екземпляр на цялото време за изпълнение на Docker, известен също като Docker engine. Swarm възлите могат да бъдат физически или виртуални машини. Представете си това като мрежа от компютри, изпълняващи подобни процеси (контейнери).
Обикновено обаче възлите обхващат няколко компютъра и сървъри, работещи с Docker двигателя в приложения от реалния живот. И както споменахме по-рано, възелът може да бъде мениджър или работник, в зависимост от ролята.
Мениджърският възел слуша сърдечния ритъм на рояка и контролира работните възли, които изпълняват задачи, възложени им от мениджърския възел. Както беше посочено по-рано, можете да имате повече от един мениджърски възел в рояк. Но в идеалния случай опитайте да ограничите броя до под седем, тъй като добавянето на твърде много мениджърски възли може да намали производителността на рояка.
Задачи
Задачата определя работата, възложена на всеки възел в Docker Swarm. Във фонов режим планирането на задачи в Docker Swarm започва, когато оркестратор създава задачи и ги предава на планировчик, който създава контейнер за всяка задача.
След това мениджърският възел използва планировчика, за да присвоява и преназначава задачи на възли, както се изисква и е посочено в услугата Docker.
Docker Swarm vs. Docker Compose: Какви са разликите?
Хората често използват Docker Compose и Docker Swarm взаимозаменяемо. Въпреки че и двете включват работа с множество контейнери, те са различни.
Докато Docker Compose ви позволява да стартирате множество контейнери на един хост, Docker Swarm ги разпространява в няколко Docker машини в клъстер.
Използвате Docker Compose, когато трябва да завъртите отделни контейнери за всяка услуга в приложението си. Така, когато един компонент се срине, той не пречи на останалите. Въпреки това, когато хост машината се повреди, цялото приложение също се срива.
Docker Swarm обаче ви помага да стартирате много контейнери на клъстерирани възли. И така, всеки компонент на вашето приложение се намира на няколко възела. И когато един възел, обработващ компонент на приложение, се срине, роят разпределя задачата си към друг възел в рамките на клъстера и пренасрочва изпълняваните задачи, предотвратявайки прекъсване.
Следователно, докато може да имате прекъсване на Docker Compose, Docker Swarm гарантира, че приложението ви продължава да работи с помощта на резервни сървъри (работни възли). Въпреки това Docker 1.13 поддържа внедряване на Docker Compose в режим Swarm с помощта на разгръщане на докер стек команда.
Docker Swarm ви помага да разположите сложни приложения
Контейнеризацията надмина виртуалните машини в дизайна на софтуера за непрекъсната интеграция и непрекъсната доставка (CI/CD). Следователно разбирането на дребните детайли на механизма на Docker Swarm е плюс умение, ако искате да станете безценен DevOps експерт.
Вероятно знаете как да завъртите Docker контейнер или дори да стартирате Docker Compose за множество контейнери в един хост. Но Docker Swarm е по-удобен за внедряване на приложения със сложна архитектура. Той разделя процесите на единици, подобрява достъпа по време на изпълнение и намалява или дори елиминира шансовете за прекъсване.
