我认为没有单一的“仅使用这个”答案 - 正如您已经概述的那样，有不同的可行概念可用。
部署到暂存/生产/预生产
一）
我是否将它作为我在第一步中创建的 Dockerfile 中的依赖项，并且每次都从头开始重新创建容器？
这无疑是最 docker`ish 的方式，并且完全符合他的 docker 哲学。它具有高度便携性、可重复性和适合任何东西，从一个容器到“群”数千个。例如。当您需要更多容器时，这个概念没有问题突然水平扩展，可以说是由于流量/负载大。
这也符合在 docker 容器中只有配置/数据应该是动态的，而不是代码/二进制文件/工件的想法
应该选择此策略用于生产用途，因此当不频繁部署时。如果您关心容器重建期间的停机时间（升级时），那么也有很好的概念可以解决这个问题。
我们将其用于生产和预生产实例。
b)
或者，我是否部署了一次容器，但里面有程序
安装 utils 的 Dockerfile，通过命令从 repo 中提取代码
还是通过钩子？
对于非常频繁的部署，这是一种更常见的做法。您可以采用 pull（您所说的）或 push（docker cp / ssh scp）概念，而我猜后者在这种环境中是首选。
我们将此用于暂存实例的任何类型的策略，它基本上应该反映当前的“代码库”及其状态。我们也将它用于冒烟测试和 CI，但取决于应用程序。如果应用程序实际上更改了很多依赖项，并且干净的构建需要重新构建以真正确保按预期测试内容，那么我们实际上会在 CI 期间重新构建映像。
配置管理
1.
如果容器正在运行，但我想更改一些设置，该怎么办，
说，nginx？我是否将这些更改添加到 Dockerfile 并重新创建
图片？
我没有将其用作 c)，因为这是配置管理，而不是应用程序部署，并且根据您的情况，此问题的答案可能非常复杂。一般来说，如果重新部署需要更改配置，这取决于您的配置管理，您是否可以使用 b) 或始终必须使用 a)。
例如如果您使用 https://github.com/markround/tiller 和 consul 作为后端，您可以将配置更改推送到 consul，使用 tiller 重新生成配置，同时使用 consul watch -prefix /configuration tiller 作为监视任务以对这些值更改做出反应。
这使您可以去 b) 并修复配置
您也可以在部署时使用https://github.com/markround/tiller，例如更改 ENV vars 或某种 yml 文件（tiller 支持不同的后端），并在部署期间自己调用 tiller。这很可能需要您拥有 ssh 或者您在主机上使用 ssh 并使用 docker cp 和 docker exec
发展
在开发中，您通常会重用您用于生产的 docker-compose.yml 文件，但使用 docker-compose-dev.yml 将其重载到例如挂载您的代码文件夹，设置 RAILS_ENV=development，重新配置/挂载一些其他配置，如 xdebug 或更详细的 nginx 登录，无论您需要什么。您还可以添加一些虚假的 MTA 服务，例如 fermata 等
docker-compose -f docker-compose.yml -f docker-compose-dev.yml up
docker-compose-dev.yml 只是重载了一些值，不会重新定义或复制它。
根据您的配置管理功能的强大程度，您还可以在开发堆栈期间进行预安装。
我们实际上为此使用了脚手架，我们使用https://github.com/xeger/docker-compose，在运行它之后，我们使用docker exec 和docker cp 来预安装实例或暂存某些东西。一些例子在这里https://github.com/EugenMayer/docker-sync/wiki/7.-Scripting-with-docker-sync
如果您在 OSX 下开发并且由于 OSXFS / 代码共享而面临性能问题，您可能想看看http://docker-sync.io（虽然我有偏见）