Setcookie и POST запрос

WMix

герр M:)ller
Партнер клуба
Ситуация: пришел тестировщик на стейдж...
в моем понимании .env не многое поменяет если в nginx прописано fastcgi_param по этой причине не врублюсь зачем debug=off в этом файле хранить, пиши сразу в conf.php
 

c0dex

web.dev 2002-...
Команда форума
Партнер клуба
Я вообще нигде не советую переносить настройки приложения в конфиги серваков, поэтому можно хоть в .env, хоть в yml, хоть куда писать то, что относится к самому сайту
 

AmdY

Пью пиво
Команда форума
в моем понимании .env не многое поменяет если в nginx прописано fastcgi_param по этой причине не врублюсь зачем debug=off в этом файле хранить, пиши сразу в conf.php
вот потому и надо хранить в .env, потому как данные из него не только для апп и настроек php, но и для конфигурирование сервера и докера используются.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума

WMix

герр M:)ller
Партнер клуба
вот потому и надо хранить в .env,
это не всегда удобно, особенно если о дебаге, при всех прелестях одной настройки это ее и недостатки, хочется иметь разные уровни, разные способы отлавливания. просто запустить под nginx новый домен с измененными fastcgi_param значениями (есть www. есть dev.) на много проще и прозрачнее - контейнер один, аппликация одна, окружение различное.
 

c0dex

web.dev 2002-...
Команда форума
Партнер клуба
другими словами, ты "не рекомендуешь" 12-факторные приложения - правила построения архитектуры корпоративных систем во всем мире
Другими словами я не рекомендую опять читать половину, понимать половину прочитанного и пытаться опять вставить свои пять копеек. Конфиг сервака - это не всегда переменные окружения. Не надо пихать все в него. Хотя ты можешь делать как тебе удобнее. Докер и конфиги внутри - для тебя ок.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
было бы неплохо тебе почитать статью по ссылке, я конкретно про "можно хоть в .env, хоть в yml, хоть куда писать то, что относится к самому сайту "
по 12 факторам - нет, нельзя, код должен быть спроектирован так, чтобы можно было его свободно опубликовать в open source, и деплоить без изменения файлов в любом окружении

писать файловые конфиги - устаревшая традиция php, а в python, golang и java принцип передачи параметров через переменные окружения считается само собой разумеющимся, никто не собирает отдельный пакет c другими файлами конфигурации для деплоя на stage
 

c0dex

web.dev 2002-...
Команда форума
Партнер клуба
У нас в проекте используется .env и его деривативы (.env.test, .env.staging ...). В git они не лежат, перечитай, там про это есть. Публикуй сколько влезет, только перепиши по шаблону .env и все. В любом случае при деплое ты будешь так же настраивать окружение, если ты хранишь свои "креды" где-то еще.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
В git они не лежат, перечитай, там про это есть.
прости, я не знаю где читать

в dotenv написано, что
Optionally you can pass in a filename as the second parameter, if you would like to use something other than .env:
$dotenv = Dotenv\Dotenv::createImmutable(__DIR__, 'myconfig');
чтобы деплоить с конфигами в файлах с другими именами, как .env.test, эти имена должны быть в коде приложения
и если они не лежат в git, то непонятно где они вообще учитываются

например, если .env.prod лежит только на сервере, и в него надо добавить параметр, то надо лезть на сервер по ssh и править его руками, а при переезде на другой сервер его надо создавать заново - по 12-factor так нельзя, да и просто с кучей виртуалок всегда будет куча ошибок

когда у нас автоматический деплоймент, значения параметров хранятся в отдельной системе, такой как AWS systems manager, и доступны сервисам или через api, или через переменные окружения, которые создаются при деплое
то есть, параметры не выносятся в конфиги сервера, наоборот - конфиги серверов становятся частью приложений,
параметры выносятся в отдельную систему управления параметрами, и у них есть версии
 

c0dex

