Можно плиз развернутый ответ. Я не понимаю, как location поможет решить проблему, озвученную выше.

обычный try_files

Есть какое-то общее решение задачи, отдавать контейнеру nginx статику js, css, которая находится внутри контейнера с php приложением ?

ИМХО, нужно билдить image nginx со статикой. Если захочется использовать swarm, то там маунтить volumes будет проблема

FROM nginx as production COPY --from=registry:4555/production:latest /app/public /app/public/

Довольно быстро и не нужно париться с volumes

Ну вот мой образ для статики к скрину выше

ИМХО, нужно билдить image nginx со статикой. Если захочется использовать swarm, то там маунтить volumes будет проблема

Тогда в этом случае, другие приложения использующие nginx будут лежать. Пока апдейтится сервис. Это неприемлимо в моем случае.

Нашёл решение. Спасибо за внимание. docker service update --mount-add type=volume,source=admin-volume,target=/usr/src/admin-app

Тогда в этом случае, другие приложения использующие nginx будут лежать. Пока апдейтится сервис. Это неприемлимо в моем случае.

nginx-proxy / traefik?

Тогда в этом случае, другие приложения использующие nginx будут лежать. Пока апдейтится сервис. Это неприемлимо в моем случае.

🤔 можно же одновременно траффик перенаправить. поднять новую версию и потом на новую версию перенаправить. Пока правда не делал такое)

nginx-proxy / traefik?

Сорри, не слышал про них. Буду изучать вопрос.

nginx-proxy / traefik?

traefik для меня к сожалению не подходит, brotli нет. А в nginx-proxy не вижу смысла в swarm. Что он решает?

🤔 можно же одновременно траффик перенаправить. поднять новую версию и потом на новую версию перенаправить. Пока правда не делал такое)

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

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

Если несколько серверов, в случае swarm то на всех нодах нужны эти файлы. А маунтить volume из другого контейнера это боль, и вроде как вообще не работает в docker-compose v3

Если несколько серверов, в случае swarm то на всех нодах нужны эти файлы. А маунтить volume из другого контейнера это боль, и вроде как вообще не работает в docker-compose v3

Вот тут описывается процесс монтирования фалов в volume из контейнера. А потмо его можно юзать в nginx https://github.com/docker/compose/issues/3211 А где можно почитать про то что ты описываешь ? Я так понимаю штука которую ты описал ответом выше, понадобится, если в nginx нужно вносить изменения и параллельно перенаправить траффик на рабочий контейнер с nginx. А если он апнулся и все норм, но перенаправить трафик обратно ?

Еще раз, в #3211 описывается volumes_from, которого в docker-compose v3 нет

https://stackoverflow.com/questions/42232051/docker-compose-volumes-from-equivalent-with-version-3

Про деплой, надо гуглить blue green deployment docker swarm. Прям ссылки ща нет. Я пока не успел сделать по хорошему такой деплой)

Еще раз, в #3211 описывается volumes_from, которого в docker-compose v3 нет

Там ниже решение. services: mysql: volumes: - datavolume:/var/run/mysqld app: volumes: - datavolume:/var/run/mysqld volumes: datavolume: {}

Ага, в теории может и должно работать, у меня были проблемы.

Там ниже решение. services: mysql: volumes: - datavolume:/var/run/mysqld app: volumes: - datavolume:/var/run/mysqld volumes: datavolume: {}

У меня была проблема, которую описывает чувак I encounter kind of the same problem and the thing is that the datavolume is not a solution for me as the files do not get overridden by a new version. Так вот, она решается с помощью команды выше.

Не могу вспомнить в чем конкретная причина)

А, ну может

Привет, ни у кого не случалось в 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 уже неприкольно расписывать системд сервис, когда это нативный функционал докера который передается одним параметром

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

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

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