Докер и Кубернети предлагат ли „най-добрата архитектура“?

Здравейте там, отново съм с друга статия. Но този път съм в настроение да разрешавам някои митове.

Светът се променя всяка секунда, както и технологията. Относно Докер и Кубернети, трябва да слушате много неща. Особено сравнението между тяхната архитектура. Много хора се чудят кое от тях е по-добро?

Има много други въпроси и споменавам всички тях. Защо? Единствената причина е, че ще ви помогне да разберете Kubernetes и Docker. И така, как Docker и Kubernetes промениха разработката на софтуера? Някой от тях предлага ли силна архитектура? Възможно ли е да се унифицират процесите на развитие и интеграция? Ако да, какви са ограниченията? Това ще намали ли усложненията за разработчиците?

Първо, разберете, че сравнение между Докер и Кубернети не е толкова лесно, колкото си мислите. Какво е по-добре? Докер или Кубернети? Вярвам, че няма „по-добро“, защото и двете са различни. Докер е автобусът, докато Kubernetes е автобусното пристанище. И така, какво е важно? Със сигурност и двете са важни. Имате нужда от двамата.

Така че в тази статия ще преминем от реалния живот към процесите на развитие, към архитектурата и обратно към реалния живот.

По-нататък ще идентифицираме различни компоненти и принципи, които са част от архитектурата. В крайна сметка заключението може да ви изненада или да ви зарадва. Зависи от вашето възприятие и опит с Докер и Кубернети.

Първият ход от реалния живот към работните процеси в развитието

Знаете ли защо процесите на развитие са важни? Ако няма процеси на развитие, няма добре насочен генерализиран подход. Процесът на развитие намалява времето между раждането на идеята до нейното доставяне. Опростява процеса и поддържа качеството.

Има два типа идеи, едната е добра, а другата е лоша. Няма трети тип междинна идея в развитието. Идеята може да бъде добра или лоша, но може да се измери само чрез изпълнението. Ако това е лоша идея, вие прилагате и откат! Ако е добра идея, просто продължете. Отстъпването се контролира от робот, т.е. автоматизация.

От всичко това непрекъснатата система за интеграция и доставка се превърна в спасител. Улесни нещата. Ако имате идея и кода, реализирайте я! Но има един малък проблем със системата за интеграция и доставка. Процесът е трудно да се формализира изолирано от технологиите и бизнес процесите, специфични за вашата компания.

И така, как беше решен този проблем?

Сега този проблем беше решен с помощта на Докер и Кубернети. И двамата се появиха като Месия. Нивото на абстракция и идеологическият подход решиха почти 80% от проблема. Имайте предвид, 80% е много добър процент в сектора за развитие. 20% са все още там и човек трябва да бъде творчески гений за решаването му. Зависи от вида на приложението и начина, по който го решавате.

Docker решава проблема с работния поток за развитие. Docker предлага прост процес и е достатъчен за повечето от работните среди.

Източник на изображения: https://cdn-images-1.medium.com/max/800/0*nDrc_jeOKTMS7akB.

С помощта на този подход човек може да автоматизира и унифицира всичко.

Въведение в средата за развитие

На първо място, проектът трябва да се състои от docker-compose.yml файл. Предимството на този файл е, че той ще премахне тежестта от стартиране на приложението / услугата на локалната машина. Програмистът няма нужда да мисли за това. Всъщност само обикновена команда за докиране на композиция е достатъчна, за да стартирате приложението си. Командата също така се грижи за зависимостите, попълвайки базата данни с приспособления, качва локалния код вътре в контейнера, като позволява проследяване на кода и отговаря на очаквания порт.

В допълнение към всичко това, вие също не трябва да се притеснявате за стартиране, извършване на промени, избор на рамка и т.н. Всяко и всичко е описано в стандартните инструкции предварително. Това е продиктувано от сервизните шаблони според настройките като frontend, backkend и работник.

Време за автоматизирано тестване

Чували ли сте за „Черната кутия“? Той записва всичко, дори последните секунди преди самолетна катастрофа. Какво стана? Как се случи това? Всичко това се получава от черната кутия. По същия начин тук има черна кутия.

Източник на изображението: https://cdn-images-1.medium.com/max/800/0*B5Qn9D5W4lscB86h.

