И 172.19

У тебя сеть может быть и 172.18

у меня на машинах, на интерфейсах docker0 везде 172.17.0.1

Я правильно понимаю, что на сегодня не существует годного распределенного стораджа для докера?

стораджа?

Да, волюмы хранить

не понял применения

у меня на машинах, на интерфейсах docker0 везде 172.17.0.1

Можно вручную задавать сеть. Привязываться к ip плохо короче

не понял применения

Сварм

Кубернетес

А что не так с свормом и кубером?

Где хранить данные? Нфс?

я не понимаю, какие данные?

Скажи юзкейс

Я правильно понимаю, что на сегодня не существует годного распределенного стораджа для докера?

Он идеологически не нужен же. А так у виртуозы продукт есть

я не понимаю, какие данные?

Стейтфул приложений

Бд всякие

Бд всякие

Так а пример?

Что распределить и как?

Банальный ламп

Ты никогда не знаешь на какой ноде встанет база

Service discovery?

Странно что ты не знаешь какой контейнер запускаешь

Особенно если сварм и кубер

Он не про это вовсе

А про вольюм для бд

А

Как вольюм по физическим нодам за подом носить

Можно вручную задавать сеть. Привязываться к ip плохо короче

docker0 по дефолту всегда 172.17.0.1, изменение подсети необходимо только в особых случаях(при конфликтах) через файл /etc/docker/daemon.json. просто другого решения не вижу, есть конечно но это самое простое

docker network create с нужной маской, а потом подкидываешь в этот нетворк запускаемые контейнеры

Service discovery?

Ну как база свой волюм найдет?

Ну как база свой волюм найдет?

Так а ты сам не знаешь где оно находится? Это не отменяет вопроса зачем в таком случае вообще докер нужен

Так а ты сам не знаешь где оно находится? Это не отменяет вопроса зачем в таком случае вообще докер нужен

Нет ты не знаешь где будет запущен контейнер

При отвале физ ноды что произойдет?

Надо что бы доступ к волюму был

Ну то есть ты вообще про распределенную файловую систему говоришь

Это с докером то не особо и связано

Ты хочешь что-то типа поларфс или гуловской gfs

Нет ты не знаешь где будет запущен контейнер

Ты вполне можешь сказать контейнеру на какой/каких нодах запускаться(селекторы в кубе и иже с ними). А при отвале ноды — репликация наше всё.

Ты вполне можешь сказать контейнеру на какой/каких нодах запускаться(селекторы в кубе и иже с ними). А при отвале ноды — репликация наше всё.

Чем делать репликацию?

Логику как описывать

Чем делать репликацию?

Стандартными механизмами БД, лол

Это на кубер или сварм не очень ложится

Это на кубер или сварм не очень ложится

Почему нет? https://crunchydata.github.io/postgres-operator/

Огонь

Огонь

Ну и в кубах для решения проблем апликух со стейтом, которые ещё и могут в кластеринг есть: https://kubernetes.io/docs/tutorials/stateful-application/basic-stateful-set/

Ну и в кубах для решения проблем апликух со стейтом, которые ещё и могут в кластеринг есть: https://kubernetes.io/docs/tutorials/stateful-application/basic-stateful-set/

A PersistentVolume (PV) is a piece of storage in the cluster that has been provisioned by an administrator. It is a resource in the cluster just like a node is a cluster resource. PVs are volume plugins like Volumes, but have a lifecycle independent of any individual pod that uses the PV. This API object captures the details of the implementation of the storage, be that NFS, iSCSI, or a cloud-provider-specific storage system.

Ответа на мой вопрос там нет)

Требуется внешнее хранилище

Ответа на мой вопрос там нет)

Ну так, а какой у тебя вопрос?

Где взять технологию хранения

Годную

Внешнее хранилище требуется всегда. Выбираешь его на свой вкус. В случае с базой, юзать distributed fs — не очень хорошее решение, если у тебя большая нагрузка.

Сейчас куча стартапов

Но пока ничего ни кто не родил

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

Внешнее хранилище требуется всегда. Выбираешь его на свой вкус. В случае с базой, юзать distributed fs — не очень хорошее решение, если у тебя большая нагрузка.

В обычном случае нутаникс такое хорошо тащит. Но их докер плугин сейчас не рабочий, сапорт мычит

Но пока ничего ни кто не родил

Ceph?

В обычном случае нутаникс такое хорошо тащит. Но их докер плугин сейчас не рабочий, сапорт мычит

Знакомая ситуёвина. Года 2 назад я тоже пробовал подружить вендорский SDS с оркестровкой контейнерной. В итоге плюнул на это, ибо всё очень печально было в плане стыковки.

Ceph?

?

Одна надежда что нутаникс пофиксит

а докер используют для веб -хостинга?

ну чтоб кажждый сайт в отдельном контейнере

ну чтоб кажждый сайт в отдельном контейнере

Почему нет?

опять вопрос по ELK есть докер сервис который логирует в stderr то есть я вижу логи сервиса по docker logs service_name какой стандартный способ завести эти логи в ELK?

В обычном случае нутаникс такое хорошо тащит. Но их докер плугин сейчас не рабочий, сапорт мычит

А обязательно их драйвер? Там же тот же цеф?

А обязательно их драйвер? Там же тот же цеф?

лолчто?

там ndfs

А обязательно их драйвер? Там же тот же цеф?

Цеф? Где)?

ничего общего с цефом

Блять, а с чем я перепутал?

ext4, cassandra и все сильно переписано

не знаю

виртуоза тоже ток с виду похоже на цеф, но не цеф

А, я вообще сильно перепутал, сорри, даже не с сдс ?

В обычном случае нутаникс такое хорошо тащит. Но их докер плугин сейчас не рабочий, сапорт мычит

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

опять вопрос по ELK есть докер сервис который логирует в stderr то есть я вижу логи сервиса по docker logs service_name какой стандартный способ завести эти логи в ELK?

Docker->syslog->logstash/graylog->elastic

Docker->syslog

у докера есть лог драйвера почти для всего

всмысле поднимать сислогсервер?

в грейлог нативно писать можно

через gelf

всмысле поднимать сислогсервер?

https://docs.docker.com/config/containers/logging/syslog/

ну мне самый простой вариант нужен. gelf я уже проверил еще чтото есть? разве gelf этосамое простое? докер же пишет в json файлы в var lib

ну поставь коллектор сайдкар от того же грейлога

ага

и собирай им

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

или в композе тоже такое сделат можно

точно так же

ага вижу.. но ставить отдельный сислог сервер для этого - разве это самое простое решение?

Да, с точки зрения всего стека

ты просто можешь через логгин драйвер писать сразу куда хочешь

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

хм я думал есть чтото самое простое и примитивное - писать логи из контейнера в логстеш. логи, которые УЖЕ есть на хосте в виде json файлов насколько я понимаю этовсе

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

Сапорт подтвердил баг

хм я думал есть чтото самое простое и примитивное - писать логи из контейнера в логстеш. логи, которые УЖЕ есть на хосте в виде json файлов насколько я понимаю этовсе

логстешь? самое простое?