Руководство по Ubuntu Server


euca-run-instances $EMI -k mykey -t m1.small --user-data-file=cloud-config.txt



Pdf просмотр
страница14/16
Дата17.11.2016
Размер1.78 Mb.
Просмотров3800
Скачиваний3
ТипРуководство
1   ...   8   9   10   11   12   13   14   15   16
euca-run-instances $EMI -k mykey -t m1.small --user-data-file=cloud-config.txt
Теперь, когда система загрузится, в ней будет:
• Добавлен Apache Edgers PPA
• Выполнено обновление
• Установлены пакеты 'build-essential' и 'pastebinit'
• Выведено сообщение, подобное имеющемуся в вышеописанном сценарии
Apache Edgers PPA из приведённого выше примера содержит последнюю версию Apache из репозиториев исходного кода в апстриме. Для версий пакета из PPA поддержка не предоставляется

Виртуализация
385
и, в зависимости от вашей ситуации, это может быть, а может и не быть желательным. Дополнительный подробности смотрите на веб- странице Ubuntu Server Edgers
20
Команды 'runcmd' запускаются на том же этапе загрузки, что и сценарий
'#!' из предыдущего примера. Это позволяет вам пользоваться всей мощью языка сценариев, в то же время не отказываясь от cloud-config.
Для дополнительной информации о том, что можно сделать с помощью cloud-config, смотрите doc/examples
21
в исходном коде.
3.9. Дополнительная информация
Как использовать контроллер хранения
22
Управление службами eucalyptus:
• sudo service eucalyptus [start|stop|restart] (на стороне CLC/CC/SC/Walrus)
• sudo service eucalyptus-nc [start|stop|restart] (на стороне узла)
Местонахождение некоторых важных файлов:
Файл журнала
• /var/log/eucalyptus
Файлы конфигурации:
• /etc/eucalyptus
База данных:
• /var/lib/eucalyptus/db
Ключи:
• /var/lib/eucalyptus
• /var/lib/eucalyptus/.ssh
Не забудьте источник вашей
/.euca/eucarc перед запуском клиентских средств.
3.10. Ссылки
• Информацию по загрузке экземпляров смотрите на странице Eucalyptus
Wiki
23
Сайт проекта Eucalyptus (форум, документация, загрузки)
24 20
https://launchpad.net/
ubuntu-server-edgers
21
http://bazaar.launchpad.net/
cloud-init-dev/cloud-init/trunk/files/head:/doc/examples/
22
https://help.ubuntu.com/community/UEC/StorageController
23
https://help.ubuntu.com/community/Eucalyptus
24
http://open.eucalyptus.com/

Виртуализация
386
Eucalyptus на Launchpad (ошибки, исходный код)
25
Поиск и устранение неисправностей Eucalyptus (1.5)
26
Зарегистрировать облако с RightScale
27
• Вы также можете получить помощь в IRC-каналах #ubuntu-virt,
#eucalyptus, и #ubuntu-server на Freenode
28 25
https://launchpad.net/eucalyptus/
26
http://open.eucalyptus.com/wiki/EucalyptusTroubleshooting_v1.5 27
http://support.rightscale.com/2._References/02-Cloud_Infrastructures/Eucalyptus/03-Administration_Guide/
Register_with_RightScale
28
http://freenode.net

Виртуализация
387
4. Облако Ubuntu
Облачные вычисления (cloud computing) — это модель вычислений, которая позволяет использовать распределять по запросу ресурсы из большого общего объёма доступных ресурсов. Эти ресурсы, такие как хранилище,
вычислительная мощность, сеть и программное обеспечение, являются абстрактными и могут предоставляться как сервис через Интернет в любом месте и в любое время. Оплата этих сервисов производится за использованное время, аналогично тому, как это делается для таких общедоступных услуг, как электроснабжение, водоснабжение и телефон.
Облачная инфраструктура Ubuntu использует открытое программное обеспечение OpenStack для создания масштабируемых решений в области облачных вычислений как для открытых, так и для частных облаков.
4.1. Обзор
Это руководство показывает установку OpenStack с компакт-диска Ubuntu
12.04 LTS Server Edition и предполагает наличие базовой сетевой топологии с единственной обслуживающей системой по принципу облачной системы "всё в одном". Поскольку рассмотрение упрощено, данные инструкции как есть не предназначены для построения промышленных серверов, а только позволяют вам получить проверку концепции построения облака Ubuntu с использованием OpenStack.
4.2. Необходимые требования
Для развертывания минимальной облачной инфраструктуры Ubuntu нужно,
как минимум, следующее:
• Одна выделенная система.
• Два сетевых диапазона адресов (частная сеть и сеть общего пользования).
• Убедитесь, что хост имеет аппаратную поддержку виртуализации (VT),
так как мы будем использовать технологию виртуализации KVM. Другие гипервизоры, такие как QEMU, UML, Vmware ESX / ESXi и XEN. LXC (Linux
Containers) также поддерживаются через Libvirt.
Проверьте, поддерживает ли ваша система kvm, набрав sudo kvm-ok в терминале linux.
"Минимальной топологией", рекомендуемой для применения в промышленных решениях, является использование трёх узлов: одного главного сервера, на котором запущены службы nova (за исключением

Виртуализация
388
compute) и двух серверов, на которых запущена nova-compute. Эта установка не является избыточной, и главный сервер является единственной точкой отказа (SPoF).
4.3. Предварительная настройка сети
Прежде чем мы начнем установку OpenStack, мы должны убедиться, что у нас установлена поддержка моста, базы данных MySQL, и служба времени
(ntp). Это будет гарантировать, что экземпляры и хосты синхронизированы.
В этом примере "частная сеть" будет находиться в диапазоне 10.0.0.0/24 на eth1. Все внутренние связи между экземплярами будут производиться там,
а "сеть общего пользования" будет находиться в диапазоне 10.153.107.0/29
на eth0.
4.3.1. Установка поддержки моста
sudo apt-get install bridge-utils
4.3.2. Установка и настройка NTP
sudo apt-get install ntp
Добавьте следующие две строки в конце файла
/etc/ntp.conf server 127.127.1.0
fudge 127.127.1.0 stratum 10
Перезапустите службу ntp
sudo service ntp restart
4.3.3. Установка и настройка MySQL
sudo apt-get install mysql-server
Создайте базу данных и пользователя mysql для OpenStack
sudo mysql -uroot -ppassword -e "CREATE DATABASE nova;"
sudo mysql -uroot -ppassword -e "GRANT ALL ON nova.* TO novauser@localhost \
IDENTIFIED BY 'novapassword' ";
Символ продолжения строки "\" подразумевает, что следующая строка является частью текущей команды.

