ЛР3.Ч3.Основи роботи з Cloud Foundry в IBM Cloud

1. Механізми роботи застосунків Cloud Foundry в IBM Cloud

Мета: навчитись керувати застосунками Cloud Foundry в IBM Cloud.

Цілі:

розібратися з механізмами роботи застосунків Cloud Foundry в IBM Cloud
встановити та навчитися працювати з Cloud Foundry Command Line Interface CLI
розбіратися з механізмами взаємодії застосунків CF з сервісами IBM Cloud
розбіратися з механізмами завантаження стартового пакету «Node-RED Starter»
виправити проблему повторного запуску Node-RED Starter

Зовнішній вигляд інтерфейсу налаштування IBM Cloud постійно змінюється! Увага, набір наданих сервісів та політика ліцензування IBM Cloud може змінитися. У будь якому випадку, без використання угоди та реєстрації кредитної картки ніякі кошти за використання стягуватися не можуть.

1. Механізми роботи застосунків Cloud Foundry в IBM Cloud

У частині 3.1 лабораторної роботи для створення застосунку використовувалася платформа Node-RED, яка базуються на SDK Node.js. Створення застосунку проводилося з використанням стартового набору «Node-RED Starter». Це швидкий шлях створення, який не передбачає знання механізмів функціонування застосунку в хмарі, однак у нештатних ситуаціях або при необхідності тонкого налаштування застосунку все ж таки треба розбиратися в основах його функціонування. Ціль даної частини лабораторної роботи отримати базові знання про основи функціонування застосунків Cloud Foundry в IBM Cloud та про їх зв’язки з хмарними сервісами.

SDK Node.js, що використовується в «Node-RED Starter», базується на Cloud Foundry (CF), який є провідним галузевим стандартом платформи як послуги (PaaS), що забезпечує швидке, просте та надійне розгортання хмарно-орієнтованих застосунків. Це платформа з відкритим вихідним кодом, яку можна розгортати для запуску своїх застосунків як на власній обчислювальній інфраструктурі, так і на існуючих IaaS (інфраструктура як послуга), таких як AWS, vSphere або OpenStack.

Хмари балансують свої навантаження на обробку на декількох машинах, оптимізуючи ефективність і стійкість до відмови. Установка Cloud Foundry виконує це на трьох рівнях:

BOSH - це ланцюг інструментів з відкритим кодом для розробки інженерних рішень, розгортання та управління життєвим циклом широкомасштабних розподілених сервісів. Для постачальників послуг Cloud Foundry, BOSH є платформою розгортання та керування за замовчуванням. BOSH створює і розгортає віртуальні машини (VM) поверх фізичної обчислювальної інфраструктури і розгортає і запускає Cloud Foundry поверх неї. Щоб налаштувати розгортання, BOSH слідує документу маніфесту.
CF Cloud Controller запускає програми та інші процеси на віртуальних машинах хмари, балансуючи попит і керуючи життєвим циклом застосунків.
Маршрутизатор (router) направляє вхідний трафік з усього світу до віртуальних машин, які працюють з застосунками, зазвичай працюючи з балансувачем навантаження, наданим клієнтом.

Основні елементи CF показані на рис.1. Розроблені застосунки виконуються на віртуальних машинах Diego Cell. Екземпляри застосунків (Application instances), прикладні задачі (application tasks) і задачі постановки (керування стадіями розгортання, staging tasks) виконуються як контейнери Garden на віртуальних машинах Diego Cell. Контейнер – це власне автономне середовище, в якому ізолюються процеси, пам'ять та файлова система, використовуючи функції операційної системи та характеристики віртуальної та фізичної інфраструктури, де розгортається CF. Ізоляція контейнерів досягається за допомогою використання окремих просторів імен ресурсів ядра (namespace). У кожному контейнері обмежується обсяг пам'яті, яку може використовувати контейнер, і кванти часу роботи CPU, доступ до яких потрібен також іншим контейнерам. Файлова система складається зі спільної для всіх контейнерів базової файлової системи (доступна тільки для читання), та контейнеро-залежної частини (доступний для читання/запису) унікальної для кожного контейнеру, розмір якої обмежений квотами проекту. Додатково про контейнери та їх порівняння з віртуальними машинами можна прочитати за цим посиланням.

Застосунки створюються для конкретної платформи, і вихідний код для них може знаходитися як в локальному сховищі (ПК розробника) так і на GitHub чи зовнішніх сховищах. У Cloud Foundry для контролю версій вихідного коду, зборок (buildpacks), документації та інших ресурсів використовується git-система на GitHub. Однак для зберігання великих двійкових файлів, CF підтримує внутрішнє або зовнішнє блокове зберігання Blob Store. У Blobstore міститься наступне:

пакети вихідного програмного коду
Buildpacks (збірки)
Droplets

Пакети вихідного програмного коду створюються для конкретних програмних інструментів з використанням ряду мов. Зокрема, Node-RED базується на Node.js, тому пакет вихідного коду для «Node-RED Starter» розроблений з урахуванням вимог SDK Node.js. Для перетворення цього сирцевого коду в реальний застосунок використовується Buildpack. Buildpack (збірка) – це колекція коду, що відповідає за перетворення сирцевого коду застосунків в готові до запуску бінарні пакети (дроплети). Процеси, що відбуваються при такому перетворенні називаються постановкою (staging). Збірка містить всі мови, бібліотеки та служби, що використовує застосунок. Перш, ніж надсилати застосунок до віртуальної машини, контролер Хмари (Cloud Controller) перетворює її в образ, поєднуючи стек, buildpack та вихідний код у droplet, які VM може розпакувати, скомпілювати та запустити. Droplet (дроплет) – це пакет, що містить усе необхідне для успішного запуску вашого застосунку (наприклад, JRE, Liberty, сам застосунок) однак без урахування операційної системи.

Cloud Controller (Контролер хмари) керує розгортанням застосунків з коду. Процес завантаження коду застосунку в хмару називається push (пуш) надалі по тексту буде використовуватися слово «запушити». Щоб запушити код застосунку до Cloud Foundry, він спрямовується на Cloud Controller (через Router), який керує окремими комірками Diego для керування етапами та запусками застосунків. Щоб підтримувати доступність застсосунків, хмарні розгортання повинні постійно контролювати свої стани та узгоджувати їх з очікуваними станами, запускаючи та зупиняючи процеси за потребою. Компоненти nsync, BBS і Cell Rep співпрацюють разом по ланцюжку, щоб підтримувати роботу застосунків з необхідною кількістю екземплярів.

Зазвичай програми залежать від таких сервісів, як бази даних або сторонні постачальники SaaS. Коли розробник передбачає та прив'язує сервіс до застсоунку, брокер сервісу (Service Broker) для цієї служби несе відповідальність за надання екземпляру сервісу.

Маршрутизатор (router) направляє вхідний трафік на відповідний компонент - Cloud Controller, або розміщений застосунок, запущений в комірці Diego. Маршрутизатор періодично надсилає запит до системи дошки оголошень Diego (BBS), щоб визначити, в яких комірках і контейнерах зараз працює кожен застосунок. Використовуючи цю інформацію, маршрутизатор перераховує нові таблиці маршрутизації на основі IP-адрес кожної віртуальної машини (VM) і номера порту на стороні хоста для контейнерів комірки.

CF керує обліковими записами користувачів за допомогою двох серверів: автентифікації та авторизації користувачів. Для забезпечення керуванням ідентифікацією разом працюють сервери OAuth2 server (the UAA) та Login Server. Один сервер UAA надає доступ до BOSH, і має аккаунти для операторів CF, які розгортають середовище виконання, сервіси та інше програмне забезпечення безпосередньо на слой BOSH. Інший сервер UAA керує доступом до Cloud Controller і визначає, хто може йому надавати команди. UAA Cloud Controller означує різні ролі користувачів, такі як адміністратор, розробник або аудитор, і надає їм різні набори привілеїв для запуску CF-команд

Компоненти Cloud Foundry спілкуються двома способами (Messaging):

Надсилаючи повідомлення внутрішньо, використовуючи протоколи HTTP і HTTPS
Надсилаючи повідомлення NATS один одному безпосередньо

Cloud Foundry створює системні журнали з компонентів Cloud Foundry та журналів програм із розміщених застосунків. Коли працює Cloud Foundry, його компонентні та хост-віртуальні машини генерують журнали та метрики. Застосунки Cloud Foundry також зазвичай генерують журнали. Система Loggregator об'єднує метрики компонентів і журнали застосунків у структуровану, корисну форму Firehose, яку можна переглянути у будь який момент постановки.

IBM Bluemix є рішенням CF поверх IBM Cloud IaaS (рис.2). Доступ до конфігурування, керування та діагностування застосунками може відбуватися як через WEB IDE (консоль), що використовувався в частині 3.1 лабораторної роботи, так і через класичний клієнтський Cloud Foundry Command Line Interface (CLI). Доступне керування життєвим циклом застосунків через утиліти DevOps, також можлива інтеграція з Eclips IDE. В наступному пункті, для керування розгортуванням буде використовуватися утиліта CLI.