Ранее в OpenVZ данная задача решалась .mount-файлами (подробнее тут). Но теперь контейнеры называются как-нибудь так «600adc12-0e39-41b3-bf05-c59b7d26dd73» и создание файла 600adc12-0e39-41b3-bf05-c59b7d26dd73.mount проблему не решает, он просто игнорируется при запуске. Конечно, наличие папки /vz/private/600adc12-0e39-41b3-bf05-c59b7d26dd73/scripts намекает, что возможен запуск каких-то скриптов, но найти документацию об этом не удалось.
В 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.service2 [Unit] Description=Mount from Hardware node After=network.target Before=smbd.service [Service] Type=oneshot ExecStart=/usr/bin/ssh mount@192.168.77.11 [Install] WantedBy=multi-user.target EOF
- Включим созданный сервис автомонтирования:
CT# systemctl enable mount.service
Всё. Теперь можно перезагружать контейнер и радоваться монтированию папки /data.
Комментарии (15)
shapa
13.09.2016 10:55Вопрос, для себя понять.
Какие преимущества даст OpenVZ над LXC? Docker? Смысл применения? Выглядит как масса костылей.
Развитие только ограниченной командой, фактически проигранный рынок.
Но я возможно чего-то не знаю?
RicoX
13.09.2016 17:28Сравнение с Docker не корректно — это абсолютно разные типы контейнеров с разными кейсами использования, то что удобно делать в докер, не удобно в ОВЗ и наоборот. LXC — достаточно молодой продукт с рядом шероховатостей, но потихоньку набирает обороты, если догонит OpenVZ прошлого поколения по стабильности — будет очень круто, но пока еще не догнал.
shapa
13.09.2016 17:38В чем некорректность сравнения с Docker? Что я не смогу сделать на Docker и смогу на OpenVZ? Какие конкретно неудобства?
Неудобным например можно считать в том что OpenVZ 7 убил совместимость с предыдущей версией.
То что я вижу — миграция проектов с OpenVZ (например Proxmox — https://forum.proxmox.com/threads/jessie-and-3-10-0-openvz-kernel-and-the-future.22035/ ).RicoX
13.09.2016 19:33В чем некорректность сравнения с Docker?
Docker — не изменяемые контейнеры отдельных приложений.
OVZ/LXC — изменяемые контейнеры полноценной среды.
Что я не смогу сделать на Docker и смогу на OpenVZ
Вопрос не в возможности или невозможности, а в количестве костылей для развертывания, например на OVZ достаточно сложно сделать несколько десятков идентичных, не сохраняющих изменения контейнеров для разных версий определенной программы, попробуйте развернуть на OVZ для одного домена поддержку скажем php 5.2,5.3,5.6,7.0,7.1 чтоб они не конфликтовали между собой и каждый обрабатывал свою часть сайта либо можно было переключаться между ними, а еще разные версии перла, скомпилированного с разными либами и так далее. В свою очередь попробуйте на докере сделать полностью рабочую среду проекта из сотни компонентов, которым надо сохранять все изменения, иметь внутри контейнера несколько СУБД и бэкапиться одним куском, чтоб можно было восстановить на определенный момент всю систему, а не отдельные ее части, разные инструменты для совершенно разных задач.
Неудобным например можно считать в том что OpenVZ 7 убил совместимость с предыдущей версией.
Ну они типа выложили скрипт миграции https://src.openvz.org/projects/OVZL/repos/ovztransfer/browse работает он правда коряво и требует ручного вмешательства во многие контейнеры после миграции, особенно если нет базового темплейта для ОС этого контейнера, но он есть, не скажу что мигратор на LXC работает значительно лучше, да и сам LXC в ProxMox то еще глючное поделие с набором косяков, смотрите заметку, чтоб не повторяться.shapa
13.09.2016 20:46Ладно, примерно понял что все плохо везде кроме докера.
" В свою очередь попробуйте на докере сделать полностью рабочую среду проекта из сотни компонентов, которым надо сохранять все изменения, иметь внутри контейнера несколько СУБД и бэкапиться одним куском, чтоб можно было восстановить на определенный момент всю систему, а не отдельные ее части, разные инструменты для совершенно разных задач. "
Это без проблем умела делать calm.io, которую мы выкупили. Если про OS решения — да, не так просто, хотя IMHO сложностей все равно меньше чем с openvz.RicoX
13.09.2016 21:13Это без проблем умела делать calm.io
Не работал с этой системой, надо глянуть если реально умеет, если не затруднит дайте ссылку на техдоку, а то открыл сайт, а там один рекламный булщит. А какие сложности с OVZ, если мы говорим про предыдущее поколение, а не урезанную седьмую версию?
zystem
13.09.2016 22:31+1Docker это надстройка над LXC. Поэтому говорим Docker подразумеваем LXC. Т.е. сравнивать OpenVZ и Docker не совсем корректно.
Далее, лично мне Docker не понравится. Все то-же самое можно сделать на чистом LXC/OpenVZ, но без недостатков самого Docker. При этом в Docker есть все недостатки присущие LXC + его собственные. У меня основная претензия — это отсутствие возможности сохранять данные в самом контейнере. Я понимаю что это сделано специально но мне такая архитектура не нравится.
Вообще у меня сложилось впечатление что докер ждет судьба VirtualBOX. Все слышали, многие используют дома/на рабочем ПК, но на серверах стоит VmWare. Так и тут. Докер удобен разработчикам, но ставить в продакшен неизвестно чьи образы с возможно присутствующими бекдорами… А если ВСЕ собирать самим то докер теряет половину достоинств. Да и для деплоя есть и другие инструменты. Они сложнее чем докер и разработчики не хотят в них разбираться. Но на продакшене есть админы, а админам Puppet/Ansible/Chef/etc… привычнее и универсальнее. Но я повторюсь мне Docker не понравится поэтому я предвзят.RicoX
14.09.2016 08:21У меня примерно такое-же мнение о Docker, его среда — это DevOps и тесты, для продакшина при его использовании мы кладем болт на безопасность, кроме чужих образов, даже на своих, если в базовой ветке найдена критичная уязвимость, то мы должны обновить все контейнеры, причем многие пересобрать вручную, особенно это критично для тех, где использовали коммит, а не делали докерфаил от базового. Хотя сам я докером иногда пользуюсь, но в основном если надо развернуть быстро какой-то говнософт, который тянет хренову гору зависимостей, но нужен на 1 раз, чтоб не захламлять систему, поставил, раз запустил, что нужно получил и убил.
zystem
13.09.2016 22:34+1Про LXC у меня сложилось мнение что это недо-OpenVZ.
Раньше LXC не было. Были патчи комманды OpenVZ на ванильное ядро. Постепенно эти патчи добавлялись прямо в ванильное ядро. Соответственно уменьшался объем OpenVZ патчей которые надо было применить дополнительно. На базе функционала добавленного в ванильное ядро был разработан LXC. Но в нем по прежнему не весь функционал OpenVZ.
Вот тред где люди перешли с OpenVZ на LXC и им это не понравилось https://forum.proxmox.com/threads/moving-to-lxc-is-a-mistake.25603/
А в целом если OpenVZ набор костылей, то LXC тоже набор костылей но не полный.
zystem
13.09.2016 22:48+1Ограниченная команда на зарплате эффективнее кучи энтузиастов в свободное время (если энтузиастов не тысячи). Кстати практически весь открытый софт по большей части пишется людьми на зарплате, которые получают зарплату именно за разработку открытого софта. Например в ядре прилично кода Red Hat, да и Parallels тоже свои патчи продвигает в ванильное ядро.
Говорить про проигранный рынок тоже сложно. Есть масса OpenVZ хостингов. А вот про хостинги на LXC лично я не слышал. Докер хостингов тоже видел всего пару проектов. Просто не сильно агрессивная по сравнению с тем-же докером реклама (про OpenVZ и так все знают). Вон xen тоже не особо рекламируется, а на нем Amazon EC2 работает.o_serega
14.09.2016 20:40Я не уверен что на амазоновских объемах и нагрузках работает именно тот xen, что мы знаем, уверен что за годы там кодовая база сильно ушла в сторону) Openvz, перед lxc, все же, пока, имеет в преимуществах более строгую изоляцию по ресурсам, хотя lxc за последние 2 года тоже на месте не стоял, лично у меня достаточно много чего переехало из kvm виртуалок в lxc контейнеры, ну и микросервисы в docker)
RicoX
Интересно ваше мнение об OpenVZ 7.0 в общем, я вот пытался на него перейти с предыдущей версии и у меня стойкое впечатление, что слияние с Virtuozzo просто убило проект, из проекта выкинуты многие удобные вещи, которые были ранее, те же маунты и бэкапы, без которых использование за пределами песочницы для OpenVZ 7 стало сомнительным и все как-бы намекает, вы тут используете демо версию Virtuozzo, не вздумайте применять проект для продакшина.
zystem
У меня сложилось впечатление, что просто пока мало документации. Я писал про папку /scripts. В документации тоже есть упоминания про запуск скриптов при старте контейнера. Просто пока не понятно как. А пока вот такой костыль.
Я не думаю что слияние убило проект. Просто для старой версии было накоплено множество готовых решений. Теперь нужно набирать новую базу рецептов. С бекапами я уверен тоже можно что-то придумать.
RicoX
Хорошо, если это реально так, про стартовые скрипты, а вариант от прошлой версии не катит, если создать в папке с конфигами скрипт с именем контейнера.mount? Про бэкапы я так понял это официальная позиция проекта, хотите бэкапы — покупайте virtuozzo, иначе prlcrl backup не пашет.