Различия

Здесь показаны различия между двумя версиями данной страницы.

--- wiki:руководство_по_ubuntu_server:виртуализация:lxc [2012/10/21 19:33]
[Файл настройки]
+++ wiki:руководство_по_ubuntu_server:виртуализация:lxc [2014/05/15 13:56] (текущий)
[Настройка основной системы]
@@ Строка 54: / Строка 54: @@
 **LXC** сохраняет информацию контейнеров и корневую файловую систему (с резервным хранилищем по умолчанию) в **/var/lib/lxc**. Также шаблоны создания контейнеров предпочитают хранить закешированную информацию по дистрибутивам в **/var/cache/lxc**.
-Если вы хотите использовать для **/var** иную файловую систему, вы можете смонтировать в этот каталог другую файловую систему большего объема. Если у вас есть диск, предназначенный для этих целей, вы можете просто смонтировать его в **/var/lib/lxc**. Если вы предпочитаете использовать другое расположение, такое как /srv, вы можете примонтировать его к этому каталогу или создать символическую ссылку. Например, если /srv является большой смонтированной файловой системой, создайте два каталога и символьные ссылки на них:
+Дефолтный путь, называемый **lxcpath**, может быть переопределён в командной строке ключом **-P** или навсегда через **lxcpath = /новый/путь** в **/etc/lxc/lxc.conf**
+Если вы переопределяете **lxcpath**, то каталог снимков **snap** добавляется к **lxcpath** и магическим образом за ним следует. Кэш шаблонов, к сожалению, жёстко вшит и не просто его сменить.
+Но можно всё сделать через символические ссылки. Например, если /srv является большой смонтированной файловой системой, создайте каталог и символьную ссылку на него:
 <code>
-sudo mkdir /srv/lxclib /srv/lxccache
+sudo mkdir /srv/lxccache
-sudo rm -rf /var/lib/lxc /var/cache/lxc
+sudo rm -rf /var/cache/lxc
-sudo ln -s /srv/lxclib /var/lib/lxc
 sudo ln -s /srv/lxccache /var/cache/lxc
 </code>
 или, используя монтирование:
 <code>
-sudo mkdir /srv/lxclib /srv/lxccache
+sudo mkdir /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
@@ Строка 79: / Строка 79: @@
 Если основная система имеет **/var**, размеченный как **btrfs**, средства администрирования LXC распознают это и автоматически будут использовать для клонирования контейнеров снимки btrfs.
+===ZFS===
+Подобно **btrfs**, использование **zfs** позволит применять возможности, но уже **ZFS**: подтом (subvolume) для контейнера, быстрое создание снимков и клонов, более эффективное использование места на диске за счёт дедупликации.
 ===Apparmor===
-LXC поставляется с профилем Apparmor, предназначенным для защиты основной системы от случайного неправильного использования привилегий внутри контейнера. Нпример, контейнер не должен иметь возможности писать в каталог /proc/sysrq-trigger или менять большинство файлов в каталоге /sys.
+LXC поставляется с профилем Apparmor, предназначенным для защиты основной системы от случайного неправильного использования привилегий внутри контейнера. Например, контейнер не должен иметь возможности писать в каталог /proc/sysrq-trigger или менять большинство файлов в каталоге /sys.
 Профиль **usr.bin.lxc-start** используется при запуске **lxc-start**. Этот профиль в основном предотвращает монтирование **lxc-start** новых файловых систем вне корневой файловой системы контейнера. Перед инициализацией контейнера LXC запрашивает переключение на профиль контейнера. По умолчанию используется профиль **lxc-container-default**, определенный в **/etc/apparmor.d/lxc/lxc-default**. Этот профиль запрещает контейнеру доступ к многим опасным каталогам и монтирование большинства файловых систем.
@@ Строка 198: / Строка 201: @@
 ===Клонирование===
-Для быстрой подготовки к работе вы можете решить изменить canonical контейнер в соответствии с вашими требованиями и затем сделать множество его копий. Это можно осуществить с помощью программы lxc-clone. Дан существующий контейнер с именем C1, новый контейнер C2 мможет быть создан:
+Для быстрой подготовки к работе вы можете решить изменить canonical контейнер в соответствии с вашими требованиями и затем сделать множество его копий. Это можно осуществить с помощью программы lxc-clone. Дан существующий контейнер с именем C1, новый контейнер C2 может быть создан:
 <code>sudo lxc-clone -o C1 -n C2</code>
@@ Строка 411: / Строка 414: @@
   .. внутри контейнера. Важно понимать, что контейнер не может монтировать файловые системы **devpts** сам по себе. Он может безопасно присоединить или переместить точки монтирования своих смонтированных **/dev/pts**. Но если он выполнит
   .. <code>sudo mount -t devpts devpts /dev/pts</code>
