Почему так не делают в docker (all-in-one чёрный ящик)?

Question

[Andrey Kobyshev]

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

Для этого вникаю в docker и начал собирать свои образы для платформ, которые использую.

И почти везде вижу советы, вида "создайте 2 контейнера: один для вашего приложения, другой контейнер для базы данных, а потом слинкуйте их" и пока ни разу - запихните всё, и базу и приложение в один контейнер. И тут я впадаю в ступор. Если основной посыл Docker'а "контейнеризация позволяет переносить и запускать в любой среде ваши приложения со всеми зависимостями", то какой тогда смысл в Docker, если мы опять разбиваем приложение на куски, имея весь тот геморой, который мы имели, когда докера не было?

Каким я вижу best-way:

1. Берём baseimage
   
2. Строим на его основе контейнер, в котором есть всё для запуска полнофункционального приложения - и база, и nginx и нужные библиотеки
   
3. Если надо, то даём приложению возможность лазить куда-нибудь на S3/внешнуюю базу (как правило, не надо)
   
4. Делаем data volume на основе этого образа в среде, где будем запускать (если в первый раз, или восстанавливаем из бекапа), на этот data-volume пишутся все последующие изменения - растёт база, хранятся файлы, создаваемые приложением и т.п.
   
5. Запускаем контейнер и радуемся жизни
   

Из плюсов: независимость от внешней среды, лёгкий и удобный бекап и восстановление/перенос через перетаскивание только data-volume, куча разных приложений не хранит свои данные в одной базе (отсюда нет гемороя с переносом/бекапом/взломом или потерей всего при крахе контейнера с базой), наружу торчит только порт сервиса, через который идёт с ним взаимодействие как с "чёрным ящиком" и ничто не мешает сервису лазить наружу за чем-нибудь, что ему может понадобиться.
Минусы: повышенный расход памяти и диска (но это терпимо в моём случае).

Мой вопрос - почему во всём инете я практически не нашёл упоминания такого подхода? Что с ним может быть не так, и каких подводных камней я не увидел?

Comments

[Руслан Гильфанов]

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

Многие подходы и многие программные продукты созданы, чтобы решать проблемы крупных корпораций, вроде 100.000 или 1.000.000 запросов в секунду.

Практиковать эти подходы и ПО имеет смысл, если Вы собираетесь трудоустроиться в крупную IT компанию с огромными нагрузками.

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

Чтобы развернуть проект парой команд (или чуть больше), есть масса более простых в устройстве инструментов: от совсем банальных установочных скриптов до уже упомянутого в ответах Ansible.

Собственно почему я заговорил о простоте? Я полагаю, что слишком большое количество магии вызывает тяжёлую форму зависимости с непредсказуемыми последствиями. Собственно, на магии выехал и нелюбимый вами веб-фреймворк Django: заготовка проекта с новым секретным ключом по команде, миграции по двум командам и куча батареек разной степени магичности. Если на достойном уровне знать Django, то прототипировать с ним быстро, 90% задач решаются быстро, а вот небольшое допиливания и кастомизация... подобны попыткам сломать головой стену, заботливо выстроенную разработчиками Django.

Похожая история и с Docker. Многие используют Docker, чтобы не писать большую документацию по установке, не пакетировать приложения, не писать установочные скрипты, не вникать в нюансы разных платформ и не поддерживать ПО в актуальном состояния. В итоге можно наблюдать в продакшене магические коробочки, в которых крутится какое-то магическое легаси с устаревшими лет пять назад зависимостями. Причём без Docker на актуальных дистрибутивах Linux это уже не собирается и не запускается. А если контейнер откажется подниматься после обновления Docker...

В общем, обычно технологии пилят под свои нужды и потом раскручивают, чтобы переложить разработку на OpenSource сообщество и получить в отделе кадров поток специалистов уже знающих эту технологию. Поэтому пользоваться всем, что на слуху -- не стоит. А если пользоваться -- то порой бывает очень полезно скептически подходить к рекомендациям и подходам из официальной документации. Нужно понимать контекст для кого это писались, какие задачи должно решать, хорошо ли всё это переносится на ваши задачи, и т.д.

Answer 1

[Сергей Протько]

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

Отчего же? Ваше приложение может работать под арчем используя одни либы, используя при этом базу данных которая крутится под дебианом, при этом вы не паритесь о каких-то других вещах. Если вам нужна база данных - вы просто используете контейнер с оной как черный ящик. А с учетом того что у нас есть docker-compose разворачивать такую систему вообще не проблема, просто запускаем docker-compose up и все. Мы добились того же что можно было бы сделать используя один контейнер, но всю систему намного проще поддерживать.

