ога, ci у них, сиди
))-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Setcookie и POST запрос
- Автор темы Mirt
- Дата начала
))
Ну, сидим, деплоим) У всех свое болотцеога, ci у них, сиди
в моем понимании .env не многое поменяет если в nginx прописано fastcgi_param по этой причине не врублюсь зачем debug=off в этом файле хранить, пиши сразу в conf.php
вот потому и надо хранить в .env, потому как данные из него не только для апп и настроек php, но и для конфигурирование сервера и докера используются.
другими словами, ты "не рекомендуешь" 12-факторные приложения - правила построения архитектуры корпоративных систем во всем мире
это не всегда удобно, особенно если о дебаге, при всех прелестях одной настройки это ее и недостатки, хочется иметь разные уровни, разные способы отлавливания. просто запустить под nginx новый домен с измененными fastcgi_param значениями (есть www. есть dev.) на много проще и прозрачнее - контейнер один, аппликация одна, окружение различное.
Другими словами я не рекомендую опять читать половину, понимать половину прочитанного и пытаться опять вставить свои пять копеек. Конфиг сервака - это не всегда переменные окружения. Не надо пихать все в него. Хотя ты можешь делать как тебе удобнее. Докер и конфиги внутри - для тебя ок.
было бы неплохо тебе почитать статью по ссылке, я конкретно про "можно хоть в .env, хоть в yml, хоть куда писать то, что относится к самому сайту "
по 12 факторам - нет, нельзя, код должен быть спроектирован так, чтобы можно было его свободно опубликовать в open source, и деплоить без изменения файлов в любом окружении
писать файловые конфиги - устаревшая традиция php, а в python, golang и java принцип передачи параметров через переменные окружения считается само собой разумеющимся, никто не собирает отдельный пакет c другими файлами конфигурации для деплоя на stage
по 12 факторам - нет, нельзя, код должен быть спроектирован так, чтобы можно было его свободно опубликовать в open source, и деплоить без изменения файлов в любом окружении
писать файловые конфиги - устаревшая традиция php, а в python, golang и java принцип передачи параметров через переменные окружения считается само собой разумеющимся, никто не собирает отдельный пакет c другими файлами конфигурации для деплоя на stage
У нас в проекте используется .env и его деривативы (.env.test, .env.staging ...). В git они не лежат, перечитай, там про это есть. Публикуй сколько влезет, только перепиши по шаблону .env и все. В любом случае при деплое ты будешь так же настраивать окружение, если ты хранишь свои "креды" где-то еще.
прости, я не знаю где читать
в dotenv написано, что
чтобы деплоить с конфигами в файлах с другими именами, как .env.test, эти имена должны быть в коде приложения
и если они не лежат в git, то непонятно где они вообще учитываются
например, если .env.prod лежит только на сервере, и в него надо добавить параметр, то надо лезть на сервер по ssh и править его руками, а при переезде на другой сервер его надо создавать заново - по 12-factor так нельзя, да и просто с кучей виртуалок всегда будет куча ошибок
когда у нас автоматический деплоймент, значения параметров хранятся в отдельной системе, такой как AWS systems manager, и доступны сервисам или через api, или через переменные окружения, которые создаются при деплое
то есть, параметры не выносятся в конфиги сервера, наоборот - конфиги серверов становятся частью приложений,
параметры выносятся в отдельную систему управления параметрами, и у них есть версии
На сколько мне не изменяет память, в симфони есть "окружения" и по ним - называются .env файлы с аффиксом (.env.test). Довольно логично. В коде приложения они будут в любом случае, вопрос только в каком виде, так как со сменой площадки тебе бы все равно пришлось переносить настройки окружения сервера.
И как по мне - ты опять мешаешь "деплой" приложения и "способ хранения" настроек, тебе никто не мешает так же в CI сделать пайплайн где в том числе ты будешь собирать файл .env для прода по шаблону (или для любого окружения). Задавать уровень "энтерпрайз с централизованным хранением параметров" - не все потянут, надеюсь ты это понимаешь.
И... ты опять тянешь все в плоскость оркестрации, которая как известно сильно зависима от проекта к проекту, где-то одна, где-то другая. Я же писал изначально - про самый простой и правильный способ - ВКЛЮЧИТЬ ОШИБКИ, то, что каждый начинающий должен делать в первых строчках, но исходя из уровня топик стартера, он не будет хранить это в конфигах, даже в .env.
Но пришел первый респондент - решил хранить это в окружении сервака, потом второй, тоже там же хранит. В уровне который приводился, нет докера, нет переменных окружения, там у него все просто. Да, я читал 12 факторов, и третий снизу абзац весьма полезен, но только его уровень - это уже уровень подразумевающий использование какой-либо оркестрации. Потому как если под этим абзацем ее не будет, то мы утыкаемся в такой же тупик "перенесли приложение на другой сервак, а переменных окружения не завезли".
И как по мне - ты опять мешаешь "деплой" приложения и "способ хранения" настроек, тебе никто не мешает так же в CI сделать пайплайн где в том числе ты будешь собирать файл .env для прода по шаблону (или для любого окружения). Задавать уровень "энтерпрайз с централизованным хранением параметров" - не все потянут, надеюсь ты это понимаешь.
И... ты опять тянешь все в плоскость оркестрации, которая как известно сильно зависима от проекта к проекту, где-то одна, где-то другая. Я же писал изначально - про самый простой и правильный способ - ВКЛЮЧИТЬ ОШИБКИ, то, что каждый начинающий должен делать в первых строчках, но исходя из уровня топик стартера, он не будет хранить это в конфигах, даже в .env.
Но пришел первый респондент - решил хранить это в окружении сервака, потом второй, тоже там же хранит. В уровне который приводился, нет докера, нет переменных окружения, там у него все просто. Да, я читал 12 факторов, и третий снизу абзац весьма полезен, но только его уровень - это уже уровень подразумевающий использование какой-либо оркестрации. Потому как если под этим абзацем ее не будет, то мы утыкаемся в такой же тупик "перенесли приложение на другой сервак, а переменных окружения не завезли".
Ну вот давай все же не будем брать экзотику) Мы же все ж на php-ориентированном форуме. В твоем случае то понятно, что как и в любом "пакете" или той же самой упакованной заранее виртуалке(образе), которая просто запускается где-то и отвечает на "запросы из вне" все будет интегрировано внутрь.
Стандарт - это настройка приложения через переменные среды.
.env - это способ "перебить" переменные среды для конкретного приложения. Нужно, разумеется, только для разработки. На продакшене (если таковым не считать шаред) переменные среды задаются штатным для ОС (или системы запуска контейнеров) способом.
Ок, мне интересно, может сделать как-то удобнее выйдет. Берем ситуацию с простым instance aws t3.large где крутится fpm+nginx, нет ни контейнеров, ни оркестрации, как будешь завадать env в том же debian?
вы что, до сих пор на arm64 не переехали?)
я для тебя погуглил - вот, по ссылке расписано как это делается для wordpress,
только не забыть раскомментировать "clear_env = no" в php-fpm.conf, чтобы читать переменные
а для оркестрованных контейнеров в aws написали мануал
Use Parameter Store parameters in Amazon Elastic Kubernetes Service - AWS Systems Manager
AWS Secrets Manager enables you to retrieve secrets from Parameter Store to use in your Amazon EKS pods.
docs.aws.amazon.com
Последнее редактирование: