一千萬個為什麽

搜索

使用docker-compose,為dev和prod處理不同容器集的推薦方法是什麽?



我正在創建一個帶有python後端的Web應用程序,Nginx作為服務器,Vue作為我的前端Web框架。在部署到生產時,我構建了一個nginx容器,在構建時,將我的所有前端代碼編譯成它可以服務的縮小靜態文件(需要大約2分鐘),並在運行時,提供這些靜態文件並路由非靜態文件HTTP請求到另一個API容器(運行python應用程序)。 (所以兩個容器:nginx和api服務器)。

The problem I'm facing is that during development, I want to use a third container to run a hot-reloading webpack-dev-server for the frontend files, instead of having to wait two whole minutes for webpack to rebuild the frontend bundle every time I make a change. For reference, building the frontend code into servable static files takes around two minutes, whereas the webpack-dev-server can reflect changes in <3 seconds)

我的想法是有一個生產nginx配置來處理直接從nginx容器提供靜態內容的生產情況,以及一個dev nginx配置,它處理將這些靜態請求路由到webpack-dev-server容器的開發案例。但是針對不同環境使用不同的docker-compose文件似乎違背了docker哲學。我接近這個錯誤嗎?

轉載註明原文: 使用docker-compose,為dev和prod處理不同容器集的推薦方法是什麽?

一共有 1 個回答:

docker-compose.override.yml,docker-compose.prod.yml和 extend

概要的答案是為您的公共基本配置提供 docker-compose.yml 文件,為生產特定的容器集合提供 docker-compose.prod.yml 。對於其他特定環境, docker-compose.override.yml 。可以在docker compose yml文件中使用docker-compose extend 關鍵字/ command/statement從其他docker compose yml文件繼承。

上述方法的基礎是,人們首先只考慮所有環境中的共同事物,因為純粹的基本設置,然後dev和prod環境將基於此(繼承)。

您的特定於開發人員的打包程序設置可以在 docker-compose.override.yml 文件中配置,該文件繼承自基本 docker-compose.yml 。所有環境中通用的配置都位於 docker-compose.yml 中。您的生產設置可以在 docker-compose.prod.yml 中,它也可以從基本 docker-compose.yml 繼承。

<�強>參考</強>

這似乎是最佳實踐方法,基於以下參考:

您可能需要或可能不需要針對具體案例考慮的一些事項

  • 可能需要或可能沒有一些定制的配置代碼 添加,即在您的部署中,例如bash腳本等,如果上述方法提供了你需要的大部分內容,但並不是一切。這些腳本可以從docker compose運行。

  • 研究編寫 docker-compose.override.yml 時可以覆蓋的內容 何時從 docker-compose.yml “繼承”。您的特定項目可能需要在每個dev和prod環境中進行配置,以覆蓋基礎環境中的相同內容,因此需要覆蓋“父”/ base docker-compose.yml環境中的內容。請考慮以下問題: https://github.com/docker/compose/issues/3729 - 這表明可以覆蓋的內容存在限制,特別是如果要移動父 docker-compose.yml 中存在的配置項。更好的方法是在 docker-compose.yml 中只包含所有環境中的項目,並在特定環境的文件中具有特定內容,例如 docker-compose.prod.yml </代碼>