Контейнеры lxc: Туториал по контейнеризации при помощи LXC

Туториал по контейнеризации при помощи LXC

Пришло время научиться работать с Linux Containers, более известными под названием LXC. Далее мы будем рассматривать LXC в контексте Debian и Ubuntu, но написанное во многом будет применимо и для других дистрибутивов Linux. Мы коснемся не только основ использования LXC, но и узнаем, как настроить bridged сеть, ограничить количество ресурсов, используемых контейнером, и даже осилим unprivileged containers.

Коротко о главном

LXC — технология контейнерной виртуализации, как и OpenVZ. Накладные расходы на создание контейнеров очень невелики, и ничто не мешает нам запускать их сотнями или тысячами. Что невозможно при использовании честной и полноценной виртуализации, такой, как KVM. С другой стороны, запустить в контейнере ОС, отличную от Linux, мы не можем. На самом деле, не совсем корректно называть LXC отдельной технологией. Все работает сразу на нескольких фичах ядра Linux. Как минимум, это cgroups и namespaces.

Control Groups, они же cgroups, позволяют организовывать процессы в группы и для каждой группы задавать лимиты. Например, лимиты на использование CPU, объем используемой памяти и дисковый ввод-вывод.

Namespaces бывают разные — PID namespace, IPC namespace, UTS namespace, user namespace, mount namespace, network namespace. Неймспейсы изолируют друг от другая процессы таким образом, что процессы в одной группе не могут видеть ресурсы другой группы. Например, PID namespace предоставляет уникальные идентификаторы процессов в рамках группы. Внутри одной группы может быть процесс с pid’ом 1 и внутри второй группы тоже может быть процесс с pid’ом 1, хотя это два совершенно разных процесса, которые друг о другие ничего не знают. Притом, все процессы все также имеют уникальные id в рамках ОС. Просто, если смотреть на процессы из группы, то эти id отображаются в другие.

В отличие от Docker, который заточен на создание PaaS, в LXC нет никаких слоеных неизменяемых файловых систем. Контейнеры очень похожи на VDS’ы, как и в OpenVZ. Но в отличие от OpenVZ, в LXC далеко не все есть из коробки. Как мы скоро убедимся, для ограничения места на диске, используемого контейнером, приходится прибегать к дополнительным ухищрениям. Повторюсь, связано это с тем, что LXC не совсем одна полноценная технология. С другой стороны, LXC не нуждается в пропатченном ядре. Все необходимое уже и так есть в ванильном ядре Linux. Как следствие, LXC превосходно работает на самой обычной Ubuntu, чем OpenVZ похвастаться не может.

Примечание: Кстати, в заметке Начало работы с Vagrant и зачем он вообще нужен рассказывается, как работать с LXC через Vagrant. Использование LXC через Vagrant кому-то может показаться удобнее, чем работа с LXC напрямую.

Установка

Как было отмечено выше, все необходимое уже есть в ядре. Тем не менее, для хождения в ядро понадобятся некоторые дополнительные утилиты. Также не повредит обновить до последней версии кое-какие, казалось бы, не особо связанные с LXC пакеты.

Итак:

sudo apt-get update
sudo apt-get install lxc lxc-templates systemd-services cgroup-bin \
  bridge-utils debootstrap

Очень важно реально сделать update, чтобы поставились наиболее свежие версии указанных пакетов. И, не поверите, но реально лучше сразу сделать reboot. Иначе, работая с LXC, вы в какой-то момент можете получить странную ошибку вроде такой:

call to cgmanager_create_sync failed: invalid request

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

Свои данные LXC хранит в следующих местах:

• /var/lib/lxc — тут лежат контейнеры, их настройки, ФС и так далее;
• /etc/lxc — прочие настройки;
• /etc/default/lxc-net — тут можно поменять настройки сети;
• /var/cache/lxc — кэш шаблонов;
• /var/lib/lxcsnaps — сюда пишутся снапшоты;
• /var/log/lxc — логи;

Теперь рассмотрим команды для управления контейнерами.

Основные команды

Создание контейнера с именем test-container из шаблона Ubuntu:

sudo lxc-create -n test-container -t ubuntu

Увидим что-то вроде:

##
# The default user is ‘ubuntu’ with password ‘ubuntu’!
# Use the ‘sudo’ command to run tasks as root in the container.
##

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

ls /usr/share/lxc/templates/

Список скачанных шаблонов:

Удалить шаблон можно просто удалив соответствующий ему каталог.

Запуск контейнера в бэкграунде:

sudo lxc-start -d -n test-container

Для отладки — запуск с логированием:

sudo lxc-start -l debug -o 1.log -d -n test-container

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

Подробная информация о контейнере:

sudo lxc-info -n test-container

Заходим в контейнер:

sudo lxc-console -n test-container

В нашем случае логин и пароль — ubuntu. Для выхода из контейнера жмем Ctr+A, затем Q.

Остановка контейнера:

sudo lxc-stop -n test-container

Создание клона контейнера (test-container должен быть остановлен):

sudo lxc-clone -o test-container -n test-container-clone

Удалить контейнер:

sudo lxc-destroy -n test-container

Заморозить/разморозить контейнер:

sudo lxc-freeze -n test-container
sudo lxc-unfreeze -n test-container

Создать снапшот (контейнер должен быть остановлен):

sudo lxc-snapshot -n test-container

Список снапщотов:

sudo lxc-snapshot -n test-container -L

Восстановление из снапшота:

sudo lxc-snapshot -n test-container -r snap0

Если нужно пошарить каталог, проще всего сделать это при помощи sshfs:

sshfs ubuntu@10. 110.0.10: ./shared-dir

Пока ничего сложного.

Автозапуск

Чтобы контейнер запускался при старте системы, в конфиг контейнера (в нашем случае это файл /var/lib/lxc/test-container/config) дописываем:

lxc.start.auto  =  1 # enabled
lxc.start.delay = 15 # delay in seconds
lxc.start.order = 50 # higher value means starts earlier

Если все было сделано верно, команда sudo lxc-ls -f покажет YES в колонке autostart.

Ограничение на использование ресурсов

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

Останавливаем контейнер:

sudo lxc-stop -n test-container

Затем правим /var/lib/lxc/test-container/config:

lxc.cgroup.memory.limit_in_bytes = 256M

Говорим:

sudo lxc-start -d -n test-container -l debug -o test.log
cat test.log  | grep -i memory

Должны увидеть что-то вроде:

lxc-start 1449237148.829 DEBUG lxc_cgmanager — cgmanager.c:
cgm_setup_limits:1385 — cgroup ‘memory. limit_in_bytes’ set to ‘256M’

Проверяем, что настройки применились:

sudo lxc-cgroup -n test-container memory.limit_in_bytes

Можно менять лимиты на лету, но они потеряются с рестартом:

sudo lxc-cgroup -n test-container memory.limit_in_bytes 100M

Также можно следить, сколько ресурвов потребляет контейнер прямо сейчас:

cat /sys/fs/cgroup/memory/lxc/test-container/memory.usage_in_bytes

Вот еще интересные параметры:

• cpu.shares — сколько единиц процессорного времени отдавать контейнеру, если у одного 2000 единиц, а у второго 1000, второй получит в два раза меньше времени;
• cpuset.cpus — какие ядра может использовать контейнер, номера начиная с нуля, например 0,1 или 0-3;
• memory.memsw.limit_in_bytes — ограничение на память и своп в сумме, если своп вообще есть;
• blkio.weight — как cpu.shared, только про дисковый ввод-вывод;

Тут больше параметров — есть, к примеру, про сеть.

Ограничение на использование дискового пространства

Эту задачу можно решить несколькими способами. Например, многие советуют использовать LVM. И хотя LVM, бесспорно, крутая штука, использовать его для решения такой простой задачи мне лично кажется оверкилом. Предлагаю пойти более простым путем.

Допустим, мы хотим создать контейнер с именем new-container, который будет занимать на диске не более 10 Гб.

sudo truncate -s 10G /var/lib/lxc/new-container.img
sudo mkfs.ext4 -F /var/lib/lxc/new-container.img
sudo mkdir /var/lib/lxc/new-container
sudo mount -t ext4 -o loop /var/lib/lxc/new-container.img \
  /var/lib/lxc/new-container

Теперь создаем контейнер, как обычно:

sudo lxc-create -t ubuntu -n new-container

Заходим внутрь контейнера, и через df видим, что отъесть от диска он может только 10 Гб.

Чтобы не приходилось каждый раз монтировать раздел руками, в /etc/fstab дописываем:

/var/lib/lxc/new-container. img /var/lib/lxc/new-container ext4 loop 0 0

Вы можете заметить, что количество loop-устройств в системе ограничено. В Ubuntu, например, их по умолчанию только 8. Если попытаться создать много контейнеров описанным выше образом, вы получите ошибку:

mount: could not find any free loop device

Эту проблему можно решить следующим скриптом:

#!/bin/sh

for i in $(seq 0 64); do
  [ -b /dev/loop$i ] || (mknod -m 660 /dev/loop$i b 7 $i && \
     chown root:disk /dev/loop$i)
done

Чтобы loop-устройства создавались при загрузке системы, создаем файл /etc/init.d/more-loop-devices следующего содержания:

#!/bin/bash

### BEGIN INIT INFO
# Provides:          more-loop-devices
# Required-Start:    $syslog
# Required-Stop:     $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: More Loop Devices
# Description:       More Loop Devices
### END INIT INFO

PATH=/sbin:/usr/sbin:/bin:/usr/bin

# Load the VERBOSE setting and other rcS variables
. /lib/init/vars.sh
. /lib/lsb/init-functions

case «$1» in
  start)
    for i in $(seq 0 64); do
      [ -b /dev/loop$i ] || (mknod -m 660 /dev/loop$i b 7 $i && \
         chown root:disk /dev/loop$i)
    done
    ;;
  *)
    echo «Usage: more-loop-devices start» >&2
    exit 1
    ;;
esac

Говорим:

sudo chmod a+x /etc/init.d/more-loop-devices
sudo update-rc.d more-loop-devices defaults

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

Настройка bridged сети

Ранее в заметке Контейнерная виртуализация при помощи OpenVZ мы научились настраивать bridged сеть под CentOS. Настало время узнать, как то же самое делается в Debian и Ubuntu.

Правим /etc/network/interfaces — часть про eth0 убираем, вместо нее пишем:

auto eth0
iface eth0 inet manual

Далее, если у вас DHCP:

auto br0
iface br0 inet dhcp
        bridge_ports eth0
        bridge_stp off
        bridge_fd 0
        bridge_maxwait 0

Если же у вас используются статические адреса:

auto br0
iface br0 inet static
        address 192. 168.0.123
        network 192.168.0.0
        netmask 255.255.255.0
        broadcast 192.168.0.255
        gateway 192.168.0.1
        bridge_ports eth0
        bridge_stp off
        bridge_fd 0
        bridge_maxwait 0

Перезагружаемся.

Если все было сделано правильно, в ifconfig’е увидим интерфейс br0.

Далее останавливаем контейнер и правим /var/lib/lxc/(container)/config:

Если хотим присвоить контейнеру статический IP, также дописываем:

lxc.network.ipv4.gateway = 192.168.0.1
lxc.network.hwaddr = 00:16:3e:6b:c7:5b
lxc.network.ipv4 = 192.168.0.124/24

Запускаем контейнер. Если все было сделано правильно, в контейнер можно будет ходить из локалки и sudo lxc-ls -f покажет у него соответствующий IP.

Резервное копирование и восстановление

Как уже отмечалось, все лежит в /var/lib/lxc. Поэтому просто нужно аккуратно заархивировать все данные оттуда. Тут каждый использует, что ему больше нравится. Для примера рассмотрим решение задачи при помощи tar.

Останавливаем контейнер, под рутом делаем:

cd /var/lib/lxc/test-container
tar -cvzf backup.tgz ./

Резервная копия готова! Для восстановления же говорим:

mkdir -p /var/lib/lxc/test-container
cd /var/lib/lxc/test-container
scp example.ru:path/to/backup.tgz ./
tar -xvzf backup.tgz
rm backup.tgz

Теперь контейнер виден в lxc-ls и может быть запущен через lxc-start.

Если описанным образом вы создаете копию контейнера (вам чем-то не подошел lxc-clone) или при восстановлении контейнера решили его переименовать, придется чуть-чуть подправить файл config. Там просто нужно поменять пути и изменить имя контейнера, плюс я бы сменил на всякий случай MAC.

В общем-то, это все. Ну разве что у tar’а еще флаг --numeric-owner рекомендуют использовать.

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

Непривилегированные контейнеры

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

При этом каталоги немного меняются:

• ~/.local/share/lxc — тут лежат контейнеры, их настройки, ФС и так далее;
• ~/.config/lxc — прочие настройки;
• ~/.cache/lxc — кэш шаблонов;
• ~/.local/share/lxcsnaps — сюда пишутся снапшоты;

Первым делом говорим:

sudo usermod —add-subuids 100000-165536 eax
sudo usermod —add-subgids 100000-165536 eax
sudo chmod +x /home/eax

… где eax — имя вашего пользователя в системе.

Только что мы выделили 65536 uid’ов и gid’ов пользователю eax. В контейнере будут использоваться айдишники от 0 до 65535, которые будут отображаться в айдишники от 100000 до 165535 в хост-системе.

Далее:

Копируем /etc/lxc/default.conf в ~/.config/lxc/default.conf и дописываем в конце:

lxc.id_map = u 0 100000 65536
lxc. id_map = g 0 100000 65536

В файл /etc/lxc/lxc-usernet пишем:

# USERNAME TYPE BRIDGE COUNT
eax        veth lxcbr0 100

Создаем контейнер (как видите, без sudo):

lxc-create -t download -n test-container — -d ubuntu \
  -r trusty -a amd64

Заметьте, как это работает. Мы указали тип контейнера download, которому передали в качестве аргумента название дистрибутива, релиза и архитектуры CPU. Все эти три параметра обязательны при создании непривилегированных контейнеров.

Теперь запускаем контейнер, как обычно:

lxc-start -d -n test-container

В случае возникновения проблем:

lxc-start -d -n test-container —logfile t.log —logpriority debug

Дополнение: Чтобы непривилегированные контейнеры заработали, может потребоваться перезагрузка. Если вы используете encfs, команды sudo и ping могут не работать. Это баг. Здесь рассказывается, как примерно можно его обойти. Идея в том, чтобы при помощи симлинков положить контейнеры и конфиги за пределы encfs.

Шаблоны непривилегированных контейнеров немного отличаются от тех, что мы использовали раньше. В частности, никакого SSH по умолчанию в них не крутится. Но это легко исправить. Заходим в контейнер под рутом при помощи lxc-attach:

lxc-attach -n test-container

… и говорим:

apt-get install ssh
passwd ubuntu

Ну вот, а в остальном все как обычно.

Заключение

Не могу не отметить ряд косяков в LXC:

• У LXC довольно высокий порог вхождения и вообще все как-то неудобно. Я просто хочу, чтобы контейнер не отжирал больше 1 Гб памяти. Я не хочу ничего знать ни о каких cgroups и читать документацию по ним на сайте RedHat! Про то, как приходится плясать для банального ограничения места на диске, я вообще молчу. OpenVZ в этом плане намного, НАМНОГО лучше;
• В LXC все очень сыро и плохо документированно. Я собирал представленную в этом посте информацию по крупицам, наверное, около месяца, попутно гугля по поводу багов, на которые я натыкался в процессе. Вам, уважаемые читатели, в этом плане будет намного проще;
• На мой взгляд, интерфейс продуман плохо. Например, первое время я постоянно забывал флаг -d у lxc-start. Правда, потом я уже как-то то ли привык, то ли запомнил. Да и если контейнеры прописаны на автозагрузку, такой проблемы нет;
• Внутри контейнера мы видим занятую и свободную память хост-системы, а не контейнера. В результате, из контейнера не ясно, кто же отожрал всю память. К тому же, некоторые программы могут работать из-за этого некорректно;
• Неизбежны накладные расходы в случае ограничения используемого места на диске;
• Плохие сообщения об ошибках. Шаг влево, шаг вправо — и тут же получаем что-то в стиле «No such file or directory — execlp»;

