Не факт, там может быть composer install тянущий какой-то пакет, у которого сто требованиях стоит ext-*.
Это как раз повод изменить Dockerfile. Ибо как вы без этих изменений собираетесь это на prod выкладывать? И эти изменения в итоге коснутся всех, когда PR будет принят, а не только dev окружения одного конкретного разработчика.
Не каждому разработчику, а в каждый проект.
Ну естественно, один проект — один Dockerfile.
Ну а в случае дев-окружения там много чего может быть. Кому-то mc хочется, кому-то htop и vim и т. п.
Зачем? Файлы проекта в dev окружении лежат на машине и доступны из IDE. Если надо что-то подправить в конфиге где то в /usr/local/etc/php, его тоже можно пробросить с хоста.
По поводу htop, процессы запущенные внутри контейнера видны в htop с локальной машины как локальные (в линуксе)
Не собраться он может только в одном случае, если разработчик там что-то поменял. Ибо он лежит по умолчанию рабочий. Я даже больше скажу, на CI сервере он лежит в кеше. И когда разработчик пушит свой код, в Dockerfile отрабатывает только копирование файлов в контейнер и не больше. Если был изменён composer.json то слой с установкой зависимостей тоже пересобирается. Все остальные низкоуровневые задачи в виде установки расширений к php и прочее лежит в глубоком кеше и пересобирается крайне редко. Может быть чуть чаще, чем выходит новая версия php.
Если у вас контролируется всё, что на прод уходит, то и вредные изменения в Dockerfile не пройдут.
Изменения в Dockerfile в 99% случаях просто не нужны. Если у Вас в него постоянно вносятся изменения, поделись, какого рода изменения. Мне интересно, зачем каждому разработчику свой персональный Dockerfile.
Конфиги приложения обычно тоже не каждый день меняются, но обычно их задаёт разработчик, и только для некоторых их частей разработчик предусматривает штатную возможность изменения при разворачивании, типа одного parameters.ini.dist когда общее число конфигов за десяток.
Не совсем понял о чём речь. У нас почти любой параметр из конфига можно переопределить передав его через ENV при старте контейнера. Эти параметры разработчик может менять как угодно, при чём тут сборка контейнера?
Образ в докер-репозитории собирает CI на основе всё того же Dockerfile.
Что это, простите, за сборная солянка, где каждый результат работы имеет разные Dockerfile'ы? Это получается на prod может залететь всё что угодно?
прежде всего разработчики пишут докерфайлы
Разработчики должны писать приложение, а не окружение к нему. Окружение нужно один раз грамотно написать и использовать. Я имею ввиду, что это не та часть приложения, которая обычно меняется каждый день.
Ну и пост собственно разработчикам адресован, чтобы не боялись докера, а если докерфайлы и ко пишут специально обученные люди, то чего, собственно бояться?
Вроде суть в том, что люди в принципе боятся его трогать и не используют ни в prod ни в dev. А вовсе не о том, что в одном и том же проекте каждый должен написать свой Dockerfile.
У меня в phpstorm написан external tool, который делает chown на нужную мне папку или файл и забинден на хоткей. Вернуть себе права секундное дело.
Плюс я внутрь контейнера выполняю команды через маленькую обёртку (главный сервис в docker-compose.yml у нас всегда называется app) В конце которой меняю владельца файлов на себя.
app
#!/bin/sh
COMPOSE="docker-compose run --rm app"
if docker top `docker-compose ps -q app` 1>/dev/null 2>&1; then
COMPOSE="docker-compose exec app"
fi
if [ -z $1 ]; then
${COMPOSE} sh -c "if type \"bash\" > /dev/null; then bash; else sh; fi"
else
${COMPOSE} "$@"
fi
fix-permission
fix-permission
#!/bin/sh
docker run --rm -v `pwd`:/app -w /app alpine sh -c "chown `id -u`:`id -g` -R ." &
Не буду утверждать, что способ идеальный, но работает и проблем вроде не доставляет.
проблемы с томами, которые шарятся между контейнерами
Мы проблему не решили, но пока ушли от неё поменяв php-fpm на apache.
конфликты портов на хосте
После неудачных танцев с dnsmasq я написал маленький демон, который при появлении контейнера с указанным hostname прописывает его в /etc/hosts. Соответственно порты контейнеров я не публикую. Но работает это только для линукса.
«неправильно» значит можно было сделать так, чтобы он удовлетворял всем задачам.
В чём плюсы сложного докерфайла
Dev окружение должно быть идентично prod'y. Это не говорит, что Dockerfile должен быть один, но наличие второго файла, который разработчик может изменить как ему угодно существенно повышает риск получить разное окружение. Можно получить расхождение и в предложенном мною варианте, но это не проблема подхода, ибо возможности расширения не должны допускать возможность выстрелить себе в ногу.
без кучи ключей и не сбилдтся вообще
Все возможные «кучи» ключей имеют значение по умолчанию, которые соответствуют production версии. Соответственно prod версия при запуске сборки не требует ввода параметров, за исключением токена к github'y для установки приватных пакетов.
В идеале разработчикам приложения вообще не нужно лезть в Dockerfile и что-то там делать, особенно если они:
обычно не очень знают
билд и запуск такого образа потребует сложной командной строки, в которой опять-таки легко ошибиться
Для запуска dev окружения у нас написан docker-compose.yml со всеми возможными параметрами, которые разработчик может менять для своих нужд. Точнее у нас docker-compose.yml.dist, а docker-compose.yml в gitignore.
лишний системный пакет в образе будет, а если какое-то влияние на продакшен-логику окажет?
Поэтому у нас запрещено трогать Dockerfile. Все необходимые библиотеки для разработки уже имеются внутри образа. Если кому то требуется что-то дополнительное и он может это обосновать, то его без проблем добавляют в сборку для всех.
Dockerfile должен подвергаться редактированию только в том случае, если изменения касаются и production серверов.
Если разработчик не может менять поведение сборки или запуска в зависимости от задач разработки не трогая Dockerfile, то у Вас просто не правильно написан Dockerfile. Поведением сборки можно управлять через build_args, а запуском environments.
IP хостовой машины определяется в момент запуска контейнера.
На моей машине параметр xdebug.remote_autostart никак не сказывается на производительности.
Лично мне не нравится подход с публикацией портов. Нет возможности запустить несколько разных проектов, не развешивая их на разные порты.
Я запускаю без публикации портов, при старте контейнера передавая параметр hostname, который привязываю к IP поднятого контейнера.
XDebug'у в docker-entrypoint устанавливаю параметры xdebug.remote_enable=On, xdebug.remote_autostart=On и xdebug.remote_host=<ip хостовой машины>. Настроек со стороны phpstorm вообще не требуется.
https://github.com/OliveTin/OliveTin
Это как раз повод изменить Dockerfile. Ибо как вы без этих изменений собираетесь это на prod выкладывать? И эти изменения в итоге коснутся всех, когда PR будет принят, а не только dev окружения одного конкретного разработчика.
Ну естественно, один проект — один Dockerfile.
Зачем? Файлы проекта в dev окружении лежат на машине и доступны из IDE. Если надо что-то подправить в конфиге где то в /usr/local/etc/php, его тоже можно пробросить с хоста.
По поводу htop, процессы запущенные внутри контейнера видны в htop с локальной машины как локальные (в линуксе)
Не собраться он может только в одном случае, если разработчик там что-то поменял. Ибо он лежит по умолчанию рабочий. Я даже больше скажу, на CI сервере он лежит в кеше. И когда разработчик пушит свой код, в Dockerfile отрабатывает только копирование файлов в контейнер и не больше. Если был изменён composer.json то слой с установкой зависимостей тоже пересобирается. Все остальные низкоуровневые задачи в виде установки расширений к php и прочее лежит в глубоком кеше и пересобирается крайне редко. Может быть чуть чаще, чем выходит новая версия php.
Изменения в Dockerfile в 99% случаях просто не нужны. Если у Вас в него постоянно вносятся изменения, поделись, какого рода изменения. Мне интересно, зачем каждому разработчику свой персональный Dockerfile.
Не совсем понял о чём речь. У нас почти любой параметр из конфига можно переопределить передав его через ENV при старте контейнера. Эти параметры разработчик может менять как угодно, при чём тут сборка контейнера?
Что это, простите, за сборная солянка, где каждый результат работы имеет разные Dockerfile'ы? Это получается на prod может залететь всё что угодно?
Разработчики должны писать приложение, а не окружение к нему. Окружение нужно один раз грамотно написать и использовать. Я имею ввиду, что это не та часть приложения, которая обычно меняется каждый день.
Вроде суть в том, что люди в принципе боятся его трогать и не используют ни в prod ни в dev. А вовсе не о том, что в одном и том же проекте каждый должен написать свой Dockerfile.
У меня в phpstorm написан external tool, который делает chown на нужную мне папку или файл и забинден на хоткей. Вернуть себе права секундное дело.
Плюс я внутрь контейнера выполняю команды через маленькую обёртку (главный сервис в docker-compose.yml у нас всегда называется app) В конце которой меняю владельца файлов на себя.
Не буду утверждать, что способ идеальный, но работает и проблем вроде не доставляет.
Мы проблему не решили, но пока ушли от неё поменяв php-fpm на apache.
После неудачных танцев с dnsmasq я написал маленький демон, который при появлении контейнера с указанным hostname прописывает его в /etc/hosts. Соответственно порты контейнеров я не публикую. Но работает это только для линукса.
«неправильно» значит можно было сделать так, чтобы он удовлетворял всем задачам.
Dev окружение должно быть идентично prod'y. Это не говорит, что Dockerfile должен быть один, но наличие второго файла, который разработчик может изменить как ему угодно существенно повышает риск получить разное окружение. Можно получить расхождение и в предложенном мною варианте, но это не проблема подхода, ибо возможности расширения не должны допускать возможность выстрелить себе в ногу.
Все возможные «кучи» ключей имеют значение по умолчанию, которые соответствуют production версии. Соответственно prod версия при запуске сборки не требует ввода параметров, за исключением токена к github'y для установки приватных пакетов.
В идеале разработчикам приложения вообще не нужно лезть в Dockerfile и что-то там делать, особенно если они:
Для запуска dev окружения у нас написан docker-compose.yml со всеми возможными параметрами, которые разработчик может менять для своих нужд. Точнее у нас docker-compose.yml.dist, а docker-compose.yml в gitignore.
Поэтому у нас запрещено трогать Dockerfile. Все необходимые библиотеки для разработки уже имеются внутри образа. Если кому то требуется что-то дополнительное и он может это обосновать, то его без проблем добавляют в сборку для всех.
Dockerfile должен подвергаться редактированию только в том случае, если изменения касаются и production серверов.
Если разработчик не может менять поведение сборки или запуска в зависимости от задач разработки не трогая Dockerfile, то у Вас просто не правильно написан Dockerfile. Поведением сборки можно управлять через build_args, а запуском environments.
На моей машине параметр xdebug.remote_autostart никак не сказывается на производительности.
Я запускаю без публикации портов, при старте контейнера передавая параметр hostname, который привязываю к IP поднятого контейнера.
XDebug'у в docker-entrypoint устанавливаю параметры xdebug.remote_enable=On, xdebug.remote_autostart=On и xdebug.remote_host=<ip хостовой машины>. Настроек со стороны phpstorm вообще не требуется.