> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devin.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# 容器化

> 在本教程中，我们将介绍 Devin 如何配置 Docker 容器，从而标准化团队的开发环境。

<div id="creating-a-docker-container">
  ## 创建 Docker 容器
</div>

由于 Devin 可以使用终端，并且能够在自己的服务器上配置和运行软件，因此搭建 Docker 容器完全在它的能力范围之内。

我们的示例应用是一个使用 MongoDB 作为数据存储的 Go 项目。本次会话对应的是 Devin 处理一名真实开发者向某开源项目提交的 Pull Request 的版本。你可以在[这里](https://app.devin.ai/sessions/379eb9a40ff2433db49e51c95c7d9bc1?ts=1729908167981)查看完整的实时运行过程。

<div id="start-with-a-github-issue">
  #### 从一个 GitHub Issue 开始
</div>

我们从原始的 GitHub Issue 开始：

<Frame>
  ![Devin](https://cdn.sanity.io/images/2mc9cv2v/production/e8a410ab96ee363911b146bcbd923da43c25b03a-1856x746.png)
</Frame>

接下来，我们可以根据这个 Issue 的需求，为 Devin 编写一个简单的提示。我们让它阅读上面的 GitHub Issue 以获取更多上下文，同时也提供我们自己对拟议解决方案的总结，以及我们希望 Devin 最终交付的成果。

<Frame>
  ![Devin](https://cdn.sanity.io/images/2mc9cv2v/production/4caecf4fd393f5573536a5b6d57d7246b684d699-1312x612.png)
</Frame>

<div id="investigating-the-codebase">
  #### 分析代码库
</div>

Devin 首先会进行初步分析，它会读取我们关联的 GitHub Issue，并[扫描](/zh/release-notes#repo-knowledge)项目的实际代码和配置文件，以查找所需的依赖项。

<Frame>
  ![Devin](https://cdn.sanity.io/images/2mc9cv2v/production/4f146e093bd0374b5d816c5fd9f49d6a411d6c8f-1334x844.png)
</Frame>

分析完成后，Devin 接着会在其本地环境中安装 Docker，然后创建初始的 Dockerfile、docker-compose.yml 和 .dockerignore，以便开始测试容器环境。它还会配置我们的 .env 文件，使应用程序能够在新配置的容器化后端环境中运行。

<Frame>
  ![Devin](https://cdn.sanity.io/images/2mc9cv2v/production/710b051e9b5f75d3b5492f554fee786e212dc129-1314x1370.png)
</Frame>

<div id="testing-the-container">
  #### 测试容器
</div>

接下来 Devin 会开始测试每个容器，先从我们的 MongoDB 服务器开始，然后再测试我们的 Go 运行环境。容器启动并就绪后，Devin 会继续测试应用本身。通过查看 Devin 的[命令历史](/zh/work-with-devin/devin-session-tools#shell-command-history)，我可以看到它找到了我们的 Swagger API 定义，并将其加载到内置的 [Browser](/zh/work-with-devin/devin-session-tools#interactive-browser) 中，以了解后端 API 的工作方式。

<Frame>
  ![Devin](https://cdn.sanity.io/images/2mc9cv2v/production/3cee193ba84dcea344e4a7fd829ae39c0d602270-2720x1422.png)
</Frame>

随后 Devin 构造了一个 curl 请求，用来测试后端 API 是否按其设计规范运行并返回预期结果。

<Frame>
  ![Devin](https://cdn.sanity.io/images/2mc9cv2v/production/de15b455421e2320b5dd6023bd0d4d47aaff2e7c-1208x710.png)
</Frame>

<div id="debugging">
  #### 调试
</div>

由于我们遇到了 **Connection refused** 错误，Devin 立刻开始调试并修正 Docker 配置。这是一种常见模式：在单次会话过程中，Devin 能够自我纠错。Devin 很快修复了配置问题，重启了 Docker 容器，并为我们总结了已经完成的工作。

<Frame>
  ![Devin](https://cdn.sanity.io/images/2mc9cv2v/production/ad2d884abb70c7dd74614addbe1d8e111ebf7d53-1356x2208.png)
</Frame>

当我们将 Devin 的工作与[实际项目中的 PR](https://github.com/Ratnesh-Team/Rehabify/pull/137)进行对比时，可以看到一些明显的差异和改进：

* Devin 在现有 Dockerfile 的基础上新增了一个 docker-compose.yml 文件。这为我们提供了更精细的编排设置，例如定义网络工作方式、卷 (volume) 的配置方式，以及各个服务之间的依赖关系。
* Devin 将构建流程从 `go mod tidy` 修改为一种可以在 Docker 构建过程中缓存部分依赖的方式。
* Devin 构建的是一个静态链接的 Go 二进制文件，而不是动态链接的，这样对我们的 Docker 构建来说更轻量。
* Devin 为 HTTPS 配置了 CA 证书，并让我们可以使用 .env 文件进行配置，而不是直接传入环境变量。
* 最值得注意的是，Devin 在我们的 Docker 配置中添加了一个 MongoDB 服务，而项目中的 PR 并没有这样做。该 PR 假定开发者已经有一个单独运行的 MongoDB 实例。

<Frame>
  ![Devin](https://cdn.sanity.io/images/2mc9cv2v/production/7607ba8b57199a26812cb8f4c7129ee5a97ffcdb-1818x1206.png)
</Frame>

在 13 分钟内，Devin 已经按照最佳实践为这个项目的后端构建好了 Docker 容器，对其进行了测试，并撰写了详尽的工作总结。现在就通过[注册](https://cognition.com/get-started#company)团队版 Devin 账号，在你自己的代码库上尝试容器化相关的提示吧。