Виртуализация
389 4.4. Установка OpenStack Compute (Nova)
Вычислительный ресурс OpenStack (Nova) является диспетчером облачного процесса вычислений (основной частью системы IaaS —
инфраструктура как сервис). Он написан на Python с использованием оболочек Eventlet и Twisted и опирается на стандартный протокол сообщений AMQP, а также SQLAlchemy для доступа к хранилищам данных.
Установите компоненты OpenStack Nova
sudo apt-get install nova-api nova-network nova-volume nova-objectstore nova-scheduler \
nova-compute euca2ools unzip
Перезапустите libvirt-bin, чтобы убедиться, что libvirtd знает о средстве фильтрации пакетов ebtables.
sudo service libvirt-bin restart
Установите RabbitMQ — реализацию протокола AMQP (Advanced Message
Queuing Protocol)
sudo apt-get install rabbitmq-server
Отредактируйте
/etc/nova/nova.conf
, добавив следующее:
# Nova config FlatDHCPManager
--sql_connection=mysql://novauser:novapassword@localhost/nova
--flat_injected=true
--network_manager=nova.network.manager.FlatDHCPManager
--fixed_range=10.0.0.0/24
--floating_range=10.153.107.72/29
--flat_network_dhcp_start=10.0.0.2
--flat_network_bridge=br100
--flat_interface=eth1
--public_interface=eth0
Перезапустите службы OpenStack
for i in nova-api nova-network nova-objectstore nova-scheduler nova-volume nova-compute; \
do sudo stop $i; sleep 2; done
for i in nova-api nova-network nova-objectstore nova-scheduler nova-volume nova-compute; \
do sudo start $i; sleep 2; done
Выполните миграцию базы данных Nova из sqlite в MySQL. Это может занять некоторое время.

Виртуализация
390
sudo nova-manage db sync
Определим отдельную частную сеть, в которой будут работать все ваши элементы. Она будет использоваться с фиксированными адресами IP,
указанными в nova.conf
sudo nova-manage network create --fixed_range_v4 10.0.0.0/24 --label private \
--bridge_interface br100
Определите конкретную сеть общего пользования и выделите 6 (полезных)
плавающих публичных IP-адреса для использования в случаях, начиная с
10.153.107.72.
sudo nova-manage floating create --ip_range=10.153.107.72/29
Создайте пользователя (user1), проект (project1), скачайте учётные данные и файл конфигурации.
cd ; mkdir nova ; cd nova
sudo nova-manage user admin user1
sudo nova-manage project create project1 user1
sudo nova-manage project zipfile project1 user1
unzip nova.zip
source novarc
Проверьте установку OpenStack Compute, набрав:
sudo nova-manage service list
sudo nova-manage version list
Если службы Nova не отображаются корректно, перезапустите службу
OpenStack, как описано выше. Для получения дополнительной информации обратитесь к разделу этого руководства, посвящённому поиску и устранению неисправностей.
4.5. Установка сервиса управления образами (Glance)
Nova использует сервис Glance для управления образами операционных систем, которые требуются для поднятия экземпляров системы. Glance может использовать различные типы систем хранилищ, такие как файловое хранение, S3 (Simple Storage Service) и пр. Glance состоит из двух компонентов: glance-api and glance-registry. Они могут управляться с использованием соответствующих задач загрузки сервисов. Для нашего примера в качестве хранилища мы будем использовать mysql.

Виртуализация
391
Установите Glance
sudo apt-get install glance
Создайте базу данных и пользователя для glance
sudo mysql -uroot -ppassword -e "CREATE DATABASE glance;"
sudo mysql -uroot -ppassword -e "GRANT ALL ON glance.* TO glanceuser@localhost \
IDENTIFIED BY 'glancepassword' ";
Отредактируйте файл /etc/glance/glance-registry.conf, изменив содержимое строки, которая содержит опцию "sql_connection =", на следующее:
sql_connection = mysql://glanceuser:glancepassword@localhost/glance
Удалите базу данных sqlite
rm -rf /var/lib/glance/glance.sqlite
Перезапустите glance-registry после того, как измените /etc/glance/glance- registry.conf. База данных MySQL будет автоматически заполнена.
sudo restart glance-registry
Если возникли ошибки, взгляните на файлы журнала в /var/log/glance/api.log и /var/log/glance/registry.log.
4.6. Запуск экземпляров
Прежде чем вы сможете использовать образы, необходимо сначала установить учётные данные пользователя. После этого первого шага также необходимо загрузить образы, которые вы хотите запустить в облака.
Если у вас есть эти образы, загруженные в облако, вы сможете работать и подключаться к ним. Вот шаги, которым вы должны следовать, чтобы получить запущенныe экземпляры OpenStack Nova:
Скачайте, зарегистрируйтесь и опубликуйте образы в облаке Ubuntu
distro=lucid
wget http://cloud-images.ubuntu.com/$distro/current/$distro-server-cloudimg-amd64.tar.gz
cloud-publish-tarball "$distro"-server-cloudimg-amd64.tar.gz "$distro"_amd64
Создайте ключевую пару для пользователя и подготовьте экземпляр системы:
cd
/nova


Виртуализация
392
source novarc
euca-add-keypair user1 > user1.priv
chmod 0600 user1.priv
Разрешите доступ по icmp (ping) и ssh к экземплярам:
euca-authorize default -P tcp -p 22 -s 0.0.0.0/0
euca-authorize -P icmp -t -1:-1 default
Запустите экземпляр
ami=`euca-describe-images | awk {'print $2'} | grep -m1 ami`
euca-run-instances $ami -k user1 -t m1.tiny
euca-describe-instances
Назначьте публичный адрес экземпляру.
euca-allocate-address
euca-associate-address -i instance_id public_ip_address
euca-describe-instances
Вы здесь должны ввести instance_id (ami) и public_ip_address, показанные выше командами euca-describe-instances и euca-allocate-address.
Теперь вы должны добавить SSH к экземпляру
ssh -i user1.priv ubuntu@ipaddress
Для завершения экземпляра
euca-terminate-instances instance_id
4.7. Установите инфраструктуру хранения данных (Swift)
Swift является высокодоступным, распределённым, с согласованностью в к конечном счёте (eventually consistent) хранилищем объектов/блобов. Он используется OpenStack, как инфраструктура для обеспечения S3, подобно облачным сервисам хранения данных. Он также S3 API совместимый с
Amazon.
Организации используют Swift для эффективного, безопасного и недорогого хранения больших объёмов данных, при этом приложения используют специальные API для взаимодействия между приложениями и объектами, хранящимися в Swift.
Хотя вы можете установить Swift на единственный сервер, для промышленных сред требуется установка на несколько серверов. Если вы

Виртуализация
393
хотите установить хранилище объектов OpenStack (Swift) на отдельный сетевой сервер для разработки или тестирования, используйте инструкции установки 'Swift всё в одном' на Ubuntu.
Для получения дополнительной информации смотрите: http://
swift.openstack.org/development_saio.html
29 4.8. Поддержка и устранение неисправностей
Поддержка сообщества
Список рассылки OpenStack
30
Поиск в Wiki OpenStack
31
Сообщения об ошибках на Launchpad
32
• Присоединитесь к каналу IRC #openstack на freenode.
4.9. Ресурсы
Облачные вычисления — сервисные модели.
33
Вычисления OpenStack
34
Сервис образов OpenStack
35
Руководство администратора OpenStack Object Storage
36
Установка OpenStack Object Storage на Ubuntu
37
http://cloudglossary.com/
4.10. Словарь терминов
Документация по облаку Ubuntu использует терминологию, которая может быть непонятна некоторым читателям. Этот раздел предоставляет словарь таких терминов и аббревиатур.
Облако (Cloud) — объединённый набор физических машин, которые предлагают вычислительные ресурсы с помощью виртуальных машин,
резервируемых и выделяемых динамически.
IaaS (инфраструктура как сервис) — сервисы облачной инфраструктуры,
благодаря которым виртуальное окружение предоставляется
29
http://swift.openstack.org/development_saio.html
30
https://launchpad.net/
openstack
31
http://wiki.openstack.org
32
https://bugs.launchpad.net/nova
33
http://en.wikipedia.org/wiki/Cloud_computing#Service_Models
34
docs.openstack.org/trunk/openstack-compute/
35
http://docs.openstack.org/diablo/openstack-compute/starter/content/GlanceMS-d2s21.html
36
OpenStack Object Storage Administration Guide
37
http://docs.openstack.org/trunk/openstack-object-storage/admin/content/installing-openstack-object-storage-on- ubuntu.html

