Translate

неділя, 13 грудня 2015 р.

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


неділя, 22 листопада 2015 р.

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 і тому подібне), шаблони для побудови контейнерів і набір біндінгів для різних мов програмування.

неділя, 18 жовтня 2015 р.

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> 

пʼятниця, 9 жовтня 2015 р.

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.

понеділок, 21 вересня 2015 р.

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 більш безпечним.

середа, 15 липня 2015 р.

GlusterFS: setup and configuration

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

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

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

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

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

четвер, 14 травня 2015 р.

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.


понеділок, 20 квітня 2015 р.

Docker. Setup and configuration

Останнім часом дуже часто пишуть про Docker та його можливості, дехто навіть приписує йому мало не магічні вміння. Тож у цій статті спробуємо розібратись, що таке Docker і чи потрібно все кидати та мігрувати на нього.

Docker - це один із різновидів контейнерної віртуалізації. Контейнерна віртуалізація не використовує віртуальні машини, як у випадку з повною віртуалізацією, а створює віртуальне середовище з власним простором процесів та мережевим стеком. Всі контейнери хосту використовують один екземпляр ядра хостової системи.

Головними перевагами контейнерної віртуалізації є: зручність у адмініструванні, щільніше розміщення віртуальних контейнерів в хост-системі, дещо краща продуктивність в порівнянні з технологіями повної віртуалізації та економніше використання місця на дисковій системі.

четвер, 29 січня 2015 р.

Centralize Loggining with Kibana/Logstash/Elasticsearch

Я раніше писав про установку та налаштування серверу централізованого збору логів в основі якого лежав Rsyslog з бекендом LogAnalyzer, та сервер із Syslog-ng. Основним недоліком LogAnalyzer є відсталість його інтерфейсу. Тому якщо цей недолік для вас є основним - раджу спробувати Kibana/Logstash зі зберіганням данних в Elasticsearch.

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

Спочатку розберемось щодо складових частин серверу збору логів та їхнього призначення.


Logstash читає логи або отримує їх від клієнтів за допомогою Logstash-forwarder, розбирає їх по полям відповідними драйверами та записує їх до Elasticsearch, потім, за допомогою Kibana, можна переглядати логи і будувати різноманітні діаграми чи графіки.

Дистрибутив, що я буду використовувати - Ubuntu 14.04. Навіть для тестів краще брати машину як мінімум із 2 ГБ RAM та 2 CPU.

Почнемо з установки серверної частини. Logstash та Elasticsearch потребують Java 7 для роботи, для чого підійде як Oracle Java 7, так і OpenJDK.

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

Для production середовища, можливо, краще скористатись джавою що надає Oracle на власному сайті та зібрати власний пакет:

# apt-get install java-package
# wget http://download.oracle.com/otn-pub/java/jdk/7u75-b13/server-jre-7u75-linux-x64.tar.gz?AuthParam=1423217016_530b51c9d6c77e8237c6a2f2288d7657 -O jre-7u75-linux-x64.tar.gz
# make-jpkg jre-7u75-linux-x64.tar.gz
# dpkg -i oracle-j2re1.7_1.7.0+update75_amd64.deb
# update-alternatives --auto java

неділя, 11 січня 2015 р.

Deploy with Webistrano (Capistrano)


Webistrano - це фронтенд написаний на ROR до ruby-програми Capistrano. Це зручна адмін-панель до управління процесом виливки коду: за допомогою Webistrano можна зручно управляти етапами деплою проектів, надавати певні права користувачам, повертатись на попередні релізи у разі появи проблем та ін.

На жаль, проект більше 5 років не підтримується розробником - тому чим далі, тим буде складніше його установити, адже ніхто не тестує його роботу з останніми бібліотеками Ruby. Наразі краще пошукати альтернативи Webistrano або ж просто користуватись лише консольним інтерфейсом Capistrano, що звісно не додає зручності.

Для Ubuntu 14.04 LTS установка і налаштування проходить наступним чином. Перш за все встановимо необхідні пакети зі стандартних репозиторіїв:

# apt-get install ruby ruby-dev gem rubygems-integration libmysqlclient-dev ruby1.9.1-dev make git mysql-server

Призначення кожного пакету, я думаю, зрозуміле. Наступний крок - установка Rails:

# gem install rdoc mysql2
# gem install rails --no-ri --no-rdoc

Встановлюємо Capistrano, бекенд до Web:

# gem install capistrano