По сути если мы разделяем наше приложение на отдельные сервисы (база данных, реверс-прокси, кэш и т.д) и при этом используем удобный формат вроде docker-compose.yml для того что бы описать что у нас там и как оно должно быть слинковано вместе, мы получаем все те плюсы которые вы указали и простоту поддержки контейнеров.

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

Ну и опять же, многие делают именно так как вы. Просто запихивают все в один контейнер.

А ну и еще - ваш подход плохо подходит для масштабирования. Скажем я хочу что бы у меня база данных крутилась на отдельном кластере серверов, а приложение на другом. И тут мы проигрываем.

Comments

[Andrey Kobyshev]

Спасибо за ответ! Да, насчёт ада в Dockerfile, пожалуй соглашусь. Но тут же основная идея в том, чтобы оперировать приложением как отдельной единицей. Скачал образ, подцепил data-volume и всё заработало. Насколько удобно с тем же docker-compose бекапить и восстанавливать все зависимости в новом окружении? Где об этом можно подробнее узнать?

[Сергей Протько]

yokotoka: что значит "бэкапить и восстанавливать"? У меня имиджи отдельные лежат в docker/distribution (или регистри) и я не парюсь. В docker-compose прописаны теги, что юзать, как линковать. ничего бэкапить не надо, разве что волум для данных базы, но опять же это не входит в обязанности докера и обычно я это делаю штатными средствами СУБД (например репликация или снэпшоты или еще чего).

[Andrey Kobyshev]

Имею в виду, что часто база данных - неотъемлемая часть приложения. Скажем, сайтик какой-нибудь или небольшой сервис. Зачем выносить базу в отдельный инстанс (да ещё класть в несколько несвязанных между собой схем в одну базу), если "приложение" в самодостаточно со всеми потрохами и требуется только его удобно при необходимости перенести в другое место?

[Сергей Протько]

yokotoka: ну и да, типичный сценарий, допустим я недавно разворачивал у себя sentry (приложение для агрегации логов). Для этого я взял docker-compose.yml и сделал docker-compose up -d. И все. Все образы скачались, все собралось, слинковалось и запустилось, бери и юзай.

[Andrey Kobyshev]

Сергей Протько: если помимо СУБД у вас различные файлы, которые приложение создаёт в процессе жизни, uploads всякие и т.п., которые хочется бекапить вместе с базой и разворачивать это же удобно? Просто задолбался скрипты писать бекапа и восстановления, когда база - отдельно, файлы - отдельно. Хотелось бы всё это в одном понятном слое хранить, который можно легко забрать/перенести.

[Сергей Протько]

yokotoka: ну у вас база это неотъемлемая часть, а у меня база на отдельном серваке крутится. И это довольно типичная ситуация. Скажем я могу захотеть что бы мое приложение крутилось в контейнере а базу данных я заменю на RDS амазоновский (что бы репликацию мышкой настраивать). И все будет работать (если нет чего кастомного сильно).

Суть в том что если вам нужна база данных вы просто линкуете свое приложение с готовым образом той базы данных которую вы хотите юзать. И все, оно просто работает. Никаких проблем, запарок и т.д. Действий намного меньше чем при объединении в один контейнер, так как наследоваться от двух образов мы таки не можем и что-то придется делать в Dockerfile самим.

По поводу волумов и т.д. - тут есть свои нюансы. Скажем при определенной конфигурации подмена контейнеров при деплоя осуществляется проще.

[Сергей Протько]

yokotoka: воу, так вы хотите и файлы внутри контейнера хранить? Вас не смущает что когда контейнер потушится то все данные исчезнут?

[Andrey Kobyshev]

Сергей Протько: data-volume же. Я же написал, что делаем image, где всё необходимое для аппликухи, на основе этого image создаём пустой data-volume, в который будет всё писаться. И ничего не порушится. У docker в доках это сейчас описывается как рекомендуемый подход.

[Сергей Протько]

yokotoka: ну вот вы меня смутили просто тем что не хотите скрипты для бэкапов писать, и при этом вы будете юзать data-volume который всеравно заставит вас писать скрипты для бэкапов так как... данные все же хранятся на файловой система в единственном экземпляре, и если что-то с серваком станет не так вы расстроитесь.

[Andrey Kobyshev]

Сергей Протько: т.е. всё, что происходит после настройки базового образа попадает в rw-слой, где файлы, база и всё остальное (security-фиксы для базового образа, например). Чтобы можно было это всё резко в одну операцию забрать, перенести и развернуть в другом месте поверх того же базового образа, который скачается и установится из registry.

[Сергей Протько]

yokotoka: и опять же, не хотите писать скрипты для бэкапа - не пишите, есть готовые инструменты. Просто подумайте как можно еще это все хэндлить.

[Сергей Протько]

yokotoka: ну ок, но чем этот подход проще при наличии одного монолитного контейнера? Вы все так же можете иметь свой data-volume и все.

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

[Andrey Kobyshev]

Сергей Протько: >вы будете юзать data-volume который всеравно заставит вас писать скрипты для бэкапов
Ну так сбекапить один слой по крону в какой-нибудь Amazon одной строчкой или бекапить базу, потом файлы, потом всё это собрать и залить - как-то немного различается. Ну и разворачивание проще, опять же. Просто настолько ли это плохо, как кажется с первого раза, вот в чём вопрос?

[Andrey Kobyshev]

Сергей Протько: с масштабированием согласен. Но опять же, если проблема встанет - то никто не мешает слить базу, залить её в отдельный убер-инстанс и слинковать кучу инстансов контейнеров с приложухой с ней. Просто проблема масштабирования, как правило, в моём случае не встаёт, т.к. либо рост нагрузки предсказуем, либо её нет (pet-project'ы), либо сразу делаю как рекомендуется в случае ожидаемых всплесков нагрузки. Т.е. мне интересно, если не фейсбуки писать - насколько порочен предложенный мной подход?

[Сергей Протько]

yokotoka: как по мне нет разницы, сбэкапить один слой по крону или два (мы же data-volumes будем бэкапить а не базу там или контейнер). Разворачивание так же простое.

Я не вижу преимуществ. Год назад да, преимущество было ибо docker-compose (или даже fig тогда) были довольно тупыми штуками которые не позволяли делать дела нормально и приходилось писать bash скрипты. Для простых проектов оно так норм, но только в контексте быстрого деплоя.

Сейчас, когда docker-compose стал более-менее функциональным и удобным, намного выгоднее делать все как маленькие части. Скажем захотели вы подключить redis в качестве кэша - не вопрос, ставим рядом контейнер, линкуем и готово. А так надо будет пересобирать контейнер с приложением, базой и прочим. А мы просто хотели быстро замутить счетчик просмотров или еще какую-нибудь хрень.

Что до бэкапов - дата-волумы это хорошая абстракция, нам пофиг что мы бэкапим. Будь то база данных, файлы или еще что. А если нет разницы, при плюсах которые дают разбиение на компоненты, лучше последнее.

[Сергей Протько]

yokotoka: словом для меня главное преимущетсво разделения приложение на контейнеры - меньше бойлерплейта и тупой фигни, я не хочу тратить время на прописывание в Dockerfile кучи bash-скриптов что бы поставить все зависимости. Я хочу сделать docker pull redis и все.

[Andrey Kobyshev]

Сергей Протько: убедительные агрументы. Спасибо за то, что поделились опытом! Попробую поюзать docker-composer в своих кейсах. Особенно насчёт прописывания Dockerfile - хочется тоже от этого уйти.

[Andrey Kobyshev]

Сергей Протько: а как в docker-compose data-volumes указать, какие куда цеплять?

[Сергей Протько]

yokotoka: посмотрите документацию по docker-compose.yml, так же можете глянуть примеры. Там все довольно просто. Еще думаю вам понравится Flocker.

Answer 2

[Andrey Kobyshev]

На SO народ говорит, что особого криминала в этом нет. Если приложухи небольшие, то этот подход - ОК. Проблемы будут когда понадобится скейлить, но и они решаемы. В общем, вроде так можно, если понимать возможные последствия и ограничения.

Answer 3

[Пума Тайланд]

вы путаете виртуализацию приложения с виртуализацией операционной системы
идеология у докера первая, а вы мыслите виртуалками и пытаетесь привить ему подход стандартной виртуализации.

Comments

[Andrey Kobyshev]

Отнюдь! Я мыслю, что приложение (микросервис) в моём случае - это коробка с одним входом и выходом (скажем, веб-аппликация или REST API на 80 порту), где все зависимости и необходимые кишочки лежат в том же контейнере, а не куски приложения, где база - в одном контейнере, статика - в другом, файло - в тертьем, аппликуха - в четвёртом, кеш - в пятом и т.п. На уровне виртуализации операционной системы единица виртуализации - операционная система. Которой выделяется память, ресурсы, на которой может быть уже запущено что-то, т.е. это не виртуализация приложения, а виртуализация оси, а мне этого не надо, мне достаточно подмножества - база, аппликуха, nginx в одном отдельном контейнере, без ssh, диспетчера окон, других полновесных пакетов оси и прочей не нужной в данном случае ереси. В предлагаемом же подходе докер-сообществом единица виртуализации - это какой-то кусок приложения, который в приложение нужно ещё собрать. Я хочу что-то среднее - чтобы единицей виртуализации было приложение-микросервис, который делает что-то независимо от других, чёрный ящик, который не надо программировать на взаимодействие между своими кусками где-то отдельно в конфигах.

Т.е. приложение для меня это набор взаимосвязанного чего-то, что в итоге даёт рабочий черный ящик. Но мне там не нужны своё ядро линукса и все стандартные пакеты операционки кроме тех, которые нужны непосредственно для работы. И не понимаю, почему Docker тут не помощник, ведь он позволяет запустить только нужное и не тянуть с собой лишнее.

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

[Пума Тайланд]

yokotoka: оркестрация да внешняя должна быть,
В вашем случаем просто делаете виртуалку и запускаете где хотите.

[Andrey Kobyshev]

Пума Тайланд: полноценная виртуалка отжирает много лишней памяти на всякое своё внутреннее барахло. Зачем?

[Andrey Kobyshev]

Пума Тайланд: ну и у виртуалок со слоями вообще никак. Скажем, накатить секьюритификс в докере - обновить используемый baseimage. В виртуалках - залезть в каждую.

[Andrey Kobyshev]

Пума Тайланд: всё со мной плохо, да? :)

[Пума Тайланд]

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

[Andrey Kobyshev]

Пума Тайланд: всё равно не убедительно, почему виртуализация приложений с потрохами - это обязательно нужна виртуалка а не докер, который для виртуализации приложений и создан, без side-эффектов полноценных виртуалок типа "не выключайте питание, пока обновления не установятся" или "хакеры по всему миру используют 0-day уязвимость в ssh", которых в докере нет.

[Пума Тайланд]

yokotoka: вообще сайд эффекта не выключайте свет нету , в датацентрах всегда есть свет, а когда нету то все пляшут. нет света это проблема какого то локального человека, а не продакшен системы.
ну не нужен вам ссх выключите . только вчера его повыключал.

[Пума Тайланд]

yokotoka: сделайте несколько виртуалок со всем что надо и настройте оркестрацию и запускайте где угодно

[Andrey Kobyshev]

Пума Тайланд: я вас понял. Если честно, странный немного диалог получился. :) Я про приложения, которые умещаются (и в обозримом будущем до своей смерти моральной будут умещаться) на одном хосте, жрут немного, но требуют нескольких разных ресурсов, типа базы, мемкеша и фреймворка для запуска кода. Понятно, что для фейсбуков надо всё вот это вот, о чём вы говорите. Но не каждый же день отказоустойчивые фейсбуки запускаем, иногда какая-нибудь тулза нужна небольшая "для себя и друзей", для которой оркестрировать виртуалки с разнесёнными отдельно потрохами - оверкилл какой-то. Разве что времени свободного много и каникулы только через 2 месяца закончатся...

[Пума Тайланд]

yokotoka: ну сделайте опенвз если вы памяти зажали.

[Andrey Kobyshev]

Пума Тайланд: а чем лучше он докера в этом кейсе?

[Пума Тайланд]

yokotoka: тем что он контейнер и в него принято как вы любите засовывать все

[Andrey Kobyshev]

Пума Тайланд: опять неубедительно, почему OpenVZ, а не докер. Судя по комментам, докер лучше и удобнее. habrahabr.ru/post/174499
Вам просто не нравится то, что я хочу осквернить докер? :)

[Пума Тайланд]

yokotoka: суть докера один контейнер одна апликация, а вы хотите десять их туда запихать, ну с другой стороны запихайте 10 и живите спокойно , этого же никто не запрещает.

[Andrey Kobyshev]

Пума Тайланд: А смотрите, такой пример как хомпага или бот какой-нибудь, для личного пользования, без ожидания миллионов посещений. Да, там требуется сохранять данные в базу иногда (особенно если юзаешь готовые движки со своими надстройками), иметь redis и код приложения. Почему нельзя в таких случаях считать, что приложение - это вещь, которая состоит из нескольких компонентов? Т.е. под аппликацией понимать не базу или процесс а завершённую совокупность этих процессов, делающих единицу полезной работы. Не вижу проблемы юзать под это докер и запихнуть всё необходимое в один контейнер. Да, конечно, виртуалка - слишком тяжело, openvz - слишком хипстово, докер - не совсем для этого. А есть ли альтернативы для таких применений?

[Пума Тайланд]

yokotoka: ну никто же вам не запрещает сделать .это ,хотите сделайте, для этого как раз и есть опенвз , оно именно для этого и сделано.