Итак, в первой части заметок про 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.
1 | iptables -t nat -A PREROUTING -p tcp -d 192.168.1.42 --dport 8112 -j DNAT --to 192.168.242.130:8112 |
Вот две “магические строчки”, которые позволят обратиться к 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. Вобщем, если бы да кабы - сами знаете что.