Привет, ни у кого не случалось в swarm'е на 17.09.0-ce такое, что контейнеры неправильно резолвят IP при обращении к сервису по имени? Проявилось спонтанно, docker inspect <container_id> показывает один IP, при обращении к нему из этой же сети по имени IP другой (к тому же статический и не меняется если грохать контейнер).

К вопросу о статике - я статику собираю прям в контейнер с nginx, как выше советовали.

Чтобы на остальные сервисы не влияло, вперед ставлю другой nginx который форвардит запросы куда нужно.

Отвечая на свой вопрос - нужно указывать в стримах nginx явное указание резолвера docker: resolver 127.0.0.11 valid=30s;

Всем привет. Столкнулся с такой проблемой. Контенер не стартует после перезагрузки виртуалки docker run -d —restart=always -p 6379:6379 -v /vagrant_data/redis/conf/redis.conf:/usr/local/etc/redis/redis.conf —name redis redis:alpine redis-server /usr/local/etc/redis/redis.conf Но если убрать из строки запуска комманду redis-server /usr/local/etc/redis/redis.conf, то все работает как надо. docker run -d —restart=always -p 6379:6379 -v /vagrant_data/redis/conf/redis.conf:/usr/local/etc/redis/redis.conf —name redis redis:alpine

пользуйся ``` для выделения блоков кода...

пользуйся ``` для выделения блоков кода...

Спасибо, исправился

docker run -d —restart=always -p 6379:6379 -v /vagrant_data/redis/conf/redis.conf:/usr/local/etc/redis/redis.conf —name redis redis:alpine redis-server /usr/local/etc/redis/redis.conf

ы)

насколько я помню, если есть аргументы (содержащие дефисы?) их нужно отделять с помощью --: docker run -d \ --restart=always \ -p 6379:6379 \ -v /xxx/redis.conf:/xxx/redis.conf \ --name redis \ redis:alpine \ -- redis-server /usr/local/etc/redis/redis.conf

насколько я помню, если есть аргументы (содержащие дефисы?) их нужно отделять с помощью --: docker run -d \ --restart=always \ -p 6379:6379 \ -v /xxx/redis.conf:/xxx/redis.conf \ --name redis \ redis:alpine \ -- redis-server /usr/local/etc/redis/redis.conf

так работает. в моем случае только ругается на отсутствие конфига. уже внутри контейнера

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

не работает. При перезапуске виртуалки также не стартует, только вручную

ну так значит конфиг кривой

нужно курить логи

Всем привет. Столкнулся с такой проблемой. Контенер не стартует после перезагрузки виртуалки docker run -d —restart=always -p 6379:6379 -v /vagrant_data/redis/conf/redis.conf:/usr/local/etc/redis/redis.conf —name redis redis:alpine redis-server /usr/local/etc/redis/redis.conf Но если убрать из строки запуска комманду redis-server /usr/local/etc/redis/redis.conf, то все работает как надо. docker run -d —restart=always -p 6379:6379 -v /vagrant_data/redis/conf/redis.conf:/usr/local/etc/redis/redis.conf —name redis redis:alpine

судя из этого ты когда подсовываешь свой конфиг по стандартому пути редиса, но не задаешь никакой command, то все работает ок?

да. если не передовать комманду то все ок

так в чем проблема так работать с контейнером?)

проблема в ручном запуске контенера. нужно vagrant up и вперед

а что контейнер нельзя запускать не указывая command?

ну можно не комманду указывать, а аргумент - путь до конфига. но результат тотже

docker run -d —restart=always -p 6379:6379 -v /vagrant_data/redis/conf/redis.conf:/etc/redis/redis.conf —name redis redis:alpine

вот так сделать вообще никак?

тогда никакие пути указывать ненадо аргументами

сейчас попробую. в alpine нет /etc/redis/ вроде как там только можно редис серверу аргументом передать конфиг. или я не понял где дефолтный конфиг лежит.

а да, действительно дефолтно он там не лежит

