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

на разных проектах

и с этого скелета будут стартовать разные люди проекты раза по 4-6 в год

Про твои заморочки я уже давно понял)

это еще что, ты и половины не знаешь)

.env и .php_cs удобнее в .gitignore держать

а .php_cs.cache сразу билдить в /var

.env и .php_cs удобнее в .gitignore держать

не удобнее, .php_cs общий для всех, как и .env

если ты не заметил - у меня нет ущербного .env.dist

А у меня разработчик может .env под себя настраивать не конфликтуя с гитом при этом

Что же у тебя тогда ущербный docker-compose.yml.dist делает?

А у меня разработчик может .env под себя настраивать не конфликтуя с гитом при этом

у меня тоже - export SOME_VAR=value

Что же у тебя тогда ущербный docker-compose.yml.dist делает?

у меня нет такого

это у тебя

точно, не туда смотрю))

)))

я уже спрашивал зачем он?

export SOME_VAR=value - это где и куда вводить надо?

Чтобы разработчик под себя менял docker-compose.yml не конфликтуя с гитом

export SOME_VAR=value - это где и куда вводить надо?

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

Чтобы разработчик под себя менял docker-compose.yml не конфликтуя с гитом

зачем ему менять compose файл не конфликтуя с гитом?)

Сергей, а чем ущербен .env.dist?

ну то есть... у меня очень простая философия - локально окружение должно быть максимально приближенным к тому, что будет на продакшене (естественно полностью не выйдет) и окружение должно быть одинаковым у всей команды

У фронта API включена в APP_ENV=prod и APP_DEBUG=0, у бекенда наоборот нода с реактом/ангуляром включена в prod. У тестировщика всё включено в prod.

Сергей, а чем ущербен .env.dist?

тем что он не нужен. Это сделано для упрощения перехода с parameters.yml в .env. По факту .env уже работает так, что твои переменные окружения учитывает. И это Твое окружение так что ты можешь любые значения свои туда запихнуть

У фронта API включена в APP_ENV=prod и APP_DEBUG=0, у бекенда наоборот нода с реактом/ангуляром включена в prod. У тестировщика всё включено в prod.

ну добавь себе в свой локальный .bashrc нужные параметры

Причём тут .bashrc?

ну баш профайл, или zshrc

это переменные окружения, Карл

переменные окружения - это export VAR=value

стандартная штука

есть во всех ОС

У нас локальные окружения не имеют отношения к контейнерам

У нас локальные окружения не имеют отношения к контейнерам

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

или типа локально нет докера?

да и потом - какая разница и прчием тут контейнеры? для чего по твоему компонент symfony/dotenv сделан?

Локально ничего кроме докера и шторма нет.

Локально ничего кроме докера и шторма нет.

операционка есть

она это умеет

зачем мне завязывать env операционки на один проект?

иначе вот тебе вопрос - зачем тогда было отказываться от parameters.yml?

У меня часто 3 проекта одновременно запущено

У меня часто 3 проекта одновременно запущено

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

ну то есть нет смысла в .env.dist

Ещё раз, у нас у каждого своя локаль.

а фронты мои не хотят докер себе локально поднимать

а если и захотят - будут работать в dev окружении

профайлер им тоже иногда полезен подебажить что не так пошло

иначе вот тебе вопрос - зачем тогда было отказываться от parameters.yml?

.env мне позволяет не перезапускать контейнер, как если бы я передал env через docker-compose.yml

.env мне позволяет не перезапускать контейнер, как если бы я передал env через docker-compose.yml

ответь на простой вопрос - зачем тогда вообще понадобился этот чертов .env если parameters.yml в целом хватало?

а если и захотят - будут работать в dev окружении

Мне не интересно чтобы фронт вёл разработку ожидая по 5с ответа, вместо 5мс

Мне не интересно чтобы фронт вёл разработку ожидая по 5с ответа, вместо 5мс

ну так он и не будет, будет где-нибудь 100 милисекунд вместо 5-ти

зато сэмулируем лэтенси сервера)

ответь на простой вопрос - зачем тогда вообще понадобился этот чертов .env если parameters.yml в целом хватало?

.env мне позволяет не перезапускать контейнер, как если бы я передал env через docker-compose.yml

.env мне позволяет не перезапускать контейнер, как если бы я передал env через docker-compose.yml

дежавю, parameters.yml тебе это тоже позволял) и даже больше - он позволял это делать на продакшене!

