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

4. Керування розгортанням проекту

4.1. Перевірка доступних збірок.

Вище було описано, що застосунки CF розгортаються з сирцевого коду з використанням готових збірок (Buildpack). На основі цих збірок та коду формується droplet, який запускається в контейнерах Garden віртуальних машин Diego Cell. Доступні збірки можна перевірити з CLI.

У командному рядку введіть (рис.11):

cf buildpacks

Використовуючи команду cf app, дізнайтеся на основі якої збірки створений ваш застосунок Node-RED.

4.2. Процедура розгортання застосунків CF та перегляд журналів роботи.

Процедура розгортання застосунку складається з наступних етапів (див. рис.12) :

У командному рядку розробник входить до каталогу, що містить вихідний код програми, і використовує інтерфейс командного рядка Cloud Foundry для видачі команди push.
CL CLI повідомляє Cloud Controller, що необхідно створити запис для застосунку.
Cloud Controller зберігає метадані застосунку (application metadata). Метадані застосунків можуть включати в себе назву програми, кількість екземплярів, вказаних користувачем, і buildpack та іншу інформацію про застосунок.
Перш ніж завантажувати всі вихідні файли програми, cf CLI видає до Cloud Controller запит на відповідність ресурсу, щоб визначити, чи існує який-небудь з файлів застосунку в кеші ресурсів. Якщо файли застосунків завантажуються, cf CLI пропускає файли, які існують в кеші ресурсів, надаючи результат запиту на відповідність ресурсу. Файли завантажених програм об'єднуються з файлами з кешу ресурсів для створення пакета застосунку(application package).
Cloud Controller зберігає application package в blobstore.
cf CLI видає команду запуску програми.
Cloud Controller видає запит на постановку (staging) в Diego, який потім планує (шедулить) Diego cell ("Cell"), щоб виконати здачу постановки ("Task"). Задача завантажує збірки (buildpacks) та кеш-код buildpack застосунку, якщо вони є. Потім він використовує buildpack, який виявляється автоматично (за структурою сирцевого коду) або задається за допомогою прапора -b, для компіляції та стадії програми.
Cell направляє вихідні дані процесу постановки, щоб розробник міг усунути неполадки, що виникають у застосунку.
Задача пакує отриманий скомпільований застосунок в архів, який називається “ droplet ”, а Cell зберігає droplet в blobstore. Задача також завантажує кеш buildpack до blobstore для використання під час наступної постановки (staged) зстосунку.
Система Diego Bulletin Board System повідомляє Cloud Controller, що проходження завершено (staging is complete). Постановка (Staging) повинна завершитися протягом 15 хвилин або постановка вважається невдалою. Застосунку надається мінімум 1 Гб пам'яті, навіть якщо потрібна оперативна пам'ять менша.
Дієго планує (шедулить) додаток як довготривалий процес (Long Running Process) на одній або декількох Diego cells.
Diego cells повідомляють про стан застосунку до Cloud Controller

Детально процедура описано за цим посиланням.

На кожній стадії застосунок і служби можуть формувати повідомлення в журналі. Для перегляду журналу скористуйтеся командою:

cf logs app_name -- recent

де app_name – ім’я застосунку Node-RED

Якщо після попереднього використання застосунок переходив у режим sleep (про це мало повідомлятися поштою), і він знаходиться в режимі помилки, в журналі буде висвітлено причину помилки. Наприклад,

OUT Exit status 1 (out of memory)

При правильному повторному розгортанні, ця помилка буде виправлена.

4.3. Завантаження коду Node-RED Starter в локальну папку

Кнопка створення «Node-RED IBM Cloud Starter Application», якою Ви користувалися для створення застосунку в частині 3.1 лабораторної роботи містить таке посилання

https://bluemix.net/deploy?repository=https://github.com/knolleary/node-red-bluemix-starter.git

Це посилання розгортає застосунок з сирцевого коду, що розміщується на github. Коли Ви натискаєте кнопку, то IBM Cloud вибирає код з цього сховища і робить його розгортання. При цьому автоматично створюється екземпляр служби Cloudant, який прив’язується застосунку.

Код застосунку можна завантажити з github і залити з використанням команд CLI.

Завантажте та розархівуйте з github код застосунку bluemix-starter https://github.com/knolleary/node-red-bluemix-starter (“clone or download” -> “download zip”). Подивіться на структуру каталогу проекту.

Зокрема в файлі «\.bluemix\pipeline.yml» вказана стадійність розсортування.

Деталі доступні за наступними посиланнями:

4.4. Робота з файлом маніфесту

Для розгортання застосунків використовується інструмент інтерфейсу командного рядка Cloud Foundry (див. CLI) командою cf push. cf push розгортає програми з типовою кількістю екземплярів, обмеженням дискового простору та обмеженням пам'яті. Ви можете перевизначити значення за замовчуванням, викликавши cf push з прапорами та значеннями, або вказавши пари ключ-значення в файлі маніфесту manifest.yml. Маніфести забезпечують узгодженість і відтворюваність, а також допомагають автоматизувати розгортання програм. Детальний опис доступний за посиланням.

При першому розгортанні Node-RED Starter, створюється сервіс Cloudant та БД, ім’я якої визначається за назвою застосунку. Це визначено в файлі pipeline.yml, який вказує IBM в якому порядку що створюється. Враховуючи що в назві застосунку можуть бути великі літери, які не дозволені в назві БД, база даних за замовчуванням може отримати назву «nodered». У цьому випадку, при повторному розгортанні застосунок не зможе знайти БД, тому її назву треба прописати в файлі маніфесту через поле NODE_RED_STORAGE_DB_NAME, так як застосунок шукає її саме в цій змінній середовища.

Відкрийте у завантаженій папці проекту файл маніфесту manifest.yml. Добавте в файлі маніфесту (manifest.yml) запис в розділ env , в якому змінній середовища NODE_RED_STORAGE_DB_NAME вказується ім’я бази даних в Cloudant, яка відповідає з Node-RED (наприклад nodered), а також три дефіса на початку («---»). Перед «NODE_RED_STORAGE_DB_NAME» треба зробити чотири пробіли. Зміни краще робити за допомогою редактору Notepad++.

---

applications:

- memory: 256M

env:

OPTIMIZE_MEMORY: true

NODE_RED_STORAGE_DB_NAME: nodered

command: node index.js --settings ./bluemix-settings.js –v

Після внесення змін необхідно зберегти файл.

4.5. Повторна відправка та перебудова застосунку.

Увага! Даний пункт виконується тільки при невдалому повторному запуску застосунку Node-RED!

Запустити командний рядок (cmd) в ньому:
- перейти на папку з завантаженим проектом, наприклад у Windows

cd c:/node-red-bluemix-starter

- вказати api endpoint, де знаходиться застосунок, якщо цього не зроблено, у нашому випадку:

cf api https://api.eu-gb.bluemix.net

- визвати команду реєстрації в хмарі, якщо цього ще не зроблено

cf login

- вказати пошту та пароль (пароль вводиться без явного відображення символів)
- зробити push проекту, вказавши ім’я Вашого екземпляру Node-RED, наприклад app_name

cf push app_name

2. Якщо в кінці розгортання з’явиться запис «FAILED», це значить що якась процедура зроблена невірно і треба повторити спробу. У випадку вдалого розгортання перевірити роботу Node-RED.

Короткий опис послідовності повторного розгортання доступний за цим посиланням.