Комментарии 23
Это хорошо, а как в разных секциях сервисов использовать разные файлы окружения, помимо .env? У меня так и не получилось
services:
# ...
myservice:
image: ...
env_file: /path/to/file.env
#...Оно?
это не работает, у меня не получилось, работает только .env из текущей папки
попробуйте убрать .env из папки, либо в другое место переместите. Может он подгружается на уровне приложения (докер считывает файл и передает его просто как переменные окружения, а не как .env-файл)
З.Ы. Есть еще второй вариант - прокинуть .env через volumes
УМВР, причем как с .env (глобально для всех контейнеров), так и с переопределенными для конкретных контейнеров env_file(дополнительные опции вдобавок к глобальным из .env)[root@nms librenms]# docker -v
Docker version 26.1.4, build 5650f9b
Собственно compose-файл - слегка переделанный из репозитария https://github.com/librenms/docker
docker-compose --env-file /path/to/file up -d
новых возможностей Docker Compose
Статья про Docker Compose v2, который был релизнут в 2020 году. В принципе, всё правильно описано, но уже 5 лет прошло.
Кэширование и таргет - скорее фичи Buildkit, который сейчас тоже по-умолчанию используется, а раньше надо было переменной окружения включать.
Какие ужасные примеры, в первом у вас и так все обновится, ведь nginx и так читать будет из волюма. С профилями тоже, пишут про разные настройки для дебага/продакшена, а по факту вы совсем разные сервисы запускаете.
Тоже не понял примера с watch. Оно и без него будет работать прекрасно.
Или это просто статья ради статьи?
не, это не будет работать с директивой :ro
я как-то правил конфиг и рестартовал nginx через docker exec web ash и офигивал от отсутствия изменений ))
Вы, случайно, не прокидывали только сам файл конфига, а не директорию, где он лежит? Некоторые редакторы при сохранении файла не пишут в него же, а создают временный невидимый, а потом перемещают на место прежнего. При этом меняется inode, а так как проброс делается по inode, а не по пути, то в контейнере изменения действительно не видны.
ro работает внутри фс контейнера, поэтому так не получится, а если изменить файл с хостовой системы, то должен увидеть изменения
Пример с nginx, показывает что так можно и нужно делать. Будь если это приложение Node.js мы хотим, чтобы код автоматически обновлялся без перезапуска контейнера вручную при этом приложение не умеет hot-reload - процесс не увидит изменения. watch ускоряет локальную разработку, убирая ручные перезапуски
Пример с Nginx просто не работает (docker compose version → 2.27.0):
docker compose watch
none of the selected services is configured for watch, consider setting an 'develop' section
При этом F5 в браузере успешно показывает изменения в файлах в проброшенной директории. Судя docker compose watch --help, она следит за build context, а не за произвольными проброшенными точками. И если наше приложение не поддерживает hot reload, надо конфигурировать, как именно docker compose watch оповестит его, что файлы изменились. И почему через labels, а не штатными средствами (https://docs.docker.com/reference/compose-file/develop/)?
Ждем свежую статью по v3!
Ждем свежую статью по v3!
На данный момент последняя версия Docker Compose: v2.32.4 .
Вероятно, вы имели в виду docker compose file v3 - формат файла третьей версии. Но статья не об этом совсем, а о бывшем приложении docker-compose, который стал плагином для Docker (и это и есть v2). Версии 3 пока нет и, возможно, даже не особо планируется.
"Кодиш — видиш"...
А ещё сам Dockerfile можно описывать прямо в compose без использования файла (dockerfile_inline).
И было дописать, что кэш можно использовать из image. А где ещё cache_to? И обратное no_cache?
Также подсовывать свой hosts (extra_hosts).
Также можно определить stage для multi-stage Dockerfile (target).
Это так на вскидку.... Полезнее было бы расширить статью.
Docker Compose: Фичи, которые ускорят вашу разработку