Я пытаюсь определить, где провести грань между тем, что входит в марионетку, и тем, что является частью «приложения». Одно место, где я немного озадачен, - это nginx conf.d файлы.
В apache эти файлы были бы помечены как .htaccess и, таким образом, являлись частью приложения. Однако в nginx нет файлов .htaccess; они должны перейти в каталог conf.d, и сервер вернется.
Достаточно справедливо, но когда дело доходит до упаковки приложения и развертывания конфигурации сервера с марионеткой, я считаю, что грань между конфигурацией сервера и областью приложений довольно размыта.
Если я помещаю файлы в пакет приложения (мы используем RPM), тогда у меня есть конфигурация сервера в приложении. Однако, если я помещаю файлы в марионетку, и автор приложения желает внести изменения (добавить другое / местоположение или переписать и т. Д.), То мне нужно обновить марионетку, и теперь следующая версия приложения зависит от версии марионетки. .
Для меня это проблема с курицей и яйцом. Куда лучше всего поместить эти файлы conf.d, пакет RPM марионетки или приложения?
Я думаю, что правильный ответ здесь будет определяться деловыми, а не техническими соображениями.
В общем, мой совет: если разработчики поддерживают этот файл как часть приложения, им следует упаковать и отправить его как часть приложения. Но они также должны нести ответственность, если их изменения нарушат производство.
Если вы поддерживаете этот файл или если они не несут ответственности за нарушение работы, вам следует сохранить файл и поместить его в марионетку.
Однако в nginx нет файлов .htaccess;
верный
они должны перейти в каталог conf.d, и сервер вернется.
не верно; они могут идти куда угодно, вам просто нужно включить файлы или целые каталоги как это:
Вы можете включать любые файлы конфигурации для любых целей. включить vhosts / *. conf;
Достаточно справедливо, но когда дело доходит до упаковки приложения и развертывания конфигурации сервера с марионеткой, я считаю, что грань между конфигурацией сервера и областью приложений довольно размыта.
Верно и обратное, из-за другой концепции: с .htaccess вы смешиваете приложение с конфигурацией сервера, а в nginx-land обычно разрешаете приложению обрабатывать запросы. nginx гораздо более распространен как обратный прокси перед сервером приложений, который обслуживает URL-адреса в стиле REST, чем как шлюз для таких вещей, как typo3 с огромным .htaccess, чтобы сделать URL-адреса, удобные для поиска, вместо /index.php?id=23&project=23&page=13&lang=fr
возвращаясь к вашему вопросу: что сказал Майкл, плюс (немного ОТ): мы используем ткань для немедленных / интерактивных изменений (интервал выполнения марионетки установлен на 15 минут), потому что мы хотим, чтобы
но YMMV.