zystem 12 сен 2016 в 13:03

Shared Folders в OpenVZ 7.0

4 мин

5.4K

Новый OpenVZ 7.0 является гибридом старого доброго OpenVZ и коммерческого Virtuozzo. Хотелось бы думать, что он взял лучшее от обоих родителей, но это не так. В данном случае под нож попал функционал Shared Folders.

Ранее в OpenVZ данная задача решалась .mount-файлами (подробнее тут). Но теперь контейнеры называются как-нибудь так «600adc12-0e39-41b3-bf05-c59b7d26dd73» и создание файла 600adc12-0e39-41b3-bf05-c59b7d26dd73.mount проблему не решает, он просто игнорируется при запуске. Конечно, наличие папки /vz/private/600adc12-0e39-41b3-bf05-c59b7d26dd73/scripts намекает, что возможен запуск каких-то скриптов, но найти документацию об этом не удалось.

UPDATE
Спасибо romchi нашелся работающий метод. Но действует он на ВСЕ контейнеры сразу. Для индивидуальных маунтов придется дополнительно вставлять if then блоки.

метод romchi

echo '#!/bin/bash
. ${VE_CONFFILE}
mount -n -o bind /opt/ /vservers/root/${VEID}/opt
' > /etc/vz/conf/vps.mount

chmod +x /etc/vz/conf/vps.mount

можно по этому методу использовать официальный скрипт Bind_mounts

метод romchi + официальный Bind_mounts

echo '#!/bin/bash
. /etc/vz/vz.conf
. ${VE_CONFFILE}
SRC=/mnt/disk
DST=/mnt/disk
if [ ! -e ${VE_ROOT}${DST} ]; then mkdir -p ${VE_ROOT}${DST}; fi
mount -n -t simfs ${SRC} ${VE_ROOT}${DST} -o ${SRC}
' > /etc/vz/conf/vps.mount

chmod +x /etc/vz/conf/vps.mount

Как итог можно вернуть все как было

возврат .mount-файлов

cat <<'EOF' > /etc/vz/conf/vps.mount
#!/bin/bash
. ${VE_CONFFILE}
VE_MOUNT=$(echo ${VE_CONFFILE} | sed 's/\.conf$/.mount/')
[ -x ${VE_MOUNT} ] && . ${VE_MOUNT}
exit 0
EOF

chmod +x /etc/vz/conf/vps.mount

/UPDATE

В Virtuozzo Shared Folders были реализованы через prlctl set, но в OpenVZ этот функционал портирован не был. Не верите — проверка под спойлером.

Скрытый текст

В этом можно убедится введя:

prlctl set СTname --shared
prlctl set СTname --shared-profile
prlctl set СTname --sharedfolder-add
prlctl set СTname --shf-host-add

Никакая из этих команд не работает.

Что же делать?

Поднять NFS сервер на физическом сервере и NFS клиент внутри контейнера. Как я понял, это официально рекомендуемый вариант. Но NFS даст дополнительные задержки и дополнительную нагрузку на систему.
С помощью prlctl --device-add подключить дисковое устройство непосредственно к контейнеру. К сожалению только к одному и при этом от физического сервера его придется отключить, одну папку так тоже не подключишь.
С помощью prlctl --device-add подключить дисковое устройство (переформатировав его в какю-нибудь кластерную файловую систему, например, GFS или OCFS2) непосредственно к контейнеру. Можно подключить к нескольким контейнерам и физическому серверу. Но папку подключить также не удастся
Вернуть старый (не нагружающий систему) функционал Bind mounts вручную.

Первые три способа описаны в официальной документации и есть много информации в интернете. А вот про четвертый способ и расскажет эта статья.

Если коротко, то мы будем из контейнера по ssh запускать скрипт на физическом сервере, делающий bind mount.

А теперь подробнее.

Для примера возьмем физический сервер с ip 192.168.0.11 и контейнер 192.168.0.22 UUID 600adc12-0e39-41b3-bf05-c59b7d26dd73 с установленным samba сервером и systemd

Заведем на физическом сервере пользователя mount для ssh подключения
```
HN# useradd mount
```
Сгенерируем rsa ключи для пользователя root в контейнере
```
CT# ssh-keygen –t rsa
```

Скопируем содержимое файла /root/.ssh/id_rsa.pub в контейнере в /home/mount/.ssh/authorized_keys на физическом сервере. Должно получится что-то типа:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDXPMfZ+9Og1uY+Eq2QE85AxO+0DM0wfejNuIEZfRUi9FZj8/3BLM9u1GrmOKSMRTGIXA3yfyfep+hAm0/phuaqqG8wU2YAai/8aF4PXokeYVPzQqsbK8fK1wLYWgTO3RCtojfpoHPvdQMt28+GFRj4CTRuktUSx63XswNjzPWlqfUjiEnLZRdwbaB6ZKeepdGUmzgYq7dhMxdl3VvtAWahGnkGnn7eXT49Z9SekvFPUL77BsHwQXgspuSosg31YE09+spyA6khzwJKEqPXHRniv4H5DUzdZiQXx3tkGheGCO6JTDmcSElZyWwC9h+H7ZEEJ4IO3RRnDcsxgkW+ixij root@container

Убедимся, что не напутали с правами на физическом сервере:

HN# ls -al /home/mount/.ssh/
total 12
drwx------ 2 mount users 4096 Sep 10 18:54 .
drwx------ 5 mount users 4096 Sep 10 18:04 ..
-rw------- 1 mount users  485 Sep 10 18:54 authorized_keys

Проверим что можем без пароля по ключу подключится к физическому серверу из контейнера:
```
CT# ssh mount@192.168.0.11
```
Создадим в контейнере точку монтирования:
```
CT# mkdir /data
```

Создадим на физическом сервере.mount скрипт /vz/samba.mount:

HN# cat <<EOF > /vz/samba.mount
#!/bin/bash
mount -n --bind /data /vz/root/600adc12-0e39-41b3-bf05-c59b7d26dd73/data
EOF
chmod +x /vz/samba.mount

На физическом сервере добавим его в sudoers для пользователя mount:
```
HN# echo "mount ALL=NOPASSWD: /vz/*.mount" > /etc/sudoers.d/mount
```
На физическом сервере для запуска скрипта по ssh отключим requiretty в sudoers
```
HN# sed -i 's/^Defaults\s\+requiretty/#Defaults    requiretty/' sudoers
```
Запретим на физическом сервере пользователю mount запускать что-либо кроме / bin/sudo /vz/samba.mount. Дописав в /home/mount/.ssh/authorized_keys текст command="/bin/sudo /vz/samba.mount",no-port-forwarding,no-X11-forwarding,no-agent-forwarding
```
HN# echo "command=\"/bin/sudo /vz/samba.mount\",no-port-forwarding,no-X11-forwarding,no-agent-forwarding $(cat /home/mount/.ssh/authorized_keys)" > /home/mount/.ssh/authorized_keys
```

В контейнере создадим юнит для автомонтирования. Обратите внимание, он запускается ДО запуска samba сервера.

CT# cat <<EOF > /etc/systemd/system/mount.service
[Unit]
Description=Mount from Hardware node
After=network.target
Before=smbd.service

[Service]
Type=oneshot
ExecStart=/usr/bin/ssh mount@192.168.0.11

[Install]
WantedBy=multi-user.target
EOF

Включим созданный сервис автомонтирования:
```
CT# systemctl enable mount.service
```

Всё. Теперь можно перезагружать контейнер и радоваться монтированию папки /data.

Теги:

Хабы:

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

Shared Folders в OpenVZ 7.0

Публикации

Истории

Работа

Ближайшие события