Подобно на оригиналната черна кутия, и нашата черна кутия за контейнери съхранява всичко. Всички двоични данни 1 или 0 и т.н. се съхраняват в черното поле. И така, как се случва автоматизацията? Лесно е, имате набор от команди и docker-compose.yml описва всички негови зависимости. Това води до автоматизация и унифицирано тестване. Не е необходимо да се съсредоточава върху детайлите за изпълнение.

Системата за доставка

Източник на изображението: https://cdn-images-1.medium.com/max/800/0*DC5Ubn7Y5seJPeSO.

Местоположението и времето за инсталиране на вашия проект нямат значение. Няма разлика в коя част от цялата екосистема ще инсталирате. Резултатът от процеса на инсталиране винаги ще бъде един и същ. Най-важното е „безсилието“. От ваша страна посочете променливите, които контролират инсталацията.

За всичко това има алгоритъм. Нека го изброяваме поетапно.

(1) Събирайте изображения от Dockerfiles.

(2) Използвайте мета-проект за доставяне на изображенията. Те трябва да бъдат доставени Kubernetes чрез Kube API. Необходимите входни параметри са:

(a) Крайна точка на API на Kube

(б) Таен обект, различен в различни контексти (местен / шоурум / постановка / продукция)

Имена на системи и тагове на изображенията на Docker за тези системи.

Например, помислете за мета-проект, състоящ се от всички системи и услуги. Това означава, че проектът описва подредбата на екосистемата и също така описва как се доставят актуализации към нея. За това ще използвам игрални книги Ansible за интеграция с API на Kube. Но има и други опции! Като цяло трябва да мислите в централизирана посока за управление на архитектурата. След като се уверите в него, можете удобно да управлявате услугите / системите.

Инсталирането на среда е необходимо в изложбения салон (за ръчни проверки и отстраняване на грешки в системата), поставяне (за близки до живи среди и интеграция) и производство (действителната среда за крайния потребител).

Непрекъсната доставка и интеграция

Вие сте щастлив човек, ако следвате унифициран начин за тестване на Docker изображенията. Той ще ви помогне безпроблемно да интегрирате функция-клон във възходящия или главния клонове на git хранилището. Единственото нещо, за което трябва да се внимава, е да се поддържа последователността на интеграция и доставка. Ако няма издания, как бихте предотвратили „състоянието на състезанието“ в една система с няколко паралелни клона на функции?

И така, какво е решението? Процесът трябва да започне, когато няма конкуренция.

Стъпките:

(1) Актуализирайте клона на функцията до поток.

(2) Изграждане на изображения.

(3) Тествайте вградените изображения.

(4) Стартирайте и изчакайте, докато стъпка 2 приключи и изображенията се доставят.

(5) Ако стъпка 4 не успее, върнете екосистемата до предишната стъпка.

(6) Комбинирайте функция-клон във възходящия поток. Изпратете го в хранилището.

Ако някоя от горните стъпки се провали, процесът на доставка незабавно се прекратява. Задачата се връща на програмиста, докато не бъде решена. Същият процес може да работи с повече от едно хранилище. Всяка от стъпките трябва да се извърши по подобен начин, но за всяко хранилище. Например, стъпка 1 за хранилище A и стъпка за хранилище B и т.н.

Kubernetes ви дава свободата да разгърнете актуализации на части. Множество тестове за АБ могат да се разгърнат и да се подложат на анализ на риска. Kubernetes разделя вътрешно услуги и приложения.

Системите за връщане

От някои от най-важните способности на силна архитектурна рамка, една е възможността за връщане назад. Има редица явни и неявни нюанси. Нека да ги разгледаме:

(1) Услугата трябва да бъде в състояние да настрои своята среда и също така да се върне обратно.

(2) Ако отмяната не е възможна, услугата трябва да бъде полиморфна. Той трябва да поддържа както старата, така и новата версия на кода.

(3) Трябва да има обратна съвместимост за всяка услуга след връщането.

В клъстер Kubernetes е лесно да се върнат състояния. Но той ще работи само ако вашият мета-проект съдържа информация за тази моментна снимка. Сложните алгоритми за връщане на доставка са обезкуражени, но са необходими.