Виртуализация
394
провайдером в виде сервиса через интернет. Инфраструктура может включать сервера, сетевое оборудование и программное обеспечение.
EBS - Эластичное блочное хранилище.
EC2 - Эластичное облако вычислений. Общедоступные облачные вычисления, предоставляемые Amazon на основе почасовой или погигабайтной оплаты.
Узел (Node) — физическая машина, которая может запускать виртуальные машины по команде контроллера узлов (node controller).
Для Ubuntu это в основном означает, что центральный процессор (CPU)
поддерживает расширения аппаратной виртуализации (VT) и может запускать гипервизор KVM.
S3 — Simple Storage Service (простой сервис хранения). Решение Amazon для предоставления хранилища с погигабайтной оплатой для EC2.
Ubuntu Cloud — облако Ubuntu. Решение облачных вычислений для
Ubuntu, основанное на OpenStack.
VM — виртуальная машина.
VT — технология виртуализации. Особенность некоторых современных процессоров, позволяющая ускорять работу виртуальных машин.

Виртуализация
395
5. LXC
Контейнеры представляют из себя облегчённую технологию виртуализации. Они больше похожи на chroot чем на полноценную виртуализацию типа Qemu или VMware, поскольку они не эмулируют оборудование, а также используют в разделяемом режиме ту же операционную систему, что и основная система. Поэтому контейнеры лучше сравнивать с зонами (zones) Solaris или изоляторами (jails) BSD. Linux- vserver и OpenVZ — это две предыдущие разработки контейнеро-подобной функциональности для Linux. На самом деле контейнеры получились, как результат работы по слиянию функциональности vserver and OpenVZ.
Некоторая функциональность vserver и OpenVZ всё ещё отсутствует в контейнерах, однако контейнеры могут загружаться множеством дистрибутивов Linux и имеют то преимущество, что они могут запускаться на неизменённом ядре.
Существует две реализации пользовательского пространства контейнеров,
каждая из которых использует те же самые возможности ядра. Libvirt позволяет использовать контейнеры через драйвер LXC, подсоединяясь к 'lxc:///'. Это очень удобно, поскольку поддерживается то же использование,
что и для других драйверов. Другая реализация, называемая просто 'LXC',
несовместима с libvirt, но более гибкая с использованием дополнительных утилит пользовательского пространства. Есть возможность переключаться с одной на другую, хотя существуют особенности, которые могут привести в замешательство.
В этом документе мы будем рассматривать в основном пакет lxc. Ближе к концу будет описано, как использовать драйвер libvirt LXC.
В этом документе имя контейнера будет указано, как CN, C1, или C2.
5.1. Установка
Пакет lxc может быть установлен так
sudo apt-get install lxc
Это повлечет за собой обязательные и рекомендуемые зависимости,
в том числе cgroup-lite, lvm2, и debootstrap. Чтобы использовать libvirt- lxc, установить libvirt-bin. LXC и libvirt-lxc могут быть установлены и использоваться в одно и то же время.

Виртуализация
396 5.2. Настройка хоста
5.2.1. Основная структура LXC файлов
Ниже приводится описание файлов и каталогов, которые установлены и используются LXC.
• Существует два задания отслеживания:

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

/etc/init/lxc.conf:
запускается если LXC_AUTO (по умолчанию true)
установлена в
/etc/default/lxc
.Оно отслеживает записи в
/etc/lxc/auto/
которые являются символическими ссылками на файлы конфигураций для контейнеров, которые должны быть запущены при загрузке системы.

/etc/lxc/lxc.conf:
По умолчанию контейнер создается в конфигурационным файле
/etc/lxc/lxc.conf
, который управляет контейнерами посредством
LXC bridge, созданным lxc-net при запуске upstart. Если при создании контейнера не указан конфигурационный файл, то будет использован конфигурационный файл по умолчанию.
• Примеры конфигурационных файлов других контейнеров находятся здесь
/usr/share/doc/lxc/examples
. Они показывают, как создать контейнер без частной сети или используя macvlan, vlan, или другие сетевые уровни.
• Административные утилиты для различных контейнеров находятся здесь
/usr/bin

/usr/lib/lxc/lxc-init
— минимальная очень легковесная инициализирующая программа, которая используется lxc-execute. Вместо того, чтобы загружать весь контейнер, она вручную монтирует несколько файловых систем, главным образом
/proc
, и отрабатывает их аргументы.
Вам нежелательно обращаться к этому файлу вручную.

