LXC-контейнеры для домашнего сервера (часть вторая)

LXC containters

Итак, в первой части заметок про LXC мы остановились на запуске нашего первого контейнера.

Если всё прошло удачно, то у нас есть сеть и мы уже изгадили свежий Ubuntu кучей приложений. Самое время научить контейнер делиться данными с хостом, а также вытащить "наружу" наши приложения-сервисы. Но вначале про доступ к контейнеру.

Попадаем внутрь контейнера

Тут всё предельно просто - во-первых есть lxc-attach. Если он не работает по причине какой-либо несовместимости - имеет смысл поставить ssh-сервер. Нищеброды ставят dropbear. Для этого внутри контейнера достаточно сказать:

apt-get install dropbear

А "снаружи" -

ssh ubuntu@your.containter.ip.address

И вы уже в внутри контейнера, где можно чинить беспредел, как душе угодно.

Пользователи с достаточным количеством ресурсов ставят openssh-server и не знают хлопот с обменом ключами.

Ну, "до кучи" можно в /etc/hosts прописать ip-адреса контейнеров с человекочитаемыми именами.

Общие папки

Предположим, наш контейнер занимается только скачкой торрентов. Было бы неплохо выставить "наружу" директорию, куда они эти самые закачки складывает, да и папочку, куда можно "подпихивать" торрент-файлы. И да, ещё директорию, где лежат незавершенные торренты, ибо места мы выделили всего пару гигов, а подшивка Hustler за десятилетие весит скорее всего несколько больше.

Нет ничего проще - в первой части материала уже приводился пример конфига контейнера.

Нас интересует вот эта строчка:

lxc.mount.entry = /var/lvm/data/downloads var/downloads none bind 0 0

Для тех, кто в танке - директория "/var/lvm/data/downloads" будет отображаться в "/var/downloads" контейнера.

Сколько таких папок нужно, столько и добавляем.

Обратите внимание, что "цель" записана без первого прямого слэша. Так и задумано.

Доступ к сервисам по сети

От того, что ваш сраный веб-сервер будет жить внутри контейнера никому особо не легче, ибо его нужно как-то вытащить "наружу".

Опять же, в первой части креатива мы выделяли собственную подсеть для наших "виртуалок" и bridge-интерфейс, "висящий в воздухе", то есть не связанный ни с каким физическим интерфейсом для обеспечения работы как по WiFi, так и по проводу.

Для пробрасывания соединений мы будем использовать iptables.

iptables -t nat -A PREROUTING -p tcp -d 192.168.1.42 --dport 8112 -j DNAT --to 192.168.242.130:8112 iptables -A FORWARD -p tcp -d 192.168.242.130 --dport 8112 -j ACCEPT

Вот две "магические строчки", которые позволят обратиться к Deluge WebUI извне.

То есть, в нашем контейнере 192.168.242.130 работает веб-интерфейс для торрента на порту 8112. Мы говорим, что "то, что пришло на порт 8112 на внешниий интерфейс 192.168.1.42 решительно отправляй на порт 8112 контейнера". И, о чудо! Наш вебинтерфейс доступен из домашней сети. Качайте на здоровье.

Автостарт контейнеров

Да, контейнеры можно стартовать вместе с системой. Возвращаемся к первой части и смотрим конфигурационный файл. Нас интересует вот эта секция:

#Autostart lxc.start.auto = 1 lxc.start.order = 0 lxc.start.delay = 10

Первая строка говорит "запускай контейнер при старте системы". Вторая - "запускай первым". Третья - "попридержи запуск остальных контейнеров на десять секунд". По-моему всё очевидно.

Общий анамнез

В данный момент у меня работает четыре контейнера, которые выполняют свои задачи:

  • TOR + Privoxy
  • Owncloud
  • Torrent
  • Misc apps (image gallery, TiddlyWiki)

И получается вот такой расклад по памяти и ресурсами:

Список контейнеров

Команда:

for app in `lxc-ls`;do lxc-info -n $app;done

выводит информацию о ваших контейнерах. Запускать под рутом, ну или под sudo.

Где я облажался и что ещё можно сделать

Ну, для начала всё в целом работает. В одном из контейнеров у меня работает TOR, который по идее должен принимать весь траффик с WiFi адаптера и прозрачно проксировать его через себя.

На обычной не-контейнерной конфигурации правило iptables выглядит так:

iptables -t nat -A PREROUTING -i wlan0 -p tcp --syn -j REDIRECT --to-ports 9040

И оно реально работает, однако стоит перенаправить его в контейнер:

iptables -t nat -A PREROUTING -i wlan0 -p tcp --syn -j DNAT --to 192.168.242.140:9040

Тут всё работать перестает. Причина мне неизвестна - то ли всё путается на уровне маскарадинга, то ли сам тор так работает, может что-то ещё. Проще поднять ещё один инстанс TOR'a на bare metal машине и пользоваться. Короче, фиг его знает что не так. Может нужно где-то добавить SNAT-правило, но оно того не стоит.

Часто задаваемые вопросы

Как правило возникают вопросы примерно следующие:

  • Насколько это быстро работает ?
  • Большой ли overhead ?
  • Как это всё бэкапить ?
  • Когда ты, сука, сдохнешь ?

Отвечаю по пунктам:

  • Сравнимо с bare metal, ибо фактически всё выполняется под тем же ядром и железо не эмулируется
  • Небольшой и будет ещё меньше, если перелезть на Alpine Linux
  • Я бы смонтировал rootfs в директорию и сделал бы tar с ключом numeric-owner. И так 4 раза.
  • Не дождётесь

Что ещё можно сделать с этим всем и для чего пригодятся контейнеры

Мне лично видятся две задачки, которыми стоит позаниматься.

Поскольку контейнеру можно разрешить пользоваться устройствами - вполне можно запускать браузер в отдельной "псевдо виртуалке" и не беспокоиться за утечку данных для особо ретивых приложений через WebSocket. Что-то подобное было на говнохабре - гугл в помощь. Но это актуально для десктопного использования. Microsoft, кстати обещал свои контейнеры - посмотрим, что вылупится.

Также для параноиков - контейнеру можно "скормить" тот же Яндекс.Диск или Облако mail.ru и пусть они там себе крутятся в одиночестве. Для ARM-устройств, ясное дело, билдов этого софта не наблюдается, НО контейнер можно обучить binary format support и заставить выполнять двоичный код i386 на ARM. Медленно, НО! Во-первых изначальная система девственно чиста (нет репозитариев i386), а во-вторых мы никуда не торопимся. Игра стоит свеч.

Итоги

В умелых руках и Хуй - балалайка, так что с помощью контейнеров можно как удовлетворить свою неудержимую страсть к "попробовать то и сё" вплоть до нового дистрибутива, так и соблюдать гигиену при использовании "глобальной сети Интернет". Короче, ценный горшочек, пользоваться можно и нужно.

Более того, если бы я лично попробовал это всё годиком раньше - то текущий домашний storage не был бы столь сильно угажен билдовой средой для ARM-ядер, сервером Plex, и ещё парой-тройкой "незаменимых приложений". Всё было бы разложено по полочками, принято у учёту и запускалось бы on-demand. Вобщем, если бы да кабы - сами знаете что.

На корм коту

Магазин открыт!

ещё