kikimor.ru — персональный сайт

Безопасность — наше все. Давно задумывался над идеей вынесения дырявого WordPress в изолированную среду. Ранее я уже использовал виртуализацию — Virtualbox. Штука интересная и достаточно простая в использовании, но, как мне показалась, немного тяжеловата для задач изоляции сервисов — долго устанавливать систему, долго настраивать, требует значительное количество ресурсов. Вообщем, не айс.

На глаза попался новый (для меня) тип виртуализации — на уровне операционной системы. Гугл сказал, что наиболее популярные варианты: OpenVZ и LXC.

OpenVZ

Изначально выбор пал именно на OpenVZ. По нему куча информации и мануалов. Что смутило сразу  — OpenVZ требует специального ядра. Что смутило позже — требуемое ядро очень древнее — 2.6 (мамонты отдыхают, на данный момент в моей системе 3.17). Есть помнить то, что «безопасность — наше все» и то, что за последние пару лет в ядре линукса было найдено достаточно много уязвимостей, то идея ставить такое решето ломает основную идею — повышения безопасности.

Но я все-таки решил попробовать это сделать. В моей любимой Linux ОС Gentoo даже нашлись парочку ебилдов: sys-kernel/openvz-sources (ядро с OpenVZ) и sys-cluster/vzctl(утилиты управления). Если кто-то хочет попробовать собрать ядро с OpenVZ, то гугл с этим поможет. Я же советую не тратить время и переходить сразу к чтению про LXC, так как ядро OpenVZ под Gentoo не собирается ни с какими конфигами.

LXC

В отличии от OpenVZ LXC не требует никакого специального ядра. Все необходимое для работы контейнера на LXC уже есть в любом современном linux ядре. Единственное что нужно сделать — пересобрать ядро с дополнительными опциями. Но для начала советую установить ебилд:

emerge -av app-emulation/lxc

После установки вы получите полный пакет утилит для управления LXC контейнером. Помимо этого (абсолютно БЕСПЛАТНО! 🙂 ), в комплекте идет утилита lxc-checkconfig, которая проверяет текущую сборку ядра на наличие необходимых для работы модулей. Результат ее работы выглядит следующим образом.

# lxc-checkconfig
--- Namespaces ---
Namespaces: enabled
Utsname namespace: enabled
Ipc namespace: enabled
Pid namespace: enabled
User namespace: enabled
Network namespace: enabled
Multiple /dev/pts instances: enabled

--- Control groups ---
Cgroup: enabled
Cgroup clone_children flag: enabled
Cgroup device: enabled
Cgroup sched: enabled
Cgroup cpu account: enabled
Cgroup memory controller: enabled
Cgroup cpuset: enabled

--- Misc ---
Veth pair device: enabled
Macvlan: enabled
Vlan: enabled
File capabilities: enabled

Если все опции enable (как показано выше), то поздравляю — уже сейчас можно начать создавать контейнеры. Однако, в стандартном конфиге ядра поддержка многих опций по умолчанию не включена (о чем утилита грозит словами «missing»).

Не беда! Включим в ядро поддержку необходимых модулей. Мне больше нравится собирать ядро genkernel’ом.

genkernel --menuconfig

Включаем поддержку необходимых опций как показано ниже.

General setup  --->
 [*] Control Group support  --->
  [*]   Freezer cgroup subsystem 
  [*]   Device controller for cgroups
  [*]   Cpuset support
  [*]     Include legacy /proc/<pid>/cpuset file
  [*]   Simple CPU accounting cgroup subsystem 
  [*]   Resource counters 
  [*]     Memory Resource Controller for Control Groups
  [*]       Memory Resource Controller Swap Extension
  [*]         Memory Resource Controller Swap Extension enabled by default
  [*]   Enable perf_event per-cpu per-container group (cgroup) monitoring
  [*]   Group CPU scheduler  --->
   [*]   Group scheduling for SCHED_OTHER 
   [*]   Group scheduling for SCHED_RR/FIFO   
  <*>   Block IO controller
 -*- Namespaces support
  [*]   UTS namespace
  [*]   IPC namespace
  [*]   User namespace (EXPERIMENTAL)
  [*]   PID Namespaces
  [*]   Network namespace 
[*] Networking support  --->
      Networking options  --->
      <M> 802.1d Ethernet Bridging
      <M> 802.1Q VLAN Support 
Device Drivers  --->
      [*] Network device support  --->
       <M>   MAC-VLAN support (EXPERIMENTAL)
       <M>   Virtual ethernet pair device
      Character devices  --->
       -*- Unix98 PTY support
       [*]   Support multiple instances of devpts

После успешной сборки не забываем обновить конфиг grub’а:

grub2-mkconfig -o /boot/grub/grub.cfg

Тем, кто до сих пор не использует grub2, придется добавлять новое ядро в конфиг вручную. Гугл поможет.

Перед перезагрузкой можно снова воспользоваться утилитой lxc-checkconfig и убедиться, что при выборе опций мы ничего не забыли:

CONFIG=/path/to/kernel-config lxc-checkconfig

P.S. Обычно конфиги в Gentoo складываются в /etc/kernels/.

Если все оказалось «enabled», то можно торжественно послать сервер в ребут для загрузки нового ядра.

LXC — как создать контейнер

Для гостевой системы мне нужен был Debian. Для этого необходимо установить ебилд dev-util/debootstrap. После этого можно невероятно быстро развернуть виртуальную систему с Debian:

lxc-create -t debian -n guestname

Можно развертывать и другие linux-подобные, подробнее — http://wiki.gentoo.org/wiki/LXC.

Первое развертывание займет около 5-10 минут (скачивание исходников системы), но последующие — невероятно быстро. У меня развертывается за пару секунд. Настройки созданного контейнера, а так же сама файловая система, по умолчанию хранится в /etc/lxc/guestname/.

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

lxc-start -n guestname

Если хочется запускать через /etc/init.d/, то в комплект поставки LXC (опять же абсолютно бесплатно) включены init скрипты. Все что нужно — создать символьную ссылку:

ln -s /etc/init.d/lxc /etc/init.d/lxc.guestname

После чего можно использовать привычные:

/etc/init.d/lxc.guestname start
/etc/init.d/lxc.guestname stop

и добавлять виртуалки в автозапуск при помощи rc-update.

Подключиться в консоль виртуалки можно командой:

lxc-console -n %CONTNAME%

Остальную информации об управлении контейнером можно прочитать на http://wiki.gentoo.org/wiki/LXC.

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

Изначально я решил написать эту статью только ради этого сабжа, но что-то разошелся. 🙂

После перехода в контейнер командой lxc-console, показывается алерт, намекающий на то, каким образом можно покинуть этот контейнер:

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

Я безуспешно пытался выполнить пресловутую комбинацию из Ctrl+a, а затем — Ctrl+q, которая ни к чему не приводила и мне приходилось открывать еще один сеанс в PuTTY. Но однажды меня озарило! Нам советуют нажимать Ctrl+a <пробел> q. Пробел! Это значит, что Ctrl в момент нажатия q уже нужно отпустить.

Действительно, если после нажатия Ctrl+a отпустить Ctrl и нажать q, то управление возвращается в хостовую систему.

Мораль: нужно читать документацию, обращая внимание на мелочи. 🙂