Translate

четвер, 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


понеділок, 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 (Tun Interface)

Декілька тижнів тому я опублікував першу статтю про програму 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). Найбільш надійний варіант, адже в клієнта та сервера є свій унікальний набір ключів/серифікатів, що підписані одним центром сертифікації.

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