所以我使用Python+Django（但对于这个问题来说并不重要）
当我编写我的代码时，我只需运行
./manage.py runserver
它包括Web服务器、静态文件、自动重载等功能。
为了将其投入生产，我使用一系列命令，例如：
./manage.py collectstatic
./manage.py migrate
uwsgi --http 127.0.0.1:8000 -w wsgi --processes=4
此外，我还有一些其他的服务，比如postgres和redis（这两者都适用于生产和开发）
所以我正在尝试使用docker（+ -compose）并且我无法理解如何用它区分生产环境和开发环境。
基本上，在docker-compose.yml文件中，您定义您的服务和镜像 - 但在我的情况下，生产环境中的镜像应该运行一个CMD，在开发环境中则是另一个CMD..
如何最好地实现这一点？
您应该创建额外的docker-compose.yml文件，例如docker-compose-dev.yml或docker-compose-pro.yml，并使用-f命令覆盖某些原始docker-compose.yml配置：
docker-compose -f docker-compose.yml -f docker-compose-dev.yml up -d
有时，我也会为不同的环境使用不同的Dockerfile，并在docker-compose-pro.yml构建部分指定dockerfile参数，但我不推荐这样做，因为这将导致重复的Dockerfile。
更新
Docker引入了多阶段构建功能 https://docs.docker.com/develop/develop-images/multistage-build/#use-multi-stage-builds ，允许为不同的环境创建Dockerfile。
Docker Compose 可以根据 .env 文件的内容构建生产环境或开发环境。
compose.yaml 文件中每个 service 的 build: 指令允许您指定用于构建服务的 Dockerfile。例如，使用 dockerfile:${nginx_Prod_Dockerfile}。每个服务需要两个 Dockerfile - 一个是 dev，另一个是 prod。
这使您可以利用相同的 compose.yaml 根据您的 .env 文件的内容构建两种环境。
请参阅文档。
您可以在环境文件中设置多个环境变量的默认值，然后将该文件作为参数传递给CLI。
这种方法的优点是您可以将文件存储在任何位置并适当命名，
例如.env.ci、.env.dev、.env.prod。
该文件路径是相对于执行Docker Compose命令的当前工作目录而言的。传递文件路径是通过选项 --env-file 完成的：
docker compose --env-file ./config/.env.dev up
通常，拥有不同的生产和开发启动工作流程是一个坏主意。您应该始终尝试保持开发和生产环境非常相似，甚至在启动应用程序的方式上也是如此。您应该始终将在不同环境之间不同的配置外部化。
具有不同的启动顺序可能是可以接受的，但是为每个环境使用多个Docker镜像（或Dockerfile）是一个非常糟糕的主意。Docker镜像应该是不可变且可移植的。
然而，您可能会有一些限制。Docker-compose允许您覆盖指定图像中的命令。有command property，它将覆盖图像中的默认命令。我建议您保持图像已准备好生产，
即在Dockerfile中使用类似CMD ./manage.py collectstatic && ./manage.py migrate && uwsgi --http 127.0.0.1:8000 -w wsgi --processes=4的内容。
在compose文件中，只需通过指定来覆盖CMD：
command: ./manage.py runserver
拥有多个Compose文件通常不是一个大问题。您可以使用一些很好的Compose文件功能，例如extends，其中一个Compose文件可以扩展另一个Compose文件，从而使您的Compose文件保持清洁和可管理。