/usr/lib/lxc/templates/
содержит `шаблоны', которые можно использовать для создания новых контейнеров для различных дистрибутивов и разновидностей этих дистрибутивов. В настоящее время поддерживаются не все шаблоны.

/etc/apparmor.d/lxc/lxc-default содержит профиль Apparmor доступа по умолчанию, который обеспечивает защиту основной системы от контейнеров. Дополнительную информацию смотрите в разделе
Раздел 5.2.6, «Apparmor» [398].

/etc/apparmor.d/usr.bin.lxc-start содержит профиль для защиты основной системы от lxc-start пока он устанавливает контейнер.

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

/etc/apparmor.d/lxc-containers заставляет все профили, определенные в
/etc/
apparmor.d/lxc
, загружаться при старте системы.
• Существует множество man-страниц по по средствам администрирования
LXC, а также конфигурационному файлу контейнеров lxc.conf

/var/lib/lxc
— здесь хранятся контейнеры и информация по их настройкам.

/var/cache/lxc
— здесь кэшируются данные дистрибутивов для ускорения создания множества контейнеров.
5.2.2. lxcbr0
Когда USE_LXC_BRIDGE установлена в true в файле /etc/default/lxc (как впрочем по умолчанию), мост с именем lxcbr0 создаётся в процессе старта. Этот мост получает частный адрес 10.0.3.1, а контейнеры его использующие получат адреса из диапазона 10.0.3.0/24. Экземпляр dnsmasq начинает прослушивать этот мост, поэтому если другой dnsmasq получает связь со всеми интерфейсами до запуска отслеживающего сервиса lxc-net, lxc-net рушится на старте и lxcbr0 не создается.
Если у вас есть другой мост, например, virbr0 по умолчанию от libvirt или br0 для вашего основного сетевого интерфейса, вы можете использовать его вместо lxcbr0 для ваших контейнеров.
5.2.3. Использование отдельной файловой системы для хранения контейнеров
LXC сохраняет информацию контейнеров и корневую файловую систему
(с резервным хранилищем по умолчанию) в
/var/lib/lxc
. Также шаблоны создания контейнеров предпочитают хранить кэшированную информацию по дистрибутивам в
/var/cache/lxc
Если вы хотите использовать для
/var
, иную файловую систему, вы можете смонтировать в этот каталог другую файловую систему большего объёма.
Если у вас есть диск, предназначенный для этих целей, вы можете просто смонтировать его в
/var/lib/lxc
. Если вы предпочитаете использовать другое расположение, такое как
/srv
, вы можете примонтировать его к этому каталогу или создать символическую ссылку. Например, если
/
srv является большой смонтированной файловой системой, создайте два каталога и символьные ссылки на них:
sudo mkdir /srv/lxclib /srv/lxccache sudo rm -rf /var/lib/lxc /var/cache/lxc sudo ln -s /srv/lxclib /var/lib/lxc sudo ln -s /srv/lxccache /var/cache/lxc
или, используя монтирование:

Виртуализация
398
sudo mkdir /srv/lxclib /srv/lxccache sudo sed -i '$a \ /srv/lxclib /var/lib/lxc none defaults,bind 0 0 \ /srv/lxccache /var/cache/lxc none defaults,bind 0 0' /etc/fstab sudo mount -a
5.2.4. Контейнеры с поддержкой lvm
Существует возможность использовать разделы LVM в качестве хранилища для контейнеров. Преимуществом этого является, кроме прочего, гибкость в управлении хранилищем и быстрое клонирование контейнеров. По умолчанию используется VG (группа томов) с именем lxc, но могут применяться и другие VG при использовании параметров командной строки. Когда LV (логический том) используется для хранения контейнеров,
конфигурационный файл контейнера все еще
/var/lib/lxc/CN/config
, но корневая точка входа в этом файле (lxc.rootfs) будет указывать на имя блочного устройства логического тома, т.е.
/dev/lxc/CN
Контейнеры с деревом каталогов и LVM хранилищем могут сосуществовать вместе.
5.2.5. Btrfs
Если основная система имеет
/var размеченный как btrfs, средства администрирования LXC распознают это и автоматически будут использовать для клонирования контейнеров снимки btrfs.
5.2.6. Apparmor
LXC поставляется с профилем Apparmor, предназначенным для защиты основной системы от случайного неправильного использования привилегий внутри контейнера. Например, контейнер не должен иметь возможности писать в каталог
/proc/sysrq-trigger или менять большинство файлов в каталоге
/sys
Профиль usr.bin.lxc-start используется при запуске lxc-start. Этот профиль в основном предотвращает монтирование lxc-start новых файловых систем вне корневой файловой системы контейнера. Перед инициализацией init
контейнера, LXC запрашивает переключение на профиль контейнера. По умолчанию используется профиль lxc-container-default определенный в
/
etc/apparmor.d/lxc/lxc-default
. Этот профиль запрещает контейнеру доступ к многим опасным каталогам и монтирование большинства файловых систем.
Если вы обнаружили, что lxc-start падает из-за попытки легитимного доступа, перекрытого политикой Apparmor, вы можете отключить профиль lxc-start следующим образом:
sudo apparmor_parser -R /etc/apparmor.d/usr.bin.lxc-start

Виртуализация
399
sudo ln -s /etc/apparmor.d/usr.bin.lxc-start /etc/apparmor.d/disabled/
Это позволит запускать lxc-start без ограничений, но продолжит ограничивать собственно контейнер. Если вы хотите также снять ограничения с контейнера, в дополнение к блокировке использования профиля usr.bin.lxc-start
, вам потребуется в файл настроек контейнера добавить:
lxc.aa_profile = unconfined
Если вы желаете запускать контейнер в собственном профиле, вы можете создать новый профиль в
/etc/apparmor.d/lxc/
. Его имя должно начинаться на lxc- чтобы lxc-start имел возможность переключения на этот профиль.
После создания политики, загрузите её, используя команду:
sudo apparmor_parser -r /etc/apparmor.d/lxc-containers
Профиль автоматически загрузится после перезагрузки системы, поскольку его содержимое учтено в
/etc/apparmor.d/lxc-containers
. Наконец, чтобы заставить контейнер
CN
использовать новый профиль lxc-CN-profile
,
добавьте следующие строки в его файл настройки:
lxc.aa_profile = lxc-CN-profile
lxc-execute не просматривает профиль Apparmor, но контейнер, который он порождает, будет ограничен.
5.2.7. Группы управления
Группы управления (cgroups) — это способность ядра предоставлять возможность иерархической группировки задач, а также назначать и ограничивать ресурсы для каждой cgroup. Они используются в контейнерах для ограничения доступа к блочным и посимвольным устройствам (block and character device) и для заморозки (приостановки) контейнеров. В
дальнейшем их можно использовать для ограничения используемой памяти и блочного ввода/вывода, гарантированного минимума использования CPU
и для фиксирования определенных CPU за отдельными контейнерами. По умолчанию LXC устанавливает зависимость на установку пакета cgroup- lite, который предоставляет надлежащую инициализацию cgroup при загрузке системы. Пакет cgroup-lite монтирует каждую cgroup подсистему отдельно в
/sys/fs/cgroup/SS
, где SS — название подсистемы. Например,
подсистема freezer монтируется в
/sys/fs/cgroup/freezer
. Группы управления
LXC хранятся в
/sys/fs/cgroup/SS/INIT/lxc
,где INIT — инициализирующая

Виртуализация
400
группа управления задачи. По умолчанию это
/
, поэтому группа управления freezer для контейнера CN будет
/sys/fs/cgroup/freezer/lxc/CN
5.2.8. Привилегии
Утилиты администрирования контейнерами должны запускаться с привилегиями суперпользователя. Утилита с названием lxc-setup была написана с намерением предоставлять инструменты с требуемыми правами доступа к файлам, позволяя обычным пользователям запускать эти инструменты с достаточными привилегиями. Однако, поскольку суперпользователь не может пока быть надежно погружен в контейнер,
эта особенность бесполезна. Поэтому рекомендуется не использовать lxc- setup и предоставлять администраторам LXC требуемые привилегии lxc- setup
, и предоставлять администраторам LXC требуемые привилегии
Пространство имен пользователя, которое предположительно будет доступно к следующему LTS-выпуску, будет позволять ограничивать
(сдерживать) суперпользователя контейнера, также как будут уменьшены привилегии, необходимые для создания и администрирования контейнеров.
5.2.9. Отслеживающие задания LXC
Как отмечалось выше, пакет lxc включает два отслеживающих задания.
Первое, lxc-net
, стартует всегда, когда другое, lxc
, собирается стартовать и останавливается, когда то останавливается. Если переменная
USE_LXC_BRIDGE установлена в
/etc/defaults/lxc
, то оно завершится немедленно. Если переменная, и возникает ошибка организации LXC
моста, то задание lxc не стартует. lxc-net отключает LXC мост, когда останавливается, хотя использующий его контейнер работает.
Задание lxc запускается на 2-5 уровне выполнения. Если переменная
LXC_AUTO установлена в true, оно ищет в
/etc/lxc контейнеры, которые должны запускаться автоматически. Когда задание lxc останавливается,
вручную или при установке уровня выполнения 0, 1 или 6, оно останавливает эти контейнеры.
Для регистрации автоматического запуска контейнера создайте символическую ссылку
/etc/default/lxc/name.conf
, указывающую на конфигурационный файл контейнера. Например, конфигурационный файл для контейнера
CN

/var/lib/lxc/CN/config
. Чтобы автоматически запускать этот контейнер, используйте команду:
sudo ln -s /var/lib/lxc/CN/config /etc/lxc/auto/CN.conf

Виртуализация
401 5.3. Администрирование контейнеров
5.3.1. Создание контейнеров
Самый простой способ создать контейнер — использовать lxc-create. Этот сценарий использует специфические для дистрибутива шаблоны в
/usr/lib/
lxc/templates/
для установки дружественных контейнеру настроек chroots в
/
var/lib/lxc/CN/rootfs
, и инициализации конфигурации в
/var/lib/lxc/CN/fstab и
/var/lib/lxc/CN/config
, где CN — название контейнера.
Команда на создание простейшего контейнера будет выглядеть следующим образом:
sudo lxc-create -t ubuntu -n CN
Она указывает lxc-create использовать шаблон ubuntu (-t ubuntu) и вызывать контейнер CN (-n CN). Поскольку не указан файл настроек (что можно сделать с помощью параметра `-f file'), будет использован файл настроек по умолчанию
/etc/lxc/lxc.conf
. Это предоставит контейнеру единственный сетевой интерфейс veth, подключенный к мосту lxcbr0.
Шаблоны создания контейнеров также могут воспринимать аргументы. Они могут быть перечислены после --. Например:
sudo lxc-create -t ubuntu -n oneiric1 -- -r oneiric
передаёт параметры '-r oneiric1' шаблону ubuntu.
5.3.1.1. Справка
Справку по команде lxc-create можно увидеть, используя lxc-create -h.
Однако шаблоны также принимают свои собственные параметры. Если вы выполните
sudo lxc-create -t ubuntu -h
то после общего экрана помощи lxc-create будет следовать вывод помощи,
касающийся шаблона ubuntu. Если не указывать шаблон, то будет показана помощь только по lxc-create.
5.3.1.2. Шаблон ubuntu
Шаблон ubuntu может использоваться для создания контейнеров системы
Ubuntu любого выпуска, начиная с 10.04 LTS. Он использует debootstrap для создания кэшированной файловой системы контейнера, с которой будет создаваться копия при каждом создании контейнера. Кэшированный