-  .. он перемонтирует экземпляры **devpts** основной системы. Если добавлена опция монтирования newinstance, то это смонтирует новые  частные (пустые) экземпляры.
+  .. он перемонтирует экземпляры **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**. Это позволит обновлениям пакетов удачно устанавливаться, из-за риска последующего получения сбоя при выполнении gettys на этих консолях до следующей перезагрузки ( FIXME This allows the package updates to succeed, at the risk of making future gettys on those consoles fail until the next reboot). Эта проблема идеально решается с помощью пространств имен устройств.
-    it will remount the host's devpts instance. If it adds the newinstance mount option, then it will mount a new private (empty) instance. In neither case will it remount the instance which was set up by LXC. For this reason, and to prevent the container from using the host's ptys, the default Apparmor policy will not allow containers to mount devpts filesystems after the container's init has been started.
-    lxc.devttydir specifies a directory under /dev in which LXC will create its console devices. If this option is not specified, then the ptys will be bind-mounted over /dev/console and /dev/ttyN. However, rare package updates may try to blindly rm -f and then mknod those devices. They will fail (because the file has been bind-mounted), causing the package update to fail. When lxc.devttydir is set to LXC, for instance, then LXC will bind-mount the console ptys onto /dev/lxc/console and /dev/lxc/ttyN, and subsequently symbolically link them to /dev/console and /dev/ttyN. This allows the package updates to succeed, at the risk of making future gettys on those consoles fail until the next reboot. This problem will be ideally solved with device namespaces.
 ====Обновления в контейнерах Ubuntu====
-Because of some limitations which are placed on containers, package upgrades at times can fail. For instance, a package install or upgrade might fail if it is not allowed to create or open a block device. This often blocks all future upgrades until the issue is resolved. In some cases, you can work around this by chrooting into the container, to avoid the container restrictions, and completing the upgrade in the chroot.
+Из-за некоторых ограничений, присутствующих в контейнерах, обновления пакетов временами могут завершаться с ошибкой. Например, установка или обновление пакета может закончиться неудачей, если не позволено создавать или открывать блочные устройства. Это часто блокирует все дальнейшие обновления, пока не разрешится данная проблема. В некоторых случаях вы можете обойти проблему, используя **chroot** внутри контейнера, чтобы обойти ограничения и завершить обновления внутри chroot.
-Some of the specific things known to occasionally impede package upgrades include:
+Некоторые известные специфические вещи, которые могут время от времени препятствовать обновлению пакетов, включают:
-    The container modifications performed when creating containers with the --trim option.
+  -- Изменения в контейнере, выполненные при создании контейнера с помощью опции **//%%--trim%%//**.
+  -- Действия, выполненные **lxcguest**. Например, если /lib/init/fstab смонтирован связыванием с другим файлом, обновления **//mountall//**, которые настаивают на замене этого файла, могут завершиться неудачей.
-    Actions performed by lxcguest. For instance, because /lib/init/fstab is bind-mounted from another file, mountall upgrades which insist on replacing that file can fail.
+  -- Перемонтированные консольные устройства с **pty** из основной системы могут иметь проблемы с обновлениями **udev**.
+  -- Политики **Apparmor** и ограничения **cgroup** для устройств могут мешать обновлениям при выполнении определенных действий.
-    The over-mounting of console devices with ptys from the host can cause trouble with udev upgrades.
+  -- Разрешения, сброшенные с помощью **lxc.cap.drop**, могут аналогично остановить обновления пакетов при выполнении определенных действий.
-    Apparmor policy and devices cgroup restrictions can prevent package upgrades from performing certain actions.
-    Capabilities dropped by use of lxc.cap.drop can likewise stop package upgrades from performing certain actions.
 ====Libvirt LXC====
-Libvirt is a powerful hypervisor management solution with which you can administer Qemu, Xen and LXC virtual machines, both locally and remote. The libvirt LXC driver is a separate implementation from what we normally call LXC. A few differences include:
+**Libvirt** является мощным решением по управлению гипервизорами (программами управления операционными системами), с помощью которой можно администрировать виртуальные машины под **Qemu**, **Xen** и **LXC**, как локально так и удаленно. Драйвер **libvirt LXC** - это отдельная реализация того, что мы обычно называем LXC. Некоторые отличия включают:
-    Configuration is stored in xml format
+  -- Конфигурация сохраняется в XML формате
+  -- Нет инструментов, облегчающих создание контейнера
-    There no tools to facilitate container creation
+  -- По умолчанию отсутствует консоль /dev/console
+  -- Не поддерживается (пока) перезагрузка или полная остановка контейнеров
-    By default there is no console on /dev/console
-    There is no support (yet) for container reboot or full shutdown
 ===Преобразование контейнера LXC в libvirt-lxc===