в моих образах энтрипойнт на него указывает

/usr/bin/redis-server /etc/redis/redis.conf

не работает. При перезапуске виртуалки также не стартует, только вручную

во-первых не стоит использовать способ с ключом -d, используй systemctl

Используем systemd для запуска docker-контейнеров [Unit] Description=My Awesome Service Requires=docker.service After=docker.service [Service] Restart=always RestartSec=3 ExecStartPre=/bin/sh -c "/usr/bin/docker rm -f my-awesome-service 2> /dev/null || /bin/true" ExecStart=/usr/bin/docker run --rm -a STDIN -a STDOUT -a STDERR --env-file=/etc/default/my-awesome-service -p 0.0.0.0:3301:3301 -v /etc/project/service:/etc/wallarm -v /var/lib/blacklist:/var/lib/blacklist -v /var/log/project/service:/var/log/wallarm --name my-awesome-service wallarm-dkr.jfrog.io/my-awesome-service:v0.17.0.0 ExecStop=/usr/bin/docker stop my-awesome-service [Install] WantedBy=multi-user.target #systemd #docker

и чем же -d плох то?

если докер стартует через системд, то какая разница как он будет ранить контейнеры?

м... всем? он просто в бекграунде контейнер запускает, тогда как systemd будет следить за его состоянием, перезапуском, собирать логи

docker run -d —restart=always -p 6379:6379 -v /vagrant_data/redis/conf/redis.conf:/etc/redis/redis.conf —name redis redis:alpine

в общем конфиг так не видит

м... всем? он просто в бекграунде контейнер запускает, тогда как systemd будет следить за его состоянием, перезапуском, собирать логи

а докер не следит да?

параметр restart always тогда как работает?

в alpine entrypoint ` #!/bin/sh set -e # first arg is -f or --some-option # or first arg is something.conf if [ "${1#-}" != "$1" ] || [ "${1%.conf}" != "$1" ]; then set — redis-server "$@" fi # allow the container to be started with --user if [ "$1" = 'redis-server' -a "$(id -u)" = '0' ]; then chown -R redis . exec su-exec redis "$0" "$@" fi exec "$@" `

а запускаешь ты его как при загрузке виртуалки?

кроном?

не вижу где тут дефолтный конфиг

а запускаешь ты его как при загрузке виртуалки?

ты докер вообще на серваках вертел?)

Докер демон запускается через системд при старте виртуалки

после этого он по полиси ранит все контейнеры

которые нужно ранить

ну в убунту вроде системд он наверное и докер стартует

да везде уже по дефолту системд старутет докер

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

докер куда логи пишет?

м... всем? он просто в бекграунде контейнер запускает, тогда как systemd будет следить за его состоянием, перезапуском, собирать логи

Если у меня 200 сервисов вертится на хосте мне на каждый писать конфиг под системд чтобы они при старте поднимался?)

докер куда логи пишет?

через docker logs смотри, а так /var/lib/docker/container/xxxxx/ для каждого контейнера

Ребята, что используете для nginx + letsencrypt?

Если у меня 200 сервисов вертится на хосте мне на каждый писать конфиг под системд чтобы они при старте поднимался?)

если у тебя 200 сервисов крутится на хосте тебе уже пора ехать в куб. иначе как не крути это уже заёба

ты докер вообще на серваках вертел?)

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

да даже для 10-20 уже неприкольно расписывать системд сервис, когда это нативный функционал докера который передается одним параметром

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

городить свой велосипед просто потому, что можно?)

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

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

Где можно посмотреть production ready docker stack compose файлы для обучения?

компоуз подходит только для маленьких "продакшенов" уровня одного хоста

Друзья, если есть кто из московского ланита - вашу маршрутку эвакуируют от м Рижская

Ребята, что используете для nginx + letsencrypt?

certbot

через docker logs смотри, а так /var/lib/docker/container/xxxxx/ для каждого контейнера

в логах контейнера все норм. если чтото и падает то до контейнера не доходит дело