Виртуализация
402
образ сохраняется и пересоздаётся только в том случае, если вы создаёте контейнер с использованием передаваемой шаблону опции -F (flush), то есть:
sudo lxc-create -t ubuntu -n CN -- -F
Версия Ubuntu, установленная в контейнер, будет той же самой, что и на основной системе, если не указать опцию -r, то есть:
sudo lxc-create -t ubuntu -n CN -- -r lucid
Если вы хотите создать 32-битный контейнер на 64-битной системе,
передайте в контейнер параметр -a i386. Если у вас установлен пакет qemu-user-static, то вы можете создать контейнер, используя любую архитектуру, поддерживаемую qemu-user-static.
В контейнере будет присутствовать пользователь ubuntu с паролемubuntu,
входящий в группу sudo. Если вы хотите хотите добавить открытый ключ для пользователя ubuntu, вы можете это сделать параметром -S sshkey.pub.
Вы можете связать bind пользователя основной системы (например) с контейнером, используя опцию -b jdoe. Это позволит скопировать пароль и shadow записи пользователя jdoe в контейнер, удостоверится, что его группа по умолчанию и оболочка доступны, добавит его в группу sudo и смонтирует связыванием (bind-mount) его домашний каталог в контейнер при запуске контейнера.
После создания контейнера архив release-updates добавляется в файл sources.list контейнера, и архив его пакетов будет обновлён. Если операционная система в контейнере имеет версию старее 12.04 LTS,
то будет автоматически установлен пакет lxcguest. Но если указана опция --trim, то пакет lxcguest не будет установлен и многие сервисы будут удалены из контейнера. Результатом будет более быстрый запуск контейнера, но, в то же время, ухудшение возможностей его обновления.
5.3.1.3. Шаблон ubuntu-cloud
Шаблон ubuntu-cloud создаёт контейнеры Ubuntu, загружая и извлекая опубликованные образы для облака Ubuntu. Он воспринимает некоторые из опций шаблона ubuntu, а именно -r release, -S sshkey.pub, -a arch,
и -F для сброса кешированных образов. Он воспринимает также некоторые дополнительные опции. Опция -C создаёт cloud контейнер,
настроенный на использование с сервисом metedata. Опция -u позволяет инициализирующему облачному файлу с пользовательскими данными настраивать контейнер при старте. Если передается -L, то не будет

Виртуализация
403
установлено никаких национальных настроек. Опция -T может быть использована для выбора размещения извлекаемой свёртки (tarball) вместо использования опубликованной свёртки облачного образа. Наконец,
опция -i устанавливает id системы для cloud-init, который по умолчанию приравнивается к случайной строке.
5.3.1.4. Другие шаблоны
Шаблоны ubuntu и ubuntu-cloud хорошо поддерживаются. Однако доступны и другие шаблоны. Шаблон debian создаёт контейнер на основе Debian,
используя debootstrap почти также, как это делает шаблон ubuntu. По умолчанию он устанавливает образ debian squeeze. Другие версии могут быть выбраны установкой переменной окружения SUITE:
sudo SUITE=sid lxc-create -t debian -n d1
Поскольку debian не может быть безопасно загружен внутри контейнера,
контейнеры debian будут урезаны как при использовании опции --trim для шаблона ubuntu.
Для очистки кэша образа контейнера вызывайте шаблон напрямую и передавайте ему опцию --clean:
sudo SUITE=sid /usr/lib/lxc/templates/lxc-debian --clean
Существует шаблон fedora, создающий контейнеры на базе версий fedora не выше 14. Выпуски fedora, начиная с 15, основаны на systemd,
который шаблоны пока не могут преобразовать в установку, загружаемую в контейнере. Перед тем как запускать шаблон fedora, вам следует убедиться, что установлены yum и curl. Контейнер с fedora 12 может быть установлен следующим образом:
sudo lxc-create -t fedora -n fedora12 -- -R 12
Существует шаблон OpenSuSE, но он требует программу zypper
которая пока не имеет пакета. Таким образом, шаблон OpenSuSE не поддерживаются.
Ещё два шаблона созданы в основном для экспериментальных целей.
Шаблон busybox создает очень маленький системный контейнер,
основанный целиком на busybox. Шаблон sshd создает контейнер приложений, запускающий sshd в области имен частной сети. Каталоги библиотек и двоичных файлов монтируются связыванием внутрь контейнера, хотя не
/home или
/root
. Для создания, запуска и соединения по ssh с контейнером, вы можете использовать следующее:

Виртуализация
404
sudo lxc-create -t sshd -n ssh1 ssh-keygen -f id sudo mkdir /var/lib/lxc/ssh1/rootfs/root/.ssh sudo cp id.pub /var/lib/lxc/ssh1/rootfs/root/.ssh/authorized_keys sudo lxc-start -n ssh1 -d ssh -i id root@ssh1.
5.3.1.5. Резервные хранилища
По умолчанию, lxc-create помещает корневую файловую систему контейнера в каталог
/var/lib/lxc/CN/rootfs.
Другим вариантом является использование логических томов LVM.Если существует группа томов lxc
вы можете создать контейнер на основе lvm с названием CN, используя команду:
sudo lxc-create -t ubuntu -n CN -B lvm
Если вы хотите использовать группу томов с именем schroots с файловой системой xfs на 5 Гб, вы можете использовать:
sudo lxc-create -t ubuntu -n CN -B lvm --vgname schroots --fssize 5G --fstype xfs
5.3.2. Клонирование
Для быстрой подготовки к работе вы можете решить изменить canonical контейнер в соответствии с вашими требованиями и затем сделать множество его копий. Это можно осуществить с помощью программы lxc-
clone. Дан существующий контейнер с именем C1, новый контейнер C2
может быть создан:
sudo lxc-clone -o C1 -n C2
Если файловой системой
/var/lib/lxc является btrfs, то lxc-clone создаст файловую систему C2 как снимок от C1. Если корневая файловая система контейнера поддерживается lvm, то вы можете указать опцию -s для создания новой rootfs как снимок lvm оригинала следующим образом:
sudo lxc-clone -s -o C1 -n C2
И lvm и btrfs снимки обеспечивают быстрое клонирование с очень небольшим изначально использованием дискового пространства.
5.3.3. Запуск и остановка
Чтобы запустить контейнер, используйте lxc-start -n CN. По умолчанию
lxc-start выполнит
/sbin/init внутри контейнера. Вы можете предоставить другую программу для выполнения плюс аргументы, как дополнительные аргументы для lxc-start:

Виртуализация
405
sudo lxc-start -n container /sbin/init loglevel=debug
Если вы не укажете опцию -d (daemon — сервис), то вы увидите консоль
(по поводу контейнерной
/dev/console
, смотрите секцию Раздел 5.3.5,
«Консоли» [407] для получения дополнительной информации) в терминале. Если вы укажете опцию -d, то эту консоль вы не увидите, а lxc- start завершится без ошибок немедленно, даже если дальнейшая часть запуска контейнера завершится неудачей. Вы можете использовать lxc-
wait или lxc-monitor (смотрите Раздел 5.3.4, «Отслеживание статуса
контейнеров» [406]) для проверки, удачно или нет запустился контейнер.
Для получения отладочной информации LXC используйте -o filename -l
debuglevel, например:
sudo lxc-start -o lxc.debug -l DEBUG -n container
Наконец, вы можете указать параметры настройки, используя опцию -
s. Однако в общем случае рекомендуется вместо этого указывать их в конфигурационном файле контейнера. Аналогичным образом можно указать целиком иной файл настроек с помощью опции -f но это тоже в общем случае не рекомендуется.
В то время как lxc-start запускает в контейнерный
/sbin/init
, lxc-
execute использует программу минимальной инициализации lxc-init,
которая пытается монтировать
/proc
,
/dev/mqueue
, и
/dev/shm
, выполняет программы, указанные в командной строке, и ждёт их завершения. lxc-
start предназначена для использования system containers, в то время как
lxc-execute для использования application containers (смотрите this article
38
для дополнительной информации).
Остановить контейнер вы можете разными способами. Вы можете использовать shutdown, poweroff и reboot когда подсоединились к контейнеру. Для чистого завершения работы контейнера извне (т.е. из основной системы), вы можете выполнить команду sudo lxc-shutdown
-n CN. Она воспринимает необязательный параметр задержки. Если он не указан, команда посылает сигнал SIGPWR в контейнер и немедленно завершается. Если опция указана, как, например, sudo lxc-shutdown -n
CN -t 10, то команда ожидает указанное количество секунд завершения работы контейнера. Затем, если контейнер всё ещё работает, она убивает
(kill) его, а также все работающие в нем приложения. Вы можете также немедленно убить контейнер (не оставляя шансов для приложений завершиться аккуратно), используя команду sudo lxc-stop -n CN. Наконец,
38
https://www.ibm.com/developerworks/linux/library/l-lxc-containers/

Виртуализация
406
lxc-kill может быть использована в общем случае для отправки любого сигнала процедуре инициализации контейнера.
В процессе завершения работы контейнера вы можете получить несколько
(безопасных) сообщений об ошибке, как например:
$ sudo poweroff
[sudo] password for ubuntu: =
$ =
Broadcast message from ubuntu@cn1
(/dev/lxc/console) at 18:17 ...
The system is going down for power off NOW!
* Asking all remaining processes to terminate...
...done.
* All processes ended within 1 seconds....
...done.
* Deconfiguring network interfaces...
...done.
* Deactivating swap...
...fail!
umount: /run/lock: not mounted umount: /dev/shm: not mounted mount: / is busy
* Will now halt
Кроме того, контейнер может быть "заморожен" командой sudo lxc-freeze
-n CN. Это заблокирует все его процессы до тех пор, пока он не будет "разморожен" командой sudo lxc-unfreeze -n CN.
5.3.4. Отслеживание статуса контейнеров
Две команды доступны для отслеживания изменения статуса контейнера.
lxc-monitor отслеживает один или более контейнеров на любые изменения статусов. Она как правило получает имя контейнера с помощью опции -n,
однако в этом случае имя контейнера может быть регулярным выражением posix, чтобы позволять отслеживать желаемые наборы контейнеров. lxc-
monitor продолжает выполнение пока выводит статусы контейнеров.
Вторая команда lxc-wait ожидает специфического изменения статуса контейнера и затем завершается. Например,
sudo lxc-monitor -n cont[0-5]*
будет выводить все изменения статусов контейнеров с именами,
попадающими под приведенное регулярное выражение, в то время как

Виртуализация
407
sudo lxc-wait -n cont1 -s 'STOPPED|FROZEN'
будет ожидать, пока контейнер cont1 не войдет в состояния STOPPED или
FROZEN и затем завершится.
5.3.5. Консоли
Контейнеры имеют настраиваемое количество консолей. Одна всегда существует в контейнерном
/dev/console.
Она видна в терминале, из которого вы запустили lxc-start, если не указана опция -d. Вывод в
/dev/
console может быть перенаправлен в файл при использовании опции -c
console-file с lxc-start. Количество дополнительных консолей указывается переменной lxc.tty, и обычно равно 4. Эти консоли видны как
/dev/ttyN
(for 1 <= N <= 4). Для соединения с консолью 3 из основной системы используйте
sudo lxc-console -n container -t 3
в противном случае, если -t N не указано, будет автоматически выбрана неиспользуемая консоль. Для входа из консоли используйте последовательность Ctrl-a q. Обратите внимание, что последовательность не сработает в консоли при использовании lxc-start без опции -d.
Каждая консоль контейнера фактически является Unix98 pty смонтированной в pty основной (не гостевой) системы через связанное монтирование гостевых
/dev/ttyN
и
/dev/console
. Следовательно, если гостевая система размонтирует их или с другой стороны попытается получить доступ к символьному устройству 4:N, она не будет обслужена getty на LXC консолях. (При настройках по умолчанию контейнер не сможет получить доступ к этому символьному устройству и getty, соответственно,
завершится с ошибкой). Это может легко случиться, когда загрузочный сценарий вслепую монтирует новые устройства в
/dev
5.3.6. Исследование контейнеров
Некоторые команды способны собирать информацию по созданным контейнерам. lxc-ls выведет все существующие контейнеры в своей первой строке вывода и все запущенные контейнеры во второй. lxc-list
предоставит ту же информацию в более развернутом формате, перечислив запущенные контейнеры сначала и остановленные в конце. lxc-ps
предоставит список процессов в контейнере. Для передачи ps аргументов в
lxc-ps, предварите их --. Например, для получения списка всех процессов в контейнере
sudo lxc-ps -n plain -- -ef

