LINUX.ORG.RU

Что за г**но происходит с виртуализацией и контейнерами?

 , , ,


1

3

Я уже не один год ищу адекватное решение для организации процесса разработки. За последние 3 года появились различные инструменты типа Vagrant, Docker и т. п.

Прикол в том, что ни одно из решений не умеет нормально и из коробки главного: работать корректно с правами доступа.

Ситуация такова:

1. Если софт умеет нормально монтировать директории проекта (скажем снаружи: он текущего юзера, внутри контейнера: www-data), например, тот же VirtualBox + Vagrant, то он тупит-тормозит, что сил нет и весит овер9000 МБ (допустим, я хочу запустить простенький проект на пэхапе, и ради этого я должен качнуть минимум 500МБ образ убунты и ждать больше 5 минут, что раскатать это чудо на своей машине).

2. Если софт умеет быстро подниматься, собираться и быть как пионер готовым в течение пары секунд, то автоматически он не умеет монтировать директории проекта (см. пример из пункта № 1) с адекватными для работы правами (идиоты делающие <chmod 777 -R ./> на весь проект ради решения проблемы идут лесом). Сюда относятся реализации Vagrant + LXC, Docker (Читай: AUFS + LXC), VirtualBox на вменяемой по скорости NFS.

Я вижу хипстеров орущих про просту оркестровки контейнерами (докир, аншибль, континиоус интегрейшин, ноу-даунтайм) и деплоинг без PITA, но в реальности нельзя взять ровно тот же Docker-контейнер у разработчика и перенести его простым движением в продакшн. Но я не вижу удобного и безкостыльного решения.

Собственно, сабж. Что вы думаете об этом?

Deleted

Последнее исправление: ifelse (всего исправлений: 1)

, но в реальности нельзя взять ровно тот же Docker-контейнер у разработчика и перенести его простым движением в продакшн.

можно

Deleted
()
Ответ на: комментарий от Deleted

, но в реальности нельзя взять ровно тот же Docker-контейнер у разработчика и перенести его простым движением в продакшн.

можно

Правда такая фигня получается...

i-rinat ★★★★★
()
Ответ на: комментарий от Deleted

Приведи пример, помоги идиотам

Deleted
()
Ответ на: комментарий от Deleted

Серебряной пуля нет, но должна же быть годами выработанная метода выгрузки.

Deleted
()
Ответ на: комментарий от i-rinat

Ну пока что я только парился из-за того что отладчиком залезть в контейнер кучеряво, и то потому что при разработке не сделали «легкое» включение отладки

Deleted
()
Ответ на: комментарий от x3al

Для докера еще окей: именнованный volume-костыльконтейнер, а остальным что делать?

Deleted
()
Ответ на: комментарий от sudopacman

Да я в курсе. Иной раз мне кажется, что это бот, но в осмысленные дискуссии он таки вступает, что исключает вариант с ботом. (=

DeadEye ★★★★★
()

народ, а просветите меня кто-нибудь, зачем нужна виртуализация для организации процесса разработки?

darkenshvein ★★★★★
()
Ответ на: комментарий от darkenshvein

она дает повторяемость и переносимость окружения.

Но только если вы разворачивать будете тоже в контейнере, в противном случае - противопоказано.

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от darkenshvein

Например, когда требуется быстро включить в процесс нового разработчика (допустим, делаем веб-приложение состоящее из нескольких микросервисов) и не мучаться с настройкой его окружения (чего те же самые веб-разработчики в 99% случаев не могут самостоятельно). А лень — она впереди всех. Виртуализация — лень управляемая, сдобренная верой в переносимость.

Deleted
()
Последнее исправление: ifelse (всего исправлений: 1)
Ответ на: комментарий от Deleted

чего те же самые веб-разработчики в 99% случаев не могут самостоятельно

Когда я слышу, что Разработчик не может настроить для себя окружение, у меня рвутся шаблоны.

Пойти что-ли в веб-разработчики. Пусть для меня настаивают окружение для разработки. Там хоть денег нормально платят? Больше чем админам, для которых такая задача и не задача вовсе, а рутина (причем независимо от языка программирования)? MySQL я знаю (настаивал примерно миллион раз, а причину тормозных запросов искал 100500 раз), какой-нибудь фреймворк за пару месяцев осилю. Денег там больше сисадминских 40-50т в месяц платят?

anonymous
()

Да, фигня там получается если без остальной обвязки использовать. Однако, если всё равно очень надо, есть один помогающий костыль: при старте контейнера смотреть на uid/gid какого-нибудь точно существующего файла в примонтированой директории и перед запуском сервиса в контейнере пересоздать сервисного пользователя с нужными uid/gid, обновить владельца его файлов в контейнере и только после этого запускать уже сам сервис.

manntes-live ★★★
()

Так всегда будет, если документацию не читать. Твою пробелму уже обсуждали, чем такое решение не подходит?

vrutkovs ★★
()

1) docker давно использует libcontainer и не имеет lxc в зависмостях 2) при сборке docker образа код проекта обычно не монтируют через volumes, а «добавляют» в persistent слой.

misanthropy
()
Ответ на: комментарий от Deleted

Приколист.

link

