5.4. Файл конфигурации

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

Детальная информация доступна на странице lxc.conf(5) руководства man. Обратите внимание, что конфигурации по умолчанию, созданные по ubuntu шаблонам, подходят для системных контейнеров и не требуют настройки.

5.4.1. Выбор файлов и опций настройки

Установка контейнера управляется параметрами настроек LXC. Параметры могут быть указаны в нескольких местах:

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

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

•Файл /var/lib/lxc/CN/config, используемый по умолчанию при запуске контейнера.

•lxc-start воспринимает альтернативный файл настроек с помощью параметра -f filename

•Отдельные переменные настроек могут быть переопределены в команде lxc-start с использованием параметра -s key=value. В общем случае лучше редактировать конфигурационный файл.

5.4.2. Настройка сети

Настройки сети в LXC контейнерах очень гибкие. Они переключаются lxc.network.type записями в файле настроек. Если таких записей

411

Виртуализация

нет, то контейнер будет разделять сетевой стек основной системы. Сервисы и соединения, запущенные в контейнере, будут использовать IP-адрес основной системы. Если хотя бы одна запись lxc.network.type присутствует, то контейнер получит частный (уровня 2) сетевой стек. Он будет иметь собственные сетевые интерфейсы и правила firewall. Существует несколько опций для lxc.network.type:

•lxc.network.type=empty: Контейнер не будет иметь других сетевых интерфейсов, кроме loopback.

•lxc.network.type=veth: Это выбор по умолчанию, когда используются шаблоны ubuntu или ubuntu-cloud, и в этом случае создаётся veth сетевой туннель. Один конец этого туннеля становится сетевым интерфейсом внутри контейнера, другой подключается к интерфейсу моста основной системы. Любое количество таких туннелей может быть создано добавлением записей lxc.network.type=veth в конфигурационный файл. Мост, к которому будут подсоединяться туннели, определяется с помощью lxc.network.link = lxcbr0.

•lxc.network.type=phys Физический сетевой интерфейс (т.е. eth2) передаётся в контейнер.

Еще две опции, которые можно использовать, это vlan и macvlan, однако их использование более сложное и не будет здесь рассматриваться. Существует еще несколько других сетевых параметров:

•lxc.network.flags может быть установлено только в up и требуется для проверки, что сетевой интерфейс поднят.

•lxc.network.hwaddr определяет MAC-адрес для присвоения сетевой карте внутри контейнера.

•lxc.network.ipv4 и lxc.network.ipv6 устанавливают соответствующие IP-

адреса, если они должны быть статичными.

•lxc.network.name определяет имя для присвоения внутри контейнера. Если не определено, выбираются правильные умолчания (т.е. eth0 для первой сетевой карты).

•lxc.network.lxcscript.up пределяет сценарий, который должен быть вызван после поднятия сети со стороны основной системы. Смотрите страницу lxc.conf(5) руководства man для деталей.

5.4.3. Настройка групп управления

Опции cgroup могут быть указаны с использованием записей llxc.cgroup. lxc.cgroup.subsystem.item = value указывает LXC установить для элемента item подсистемы subsystem значение value. Это возможно проще реализовать, чем просто записать значение в файл группы

412

Виртуализация

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

lxc.cgroup.memory.limit_in_bytes = 320000000

что заставит записать значение 320000000 в файл /sys/fs/cgroup/memory/lxc/

CN/limit_in_bytes.

5.4.4. Rootfs, элементы монтирования и fstab

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

lxc.rootfs = /var/lib/lxc/CN/rootfs lxc.mount.entry=proc /var/lib/lxc/CN/rootfs/proc proc nodev,noe

Первая строка говорит, что корневая файловая система контейнера уже смонтирована в /var/lib/lxc/CN/rootfs. Если файловая система является блочным устройством (таким как логический том LVM), то вместо этого потребуется указать путь до блочного устройства.

Каждая строка lxc.mount.entry должна содержать элемент для монтирования в правильном формате fstab. Целевой каталог должен предваряться /var/lib/lxc/CN/rootfs, даже если lxc.rootfs указывает на блочное устройство.

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

5.4.5. Другие опции настройки

•lxc.cap.drop может быть использована для предотвращения получения контейнером указанных возможностей. Например, добавление

lxc.cap.drop = sys_admin

предотвратит возможность монтирования файловых систем, так же как другие действия, которые требуют cap_sys_admin. Смотрите страницу capabilities(7) руководства man для перечня возможностей и их толкований.

413

Виртуализация

•lxc.aa_profile = lxc-CN-profile определяет специальные профили

Apparmor в которых запускать контейнер. Смотрите Раздел 5.2.6, «Apparmor» [398] для дополнительной информации.

•lxc.console=/path/to/consolefile определяет что консольные сообщения должны записываться в указанный файл.

•lxc.arch определяет архитектуру контейнера, например, x86 или x86_64.

•lxc.tty=5 определяет, что должны быть созданы 5 консолей (в дополнение к /dev/console). Соответственно, будут доступны консоли от / dev/tty1 до /dev/tty1. Шаблоны ubuntu устанавливают это значение в 4.

•lxc.pts=1024 определяет, что контейнер должен иметь смонтированную

частную (Unix98) файловую систему devpts. Если не указано, то контейнер будет разделять (иметь в совместном доступе) /dev/pts с основной системой, что редко бывает желательным. Число 1024 означает, что 1024 pty должны быть доступны в контейнере, однако это число в настоящее время игнорируется. Перед запуском инициализации контейнера, LXC (по существу) выполняет

sudo mount -t devpts -o newinstance devpts /dev/pts

внутри контейнера. Важно понимать, что контейнер не может монтировать файловые системы devpts сам по себе. Он может безопасно присоединить или переместить точки монтирования своих смонтированных /dev/pts. Но если он выполнит

sudo mount -t devpts devpts /dev/pts

он перемонтирует экземпляры devpts основной системы. Если добавлена опция монтирования newinstance, то это смонтирует новые частные (пустые) экземпляры. Ни в одном случае он не может перемонтировать экземпляры, определенные LXC. По этой причине и для предотвращения использования контейнером pty основной системы, политика Apparmor по умолчанию не позволяет контейнерам монтировать файловые системы devpts после запуска инициализации контейнера.

•lxc.devttydir определяет каталог внутри /dev, в котором LXC будет создавать свои консольные устройства. Если эта опция не определена, то все pty будут монтироваться связыванием с /dev/console и /dev/ttyN. Однако изредка обновления пакетов могут пытаться слепо выполнять rm -f и затем mknod для этих устройств. Это будет приводить к сбоям (поскольку используется монтирование связыванием), что приведет к сбою установки обновлений. Когда lxc.devttydir установлен на LXC, например, то LXC будет монтировать связыванием консоли pty в /dev/ lxc/console и /dev/lxc/ttyN и впоследствии символически связывают их

414