Тем не менее, если вы хотите запихнуть что-то в контейнер под Ubuntu, и при этом вы не пишите PaaS’ов, LXC может быть для вас неплохим вариантом. Особенно теперь, когда вы знаете о большинстве подвобных граблей этой технологии.

Больше полезной информации вы найдете на сайте linuxcontainers.org, а также в списке рассылки lxc-users@. Если вас интересует, как запускать GUI-приложения под LXC, обратите внимание на заметку Осилил запуск GUI-приложений в Docker. Она без единого изменения применима и к LXC.

А используете ли вы LXC и если да, то для каких задач?

Дополнение: Также вас могут заинтересовать статьи Мой первый опыт использования Proxmox VE и Управление VirtualBox из консоли с помощью vboxmanage.

Метки: Linux, Виртуализация, Сети.

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

LXC (LinuX Containers) — система виртуализации на уровне операционной системы, позволяющая исполнять множество изолированных Linux-систем (контейнеров) в одной системе, то-есть получить полноценную виртуализацию уровня операционной системы на одном экземпляре ядра и используя только его функции.

Виртуализация на уровне операционной системы — метод виртуализации, при котором ядро операционной системы поддерживает несколько изолированных экземпляров пространства пользователя, вместо одного. Эти экземпляры (часто называемые контейнерами или зонами) с точки зрения пользователя полностью идентичны реальному серверу. Виртуализация на уровне операционной системы — метод виртуализации, при котором ядро операционной системы поддерживает несколько изолированных экземпляров пространства пользователя, вместо одного. Эти экземпляры (часто называемые контейнерами или зонами) с точки зрения пользователя полностью идентичны реальному серверу.

LXC  похож на Linux-VS и OpenVZ, за исключением того, что вместо внедрения в ядро соответствующих патчей ядра, он использует механизмы пространства имен (namespaces) и группировки процессов — cgroups (добавлено в версии ядра 2.6.24), доступные в любом современном Linux kernel.

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

Технология cgroups — это механизм группировки процессов и управления их ресурсами, такими как количество оперативной памяти, процессорные ресурсы, приоритеты ввода-вывода и доступа к сети.

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

Основные преимущества LXC — это возможность довольно гибко конфигурировать контейнеры, очень высокая степень безопасности и скорость работы — он быстрее, чем виртуализация, даже аппаратная, так как эмулировать ничего не надо.

Ну и основной недостаток, проистекающий от идеологии его построения — в контейнере могут функционировать только Linux системы.

Stéphane Graber (работает в Canonical в Ubuntu Foundations Team) и Serge Hallyn являются главными мейнтейнерами LXC.

До выхода первой версии LXC (LXC 1.0.0) работать с системой можно было только тестовом режиме: версии 0.X были достаточно сырыми и ненадежными.

LXC 1.0.0 явился результатом 10 месячной разработки и появился весной 2014 года в составе Ubuntu 14.04 LTS и был официально объявлен пригодным для промышленного применения. Первая версия является LTS — поддержка выпуска исправлений для ветки LXC 1.0 будет осуществляться в течение пяти лет.

В состав пакета LXC входит  входит библиотека liblxc, набор утилит (lxc-create, lxc-start, lxc-stop, lxc-ls и т.п.), шаблоны для построения контейнеров и набор биндингов для различных языков программирования.

Данный релиз имеет огромный список изменений, тем не менее вот список наиболее главных изменений:

Ключевые улучшения в LXC 1.0:

• Надежность и стабильность работы;
• Поддержка полностью непривилегированных контейнеров — пользователи могут создавать и управлять контейнерами без использования root-привилегий;
• Большая часть функциональности LXC теперь может быть доступна через API, экспортируемый из liblxc;
• Поставка официальных биндингов для использования API в программах на языках python3, lua, ruby и Go;
• Гибкая система размещения контейнеров в различных типах хранилищ. Поддерживается размещение контейнеров в обычном дереве директорий, в btrfs и zfs, в lvm, loop-устройствах, aufs и overlayfs;
• Поддержка клонирования работающих контейнеров и возможность заморозки их состояния через создание снапшотов;
• Сокращенный, но более внятный и структурированный набор утилит;
• Обновлённая и полноценная документация;
• Поддержка нескольких методов создания контейнеров на основе недавно сгенерированных образов;
• Поставка шаблонов для создания контейнеров на основе популярных дистрибутивов Linux. Шаблоны подготовлены для Alpine Linux, Alt Linux, Arch Linux, busybox, CentOS, Cirros, Debian, Fedora, OpenMandriva, OpenSUSE, Oracle, Plamo, sshd, Ubuntu Cloud и Ubuntu. В контейнере также можно запустить окружение Android;
• Возможность запуска графического окружения внутри контейнера.

Работа с LXC описана нашей базе знаний.

Сайт команды разработчиков LXC — linuxcontainers.org.

Оркестрация проектов с помощью менеджера контейнеров LXD

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

В Linux существует технология LXC, которая предоставляет производительный и гибко настраиваемый механизм контейнеризации. Использовать LXC напрямую не очень удобно, поэтому существуют различные интерфейсы, например, LXD. Сегодня он поддерживается всеми современными Linux-дистрибутивами. 

В этой статье мы рассмотрим пример настройки LXD на сервере с Ubuntu 16.04 и запустим первый контейнер, чтобы в дальнейшем можно было создать свой мини-хостинг.

Установка

Если вы настраиваете новый сервер, то первым делом следует обновить список пакетов и установить все обновления

apt update
apt upgrade -y

Установим пакет zfsutils, чтобы в контейнерах можно было использовать файловую систему ZFS

apt install zfsutils-linux

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

apt install bridge-utils

Для того, чтобы установить самую свежую версию lxd из репозиториев snap, удалим текущую версию, если она есть в системе

apt remove --purge lxd lxd-client

Установим менеджер пакетов snap

apt install snapd

Теперь можно установить пакет lxd

snap install lxd

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

lxc list

Система может сказать, что команды «lxc» нет. В таком случае проверьте, существует ли файл lxc в директории /snap/bin.

Если есть, то перезагрузите сервер, например, с помощью reboot или выполните следующую команду. 

source /etc/profile.d/apps-bin-path.sh

После этого директории snap должны добавиться в переменную окружения PATH.

Настройка NAT

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

Для переадресации запросов будем использовать iptables. Включаем механизм роутинга следующей командой

sysctl -w net. ipv4.ip_forward=1

Активируем NAT

iptables --table nat --append POSTROUTING --out-interface ens3 -j MASQUERADE

При перезагрузке сервера настройки iptables сбрасываются. Чтобы не вводить их каждый раз заново, установим утилиту iptables-persistent

apt install iptables-persistent

После её установки нам будет предложено сохранить текущие параметры в файл. Соглашаемся.

Если в будущем потребуется сохранить изменения iptables, выполните команду

iptables-save > /etc/iptables/rules.v4

Настройка LXD

Теперь приступим к инициализации LXD. Выполните следующую команду.

lxd init

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

Do you want to configure a new storage pool (yes/no) [default=yes]?

Да, мы хотим сконфигурировать новое хранилище.

Name of the new storage pool [default=default]:

Оставляем для него имя default.

Name of the storage backend to use (dir, btrfs, ceph, lvm, zfs) [default=zfs]:

Теперь у нас спрашивают тип файловой системы этого хранилища. Оставляем ZFS.

Create a new ZFS pool (yes/no) [default=yes]?

Хотим ли мы создать новый ZFS пул? Да, у нас пока нет ни одного.

Would you like to use an existing block device (yes/no) [default=no]?

Нет, мы не хотим использовать дополнительное устройство, где будет находиться хранилище.

Size in GB of the new loop device (1GB minimum) [default=15GB]:

Теперь нужно задать объем этого хранилища. 15 ГБ для начала устроит.

Would you like LXD to be available over the network (yes/no) [default=no]?

Нет, не нужно делать контейнеры доступными из сети. Мы сами настроим это позже.

Would you like stale cached images to be updated automatically (yes/no) [default=yes]?

Нужно ли автоматически обновлять базовые образы систем, из которых создаются контейнеры? Пусть обновляются.

Would you like to create a new network bridge (yes/no) [default=yes]? no

Тут отвечаем «no». Не нужно создавать мост, потому что мы это сделаем сами.

Диалог с системой

Создание контейнера

Чтобы создать контейнер, нужно выполнить следующую команду

lxc init ubuntu:16. 04 container-alice -p default

В качестве базовой системы для контейнера будет взята Ubuntu 16.04. Контейнер получит имя «container-alice» и будет размещен в хранилище default.

Перед запуском контейнера, необходимо настроить сеть, в которой он будет работать.

Создаем сеть alice-br 10.0.1.0/24

lxc network create alice-br ipv6.address=none ipv4.address=10.0.1.1/24 ipv6.nat=false ipv4.nat=false ipv4.firewall=false ipv6.firewall=false

Основной сервер будет иметь адрес 10.0.1.1

Привяжем контейнер к сети alice-br и зададим ему адрес 10.0.1.2

lxc network attach alice-br container-alice eth0
lxc config device set container-alice eth0 ipv4.address 10.0.1.2

Теперь можно запустить контейнер следующей командой

lxc start container-alice

Настройка контейнера

В контейнерах можно выполнять любые команды с помощью lxc exec

lxc exec

Подключимся к терминалу container-alice, выполнив следующую команду

lxc exec container-alice /bin/bash

Теперь можно настроить контейнер как самостоятельную систему

apt update
apt upgrade -y

Установим nginx, который в будущем может отвечать каким-нибудь сайтом из этого контейнера  

apt install nginx -y

Теперь отредактируем дефолтный конфиг для сервера

nano /etc/nginx/sites-enabled/default

Стираем всё, что там находится, и добавляем следующие строки

server {
listen 80;

add_header Content-Type text/plain;
return 200 'Hello! My name is Alice!';
}

По этим настройкам сервер будет слушать порт 80 и отвечать на запросы текстом «Hello! My name is Alice!».  

Это самый простой nginx-конфиг, который умеет отвечать только одной фразой. Чтобы запустить настоящий сайт, вам понадобятся более сложные настройки. Например, конфигурационный файл сервера для проекта Capella выглядит так.

Чтобы сохранить файл и выйти из nano, нажмите Ctrl+x, нажмите Y, а затем Enter.

Перезагрузите nginx, чтобы подключить обновленный конфиг

service nginx restart

На этом этапе завершаем настройку контейнера и возвращаемся на уровень выше — на основной сервер

exit

Проксирование запросов

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

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

apt install nginx -y

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

nano /etc/nginx/sites-available/container-alice

И добавим туда следующее


server {
listen 80;
server_name alice.myserver.com;

include proxy_params;

location / {
proxy_pass http://10.0.1.2/;
}
}

Сервер будет слушать порт 80, а этот хост будет отзываться на имя alice.myserver.com. Вместо этого адреса подставьте поддомен своего сервера. Также будут добавлены параметры из файла /etc/nginx/proxy_params, которые проставят необходимые для проксирования заголовки. Все запросы будут отправляться на контейнер по адресу 10.0.1.2.

Чтобы активировать конфиг хоста, нужно добавить символическую ссылку на этот файл в папку sites-enabled

ln -s /etc/nginx/sites-available/container-alice /etc/nginx/sites-enabled/

Перезагружаем nginx

service nginx restart

Теперь, если вы попробуйте открыть в браузере сайт, который указали в конфиге, то увидите приветствие от container-alice

Как создавать новые контейнеры

Если вы захотите создать ещё один контейнер, то следуйте инструкциям по созданию первого, но внимательно следите за названиями сетей и адресов.  

Создайте новый контейнер командой

lxc init ubuntu:16.04 container-bob -p default

Вместо «container-bob» вы можете задать любое другое имя.Если новый контейнер, будет работать в отдельной сети, то создайте её. Для этого нужно выбрать имя сети (например, bob-br) и задать адрес и маску сети (например, 10.0.2.1/24).

lxc network create bob-br ipv6.address=none ipv4.address=10.0.2.1/24 ipv6.nat=false ipv4.nat=false ipv4.firewall=false ipv6.firewall=false

Можно не создавать новую сеть, а добавить контейнер в уже существую. Для этого нужно выдать ему соответсвующий адрес. Например, если у нас есть сеть alice-br 10.0.1.0, где 10.0.1.1 — это основной сервер, а 10.0.1.2 — это container-alice, то новый контейнер может получить адрес 10.0.1.3.

Теперь подключаем контейнер к сети и задаем ему адрес

lxc network attach bob-br container-bob eth0
lxc config device set container-bob eth0 ipv4. address 10.0.2.2

И запускаем новый контейнер

lxc start container-bob

Теперь вы можете подключиться к нему с помощью lxc exec и произвести настройку. Если в container-bob тоже будет развернут какой-то сайт, то не забудьте создать nginx-конфиг на основном сервере для этого контейнера.

Подведем итоги

Мы научились создавать LXC-контейнеры и управлять ими при помощи менеджера контейнеризации LXD. Затем настроили веб-сервер внутри контейнера и предоставили к нему доступ извне при помощи NAT и проксирования Nginx.

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

Что такое LXC и как начать?

_________________________________________________ LXC _________________________________________________________

                           Linux Containers ( Ubuntu )

обзор

Контейнеры Linux (LXC) представляют собой облегченную технологию виртуализации и предоставляют бесплатную систему виртуализации программного обеспечения для компьютеров, работающих под управлением GNU / Linux. Это достигается за счет изоляции на уровне ядра. Это позволяет запускать несколько виртуальных блоков (контейнеров) одновременно на одном хосте.

Контейнер — это способ изолировать группу процессов от других в работающей системе Linux. Используя существующие функции, такие как новые функции управления ресурсами ядра Linux и функции выделения ресурсов (группы и пространства имен), эти процессы могут иметь свое собственное частное представление операционной системы со своим собственным пространством идентификатора процесса (PID), структурой файловой системы и сетевые интерфейсы.

Контейнеры совместно используют одно и то же ядро ​​со всем, что на нем запущено, но их можно ограничить использованием только определенного количества ресурсов, таких как процессор, память или ввод-вывод. Комбинируя контейнеры с другими функциями, такими как файловая система Btrfs, можно будет быстро настроить несколько облегченных изолированных экземпляров Linux на одном хосте. Поэтому контейнеры лучше по сравнению с зонами Solaris или тюрьмами BSD.

Установка

Делать LXC проще

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

 sudo apt-get install lxc
 sudo lxc-create -t ubuntu -n my-container
 sudo lxc-start -n my-container

Авторизоваться

sudo lxc-console -n my-container -t 1

По умолчанию будет использоваться та же версия и архитектура, что и на вашем компьютере, очевидно, доступны дополнительные опции (–help перечислит их). Логин / Пароль Ubuntu / Ubuntu.

Для подробной конфигурации хоста

Подробнее о LXC

Debian

оракул

SourceForge

