如何在 terraform 中使用 docker 文件

Question

Terraform 有一个专门的“docker”提供程序，它可以处理图像和容器，并且可以使用私有注册表并为其提供凭据，参见。注册表文件。但是，我没有找到任何Dockerfile不使用单独注册表直接提供 a 的方法。处理对 docker 文件本身的更改的问题已经解决，例如在这个问题中，尽管没有使用 terraform。

我可以做一些解决方法：不使用专用的 docker 提供程序，而是使用其他一些提供程序（尽管我不知道是哪一个）。或者，我可以开始自己的私人注册表（可能与terraform泊坞窗容器），在本地运行的泊坞窗命令其生成的图像文件（从terraform这可能使用来完成null_resource的的null供应商），然后继续与那些。

这些解决方法对我来说都没有多大意义。有没有办法直接使用 terraform 部署 docker 文件中描述的 docker 容器？

Answer 1

Terraform 是一种配置工具而不是构建工具，因此从源构建 Docker 镜像等工件并不真正在其范围内。

就像处理 EC2 镜像 (AMI) 的常用和推荐方法是让其他工具构建它们，而 Terraform 只是简单地使用它们，同样的原则适用于 Docker 镜像：常用和推荐的路径是使用其他系统构建你的 Docker 镜像——例如一个 CI 系统——并将结果发布到 Terraform 的 Docker 提供者能够在配置时找到它们的地方。

这种分离的主要原因是它将构建新工件和使用工件供应基础设施的关注点分开。这在很多方面都很有用，例如：

• 如果您正在更改一些不需要新映像的基础架构，那么您可以重新使用您已经构建的映像。
• If there's a problem with your Dockerfile that produces a broken new image, you can easily roll back to the previous image (as long as it's still in the registry) without having to rebuild it.

It can be tempting to try to orchestrate an entire build/provision/deploy pipeline with Terraform alone, but Terraform is not designed for that and so it will often be frustrating to do so. Instead, I'd recommend treating Terraform as just one component in your pipeline, and use it in conjunction with other tools that are better suited to the problem of build automation.

If avoiding running a separate registry is your goal, I believe that can be accomplished by skipping using docker_image altogether and just using docker_container with an image argument referring to an image that is already available to the Docker daemon indicated in the provider configuration.

docker_image retrieves a remote image into the daemon's local image cache, but docker build writes its result directly into the local image cache of the daemon used for the build process, so as long as both Terraform and docker build are interacting with the same daemon, Terraform's Docker provider should be able to find and use the cached image without interacting with a registry at all.

For example, you could build an automation pipeline that runs docker build first, obtains the raw id (hash) of the image that was built, and then runs terraform apply -var="docker_image=$DOCKER_IMAGE" against a suitable Terraform configuration that can then immediately use that image.

Having such a tight coupling between the artifact build process and the provisioning process does defeat slightly the advantages of the separation, but the capability is there if you need it.