Различия

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

--- wiki:руководство_по_ubuntu_server:виртуализация:lxc [2012/10/27 08:51]
[Libvirt LXC]
+++ 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>
@@ Строка 437: / Строка 440: @@
 ===Преобразование контейнера 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.
 ----
@@ Строка 536: / Строка 521: @@
 [[wiki:руководство_по_ubuntu_server:виртуализация:ubuntu_cloud|<-назад]] |
 [[wiki:руководство_по_ubuntu_server:кластеризация|далее->]]</style>

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

Различия