Linux-контейнеры дома: зачем и как
Рассуждения
При упоминании словосочетания «контейнерная виртуализация», многим на ум сразу же приходят Virtuozzo и OpenVZ, а также Docker. Ассоциируется же это все, в первую очередь, с хостингом, VPS и другими подобными вещами.
Дома, на личных компьютерах многие используют виртуальные машины: в основном, пожалуй, Virtualbox. Как правило, для того, чтобы работая под Linux, иметь под рукой Windows или наоборот. Однако, при наличии множества родственных Linux-операционок, я стал замечать, что использование виртуальных машин — это, мягко говоря, нерационально.
В первую очередь, очень быстро расходуется дисковое пространство. Каждой виртуальной машине нужно место, даже если несколько из них отличаются только конфигами. Особенно критично это на невеликих размеров SSD лаптопа. В принципе, Virtualbox умеет работать с raw-девайсами и, теоретически, машинам можно назначать rw LVM-снапшот, но тут опять же встают вопросы с изменением размера файловой системы в дальнейшем, автоматизацией клонирования, переноса, удаления и тому подобное.
Во вторую — это больший расход оперативной памяти. В третью — не самые удобные инструменты взаимодействия…
Потому, возникла идея опробовать в домашних условиях контейнерную виртуализацию. OpenVZ отмел сразу, по причине необходимости возиться с кастомным ядром. Выбор же пал на LXC, поставляющийся в репозитарии стабильного Debian’a.
Что такое контейнеры и чем это все отличается от виртуализации? В случае контейнеров, не создается виртуальное аппаратное окружение, а используется изолированное пространство процессов и сетевого стека. Скажем так, получается chroot с расширенными возможностями.
— Для сборки ПО при нежелании захламлять разномастными *-dev пакетами основную рабочую систему.
— Потребность в другом дистрибутиве для запуска каких-либо специфических программ и, опять же, сборки.
— Изоляция потенциально небезопасного софта, вроде того же скайпа совершающего разные непонятные действия в домашнем каталоге пользователя и всяких сомнительных веб-технологий: уязвимость во флеше, в java, в обработчике pdf — это только то, что плавает на поверхности.
— Анонимность. Эдак можно банально остаться залогиненым в своей любимой социалочке, забыть подчистить куки или оказаться незнакомым с очередной новой веб-технологией вроде этой webrtc. Можно, конечно, держать несколько профилей браузера, но от перечисленных выше дыр и технологий это не защитит.
Итак, рассмотрим плюсы и минусы LXC:
+ Работает на ванильном ядре
+ Простота проброса устройств и каталогов хоста, так как работает это все через cgroups
+ Очень нетребовательно к ресурсам, в отличии от виртуальных машин типа Virtualbox или qemu
— Контейнеры будут работать на том же ядре, что и хост, хотя — это скорей особенность контейнерной виртуализации в целом.
— Некоторая недоделанность идущих в комплекте утилит.
Развертывание и настройка контейнера
В первую очередь, ставим пакет lxc и все необходимые утилиты:
Смотрим доступные группы томов LVM:
Указываем использовать LVM в качестве системы хранения, Volume Group ( в моем случае — nethack-vg) и размер 2 гигабайта, иначе по умолчанию будет создан одногиговый том. Хотя, если вдруг стало тесновато, можно будет сделать lvresize.
Видим, что у нас появился том deb_test.
Типовой конфиг, созданный скриптом:
Пока у нас ни сети, ни нужных для работы программ. Для этого на хосте поднимаем мост, задаем IP, заворачиваем трафик из подсети виртуалки, при отключении интерфейса разрушаем мост.
На хосте прописываем в /etc/network/interfaces
В конфиг контейнера дописываем:
Понятно, что mac-адрес произвольный, на любой вкус.
Чтобы сразу получить рабочую сеть и возможность установки пакетов apt’ом, допишем
Понятно, что 192.168.18.1 — IP моего DNS.
Установим нужные пакеты:
Дальше либо на хосте, либо на другой рабочей виртуалке можно получить список установленных пакетов и установить их все в нашем новом контейнере:
Теперь можно по-человечески настроить сетевой интерфейс в контейнере, использовав любимый текстовый редактор:
Впрочем, это можно было сделать с хост-системы, например, смонтировав логический том. Способов много.
В принципе, в качестве DNS можно указать любой публичный, если не опасаетесь за свою приватность. Например, гугловские 8.8.8.8 и 8.8.4.4.
По доступу к устройствам хост-системы, я придерживаюсь политики «все, что не разрешено, запрещено». Добавим для этого следующую строчку в конфиг:
Попробуем подключиться через OpenVPN. Сразу же получаем ошибку:
Система пишет, что интерфейсы TUN/TAP недоступны по причине их отсутствия. Очевидно, что нужно разрешить гостевой системе использовать устройства хоста. Открываем конфигурационный файл контейнера, /var/lib/lxc/deb_test/config и добавляем туда строчку:
В контейнере выполняем:
Обратим внимание на 10:200 — это идентификатор типа устройств. Если выполним на хосте:
То увидим идентификаторы 10, 200. По ним и будем ориентироваться, разрешая доступ к устройства, например камере — video0.
Точно также добавляем остальные нужные устройства:
Для функционирования иксов и возможности их проброса через ssh, нужно добавить точку монтирования:
По аналогии можно примонтировать и другие, нужные каталоги и файлы:
Для воспроизведения звука, можно разрешить доступ к звуковому устройству, если карта многопоточная (с однопоточной при использовании dmix возникают проблемы с блокировкой):
А можно настроить pulseaudio на воспроизведение звука по сети, как это описано здесь. Кратко:
Отредактировать на хосте /etc/pulse/default.pa, дописав туда:
В итоге у нас получается вот такой конфиг:
Контейнер готов к использованию.
Использование
Доустановим, например, i2p с Tor’ом, если не сделали этого ранее, и сходу настроим privoxy:
Запускать графические приложения вроде браузера удобнее всего через ssh:
Также, разумеется, LXC предоставляет средства для клонирования контейнеров и снятия снапшотов.
Так, например, склонировать контейнер, файловая система которого будет являться LVM-снапшотом можно командой:
Будет создан контейнер deb_test2 с файловой системой, размещенной на LVM-снапшоте размером 200MB (под хранение diff’ов). Это будет точная копия deb_test, над которой можно провести пару экспериментов и, например, безболезненно удалить.
А вот lxc-snapshot с LVM в качестве хранилища, на версии lxc-1.0.6 почему-то не работает:
Проблема описывается и обсуждается здесь. Потому, снимки придется делать по старинке:
В данном случае создали read-only снапшот с именем deb_test_before_rm_rf размером 100MB. Что с ним делать дальше? Например, его можно сдампить посредством dd, перенести на другую машину вместе с конфигами контейнера, создать там том нужного размера и пролить тем же dd (cp, cat, итд) — эдакая «живая миграция».
Как писалось выше, областей применения контейнерам можно найти массу. Но главной, при домашнем использовании, на мой взгляд, является изоляция приложений.
Linux-контейнеры: изоляция как технологический прорыв
Представьте, что вы разрабатываете приложение, причем, на своем ноутбуке, где рабочее окружение имеет определенную конфигурацию. Приложение полагается на эту конфигурацию и зависит от определенных файлов на вашем компьютере. У других разработчиков конфигурация может слегка отличаться. Кроме того, в вашей организации есть тестовые и промышленные среды со своими конфигурациями и наборами файлов. Вам хотелось бы как можно точнее эмулировать эти среды у себя, но совершенно не хочется воспроизводить сложные и тяжелые сервера на своей машине. Как же сделать так, чтобы приложение работало во всех средах, прошло контроль качества и попало в продакшн, не сталкиваясь по дороге с массой проблем, требующих постоянной доработки кода?
Ответ: использовать контейнеры. Вместе с вашим приложением контейнер содержит в себе все необходимые конфигурации (и файлы), поэтому его можно легко переносить из среды разработки в среду тестирования, а затем в промышленную среду, не опасаясь никаких побочных эффектов. Кризис устранен, все в выигрыше.
Это, конечно, упрощенный пример, но Linux-контейнеры действительно позволяют успешно справляться с множеством проблем, связанных с переносимостью, настраиваемостью и изоляцией приложений. Будь то локальная ИТ-инфраструктура, облако или гибридное решение на их основе, контейнеры эффективно справляются со своей задачей. Разумеется, помимо собственно контейнеров, важен и выбор правильной контейнерной платформы.
Что такое Linux-контейнеры
Linux-контейнер – это набор процессов, изолированный от остальной операционной системы и запускаемый с отдельного образа, который содержит все файлы, необходимые для их работы. Образ содержит все зависимости приложения и поэтому может легко переноситься из среды разработки в среду тестирования, а затем в промышленную среду.
А разве это не просто виртуализация?
Что это значит? Прежде всего, то, что для одновременной работы нескольких операционных систем на одном гипервизоре (программе, которая реализует виртуализацию), требуется больше системных ресурсов, чем для аналогичной конфигурации на основе контейнеров. Ресурсы, как правило, не безграничны, поэтому, чем меньше «весят» ваши приложения, тем плотнее их можно разместить на серверах. Все Linux-контейнеры, работающие на компьютере, используют одну и ту же операционную систему, поэтому ваши приложений и сервисы остаются легковесными и работают в параллельном режиме, не тормозя друг друга.
Краткая история контейнеров
Прародителем контейнеров можно считать технологию FreeBSD Jail, который появился в 2000 году. Он позволяет создавать внутри одной операционной системы FreeBSD несколько независимых систем, работающих на ее же ядре, так называемых «тюремных камер» (jails). Камеры задумывались как изолированные среды, которые администратор может безопасно предоставлять внутренним пользователям или внешним клиентам. Поскольку камера строится на основе вызова chroot и представляет собой виртуальную среду со своими файлами, сетью и пользователями, процессы не могут выйти за пределы камеры и повредить основную ОС. Однако в силу конструктивных ограничений механизм Jail все же не обеспечивает полной изоляции процессов, и со временем появились способы «побега» из камеры.
Но сама идея была многообещающей, и уже в 2001 году на платформе Linux появился проект VServer, созданный, по словам его основателя, Жака Гелинаса (Jacques Gélinas), для того, чтобы запускать «несколько стандартных Linux-серверов на одной машине с высокой степенью независимости и безопасности». Таким образом, в Linux появился фундамент для реализации параллельно работающих пользовательских сред, и постепенно стало вырисовываться то, что мы сегодня называем контейнерами.
На пути к практическому использованию
Крупным и быстрым шагом на пути к изоляции стала интеграция уже имеющихся технологий. В частности, механизма cgroups, действующего на уровне ядра Linux и ограничивающего использование системных ресурсов процессом или группой процессов, с системой инициализации systemd, отвечающей за создание пользовательского пространства и запуск процессов. Объединение этих механизмов, изначально созданных для того, чтобы повысить общую управляемость в Linux, позволило значительно лучше контролировать изолированные процессы и заложило основу для успешного разделения сред.
Следующая веха в истории контейнеров связана с развитием пространств имен пользователей (User namespaces), «позволяющих разделить присвоенные процессу идентификаторы пользователя и группы внутри и вне пространства имен. В контексте контейнеров это означает, что пользователи и группы могут иметь привилегии на выполнение определенных операций внутри контейнера, но не за его пределами». Это похоже на концепцию Jail, но более безопасно за счет дополнительной изоляции процессов.
Затем появилась система виртуализации Linux Containers project (LXC), которая предложила ряд крайне востребованных инструментов, шаблонов, библиотек и средств языковой поддержки, резко упростив использование контейнеров на практике.
Появление Docker
В 2008 на сцену вышла компания Docker (тогда она называлась dotCloud) с одноименной технологией, объединившей достижения LXC с продвинутыми инструментами для разработчиков и еще больше облегчившей использование контейнеров. Сегодня технология с открытым кодом Docker – это наиболее известный и популярный инструментарий развертывания и управления Linux-контейнерами.
Наряду с многими другими компаниями, Red Hat и Docker являются участниками проекта Open Container Initiative (OCI), целью которого является унификация стандартов управления контейнерными технологиями.
Стандартизация и Open Container Initiative
Проект Open Container Initiative работает под эгидой организации Linux Foundation. Он был учрежден в 2015 году «с целью создания открытых отраслевых стандартов контейнерных форматов и сред исполнения». В настоящий момент его главной задачей является разработка спецификаций для контейнерных образов и сред исполнения.
Спецификация среды исполнения задает набор открытых стандартов, описывающих состав и структуру комплекта файловой системы контейнера (filesystem bundle), и то, как этот комплект должен распаковываться средой исполнения. В основном, эта спецификация нужна для того, чтобы контейнер работал, как задумано, и все необходимые ресурсы были доступны и находились в нужных местах.
Спецификация контейнерных образов определяет стандарты для «манифеста образа, сериализации файловой системы и конфигурирования образа».
Вместе две эти спецификации определяют то, что находится внутри контейнерного образа, а также его зависимости, окружения, аргументы и другие параметры, необходимые для корректного выполнения контейнера.
Контейнеры как абстракция
Linux-контейнеры – это очередной эволюционный шаг в развитии методов разработки, развертывания и сопровождения приложений. Обеспечивая переносимость и управление версиями, образ контейнера гарантирует, что если приложение работает на компьютере разработчика, то оно будет работать и в промышленной среде.
Требуя меньше системных ресурсов по сравнению с виртуальной машиной, Linux-контейнер почти не уступает ей в возможностях изоляции и значительно облегчает сопровождение составных многоуровневых приложений.
Смысл Linux-контейнеров в том, чтобы ускорить разработку и помочь вам оперативно реагировать на требования бизнеса по мере их появления, а не предоставить какой-то конкретный софт для решения возникающих задач. Причем, в контейнер можно упаковывать не только приложения целиком, но и отдельные части приложения и сервисы, а затем использовать технологии наподобие Kubernetes для автоматизации и оркестрации таких контейнеризованных приложений. Иначе говоря, можно создавать монолитные решения, где вся логика приложения, runtime-компоненты и зависимости находятся в одном контейнере, или же строить распределенные приложения из множества контейнеров, работающих как микросервисы.
Контейнеры в промышленных средах
Контейнеры – это отличный способ ускорить доставку ПО и приложений заказчикам, используя их в промышленных средах. Но это закономерно повышает ответственность и риски. О том, как обеспечить безопасность контейнеров, рассказывает Джош Брессер, стратег по безопасности Red Hat.
«Я очень давно занимаюсь вопросами безопасности, и им почти всегда не придают должного значения до тех пор, пока технология или идея не становится мейнстримом, – сетует Брессер. – Все согласны, что это проблема, но так уж устроен мир. Сегодня мир захватывают контейнеры, и их место в общей картине безопасности начинает проясняться. Должен сказать, что контейнеры не являются чем-то особенным, это просто очередной инструмент. Но поскольку сегодня они в центре внимания, то пора поговорить об их безопасности.
Минимум раз в неделю меня заверяют, что запускать рабочие нагрузки в контейнерах – это безопасно, поэтому не стоит беспокоиться, что там внутри них. На самом деле все совсем не так, и такое отношение весьма опасно. Безопасность внутри контейнера важна в той же мере, что и безопасность на любом другом участке ИТ-инфраструктуры. Контейнеры уже здесь, они активно используются и распространяются с поразительной скоростью. Однако никакого волшебства по части безопасности в них нет. Контейнер безопасен настолько, насколько безопасно выполняющееся внутри него содержимое. Поэтому если ваш контейнер содержит кучу уязвимостей, то результат будет точно такой же, как и в случае «голого железа» с той же кучей уязвимостей».
Что не так с безопасностью контейнеров
Технология контейнеров меняет устоявшийся взгляд на вычислительную среду. Суть нового подхода в том, что у вас есть образ, который содержит только то, что вам нужно, и который вы запускаете только тогда, когда это нужно. У вас больше нет никакого постороннего софта, который установлен, но работает непонятно зачем и может стать причиной больших неприятностей. С точки зрения безопасности это называется «поверхность атаки». Чем меньше у вас запущено всяких вещей в контейнере, тем меньше эта поверхность, и тем выше безопасность. Однако даже если внутри контейнера запущено немного программ, вам все равно нужно убедиться, что содержимое контейнера не устарело и не кишит уязвимостями. Размер поверхности атак не имеет никакого значения, если внутри установлено нечто, что имеет серьезные уязвимости безопасности. Контейнеры не всемогущи, им тоже нужны обновления безопасности.
Banyan опубликовала отчет под названием «Более 30% официальных образов в Docker Hub имеют уязвимости безопасности с высоким уровнем критичности». 30% – это много. Поскольку Docker Hub является реестром общественного пользования, он содержит массу контейнеров, созданных самой разной публикой. И поскольку размещать контейнеры в таком реестре может кто угодно, никто не поручится, что свежеопубликованный контейнер не содержит старого «дырявого» ПО. Docker Hub – это и благословение, и проклятие. С одной стороны, он экономит массу времени и усилий при работе с контейнерами, с другой, не дает никаких гарантий, что загруженный контейнер не содержит известные уязвимости безопасности.
Большинство этих уязвимых образов не являются вредоносными, никто не встраивал в них «дырявый» софт со злым умыслом. Просто кто-то в свое время упаковал софт в контейнер и выложил его на Docker Hub. Прошло время, и в софте обнаружилась уязвимость. И до тех пор, пока кто-нибудь не будет за этим следить и заниматься обновлением, Docker Hub так и будет рассадником уязвимых образов.
При развертывании контейнеров базовые образы обычно «подтягиваются» из реестра. Если это реестр общественного пользования, то не всегда можно понять, с чем вы имеете дело, и в некоторых случаях получить образ с весьма серьезными уязвимостями. Содержимое контейнера – это действительно важно. Поэтому ряд организаций начинают создавать сканеры, которые заглядывают внутрь контейнерных образов и сообщают о найденных уязвимостях. Но сканеры – это только половина решения. Ведь после того, как уязвимость найдена, для нее нужно найти и установить обновление безопасности.
Конечно, вы можете полностью отказаться от сторонних контейнеров, чтобы разрабатывать их и управлять ими исключительно собственными силами, но это очень непростое решение, и оно может серьезно отвлечь вас от основных задач и целей. Поэтому гораздо лучше найти партнера, который разбирается в безопасности контейнеров и умеет решать соответствующие проблемы, чтобы вы могли сосредоточиться на том, что вам действительно нужно.
Решения Red Hat для контейнеров
Red Hat предлагает полностью интегрированную платформу для внедрения Linux-контейнеров, которая подходит как для небольших пилотных проектов, так и для комплексных систем на основе оркестрируемых мультиконтейнерных приложений – от операционной системы для хоста, где работают контейнеры, до верифицированных контейнерных образов для построения собственных приложений или же платформы оркестрации и средства управления для промышленной контейнерной среды.
Инфраструктура
Платформа
Управление
Контейнеры Linux – еще один эволюционный шаг в том, как мы разрабатываем, развертываем и управляем приложениями. Они обеспечивают переносимость и контроль версий, помогая гарантировать, что работающее на ноутбуке разработчика будет работать на производстве.
Используете ли вы контейнеры в своей работе и как оцениваете их перспективы? Поделитесь своей болью, надеждами и успехами.
LXC aka Linux Container: простота и надёжность
Что такое LXC? 
Аббревиатура расшифровывается просто Linux Container. Это контейнерная система виртуализации, которая действует в пределах операционной системы Linux. Что это значит? С LXC можно запустить несколько полностью изолированных и независимых друг от друга экземпляров ОС Linux на одном компьютере. Помимо этого есть возможность создать надежный кластер из нескольких десятков серверов, когда один и тот же экземляпр контейнера выполняется сразу на нескольких физических машинах и в случае выхода из строя одного сервера работа контейнера не приостанавливается ни на минуту. Так же данные контейнера находятся сразу на нескольких хранилищах, реализуется это различными методами (ceph ). Что позволяет помимо живой миграции контейнера между нодами кластера так же еще больше повысить надежность хранения данных, гибко увеличивать дисковую подсистему контейнера в пределах … ну пределы практически неограничены –настолько насколько хватит хранилища, а хранилища могут быть очень большие, например, в нашем случае мы сейчас строим хранилище в несколько петабайт информации.
Немного о механизмах виртуализации
В чем разница между виртуальными машинами и контейнерами? традиционные типы виртуализации, например, KVM тратят ресурсы сервера на обcлуживание самой виртуальной среды, в случае же контейнера до 95% мощности отдается непосредственно в контейнер и он работает по сути на уровне хостовой машины. Замеры производительности контейнеров мы приведем ниже в этой статье.
Сравнение LXC и KVM
| LXC | KVM |
|---|---|
| Изменение размера диска – в случае контейнера LXC увеличение или уменьшение диска происходит очень быстро практически на «лету» | Так как KVM это полноценно изолированный контейнер измение размера диска требует перезагрузки виртуальной машины, все как на физическом сервере |
| Расщирение RAM, ядер CPU, диска etc. Не требует перезагрузки, если требуется непрерывная работа виртуальной машины то выбор очевиден | При любых изменениях в параметрах VPS требуется перезагрузка |
| Быстрая перезагрузка контейнера | Как писали выше – KVM требует столько же времени на рестарт как и обычный сервер |
| Быстрая установка любого образа как операционной системы так и готовых шаблонов (OpenVPN, TorrenServer,OpenLDAP,MediaServer, OwnCloud у нас больше 100 различных шаблонов на все случаи жизни) | Возможность установки различных версий Windows и FreeBSD как из шаблонов так и из собственного ISO |
| Создание собственной внутренней сети между контейнерами | Создание собственной внутренней сети между контейнерами |
По сути, LXC и не является полноценной системой виртуализации. Виртуального аппаратного окружения как такового нет, зато создаётся безопасное изолированное пространство. LXC отличается высокой функциональностью, компактностью и гибкостью в отношении ресурсов, необыкновенной результативностью, простотой использования. С этим механизмом вы сможете создать дата-центр состоящий из нескольких контейнеров для различных целей. Как пример один контейнер мы настраиваем как роутер и firewall за ним распологаем в сегменте DMZ –web, почтовый и file сервера.
Создание контейнера на примере нашего хостинга
Итак приступим к заказу (ссылка на корзину) – выбираем имя хоста, пароль для root, параметры CPU, RAM и диска, далее переходим к выбору шаблона для контейнера и жмем «Далее», для тестов мы сделали промо-код HelloHabr, который позволит месяц тестировать совершенно бесплатно. Далее регистрируемся в билинге и если что-то пошло не так создаем запрос в сапорт. Заходим в клиентский кабинет выбираем свежесозданный контейнер и приступаем к тестам. Какие же возможности по доступу нам предлагают в личном кабинете – самое простое это noVNC консоль которая позволяет управлять контейнером непосредственно из браузера:
… далее SPICE консоль — представляет собой систему отображения (рендеринга) удаленного дисплея, построенную для виртуальной среды, которая позволяет вам просматривать виртуальный «рабочий стол» вычислительной среды не только на машине, на которой он запущен, но и откуда угодно через Интернет(из wiki), так же в разделе Backup мы можем сделать как мгновенный снимок контейнера, так и полное резервное копирование виртуально машины, есть возможность выбрать как тип архива, так и вид копии.
Также мы можем настроить задания для Backup которые будут выполнятся по определенному расписанию с оповещением на емейл.
Также хотел бы отметить еще одну удобную опцию – настройка firewall непосрдественно из бразуера, что очень удобно для тех кто не владеет тонкими настройками firewall в Linux. Все очень удобно как для опытных администраторов, так и совсем начинающих.
Тестирование производительности
Я для тестов взял самую начальную конфигурацию и теперь хочу посмотреть насколько ее хватает для простых задач, тестировать производительность я буду с помощью пакета unixbench сначала добавим недостающие пакеты
далее скачиваем сам unixbench и приступаем к тестированию —
Ждем пока unixbench потестирует контейнер и любуемся результатом
Также хотел бы напомнить про наши выделенные сервера с защитой от ДДОС атак
Сейчас вы можете заказать 2x Intel Xeon E5540 с 32Gb ECC DDR3 RAM с полной защитой и SSD диском на 240Gb всего за 3127 руб. Также всегда в наличии Intel Core i7-7700 от 3769 руб
За дополнительными скидками велкам в личку