Что такое контейнер в linux

LXC aka Linux Container: простота и надёжность

Что такое LXC?

Аббревиатура расшифровывается просто Linux Container. Это контейнерная система виртуализации, которая действует в пределах операционной системы Linux. Что это значит? С LXC можно запустить несколько полностью изолированных и независимых друг от друга экземпляров ОС Linux на одном компьютере. Помимо этого есть возможность создать надежный кластер из нескольких десятков серверов, когда один и тот же экземляпр контейнера выполняется сразу на нескольких физических машинах и в случае выхода из строя одного сервера работа контейнера не приостанавливается ни на минуту. Так же данные контейнера находятся сразу на нескольких хранилищах, реализуется это различными методами (ceph ). Что позволяет помимо живой миграции контейнера между нодами кластера так же еще больше повысить надежность хранения данных, гибко увеличивать дисковую подсистему контейнера в пределах … ну пределы практически неограничены –настолько насколько хватит хранилища, а хранилища могут быть очень большие, например, в нашем случае мы сейчас строим хранилище в несколько петабайт информации.

Немного о механизмах виртуализации

В чем разница между виртуальными машинами и контейнерами? традиционные типы виртуализации, например, KVM тратят ресурсы сервера на обcлуживание самой виртуальной среды, в случае же контейнера до 95% мощности отдается непосредственно в контейнер и он работает по сути на уровне хостовой машины. Замеры производительности контейнеров мы приведем ниже в этой статье.

Сравнение LXC и KVM

По сути, 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 руб
За дополнительными скидками велкам в личку

Источник

Контейнеры LXC в Linux

LXC можно расценивать как что-то среднее между изолированным окружением chroot и полноценной технологией виртуализации Qemu, Xen, KVM или VirtualBox. Поскольку все программы выполняются на реальном железе, без использования виртуализации, то вы не теряете производительность, в отличие от случая если бы вы использовали VirtualBox. Вы можете очень легко запустить параллельно несколько контейнеров в своей системе, даже при очень низких аппаратных ресурсах, чего нельзя сделать с полноценными технологиями виртуализации.

В этой небольшой статье мы рассмотрим как выполняется установка и настройка LXC в Ubuntu, а также как использовать эту технологию.

Что такое контейнеры LXC?

Виртуальные окружения создаются с помощью встроенных в ядро механизмов. Это в первую очередь улучшенный механизм chroot, который изолирует файловую систему контейнера от основной файловой системы. Но, как вы знаете в chroot есть один недостаток, вы не можете запустить систему инициализации, поскольку программа с таким PID уже существует, но это необходимо для управления процессами и службами.

Для решения этой проблемы используются пространства имен PID, с помощью этого механизма PID процессов контейнера не зависят от основной системы и других контейнеров, а поэтому мы можем очень просто запустить систему инициализации. Ну и наконец нужно управлять ресурсами, для этого используется механизм cgroups.

Благодаря всему этому потеря производительности при использовании контейнеров LXC Linux составляет не более 1%. Теперь, когда вы знаете как все это работает, перейдем к описанию процесса установки LXC.

Установка и настройка LXC

В этой инструкции мы будем настраивать LXC в Ubuntu, поскольку это самая популярная операционная система, но все эти команды подойдут для всех других дистрибутивов. Отличие составляет только команда установки. Сначала нужно установить все необходимое программное обеспечение. Установка LXC на Ubuntu выполняется командой:

sudo apt install lxc lxc-templates uidmap

Дальше нужно задать базовые настройки, которые будут применяться для создания сети в контейнерах и установки других параметров. Сначала создаем папку с конфигурацией:

Настроим пользовательские пространства имен. Первая цифра означает первый UID пользователя linux в контейнере, вторая отвечающий ему UID пользователя в основной системе:

echo «lxc.id_map = u 0 100000 65536» >>

/.config/lxc/default.conf
echo «lxc.id_map = g 0 100000 65536» >>

Дальше настраиваем сеть в контейнере:

echo «lxc.network.type = veth» >>

/.config/lxc/default.conf
echo «lxc.network.link = lxcbr0» >>

/.config/lxc/default.conf
echo «lxc.network.flags = up» >>

Затем в файле /etc/lxc/lxc-usernet нужно разрешить использовать сетевые интерфейсы текущему пользователю, чтобы получить возможность запускать контейнер без root прав:

Для того чтобы пространства имен пользователей linux в контейнере работали нужно присвоить своему пользователю подпространство UID и GID 100000-165536:

И даем права на использование данного пользователя в cgm:

Теперь первоначальная настройка завершена и мы готовы перейти к загрузке и установке образа контейнера. Для установки в интерактивном режиме наберите такую команду, здесь ubu1, это имя будущего контейнера:

В этом списке вам предстоит выбрать нужную операционную систему. Просто введите необходимые параметры, имя, релиз и архитектура, выбрав их из списка доступных, например, для Ubuntu Yakkety Yak 64 бит:

Затем начнется загрузка уже готового, настроенного образа из интернета. Это может занять довольно много времени если у вас медленный интернет.

Также вы можете использовать не интерактивный режим и указать все необходимые параметры сразу в командной строке:

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

Использование контейнеров LXC

После всех проделанных выше действий мы можем перейти к запуску контейнера. Для этого используйте команду lxc-start с именем вашего контейнера, например:

Подключение к контейнеру

Чтобы подключиться к терминалу контейнера используйте команду lxc-attach:

После подключения вы получаете полный root доступ к файлам в контейнере, дальше рекомендуется задать пароль root и создать пользователя:

Настройка системы или установка программ выполняется точно так же, как и в обычной системе, например установка программ:

apt install wget openssh-server htop tmux nano iptables

Выключение контейнера

Когда вы завершили все работы в контейнере, его можно выключить, чтобы он не отнимал системные ресурсы. Для этого выполните:

Эта команда проведет правильное завершение работы контейнера и он больше не будет потреблять ресурсов системы, кроме дискового пространства.

Клонирование контейнеров

После того как вы установили все необходимые программы в контейнере и настроили его как нужно, можно создать несколько его копий для упрощения настройки новых контейнеров и экспериментов. Для этого есть команда clone, которая создает полную копию контейнера:

Для примера давайте создадим клон контейнера ubu1 с именем ubu2. Сначала нужно остановить контейнер:

Затем вы опять можете использовать lxc-ls, чтобы убедится, что контейнер был создан:

Моментальные снимки

Если вы хотите экспериментировать с контейнером, вносить какие-либо изменения, которые будет трудно исправить, то можно сделать снимок контейнера, чтобы потом вернуть все как было, с помощью одной команды восстановив снимок. Чтобы создать снимок тоже нужно остановить контейнер:

Затем используйте команду lxc-snapshot для создания снимка:

Вам нужно указать имя снимка и имя контейнера.

Запуск контейнера при старте системы

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

lxc.start.auto = 1
lxc.start.delay = 5

Первая строка означает, что контейнер нужно запускать при старте системы,а вторая указывает, что нужно подождать пять секунд перед запуском следующего контейнера, если такие есть.

Решение проблем

Проанализировав вывод команды, вы сможете понять в чем дело и исправить проблемы. Если вы пытаетесь запустить несколько контейнеров одновременно, то можете получить ошибки типа «Quota reached» или «failed to create the configured network». Это потому что вы используете больше сетевых интерфейсов, чем было разрешено. Мы задавали этот параметр в файле /etc/lxc/lxc-usernet. Вначале мы усказали, что можно использовать два сетевых интерфейса, но можно сделать 5:

sudo vi /etc/lxc/lxc-usernet

losst veth lxcbr0 5

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

Выводы

Контейнеры Linux можно использовать для решения огромного количества задач. Начиная от средства тестирования настроек или нового программного обеспечения и до изоляции своих приложений для обеспечения максимальной безопасности системы. Обратите внимание, что вы даже можете запускать приложения с графическим интерфейсом с помощью контейнеров.

Установка и настройка LXC Linux полностью рассмотрена и я надеюсь, теперь вам стало понятнее как работать с этой технологией. Ее полезность ограничена только вашей фантазией, так что не бойтесь экспериментировать. Если остались вопросы по настройке контейнеров, спрашивайте в комментариях!

На завершение видео с конференции LinuxPiter, где рассказывается подробно что такое контейнеры Linux и действительно ли они настолько безопасны:

Источник

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 в деталях — LXC и OpenVZ. Часть 1

В прошлой статье мы начали разговор о преимуществах контейнерной изоляции (контейнеризации), теперь мне бы хотелось углубится в технические аспекты реализации контейнеров.

