Закончив собирать домашний сервер на VirtualBox, я решил повторить то же самое на Docker — для саморазвития. Потрогать его пока не доводилось, а тут подходящая задача, чтоб разобраться с основами.

Docker нынче очень популярный в разработке инструмент. Возможность быстро и автоматизированно создать чистое рабочее окружение полезна и для деплоя, и для тестирования.Фактически, Docker — это не полноценная виртуализация, но изоляция процессов и ресурсов. Что имеет как свои преимущества, так и недостатки.

Хорошо: производительность на уровне нативной. На слабом процессоре вроде моего Атома надо ловить каждую крупинку процессорной мощности. Особенно если аппаратная виртуализация не поддерживается железом.Плохо: изоляция контейнера не абсолютная, некоторые вещи при каждом переезде на новое железо придётся делать ручками на хосте (iptables, настройка сетевых интерфейсов, хранение контейнерных томов).

Нет смысла описывать тут рутинные операции по настройке контейнеров. Можно брать готовые на Docker Hub, можно собирать свои буквально в несколько строк в Dockerfile. Я взялся было брать за основу привычный Debian, да образы оказались слишком жирными, и Alpine Linux тут оказался хорош. Прекомпилированные пакеты в достатке, а каких нет — можно поискать в testing-репозитории.

Не обошлось, однако, и без традиционных граблей.

Munin¶

Запустить ноду munin просто так из коробки не получится: некоторые метрики хоста недоступны из контейнера, как то: количество залогиненных пользователей, занятое место на жёстких дисках, трафик на сетевых интерфейсах и т.д. Что-то решается параметрами --privileged и --network=host, что-то (возможно) монтированием хостовых директорий /proc и /sys. Для плагинов «df» и «df_inode» можно прокинуть внутрь устройства /dev/sd* (параметр --device) и внутри примонтировать их чисто декоративно.

CUPS и HPLIP¶

У меня есть старенький лазерный принтер HP LaserJet 1010, купленный на Авито несколько лет назад. А у HP существует такой специальный проект HPLIP: набор драйверов и утилит чисто для их принтеров и сканеров.

Не знаю, что пошло не так, но я не смог сходу сдружить вместе Alpine, CUPS и hplip. Утилит hp-* там в комплекте не было, бэкэнд /usr/lib/cups/backends/hp писал, мол, «unknown device». Причём lsusb принтер видела. В тестовом контейнере с Debian, несмотря на более раннюю версию hplip, подобной проблемы не обнаруживалось. Не стал копать глубже, выкинул hplip, поставил gutenprint, настроил как USB-принтер через веб-интерфейс, — и порядок.

Android 5 и DNS¶

Для разных сервисов я завёл локальные домены (вида cups.lan, samba.lan, munin.lan), ведущие фактически на одну машину, и настроил dnsmasq, чтоб оно могло таковые домены резолвить. На ноутбуке и телевизоре проблем нет. Нет их даже во встроенном в Kindle браузере. А вот в Android 5, который стоит на борту наших смартфонов и планшетов — проблема обнаружилась.

Все локальные домены не распознаются с ошибкой «not resolved». Т.е. что-то там с DNS не то. Причём Android-программки специально для проверки DNS-серверов честно работают (если указать им локальный DNS-сервер вручную).

После небольшого гугления и манипуляций с adb выяснилось, что Android отдаёт предпочтение DNS-серверу с IPv6-адресом (adb shell → getprop net.dns1). В ход пошёл tcpdump, и стало ясно, что запросы на сервер элементарно не приходят. А они широковещательные, и сначала на них отвечает OpenWRT-роутер со своей dnsmasq на борту, который как раз про локальные имена ничего не знает. Решилось отключением лишней dnsmasq. Держите ваши DNS-сервера опрятными!

В итоге сервер пока работает стабильно.Загрузка приподнялась, когда я включил motion. Вероятно, у него постоянно активен алгоритм поиска движения на картинке. Попробую или отключить, или подобрать другую программку для захвата с камеры. Но даже и возросшая нагрузка — в пределах нормы, с VirtualBox такого результата не получилось.