web.dev 2002-...
Команда форума
Партнер клуба
На сколько мне не изменяет память, в симфони есть "окружения" и по ним - называются .env файлы с аффиксом (.env.test). Довольно логично. В коде приложения они будут в любом случае, вопрос только в каком виде, так как со сменой площадки тебе бы все равно пришлось переносить настройки окружения сервера.

И как по мне - ты опять мешаешь "деплой" приложения и "способ хранения" настроек, тебе никто не мешает так же в CI сделать пайплайн где в том числе ты будешь собирать файл .env для прода по шаблону (или для любого окружения). Задавать уровень "энтерпрайз с централизованным хранением параметров" - не все потянут, надеюсь ты это понимаешь.

И... ты опять тянешь все в плоскость оркестрации, которая как известно сильно зависима от проекта к проекту, где-то одна, где-то другая. Я же писал изначально - про самый простой и правильный способ - ВКЛЮЧИТЬ ОШИБКИ, то, что каждый начинающий должен делать в первых строчках, но исходя из уровня топик стартера, он не будет хранить это в конфигах, даже в .env.

Но пришел первый респондент - решил хранить это в окружении сервака, потом второй, тоже там же хранит. В уровне который приводился, нет докера, нет переменных окружения, там у него все просто. Да, я читал 12 факторов, и третий снизу абзац весьма полезен, но только его уровень - это уже уровень подразумевающий использование какой-либо оркестрации. Потому как если под этим абзацем ее не будет, то мы утыкаемся в такой же тупик "перенесли приложение на другой сервак, а переменных окружения не завезли".
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
да, от вопроса включения ошибок, когда код деплоится по ftp, мы далеко ушли

а вот собирать файл .env для прода - это неправильно, представь что у тебя деплоится rpm-пакет, и перед деплоем его надо тестировать
 

c0dex

web.dev 2002-...
Команда форума
Партнер клуба
Ну вот давай все же не будем брать экзотику) Мы же все ж на php-ориентированном форуме. В твоем случае то понятно, что как и в любом "пакете" или той же самой упакованной заранее виртуалке(образе), которая просто запускается где-то и отвечает на "запросы из вне" все будет интегрировано внутрь.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
образ ничем не отличается от rpm - это архив, который распаковывается и запускается "as is", если в проде править конфиги после деплоя - гарантированно будут ошибки
 

fixxxer

К.О.
Партнер клуба
.env уже почти стандарт, используемый даже в велосипедах благодаря библиотечке: https://github.com/vlucas/phpdotenv Да, ты можешь окружение тягать откуда угодно, но вопрос удобства и последующего понимания тебя другими разрабами тут не последний.

Да ,при чем тут прод или не прод, я говорю об уровнях, что и где должно лежать соразмеряясь с практикой использования. На проде эти параметры и менять то может 1 админ
Стандарт - это настройка приложения через переменные среды.

.env - это способ "перебить" переменные среды для конкретного приложения. Нужно, разумеется, только для разработки. На продакшене (если таковым не считать шаред) переменные среды задаются штатным для ОС (или системы запуска контейнеров) способом.
 

c0dex

web.dev 2002-...
Команда форума
Партнер клуба
Стандарт - это настройка приложения через переменные среды.

.env - это способ "перебить" переменные среды для конкретного приложения. Нужно, разумеется, только для разработки. На продакшене (если таковым не считать шаред) переменные среды задаются штатным для ОС (или системы запуска контейнеров) способом.
Ок, мне интересно, может сделать как-то удобнее выйдет. Берем ситуацию с простым instance aws t3.large где крутится fpm+nginx, нет ни контейнеров, ни оркестрации, как будешь завадать env в том же debian?
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
я и забыл, что файловые конфиги появились в php из-за shared hosting :)
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Берем ситуацию с простым instance aws t3.large где крутится fpm+nginx, нет ни контейнеров, ни оркестрации, как будешь завадать env в том же debian?
я для тебя погуглил - вот, по ссылке расписано как это делается для wordpress,
только не забыть раскомментировать "clear_env = no" в php-fpm.conf, чтобы читать переменные


а для оркестрованных контейнеров в aws написали мануал
 
Последнее редактирование:
Сверху