Translate

понеділок, 15 травня 2017 р.

Cloud Foundry. Part III: BOSH 2 Lite/Cloud Foundry (Diego)

Декілька тижнів тому я опублікував другу статтю про PAAS-платформу Cloud Foundry, а цього разу мова піде про установку нового Cloud Foundry з Diego runtime. Нагадаю, що Diego має купу вдосконалень в порівнянні з DEA, а саме нова система менеджменту контейнерів Garden, що підтримує деплой Docker-контейнерів, новий алгоритм розміщення задач Diego Auction та інші оптимізації.

Підтримка DEA буде припинена 22 травня 2017 року, останні релізи stemcell вже не працюють з DEA, тому практичне знайомство з Cloud Foundry ліпше починати з цієї статті. Цього разу буде описана установка BOSH2 Lite (так, існує ще і друга версія), Cloud Foundry з Diego runtime.

1. BOSH 2 LITE INSTALLATION (BOSH 2 DIRECTOR)


BOSH Lite - це реліз системи виливки Cloud Foundry для системи VirtualBox. Тож останній має бути встановлений в хост-системі:

$ VBoxManage --version
5.1.22r115126

Для інсталяції BOSH 2 Lite більше не потрібен Vagrant, адже його установочні скрипти вміють працювати з VirtualBox напряму.

BOSH 2 CLI написаний на мові Go і його установка для macOS заключається в завантаженні готового бінарного файлу:

$ cd ~/Downloads
$ wget https://s3.amazonaws.com/bosh-cli-artifacts/bosh-cli-2.0.16-darwin-amd64
$ chmod +x bosh-cli-*
# mv bosh-cli-* /usr/local/bin/bosh2

$ bosh2 -v
version 2.0.16-88aa790-2017-05-02T01:12:20Z

За релізами версій BOSH2 CLI можна слідкувати за наступним посиланням https://bosh.io/docs/cli-v2.html. Там же можна завантажити останню версію BOSH2 CLI для ОС Linux.

понеділок, 1 травня 2017 р.

Cloud Foundry. Part II: BOSH Lite/Cloud Foundry (DEA)

Зовсім нещодавно я написав першу ввідну статтю про PAAS-платформу Cloud Foundry , а зараз я пропоную локально встановити та на практиці оцінити цю платформу.

Є 2 найпростіші способи спробувати Cloud Foundry на локальній системі: PCF Dev та BOSH Lite. У цій статті буде розглянуто останній варіант, як більш гнучкий, проте і складніший. У якості хост-системи буде використано macOS, але звісно з установкою на інших операційних системах проблем не має бути. У кінцевому рахунку це все рівно буде віртуальна машина VirtualBox з Ubuntu 14.04 всередині. Головне - це мати систему з мінімальною кількістю оперативної пам'яті, що рівна 8ГБ.


1. BOSH LITE INSTALLATION (BOSH DIRECTOR)


Отже, до діла. Перш за все установимо BOSH, систему, котра розгортає вузли Cloud Foundry. У випадку Lite-версії, BOSH розповсюджується у вигляді готового образу віртуальної машини, тому Vagrant та VirtualBox мають бути установлені:

$ vagrant --version
Vagrant 1.9.1

$ VBoxManage --version
5.1.18r114002

Для VirtualBox варто також проінсталювати Oracle VM VirtualBox Extension Pack, адже інакше можливі проблеми з мережею між майбутніми компонентами.

Установимо BOSH CLI клієнт, котрий розповсюджується як ruby gem-пакет:

# gem install bosh_cli --no-ri --no-rdoc

$ bosh --version
BOSH 1.3215.4.0

неділя, 16 квітня 2017 р.

Cloud Foundry. Part I: Basics