Виртуализация
408
lxc-info возвращает статус контейнера и pid его инициирующего процесса.
lxc-cgroup может быть использована для получения и установки переменных ограничений и информации управляющих групп контейнера.
Это может оказаться более удобным, чем взаимодействие с файловой системой cgroup. Например, для получения списка устройств, к которым контейнер имеет доступ, вы можете использовать:
sudo lxc-cgroup -n CN devices.list
или для добавления прав доступа mknod, read и write к
/dev/sda
,
sudo lxc-cgroup -n CN devices.allow "b 8:* rwm"
и для ограничения памяти до 300M:
lxc-cgroup -n CN memory.limit_in_bytes 300000000
lxc-netstat выполняет netstat в запущенном контейнере, давая вам представление о статусе его сети.
lxc-backup создаст резервные копии корневой файловой системы всех существующих контейнеров (за исключением основанных на lvm-based ), используя rsync для сохранения содержимого в
/var/lib/
lxc/CN/rootfs.backup.1
. Эти резервные копии могут использоваться для восстановления с помощью lxc-restore Однако, lxc-backup и lxc-
restore неустойчивы благодаря модификациям и, соответственно, не рекомендуются к использованию.
5.3.7. Уничтожение контейнеров
Используйте lxc-destroy для уничтожения контейнера.
sudo lxc-destroy -n CN
Если контейнер запущен, lxc-destroy завершится с сообщением о возможности остановить и уничтожить контейнер с помощью команды
sudo lxc-destroy -n CN -f
5.3.8. Использование расширенного пространства имен
Одной из особенностей ядра Linux, используемой в LXC для создания контейнеров, являются частные пространства имён. Пространства имён позволяют ряду задач иметь частные отображения имен ресурсов для таких вещей как пути и ID процессов. (Смотрите Раздел 5.9,
«Ресурсы» [418] для дополнительной информации). В отличие от

Виртуализация
409
групп управления и других особенностей монтирования, которые также используются при создании контейнеров, пространствами имён невозможно манипулировать при помощи интерфейса файловой системы.
Поэтому LXC поставляется с программой lxc-unshare которая большей частью используется для тестирования. Она предоставляет возможность создавать новую задачу в частном пространстве имён. Например,
sudo lxc-unshare -s 'MOUNT|PID' /bin/bash
создаст оболочку shell с частными pid и пространством имён монтирования.
В этой оболочке вы можете выполнить root@ubuntu:
# mount -t proc proc /proc root@ubuntu:
# ps -ef
UID PID PPID C STIME TTY TIME CMD
root 1 0 6 10:20 pts/9 00:00:00 /bin/bash root 110 1 0 10:20 pts/9 00:00:00 ps -ef притом, что ps покажет только задачи в вашем новом пространстве имён.
5.3.9. Недолговечные контейнеры
Недолговечные (эфемерные — ephemeral) контейнеры — это одноразовые контейнеры. Имея созданный контейнер CN, вы можете выполнить команду в недолговечном контейнере, созданном на основе CN, подсоединив пользователя jdoe в контейнер, используя команду:
lxc-start-ephemeral -b jdoe -o CN -- /home/jdoe/run_my_job
После завершения задания, контейнер будет сброшен.
5.3.10. Команды для работы с контейнерами
Далее приведена таблица всех контейнерных команд:
Таблица 20.3. Команды для работы с контейнером
Команда
Описание
lxc-attach
(НЕ ПОДДЕРЖИВАЕТСЯ) Выполняет команду в запущенном контейнере lxc-backup
Создаёт резервную копию корневой системы для всех контейнеров, основанных на lvm lxc-cgroup
Просмотр и установка параметров групп управления lxc-checkconfig
Проверка основной системы на поддержку контейнеров

Виртуализация
410
Команда
Описание
lxc-checkpoint
(НЕ ПОДДЕРЖИВАЕТСЯ) Контрольная точка для запущенного контейнера lxc-clone
Создание копии существующего контейнера lxc-console
Открытие консоли работающего контейнера lxc-create
Создание нового контейнера lxc-destroy
Уничтожение существующего контейнера lxc-execute
Запуск команды в (незапущенном) контейнере приложений lxc-freeze
Приостановка работающего контейнера lxc-info
Вывод информации о состоянии контейнера lxc-kill
Передача сигнала в инициализирующий процесс контейнера lxc-list
Получение списка всех контейнеров lxc-ls
Получение списка всех контейнеров с меньшим выводом, чем у lxc-list lxc-monitor
Отслеживание изменения состояния одного или нескольких контейнеров lxc-netstat
Выполнение команды netstat в запущенном контейнере lxc-ps
Просмотр информации по процессам в работающем контейнере lxc-restart
(НЕ ПОДДЕРЖИВАЕТСЯ) Сброс контейнера,
остановленного в контрольной точке lxc-restore
Восстановление контейнеров из резервных копий,
сделанных lxc-backup lxc-setcap
(НЕ РЕКОМЕНДУЕТСЯ) Установка характеристик файлов (file capabilities) на инструменты LXC
lxc-setuid
(НЕ РЕКОМЕНДУЕТСЯ) Установка или сброс setuid битов для инструментов LXC
lxc-shutdown
Безопасное завершение работы контейнера lxc-start
Запуск остановленного контейнера lxc-start-ephemeral
Запуск недолговечного (одноразового) контейнера lxc-stop
Немедленная остановка работающего контейнера

Виртуализация
411
Команда
Описание
lxc-unfreeze
Восстановление работы приостановленного контейнера lxc-unshare
Инструмент тестирования вручную объединенных пространств имён lxc-version
Вывод версии инструментов LXC
lxc-wait
Ожидание перехода контейнера в определенное состояние
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 записями в файле настроек. Если таких записей

Виртуализация
412
нет, то контейнер будет разделять сетевой стек основной системы.
Сервисы и соединения, запущенные в контейнере, будут использовать
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. Это возможно проще реализовать, чем просто записать значение в файл группы

Виртуализация
413
управления контейнера для подсистемы. Например, чтобы установить ограничение для памяти в 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,noexec,nosuid 0 0 lxc.mount = /var/lib/lxc/CN/fstab
Первая строка говорит, что корневая файловая система контейнера уже смонтирована в
/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 для перечня возможностей и их толкований.

Виртуализация
414
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
и впоследствии символически связывают их

