Наступний малюнок відображає рівень абстракцій, з якими необхідно буде працювати конкретному розробнику. Всі інші рівні будуть обслуговуватись власним відділом адміністрування (якщо cloud платформа встановлена на власному залізі) або ж третьою стороною, на зразок IAAS-провайдера Amazon Web Services чи Google Cloud Platform.
Одного разу я вже писав про IAAS/PAAS-платформу Mesos/Marathon, про її особливості та переваги, а цього разу я пропоную познайомитись з хмарною платформою Cloud Foundry.
Cloud Foundry - вільне програмне забезпечення, розробкою якого з 2009 року займалась компанія VMware, а наразі - Pivotal. Код Cloud Foundry був відкритий в 2011 році і на сьогодній час курується організацією Cloud Foundry Foundation (Linux Foundation Collaborative Project).
Сloud Foundry можна встановити на одну із IAAS-платформ, що офіційно підтримується: AWS, VMware vSphere, OpenStack та ін. Власні комерційні PAAS-рішення на основі Cloud Foundry пропонують HPE (Stackato), IBM (Bluemix), Huawei (FusionStage), Pivotal та ін. Для потреб розробників можна звісно встановити увесь стек локально, використавши напрацювання Bosh Lite чи PCF Dev.
Перед тим, як переходити до практичної частини, опишемо основні підсистеми платформи Cloud Foundry:
• Router. Направляє вхідні запити до віртуальних машин, що обслуговують кожний конкретний додаток, зазвичай працює з клієнтськими балансувальниками навантаження на кшталт HAproxy, Nginx, F5. Періодично роутер опитує інші підсистеми для отримання інформації у яких відсіках (cell) і контейнерах наразі працюють додатки і, на основі цих даних, вже будує оновлену таблицю маршрутів до всіх користувацьких контейнерів. Інфраструктура CF може мати декілька роутерів для підвищення рівня доступності системи.
• User Account and Authentication (UAA) Server та Login Server. Працюють разом задля забезпечення аутентифікації та авторизації користувачів Cloud Foundry. Також має інтеграцію з LDAP.
• Cloud Controller. Управляє розгортанням кінцевих користувацьких додатків. Спочатку Cloud Controller отримує вказівки на розгортання додатку від Cloud Foundry клієнта, і потім спрямовує запити на підсистему Diego Brain для координації окремого відсіку (cell) Diego для запуску додатку. Раніше ці ж завдання виконувала підсистема DEA (Droplet Execution Agent).
• Nsync, BBS та Cell Reps. Для підтримки додатків в робочому стані, їх стан має постійно моніторитись. До Diego цю роль виконувала підсистема Health Manager (HM9000). Nsync, BBS, and Cell Reps використовують більш розподілений підхід для вирішення цієї проблеми.
Як же nsync, BBS, and Cell Reps працюють разом? Спочатку nsync отримує повідомлення від Cloud Controller, коли користувач масштабує додаток. Нове значення кількості інстансів записується до змінної DesiredLRP структури бази даних Diego BBS. Остання в свою чергу порівнює значення DesiredLRP із значенням ActualLRP (кількість інстансів додатку, що вже запущені) і, в залежності від значення останньої величини, буде піднято додаткові або знищено зайві інстанси додатку. Cell Reps же моніторить контейнери для отримання актуальних значень ActualLRP.
BBS окрім сказаного вище відповідає за надання API до Diego Core компонентів, слідкує за тим чи всі повідомлення було надіслано до системи логування та інше.
• Blobstore. Це репозиторій (сховище) великих бінарних об’єктів. Його можна поділити на такі підсистеми:
- Application code packages. Код користувацьких додатків, що запущені в системі.
- Buildpacks. Фреймворки та набір програмного забезпечення, що необхідний для роботи додатків. Наприклад, є окремий buildpack для запуску python-програм (з підтримкою бібліотек фреймворків Flask, Django), PHP-аплікацій і т.п. З переліком офіційних buildpack-ів можна ознайомитись за наступним посиланням https://docs.cloudfoundry.org/buildpacks/#system-buildpacks
- Droplets. Продукт пакування відповідним buildpack-ом, котрий складається із самого додатку та набору програм (наприклад, необхідні бібліотеки), що забезпечує його запуск. У випадку програм на компілюємих мовах в droplet буде вже потрапляти готовий бінарник. Надалі droplet надсилається до Cloud Controller для виділення йому місця запуску та необхідних потужностей.
• Diego Cell. Вузли, на яких фізично знаходяться контейнери додатків, що працюють. Також сервіси Diego Cell моніторять роботу додатків та рапортують про їх стан підсистемі BBS та Loggregator-у. Раніше інстанси DEA виконували ці ж задачі і їх вузли називались Runner.
• Warden (DEA)/Garden (Diego) контейнер. Кожен додаток знаходиться в окремому контейнері, щоб якомога менше впливати на роботу сусідів-додатків. Контейнер CF, як і всі інші, працює на технологіях ядра Linux. Цим контейнером управляє DEA/Diego через API контейнера. Garden, на відміну від Warden, це інтерфейс для підключення бекендів, і, як наслідок, він не привязаний лише до одного типу контейнеризації (в т.ч. єдиної ОС в контейнері). Наразі Garden використовує Garden-runC бекенд по-замовчуванню, котрий підтримує контейнери формату OCI (Open Container Interface). Ця додаткова стаття також може бути корисною https://content.pivotal.io/blog/cloud-foundrys-container-technology-a-garden-overview
• Service Brokers/Services. Зазвичай кожен додаток потребує для своєї роботи базу даних чи доступ до сторонніх постачальників SaaS послуг. Цей доступ реалізується за допомогою Open Service Broker API, котрий розроблюється групою компаній в т.ч. і для інших PaaS/IaaS-рішень. Тобто якщо користувацький додаток потребує для своєї роботи базу даних, Cloud Foundry надає її при умові якщо її сервіс доступний (установлений і коректно налаштований). Брокер сервісу обслуговує і адресує запити кожного додатку до кінцевого інтсансу сервісу.
• Messaging (Consul та BBS). Компоненти Cloud Foundry підтримують зв’язок між собою за допомогою HTTP та HTTPS протоколів. Сервер Consul відповідає за більш довговічні дані на кшталт IP-адрес та розподілених блокувань. Коли ж сервіс BBS (Bulletin Board System) зберігає недовговічні, одноразові дані, такі як статус роботи додатку та його відсіку. BBS зберігає свої дані у внутрішній MySQL-базі.
У свою чергу route-emitter компонент використовує NATS протокол для широкомовної передачі інформації щодо таблиці маршрутів до роутерів. До Diego вся ця роль лягала на плечі шині NATS, що відповідала за всі внутрішні комунікації між компонентами Cloud Foundry.
• Loggregator/Metrics Collector. Тут все однозначніше. Loggregator показує потік логів додатку, а Metrics Collector збирає метрики та статистику з усіх компонентів.
Основна документація до архітектури Diego пропонує наступну блок-схему:
Тут краще видно як компоненти взаємодіють разом та з яких компонентів складається кожна підсистема.
Ознайомившись з базовими сервісами Cloud Foundry, розглянемо як відбувається деплой додатків. Я вірю, це додасть більше ясності в роботі CF. Почнемо зі старої архітектури DEA, котра і досі використовується в деяких інсталяціях:
1. Розробник з директорії з підготовленим для деплою коду, використовуючи командний інтерфейс Cloud Foundry (cf CLI), запускає команду cf push.
2. cf CLI запитує створення запису для додатку в підсистемі Cloud Controller.
3. Останній, в свою чергу, записує метадані додатку (ім’я додатку, кількість інстансів, та тип білдпаку). Ці дані записуються до CCDB (Cloud Controller Data Base). У якості цієї бази, у випадку DEA, використовується PostgreSQL.
4. Далі cf CLI завантажує файли додатку до підсистеми Cloud Controller. Попередньо cf CLI через Cloud Controller перевіряє чи їх ще немає в кешах і, за необхідності, лише довантажує зміни.
5. Cloud Controller передає ці файли на збереження до Blobstore сховища.
6. cf CLI інтерфейс надсилає команду запуску додатку до Cloud Controller-а.
7. Cloud Controller обирає DEA-staging інстанс серед пулу доступних інстансів для створення droplet-у додатка, для чого він використовує інструкції білдпаку.
8. Процес створення droplet-у логується і відображається в cf CLI.
9. DEA-staging інстанс надсилає готовий droplet на зберігання до blobstore-у. При кожному наступному запуску цього ж додатку буде вже використовуватись ця готова версія.
10. DEA-staging інстанс повідомляє Cloud Controller, що процес пакування droplet-у завершений.
11. В свою чергу Cloud Controller обирає один чи декілька інстансів DEA-running для запуску цього ж droplet-у додатка.
12. Інстанс DEA-running рапортує про статус додатка до Cloud Controller-а.
Тепер розглянемо деплой додатків в новій архітектурі Diego (DEA-Go, DEA переписаний на мові Go), на яку вже мігрували деякі вендори:
Не буду вдаватись в подробиці, адже загалом логіка подібна. Деякі пункти тут описуються детальніше, але загалом все дуже подібно до деплою додатків в DEA:
1-6. Пункти аналогічні з DEA. Окрім того, що у якості CCDB використовується MySQL.
7. Так як droplet додатку ще не було попередньо створено, Cloud Controller через CC-Bridge наказує підсистемі Diego його створити.
8. Diego, використовуючи аукціон-алгоритм (підсистема Diego Brain), обирає відсік (Cell) для створення droplet-у і відсилає на нього задачу.
9. Обраний cell використовує інструкції у відповідному для додатку buildpack-у, завантажує необхідні дані з файлсерверу Diego і запускає задачу на створення droplet-у додатку.
10. Процес створення droplet-у відображається в консолі розробника.
11. Droplet завантажується до Blobstore.
12. Diego рапортує Cloud Controller, що задача завершена, і останній, в свою чергу, записує оновлені метадані до CCDB.
13. Cloud Controller, через підсистему CC Bridge, ініціює запуск droplet-а в Diego.
14. Останній, використовуючи аукціон-алгоритм, обирає відсік для запуску постійно працюючого процесу (LRP).
15. Відсік (Cell), що вже працює, завантажує droplet додатку з репозиторію Blobstore.
16. Потім цей же Cell завантажує бінарні файли з Diego файлсерверу і використовує їх для створення відповідного контейнера, а після і запуску droplet-у додатка.
17. Diego рапортує про статус роботи додатку до Cloud Controller, котрий час від часу отримує інформацію щодо інстансів, що працюють, чи інформацію щодо будь-яких аварійних подій.
18. Логи додатку прямують від відсіку (Cell) до підсистеми Loggregator (напряму, не через CC-Bridge)
Як я вже писав, Diego вміє запускати Docker-контейнери (OCI-формат) і в такому разі деплой нового додатку буде виглядати трішки іншим чином:
1-2. Пункти аналогічні з деплоєм в DEA-архітектурі та Diego Buildpack варіанті.
3. Потім запит на підняття образу контейнера додатку одразу прямує до Diego Cell (Staging етап)
4. Логи попереднього етапу направляються в консоль cf CLI.
5. Diego cell на этапі установки додатку направляє метадані, що пов'язані з Docker-образом до Сloud Controller.
6. Сloud Controller обробляє ці метадані та формує дані для створення LRP (Long Running Process), що власне і запускатиме команди, що описані в Dockerfile. Змінні оточення, описані в Dockerfile, також будуть назначені в майбутньому контейнері Garden.
7. LRP направляється на запуск до одного чи декількох Diego Cell.
8. Cloud Controller інструктує Diego та Gorouter направляти користувацькі запити до створеного додатку, що працює в контейнері.
Якщо говорити коротко, то основні відмінності/переваги Diego від/над DEA є наступні:
• Архітектура DEA в основному написана на Ruby, коли Diego - на Go, що в теорії має вплинути на швидкість роботи.
• Деякі зміни обробки запитів, функції “DEA node” інстансу наразі виконуються підсистемою “Diego cell”. Остання в свою чергу вже не являється частиною Cloud Controller-а.
• Нова система менеджменту контейнерів Garden (в DEA вона мала назву Warden). Garden дозволяє не прив’язуватись лише до єдиної ОС.
• Зміни в моніторингу доступності додатку та NATS. Health Manager було замінено на підсистеми nsync, BBS, та Cell Rep в архітектурі Diego. Про це я вже згадував вище.
• Архітектура DEA не розрізняє короткотривалі і постійні задачі. Diego ж вміє це робити і розподіляє їх на Задачі (Tasks) та Довготривалі Процеси (LRP, Long-Running Processes). Це вміння дозволяє останньому краще розміщати додатки ефективніше, використовуючи свій новий алгоритм Auction.
• В Diego-архітектурі з'явилась можливість підключатись до контейнерів додатків використовуючи SSH.
• Зміни на рівні обробки трафіку в контейнерах.
• Diego має підтримку запуску стандарту контейнерів OCI. Тобто Diego може запускати-Docker контейнери, наприклад з Docker Hub.
• Garden, на відміну від Warden, вміє відкривати декілька портів на кожен контейнер (додаток).
Це лише перша стаття циклу, надалі я планую написати ще дві про установку BOSH Lite/Cloud Foundry (DEA) та BOSH Lite/Cloud Foundry (Diego) + Docker's image integration. Маю надію, що так буде простіше ознайомлюватись із ними.
Посилання:
https://bosh.io/docs/
https://bosh.io/docs/problems.html
https://docs.cloudfoundry.org/concepts/overview.html
https://specify.io/systems/cloudfoundry/features-and-usecases
http://www.cloud-council.org/webinars/CSCC-Webinar-Cloud-Foundry-Roadmap-6-16-16.pdf
https://docs.cloudfoundry.org/concepts/architecture/
https://docs.cloudfoundry.org/concepts/diego/diego-architecture.html
https://docs.cloudfoundry.org/concepts/how-applications-are-staged.html
https://docs.cloudfoundry.org/concepts/architecture/execution-agent.html
https://docs.cloudfoundry.org/concepts/architecture/dea-algorithm.html
https://docs.cloudfoundry.org/concepts/diego/diego-auction.html
https://docs.cloudfoundry.org/concepts/diego/dea-vs-diego.html
http://cloudacademy.com/blog/cloud-foundry-components/
http://cloudacademy.com/blog/cloud-foundry-benefits/
https://dzone.com/refcardz/cloud-foundry
https://www.safaribooksonline.com/library/view/cloud-foundry-the/9781491932421/
https://www.safaribooksonline.com/library/view/cloud-foundry-the/9781491932421/ch04.html
https://de.slideshare.net/cdavisafc/cloud-foundry-technical-overview
https://de.slideshare.net/cdavisafc/lattice-meetupdenver
https://www.cloudfoundry.org/cloud-foundry-containers-difference-warden-docker-garden/
https://techcrunch.com/2016/09/19/cloud-foundry-launches-its-new-docker-compatible-container-management-system/
Немає коментарів:
Дописати коментар