Т.е. в каждом контейнере будет свой pm2 крутиться?

Да

Он будет контролировать твою Апу на ноде

Понял

Спасиб

есть надстойки для автоматизации по коду?

Consul?

привет, подскажите плс есть докер, в нем сервис с апи. при запуске контейнера выставлено -p 127.0.0.1:8545:8545 если дернуть апи курлом из контейнера - получаю ответ. если из вне curl: (56) Failure when receiving data from the peer что могло бы быть?

Expose есть?

нет, не прописано в параметрах нужно? с тем же портом, что у сервиса открыт?

Пробуй)

попробовал. легче не стало

Docker ps

Docker inspect dpckernan

ps - мой контейнер inspect https://gist.github.com/alexadept/7aa9ff6784ba93f0d993a09cffc0be03

Curl 172.17.0.1:port

Сост машины

Хоста*

couldn't connect to host на 172.17.42.1 (докер интерфес хоста) - то же самое если указать не -p 127.0.0.1:8545:8545 а 8545:8545 то на 172.17.42.1 запрос отрабатывает. остальные - ничего не меняется это уже не плохо. правда нельзя сервис наружу выставлять

о чем это должно было мне сказать?)

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

Сорри. Спать

Выкинуть в пастедин

А дальше видно будет

в любом случае спасибо

частично проблема решена

всем привет

кто-нибудь dc/os использует?

кто-нибудь dc/os использует?

I am

Господа, объясните где я тупой, есть строчка в /etc/docker/daemon.json, но в лога он говорит что не понимает этот параметр

the following directives don't match any configuration option: data-root

docker.io 1.12.6-0 если что

docker.io 1.12.6-0 если что

https://stackoverflow.com/questions/24309526/how-to-change-the-docker-image-installation-directory

вообще версия прилично древняя у вас

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

То есть мне нужно, чтобы второй контейнер внёс изменения в первый и сделал это только один раз при деплое

Или лучше просто сделать файл-заглушку, который не даст инициализировать бд больше одного раза и забить?)

вообще есть depends_on

но build в компоузе это просто как дополнительная фича, не стоит использовать ее вмесо ci

Как вариант билдить имаджи отдельно, а в компоузе только их указывать и запускать с директивой depends_on

вообще есть depends_on

он же на запуск вроде влияет, а не деплой

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

Но это не точно

Depends_on не будет ждать пока стартанет база например

Нужно свой велосипед делать

ну старта базы да, только контейнера самого

Всем привет Есть задача навесить на сворм мониторинг живучести контейнеров, плюс аггрегатор логов

Под мониторинг пробовал делать по https://habrahabr.ru/company/southbridge/blog/327670/ вот этому мануалу, то есть на связке cAdvisor, InfluxDB и Grafana

Под логи насколько мне известно популярностью пользуется стек Elasticsearch, Logstash и Kibana, быстрое гугление привело на статью (пока сам ещё не поднимал) https://habrahabr.ru/post/282866/

Вопрос Как, собственно, лучше делать? Под мониторинг - одно, под логи - друогое? Или есть какой-нибудь стек, объединяющий в себе это всё?

ERROR: S client not available

для инфо - сворм ~8 машин, ~30 сервисов

Prometheus + cadvisor + grafana для мониторинга контейнеров и elk/efk для логов

Мониторинг и логи все таки разные вещи

Принято, спасибо Ещё кто-нибудь что-нибудь посоветует? Может комментарии?

Вопрос Как, собственно, лучше делать? Под мониторинг - одно, под логи - друогое? Или есть какой-нибудь стек, объединяющий в себе это всё?

elk 5 умеет мониторинг, но вот как это будет работать на больших нагрузках хз

@DenisIzmaylov @hitmaker ACHTUNG, SPAM!!!11

Коллеги, доброго утра! Хочу сделать интеграционный тест с помощью докера. Простейший случай: в одном контейнере JSON API сервер, в другом контейнере - JSON API клиент, в третьем контейнере PostgreSQL (для сервера). Далее, когда я правлю код либо сервера либо клиента и нажимаю ctrl-S, хочу чтоб не только юнит-тесты запустились, но и протестировалась интеграция между сервером и клиентом. В интернетах какие-то бородатые туториалы про docker-compose v2. Как я понимаю, современный подход - это swarm. Резюмируя, нужны: 1) интеграционные тесты в процессе редактирования кода 2) ну и CD pipeline в итоге Кодовая база у меня - руби, если это интересно. Кто-то решал уже эту задачу?

Как я понял, надо сделать отдельный контейнер с тестовой логикой. Так?

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

яб накостылял)

Конфигурить сварм ради 3 контейнеров - мощно ??

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

у меня IoT проект с 1 сервером и n клиентами. Флоту клиентов swarm уже прописан...

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

и CI и разработка, но для начала - да, чтобы внося изменения в код знать что вся система end-to-end не разваливается (юнит-тесты это, естественно, не покажут)

ну вот для начала: юнит-тесты сервера лежат в репозитории с сервером. юнит-тесты клиента лежат в репозитории клиента. а куда положить интеграционные? объединить репозитории? сделать третью репу с субмодулями и туда положить? оба репозитория контролирую я.

пожалуй, учитывая что обе репы - мои, проще объединить

по swarm + CI - у кого как этот процесс сейчас организован? или ни у кого никак? ?

gitlab + gitlab-ci

раннер дергает shell скрипт которому передаются все параметры и переменные и он творит всю магию

Gitlab CI: сборка проекта, докер образ, пуш образа, ssh exec к заказчику -> docker stack deploy

а jenkins чем хуже? я просто ни то ни то еще не настраивал, хочу понять на что время потратить разобраться

тем что у гитлаба ci из коробки

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

ну и грех не пользоваться доступным и бесплатным CI

ну и да, если гитлаб как репозиторий это удобно юзать нативный ci