Cloud платформи дозволяють будь-кому розгортати мережеві програми чи сервіси за лічені хвилини. Більш того, вони спрощують масштабування програм для потреб обслуговування більших навантажень, завдяки ним це відбувається кількома командами. Cloud платформи дозволяють розробникам більше фокусуватись на розробці кінцевого продукту, а не на інфраструктурі, що лежить в його основі. Проте, відверто кажучи, це скоріше ускладнить життя відділу адміністрування, адже чим більше рівнів абстракцій - тим вищим рівнем кваліфікації мають володіти співробітники, що будуть її обслуговувати.

Наступний малюнок відображає рівень абстракцій, з якими необхідно буде працювати конкретному розробнику. Всі інші рівні будуть обслуговуватись власним відділом адміністрування (якщо 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.

пʼятниця, 3 лютого 2017 р.

OpenVPN Part II: Connect Two Local Networks

Декілька тижнів тому я опублікував першу статтю про програму OpenVPN, де описав декілька способів її практичного використання. Цього разу я розповім про те, як об’єднати дві різні локальні мережі, в результаті чого кожен із вузлів буде мати доступ до всіх інших вузлів обох підмереж. Звісно дуже раджу спочатку ознайомитись із першою статтею, яка надасть необхідний теоретичний мінімум.

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

 Short name  Public IP  Private IP  Network  Role
 ams1 37.139.10.10 10.129.18.182  10.129.0.0/16 SERVER
 ams2  - 10.129.20.80 10.129.0.0/16   -
 local1  - 192.168.1.10 192.168.1.0/24 CLIENT
 local2 -  192.168.1.20 192.168.1.0/24  -

Отже ми маємо два хости у підмережі 10.129.0.0/16 та два в іншій підмережі 192.168.1.0/24. ams1 (10.129.18.182) буде працювати у ролі сервера і для зовнішніх з’єднань володітиме публічною адресою 37.139.10.10 (це обов’язкова умова, якщо не враховувати можливість перебросу порта на OpenVPN-сервер). А local1 (192.168.1.10) буде підключатись до сервера у якості клієнта OpenVPN.

Установимо OpenVPN на ams1 та local1 вузлах:

# apt install openvpn

неділя, 22 січня 2017 р.

OpenVPN Part I: Setup and Configuration

OpenVPN - вільна реалізація технології Віртуальної Приватної Мережі (VPN) для створення зашифрованих каналів типу точка-точка або сервер-клієнти між комп’ютерами і може працювати як у звичайному routing, так і у bridge-режимі. Програма дозволяє створювати з’єднання навіть між вузлами, що знаходяться за NAT та мережевими екранами (фаєрволами), без необхідності їх переналаштування. OpenVPN була написана Джеймсом Йонаном (James Yonan) на мові програмування C і поширюється по ліцензії GNU GPL. Її перший реліз побачив світ в далекому 2001 році, і, на момент написання статті, актуальною є версія 2.4.

Для організації з’єднань OpenVPN використовує свій оригінальний протокол над TCP/UDP, що в свою чергу застосовує SSL/TLS для обміну ключами. Програма використовує бібліотеку OpenSSL для шифрування як корисних даних, так і сервісних, що необхідні для створення підключень і підтримки з’єднань. Остання, в свою чергу, дозволяє задіяти увесь набір алгоритмів шифрування, що доступні в бібліотеці.

Клієнти для OpenVPN існують для великої кількості операційних систем і платформ, в т.ч. мобільних та ОС для роутерів. У цьому сенсі це майже універсальне рішення.

Автентифікувати підключення OpenVPN-сервер може наступними способами:

  • За допомогою логіна та пароля із клієнтськими сертифікатами/без сертифікатів. Це забезпечується сторонніми модулями.
  • За допомогою попередньо згенерованого єдиного ключа для сервера та клієнта (PSK, тобто з’єднання встановлюється симетричним алгоритмом шифруванням).
  • Аутентифікація за допомогою сертифікатів (TLS client/server mode). Найбільш надійний варіант, адже в клієнта та сервера є свій унікальний набір ключів/серифікатів, що підписані одним центром сертифікації.

У останньому варіанті аутентифікації, сервер та клієнт мають свій ключ, випущений сертифікат та кореневий (СА) сертифікат. Для підняття рівня безпеки, клієнт також може мати додатковий пароль.

субота, 26 листопада 2016 р.

RabbitMQ Cluster. AMQP protocol

RabbitMQ - сервер черг, написаний на мові Erlang, що реалізує платформу обміну повідомленнями між компонентами програмної системи.

RabbitMQ побудований на фреймоворку Open Telecom Platform та реалізує стандарт обміну повідомленнями AMQP версії 0-9-1 (через плагіни також AMQP версії 1)

Для роботи з RabbitMQ існує багато готових бібліотек для основних мов програмування, що дозволяють без особливих надзусиль почати використовувати сервер у власній інфраструктурі.

Наразі розробкою RabbitMQ займається компанія Pivotal, що в свою чергу є підрозділом Dell. Код сервера відкритий і розповсюджується по ліцензії Mozilla Public License.

Перш за все розглянемо основні логічні одиниці, з яких складається процес роботи брокера повідомлень RabbitMQ (протоколу AMQP):
Отже, програма-генератор повідомлень (Producer) створює повідомлення і у разі, якщо в користувача, від якого вона працює, є права на їх запис у конкретний Virtual Host, повідомлення потрапляє до точки обміну (Exchange). У залежності від її типу та правил, за якою вона працює (Bindings), повідомлення записуються в черги (Queues). Далі вони відправляються до програм-споживачів (Consumers), що підписані на зміни до черг (push API), або ж останні самостійно їх забирають (pull API). У випадку push API споживачі повідомлень підписуються на зміни і, як результат, надсилають запити на реєстрацію (підписку) до черги. Кожен споживач має унікальний ідентифікатор, що зветься consumer tag. Він може використовуватись брокером для відписки останніх від черги.

середа, 2 листопада 2016 р.

Apache Kafka: Setup And Configuration

Apache Kafka - популярний сервер черг, що був створений для ефективної обробки великих обсягів даних в реальному часі. Кластер Kafka не лише гарно масштабується, але і має значно кращу продуктивність, в порівнянні з такими брокерами повідомлень, як ActiveMQ та RabbitMQ. Це зовсім не значить, що в останніх немає переваг.

Apache Kafka - це розробка компанії Linkedin, код якої було відкрито в 2011 році і пізніше переданий в інкубатор Apache. Сервер написаний на мові Scala, тож потребує Java-машину для роботи.

Що ж таке брокер повідомлень? Брокер повідомлень (сервер черг, система повідомлень) - це сервер, що відповідає за передачу даних від однієї програми (producer) до іншої (consumer). Брокер повідомлень допомагає абстрагуватись від того, як буде відбуватись обмін повідомленнями між програмами та зосередитись на написанні логіки програм, що працюють по обидва боки. Більш того, сервери черг дозволяють винести певну логіку на окремі сервери задля того, щоб основні потужності працювали швидко і без перебоїв, особливо якщо ця окрема логіка не термінова по часу виконання - щось на кшталт обробки фотографій для корисувачів і т.п. З іншого боку з брокерами повідомлень досить легко масштабувати споживачів (в т.ч. тимчасово), у разі якщо навантаження зросло чи ускладнилась логіка.
Також сервер черг корисно мати у разі, якщо програма-генератор повідомлень часом створює їх більше ніж програма-споживач може обробити, та деякі затримки у обробці цих повідомлень не є критичними. Наприклад, Rsyslog може слати логи напряму в Logstash, але якщо Rsyslog на деякий час почне генерувати їх більше, ніж останній може обробити, то Logstash може впасти, як зазвичай і відбувається. Коли ж в цю схему додати брокер Kafka між Rsyslog та Logstash, то перший буде все одразу віддавати в чергу, а останній по змозі все буде забирати з неї і обробляти. Більше того, часом Kafka-у використовують як основний лог-сервер, адже вона зберігає свої дані на диск.