Виртуализация
415
с
/dev/console и
/dev/ttyN
. Это позволит обновлениям пакетов удачно устанавливаться, из-за риска последующего получения сбоя при выполнении gettys на этих консолях до следующей перезагрузки. Эта проблема идеально решается с помощью пространств имён устройств.
5.5. Обновления в контейнерах Ubuntu
Из-за некоторых ограничений, присутствующих в контейнерах, обновления пакетов временами могут завершаться с ошибкой. Например, установка или обновление пакета может закончиться неудачей, если не позволено создавать или открывать блочные устройства. Это часто блокирует все дальнейшие обновления, пока не разрешится данная проблема. В
некоторых случаях вы можете обойти проблему, используя chroot внутри контейнера, чтобы обойти ограничения и завершить обновления внутри chroot.
Некоторые известные специфические вещи, которые могут время от времени препятствовать обновлению пакетов, включают:
• Изменения в контейнере, выполненные при создании контейнера с помощью опции --trim.
• Действия, выполненные lxcguest. Например, если
/lib/init/fstab смонтирован связыванием с другим файлом, обновления mountall,
которые настаивают на замене этого файла, могут завершиться неудачей.
• Перемонтированные консольные устройства с pty из основной системы могут иметь проблемы с обновлениями udev.
• Политики Apparmor и ограничения cgroup для устройств могут мешать обновлениям при выполнении определенных действий.
• Разрешения, сброшенные с помощью lxc.cap.drop, могут аналогично остановить обновления пакетов при выполнении определенных действий.
5.6. Libvirt LXC
Libvirt является мощным решением по управлению гипервизорами
(программами управления операционными системами), с помощью которой можно администрировать виртуальные машины под Qemu, Xen и LXC, как локально так и удаленно. Драйвер libvirt LXC — это отдельная реализация того, что мы обычно называем LXC. Вот некоторые отличия:
• Конфигурация сохраняется в формате XML
• Нет инструментов, облегчающих создание контейнера
• По умолчанию отсутствует консоль
/dev/console

Виртуализация
416
• Не поддерживается (пока) перезагрузка или полная остановка контейнеров
5.6.1. Преобразование контейнера LXC в libvirt-lxc
В разделе Раздел 5.3.1, «Создание контейнеров» [401] показано, как создавать LXC контейнеры. Если вы создали рабочий LXC контейнер таким способом, то вы можете управлять им при помощи libvirt. Загрузите xml файл в качестве примера:
wget http://people.canonical.com/
serge/o1.xml

Отредактируйте этот файл, заменив название контейнера и расположение корневой файловой системы. Затем вы можете зарегистрировать контейнер командой:
virsh -c lxc:/// define o1.xml
5.6.2. Создание контейнера из облачного образа
Если вы предпочитаете создавать новые оригинальные контейнеры только под LXC, вы можете загрузить образ для облака ubuntu, извлечь его и указать его расположение в xml файле libvirt LXC. Например, найдем адрес образа последней ежедневной корневой сборки Ubuntu 12.04 LTS
следующим образом:
url1=`ubuntu-cloudimg-query precise daily $arch --format "%{url}\n"` url=`echo $url1 | sed -e 's/.tar.gz/-root\0/'` wget $url filename=`basename $url`
Распакуйте загруженный образ, например, так:
mkdir $HOME/c1 cd $HOME/c1 sudo tar zxf $filename
Загрузите шаблон xml:
wget http://people.canonical.com/
serge/o1.xml

В шаблоне замените o1 на c1 и каталог расположения
/var/lib/lxc/o1/rootfs на
$HOME/c1
. Затем зарегистрируйте контейнер с помощью:
virsh define o1.xml
5.6.3. Взаимодействие с контейнерами libvirt
Как мы видели, вы можете создавать libvirt-lxc контейнеры с помощью:

Виртуализация
417
virsh -c lxc:/// define container.xml
Для запуска контейнера с именем container используйте:
virsh -c lxc:/// start container
Для остановки запущенного контейнера:
virsh -c lxc:/// destroy container
Обратите внимание, что хотя команда lxc-destroy уничтожает контейнер,
команда virsh destroy только останавливает работающий контейнер. Для удаления регистрации контейнера используйте:
virsh -c lxc:/// undefine container
Для получения консоли работающего контейнера используйте:
virsh -c lxc:/// console container
Для выхода из консоли нажмите комбинацию Ctrl-].
5.7. Пакет lxcguest
В выпусках Ubuntu 11.04 (Natty) и 11.10 (Oneiric) был представлен пакет
lxcguest. Немодифицированный коревой образ не может быть безопасно загружен внутри контейнера, однако образ с установленным пакетом lxcguest может быть загружен как контейнер на голом железе или под виртуальной машиной Xen, kvm или VMware.
Что касается выпуска 12.04 LTS, функции, выполнявшиеся ранее пакетом lxcguest, были возложены на пакеты ядра, а пакет lxcguest был удалён.
Как результат, оригинальный образ 12.04 LTS без изменений может быть загружен в качестве контейнера как на голом железе, так и под виртуальными машинами Xen, kvm или VMware. Использование более ранних выпусков всё ещё требует использования пакета lxcguest .
5.8. Защита
Пространство имен сопоставляет идентификаторы с ресурсами. Чтобы не предоставлять доступ контейнерам к любым идентификаторам (id),
указывающим на ресурсы, ресурсы должны быть защищены. Это является основой некоторой безопасности, предоставляемой пользователям контейнеров. Например, пространство имён IPC (взаимодействия между процессами) полностью изолировано. Однако другие пространства имён

Виртуализация
418
имеют различные уязвимости, которые позволяют получать неправильно предоставленные привилегии из одного контейнера в другой или в основную систему.
По умолчанию LXC контейнеры запускаются под управлением политики
Apparmor для ограничения некоторых действий. Несмотря на то, что более строгая безопасность является задачей следующих редакций, в 12.04 LTS
задачей политики Apparmor является не прекращение злонамеренных действий, а предупреждения случайных повреждений основной системы из гостевой.
Смотрите LXC security wiki
39
для дополнительной актуальной информации.
5.8.1. Используемые системные вызовы
Возможность совместного использования ядра системы контейнерами является базовой особенностью. Поэтому, если ядро содержит некоторые потенциально опасные вызовы, контейнеры также могут их использовать.
Как только контейнер сможет контролировать ядро системы, он сможет полностью управлять любыми ресурсами, доступными основной системе.
5.9. Ресурсы
• Статья в DeveloperWorks LXC: Linux container tools
40
является введением в использование контейнеров.
Secure Containers Cookbook
41
демонстрирует использование модулей безопасности с целью сделать контейнеры более безопасными.
• Страницы руководств могут быть найдены по данным ссылкам:
capabilities
4342
lxc.conf
45
.
44
• Страница проекта LXC на Sourceforge
46
• Проблемы безопасности приведены и обсуждаются на странице the LXC
Security wiki page
47
• Для дополнительной информации по пространствам имен в Linux смотрите: S.Bhattiprolu, E.W.Biederman, S.E.Hallyn, and D.Lezcano. Virtual
39
http://wiki.ubuntu.com/LxcSecurity
40
https://www.ibm.com/developerworks/linux/library/l-lxc-containers/
41
http://www.ibm.com/developerworks/linux/library/l-lxc-security/index.html
43
http://manpages.ubuntu.com/manpages/en/man7/capabilities.7.html
42
http://manpages.ubuntu.com/manpages/en/man7/capabilities.7.html
45
http://manpages.ubuntu.com/manpages/en/man5/lxc.conf.5.html
44
http://manpages.ubuntu.com/manpages/en/man5/lxc.conf.5.html
46
http://lxc.sf.net
47
http://wiki.ubuntu.com/LxcSecurity

Виртуализация
419
Servers and Checkpoint/Restart in Mainstream Linux. SIGOPS Operating
Systems Review, 42(5), 2008.
1   ...   8   9   10   11   12   13   14   15   16


База данных защищена авторским правом ©nethash.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал