Translate

понеділок, 15 жовтня 2018 р.

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, про яку я вже писав декілька років тому.

понеділок, 16 липня 2018 р.

Terraform. Managing AWS Infrastructure

Terraform - це програма для побудови та безпечного обслуговування інфраструктури. Його основний розробник, компанія HashiCorp, представила перший реліз Terraform в 2012 році і наразі будь-хто може приєднатись до його розробки.

Ресурси в Terraform описуються як код на власній декларативній мові HCL (Hashicorp Common Language), тому він з легкістю може бути доданий до системи контролю версій на зразок Git (Infrastructure as Code). Ця особливість забезпечує зручне відслідковування змін коду, його рецензування, можливість налаштування якісного CI/CD та інше.

Terraform складається із двох основних частин: Core та Plugins. Terraform Core відповідальний за побудову графів залежності ресурсів, плану їх створення чи зміни та, за допомогою протоколу RPC, комунікує із плагінами. У свою чергу Terraform Plugins - це різноманітні реалізації API специфічних сервісів, на кшталт SDN (AWS, Azure, Google Cloud, OpenStack і інші), PaaS-платформ (Heroku), SaaS сервісів (наприклад, DNSimple, CloudFlare, Gitlab), self-hosted програмного забезпечення (Docker, MySQL, RabbitMQ) і неймовірної кількість іншого софту.

Далі буде розглянуто роботу Terraform з IaaS провайдером Amazon Web Services. Забігаючи наперед скажу, що Terraform не cloud-agnostic, тобто для побудови схожої інфраструктури, наприклад, у Google Cloud необхідно буде переписувати всі темплейти.


1. PREREQUIREMENTS


Terraform і його плагіни написані на мові Go зі статичним лінкуванням бібліотек і розповсюджується як готовий бінарний файли для всіх популярних і не дуже ОС. У якості клієнта я буду використовувати Ubuntu, тож завантажу відповідний архів:

$ wget https://releases.hashicorp.com/terraform/0.11.7/terraform_0.11.7_linux_amd64.zip
$ tar xvfz terraform_0.11.7_linux_amd64.zip
$ chmod +x terraform
$ sudo mv terraform /usr/local/bin/

$ terraform -v
Terraform v0.11.7

Надалі нам також знадобиться aws-cli, хоч він не обов'язковий і Terraform не потребує його присутності:

$ 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

четвер, 28 червня 2018 р.

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

неділя, 1 квітня 2018 р.

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

середа, 10 січня 2018 р.

Kubernetes. Part V: Configure And Use Ingress

Ця стаття вже п'ята з серії статей про Kubernetes. Перед її прочитанням рекомендую ознайомитись хоча б з базовими об'єктами кластеру та їх використанням для вирішення задач.

Сервіси Kubernetes надають можливість створення постійних точок входу до контейнерів додатків, що працюють в подах, проте IP адреси сервісів обираються з діапазону оверлейної мережі, і тому є видимими лише в межах кластеру. Тож у разі необхідності доступу до таких додатків ззовні існують наступні варіанти:

hostNetwork: true. Под, створений із такою опцією, матиме можливість бачити мережеві інтерфейси Kubernetes хосту, де його було запущено.

apiVersion: v1
kind: Pod
metadata:
  name: influxdb
spec:
  hostNetwork: true
  containers:
    - name: influxdb
      image: influxdb

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

hostPort: integer. Ця опція дозволяє поду активувати лише один порт на всіх інтерфейсах вузла Kubernetes. Yaml для створення такого поду буде виглядати наступним чином:

apiVersion: v1
kind: Pod
metadata:
  name: influxdb
spec:
  containers:
    - name: influxdb
      image: influxdb
      ports:
        - containerPort: 8086
          hostPort: 8086

Його, як і попередній варіант, дуже не рекомендовано використовувати по тим же причинам.

четвер, 14 грудня 2017 р.

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


пʼятниця, 6 жовтня 2017 р.

Kubernetes. Part III: Objects And How To Use Them

Отже у нас вже є готовий налаштований кластер і, озброївшись необхідним теоретичним мінімумом, ми можемо переходити до подальшого вивчення Kubernetes. Цього разу ми поговоримо детальніше про основні примітиви (objects) Kubernetes, як вони взаємодіють між собою та як реалізовані.

Забігаючи наперед, основні команд для отримання даних про роботу об'єктів є наступні:
  • kubectl get object_type - перерахунок всіх об'єктів даного типу, котрі знаходяться в межах одного неймспейсу
  • kubectl describe object_type - детальна інформація про всі об'єкт даного типу, що також знаходяться в одному неймспейсі
Всі основні об'єкти перераховані нижче. Якщо замість object_type вказати all, то буде виведено все, що знаходиться в неймспейсі.

ПОД (POD). Створимо под, що буде складатись з одного docker-контейнера і буде доступний на порту 9876. Для цього використаємо образ з dockerhub mhausenblas/simpleservice:0.5.0:

$ kubectl run first-pod --image=mhausenblas/simpleservice:0.5.0 --port=9876
deployment "first-pod" created

Перевіримо чи новий под працює:

$ kubectl get pods
NAME                         READY     STATUS    RESTARTS   AGE
first-pod-2257828502-l6z96   1/1       Running   0          23s

$ kubectl describe pod first-pod-2257828502-l6z96 | grep IP:
IP:   10.34.0.25

Отже, в межах кластеру под працює за адресою 10.34.0.25. Із будь-якого вузла кластеру пересвідчимось в цьому, зробивши запит до додатку:

[cluster]$ curl 10.34.0.25:9876/info
{"host": "10.34.0.25:9876", "version": "0.5.0", "from": "10.32.0.1"}