Така че при какви обстоятелства трябва да се задейства механизмът за връщане?

(1) Когато процентът грешки в приложението е висок след пускането.

(2) След като започнете да получавате сигнали от ключови точки за наблюдение.

(3) Когато тестовете за дим се провалят.

(4) Може да се направи ръчно.

Мерки за сигурност

Направата на екосистема без броня не е лесно. Това не може да стане само като следвате един работен процес. Архитектурната рамка трябва да бъде достатъчно сигурна, за да се справи с всякакви проблеми. Kubernetes предлага някои добри вградени механизми за контрол на достъпа, мрежови политики, одит на събития и др. Има някои инструменти за информационна сигурност и те се оказаха отлични по отношение на защитата.

Следващата стъпка, от работните процеси за развитие до архитектурата

Архитектурната рамка, която предлага гъвкавост, мащабируемост, наличност, надеждност, защита срещу заплахи и т.н., е почти задължителна. Това е решаващо нещо. Всъщност тази нужда доведе до нова концепция. Някакви предположения? Да, DevOps. Това доведе до цялостната концепция за инфраструктура за автоматизация и оптимизация.

Сега беше време да променим архитектурата от Monolithic в Microservices. Той предлага огромни предимства на ориентирана към услуги архитектура. Поне за Докер и Кубернети е идеологически погрешно да се използва монолитна архитектура. Със сигурност ще обсъдя някои точки от архитектурата на микросервизите. За задълбочени познания за DevOps, моля, прочетете тази статия за DevOps.

Сега бързо ще обсъдим основните критични компоненти и решенията на добра архитектура.

Критичните компоненти

Номер 1- Служба за самоличност:

Микросервизът за идентичност се отнася до „идентичността като микросервиз“. Услугите са леки. Той осигурява модулност и дава възможност за гъвкавост на приложението. Микросервисът за самоличност е мощен и има достъп до всички данни на профила. Той е в състояние да предостави всичко необходимо в основата на всички приложения.

Ако искате да сте клиент на големи корпоративни платформи като IBM, Google, Microsoft и т.н., достъпът ще се обработва от услугите на продавача. Но какво ще стане, ако искате вашето собствено решение? Списъкът в предстоящия раздел ще ви помогне да го решите.

Номер 2- Автоматичното предоставяне на услуга:

Изградените услуги са независими една от друга. Това води до лесно развитие и по-малко грешки. Той също така помага при търсене на други услуги в динамичен и автоматизиран модел.

Kubernetes намалява необходимостта от допълнителни компоненти. Но все пак човек трябва да автоматизира добавянето на нови машини. Ето списък с инструменти:

(1) KOPS - Помага да инсталирате клъстер на AWS или GCE.

(2) Teraform - Помага за управление на инфраструктурата за всяка среда.

(3) Отговор - Предлага автоматизация от всякакъв вид.

Аз лично препоръчвам Ansible, защото ви помага да работите и с двата сървъра, както и с обектите на Kubernetes.

Номер 3- Git хранилище и проследяване на задачи:

С хранилищата на Git задачите могат да се справят лесно. Основната идея е да имате малко хранилище. Той служи за проследяване на околната среда. Съдържанието включва какъв тип версии да се използват за различни услуги. Предпочитаната система за контрол на източника за това е „git”.

Трябва да има подходящо работно място за работа в екип и съхранение на код за всички важни дискусии. Ако искате безплатна услуга, отидете за Redmine. Друго, Джира е платена услуга и е доста полезна. За хранилището с кодове Gerrit е чудесен избор, безплатно!

Номер 4- Регистърът на Докер:

Докер регистърът е вид система за съхранение и доставяне на съдържание. Той съдържа името на Docker изображенията и е достъпен в различни маркирани версии. За да взаимодейства с регистър, потребителят трябва да задейства командите за натискане и изтегляне.

Системата за управление на изображения на докер е доста важна. Системата също трябва да поддържа достъп за потребители и група потребители. За това изберете облачно решение или някаква частна хоствана услуга. Добър вариант е Vmware Harbour.

Номер 5- CI / CD и доставка на услуги:

Само непрекъснатата интеграция и услугата за доставка свързват компонентите, обсъдени по-рано. Постоянната доставка се отнася до това, че услугата е проста и лишена от всякаква логика. CI / CD услугата трябва да реагира само на събития от външния свят като промени в git хранилището и т.н.

Интеграционната услуга е отговорна за автоматичното тестване на услугата, доставката на услуги, отстъпването, премахването на услугата и изграждането на изображения.

Номер 6- Събиране и анализ на дневника:

Във всяко приложение за микросервиз проследяването на проблема е важно. Проследяването е възможно с помощта на регистрация. Така че регистрирането и наблюдението ви дават цялостен поглед върху системата.

Дневниците се правят достъпни чрез записването им в STDOUT или STDERR на кореновия процес. Данните от дневниците трябва да са достъпни, когато е необходимо. Той трябва да съдържа и записи от миналото.

Номер 7- Проследяване, наблюдение и предупреждение:

Инструменти като Opentracing и Zipkin ви помагат да разберете грешката. Като къде се объркахте? Тези инструменти ще ви помогнат да отговорите на подобни въпроси. Провалите се случват и проследяването им е важно.

Освен това мониторингът е разделен на три нива. Това са физическо ниво, ниво на клъстери и ниво на обслужване. Няма възможност за грешки при мониторинга. Инструменти като Prometheus и OpsGenie се оказаха много полезни за наблюдение. OpsGenie също сигнализира и уведомява за проблеми на всички нива. Така че проследяването, мониторинга и сигналите никога не трябва да се вземат леко. Те са защитната част на приложението.

Номер 8- API шлюз с единичен вход:

В микросервизите всички обаждания трябва да преминават само през шлюза на API. Той помага да се поддържа сигурността. Той е отговорен и за маршрутизиране на заявките за API. Така Gateway API е входна точка за всички съответни микросервизи. Единичното влизане се отнася до сесия. Това е някакъв вид услуга за удостоверяване на потребителя. Според името, идентификационните данни за вход се задават веднъж или еднократно. След това може да се използва за достъп до множество приложения.

Човек се нуждае от надеждна услуга за обработка на задачи като упълномощаване, удостоверяване, регистрация на потребители, еднократно влизане и т.н. Услугата се интегрира с шлюза на API и всичко се обработва чрез него.

Номер 9 - Автобусът за събития:

Ако екосистемата има стотици услуги, с тях трябва да се работи внимателно. Междусъобщителната комуникация е задължителна и няма възможност за грешки. Потокът от данни трябва да бъде рационализиран. Шина за събития се отнася до добре насочен поток от събития от едната микрослужба към другите.

Номер 10 - Бази данни и актуални услуги:

В приложение, базирано на микросервиз, обикновено има многобройни услуги. Изискванията за съхранение на данни за всички са различни, според ролите на услугите. Така че някои услуги са добри с релационна база данни, а други може да се нуждаят от база данни NoSQL като MongoDB.

Докер е променил правилата на играта. Базата данни заема централното важно значение в света на съхранението. Така че каквото и да е решението, то трябва да може да работи в среда на Kubernetes с лекота.

Обратно към реалността, от архитектурата към реалния живот

Ще бъда съвсем откровен с вас в споделянето на моите възгледи. Вярвам, че в бъдеще цялата архитектура ще се счита за провал. Принципите на дизайна, основите и т.н. всичко се променя! Но трябва да останете на върха на играта. За това се интегрирайте в професионалната общност. Рано или късно ще трябва да се адаптирате към тези промени. Тогава защо да не започна сега самият?

Има много възможности, но само ако се актуализирате с новите технологични актуализации.

Сега се връщаме към заглавието на тази статия. Докер и Кубернети имат най-добрата архитектура? Засега със сигурност „Да“. Но това може би е най-добрата архитектура засега. Стремете се към повече, стремете се да изградите по-добра архитектура, по-добра от най-добрата!

Споделям няколко полезни връзки с всички вас.

Статия за Docker: Урок за Docker: Контейнери, виртуални машини и докер за начинаещи

Docker Video Tutorial: Docker Video Tutorial Series

Статия за Kubernetes: Библията на Kubernetes за начинаещи и разработчици

Kubernetes Video Tutorial: Kubernetes Video Tutorial Series