Речь не про то что незасовывание в контейнер спасет стейт или поможет перезжать
Естественно, при краше вы потеряете данные в обоих случаях
Речь идет о том что не надо пытаться использовать технологии, которые заранее говорят, что они не сильно заботятся о времени и стабильности жизни контейнера ( и даже более того, убивают и поднимают новые, когда захотят), для случаев, когда вам нужно долгое время жизни и стабильность контейнера
Тык я про это в комменте ниже и говорю)
не кладите данные в контейнер
целевое место зависит от данных, которые вы хотите юзать
если речь про настройки приложений — юзайте config-server (consul, spring-cloud-config-server и иже с ними)
если речь про СУБД — выносите на отдельные хосты, вне экосистемы докера
и это же написано в оригинальном комменте — не надо засовывать их в докер или даже на хосты с докером
а приложениями только стучите в них
обновляются без обратной совместимости?
ну ок, мы деплоимся по blue-green, уже было такое что так обновлялись месяц с версии еластика 1.4 на 5.2.2 — на таком скачке совместимость вобще раздолбана ко всем чертям
естественно из-за blue-green нашли проблему раньше чем положили рабочую систему, доработались, поставились
whats problem?
баги из-за которого рестартует хост?
ну ладно, у меня приложуха живет не меньше ( иногда и больше) чем в трех контейнерах на трех разных хостах в трех разным датацентрах, имея в пуле еще десяток свободных машинок, один инстанс переедет, потом вернется ( когда и тот упадет )
неприятно, ссыплет в логи, но фатальным трудно назвать
опять же, это должно пройти через blue-green
почему чувакам было так больно от рестарта машинки?
отчего они вобще ходили по хостам и руками поднимали контейнеры?
непонятно
еще раз, все это пилится не для того чтобы гарантировать аптаймы по несколько лет — все это пилится для того чтобы легко переживать частые падения
ну во первых
1) Проблема в том что никто не использует докер просто так
всего его оркестрируют ( это mesos, kuber и прочие) — а это предполагает что ваши приложения готовы уехать с одного хост на другой в любой момент времени и как угодно часто, просто потому что оркестратор так решил ( перераспределяет ли ресурсы, упал ли хост — не важно), соответственно все ваши данные должны скидываться не просто на диск, а в какое-то облачное/сетевое хранилище, что добавляет немало проблем.
2) стейт это вобще говоря не только про данные на харде, но и про данные в оперативке, которые бывают почему-то важны
любят некоторые запихивать j2ee сервак в докер — это вот к примеру точно антипаттерн засовывания толстого приложения со своим рабочим стейтом, которое не может просто так взять и быстро переехать с хоста на хост
Миграцию контейнера со стейтом по слухам дорабатывают в докере — к примеру вот https://criu.org/Docker
This feature is available in the experimental mode for Docker
где-то видел и интервью автора по поводу работы с командой докера в этом направлении
Во-первых, смысл контейнеров — в экономии ресурсов, благодаря запуску множества контейнеров на одном (большом) хосте.
facepalm
в 2017 году, имея все средства оркестрации и масштабирования, мы пытаемся запускать все на одной большой машинке
лучше было только когда в одном банке на собесе рассказывали, как они через sh запускают руками jar с сервисом на embedded jetty, руками прописывают его хост и порт в балансер, а потом говорят про это «У нас микросервисы, все стильно модно молодежно»
Статья выглядит так, будто чуваки сделали ВСЕ что нельзя делать с докером, кубером и так далее (ставить приложения со стейтом в докер, ставить туда же в докер базы данных, запускать меньше трех инстансов), набрали много боли, а потом написали гневную статью и в выводах переписали общеизвестные истины, написанные чуть ли не в каждой статье про оркестрацию микросервисов
Естественно, при краше вы потеряете данные в обоих случаях
Речь идет о том что не надо пытаться использовать технологии, которые заранее говорят, что они не сильно заботятся о времени и стабильности жизни контейнера ( и даже более того, убивают и поднимают новые, когда захотят), для случаев, когда вам нужно долгое время жизни и стабильность контейнера
не кладите данные в контейнер
целевое место зависит от данных, которые вы хотите юзать
если речь про настройки приложений — юзайте config-server (consul, spring-cloud-config-server и иже с ними)
если речь про СУБД — выносите на отдельные хосты, вне экосистемы докера
и это же написано в оригинальном комменте — не надо засовывать их в докер или даже на хосты с докером
а приложениями только стучите в них
обновляются без обратной совместимости?
ну ок, мы деплоимся по blue-green, уже было такое что так обновлялись месяц с версии еластика 1.4 на 5.2.2 — на таком скачке совместимость вобще раздолбана ко всем чертям
естественно из-за blue-green нашли проблему раньше чем положили рабочую систему, доработались, поставились
whats problem?
баги из-за которого рестартует хост?
ну ладно, у меня приложуха живет не меньше ( иногда и больше) чем в трех контейнерах на трех разных хостах в трех разным датацентрах, имея в пуле еще десяток свободных машинок, один инстанс переедет, потом вернется ( когда и тот упадет )
неприятно, ссыплет в логи, но фатальным трудно назвать
опять же, это должно пройти через blue-green
почему чувакам было так больно от рестарта машинки?
отчего они вобще ходили по хостам и руками поднимали контейнеры?
непонятно
еще раз, все это пилится не для того чтобы гарантировать аптаймы по несколько лет — все это пилится для того чтобы легко переживать частые падения
1) Проблема в том что никто не использует докер просто так
всего его оркестрируют ( это mesos, kuber и прочие) — а это предполагает что ваши приложения готовы уехать с одного хост на другой в любой момент времени и как угодно часто, просто потому что оркестратор так решил ( перераспределяет ли ресурсы, упал ли хост — не важно), соответственно все ваши данные должны скидываться не просто на диск, а в какое-то облачное/сетевое хранилище, что добавляет немало проблем.
2) стейт это вобще говоря не только про данные на харде, но и про данные в оперативке, которые бывают почему-то важны
любят некоторые запихивать j2ee сервак в докер — это вот к примеру точно антипаттерн засовывания толстого приложения со своим рабочим стейтом, которое не может просто так взять и быстро переехать с хоста на хост
Миграцию контейнера со стейтом по слухам дорабатывают в докере — к примеру вот https://criu.org/Docker
где-то видел и интервью автора по поводу работы с командой докера в этом направлении
facepalm
в 2017 году, имея все средства оркестрации и масштабирования, мы пытаемся запускать все на одной большой машинке
лучше было только когда в одном банке на собесе рассказывали, как они через sh запускают руками jar с сервисом на embedded jetty, руками прописывают его хост и порт в балансер, а потом говорят про это «У нас микросервисы, все стильно модно молодежно»