а что не работает?

а что не работает?

байты не бегают

ща, надо передохнуть и победю

А что за userland-proxy?

{ "iptables": false, "userland-proxy": true, ... }

Советуют ставить для xenia чтобы работал ufw

Господа, объясните нубасу, пожалуйста, как заставить бежать sensu в контейнере centos7? Что-то я грущу, потому что service и systemctl не алё по причине малых прав, а запуск с /sbin/init не приводит к ожидаемому запуску сервисов.

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

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

Это совсем неправильно.

Это совсем неправильно.

Для мониторинга как раз нормально

привет, как таймзону поставить через docker-compose для https://hub.docker.com/_/mariadb/

там вообще системное используется в настройка марии

по ссылке раздел есть Using a custom MySQL configuration file

а контейнер берет время хоста?

скорее UTC

docker exec -it <ID> date

спасибо

А что за userland-proxy? { "iptables": false, "userland-proxy": true, ... } Советуют ставить для xenia чтобы работал ufw

Вроде обычно хватало iptables: false

Я пока обычно заходил в контейнер через я ssh. ssh -> docker exec - а есть какие- нить удобные способы сделать это удобнее?

Я пока обычно заходил в контейнер через я ssh. ssh -> docker exec - а есть какие- нить удобные способы сделать это удобнее?

вожно выставить docker socket через tcp, настроить сертификаты и делать со своей машины docker exec с указанием сокета удаленного сервера

понял спасибо

Подскажите, есть ли устоявшиеся практики по переносу контейнеров на другой хост? Понятно что можно просто сделать коммит, а потом save/load, а как быть с volumes?

Подскажите, есть ли устоявшиеся практики по переносу контейнеров на другой хост? Понятно что можно просто сделать коммит, а потом save/load, а как быть с volumes?

backup?

а нет, стоп

кажется я не шарю

а что там с volumes когда коммит делаешь?

Подскажите, есть ли устоявшиеся практики по переносу контейнеров на другой хост? Понятно что можно просто сделать коммит, а потом save/load, а как быть с volumes?

vloumes не сохраняются при бекапе контейнера?

Подскажите, есть ли устоявшиеся практики по переносу контейнеров на другой хост? Понятно что можно просто сделать коммит, а потом save/load, а как быть с volumes?

вот вроде хорошее решение https://docs.docker.com/engine/tutorials/dockervolumes/#backup-restore-or-migrate-data-volumes

А вы правда храните данные внутри контейнера?

Вы называете использовангие volumes хранением внутри контейнера?

Подскажите, мб кто-то сталкивался - у меня проблема как в этом посте https://stackoverflow.com/questions/44689202/springboot-client-unable-register-with-eureka-using-docker-container-id. половина контейнеров регаются на эврике по id контейнера и до них могу достучаться, а те что регаются по странному адресу недоступны. Решений чот быстро не нагуглил

А вы правда храните данные внутри контейнера?

формально volumes это не внутри контейнера

А вы правда храните данные внутри контейнера?

все volumes хранятся не изолированно

так доступ к ним всё равно же только у одного контейнера, если не указано иное и сам волум привязан к ящику. Не проще -v и хранить снаружи?

Или я ошибаюсь?

человек пока не столкнулся с тем, что нужно будет доставлять это на несколько нод)

так доступ к ним всё равно же только у одного контейнера, если не указано иное и сам волум привязан к ящику. Не проще -v и хранить снаружи?

Волумы можно шарить между контейнерами и они тоже в каком-то виде хранятся на хосте

человек пока не столкнулся с тем, что нужно будет доставлять это на несколько нод)

Это больше похоже на плохую практику) Мне просто интересно, зачем?

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

В случае переразвертывания на другой ноде?

в случае необходимости общих волюмов

Мне казалось нормальная практика - это staleless, все-таки. Базы данных так не пошаришь.

так я и не о бд

условный сторадж или логи

сами то аппы ессессно стейтлес должны быть

Если у вас кубер, уж можно расщедрится на какой-то elk или хотя бы центральный syslog

так елк и есть

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

Ну так это локально примонтированные файлы - все равно такие же запросы по сетке, только еще и с оверхедом и ненадежностью распределенных файловых систем

Оно же не на магии работает.

У меня речь именно о БД, надо монгу перенести, соответвенно данные в volume на хочет

*хосте

бд в контейнере держать, ну такое

разве что тестовую, но там и переносить ничего не нужно было бы

бд в контейнере держать, ну такое

Тоже вроде нормальная практика)

оО

ERROR: S client not available

Разве что volume использовать немного странная идея

Ну, зачем то же нужны контейнеры со всеми базами

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

Ну, много кто думает по другому. Например ребята из core os, разработчики кубера и другое. Кстати, а почему нет?

кластеризировать сложно

У меня вот кластеризация в конейнерах вроде нормально прошла (правда, для redis). Но традиционные sql базы в целом сложно кластеризировать.

ну вот я об sql и имел ввиду

А не подскажите, почему именно в docker их сложно кластеризировать?

Я просто к вопросу их кластеризации подходил только в духе "ой, что-то все очень сложно, слава богу пока не нужно".

Ну так это локально примонтированные файлы - все равно такие же запросы по сетке, только еще и с оверхедом и ненадежностью распределенных файловых систем

не все примонтированные директории - это запросы по сети, есть же hostPath. Для логов самое то.

не все примонтированные директории - это запросы по сети, есть же hostPath. Для логов самое то.

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

А есть смысл синхронизировать volume c логами?

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

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

Я бы сказал, что это изъян в архитектуре и так быть не должно, но кто я такой)

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

С какими файлами? Почему они не в хеше, базе данных или еще чем-то?

для чего в том же кубере driver nfs, cepf и gluster для persistent volume в частности с поддержкой мода RWX

С какими файлами? Почему они не в хеше, базе данных или еще чем-то?

"еще чем то" и есть распределенно хранилище.

вы мыслите в масштабах одной ноды

Я бы сказал, что это изъян в архитектуре и так быть не должно, но кто я такой)

У нас сейчас как раз архитектура сбора логов только зарождается, сейчас мы логи в директорию на хосте пишем, а оттуда logstash->relk. Может расскажешь в чем изъян?)

Вопрос, в swarm можно создать сервис который будет ссылаться на внешний ресурс, по аналогии с кубером когда ендпойнт http:/database-pod/ будет ссылаться на внешний хост бд изнутри остальных контейнеров?

или только добавлять днс запись при поднятии сервисов?

У нас сейчас как раз архитектура сбора логов только зарождается, сейчас мы логи в директорию на хосте пишем, а оттуда logstash->relk. Может расскажешь в чем изъян?)

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

"еще чем то" и есть распределенно хранилище.

Распредленное хранилище чего? Ну, вот есть отдельные сервисы для картинок, которые сами работают. Мне просто интересен тип файлов.

различные файлы, условно - файлы юзеров

которые изменяемы при этом

это не какая нибудь статика для сайтика

У меня речь именно о БД, надо монгу перенести, соответвенно данные в volume на хочет

Разобрался?