-Creating Containers showed how to create LXC containers. If you've created a valid LXC container in this way, you can manage it with libvirt. Fetch a sample xml file from
+В разделе [[#создание_контейнеров|Создание контейнеров]] показано как создавать LXC контейнеры. Если вы создали рабочий LXC контейнер таким способом, то вы можете управлять им при помощи **libvirt**. Загрузите xml файл в качестве примера:
 <code>wget http://people.canonical.com/~serge/o1.xml</code>
+Отредактируйте этот файл, заменив название контейнера и расположение корневой файловой системы. Затем вы можете зарегистрировать контейнер командой:
-Edit this file to replace the container name and root filesystem locations. Then you can define the container with:
 <code>virsh -c lxc:/// define o1.xml</code>
 ===Создание контейнера из облачного образа===
-If you prefer to create a pristine new container just for LXC, you can download an ubuntu cloud image, extract it, and point a libvirt LXC xml file to it. For instance, find the url for a root tarball for the latest daily Ubuntu 12.04 LTS cloud image using
+Если вы предпочитаете создавать новые оригинальные контейнеры только под LXC, вы можете загрузить образ для облака ubuntu, извлечь его и указать его расположение в xml файле libvirt LXC. Например, найдем адрес образа последней ежедневной корневой сборки Ubuntu 12.04 LTS следующим образом:
+<code>
 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`
+</code>
-Extract the downloaded tarball, for instance
+Распакуем загруженный образ, например, так:
+<code>
 mkdir $HOME/c1
 cd $HOME/c1
 sudo tar zxf $filename
+</code>
-Download the xml template
+Загрузим шаблон xml:
 <code>wget http://people.canonical.com/~serge/o1.xml</code>
-In the xml template, replace the name o1 with c1 and the source directory /var/lib/lxc/o1/rootfs with $HOME/c1. Then define the container using
+В шаблоне заменим **o1** на **c1** и каталог расположения **/var/lib/lxc/o1/rootfs** на **$HOME/c1**. Затем зарегистрируем контейнер с помощью:
+<code>virsh define o1.xml</code>
-virsh define o1.xml
 ===Взаимодействие с контейнерами libvirt===
-As we've seen, you can create a libvirt-lxc container using
+Как мы видели, вы можете создавать libvirt-lxc контейнеры с помощью:
 <code>virsh -c lxc:/// define container.xml</code>
-To start a container called container, use
+Для запуска контейнера с именем **container** используйте:
 <code>virsh -c lxc:/// start container</code>
-To stop a running container, use
+Для остановки запущенного контейнера:
 <code>virsh -c lxc:/// destroy container</code>
-Note that whereas the lxc-destroy command deletes the container, the virsh destroy command stops a running container. To delete the container definition, use
+Обратите внимание, что хотя команда **lxc-destroy** уничтожает контейнер, команда **virsh destroy** только останавливает работающий контейнер. Для удаления регистрации контейнера используйте:
 <code>virsh -c lxc:/// undefine container</code>
-To get a console to a running container, use
+Для получения консоли работающего контейнера используйте:
 <code>virsh -c lxc:/// console container</code>
+Для выхода из консоли нажмите комбинацию **Ctrl-]**.
-Exit the console by simultaneously pressing control and ].
 ====Пакет lxcguest====
-In the 11.04 (Natty) and 11.10 (Oneiric) releases of Ubuntu, a package was introduced called lxcguest. An unmodified root image could not be safely booted inside a container, but an image with the lxcguest package installed could be booted as a container, on bare hardware, or in a Xen, kvm, or VMware virtual machine.
+В выпусках Ubuntu 11.04 (Natty) и 11.10 (Oneiric) был представлен пакет **lxcguest**. Немодифицированный коревой образ не может быть безопасно загружен внутри контейнера, однако образ с установленным пакетом **lxcguest** может быть загружен как контейнер на голом железе или под виртуальной машиной **Xen**, **kvm** или **VMware**.
-As of the 12.04 LTS release, the work previously done by the lxcguest package was pushed into the core packages, and the lxcguest package was removed. As a result, an unmodified 12.04 LTS image can be booted as a container, on bare hardware, or in a Xen, kvm, or VMware virtual machine. To use an older release, the lxcguest package should still be used.
+Что касается сборки **12.04 LTS**, функции, выполнявшиеся ранее пакетом **lxcguest**, были погружены пакеты ядра, а пакет **lxcguest** был удален. Как результат, оригинальный образ **12.04 LTS** без изменений может быть загружен в качестве контейнера как на голом железе, так и под виртуальными машинами **Xen**, **kvm** или **VMware**. Использование более ранних выпусков все еще требует использование пакета **lxcguest **.
 ====Безопасность====
-A namespace maps ids to resources. By not providing a container any id with which to reference a resource, the resource can be protected. This is the basis of some of the security afforded to container users. For instance, IPC namespaces are completely isolated. Other namespaces, however, have various leaks which allow privilege to be inappropriately exerted from a container into another container or to the host.
+Пространство имен сопоставляет идентификаторы с ресурсами. Чтобы не предоставлять доступ контейнерам к любым идентификаторам (id) , указывающим на ресурсы, ресурсы должны быть защищены. Это является основой некоторой безопасности, предоставляемой пользователям контейнеров. Например, пространство имен IPC (взаимодействия между процессами) полностью изолировано. Однако другие пространства имен имеют различные уязвимости, которые позволяют получать неправильно предоставленные привилегии из одного контейнера в другой или в основную систему.
-By default, LXC containers are started under a Apparmor policy to restrict some actions. However, while stronger security is a goal for future releases, in 12.04 LTS the goal of the Apparmor policy is not to stop malicious actions but rather to stop accidental harm of the host by the guest.
+По умолчанию LXC контейнеры запускаются под управлением политики Apparmor для ограничения некоторых действий. Несмотря на то, что более строгая безопасность является задачей следующих редакций, в 12.04 LTS задачей политики Apparmor является не прекращение злонамеренных действий, а предупреждения случайных повреждений основной системы из гостевой.
-See the LXC security wiki page for more, uptodate information.
+Смотрите [[http://wiki.ubuntu.com/LxcSecurity|LxcSecurity wiki]] страницу для дополнительной актуальной информации.
 ===Используемые системные вызовы===
-It is a core container feature that containers share a kernel with the host. Therefore, if the kernel contains any exploitable system calls, the container can exploit these as well. Once the container controls the kernel it can fully control any resource known to the host.
+Возможность совместного использования ядра системы контейнерами является базовой особенностью. Поэтому, если ядро содержит некоторые потенциально опасные вызовы, контейнеры также могут их использовать. Как только контейнер сможет контролировать ядро системы, он сможет полностью управлять любыми ресурсами, доступными основной системе.
 ====Ссылки====
-    The DeveloperWorks article LXC: Linux container tools was an early introduction to the use of containers.
+  ~~ Статья в DeveloperWorks [[https://www.ibm.com/developerworks/linux/library/l-lxc-containers/|LXC: Linux container tools]] является введением в использование контейнеров.
+  ~~ [[http://www.ibm.com/developerworks/linux/library/l-lxc-security/index.html|The Secure Containers Cookbook]] демонстрирует использование модулей безопасности с целью сделать контейнеры более безопасными.
-    The Secure Containers Cookbook demonstrated the use of security modules to make containers more secure.
+  ~~ Страницы руководств могут быть найдены по данным ссылкам:
+    ~~ [[http://manpages.ubuntu.com/manpages/en/man7/capabilities.7.html|capabilities]].
-    Manual pages referenced above can be found at:
+    ~~ [[http://manpages.ubuntu.com/manpages/en/man5/lxc.conf.5.html|lxc.conf]].
+  ~~ Основное развитие проекта LXC на [[http://lxc.sf.net/|Sourceforge]].
-    capabilities
+  ~~ Проблемы безопасности приведены и обсуждаются на странице [[http://wiki.ubuntu.com/LxcSecurity|LxcSecurity wiki]].
-    lxc.conf
+  ~~ Для дополнительной информации по пространствам имен в Linux смотрите: [[http://dl.acm.org/citation.cfm?id=1400097.1400109&coll=DL&dl=GUIDE&CFID=133158545&CFTOKEN=80778967|S.Bhattiprolu, E.W.Biederman, S.E.Hallyn, and D.Lezcano. Virtual Servers and Checkpoint/Restart in Mainstream Linux. SIGOPS Operating Systems Review, 42(5), 2008]].
+  ~~ Стефан Грабер (Stéphane Graber), в предверии выхода 20 февраля 2014 года релиза LXC 1.0, опубликовал цикл статей о Linux Containers. [[https://www.stgraber.org/2013/12/20/lxc-1-0-blog-post-series/|LXC 1.0: Blog post series]] ([[http://vasilisc.com/lxc-1-0-blog-post-series|перевод]]).
-    The upstream LXC project is hosted at Sourceforge.
-    LXC security issues are listed and discussed at the LXC Security wiki page
-    For more on namespaces in Linux, see: S. Bhattiprolu, E. W. Biederman, S. E. Hallyn, and D. Lezcano. Virtual Servers and Check- point/Restart in Mainstream Linux. SIGOPS Op- erating Systems Review, 42(5), 2008.
 ----
@@ Строка 546: / Строка 521: @@
 [[wiki:руководство_по_ubuntu_server:виртуализация:ubuntu_cloud|<-назад]] |
 [[wiki:руководство_по_ubuntu_server:кластеризация|далее->]]</style>

LXC Сравнение версий

Различия