Для новичка я бы порекомендовал использовать LXC Webpanel. Хорошая часть заключается в том, что если вы создадите контейнер в режиме cli, он появится в LXC Web Panel.

  sudo apt-get install lxc debootstrap bridge-utils -y
  sudo su
  wget https://lxc-webpanel.github.com/tools/install.sh -O - | bash

Откройте веб-браузер и подключитесь

                       http://your_ip_address:5000/
                Login with user admin and password admin

обзор

Обзор контейнеров

Сеть LXC

Настройки контейнера

Ограничение ресурсов

Модификация пользователя (создание, удаление, изменение)

Работа с LXC контейнерами | сЭВО:эволюция работ

Расскажу про базовую настройку контейнера и о том как осуществляется работа с LXC контейнерами версии 3.0. Работа с LXC контейнером имеет некоторые нюансы, но в основном проблем с настройкой и обслуживанием нет.

Введение

В этой статье вы узнаете как произвести базовую настройку контейнера LXC c операционной системой CentOS 7. Расскажу про основные команды управления контейнерами, так же узнаете о способах резервного копирования и клонирования контейнера.

Базовая настройка контейнера LXC

Ранее я рассказывал как производится Создание и настройка LXC контейнера. Работа с LXC начинается с того что необходимо произвести базовую настройку контейнера. В контейнере находится система CentOS 7 и работать с ней надо как с обычной системой, но с небольшими нюансами. Более подробно о настройке системы можно почитать в статье CentOS 7 установка и настройка.

Обновим систему:

yum update

Для автоматической проверки обновлений установим необходимую утилиту:

yum install yum-cron

Действия на хосте LXC

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

На хосте с установленной системой LXC выполним команду которая сделает проброс порта с изменением для сервера SSH в контейнере:

firewall-cmd --permanent --zone=external --add-forward-port=port=25552:proto=tcp:toport=22:toaddr=10.10.0.2
= вывод команды =
success

Сохраним изменения:

firewall-cmd --reload
= вывод команды =
success

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

firewall-cmd --list-all --zone=external
= вывод команды =
external (active)
target: default
icmp-block-inversion: no
interfaces: ens18
sources:
services: http https
ports: 25555/tcp 10050/tcp
protocols:
masquerade: yes
forward-ports: port=25552:proto=tcp:toport=22:toaddr=10.10.0.2
source-ports:
icmp-blocks:
rich rules:

В результате при запросе порта 25552 на хосте он будет проброшен на 22 порт в контейнер с ip адресом 10.10.0.2.

Установка программ

Установим популярный репозиторий Epel:

yum -y install epel-release

Ставим необходимые пакеты без вопросов:

yum -y install vim mc net-tools bind-utils htop atop iftop lsof wget bzip2 traceroute gdisk yum-utils

Настройка SSH и консоли

Установим, запустим и добавим в автозагрузку ssh сервер:

yum install openssh-server
systemctl start sshd
systemctl enable sshd

Создадим пароль пользователя root в контейнере:

passwd

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

vim /root/. bashrc
= добавляем внизу =
# Вид приветствия bash
PS1='\[\033[01;31m\]\u@\H\[\033[01;34m\] \w \$\[\033[00m\] '
# Настройка истории bash
export HISTSIZE=10000
export HISTTIMEFORMAT="%h %d %H:%M:%S "
PROMPT_COMMAND='history -a'
export HISTIGNORE="ls:ll:history:w"

Применим изменения без перезагрузки:

source ~/.bashrc

Время в контейнере

Время будет браться с хоста поэтому нам необходимо указать только временную зону.

Посмотрим текущую временную зону:

date
= вывод команды =
Пт окт 12 23:58:14 UTC 2018

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

mv /etc/localtime /etc/localtime.bak

в папке /usr/share/zoneinfo/ находим необходимую временную зону и делаем ссылку

ln -s /usr/share/zoneinfo/Europe/Moscow /etc/localtime

В результате увидим следующее:

date
= вывод команды =
Сб окт 13 02:59:46 MSK 2018

Смена имени контейнера

Смена имени производится командой:

hostnamectl старое НОВОЕ

Не забываем сменить в файле конфигурации контейнера lxc.

При желании можно поменять и название контейнера для этого надо остановить контейнер, поменять название папки с контейнером и имена в файле конфигурации контейнера.

Настройка почты

Для проверки работы почты установим пакет который позволяет отправлять письма с консоли:

yum install mailx

Установим, запустим и добавим в автозагрузку сервис для работы с почтой Рostfix:

yum install postfix
systemctl start postfix
systemctl enable postfix

Дальнейшая настройка как производится отправка почты с авторизацией на другом SMTP сервере вы найдете в статье CentOS 7 установка и настройка.

Управления контейнером LXC

Для вывода справки к командам добавляется параметр -h. Например, # lxc-destroy -h

Запуск контейнера:

lxc-start php7-lxc

Запуск можно произвести с выводом информации о процессе загрузки указав необходимый параметр -F.

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

lxc-start php7-lxc -F

Остановка контейнера:

lxc-stop php7-lxc

Заморозить/разморозить контейнер можно командами:

lxc-freeze php7-lxc
lxc-unfreeze php7-lxc

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

lxc-attach php7-lxc

Информация о контейнерах LXC

Вывод информации о всех контейнерах:

lxc-ls -f
= вывод команды =
NAME STATE AUTOSTART GROUPS IPV4 IPV6 UNPRIVILEGED 
elk-lxc RUNNING 1 - 10.10.0.2 - false 
glpi-lxc RUNNING 1 - 10.10.0.3 - false 
php5-lxc RUNNING 1 - 10.10.0.4 - false 
php7-lxc RUNNING 1 - 10.10.0.5 - false

Подробный вывод информации о контейнере php7-lxc:

lxc-info php7-lxc
= вывод команды =
Name: php7-lxc
State: RUNNING
PID: 3917
IP: 10.10.0.5
CPU use: 3353.19 seconds
BlkIO use: 5.50 GiB
Memory use: 11.39 MiB
KMem use: 0 bytes
Link: php7-lxc
TX bytes: 5.49 MiB
RX bytes: 310.08 MiB
Total bytes: 315. 57 MiB

Резервное копирование контейнеров LXC

LXC-контейнеры совместимы с файловыми системами ZFS, Btrfs и томами LVM. При размещении контейнеров на хранилищах такого типа, будут использоваться их встроенные средства для создания моментальных снимков.

Перед созданием снимка (snapshot) контейнера его необходимо остановить!

Создать снимок:

lxc-snapshot php7-lxc

=== Для создания снимка с комментарием ===
= создаем файл с комментарием =
echo "base setup sevo44" > snap-comment
= создаем снимок с комментарием =
lxc-snapshot php7-lxc -c snap-comment

Посмотреть имеющиеся снимки с выводом комментариев если они есть:

lxc-snapshot php7-lxc -L -С
= вывод команды =
snap0 (/var/sevo44/lxcsnaps/php7-lxc) 2019:02:26 20:52:17
snap1 (/var/sevo44/lxcsnaps/php7-lxc) 2019:02:26 21:02:44
base setup sevo44

Откатится к снимку snap0 контейнера php7-lxc можно выполнив команду:

lxc-snapshot php7-lxc -r snap0

Удалить снимок:

lxc-snapshot php7-lxc -d snap0

Создать новый контейнер из снимка:

lxc-snapshot php7-lxc -r snap0 php7-2-lxc

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

Перед клонированием контейнера его необходимо остановить!

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

lxc-copy php7-lxc -N php7-2-lxc

Перенос контейнера LXC на другой сервер

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

Если контейнер переносится один в один (название, пути и тд.), то он с большой вероятностью запустится и всё там будет работать.

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

Перед переносом контейнера его необходимо остановить!

Перейдем в домашнюю папку и создадим архив который будем переносить на примере для контейнера php7-lxc:

cd
tar --numeric-owner -czvf php7-lxc.tar.gz /var/sevo44/lxc/php7-lxc

Где параметры tar означают:

• c — создание архива tar,
• z — сжать архив, используя алгоритм gzip,
• v — выводить подробную информацию процесса,
• f — указывает имя файла архива,
• —numeric-owner — какие изначально при архивации ID были, такими они и будет после распаковки.

После переноса распакуем архив в необходимую папку:

tar -xzvf php7-lxc. tar.gz -C /var/sevo44/

Где параметры tar означают:

• x — создание архива tar,
• -C — указывает место для распаковки архива.

В указанной папке вы найдете полный путь до контейнера как на сервере откуда переносили контейнер.

Bash скрипт для переноса контейнера LXC

Для быстроты и удобства лучше использовать скрипт который будет выполнять следующие действия:

• Останавливать переносимый контейнер,
• Создавать архив контейнера,
• Запускать контейнер после архивирования,
• Передавать архив контейнера на удаленный сервер,
• Удалять архив контейнера после передачи на удаленный сервер,
• Распаковывать архив на удаленном сервере,
• Удалять архив контейнера на удаленном сервере после распаковки.

Для подключение к удаленному серверу без ввода пароля пользователя необходимо произвести соответствующую настройку о которой рассказано в статье RSA или авторизация SSH по ключу.

Создадим папку для размещения скрипта и создадим скрипт:

mkdir /root/bin
vim /root/bin/tar-lxc_php7-lxc. sh
= необходимый код с пояснениями =
#!/bin/bash

# Переносимый контейнер
container_name="php7-lxc"
# Параметры подключения к удаленому серверу
connect_string="[email protected]"

# Остановка контейнера перед архивацией
lxc_status=$(lxc-info $container_name|grep "STOPPED")
if [ -z "$lxc_status" ];
then
 lxc-stop "$container_name"
 run_again="yes"
fi

# Создание архива контейнера
tar --numeric-owner -czvf /tmp/$container_name.tar.gz /var/sevo44/lxc/$container_name

# Запуск контейнера после архивирования
if [ -n "$run_again" ];
then
 lxc-start "$container_name"
fi

# Копирование архива контейнера на удаленный сервер
scp /tmp/$container_name.tar.gz $connect_string:/tmp/

# Удаление архива после отправки на удаленный сервер
rm -f /tmp/$container_name.tar.gz

# Создадим необходимую папку если она отсутствует
ssh $connect_string mkdir -p /var/sevo44/tmp

# Распаковка архива на удаленном сервере !!! ВНИМАНИЕ !!! указываем полное имя архива
ssh $connect_string tar -xvf /tmp/php7-lxc. tar.gz -C /var/sevo44/tmp/

# Удаление архива после распаковки на удаленном сервере !!! ВНИМАНИЕ !!! указывается полное имя архива
ssh $connect_string rm -f /tmp/php7-lxc.tar.gz

Делаем скрипт исполнительным для владельца файла:

chmod u+x /root/bin/tar-lxc_php7-lxc.sh

Запускаем скрипт с параметром отправки информации о завершении переноса контейнера:

/root/bin/tar-lxc.sh | mailx -s 'Контейнер php7-lxc перенесён!' [email protected]

В результате на почту придет сообщение с темой «Контейнер php7-lxc перенесён!» а в теле письма вы увидите перечень всех файлов что были архивированы.

Удаление контейнера LXC

lxc-destroy php7-lxc

Вывод

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

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Как запустить Ubuntu в Ubuntu? Введение в LXC контейнеры – Linux System Administration

LXC – хорошее решение для быстрого получения изолированного окружения (контейнера) с возможностью сохранения состояния (stateful). Любые изменения будут сохранены, в этом ключевое отличие от Docker.

apt-get update
apt-get install lxd

• Вначале выполните:

lxd init

Подтвердите все вопросы ответами по умолчанию. Можере изменить ответ на вопрос Name of the storage backend to use (btrfs, dir, lvm) [default=btrfs]: dir , выбрав директории в качестве способа хранения данных. Так проще получить к ним доступ из-вне и резервировать их (обычным tar или rsync).

• Список репозитариев. Выполните команду и убедитесь, что у вас подключены внешние URL.

lxc remote list

+-----------------+------------------------------------------+---------------+-----------+--------+--------+
|      NAME       |                   URL                    |   PROTOCOL    | AUTH TYPE | PUBLIC | STATIC |
+-----------------+------------------------------------------+---------------+-----------+--------+--------+
| images          | https://images. linuxcontainers.org       | simplestreams |           | YES    | NO     |

• Получите список доступных образов в репозитарии:

lxc image list images:

Вы можете сделать выборку (grep той операционной системы, которая нужна вам для установки внутри контейнера):

lxc image list images: | grep 'ubuntu.*18.04.*amd64'

Старт

• Запустить контейнер с именем ubuntu01 из образа ubuntu/18.04:

lxc launch images:ubuntu/18.04 ubuntu01

• Получить список запущенных контейнеров:

lxc list

• Зайти в запущенный контейнер:

lxc exec ubuntu01 -- /bin/bash

Теперь вы внутри контейнера, можете устанавливать и настраивать программы, заливать данные.

Если выиспользовали директории (dir) в качестве хранилища для контейнеров, вы можете получить доступ к его файлам тут: /var/lib/lxd/containers/ . Используйте его только для целей резервирования.

• Подключение внешней директории (тома / диска):

lxc config device add ubuntu01 srv disk source=/mnt/storage/srv/data/ path=/srv

• Запуск контейнера от привилегированного пользователя (root=root) без смещения uid на 100000 :

lxc config set ubuntu01 security.privileged true

• Изменение конфигурации внутренней сети lxdbr0:

lxc network show lxdbr0
lxc network set lxdbr0 ipv4.address 10.10.107.1/24

или создание новой:

lxc network create lxdbr0 ipv6.address=none ipv4.address=10.0.3.1/24 ipv4.nat=true

выделений IP адреса для контейнера:

lxc network attach lxdbr0 ubuntu01 eth0

lxc config device set ubuntu01 eth0 ipv4.address 10.10.107.123

Установка и настройка lxc контейнеров на Centos 7

Я давно хотел посмотреть какую-нибудь систему контейнеризации, отличную от docker, так как очень его не люблю. Решил в итоге остановиться для начала на lxc, познакомиться, рассказать вам, как установить и настроить lxc на CentOS 7. Впечатления у меня от него не однозначные, расскажу обо всем по порядку.

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужно пройти .

Введение

Сразу предупреждаю, что данная статья это мое знакомство с lxc контейнерами. Я не имею практического опыта работы с ними, поэтому бездумно брать и применять мои рекомендации не стоит.

Не буду много писать о том, что такое контейнеры, чем они отличаются от виртуальных машин, и чем отличаются системы контейнеров (lxc, docker, openvz и др.) друг от друга. Все это можно найти в интернете на сайтах самих продуктов. Расскажу все своими словами.

1. Главное отличие контейнера от виртуальной машины в том, что он запускается на том же уровне железа, что и хостовый сервер. Нет необходимости в виртуальных устройствах. Контейнер видит исходное железо. Это плюс к производительности. Используется ядро исходной системы и изоляция ресурсов внутри системы.
2. Контейнер может масштабироваться по ресурсам до целого физического сервера. Например, контейнер может использовать тот же диск и файловую систему, что и хостовая машина. Нет необходимости разбивать диск на кусочки, как с виртуальными машинами и давать каждому по кусочку. В итоге, кто-то может свой диск вообще не использовать, а кому-то не хватит. С контейнерами можно поступить проще — все используют общий диск с хостом. Ограничений для диска как в виртуальной машине тем не менее все равно можно устанавливать. То же самое можно сделать с процессором и памятью.

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

Расскажу о том, почему мне захотелось посмотреть на контейнеры вместо виртуальных машин, которые использую повсеместно уже много лет.

1. Как уже написал ранее, привлекает возможность использовать ресурсы хостовой машины напрямую. Взял системный диск с корнем / на 1Тб и все контейнеры его используют пока есть место.
2. Легкий бэкап и доступ к файлам в контейнерах. Посмотреть файлы в контейнере можно просто зайдя в директорию контейнера с хостовой машины. Они все хранятся в открытом виде. Так их очень удобно бэкапить с помощью rsync, или каким-то другим способом.
3. Легко копировать, разворачивать, управлять контейнерами. Они занимают мало места, можно руками с хоста поправить какой-то конфиг в системе контейнера.

Например, у меня есть достаточно мощные VDS серверы от ihor. 2 ядра, 8 гигов, 150Гб диск. Иногда то, что там размещается, не использует полностью ресурсы виртуальной машины. Хочется как-то их занять, но при этом никак не затрагивать основные проекты на виртуальной машине. Иногда хочется какие-то тестовые среды создавать для сайтов и пробовать новые версии софта. Для этого надо отдельную виртуалку брать. Вместо этого я решил попробовать lxc контейнеры.

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

1. Заказывать каждому контейнеру отдельный внешний IP, настраивать для контейнера bridge на реальном сетевом интерфейсе и выпускать его напрямую в интернет. Этот вариант подходит, если есть ip адреса или не жалко для них денег. Так работать удобнее всего.
2. Настраивать виртуальный bridge, настраивать NAT и проброс портов с хостовой машины внутрь контейнеров. Не очень удобно, но тем не менее вполне рабочий вариант.

Я расскажу про оба способа, так как проверял и то и другое. Настраивать все будем на CentOS 7.

Если у вас еще нет своего сервера с CentOS 8, то рекомендую мои материалы на эту тему:

Настройка сети для LXC контейнеров

Начнем с настройки сети для контейнеров. Нам понадобится пакет bridge-utils. Установим его:

# yum install bridge-utils

Настроим виртуальный бридж, который будут использовать только контейнеры внутри своей виртуальной сети — 10.1.1.1/24. Для этого создаем в директории /etc/sysconfig/network-scripts файл ifcfg-virbr0 следующего содержания:

# mcedit /etc/sysconfig/network-scripts/ifcfg-virbr0

DEVICE=virbr0
BOOTPROTO=static
IPADDR=10.1.1.1
NETMASK=255.255.255.0
ONBOOT=yes
TYPE=Bridge
NM_CONTROLLED=no

После изменения сетевых настроек лучше перезагрузиться. Проверим, что получилось:

# ip a

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

• Включить маршрутизацию пакетов между сетевыми интерфейсами
• Настроить NAT для виртуальной сети контейнера
• Настроить проброс портов в контейнеры

Включаем маршрутизацию пакетов. Для этого в файл /etc/sysctl. conf добавляем строку в самый конец:

net.ipv4.ip_forward = 1

Применяем изменение:

# sysctl -p

Теперь основное — настройка iptables. Вообще, она сходу не берется и чаще всего у людей возникают вопросы по работе, если настраивают первый раз. В CentOS 7 по-умолчанию установлен firewalld. Я не использую его и всегда отключаю. Не потому, что он плохой и неудобный, а потому, что привык работать с iptables напрямую, у меня много готовых конфигурация для него.

Отключаем firewalld:

# systemctl stop firewalld
# systemctl disable firewalld

Устанавливаем службы iptables:

# yum install iptables-services

Рисуем конфиг для iptables. Пример взял из статьи про настройку шлюза для локальной сети, только изменил адрес виртуальной сети и имя интерфейса. По сути нам нужно то же самое. Привожу конфиг с рабочего сервера:

# mcedit /etc/iptables.sh

#!/bin/bash
#
# Объявление переменных
export IPT="iptables"

# Интерфейс который смотрит в интернет
export WAN=ens18
export WAN_IP=95. 169.190.64

# lxc сеть
export LAN1=virbr0
export LAN1_IP_RANGE=10.1.1.1/24

# Очистка всех цепочек iptables
$IPT -F
$IPT -F -t nat
$IPT -F -t mangle
$IPT -X
$IPT -t nat -X
$IPT -t mangle -X

# Установим политики по умолчанию для трафика, не соответствующего ни одному из правил
$IPT -P INPUT DROP
$IPT -P OUTPUT DROP
$IPT -P FORWARD DROP

# разрешаем локальный траффик для loopback
$IPT -A INPUT -i lo -j ACCEPT
$IPT -A OUTPUT -o lo -j ACCEPT

# Разрешаем исходящие соединения самого сервера
$IPT -A OUTPUT -o $WAN -j ACCEPT

# Разрешаем доступ из lxc наружу и обратно
$IPT -A FORWARD -i $LAN1 -o $WAN -j ACCEPT
$IPT -A FORWARD -i $WAN -o $LAN1 -j ACCEPT
$IPT -A INPUT -i $LAN1 -j ACCEPT
$IPT -A OUTPUT -o $LAN1 -j ACCEPT

# Включаем NAT
$IPT -t nat -A POSTROUTING -o $WAN -s $LAN1_IP_RANGE -j MASQUERADE

# Пробрасываем порты в контейнер lxc_centos
$IPT -t nat -A PREROUTING -p tcp --dport 23543 -i ${WAN} -j DNAT --to 10. 1.1.2:22
$IPT -t nat -A PREROUTING -p tcp --dport 80 -i ${WAN} -j DNAT --to 10.1.1.2:80
$IPT -t nat -A PREROUTING -p tcp --dport 443 -i ${WAN} -j DNAT --to 10.1.1.2:443

# Состояние ESTABLISHED говорит о том, что это не первый пакет в соединении.
# Пропускать все уже инициированные соединения, а также дочерние от них
$IPT -A INPUT -p all -m state --state ESTABLISHED,RELATED -j ACCEPT
# Пропускать новые, а так же уже инициированные и их дочерние соединения
$IPT -A OUTPUT -p all -m state --state ESTABLISHED,RELATED -j ACCEPT
# Разрешить форвардинг для уже инициированных и их дочерних соединений
$IPT -A FORWARD -p all -m state --state ESTABLISHED,RELATED -j ACCEPT

# Включаем фрагментацию пакетов. Необходимо из за разных значений MTU
$IPT -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

# Отбрасывать все пакеты, которые не могут быть идентифицированы
# и поэтому не могут иметь определенного статуса. 
$IPT -A INPUT -m state --state INVALID -j DROP
$IPT -A FORWARD -m state --state INVALID -j DROP

# Приводит к связыванию системных ресурсов, так что реальный
# обмен данными становится не возможным, обрубаем
$IPT -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
$IPT -A OUTPUT -p tcp ! --syn -m state --state NEW -j DROP

# Рзрешаем пинги
$IPT -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT
$IPT -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
$IPT -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
$IPT -A INPUT -p icmp --icmp-type echo-request -j ACCEPT

# Открываем порт для ssh
$IPT -A INPUT -i $WAN -p tcp --dport 22 -j ACCEPT

# Записываем правила
/sbin/iptables-save  > /etc/sysconfig/iptables

Не забудьте поменять имена сетевых интерфейсов и ip адреса. Я не рекомендую настраивать фаервол, если у вас нет доступа к консоли сервера. Так вы можете потерять управление сервером.

В моем примере показан проброс порта ssh, http и https внутрь контейнера с ip адресом 10.1.1.2. Дальше в примерах я его создам.

Делаем скрипт /etc/iptables.sh исполняемым:

# chmod 0740 /etc/iptables.sh

Запускаем iptables и добавляем в автозагрузку:

# systemctl start iptables.service
# systemctl enable iptables.service

Выполняем скрипт с правилами:

# /etc/iptables.sh

Проверяем установленные правила:

# iptables -L -v -n

Проверяем NAT и проброс портов:

# iptables -L -v -n -t nat

Это я разобрал пример, когда у контейнеров своя виртуальная сеть, без прямого доступа во внешнюю. Если же они будут бриджем выходить наружу с прямым ip,  то iptables вообще трогать не надо. Достаточно включить маршрутизацию пакетов между интерфейсами, создать bridge и добавить туда реальный интерфейс сервера. Контейнерам подключать этот бридж. Работает так же, как и bridge в proxmox.

Создаем конфиг для нового бриджа:

# mcedit /etc/sysconfig/network-scripts/ifcfg-virbr1

DEVICE=virbr1
BOOTPROTO=static
IPADDR=192.168.13.25
NETMASK=255.255.255.0
GATEWAY=192.168.13.1
DNS1=192.168.13.1
ONBOOT=yes
TYPE=Bridge
NM_CONTROLLED=no

И приводим конфиг основного сетевого интерфейса к такому виду:

# mcedit /etc/sysconfig/network-scripts/ifcfg-eth0

TYPE=Ethernet
BOOTPROTO=none
DEVICE=eth0
ONBOOT=yes
NM_CONTROLLED=no
BRIDGE=virbr1

После изменения сетевых настроек сервер лучше перезагрузить. Будем считать, что с сетью разобрались и все настроили. Еще раз напоминаю:

• virbr0 — виртуальный бридж, который создает виртуальную локальную сеть для контейнеров. Выход во внешнюю сеть они осуществляют с помощью хоста, где настроен NAT и проброс портов с помощью iptables.
• virbr1 — бридж, который включает в себя реальный физический интерфейс хоста. С помощью этого бриджа контейнеры получают прямой доступ во внешнюю сеть.

Установка LXC на CentOS 7

Первым делом подключаем репозиторий epel:

# yum install epel-release

Теперь устанавливаем сам lxc:

# yum install debootstrap lxc lxc-templates lxc-extra

Проверим готовность системы к работе lxc:

# lxc-checkconfig

Все должно быть enable, кроме двух строк:

newuidmap is not installed
newgidmap is not installed

Запускаем lxc и добавляем в автозагрузку:

# systemctl start lxc
# systemctl enable lxc

Проверяем:

# systemctl status lxc

Все в порядке, lxc сервис установлен и запущен. Переходим к созданию и настройке контейнеров.

Создание и настройка lxc контейнеров

Создадим новый контейнер с названием lxc_centos под управлением системы centos.

# lxc-create -n lxc_centos -t centos

После ключа -t указывается название шаблона. Список доступных шаблонов для установки можно посмотреть в /usr/share/lxc/templates/

# ll /usr/share/lxc/templates

После установки контейнера, нам нужно указать свой root пароль к нему.

Для этого выполните в консоли команду и укажите новый пароль:

# chroot /var/lib/lxc/lxc_centos/rootfs passwd

Новый контейнер располагается по адресу /var/lib/lxc/lxc_centos. В этой директории лежит файл config. Приводим его к следующему виду:

lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = virbr0
lxc.network.hwaddr = fe:89:c3:04:aa:38
lxc.rootfs = /var/lib/lxc/lxc_centos/rootfs
lxc.network.name = eth0
lxc.network.ipv4 = 10.1.1.2/24
lxc.network.ipv4.gateway = 10.1.1.1
lxc.include = /usr/share/lxc/config/centos.common.conf
lxc.arch = x86_64
lxc.utsname = lxc_centos
lxc.autodev = 1

Зададим некоторые сетевые настройки в самом контейнере. Добавим dns серверы в /etc/resolv. conf:

# mcedit /var/lib/lxc/lxc_centos/rootfs/etc/resolv.conf

nameserver 77.88.8.1
nameserver 8.8.4.4

Конфиг сетевого интерфейса приводим к следующему виду:

# mcedit /var/lib/lxc/lxc_centos/rootfs/etc/sysconfig/network-scripts/ifcfg-eth0

DEVICE=eth0
BOOTPROTO=none
ONBOOT=yes
HOSTNAME=lxc_centos
NM_CONTROLLED=no
TYPE=Ethernet

Настройка lxc контейнера завершена. Запускаем его:

# lxc-start -n lxc_centos -d

Посмотрим состояние контейнера:

# lxc-info -n lxc_centos

Подключаемся к консоли контейнера:

# lxc-console -n lxc_centos -t 0

Обращаю внимание на ключ -t 0. Если его не указать, то при подключении к консоли, вы будете пытаться подключиться к tty 1, на котором не будет никакого ответа. Вы увидите на экране:

Connected to tty 1
                  Type <Ctrl+a q> to exit the console, <Ctrl+a Ctrl+a> to enter Ctrl+a itself

Ничего сделать больше не сможете, кроме как отключиться, нажав сначала Ctrl+a, затем отдельно q. Обращаю на это внимание, так как не очевидно, как нужно набирать эту комбинацию. Ключом -t мы указываем нулевую консоль и успешно к ней подключаемся. Для возврата к хостовой системе, нужно нажать Ctrl+a, затем отдельно q.

Если после подключения к консоли контейнера вы не видите экрана приветствия, нажмите Enter на клавиатуре.

На этом настройка lxc контейнера с centos 7 закончена. Проверяйте сеть, должно быть все в порядке. Чтобы подключиться по ssh к контейнеру, необходимо подключиться к порту 23543 хоста. При условии, что вы взяли мой пример настройки iptables в самом начале.

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

lxc.rootfs = /var/lib/lxc/lxc_centos/rootfs
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = virbr1
lxc.network.hwaddr = fe:89:c3:04:aa:38
lxc. network.name = eth0
lxc.network.ipv4 = 192.168.13.44/24
lxc.network.ipv4.gateway = 192.168.13.1
lxc.network.veth.pair = veth-01
lxc.include = /usr/share/lxc/config/centos.common.conf
lxc.arch = x86_64
lxc.utsname = lxc_centos
lxc.autodev = 1

В данном случае 192.168.13.0/24 — внешняя сеть для хоста. В моем случае это локальная сеть тестового окружения. Если у вас будет реальный ip адрес на бридже, то контейнеру понадобится еще один реальный внешний ip адрес.

Обращаю внимание на очень важный нюанс, который мне стоил нескольких часов разбирательств. Для написания этой статьи я использовал виртуальную машину на hyper-v, у которой единственный сетевой интерфейс был бриджем во внешнюю сеть. Когда я пробрасывал контейнер через этот интерфейс с помощью virbr1, у меня ничего не работало. Контейнер видел только хост и ничего за его пределами. Я многократно проверял настройки, но никак не мог понять, почему не работает.

Оказалось, что по-умолчанию, гипервизор выпускает во внешнюю сеть только те устройства, mac адреса которых он знает. В данном случае это только мак адрес виртуальной машины. Контейнеры же на этой машине имеют другие мак адреса, которые гипервизору неизвестны, и он не выпускал их пакеты во внешнюю сеть. Конкретно в hyper-v такое поведение можно изменить в свойствах сетевого адаптера виртуальной машины:

После этого бридж во внешнюю сеть нормально заработал и контейнеры получили в нее доступ. Такое же поведение будет на виртуальных машинах с proxmox. По-умолчанию, контейнеры не получат доступа во внешнюю сеть. У меня не было под рукой доступа к настройкам гипервизора proxmox на той машине, где я проверил. Не стал подробно разбираться, но имейте ввиду этот момент. C vmware, кстати, будет то же самое. Контейнеры не выйдут во внешнюю сеть.

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

Проблемы и ошибки

Не устанавливается httpd

Сразу скажу, что в качестве хостовой системы и шаблонов для lxc контейнеров я использовал только centos. Возможно в других системах указанных мной ошибок не будет. Первое с чем сразу же столкнулся было невозможность установить пакет httpd. Была вот такая ошибка:

# yum install httpd

Running transaction
  Installing : httpd-2.4.6-67.el7.centos.6.x86_64                                                                                                        1/1 
