Пума Тайланд: всё равно не убедительно, почему виртуализация приложений с потрохами - это обязательно нужна виртуалка а не докер, который для виртуализации приложений и создан, без side-эффектов полноценных виртуалок типа "не выключайте питание, пока обновления не установятся" или "хакеры по всему миру используют 0-day уязвимость в ssh", которых в докере нет.
Пума Тайланд: ну и у виртуалок со слоями вообще никак. Скажем, накатить секьюритификс в докере - обновить используемый baseimage. В виртуалках - залезть в каждую.
Отнюдь! Я мыслю, что приложение (микросервис) в моём случае - это коробка с одним входом и выходом (скажем, веб-аппликация или REST API на 80 порту), где все зависимости и необходимые кишочки лежат в том же контейнере, а не куски приложения, где база - в одном контейнере, статика - в другом, файло - в тертьем, аппликуха - в четвёртом, кеш - в пятом и т.п. На уровне виртуализации операционной системы единица виртуализации - операционная система. Которой выделяется память, ресурсы, на которой может быть уже запущено что-то, т.е. это не виртуализация приложения, а виртуализация оси, а мне этого не надо, мне достаточно подмножества - база, аппликуха, nginx в одном отдельном контейнере, без ssh, диспетчера окон, других полновесных пакетов оси и прочей не нужной в данном случае ереси. В предлагаемом же подходе докер-сообществом единица виртуализации - это какой-то кусок приложения, который в приложение нужно ещё собрать. Я хочу что-то среднее - чтобы единицей виртуализации было приложение-микросервис, который делает что-то независимо от других, чёрный ящик, который не надо программировать на взаимодействие между своими кусками где-то отдельно в конфигах.
Т.е. приложение для меня это набор взаимосвязанного чего-то, что в итоге даёт рабочий черный ящик. Но мне там не нужны своё ядро линукса и все стандартные пакеты операционки кроме тех, которые нужны непосредственно для работы. И не понимаю, почему Docker тут не помощник, ведь он позволяет запустить только нужное и не тянуть с собой лишнее.
Может кому-то бывает нужна постгря на арче а джава на убунте, тут да, только по отдельным контейнерам распихивать и линковать, но такое же не каждый день нужно.
Сергей Протько: убедительные агрументы. Спасибо за то, что поделились опытом! Попробую поюзать docker-composer в своих кейсах. Особенно насчёт прописывания Dockerfile - хочется тоже от этого уйти.
Сергей Протько: с масштабированием согласен. Но опять же, если проблема встанет - то никто не мешает слить базу, залить её в отдельный убер-инстанс и слинковать кучу инстансов контейнеров с приложухой с ней. Просто проблема масштабирования, как правило, в моём случае не встаёт, т.к. либо рост нагрузки предсказуем, либо её нет (pet-project'ы), либо сразу делаю как рекомендуется в случае ожидаемых всплесков нагрузки. Т.е. мне интересно, если не фейсбуки писать - насколько порочен предложенный мной подход?
Сергей Протько: >вы будете юзать data-volume который всеравно заставит вас писать скрипты для бэкапов
Ну так сбекапить один слой по крону в какой-нибудь Amazon одной строчкой или бекапить базу, потом файлы, потом всё это собрать и залить - как-то немного различается. Ну и разворачивание проще, опять же. Просто настолько ли это плохо, как кажется с первого раза, вот в чём вопрос?
Сергей Протько: т.е. всё, что происходит после настройки базового образа попадает в rw-слой, где файлы, база и всё остальное (security-фиксы для базового образа, например). Чтобы можно было это всё резко в одну операцию забрать, перенести и развернуть в другом месте поверх того же базового образа, который скачается и установится из registry.
Сергей Протько: data-volume же. Я же написал, что делаем image, где всё необходимое для аппликухи, на основе этого image создаём пустой data-volume, в который будет всё писаться. И ничего не порушится. У docker в доках это сейчас описывается как рекомендуемый подход.
Сергей Протько: если помимо СУБД у вас различные файлы, которые приложение создаёт в процессе жизни, uploads всякие и т.п., которые хочется бекапить вместе с базой и разворачивать это же удобно? Просто задолбался скрипты писать бекапа и восстановления, когда база - отдельно, файлы - отдельно. Хотелось бы всё это в одном понятном слое хранить, который можно легко забрать/перенести.
Имею в виду, что часто база данных - неотъемлемая часть приложения. Скажем, сайтик какой-нибудь или небольшой сервис. Зачем выносить базу в отдельный инстанс (да ещё класть в несколько несвязанных между собой схем в одну базу), если "приложение" в самодостаточно со всеми потрохами и требуется только его удобно при необходимости перенести в другое место?
Спасибо за ответ! Да, насчёт ада в Dockerfile, пожалуй соглашусь. Но тут же основная идея в том, чтобы оперировать приложением как отдельной единицей. Скачал образ, подцепил data-volume и всё заработало. Насколько удобно с тем же docker-compose бекапить и восстанавливать все зависимости в новом окружении? Где об этом можно подробнее узнать?
DevMan: ну вдруг захочется человеку свежих ощущений? :) Go там, какой-нибудь пощупать повод будет, или что там сейчас модно.
А так да - потоковый парсер или найти из-за чего лимит по памяти не проставляется в конфиге.
