Prometheus. From Metrics To Insight

Prometheus  - моніторингова система з відкритим вихідним кодом,  була створена та розроблялась в компанії Soundcloud з 2012, а в 2015 році представлена публічно і наразі розвивається незалежно.

Переважно написана на мові Go колишніми співробітниками компанії Google. Прототипом Prometheus виступала моніторингова система Borgmon. Ця моніторингова система має наступні переваги/недоліки/особливості:

• багатовимірну модель даних, з часовими рядами, що ідентифікуються назвою метрики та парою ключ/значення;
• гнучку мову запитів, що використовує цю модель;
• pull-модель роботи серверу, збирання даних відбувається опитуванням вузлів, що моніторяться, по протоколу HTTP (хоча існує також Pushgateway, що працює по push-моделі і призначений для збирання метрик з недовговічних вузлів);
• відсутність залежності від розподілених віддалених сховищ; кожен вузол Prometheus є автономним;
• об'єкти моніторингу можуть додаватись вручну до основного конфігураційного файлу Prometheus чи автоматично через service discovery (Consul, API/теги AWS, GCP, Kubernetes, Openstack та інші).

Як вже було згадано, Prometheus - це моніторингова система, що працює за pull-моделлю. Тобто сервер опитує власноруч кожен вузол, що потребує моніторингу. На думку авторів проекту, така модель дещо краща за push-модель (коли метрики відправляються самостійно на сервер моніторингу без жодних запитів). Чудовим прикладом останньої є Sensu, про яку я вже писав декілька років тому.

Kubernetes. Part VI: Setup HA Master Cluster on AWS With Kops

Раніше я вже робив огляд актуальних способів установки Kubernetes та описував досить детально його установку через Kubeadm і Kubespray. Цього ж разу мова піде про інший метод установки кластеру високої доступності - Kops.

Kops (Kubernetes Operation) - це програмне забезпечення написане на мові Go, що дозволяє вирішувати проблеми установки та обслуговування кластеру Kubernetes. Серед його особливостей та переваг можна відзначити наступні:

• Підтримує установку кластерів для cloud-платформ AWS, GCE (beta статус), DigitalOcean (зі значними обмеженнями), VMWare Vsphere (alpha статус).
• Здатний інсталювати кластери високої доступності (HA), може налаштовувати мульти-майстер конфігурації з урахуванням можливостей та сервісів cloud-платформ. 
• Підтримує ідемпотентність операцій над кластером; перед застосуванням змін здатен інформувати, що саме буде змінено (dry-runs).
• Опис інфраструктури може зберігати в Terraform темплейтах чи CloudFormation.
• Підтримує установку додатків Kubernetes (Dashboard, EFK, Prometheus Operator, Ingress і інші). У свою чергу вони можуть бути дещо змінені задля кращої інтеграції з функціоналом cloud-платформи.
• Налаштування зберігає в форматі YAML.
• Підтримує 8 різних плагінів для опису оверлейної мережі pod-to-pod/pod-to-service (CNI Networking)

Як і Kubespray, для установки та налаштування кластеру "під капотом" Kops використовує Kubeadm. Якщо ж існують плани в недалекому майбутньому мігрувати з AWS на інші платформи (в т.ч. baremetal) можливо ліпше буде одразу інвестувати час в Kubespray, адже це набір Ansible-ролей, котрі, за необхідності, відносно легко відредагувати під власні потреби. Знову ж, він підтримує значно обширніший список підтримуваних платформ.

1. PREREQUIREMENTS

Для того щоб перейти до установки Kubernetes кластеру спочатку необхідно встановити awscli та kops. Перший розповсюджується як python-пакет, котрий із легкістю можна встановити через pip:

$ pip install awscli --upgrade --user

$ aws --version
aws-cli/1.15.37 Python/3.6.3 Linux/4.13.0-43-generic botocore/1.10.37

OpenLDAP Server. Part II: FusionDirectory LDAP Browser

Нещодавно я оновив статтю про установку та налаштування OpenLDAP серверу, де також торкнувся теми підвищення безпеки інсталяції та використання панелі адміністрування phpLDAPadmin. Цього ж разу я хочу приділити увагу іншій веб-інтерфейсу FusionDirectory.

FusionDirectory - програмний комплекс, що забезпечує зручне управління даними в LDAP-каталозі. Це форк проекту Gosa², який відбувся в 2011 році через обмежений доступ до коду та процесу розробки оригінального продукту. Таким чином FusionDirectory хотів залучити в проект сторонніх розробників та покращити документацію.

У 2010 році Gosa² була обрана як фронтенд управління LDAP інфраструктурою німецького міста Мюнхен у межах проекта LiMux. На жаль, проект планують згорнути до 2020 на користь продуктів компанії Microsoft. Та і самій Gosa² пощастило не більше: останній реліз датується 2012 роком, хоча варто визнати, що пакети для її установки і досі присутні в офіційних репозиторіях Ubuntu.

1. INSTALLATION

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

# apt install make
# cpan -i Archive::Extract

На відміну від Gosa², останні пакети FusionDirectory не присутні в стандартних репозиторіях Ubuntu, тому необхідно додати сторонні:

# cat << EOF > /etc/apt/sources.list.d/fusiondirectory.list
# FusionDirectory
deb http://repos.fusiondirectory.org/fusiondirectory-current/debian-wheezy wheezy main
deb http://repos.fusiondirectory.org/fusiondirectory-extra/debian-jessie jessie main
EOF

Kubernetes. Part IV: Setup HA Cluster With Kubespray

Kubespray (раніше Kargo) - це набір Ansible ролей для установки та конфігурації системи оркестрації контейнерами Kubernetes. У якості IaaS-у в цьому випадку може виступати AWS, GCE, Azure, OpenStack чи звичайні віртуальні машини. Це проект з відкритим вихідним кодом та відкритою моделлю розробки, тому за бажанням кожен може вплинути на його життєвий цикл.
Нещодавно я писав про інсталяцію Kubernetes за допомогою Kubeadm, але в цьому способі є значні недоліки: він і досі не підтримує мультимайстер конфігурацій та, часом, є не дуже гнучким. Kubespray, хоч і використовує Kubeadm під капотом, вже має функціонал забезпечення високої доступності як для майстра, так і для etcd на етапі інсталяції. Про його порівняння із іншими методами установки Kubernetes можна почитати за наступним посиланням https://github.com/kubernetes-incubator/kubespray/blob/master/docs/comparisons.md

У цій статті ми створимо 5 серверів на ОС Ubuntu 16.04. У моєму випадку їх перелік наступний:

192.168.20.10  k8s-m1.me
192.168.20.11  k8s-m2.me
192.168.20.12  k8s-m3.me
192.168.20.13  k8s-s1.me
192.168.20.14  k8s-s2.me

Додаємо їх до /etc/hosts всіх вузлів, в тому числі локальної системи, або ж до dns-серверу. Фаерволи та інші обмеження в мережі цих вузлів мають бути деактивовані. Окрім цього, має бути дозволений IPv4 forwarding та кожен із хостів повинен мати вільний доступ до мережі Інтернет задля завантаження docker-образів.

Копіюємо публічний rsa-ключ до кожного серверу зі списку:

$ ssh-copy-id ubuntu@server.me

Вказуємо необхідного користувача та ключ для підключення з локальної машини:

$ vim ~/.ssh/config
...
Host *.me
    User ubuntu
    ServerAliveInterval 60
    IdentityFile ~/.ssh/id_rsa

Де ubuntu - користувач, від імені якого буде відбуватись підключення до сервера, id_rsa - приватний ключ. Більш того, цей користувач потребує можливості виконувати команди sudo без паролю.

Клонуємо репозиторій Kubespray:

$ git clone https://github.com/kubernetes-incubator/kubespray.git

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.

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

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.