开发团队的Docker工作流程

19

我们团队目前使用vagrant作为开发环境。现在我想用docker替换它,但是我无法理解团队使用docker的工作流程。

这就是困扰我的问题:使用vagrant时,我会在项目仓库中创建一个Vagrantfile,并且每个开发人员都会拉取该仓库并运行vagrant up。如果项目需要对环境进行一些更改,则我会编辑Vagrantfile、chef配方或requirements文件,开发人员必须运行vagrant provision来获得更新的环境。

但是对于docker,我看到至少有两种选择:

  • 创建一个Dockerfile并将其放入仓库中,每个开发人员都从其中构建镜像。在每次更改时,他们重新构建自己的镜像。
  • 构建一个镜像,将其放置在服务器上,每个开发人员都拉取镜像并运行。在每次更改时,在服务器上重新构建镜像(可能会有一些自动重建和自动拉取脚本)。

Docker的哲学是“一次构建,随处运行”,但同时我们在仓库中也有一个Dockerfile...你对此有何想法?你们团队又是如何做的呢?

2个回答

11

Docker更适用于生产环境而非开发环境

Docker是一种部署工具,用于将应用程序打包到生产环境(或测试环境)。它并不是一种开发工具,而是为已经开发好的应用程序创建一个隔离的运行环境,在服务器、云端或笔记本电脑上运行。

使用Dockerfile文档化打包过程

我认为在你的项目中使用Dockerfile很好。类似于Vagrant文件,它是一种可执行文档,描述了您的生产环境应该是什么样子的。任何新加入你项目的人都可以运行该文件,获得一个打包好且准备就绪的容器。太棒了!

使用注册表集成Docker

如果你将Docker集成到你的(CI)工作流程(例如测试和构建系统)中,我认为你应该提供一个(私有)Docker注册表。一个存储所有产品经过验证和测试的镜像的单一存储库肯定会加快创建新的测试或生产系统的速度(例如扩展你的应用程序或设置演示或客户安装)。如果你的产品是开源的,请考虑使用公共的Docker索引,这样人们就可以在那里找到你的东西。你可以配置构建系统在每次(成功)构建后创建一个新的Docker镜像并将其推送到注册表中。由于镜像是分层的(并且这些层是共享的),因此这将很快而且不会占用太多磁盘空间。

如果你想在开发中集成Docker,我并没有看到太多可能性:

  • 你可以创建一个包含最终镜像的存储库(如上所述)
  • 或者你可以使用Docker镜像进行开发(例如运行MongoDB)

也许你有一个A团队,他们需要针对B团队的API进行编程,并且总是需要一个运行中的B团队产品实例。那么你可以将该产品打包到一个Docker镜像中,并与A团队共享。在这种情况下,B团队应该在存储库中提供该镜像(而A团队不必关心如何构建它并将其用作黑匣子)。


编辑:如果你依赖许多外部应用程序

为了更清晰地表达“团队A和团队B”的概念:如果你在开发一个应用程序时需要用到其他工具,比如来自另一个团队的应用程序、MongoDB或Elasticsearch等,你可以将这些应用程序打包成Docker镜像,运行它们(本地)并对它们进行开发。你也有很大的机会在公共Docker索引中找到流行的应用程序(比如MongoDB)。因此,你可以直接拉取并启动它们,而不是手动安装它们。但是,为了组成这样的环境,你还需要再次使用Vagrant。

你也可以使用Docker来创建测试环境(构建和运行镜像并对其进行测试)。但这不能替代在开发中使用Vagrant。

Vagrant + Docker

我建议两者都使用。提供一个Vagrantfile来构建开发环境,并提供一个Dockerfile来构建生产环境。

还可以查看http://docs.vagrantup.com/v2/provisioning/docker.html。自从一段时间以来,Vagrant就已经与Docker集成在一起了,所以你可以使用Vagrant创建Docker容器/环境。


@fox - 这就是我所说的 A团队和B团队 的意思。如果你要开发一个应用程序来对抗许多其他工具,例如另一个团队的应用程序、MongoDB或Elasticsearch,你可以将这些应用程序打包成Docker镜像,在本地运行并进行开发。你也有很大的机会在公共Docker Index中找到这些应用程序。因此,你不必手动安装它们,只需拉取并启动它们即可。但是,要组建这样的环境,你还需要再次使用Vagrant。 - Thomas Uhrig

7
我在 Docker 工作。
把 Docker(和 Docker index/registry)想象成 Git。你不必做得太复杂。如果更改 Dockerfile,更新映像是一项廉价且快速的操作。如果在我们的 registry 中使用“Trusted Builds”,则可以根据需要自动构建任何分支。
这些是基本的构建块,但在开发中非常有效。Docker 本身是在 Docker 容器内构建和开发的,因此我们知道它可以正常工作。

4
你们的团队是通过镜像仓库分享 Dockerfile 还是镜像本身?前者意味着每个开发人员都有自己的工作环境镜像?将项目文件添加到 Docker 容器里是由个人开发人员负责,还是这部分包含在 Dockerfile 中?在 Git 工作流中,提交通过中央仓库与其他人共享;如果 Docker 是等效的,我希望从镜像仓库中拉取最新的镜像,但我发现这会带来一些问题,比如项目文件处于不同的状态(例如 git 分支等)。我仍然不能确定你的答案的意思。 - Aaron Storck
整个团队使用Docker工作流似乎对我来说不太清晰。我看到了部署的好处,但理想情况下,我希望开发的内容与部署的内容完全一致。这意味着对于Node等,我需要从我的开发工作站实时访问代码等内容。 - mgoetzke

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接