Error unpacking rpm package httpd-2.4.6-67.el7.centos.6.x86_64
error: unpacking of archive failed on file /usr/sbin/suexec;5a8adbd2: cpio: cap_set_file
  Verifying  : httpd-2.4.6-67.el7.centos.6.x86_64                                                                                                        1/1 

Failed:
  httpd.x86_64 0:2.4.6-67.el7.centos.6                                                                                                                       

Complete!

В интернете полно информации по подобной ошибке в контейнерах centos. Она встречается не только в lxc, но и в docker. В докере ее каким-то образом в определенный момент исправили, в lxc до сих пор воспроизводится и я не уверен, что исправление будет.

Суть ошибки в том, что существуют некие ограничения ядра для работы file capabilities. Я не вникал подробно в эти file capabilities, не понимаю до конца сути ошибки, только поверхностно. Подробно ошибка разобрана тут — https://github.com/lxc/lxd/issues/1245. Так как решением проблемы предлагается перевести контейнер в privileged режим, когда хостовый рут и контейнерный имеют одинаковые системные id, то примерно понятно, в чем суть ошибки.

В общем, я не стал переводить контейнер в privileged режим, а поступил следующим образом. Зачрутился с хостовой машины в контейнер и установил httpd оттуда. Выполняем на хосте:

# chroot /var/lib/lxc/lxc_centos/rootfs
# yum install httpd

Теперь можно зайти в контейнер и проверить, что httpd установлен и нормально работает. Это рабочее решение, когда вы администратор и хоста и контейнеров. Но если вы кому-то отдаете контейнеры под управление, то либо вам придется самим решать ошибки владельцев контейнеров, либо искать какое-то другое решение.

Зависает контейнер и нагружает cpu хоста

Следующая неприятная ошибка, с которой столкнулся сразу же после начала тестирования lxc контейнеров. Контейнер через несколько минут после запуска зависал. Я не мог его ни остановить, ни удалить. При этом на самом хосте процесс /usr/lib/systemd/systemd-journald на 100% нагружал одно ядро cpu.

Решение проблемы следующее. Добавляем в конфиг контейнера параметр:

lxc.kmsg = 0

Перезапускаем контейнер. Заходим в него и удаляем /dev/kmsg (именно в контейнере, не на хосте!!!)

# rm -f /dev/kmsg

После этого контейнеры стали работать стабильно и перестали зависать. Я установил bitrix-env и развернул сайт. Все заработало без проблем с нормальной скоростью.

Не работает chronyd

После установки и запуска chronyd в lxc контейнере с centos 7 получаем ошибку:

ConditionCapability=CAP_SYS_TIME was not met

Тут я уже немного утомился ковыряться в ошибках lxc и понял, что не хочу использовать в работе эти контейнеры. Но все же собрался с силами и погуглил еще немного. Как оказалось, это не ошибка, это ограничение работы в контейнере. Условием работы chronyd является доступ к системному вызову adjtimex(). У контейнера в не privileged режиме нет этого доступа, поэтому он и не запускается.

Контролирует эту ситуацию параметр

ConditionCapability=CAP_SYS_TIME

в конфиге systemd службы chronyd в контейнере — /etc/systemd/system/multi-user.target.wants/chronyd.service. Если убрать этот параметр и запустить службу, получим ошибку:

adjtimex(0x8001) failed : Operation not permitted

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

Заключение

Не понравилась статья и хочешь научить меня администрировать? Пожалуйста, я люблю учиться. Комментарии в твоем распоряжении. Расскажи, как сделать правильно!

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

В целом, вывод по lxc неоднозначный. С одной стороны, вроде все удобно и даже работает. Но с дугой стороны, такие нерешенные проблемы, как зависание контейнеров мне не понятны. Почему оно не заработало из коробки — не ясно. Кроме того, периодически я получал зависания таких команд как lxc-info. Хочешь получить инфу по контейнеру, а в ответ тишина. Просто висит команда в консоли и не выводит ничего. Оставлял на час — без изменений. После перезапуска контейнера показывает нормально. Такие явные ошибки очень настораживают и предостерегают от использования в продакшене.

Потестирую дальше на своих небольших проектах. Если все будет нормально, то дополню статью новым материалом. В принципе, если дальше будет работать стабильно, можно кое-где использовать. В целом, контейнеры очень интересная технология, которая будет отличным дополнением виртуальным машинам, особенно если весь хост используется для однотипной нагрузки, к примеру, под web сайты. Можно их безопасно изолировать с минимальным оверхедом по ресурсам, чего не скажешь о виртуальных машинах даже в минимальной конфигурации.

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

Онлайн курс «DevOps практики и инструменты»

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, научиться непрерывной поставке ПО, мониторингу и логированию web приложений, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.

Проверьте себя на вступительном тесте и смотрите программу детальнее по .

Помогла статья? Подписывайся на telegram канал автора

Анонсы всех статей, плюс много другой полезной и интересной информации, которая не попадает на сайт.

Контейнеры Linux — LXC — Введение

LXC — это интерфейс пользовательского пространства для функций локализации ядра Linux.
Благодаря мощному API и простым инструментам он позволяет пользователям Linux легко создавать
и управлять контейнерами системы или приложений.

Текущий LXC использует следующие функции ядра для хранения процессов:

• Пространства имен ядра (ipc, uts, mount, pid, network и user)
• Профили Apparmor и SELinux
• Политики Seccomp
• Chroots (с использованием pivot_root)
• Возможности ядра
• CGroups (контрольные группы)

Контейнеры LXC часто рассматриваются как нечто среднее между chroot и
полноценная виртуальная машина.Цель LXC — создать среду как можно ближе
к стандартной установке Linux, но без необходимости в отдельном ядре.

LXC в настоящее время состоит из нескольких отдельных компонентов:

• Библиотека liblxc
• Несколько языковых привязок для API:
  • python3 (в дереве, долгосрочная поддержка в 2.0.x)
  • lua (в дереве, долгосрочная поддержка в 2.0.x)
  • Вперед
  • рубин
  • питон3
  • Haskell
• Набор стандартных средств контроля контейнеров
• Шаблоны распределительных контейнеров

LXC — бесплатное программное обеспечение, большая часть кода выпущена в соответствии с условиями GNU LGPLv2.1+ лицензия,
некоторые биты совместимости с Android выпускаются под стандартной лицензией BSD с двумя пунктами
а некоторые двоичные файлы и шаблоны выпущены под лицензией GNU GPLv2.

Лицензия по умолчанию для проекта — GNU LGPLv2.1 +.

Поддержка стабильного выпуска

LXC зависит от дистрибутивов Linux.
и их собственное стремление выдвигать стабильные исправления и обновления безопасности.

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

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

Коммерческую поддержку LXC в выпусках Ubuntu LTS можно получить в Canonical Ltd.

Расширенная поддержка

LXC 2.0 и 3.0 являются выпусками с долгосрочной поддержкой:
— LXC 2.0 будет поддерживаться до 1 июня 2021 г.
— LXC 3.0 будет поддерживаться до 1 июня 2023 г.

Это благодаря Canonical Ltd и Ubuntu, которые включают
выпуски долгосрочной поддержки LXC в их собственные выпуски LTS и тесно сотрудничать
с LXC вверх по течению для поддержания наших стабильных филиалов.

Контейнеры — lxc | Ubuntu

Контейнеры — это облегченная технология виртуализации. Они больше похожи на расширенный chroot, чем на полную виртуализацию, такую ​​как Qemu или VMware, потому что они не эмулируют оборудование и потому что контейнеры используют ту же операционную систему, что и хост. Контейнеры похожи на зоны Solaris или тюрьмы BSD. Linux-vserver и OpenVZ — это две ранее существовавшие, независимо разработанные реализации контейнерной функциональности для Linux.Фактически, контейнеры возникли в результате работы по апстриму vserver и функциональности OpenVZ.

Существует две реализации контейнеров в пространстве пользователя, каждая из которых использует одни и те же функции ядра. Libvirt позволяет использовать контейнеры через драйвер LXC, подключившись к lxc: /// . Это может быть очень удобно, поскольку поддерживает то же использование, что и другие драйверы. Другая реализация, называемая просто «LXC», несовместима с libvirt, но более гибкая благодаря большему количеству инструментов пользовательского пространства.Между ними можно переключаться, хотя есть особенности, которые могут вызвать путаницу.

В этом документе мы в основном описываем корпус lxc . Использование libvirt-lxc обычно не рекомендуется из-за отсутствия защиты Apparmor для контейнеров libvirt-lxc.

В этом документе имя контейнера будет отображаться как CN, C1 или C2.

Установка

Пакет lxc можно установить с помощью

  sudo apt install lxc
  

Это подключит необходимые и рекомендуемые зависимости, а также настроит сетевой мост для использования контейнеров.Если вы хотите использовать непривилегированные контейнеры, вам нужно будет убедиться, что у пользователей достаточно выделенных subuid и subgid, и, вероятно, они захотят разрешить пользователям подключать контейнеры к мосту (см. Basic unprivileged usage ниже).

Основное использование

LXC можно использовать двумя разными способами: с привилегиями, выполняя команды lxc от имени пользователя root; или непривилегированный, запустив команды lxc от имени пользователя без полномочий root. (Запуск непривилегированных контейнеров пользователем root возможен, но здесь не описывается.) Непривилегированные контейнеры более ограничены, например, они не могут создавать узлы устройств или монтировать блочные файловые системы. Однако они менее опасны для хоста, поскольку корневой UID в контейнере сопоставляется с некорневым UID на хосте.

Базовое привилегированное использование

Чтобы создать привилегированный контейнер, вы можете просто:

  sudo lxc-create - загрузка шаблона - имя u1
  

или сокращенно

  sudo lxc-create -t ​​скачать -n u1
  

Это интерактивно запросит загрузку типа корневой файловой системы контейнера — в частности, дистрибутив, выпуск и архитектуру.Чтобы создать контейнер в неинтерактивном режиме, вы можете указать эти значения в командной строке:

  sudo lxc-create -t ​​download -n u1 - --dist ubuntu --release DISTRO-SHORT-CODENAME --arch amd64
  

или

  sudo lxc-create -t ​​download -n u1 - -d ubuntu -r DISTRO-SHORT-CODENAME -a amd64
  

Теперь вы можете использовать lxc-ls для перечисления контейнеров, lxc-info для получения подробной информации о контейнере, lxc-start для запуска и lxc-stop для остановки контейнера. lxc-attach и lxc-console позволяют вводить контейнер, если ssh не подходит. lxc-destroy удаляет контейнер, включая его rootfs. См. Страницы руководства для получения дополнительной информации по каждой команде. Пример сеанса может выглядеть так:

  судо lxc-ls - фантазии
sudo lxc-start --name u1 --daemon
sudo lxc-info --name u1
sudo lxc-stop --name u1
sudo lxc-destroy --name u1
  

Пространства имен пользователей

Непривилегированные контейнеры позволяют пользователям создавать и администрировать контейнеры без каких-либо привилегий root.Функция, лежащая в основе этого, называется пользовательскими пространствами имен. Пространства имен пользователей являются иерархическими, при этом привилегированные задачи в родительском пространстве имен могут сопоставлять его идентификаторы с дочерними пространствами имен. По умолчанию каждая задача на хосте выполняется в начальном пространстве имен пользователя, где полный диапазон идентификаторов отображается на полный диапазон. Это можно увидеть, посмотрев на / proc / self / uid_map и / proc / self / gid_map , которые оба покажут 0 0 4294967295 при чтении из исходного пространства имен пользователя.Начиная с Ubuntu 14.04, когда создаются новые пользователи, им по умолчанию предлагается ряд UID. Список назначенных идентификаторов можно увидеть в файлах / etc / subuid и / etc / subgid . Для получения дополнительной информации см. Соответствующие страницы руководства. Субъиды и субжиды по соглашению начинаются с идентификатора 100000, чтобы избежать конфликта с пользователями системы.

Если пользователь был создан в более ранней версии, ему может быть предоставлен диапазон идентификаторов с помощью usermod , а именно:

  sudo usermod -v 100000-200000 -w 100000-200000 пользователь1
  

Программы newuidmap и newgidmap являются программами setuid-root в пакете uidmap , которые используются внутри lxc для отображения подчиненных идентификаторов и вспомогательных идентификаторов хоста в непривилегированный контейнер.Они гарантируют, что пользователь сопоставляет только те идентификаторы, которые разрешены конфигурацией хоста.

Базовое непривилегированное использование

Чтобы создать непривилегированные контейнеры, необходимо сделать несколько первых шагов. Вам нужно будет создать файл конфигурации контейнера по умолчанию, указав желаемые сопоставления идентификаторов и настройку сети, а также настроить хост, чтобы позволить непривилегированному пользователю подключаться к сети хоста. В приведенном ниже примере предполагается, что диапазоны сопоставленных идентификаторов пользователя и группы составляют 100000–165536.Проверьте фактические диапазоны идентификаторов пользователей и групп и соответствующим образом измените пример:

  grep $ USER / etc / subuid
grep $ USER / etc / subgid
  

  mkdir -p ~ / .config / lxc
echo "lxc.id_map = u 0 100000 65536"> ~ / .config / lxc / default.conf
echo "lxc.id_map = g 0 100000 65536" >> ~ / .config / lxc / default.conf
echo "lxc.network.type = veth" >> ~ / .config / lxc / default.conf
echo "lxc.network.link = lxcbr0" >> ~ / .config / lxc / default.conf
echo "$ USER veth lxcbr0 2" | sudo tee -a / etc / lxc / lxc-usernet
  

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

  lxc-create -t ​​скачать -n u1 - -d ubuntu -r DISTRO-SHORT-CODENAME -a amd64
lxc-start -n u1 -d
lxc-attach -n u1
lxc-stop -n u1
lxc-destroy -n u1
  

Вложенность

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

  lxc.mount.auto = cgroup
lxc.aa_profile = lxc-контейнер-по умолчанию-с вложением
  

Первый вызовет привязку сокета диспетчера cgroup к контейнеру, чтобы lxc внутри контейнера мог администрировать cgroups для своих вложенных контейнеров.Во втором случае контейнер запускается в более свободной политике Apparmor, которая позволяет контейнеру выполнять монтаж, необходимый для запуска контейнеров. Обратите внимание, что эта политика при использовании с привилегированным контейнером намного менее безопасна, чем обычная политика или непривилегированный контейнер. См. Раздел Apparmor для получения дополнительной информации.

Глобальная конфигурация

LXC обращается к следующим файлам конфигурации. Для привилегированного использования они находятся в / etc / lxc , а для непривилегированного использования — в ~ /.config / lxc .

• lxc.conf может дополнительно указывать альтернативные значения для нескольких настроек lxc, включая lxcpath, конфигурацию по умолчанию, используемые cgroups, шаблон создания cgroup и настройки внутреннего хранилища для lvm и zfs.
• default.conf определяет конфигурацию, которую должен содержать каждый вновь созданный контейнер. Обычно он содержит как минимум раздел сети, а для непривилегированных пользователей — раздел сопоставления идентификаторов

.

• lxc-usernet.conf указывает, как непривилегированные пользователи могут подключать свои контейнеры к сети, принадлежащей хосту.

lxc.conf и default.conf находятся под / etc / lxc и $ HOME / .config / lxc , а lxc-usernet.conf — только для всего хоста.

По умолчанию контейнеры находятся в / var / lib / lxc для пользователя root.

Сеть

По умолчанию LXC создает пространство имен частной сети для каждого контейнера, который включает сетевой стек уровня 2.Контейнеры обычно подключаются к внешнему миру, передавая в контейнер физический сетевой адаптер или конечную точку туннеля veth. LXC создает мост с NAT, lxcbr0, при запуске хоста. Контейнеры, созданные с использованием конфигурации по умолчанию, будут иметь одну сетевую карту veth с удаленным концом, подключенным к мосту lxcbr0. Сетевая карта может существовать только в одном пространстве имен одновременно, поэтому физическая сетевая карта, переданная в контейнер, не может использоваться на хосте.

Можно создать контейнер без пространства имен частной сети.В этом случае контейнер будет иметь доступ к сети хоста, как и любое другое приложение. Обратите внимание, что это особенно опасно, если в контейнере запущен дистрибутив с выскочкой, такой как Ubuntu, поскольку программы, которые взаимодействуют с init, например shutdown , будут общаться через абстрактный сокет домена Unix с выскочкой хоста и отключать хост.

Чтобы дать контейнерам на lxcbr0 постоянный IP-адрес на основе имени домена, вы можете записать записи в / etc / lxc / dnsmasq.conf как:

  dhcp-хост = lxcmail, 10.0.3.100
dhcp-host = ttrss, 10.0.3.101
  

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

  iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 587 -j DNAT \
    - в пункт назначения 10.0.3.100:587
  

Затем укажите мост хоста в файле конфигурации контейнера вместо lxcbr0, например

  лк.network.type = veth
lxc.network.link = br0
  

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

Есть несколько способов определить IP-адрес контейнера. Во-первых, вы можете использовать lxc-ls --fancy , который будет печатать IP-адреса всех запущенных контейнеров, или lxc-info -i -H -n C1 , который напечатает IP-адрес C1.Если на хосте установлен dnsmasq, вы также можете добавить запись в /etc/dnsmasq.conf следующим образом:

  сервер = / lxc / 10.0.3.1
  

, после чего dnsmasq разрешит C1.lxc локально, так что вы можете:

  пинг C1
ssh C1
  

Для получения дополнительной информации см. Справочную страницу lxc.conf (5) , а также примеры сетевых конфигураций в / usr / share / doc / lxc / examples / .

Запуск LXC

LXC не имеет долго работающего демона.Однако у него есть три новых места работы.

• /etc/init/lxc-net.conf: — необязательное задание, которое запускается, только если / etc / default / lxc-net указывает USE_LXC_BRIDGE (по умолчанию true). Он устанавливает NAT-мост для использования контейнеров.

• /etc/init/lxc.conf загружает профили lxc apparmor и при необходимости запускает любые автозапускаемые контейнеры. Контейнеры автозапуска будут проигнорированы, если LXC_AUTO (по умолчанию true) имеет значение true в / etc / default / lxc .См. Страницу руководства lxc-autostart для получения дополнительной информации об автозапускаемых контейнерах.

• /etc/init/lxc-instance.conf используется файлом /etc/init/lxc.conf для автоматического запуска контейнера.

Резервные магазины

LXC поддерживает несколько резервных хранилищ для корневых файловых систем контейнеров. По умолчанию используется простое хранилище резервных копий каталогов, поскольку оно не требует предварительной настройки хоста, если базовая файловая система достаточно велика.Также не требуется никаких привилегий root для создания резервного хранилища, поэтому его можно легко использовать без привилегий. Rootfs для привилегированного контейнера, поддерживаемого каталогом, находится (по умолчанию) в / var / lib / lxc / C1 / rootfs , а rootfs для непривилегированного контейнера находится в ~ / .local / share / lxc / C1 / rootfs . Если в lxc.system.com указан пользовательский lxcpath, то rootfs-контейнер будет находиться под $ lxcpath / C1 / rootfs .

Клон снимка C2 контейнера C1 с поддержкой каталога становится контейнером с поддержкой overlayfs с rootfs, называемым overlayfs: / var / lib / lxc / C1 / rootfs: / var / lib / lxc / C2 / delta0 .Другие типы резервного хранилища включают loop, btrfs, LVM и zfs.

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

Корневая файловая система для контейнера с поддержкой LVM может быть любым отдельным LV. Имя VG по умолчанию можно указать в lxc.conf. Тип и размер файловой системы настраиваются для каждого контейнера с помощью lxc-create.

rootfs для контейнера, поддерживаемого zfs, представляет собой отдельную файловую систему zfs, смонтированную в традиционном месте / var / lib / lxc / C1 / rootfs . Zfsroot можно указать в lxc-create, а значение по умолчанию можно указать в lxc.system.conf.

Более подробную информацию о создании контейнеров с различными резервными хранилищами можно найти на странице руководства lxc-create.

шаблоны

Создание контейнера обычно включает создание корневой файловой системы для контейнера. lxc-create делегирует эту работу шаблонам , которые обычно предназначены для каждого распределения. Шаблоны lxc, поставляемые с lxc, можно найти в каталоге / usr / share / lxc / templates и включают шаблоны для создания контейнеров Ubuntu, Debian, Fedora, Oracle, centos и gentoo среди других.

Создание образов дистрибутивов в большинстве случаев требует способности создавать узлы устройств, часто требует инструментов, которых нет в других дистрибутивах, и обычно занимает довольно много времени.Поэтому lxc поставляется со специальным шаблоном download , который загружает предварительно созданные образы контейнеров с центрального сервера lxc. Наиболее важным вариантом использования является разрешение простого создания непривилегированных контейнеров пользователями без полномочий root, которые, например, не могут легко запустить команду debootstrap .

При запуске lxc-create все параметры, которые идут после — , передаются в шаблон. В следующей команде –name , –template и –bdev передаются в lxc-create , а –release передаются в шаблон:

  lxc-create --template ubuntu --name c1 --bdev loop - --release DISTRO-SHORT-CODENAME
  

Вы можете получить справку по параметрам, поддерживаемым любым конкретным контейнером, передав –help и имя шаблона в lxc-create .Например, если вам нужна помощь с шаблоном загрузки,

  lxc-create --template скачать --help
  

Автозапуск

LXC поддерживает маркировку контейнеров, запускаемых при загрузке системы. До Ubuntu 14.04 это было сделано с помощью символических ссылок в каталоге / etc / lxc / auto . Начиная с Ubuntu 14.04, это делается через файлы конфигурации контейнера. Запись

  люкс. Start.auto = 1
lxc.start.delay = 5
  

будет означать, что контейнер должен запускаться при загрузке, и система должна подождать 5 секунд перед запуском следующего контейнера.LXC также поддерживает упорядочивание и группировку контейнеров, а также перезагрузку и выключение с помощью групп автозапуска. См. Страницы руководства для lxc-autostart и lxc.container.conf для получения дополнительной информации.

Аппарат

LXC поставляется с профилем Apparmor по умолчанию, предназначенным для защиты хоста от случайного злоупотребления привилегиями внутри контейнера. Например, контейнер не сможет писать в / proc / sysrq-trigger или в большинство файлов / sys .

уср.Профиль bin.lxc-start вводится путем запуска lxc-start . Этот профиль в основном предотвращает установку lxc-start новых файловых систем вне корневой файловой системы контейнера. Перед выполнением init контейнера LXC запрашивает переключение на профиль контейнера. По умолчанию этот профиль является политикой lxc-container-default , которая определена в /etc/apparmor.d/lxc/lxc-default . Этот профиль предотвращает доступ контейнера ко многим опасным путям и от монтирования большинства файловых систем.

Программы в контейнере не могут быть дополнительно ограничены — например, MySQL работает под профилем контейнера (защищая хост), но не сможет войти в профиль MySQL (чтобы защитить контейнер).

lxc-execute не входит в профиль Apparmor, но контейнер, который он порождает, будет ограничен.

Настройка контейнерных политик

Если вы обнаружите, что lxc-start дает сбой из-за законного доступа, который запрещен его политикой Apparmor, вы можете отключить профиль lxc-start, выполнив:

  sudo apparmor_parser -R / etc / apparmor.d / usr.bin.lxc-start
sudo ln -s /etc/apparmor.d/usr.bin.lxc-start /etc/apparmor.d/disabled/
  

Это приведет к тому, что lxc-start будет работать без ограничений, но продолжит ограничивать сам контейнер. Если вы также хотите отключить ограничение контейнера, то помимо отключения профиля usr.bin.lxc-start необходимо добавить:

  lxc.aa_profile = неограниченный
  

в файл конфигурации контейнера.

LXC поставляется с несколькими альтернативными политиками для контейнеров.Если вы хотите запускать контейнеры внутри контейнеров (вложение), вы можете использовать профиль lxc-container-default-with-nesting, добавив следующую строку в файл конфигурации контейнера

  lxc.aa_profile = lxc-контейнер-по умолчанию-с-вложением
  

Если вы хотите использовать libvirt внутри контейнеров, вам потребуется отредактировать эту политику (которая определена в /etc/apparmor.d/lxc/lxc-default-with-nesting ), раскомментировав следующую строку:

  смонтировать fstype = cgroup -> / sys / fs / cgroup / **,
  

и повторно загрузите политику.

Обратите внимание, что политика вложения с привилегированными контейнерами намного менее безопасна, чем политика по умолчанию, поскольку она позволяет повторно монтировать контейнеры / sys и / proc в нестандартных местах, минуя защиту аппарелей. У непривилегированных контейнеров нет этого недостатка, поскольку корень контейнера не может выполнять запись в файлы proc и sys , принадлежащие корневому пользователю.

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

Если вам нужно запустить контейнер в настраиваемом профиле, вы можете создать новый профиль в /etc/apparmor.d/lxc/ . Его имя должно начинаться с lxc-, чтобы lxc-start мог перейти к этому профилю. Профиль lxc-default включает повторно используемый файл абстракций / etc / apparmor.d / абстракции / lxc / контейнер-база . Поэтому простой способ создать новый профиль — это сделать то же самое, а затем добавить дополнительные разрешения в нижней части вашей политики.

После создания политики загрузите ее, используя:

  sudo apparmor_parser -r /etc/apparmor.d/lxc-containers
  

Профиль будет автоматически загружен после перезагрузки, поскольку его источник находится в файле /etc/apparmor.d/lxc-containers . Наконец, чтобы контейнер CN использовал этот новый lxc-CN-profile , добавьте следующую строку в его файл конфигурации:

  лк.aa_profile = lxc-CN-профиль
  

Контрольные группы

Контрольные группы (контрольные группы) — это функция ядра, обеспечивающая иерархическое группирование задач, а также учет и ограничения ресурсов для каждой контрольной группы. Они используются в контейнерах для ограничения доступа к блочным и символьным устройствам и для замораживания (приостановки) контейнеров. В дальнейшем их можно использовать для ограничения использования памяти и блокировки ввода-вывода, гарантии минимального количества общих ресурсов ЦП и блокировки контейнеров для определенных ЦП.

По умолчанию привилегированный контейнер CN будет назначен контрольной группе с именем / lxc / CN .В случае конфликта имен (который может возникнуть при использовании пользовательских lxcpaths) к имени cgroup будет добавлен суффикс «-n», где n — целое число, начинающееся с 0.

По умолчанию привилегированный контейнер CN будет назначен контрольной группе с именем CN в контрольной группе задачи, запустившей контейнер, например /usr/1000.user/1.session/CN . Корню контейнера будет предоставлено групповое владение каталогом (но не всеми файлами), так что ему будет разрешено создавать новые дочерние контрольные группы.

Начиная с Ubuntu 14.04, LXC использует диспетчер групп (cgmanager) для управления группами. Менеджер cgroup получает запросы D-Bus через сокет Unix / sys / fs / cgroup / cgmanager / sock . Для обеспечения безопасности вложенных контейнеров линия

  lxc.mount.auto = cgroup
  

можно добавить в конфигурацию контейнера, в результате чего каталог / sys / fs / cgroup / cgmanager монтируется с привязкой к контейнеру. Контейнер, в свою очередь, должен запустить прокси-сервер управления cgroup (выполняется по умолчанию, если пакет cgmanager установлен в контейнере), который переместит каталог / sys / fs / cgroup / cgmanager в / sys / fs / cgroup / cgmanager.ниже , затем начните прослушивать запросы к прокси на собственном сокете / sys / fs / cgroup / cgmanager / sock . Хост cgmanager гарантирует, что вложенные контейнеры не смогут выйти из назначенных им контрольных групп или сделать запросы, для которых они не авторизованы.

Клонирование

Для быстрой подготовки вы можете настроить канонический контейнер в соответствии со своими потребностями, а затем сделать несколько его копий. Это можно сделать с помощью программы lxc-clone .

Клоны — это либо моментальные снимки, либо копии другого контейнера.Копия — это новый контейнер, скопированный с оригинала, и занимает на хосте столько же места, сколько оригинал. Снимок использует возможность создания снимков базового резервного хранилища для создания контейнера копирования при записи, ссылающегося на первый. Снимки можно создавать из контейнеров btrfs, LVM, zfs и каталогов. У каждого резервного хранилища есть свои особенности — например, контейнеры LVM, которые не имеют тонкого пула, не могут поддерживать моментальные снимки моментальных снимков; Контейнеры zfs со снимками нельзя удалить, пока не будут выпущены все снимки; Контейнеры LVM должны быть более тщательно спланированы, поскольку базовая файловая система может не поддерживать рост; btrfs не страдает ни одним из этих недостатков, но страдает от снижения производительности fsync, что приводит к тому, что dpkg и склонны работать медленнее.

Снимки контейнеров, упакованных в каталоги, создаются с использованием файловой системы оверлея. Например, у привилегированного контейнера C1 с поддержкой каталога будет корневая файловая система в каталоге / var / lib / lxc / C1 / rootfs . Клон снэпшота C1 с именем C2 будет запущен с rootfs C1, смонтированными только для чтения в каталоге / var / lib / lxc / C2 / delta0 . Важно отметить, что в этом случае C1 не следует разрешать запускать или удалять во время работы C2. Вместо этого рекомендуется рассматривать C1 как канонический базовый контейнер и использовать только его снимки.

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

  Судо lxc-clone -o C1 -n C2
  

Снимок можно создать с помощью:

  Судо lxc-clone -s -o C1 -n C2
  

Дополнительные сведения см. На странице руководства lxc-clone.

Снимки

Чтобы упростить поддержку использования клонов моментальных снимков для итеративной разработки контейнеров, LXC поддерживает моментальных снимков . При работе с контейнером C1 перед внесением потенциально опасного или труднообратимого изменения вы можете создать снимок

  Судо lxc-моментальный снимок -n C1
  

, который представляет собой клон-снимок под названием «snap0» в / var / lib / lxcsnaps или $ HOME /.локальный / share / lxcsnaps. Следующий снимок будет называться «snap1» и т. Д. Существующие снимки могут быть перечислены с помощью lxc-snapshot -L -n C1 , а снимок можно восстановить — удалив текущий контейнер C1 — с помощью lxc-snapshot -r snap1 -n C1 . После команды восстановления снимок snap1 продолжает существовать, а предыдущий C1 стирается и заменяется снимком snap1.

Снимки поддерживаются для контейнеров btrfs, lvm, zfs и overlayfs. Если lxc-snapshot вызывается в контейнере, поддерживаемом каталогом, ошибка будет записана в журнал, и моментальный снимок будет создан как копия-клон.Причина в том, что если пользователь создает моментальный снимок overlayfs контейнера с поддержкой каталога, а затем вносит изменения в контейнер с поддержкой каталога, то первоначальные изменения контейнера будут частично отражены в моментальном снимке. Если требуются моментальные снимки контейнера C1, поддерживаемого каталогом, то необходимо создать клон overlayfs для C1, C1 не следует снова трогать, а клон overlayfs можно редактировать и делать снимки по желанию, как таковой

  lxc-клон -s -o C1 -n C2
