docker-為開發和生產組成相同的配置，但僅在開發中啟用主機和容器之間的代碼共享

Question

由於使用docker的最重要好處是使dev和prod env保持相同，因此我們排除使用兩個不同docker-compose.yml的選項

假設我們有一個Django應用程序，我們使用gunicorn進行生產，並且有一個專用的apache2作為反向代理（該apache2在設計上超出了docker）。 因此，此應用程序（docker-compose）只有兩部分，即web （Django）和db （mysql）。 數據庫部分沒有任何問題。

對於Django部分，沒有docker的dev例程將使用venv和python3 manage.py runserver或IDE提供的任何快捷方式。 我們可以愉快地更改我們的代碼，開發服務器很聰明，可以立即進行更改和反映。

當docker進入時，事情變得棘手，因為所有源代碼都應打包到映像中，這給我們的開發人員帶來了很大的開銷，需要一次又一次地重新創建映像和容器。 一個人可能有以下解決方案（我發現這不是很優雅）：

• 在docker-compose.yml使用volume將源代碼文件夾安裝到容器中，以便主機源代碼文件夾中的所有更改將自動反映在容器中，然后gunicorn將拾取更改並進行反映。 ---這確實消除了大多數重新創建容器的開銷，但是我們不能在生產中使用相同docker-compose.yml ，因為這會引入對主機服務器源代碼的依賴性。

• 我知道有一個命令行選項可將主機文件夾安裝到容器，但據我所知，此選項僅存在於docker run而不存在於docker-compose 。 因此，使用不同的命令在不同的環境中啟動服務是另一個死角。 （ 我對此不是100％的確定，因為我對docker還是很陌生，如果我錯了，請糾正我 ）

TLDR; 我該如何設置我的環境

• 我僅對dev和prod使用一個docker-compose.yml
• 我無需重新創建Docker容器即可輕松進行實時更改

非常感謝！

Answer 1

我還喜歡將盡可能多的功能添加到單個docker-compose.yml文件中。 我會考慮一些策略：

1. 為產品和開發人員定義不同的服務。 因此，您將運行docker-compose up dev或docker-compose up prod或docker-compose run dev 。 這里有一些復制品，但通常不是很多。

2. 使用多個docker-compose.yml文件並將其合並。 例如： docker-compose -f docker-compose.yml -f docker-compose.prod.yml up -d 。 此處有更多詳細信息： https : //docs.docker.com/compose/extends/

我通常只是注釋掉我的卷部分，但這可能不是最好的解決方案。

Answer 2

在docker-compose.yml中將django服務定義為

services:
  backend:
    image: backend

然后為dev添加文件： docker-compose.dev.yml

services:
  backend:
    extends:
      file: docker-compose.yml
      service: backend
    volume: local_path:path

要啟動產品，只需docker-compose up

為dev docker-compose -f docker-compose.yml -f docker-compose.dev.yml up

要熱重載dev django應用，只需重載gunicorn ps aux | grep gunicorn | grep greencar_proj | awk '{ print $2 }' | xargs kill -HUP ps aux | grep gunicorn | grep greencar_proj | awk '{ print $2 }' | xargs kill -HUP