Nginx conf.d 文件通過 puppet
我正在嘗試確定在 puppet 中的內容和“應用程序”的一部分之間劃清界限。我有點困惑的一個地方是 nginx conf.d文件。
在 apache 中，我會將這些文件標記為 .htaccess，因此是應用程序的一部分。但是，在 nginx 中沒有 .htaccess 文件；他們必須進入 conf.d 目錄並且伺服器被退回。
很公平，但是在使用 puppet 打包應用程序和部署伺服器配置時，我發現伺服器配置和應用程序之間的界線在這里相當模糊。
如果我將文件放在應用程序包中（我們使用的是 RPM），那麼我在應用程序中有伺服器配置。但是，如果我將文件放入 puppet 並且應用程序作者希望進行更改（添加另一個/位置或重寫等），那麼我必須更新 puppet，現在應用程序的下一個版本取決於 puppet 版本.
對我來說，這似乎是一個雞和蛋的問題。那麼，放置這些 conf.d 文件的最合適的位置是 puppet 還是應用程序 RPM？
我認為這裡的正確答案將由業務考慮驅動，而不是技術考慮。
一般來說，我的建議是：如果開發人員將此文件作為應用程序的一部分進行維護，那麼他們應該將其打包並作為應用程序的一部分發布。但是，如果他們的更改破壞了生產，他們也必須承擔責任。
如果您維護此文件，或者如果他們中斷生產而不負責，那麼您應該維護該文件並將其放入 puppet。
但是，在 nginx 中沒有 .htaccess 文件；
正確的
他們必須進入 conf.d 目錄並且伺服器被退回。
不正確; 他們可以去任何你想去的地方，你只需要像這樣包含文件或整個目錄：
您可以根據需要包含任何配置文件。包括虛擬主機/*.conf；
很公平，但是在使用 puppet 打包應用程序和部署伺服器配置時，我發現伺服器配置和應用程序之間的界線在這里相當模糊
恰恰相反，因為有一個不同的概念：使用 .htaccess 您可以將應用程序與伺服器配置混合在一起，而在 nginx-land 中通常讓應用程序處理請求。nginx 作為提供 REST 樣式 URL 的應用程序伺服器的反向代理，比作為帶有 huuuge .htaccess 的typo3 之類的東西的網關更為常見，以製作對 seo 友好的 URL，而不是
/index.php?id=23&project=23&page=13&lang=fr回到你的問題：michael 說了什麼，加上（有點 OT）：我們使用織物進行即時/互動式更改（puppet runinterval 設置為 15 分鐘），因為我們想要
- 此類更改的部署過程和活動操作，這意味著：有人必須按下按鈕
- 可以查看、檢測和立即修復故障，例如當配置測試失敗時
- 通常將配置更改推送到備用伺服器上進行測試，如果可行，則更新實時伺服器。
但是YMMV。