parameters.yml больше нет, его мне заменяет .env. Чо не так то?)

да и ничего страшного не вижу в том что бы рекреейтнуть контейнер, зато точно не забуду прописать новый параметр в docker-compose

parameters.yml больше нет, его мне заменяет .env. Чо не так то?)

"его нет потому что его нет"

короч я тебя понял

мне не интересно

У меня в docker-compose.yml только те настройки, которые влияет на старт контейнера и не более. Всё env которые на запуск не вклюяют находятся в .env

повторюсь - в моем флоу такие вещи как "подправить параметры для себя" или еще хуже - свой compose файл - это что-то исключительное

А у меня нет, у многих разное

У меня в docker-compose.yml только те настройки, которые влияет на старт контейнера и не более. Всё env которые на запуск не вклюяют находятся в .env

у меня все параметры которые не влияют на окружение (и как следствие на запуск контейнера) просто в config.yml

у меня все параметры которые не влияют на окружение (и как следствие на запуск контейнера) просто в config.yml

У меня тоже. Но когда их надо подменить, я использую .env

А у меня нет, у многих разное

1. зачем им менять compose файлики? 2. зачем твоим фронтендерам где-то чего-то менять? им дефолтного не хватает?

У меня тоже. Но когда их надо подменить, я использую .env

export VAR=name docker-compose up -d

ERROR: S client not available

если часто это делаешь - есть повод подправить .env

и обсудить с командой

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

а вот зафорсить уменьшение различий и что бы кейсы всплывали на поверхность - в этом смысл вижу

Проблемы из-за различий бывают только если я что-то обновлю и забуду всем сказать. Для меня это приемлимо. А вот заставлять фронта долбить апи с APP_DEBUG=1 и XDEBUG:true для меня не приемлимо.

Когда настраивал проект на macbook так вообще в compose пришлось haproxy добавить)

Когда настраивал проект на macbook так вообще в compose пришлось haproxy добавить)

я dinghy-http-proxy просто юзаю

у всех почти из коробки взлетало

Проблемы из-за различий бывают только если я что-то обновлю и забуду всем сказать. Для меня это приемлимо. А вот заставлять фронта долбить апи с APP_DEBUG=1 и XDEBUG:true для меня не приемлимо.

без волумов - это не так страшно)

Путного правда ничего не вышло. Раз в пол часа docker-for-mac теряет синхронизацию файлов. Разраб только после 10-30 минут дебага одупляет, что проблем не в коде, а том что новый код до контейнера не доходит.

Путного правда ничего не вышло. Раз в пол часа docker-for-mac теряет синхронизацию файлов. Разраб только после 10-30 минут дебага одупляет, что проблем не в коде, а том что новый код до контейнера не доходит.

docker-for-mac дикий тормоз к тому же. Я юзаю dinghy + virtualbox.

так что твое "5 секунд грузить страницу" я теперь понимаю. У меня нет таких проблем

хотя конечно по сравнению с ребятами кто на linux сидят - 500 милисекунд тоже медленно

а победить docker-for-mac что бы в пол пинка завести NFS у меня не вышло

У нас у всех ubuntu, 5с я конечно загнул. Но без кешей и с дебагом очень некомфортно работать фронту. У бека выбора нет)

а с osxfs - это просто ад

У нас у всех ubuntu, 5с я конечно загнул. Но без кешей и с дебагом очень некомфортно работать фронту. У бека выбора нет)

хочешь раскрою тебе секрет как я избежал таких проблем?

жги

у каждого фронта свой dev сервер и они вообще не парятся с этими вашими докерами

просто деплоят сервачек и делают у себя свой любимый npm start

Выделил им дебаг сервер ?

да и потом

у фронтов тоже есть скелет проектов и не сложно добавить в npm start и экспорты переменных нужных и все что надо

так что фронт приходит и делает npm install && npm start и работает себе

я вот у себя локально проект через composer start запускал)

что бы спрятать любые изменения во флоу старта проекта

за одну простую команду

но это если у тебя фронты делают SPA а бэкэнд делают API

тогда счастье и любовь

а если web.... там есть нюансы

я таким не занимаюсь а от того мой флоу сильно упрощен

У меня после установки ubuntu происходит установка phpstorm и git. Пулится репа. После чего make docker-install && make && make install после чего можно работать. И нет зависимости от доступности интернета) Требуется крайне редко, но тем не менее