Контейнеризация в Linux

Механизмы, которые обеспечивают работу контейнеров внутри ядра, называются namespaces (вот хороший обзор данной функциональности). Кроме этого, за ограничения различных ресурсов контейнера (объем занимаемой памяти, нагрузка на диск, нагрузка на центральный процессор) отвечает механизм ядра — cgroups (обзор). А в свою очередь обе эти технологии для удобства повествования я решил объединить под названием Linux upstream containers, то есть контейнеры из актуальной версии Linux ядра с kernel.org.

Если же говорить о пространстве пользователя, то такие пакеты как LXC, systemd-nspawn и даже vzctl (утилита из проекта OpenVZ) занимаются исключительно тем, что создают/удаляют namespac’ы и конфигурируют для них cgroup’ы.

Что такое OpenVZ?

Если с Linux upstream containers все более-менее понятно, так как они входят в ядро Linux, то для OpenVZ потребуются пояснения. OpenVZ — это open source проект развиваемый компанией Parallels (называвшейся ранее SwSoft) с 2005 года (уже более 8 лет) и занимающийся разработкой и поддержкой production ready решения по контейнеризации на базе ядра Linux (патчи накладываются на ядра от RHEL).

Данный проект состоит из двух частей — Linux ядра с патчами от компании Parallels (vzkernel), а также набора утилит для управления ядром (vzctl, vzlist и проч). Так как модифицированное ядро от OpenVZ строится на базе ядра Red Hat Enterprise Linux, то логично предположить, что рекомендованная ОС для OpenVZ — это RedHat либо CentOS. Также недавно была осуществлена очень большая работа по предоставлению поддержки OpenVZ в Debian 7 Wheezy, но со своей стороны я все равно рекомендуют использовать OpenVZ исключительно на CentOS 6.

На данный момент в мире насчитывается более 25 тысяч серверов (стоит отметить, что в связи с особенностями сбора статистики, данные несколько занижены) с установленным OpenVZ, подробную статистику можно увидеть тут: https://stats.openvz.org/

История развития OpenVZ

История развития Linux upstream containers

Две фундаментальных технологии лежат в основе Linux upstream containers — это namespaces и cgroups. Фреймворк namespaces в виде mount namespace был впервые представлен в 2000 году известным разработчиком Al Viro (Alexander Viro). В свою же очередь фреймворк cgroup был разработан в Google, с участием инженеров Paul Menage и Rohit Seth.

Также очень большой вклад в разработку новых подсистем namespaces/cgroups внесли разработчики проекта OpenVZ. В частности, namespace’ы PID и Net были разработаны в контексте проекта OpenVZ. Кроме этого, недавно был переведен в стабильную фазу фреймворк Criu для сериализации/десериализации наборов работающих Linux процессов lwn.net/Articles/572125, разрабатывался он также в контексте решения задач для OpenVZ.

Если Вы хотите оценить вклад самостоятельно, предлагаю два документа — отчет о вкладе компаний в разработку ядра в 2013 году и аналогичный отчет за 2012й год: Parallels там имеет вклад 0.7% и 0.9% соответственно. Может показаться, что 1% — это мало, то хотелось бы напомнить, что размер правок в год достигает нескольких миллионов строк.

Если Вы уже используете OpenVZ и у Вас есть что сообщить (баги) или чем поделиться (патчи), то милости прошу в баг-трекер OpenVZ Каждый Ваш бег репорт улучшает стабильность и качество проекта для всех его пользователей!

Техническая реализация подсистемы изоляции контейнеров

Тут я хотел бы пойти по пути, через который, уверен, проходил каждый системный администратор, у которого стояла задача «изолировать пользователей друг от друга» в пределах одного Linux сервера.

Итак, допустим у нас имеется два веб-приложения, которые принадлежат разным клиентам (обращаю внимание, я тут не использую термин «пользователи», чтобы не было путаницы с Linux пользователями) и не должны никак влиять друг на друга (например, при взломе, перегрузке, исчерпании ресурсов) и тем более на сам физический сервер.

Давайте последовательность предпринимаемых шагов представим в виде списка:

Что ждать в продолжении?

Отдельно хотелось бы поблагодарить Andrey Wagin avagin за помощь в редактуре особо сложных технических вопросов.

С уважением,
CTO хостинг-компании FastVPS
Павел Одинцов

Источник