LXC Сontainers. Part II: Network Configuration

У попередній статті я описав, що таке LXC та чому ця технологія може вас зацікавити.

Перед прочитанням тексту нижче, бажано звісно розуміти базові речі про LXC чи просто про контейнеризацію, тому дуже раджу хоча б переглянути статтю, згадану вище.
У цій статті спробуємо розібратись які можливості надає LXC для конфігурації мережевого стеку та і що власне ОС Linux може запропонувати для цього.

Конфігурація з'єднання з мережею описується окремо для кожного контейнера в /var/lib/lxc/<container_name>/config. По замовчуванню, мережевий зв’язок для контейнерів LXC налаштовується за рахунок додаткової приватної мережі 10.0.3.0/24, що NAT-иться на хост машині: всі пакети, що приходять на інтерфейс lxcbr0 (10.0.3.1, gateway) за допомогою маскарадингу динамічно транслюються в публічний айпі і навпаки. Видає IP-адреси dnsmasq, що працює на LXC-хості, а діапазон можливих адрес описаний в /etc/default/lxc-net. На практиці це виглядає так:

# vim /etc/default/lxc-net
...
USE_LXC_BRIDGE="true"

LXC_BRIDGE="lxcbr0"
LXC_ADDR="10.0.3.1"
LXC_NETMASK="255.255.255.0"
LXC_NETWORK="10.0.3.0/24"
LXC_DHCP_RANGE="10.0.3.2,10.0.3.254"
LXC_DHCP_MAX="253"
...

Налаштування Iptables на хості, одразу після установки lxc, мають такий вигляд:

# iptables-save
...
-A POSTROUTING -s 10.0.3.0/24 ! -d 10.0.3.0/24 -j MASQUERADE
...
COMMIT

LXC Сontainers. Part I: Overview

LXC (англ. LinuX Containers) — система віртуалізації на рівні операційної системи для запуску декількох ізольованих примірників ОС Linux на одному комп'ютері. LXC не використовує віртуальні машини, а створює віртуальне оточення (контейнер) з власним простором процесів і мережевим стеком. Тобто у разі контейнеризації хост-ситема не емулює хардову частину (відсутній гіпервізор), а просто обмежує процеси та ресурси гостей внутрішніми підсистемами.

У разі LXC, ці підсистеми - це cgroups (додана у версії 2.6.29), namespaces (для ізоляції процесів, мережевого стека і т.д.); для обмеження доступу задіяні такі можливості ядра, як профілі Apparmor і SELinux, політики Seccomp, Chroots (pivot_root) і capabilities. Усі контейнери LXC використовують один примірник ядра ОС.

Ця система схожа на системи OpenVZ (LXC прийняв багато патчів та ідей з цього проекту) і Linux-VServer для ОС Linux, jail для FreeBSD, Solaris Containers для Solaris. Проте на відміну від OpenVZ, LXC не потребує окремого ядра для своєї роботи: необхідні для роботи LXC підсистеми одразу знаходяться в основній вітці ядра.

До складу інструментарію LXC входить бібліотека liblxc, набір утиліт (lxc-create, lxc-start, lxc-stop, lxc-ls і тому подібне), шаблони для побудови контейнерів і набір біндінгів для різних мов програмування.

Cassandra. Part II: Cluster

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

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

10.131.75.141  cs-1
10.131.75.142  cs-2
10.131.75.143  cs-3
10.131.75.144  cs-4

Із них і буде складатись кільце кластеру (Token Ring). Отже, створимо ці віртуальні машини та додамо цей список адрес до кожної із них в /etc/hosts. У якості ОС я обрав Ubuntu 14.04. Кількість оперативної пам'яті для кожної віртуальної машини рівна 1 ГБ, що звісно достатньо лише для тестових цілей.

Установлюємо Java:

# add-apt-repository ppa:webupd8team/java
# apt-get update
# apt-get install oracle-java8-installer

# apt-get install oracle-java8-set-default

Та останню версію Cassandra з репозиторіїв DataStax:

# echo "deb http://debian.datastax.com/community stable main" | sudo tee -a /etc/apt/sources.list.d/cassandra.sources.list
# curl -L http://debian.datastax.com/debian/repo_key | sudo apt-key add -

# apt-get update
# aptitude install cassandra
The following NEW packages will be installed:
  cassandra libopts25{a} ntp{a} python-support{a} 
0 packages upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
Need to get 24.9 MB of archives. After unpacking 34.0 MB will be used.
Do you want to continue? [Y/n/?]

Java та Cassandra, очевидно, необхідні на всіх нодах кластеру. Після установки перевіримо роботу бази, підключившись до неї через CQLSH:

# cqlsh
Connected to Test Cluster at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 2.2.1 | CQL spec 3.3.0 | Native protocol v4]
Use HELP for help.
cqlsh> 

Cassandra. Part I: Overview

Apache Cassandra — розподілена система керування базами даних, що відноситься до класу noSQL-систем і розрахована на створення високомасштабованих і надійних сховищ величезних масивів даних, представлених у вигляді хеша.

Проект стартував у надрах компанії Facebook і в 2009 році був переданий фонду Apache. В основу Cassandra лягли 2 архітектурні ідеї: Amazon Dynamo та Google Big Table, опис яких був опублікований в 2007 та 2006 роках відповідно.

Цю базу данних використовують такі компанії як IBM, Apple, Netflix, Twitter, Yandex, CERN, Reddit, SoundCloud, Rackspace та інші.

Cassandra проектувалась для великих географічно розподілених систем, тому на відміну від традиційних баз не має багатьох недоліків: масштабування, висока доступність і т.п. тут реалізовано простіше ніж, скажімо, в MySQL. Звісно Cassandra не срібна куля, і при проектуванні інфраструктури треба добре розуміти як архітектору так і розробнику, які запити буде обслуговувати база та інші особливості.

Що ж таке Cassandra? Cassandra - це гібрид key-value и column-oriented баз даних. Термінологія структури данних дещо інша ніж в реліційній моделі, проте не варто на цьому особливо зациклюватись адже це не так важливо.

Тож в Cassandra є бази (keyspace), в котрих знаходяться сімейства колонок (аналог таблиць у реляційній системі), а в самому сімействі, вже майже як і у звичайній таблиці, колонки і рядки. Майже, тому що для кожного рядка може бути визначений свій набір колонок (розріджені таблиці). Як це виглядає в реальному житті? Ну щось схоже на це:

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

Start Jenkins task after push to Git/Gitlab

Часто монотонні кроки можна просто автоматизувати і не виконувати їх щоразу. Скажімо, після кожного коміту в репозиторій чи коміту з певним тегом можна запускати певну задачу чи виливати свіжий код проекту. Насправді, це не так складно, як може здаватись на перший погляд.

Розглянемо конкретний випадок: будемо автоматично запускати Jenkins задачу після кожного коміту в GitLab репозиторій. GitLab - це менеджмент-панель на базі Git і приведена лише як приклад.

Jenkins "із коробки" підтримує таку можливість, проте не від анонімного користувача. Тому скористаємось іншим рішенням - плагіном Build Token Root. Спочатку встановимо його: Manage Jenkins > Manage Plugins > Available > Build Authorization Token Root Plugin:

Як варіант, звісно, можна скористатись Gitlab Hook плагіном, проте він працює лише зі стандартним SCM Git і при бажанні змінити останній на, наприклад, Multiple SCMs Plugin Jenkins, буде втрачена можливість користуватись першим плагіном. Також я вбачаю використання плагіну Build Token Root більш безпечним.

GlusterFS: setup and configuration

GlusterFS — розподілена файлова система, що дозволяє організувати роботу розподіленого на кілька вузлів сховища, розгорнутого поверх штатних файлових систем POSIX, таких як Ext4, XFS і Btrfs, з використанням механізму FUSE (файлова система у просторі користувача). GlusterFS надає засоби автоматичного відновлення після збоїв і забезпечує практично необмежену масштабованість, завдяки відсутності прив'язки до централізованого серверу мета-даних (використовуються розподілені хеш-таблиці).

Цю файлову систему застосовують у хмарних обчисленнях, службах потокового медіа та у мережах постачання даних. (c) Wikipedia

Ключові особливості GlusterFS:

* Еластичність - томи зберігання даних абстраговані від заліза, на якому фізично знаходяться і можуть бути як-завгодно збільшені/зменшені/переміщені в межах фізичних систем.
* Відсутність окремого сервера метаданих - на відміну від інших розподілених файлових систем (наприклад, Lustre), GlusterFS не використовує окремого сервера для метаданих. Таким чином у неї відсутня єдина точка відмови.
* Масштабованість - досить просто збільшити або зменшити розмір файлової системи, без даунтайму. Може маштабуватись як у продуктивності так і обсягу даних.
* Висока доступність - у випадку правильного проектування тому, випадання окремого серверу не призведе до простою системи. Звісно, рівень доступності залежить від кількості реплікацій.
* Гнучкість - GlusterFS працює в просторі користувача (FUSE), тому не потрібно патчити ядро, додавати до нього модулі і т.д. Проте з іншої сторони, файлові системи в ядрі працюють швидше.
* Гео-реплікація - GlusterFS дозволяє синхронізувати всю систему збереження даних між різними датацентрами чи географічними місцями.

Налаштування GlusterFS достатньо просте. Конфігурацію будемо проводити на 3 віртуальних машинах: 2 сервера та 1 клієнт. До клієнта буде примонтований розділ GlusterFS, котрий буде попередньо створений на серверах.

Provisioning with Ansible

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

Щоб уникнути подібних страждань людство і придумало системи управління конфігураціями. До найбільш популярних таких систем можна віднести Puppet, Salt, Chef, CFEngine. Хронологія їх появи така:

* CFEngine. Перший реліз - 1993, написаний на С.
* Puppet - 2005, написаний на Ruby. DSL
* Chef - 2009, написаний також на Ruby, DSL
* Juju - 2010, Python.
* Salt - 2011, Python.
* Ansible. Перший реліз - 2012, Python.

Ansible один із наймолодших із існуючих популярних систем конфігурації. Проект стартував лише в 2012 році, проте вже має багато прихильників. Засновник проекту - Майкл Де Хаанн, попередньо працював над Puppet і Cobbler/Func. Назва продукту взято з науково-фантастичної літератури: в романах американської письменниці Урсули Ле Гуїн ансіблом називається пристрій для оперативного космічного зв'язку. Про Ansible далі і піде мова.

Ansible - програма з відкритим вихідним кодом для налаштування і управління серверами. Для деплоя конфігурації на новий сервер необхідно лише SSH-з’єднання та Python-інтерпритатор, який зазвичай йде по-замовчуванню в основних дистрибутивах. Сценарій конфігурації (в Ansible він називається Playbook) описується за допомогою мови розмітки YAML.