Сейчас они перешли на runc, но это неважно.

*** Если ты работаешь над проектом и изменения постоянны - к образу/ам монтируют папку с проектом.

Если изменения редки (в production) - проект собирается в образ, а не монтируется к нему.

misanthropy
()
Ответ на: комментарий от misanthropy

проект собирается в образ, а не монтируется к нему

Это правда, но бывают проекты, где есть пользовательские данные: банальная директория upload (использовать riak cs — overkill, хотя и там нужен еще один volume для хранения данных), например. Как быть?

Deleted
()
Ответ на: комментарий от misanthropy

К слову, единственная адекватная статья о докере, где более или менее разложено по полочкам, но все равно обходят стороной вопрос монтирования-расшаривания, это вот: https://grikdotnet.gitbooks.io/docker-myths-and-receipts/content/docker1.html

Приведу даже цитату:

Перефразируя фильм «Адвокат дьявола», авторы docker дают нам тома в контейнерах, дарят этот экстраординарный подарок, а потом для своего ролика космических трюков устанавливает противоположные правила игры. Расшаривай каталог между контейнерами - но не удаляй. Монтируй свою папку - но не распространяй в образе. Записывай папки в образ и распространяй - но не расшаривай между контейнерами!

Несмотря на проблемы, использовать в контейнерах общие каталоги для хранения файлов приложения и базы данных очень удобно, а проблему можно подпереть костылем в виде пары shell-команд в Dockerfile.

Костылем, Карл. И в связи с этим хочется спросить, так как же все-таки реализовать этот костыль, чтобы одна и та же конфигурация идентично собиралась у любого разработчика (читай: из коробоки)?

Deleted
()
Последнее исправление: ifelse (всего исправлений: 1)
Ответ на: комментарий от Deleted

Не могу здесь помочь.

***

под монтированияем я понимаю это.

Да, в таком случае нужно одновременное монтирование директории к нескольким контейнерам. Если это БД, то монтирование обязательно (aufs - cow файловая система, - должно, наверно, быть проседание производительности).

Есть flocker - я не знаю, как он рабодает.

Есть distributed fs - типа ceph, glusterfs и т.д. - они годятся для статики.

И, как мне кажется, современные веб-приложения должны быть написаны в стиле mesos фреймворков (или nomad), и поддерживать репликацию данных на более низком уровне, ...

misanthropy
()
Ответ на: комментарий от misanthropy

Ночью появилась идея как все это завернуть в одно решение. Коробочный костыль, но, черт возьми, может быть сработает. Отпишусь как попробую.

Deleted
()

Если софт умеет быстро подниматься, собираться и быть как пионер готовым в течение пары секунд, то автоматически он не умеет монтировать директории проекта…

Работаю с докером полтора месяца, пока всё устраивает.

При создании образа в нем делаю юзера:

# Dockefile
FROM ubuntu:14.04
...
ARG user
ARG uid
ARG group
ARG gid
...
RUN groupadd --gid ${gid} ${user}
RUN useradd --uid ${uid} --gid ${gid} ${user}
...

При создании контейнера монтирую каталоги:

$ docker create ... \
    --volume $dir/home:/home/$user \
    --volume $dir/work:/$user/work \
    ...

$dir/home — это не ~. Незачем контейнеру иметь доступ ко всему моему домашнему каталогу. Это специальный каталог, который будет домашним для контейнерного юзера (у меня в нём лежат .bash_profile и пара скриптов).

Последний шаг — на хосте разрешить докеру доступ к $dir/home и $dir/work:

$ chcon -R -t svirt_sandbox_file_t $dir/home $dir/work

Вуаля: на хосте и в контейнере мой юзер имеет одно и то же имя и юиды/гиды, каталоги $dir/home и $dir/work видны как с хоста так и из контейнера с адекватными правами. Текстовый редактор работает на хосте, компиляция идёт в контейнере (запускается по кнопке из редактора). Мапить внешние юиды во внутренние пока не пробовал.

…в реальности нельзя взять ровно тот же Docker-контейнер у разработчика и перенести его простым движением в продакшн.

В моём случае о «переносе контейнера в продакшн» речи нет: исправленные исходники отправляются в гит (гит тоже работает на хосте), на чём моя работа заканчивается.

Контейнер создавался по причине того, что требуемые версии компиляторов/библиотек древние, которых в федоре давно нет. Ставить же на рабочую машину старую убунту вместо текущей федоры я не хотел. Потыкал палочкой докер — всё получилось.

debugger ★★★★★
()
Ответ на: комментарий от beastie

Угу, по умолчиню там всё root.

Умолчание легко сменить.

debugger ★★★★★
()
Ответ на: комментарий от debugger

Контейнер создавался по причине того, что требуемые версии компиляторов/библиотек древние, которых в федоре давно нет.

Тебе нужен chroot, контейнер с изоляцией процессов тут нафиг не уперся

annulen ★★★★★
()
Ответ на: комментарий от annulen

Тебе нужен chroot, контейнер с изоляцией процессов тут нафиг не уперся

Самому собирать файлы под чрутом мне нафиг не уперлось. Имхо, проще в докерфайле одну строчку написать — благо готовых образов навалом.

debugger ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.