lxc-start -n C2 -d # внести некоторые изменения
lxc-stop -n C2
lxc-снимок -n C2
lxc-start -n C2 # и т. д.
  

Эфемерные контейнеры

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

  lxc-start-ephemeral -o C1
  

Контейнер начинается как снимок C1. Инструкции по входу в контейнер будут распечатаны на консоли. После выключения эфемерный контейнер будет уничтожен. Дополнительные параметры см. На странице руководства lxc-start-ephemeral.

Крючки для управления жизненным циклом

Начиная с Ubuntu 12.10, можно определить хуки, которые будут выполняться в определенные моменты времени жизни контейнера:

• Предварительные обработчики запускаются в пространстве имен хоста до того, как будут запущены контейнеры ttys, консоли или монтирования.Если какие-либо крепления выполняются на этом крюке, они должны быть убраны в крюке пост-стопа.
• Перехватчики перед монтированием запускаются в пространствах имен контейнера, но до монтирования корневой файловой системы. Крепления, сделанные на этом крючке, будут автоматически очищены при закрытии контейнера.
• Перехватчики монтирования запускаются после того, как файловые системы контейнера были смонтированы, но до того, как контейнер вызвал pivot_root для изменения своей корневой файловой системы.
• Перехватчики запуска запускаются непосредственно перед выполнением инициализации контейнера.Поскольку они выполняются после перехода в файловую систему контейнера, команда, которая должна быть выполнена, должна быть скопирована в файловую систему контейнера.
• Перехватчики после остановки выполняются после закрытия контейнера.

Если какой-либо обработчик вернет ошибку, выполнение контейнера будет прервано. Любой хук post-stop по-прежнему будет выполняться. Любой вывод, сгенерированный сценарием, будет регистрироваться с приоритетом отладки.

Пожалуйста, обратитесь к странице руководства lxc.container.conf (5) , чтобы узнать о формате файла конфигурации, с помощью которого можно указать ловушки.Некоторые примеры хуков поставляются с пакетом lxc, чтобы служить примером того, как писать и использовать такие хуки.

Консоли

Контейнеры имеют настраиваемое количество консолей. Один всегда существует на / dev / console контейнера. Это отображается на терминале, с которого вы запустили lxc-start , если не указана опция -d . Вывод на / dev / console можно перенаправить в файл с помощью параметра -c console-file на lxc-start .Количество дополнительных консолей определяется переменной lxc.tty и обычно устанавливается на 4. Эти консоли показаны на / dev / ttyN (для 1 <= N <= 4). Чтобы войти в консоль 3 с хоста, используйте:

  sudo lxc-console -n контейнер -t 3
  

или если опция -t N не указана, автоматически будет выбрана неиспользуемая консоль. Для выхода из консоли используйте escape-последовательность Ctrl-a q . Обратите внимание, что escape-последовательность не работает в консоли после lxc-start без опции -d .

Каждая контейнерная консоль на самом деле представляет собой pty Unix98 в монтировании pty хоста (а не гостя), монтируется с привязкой поверх / dev / ttyN и / dev / console гостя. Следовательно, если гость размонтирует их или иным образом попытается получить доступ к фактическому символьному устройству 4: N , он не будет обслуживать getty на консолях LXC. (При настройках по умолчанию контейнер не сможет получить доступ к этому символьному устройству, и getty, следовательно, завершится ошибкой.) Это может легко произойти, когда сценарий загрузки слепо монтирует новый / dev .

Поиск и устранение неисправностей

Лесозаготовка

Если что-то пойдет не так при запуске контейнера, первым делом необходимо получить полное ведение журнала от LXC:

  sudo lxc-start -n C1 -l trace -o debug.out
  

Это заставит lxc вести журнал на самом подробном уровне, , трассировку, , и выводить информацию журнала в файл с именем «debug.out». Если файл debug.out уже существует, новая информация журнала будет добавлена.

Мониторинг состояния контейнера

Доступны две команды для отслеживания изменений состояния контейнера. lxc-monitor контролирует один или несколько контейнеров на предмет любых изменений состояния. Он принимает имя контейнера, как обычно, с опцией -n , но в этом случае имя контейнера может быть регулярным выражением posix, что позволяет отслеживать желаемые наборы контейнеров. lxc-monitor продолжает работать, пока печатает изменения контейнера. lxc-wait ожидает определенного изменения состояния и затем завершает работу. Например,

  sudo lxc-monitor -n cont [0-5] *
  

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

  sudo lxc-wait -n cont1 -s 'ОСТАНОВЛЕН | ЗАМОРОЖЕН'
  

будет ждать, пока контейнер cont1 перейдет в состояние ОСТАНОВЛЕН или ЗАМОРОЖЕН, а затем выйдет.

Прикрепить

Начиная с Ubuntu 14.04, можно подключаться к пространствам имен контейнера. Самый простой случай — просто сделать

  Судо lxc-attach -n C1
  

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

Подробная информация об инициализации контейнера

Если LXC завершает запуск контейнера, но инициализация контейнера не завершается (например, не отображается запрос на вход в систему), может быть полезно запросить дополнительную информацию от процесса инициализации.Для контейнера выскочки это может быть:

  sudo lxc-start -n C1 / sbin / init loglevel = отладка
  

Вы также можете запустить совершенно другую программу вместо init, например

  Судо lxc-start -n C1 / bin / bash
sudo lxc-start -n C1 / bin / sleep 100
sudo lxc-start -n C1 / bin / cat / proc / 1 / статус
  

LXC API

К большей части функциональности LXC теперь можно получить доступ через API, экспортированный из liblxc , для которого привязки доступны на нескольких языках, включая Python, lua, ruby ​​и go.

Ниже приведен пример использования привязок python (которые доступны в пакете python3-lxc), которые создают и запускают контейнер, а затем ждут, пока он не будет выключен:

  # sudo python3
Python 3.2.3 (по умолчанию, 28 августа 2012 г., 08:26:03)
[GCC 4.7.1 20120814 (предварительная версия)] на linux2
Для получения дополнительной информации введите «помощь», «авторские права», «кредиты» или «лицензия».
>>> import lxc
__main __: 1: Предупреждение: API python-lxc еще не стабилен и может измениться в любой момент в будущем.>>> c = lxc.Container ("C1")
>>> c.create ("убунту")
Правда
>>> c.start ()
Правда
>>> c.wait ("ОСТАНОВЛЕН")
Правда
  

Безопасность

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

По умолчанию контейнеры LXC запускаются под политикой Apparmor, чтобы ограничить некоторые действия. Подробности интеграции AppArmor с lxc находятся в разделе Apparmor . Непривилегированные контейнеры идут дальше, сопоставляя корень в контейнере с UID непривилегированного хоста. Это предотвращает доступ к файлам / proc и / sys , представляющим ресурсы хоста, а также к любым другим файлам, принадлежащим root на хосте.

Используемые системные вызовы

Это основная функция контейнера, в которой контейнеры совместно используют ядро ​​с хостом.Поэтому, если ядро ​​содержит какие-либо уязвимые системные вызовы, контейнер также может использовать их. Как только контейнер управляет ядром, он может полностью контролировать любой ресурс, известный хосту.

Как правило, для запуска полного контейнера распространения потребуется большое количество системных вызовов. Однако для контейнеров приложений можно сократить количество доступных системных вызовов до нескольких. Даже для системных контейнеров, работающих с полным распределением, можно добиться повышения безопасности, например, удалив системные вызовы 32-битной совместимости в 64-битном контейнере.См. Страницу руководства lxc.container.conf для получения подробной информации о том, как настроить контейнер для использования seccomp. По умолчанию политика seccomp не загружается.

ресурсов

Что такое контейнер Linux?

Контейнер Linux® — это набор из 1 или нескольких процессов, изолированных от остальной системы. Все файлы, необходимые для их запуска, предоставляются из отдельного образа, что означает, что контейнеры Linux переносимы и согласованы при переходе от разработки к тестированию и, наконец, к производству.Это делает их намного более быстрыми в использовании, чем конвейеры разработки, которые полагаются на репликацию традиционных сред тестирования. Благодаря своей популярности и простоте использования контейнеры также являются важной частью ИТ-безопасности.

Зачем нужны контейнеры Linux?

Представьте, что вы разрабатываете приложение. Вы работаете на ноутбуке, и ваша среда имеет определенную конфигурацию. У других разработчиков могут быть немного другие конфигурации. Приложение, которое вы разрабатываете, зависит от этой конфигурации и зависит от конкретных библиотек, зависимостей и файлов.Между тем в вашем бизнесе есть среды разработки и производства, стандартизированные с их собственными конфигурациями и собственными наборами вспомогательных файлов. Вы хотите максимально эмулировать эти среды локально, но без лишних затрат на воссоздание серверных сред. Итак, как заставить ваше приложение работать в этих средах, пройти контроль качества и развернуть приложение без больших головных болей, переписывания и исправления сбоев? Ответ: контейнеры.

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

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

Red Hat® OpenShift® включает все необходимое для гибридного облака, корпоративного контейнера, а также разработки и развертывания Kubernetes.

Разве это не виртуализация?

Не совсем так. Считайте их скорее дополняющими друг друга. Вот простой способ представить себе виртуализацию 2:

• , позволяющую вашим операционным системам (Windows или Linux) работать одновременно на одной аппаратной системе.
• Контейнеры используют одно и то же ядро ​​операционной системы и изолируют процессы приложения от остальной системы. Например: системы ARM Linux запускают контейнеры ARM Linux, системы x86 Linux запускают контейнеры x86 Linux, системы x86 Windows запускают контейнеры x86 Windows.Контейнеры Linux чрезвычайно портативны, но они должны быть совместимы с базовой системой.

Что это значит? Во-первых, виртуализация использует гипервизор для эмуляции оборудования, что позволяет нескольким операционным системам работать бок о бок. Это не так легко, как использовать контейнеры. Когда у вас есть ограниченные ресурсы с ограниченными возможностями, вам нужны легкие приложения, которые можно плотно развернуть. Контейнеры Linux изначально работают в операционной системе, разделяя их между всеми вашими контейнерами, поэтому ваши приложения и сервисы остаются легкими и быстро работают параллельно.

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

Существуют даже инструменты, сочетающие оркестровку контейнеров и управление виртуальными машинами. Узнайте больше об этом в этом треке Red Hat Summit 2020, который включает в себя секционное обсуждение именно такого инструмента.

Что такое LXC?

Проект Linux Containers (LXC) — это контейнерная платформа с открытым исходным кодом, которая предоставляет набор инструментов, шаблонов, библиотек и языковых привязок. LXC имеет простой интерфейс командной строки, который улучшает взаимодействие с пользователем при запуске контейнеров.

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

Краткая история контейнеров

Идея того, что мы сейчас называем контейнерной технологией, впервые появилась в 2000 году как тюрьмы FreeBSD, технология, которая позволяет разделить систему FreeBSD на несколько подсистем или тюрем. Тюрьмы были разработаны как безопасные среды, которыми системный администратор мог поделиться с несколькими пользователями внутри или за пределами организации.

В 2001 году реализация изолированной среды вошла в Linux благодаря проекту Жака Желинаса VServer. Как только эта основа была заложена для множества контролируемых пользовательских пространств в Linux, части начали складываться на свои места, чтобы сформировать то, что сегодня является контейнером Linux.

Очень быстро, все больше технологий объединились, чтобы сделать этот изолированный подход реальностью. Группы управления (cgroups) — это функция ядра, которая контролирует и ограничивает использование ресурсов для процесса или групп процессов.А systemd, система инициализации, которая настраивает пользовательское пространство и управляет их процессами, используется cgroups для обеспечения большего контроля над этими изолированными процессами. Обе эти технологии, добавляя общий контроль над Linux, были основой того, как среды могут успешно оставаться разделенными.

Введите Docker

В 2008 году на сцену вышли Docker (через dotCloud) со своей одноименной контейнерной технологией. Технология docker добавила много новых концепций и инструментов — простой интерфейс командной строки для запуска и создания новых многоуровневых образов, серверный демон, библиотеку предварительно созданных образов контейнеров и концепцию сервера реестра.В совокупности эти технологии позволили пользователям быстро создавать новые многоуровневые контейнеры и легко обмениваться ими с другими.

Существует 3 основных стандарта, обеспечивающих совместимость контейнерных технологий: спецификации OCI Image, Distribution и Runtime. В совокупности эти спецификации позволяют проектам сообщества, коммерческим продуктам и поставщикам облачных услуг создавать совместимые контейнерные технологии (подумайте о том, чтобы поместить свои собственные созданные образы на сервер реестра поставщика облачных услуг — это необходимо для работы).Сегодня Red Hat и Docker, среди многих других, являются участниками Open Container Initiative (OCI), которая обеспечивает открытую отраслевую стандартизацию контейнерных технологий.

А как насчет безопасности контейнеров?

Контейнеры популярны, но насколько они безопасны? В обеспечении безопасности контейнеров есть много подвижных частей — вам необходимо защитить конвейер контейнера и приложение; среды и инфраструктуры развертывания, и вам нужен план интеграции с корпоративными инструментами и политиками безопасности.Вам нужен план. Мы можем помочь.

Почему выбирают Red Hat для контейнеров Linux?

Red Hat имеет долгую историю работы в сообществе разработчиков ПО с открытым исходным кодом, чтобы сделать такие технологии, как контейнеры, безопасными, стабильными и надежными. Это то, чем мы занимаемся. Затем мы поддерживаем эти технологии. Так что, если вам понадобится помощь, мы всегда рядом.

Технологии Red Hat исключают все догадки, чтобы правильно создавать контейнеры. Решения Red Hat помогут вам получить ваши команды разработчиков на платформе, созданной с учетом контейнеров, запустить инфраструктуру контейнеров в лучшей в своем классе операционной системе или предоставить решения для хранения больших объемов данных, создаваемых контейнерами.

GitHub — lxc / lxc: LXC — Контейнеры Linux

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

Статус

Системные контейнеры

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

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

Непривилегированные контейнеры

Непривилегированные контейнеры — это контейнеры, которые запускаются без каких-либо привилегий. Эта
требует поддержки пространств имен пользователей в ядре, в котором запущен контейнер
на.LXC была первой средой выполнения, которая поддерживала непривилегированные контейнеры после того, как пользователь
пространства имен были объединены в основное ядро.

По сути, пользовательские пространства имен изолируют заданные наборы UID и GID. Это
достигается путем установления соответствия между рядом UID и GID на хосте
к другому (непривилегированному) диапазону UID и GID в контейнере. В
ядро переведет это отображение таким образом, что внутри контейнера все
UID и GID отображаются так, как и следовало ожидать от хоста, тогда как на хосте
эти UID и GID фактически непривилегированы.Например, процесс, работающий как
UID и GID 0 внутри контейнера могут отображаться как UID и GID 100000 на
хост. Сведения о реализации и работе можно получить из
соответствующая страница руководства пространства имен пользователя.

Поскольку непривилегированные контейнеры являются средством повышения безопасности, они, естественно,
с некоторыми ограничениями, налагаемыми ядром. Чтобы в полной мере
функциональный непривилегированный контейнер LXC взаимодействует с 3 частями кода setuid:

• lxc-user-nic (помощник setuid для создания пары veth и подключения ее к хосту)
• newuidmap (из пакета shadow устанавливает карту uid)
• newgidmap (из пакета shadow устанавливает карту gid)

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

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

Более подробное введение в безопасность LXC можно найти по следующей ссылке

Удаление всех привилегий