проблема только после рестарта виртуалки?

Ребята, что используете для nginx + letsencrypt?

Вкратце 2 вольюма - для ключей и для http верификации.

Спрошу еще раз. Подскажите пожалуйста в docker swarm. Как можно сделать что запросы outbound (в интернет), шли с worker ip адреса если даже запрос идет с manager? Я с сетями на вы)

проблема только после рестарта виртуалки?

ну да

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

в любом случае тут не проблема докера, а с вм или вагрантом что-то

Подскажите, есть named volume от одного проекта, хочу заюзать его внутри docker-compose другого проекта. Пробовал делать через volumes: в корне но он создаёт новый. Что впринципе и понятно. В доке не нашёл нужной опции. Это возможно ?

Нужно переименовать, docker compose называет вольюмы project_volumename

Переименовать не очень просто, т.к. нативной команды нет.

https://github.com/moby/moby/issues/31154

Чтобы на остальные сервисы не влияло, вперед ставлю другой nginx который форвардит запросы куда нужно.

1.И получается на каждый сервис по одному nginx ? 2.Т.е. у меня сейчас 4 сервиса = 5 nginx контейнеров в итоге. Так все делают или есть еще способы ? 3. А если 2 сервиса API а остальные 2 это админки, то в любом случае нужно все 4 + 1 поднимать ?

Нет, я имел в виду 1 прокся + 1 статика.

Если не хочешь чтобы при обновлении статики остальные дергались

Т.е. для статики будет выделенный nginx, остальное как раньше будет.

Собственно nginx нужен для 1) SSL 2) Статики 3) Раскидывать запросы по остальным сервисам, возможно с балансировкой нагрузки.

Можно функцию 2 вынести на отдельный контейнер.

Я не совсем понял, сейчас app-ы свою статику сами отдают?

Тогда в этом случае, нужно чтобы статика из app1 и app2 монтировалась в volume, чтобы nginx знал, откуда тащить данные при сборке.

Статика она на то и статика, что не меняется. При сборке image-ов собирай всю статику в один контейнер.

Статика она на то и статика, что не меняется. При сборке image-ов собирай всю статику в один контейнер.

js, css тоже статика. Она внутри приложения находится же. Не будет же приложение отдавать их. Я вот эту задачу пытаюсь решить.

И потом изображения могут заливаться с App2 или App1 и тогда их нужно куда-то класть. Без volume не обойтись короче.

Ну если заливать, то да. А js/css можно при сборке контейнера брать. Обновил приложение - пересобрал контейнер.

Вот в этом случае проблема в том, что каждое приложение в gitlab создаётся по своему пайплайну. И получается, что в каждый пайплайн придётся добавить еще одну джобу, которая будет лезть в репозиторий каждого приложения чтобы достать оттуда данные для сборки нового контейнера nginx и пушить его на прод. Я просто незнаю насколько это будет правильно. Нужно как-то это все запихать в текущий workflow

В моем случае там 2 репо с админками.

А хранить все эти файлы в подключаемом volume для nginx плохая идея ? Там какой-то оверхед будет на доступ к ФС ?

Минимальный, не стоит даже на это обращать внимания

Идея норм если нужно разделяемые данные между контейнерами

Ток масштабировать не удобно

Мне кажется если нужны совсем разделямые данные, то лучше заюзать распределенные фс, все-таки волюмы не под это проектировались) А оверхед на фс минимальный в докере, вот замечательная pdf-ка, никто, кстати обновленную не встречал? https://arxiv.org/pdf/1709.10140.pdf

Идея норм если нужно разделяемые данные между контейнерами

А как насчёт варианта c использованием multi-stage билдов ?: На проде для nginx Dockerfile прописать: FROM app1 AS data1 FROM app2 AS data2 FROM nginx COPY --from=data1 /usr/src/app/public /data/ COPY --from=data2 /usr/src/app/public /data/ И получается что волюмы будут использоваться только для загружаемой статики из app1 или app2