В принципе LXC может работать без любого из этих инструментов при условии правильного
конфигурация применяется. Однако полезность таких контейнеров обычно
довольно ограниченный.Чтобы выделить две наиболее распространенные проблемы:

1. Сеть

   : без использования помощника setuid для настройки соответствующей сети
   устройства для непривилегированного пользователя (см. двоичный файл LXC lxc-user-nic )
   вариант — разделить сетевое пространство имен с хостом. Хотя это должно
   быть безопасным в принципе, совместное использование сетевого пространства имен хоста по-прежнему остается одним
   шаг изоляции меньше и увеличивает вектор атаки.
   Кроме того, когда хост и контейнер используют одно и то же сетевое пространство имен,
   ядро откажется от монтирования sysfs.Обычно это означает, что двоичный файл init
   внутри контейнера не сможет правильно загрузиться.

2. Пространства имен пользователей: как указано выше, пространства имен пользователей — большая безопасность
   улучшение. Однако, не полагаясь на привилегированных помощников, пользователи, которые
   непривилегированным на хосте разрешено только отображать свой собственный UID в
   контейнер. Однако для стандартной системы POSIX требуется 65536 UID и GID.
   быть доступным, чтобы гарантировать полную функциональность.

Конфигурация

LXC настраивается с помощью простого набора ключей.Например,

• lxc.rootfs.path
• люк, вход

LXC использует ключи конфигурации пространств имен с использованием одиночных точек. Это означает сложный
ключи конфигурации, такие как lxc.net.0 , предоставляют различные подразделы, такие как
lxc.net.0.type , lxc.net.0.link , lxc.net.0.ipv6.address и другие для
еще более мелкозернистая конфигурация.

LXC используется как среда выполнения по умолчанию для LXD,
контейнерный гипервизор, предоставляющий хорошо продуманный и стабильный REST-api поверх
Это.

Требования к ядру

LXC работает на любом ядре, начиная с версии 2.6.32. Все, что для этого требуется, это функционал
Компилятор C. LXC работает на всех архитектурах, которые предоставляют необходимое ядро
Особенности. Это включает (но не ограничивается):

• i686
• x86_64
• ppc, ppc64, ppc64le
• s390x
• armvl7, arm64

LXC также поддерживает как минимум следующие стандартные библиотеки C:

• glibc
• мусл
• бионический (библиотека Android)

Обратная совместимость

LXC всегда ориентировался на сильную обратную совместимость.Фактически, API
не был сломан, начиная с версии 1.0.0 . Главный LXC в настоящее время находится на
версия 4. *. * .

Сообщение о проблемах безопасности

Проект LXC имеет хорошую репутацию в плане быстрого и эффективного решения проблем безопасности.
эффективно. Если вы считаете, что обнаружили потенциальную проблему безопасности, пожалуйста
сообщите об этом по электронной почте всем следующим лицам:

• serge (at) hallyn (точка) com
• stgraber (ат) ubuntu (точка) ком
• христианский.Браунер (в) Ubuntu (точка) ком

Подробности смотрите на

Активное участие в разработке LXC

Мы всегда рады новым участникам и будем рады помочь вам, когда
нужно. LXC следует соглашениям о кодировании ядра. Это означает, что мы только
требовать, чтобы каждая фиксация включала в себя строку Подписано . Стиль кодирования, который мы
использование идентично тому, которое используется ядром Linux. Вы можете найти подробную
введение по адресу:

, а также следует взглянуть на ДОПОЛНИТЕЛЬНЫЙ файл в этом
репо.

Если вы хотите стать более активным, обычно также неплохо появиться в
IRC-канал LXC # lxc-dev на Freenode . Мы стараемся делать все развитие
в открытом виде и обсуждение новых функций или ошибок осуществляется либо в
соответствующие выпуски GitHub или IRC.

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

Семантическое управление версиями

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

Загрузка текущего исходного кода

Исходный код последней выпущенной версии всегда можно скачать с

Вы можете просматривать самый последний исходный код и историю изменений онлайн.

Здание LXC

Без учета специфических деталей распределения простой

  ./autogen.sh && ./configure && make && sudo make install
  

обычно достаточно.

Чтобы протестировать текущий мастер Git LXC, обычно рекомендуется скомпилировать с

 ./autogen.sh && ./configure && make
  

в удобном каталоге и установите LD_LIBRARY_PATH = "$ {BUILD_DIR}" / lxc / src / lxc / .libs .

Получение помощи

Если вам понадобится помощь, проекты LXC предоставят вам несколько вариантов.

Обсудить форум

Мы поддерживаем дискуссионный форум по номеру

, где вы можете получить поддержку.

IRC

Вы можете получить поддержку, присоединившись к #lxcontainers на Freenode .

Списки рассылки

Вы можете проверить один из двух архивов списков рассылки LXC и зарегистрироваться, если
интересовались:

Пора начать все сначала и вернуться к контейнерам LXC — новый стек

Принято считать, что Docker установил стандарт для контейнеров, а Kubernetes отказался от оркестровки. Но один стартап из Мумбаи утверждает, что нам нужно вернуться к началу и начать все сначала — на этот раз с контейнерами Linux (LXC) вместо Docker.

Flockport начал свою деятельность в 2013 году как магазин приложений для серверных приложений, прежде чем сместить акцент на то, чтобы стать альтернативой более сложным решениям, таким как Kubernetes, которые, по словам основателя Flockport Индраджита Банерджи, значительно усложняют ситуацию и требуют гораздо большего опыта, чем может справиться большинство компаний. . Проблема, по словам Банерджи, возникла с уходом от LXC и тремя конкретными дизайнерскими решениями, принятыми Docker.

«Проект LXC предоставляет стандартные многопроцессорные контейнеры.Они похожи на легкие виртуальные машины. Docker взял это и изменил, чтобы предоставить вам «однопроцессные контейнеры», — написал Банерджи в электронном письме. «И это имеет существенные последующие эффекты с точки зрения сложности и накладных расходов на управление».

Ссылаясь на сообщение в блоге, которое он написал о том, почему вы должны «говорить« да контейнерам, а нет — сложности », Банерджи объяснил, что он ошибает Docker в применении однопроцессных контейнеров, использовании слоев с использованием aufs и overlayfs. virtaul файловых систем и превращение контейнерных приложений в «лишенные состояния по указу» — три решения, которые, по его мнению, привели к неуправляемому уровню сложности.

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

«Предприятия все чаще переходят на гибридную и мультиоблачную стратегию, и контейнеры являются идеальным средством решения этого варианта использования», — написал Банерджи в заявлении компании. «Хотя DevOps нацелен на разработчиков, реальная история контейнеров находится в стадии развертывания, и Flockport предлагает комплексную платформу, которая демонстрирует истинную мощность и гибкость контейнеров.”

Flockport предоставляет то, что Банерджи называет «стандартной средой ОС», что означает, что она не требует приложений без сохранения состояния, использования уровней или ограничения одного процесса в контейнере, и тем самым обеспечивает «плавную миграцию приложений». с виртуальных машин без необходимости какой-либо настройки или дорогостоящего реинжиниринга »и позволяя переносить приложения« как есть ».

В интервью The New Stack Банерджи сказал, что эта «нестандартная среда ОС», предоставляемая Docker и Kubernetes, создает трудности для компаний, стремящихся перейти от устаревших приложений к контейнерам.

«Когда мы начинали, с Docker мы столкнулись с рядом проблем. Это создает небольшую нагрузку на управление и немного усложняет работу. Это дает вам нестандартную среду ОС. В основе вашего стека находится нестандартная среда ОС, которая добавляет сложности. Когда вы хотите мигрировать, это становится препятствием », — сказал Банерджи. «Существуют огромные возможности для контейнеров, все развертывается в виртуальных машинах, и вы можете довольно легко перейти от виртуальной машины к контейнеру LXC со всеми своими инструментами, не вдаваясь в управление однопроцессными контейнерами и способом работы Docker.Я думаю, что это препятствует переходу ».

Угроза, которую представляет текущая сложность контейнеров, утверждает Банерджи, выходит за рамки сложности миграции, а скорее угрожает подорвать всю отрасль. Он сравнивает нынешнюю атмосферу с атмосферой OpenStack.

«В настоящее время вся экосистема состоит из Docker, Kubernetes и всех этих других сервисов, и все эти компании создают решения на их основе. То же самое произошло с OpenStack, но люди продолжали жаловаться на сложность, и в какой-то момент он просто сработал », — сказал Банерджи.«Это то же самое, что и меня, потому что это может отвлечь людей от контейнеров, и они будут продолжать работать с AWS и виртуальными машинами, не беспокоясь. Если это будет так сложно и так дорого, каковы преимущества? »

Flockport впервые выпускает свое программное обеспечение в публичный доступ и предлагает демонстрационные примеры управления контейнерами, предоставления серверов, работы в сети, хранения и обнаружения сервисов. Банерджи сказал, что Flockport написан на Python и имеет открытый исходный код под лицензией GPL, хотя команда из пяти человек еще не разместила его на GitHub.Flockport в настоящее время доступен для загрузки либо с установщиком, либо для запуска в качестве виртуальных машин.

Изображение функции через Pixabay.

Контейнеры TurnKey LXC LinuX | TurnKey GNU / Linux

You are here

Home / Контейнеры TurnKey LXC LinuX

1 хост, несколько приложений TurnKey

TurnKey LXC упрощает загрузку и развертывание нескольких приложений TurnKey бок о бок на одном и том же хосте в надежно изолированных легких контейнерах, при этом обрабатывая сложные детали, такие как сетевая маршрутизация.LXC (также известная как LinuX Containers) — это восходящая звезда облегченной технологии виртуализации, которая поддерживает Docker и другие платформы развертывания программного обеспечения следующего поколения.

Это устройство включает в себя все стандартные функции TurnKey Core, а также:

• Включает шаблон TurnKey LXC:
  • Загрузите и создайте контейнер любого устройства TurnKey.
  • Вставить указанный inithooks.conf в контейнер для предварительной загрузки.
  • Поддерживает конфигурацию сетевого соединения (например,g., br0, natbr0, нет).
  • Поддерживает настройку apt proxy.
  • Проверяет подписи GPG, если они доступны
  • Обертка для lxc-destroy убирается после удаления контейнера
  • Поддерживает LVM в группе томов TurnKey по умолчанию «под ключ»
  • Позволяет устройству TurnKey Ansible управлять контейнерами LXC
  • Достаточно универсален для использования в любом дистрибутиве с поддержкой LXC.
• Легко предоставлять услуги контейнеров NAT:
  • nginx-proxy: предоставить доступ к веб-службам контейнеров в сети, создав конфигурацию сайта nginx для проксирования всех веб-запросов (порты 80, 443, 12320, 12321, 12322), предназначенных для определенного домена, контейнеру на соответствующих портах.
  • iptables-nat: Предоставьте сети не веб-службу контейнеров (например, SSH), настроив iptables на хосте для пересылки трафика, получаемого через порт X, в контейнер через порт Y.

Конфигурации устройства

• LXC:
  • Предварительно настроенный интерфейс сетевого моста (br0).
  • Предварительно настроенный интерфейс сетевого моста NAT (natbr0).
  • Предварительно сконфигурированный dnsmasq на natbr0, обеспечивающий службы DHCP и DNS. На контейнеры можно ссылаться по имени хоста или имени хоста.local.lxc
  • Включает apt-cacher-ng, привязку к интерфейсу natbr0.
  • Включает веб-панель управления TurnKey (удобство).
  • Включает пример конфигурации inithooks для предварительной загрузки (для удобства).
  • IP-переадресация и группы управления включены.
• LXC ограничения:
  • Устройство LXC не может работать во вложенном режиме, т.е. в контейнере LXC без дополнительной настройки. Этот режим не рекомендуется для производственных систем из соображений безопасности.

Дополнительные сведения см. В документации по использованию.

Сведения об использовании и вход в систему для администрирования

Нет паролей по умолчанию : По соображениям безопасности паролей по умолчанию нет. Все пароли устанавливаются во время инициализации системы.

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

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

Войдите в систему как root , за исключением торговой площадки AWS, где используется имя пользователя admin .

1. Укажите в браузере:
2. Войти через SSH-клиент:

   ssh [email protected]
    

   Особый случай для торговой площадки AWS:

   ssh [email protected]
    

* Замените 12.34.56.789 действительным IP-адресом или именем хоста.

Можно ли запустить контейнер LXC внутри контейнера LXC?

Здесь я развею несколько мифов.

Это просто плохая идея. Мне жаль. — Джейкоб 5 марта в 20:30

Я не понимаю, почему это плохая идея. На самом деле это просто chroot внутри chroot. С одной стороны, это могло привести к незначительному снижению производительности (ничто по сравнению с запуском виртуальной машины внутри виртуальной машины). С другой стороны, он, вероятно, будет более безопасным (например, более изолированным от корневой хост-системы и ее составляющих).

У вас на самом деле есть реальная причина для этого? Помните, что вопросы здесь должны касаться реальных проблем, с которыми вы сталкиваетесь.- Zoredache, 5 марта в 21:52,

Я на 100% согласен со следующим комментарием автора. Более того, я думаю, что можно с уверенностью предположить, что каждый, кто задает здесь вопрос, вероятно, думает, что у него есть реальная причина сделать [это].

Я думаю, что lxc должен упростить миграцию ВМ (а также резервное копирование + восстановление). Но я не уверен в случаях, когда нет доступа к хост-ОС (например, дешевые vps). — Михаил 6 марта в 11:17

Я действительно столкнулся с этим вопросом еще в июне, когда впервые погрузился в LXC для проектов PaaS / IaaS, и меня особенно интересовала возможность позволить пользователям эмулировать облачные среды в целях разработки.

LXОпция. Мы слишком глубоко. — Том О’Коннор, 6 марта, 22:46,

Я немного посмеялся, когда прочитал это, но это совсем не так 🙂

В любом случае, я в конце концов установил среду VirtualBox со стандартной установкой Ubuntu 12.04 LTS Server Edition после прочтения всего этого, думая, что это 100% возможно. После установки LXC я создал новый контейнер и установил LXC внутри контейнера с помощью apt-get. По большей части установка прошла успешно, но в конечном итоге привела к ошибке из-за проблемы с пакетом cgroup-lite, чье задание выскочки не удалось запустить после установки пакета.

После небольшого поиска я наткнулся на эту прекрасную статью на stgraber.org (полезности скрываются в разделе «Вложение контейнеров»):

  sudo apt-get install lxc
sudo lxc-create -t ​​ubuntu -n мой-хост-контейнер -t ubuntu
sudo wget https://www.stgraber.org/download/lxc-with-nesting -O /etc/apparmor.d/lxc/lxc-with-nesting
sudo /etc/init.d/apparmor reload
sudo sed -i "s / # lxc.aa_profile = неограниченный / lxc.aa_profile = lxc-container-with-nesting /" / var / lib / lxc / my-host-container / config
sudo lxc-start -n мой-хост-контейнер
(в моем-хост-контейнере) sudo apt-get install lxc
(в контейнере my-host) sudo stop lxc
(в моем-хост-контейнере) sudo sed -i "s / 10.0,3 / 10,0,4 / г "/ и т. Д. / По умолчанию / lxc
(в моем-хост-контейнере) sudo start lxc
(в моем-хост-контейнере) sudo lxc-create -n my-sub-container -t ubuntu
(в моем-хост-контейнере) sudo lxc-start -n my-sub-container
  

Установка этой политики AppArmor и перезапуск демона помогли (не забудьте изменить сетевые диапазоны!).