Docker 工作流工具 转换、生成、检查和计算容器大小

它起初看起来很温和。你把一条命令粘贴到 Slack 会话中，以便你的队友启动一个本地数据库。两个月后，同样的命令出现在四个不同的频道、三个维基和一个没人记得写过的 Bash 脚本的注释中。没人知道它是否仍然有效，也不知道它适用于哪个环境。 docker run Docker 命令发展迅速。一个 Postgres 实例需要网络标志、卷挂载、重启策略、用于凭据的环境变量以及端口绑定。这是一条长达 200 个字符的单行命令，几乎无法审查、版本控制或交接。将其扩展到五个服务，你就得到了无法维护的基础设施。

有四个免费工具解决了这个问题的不同部分。按顺序使用它们，你可以在十分钟内从混乱的运行命令过渡到一个生产就绪、经过检查的容器配置。

工具 1：Docker Run 到 Compose 转换器

在使用 Docker 的工作流中，最痛苦的时刻是继承一个完全存在于某人 shell 历史中的服务。该工具将这个考古文物转化为一个规范的

这里有一个现实的例子：一个 Postgres 容器以前是用旧方式启动的。 Docker Run 转 Compose 工具 将它粘贴到转换器中，你将得到： docker-compose.yml.

这不再是只在你记住所有标志时才能正确运行的命令，而是一个可审查、可版本控制的文件。转换器处理网络别名、卷声明、重启策略和环境变量——这些都是当某人凭记忆输入时容易丢失的内容。

docker run -d \
  --name postgres-db \
  --restart unless-stopped \
  -e POSTGRES_USER=myapp \
  -e POSTGRES_PASSWORD=secretpassword \
  -e POSTGRES_DB=myapp_production \
  -v postgres_data:/var/lib/postgresql/data \
  -p 5432:5432 \
  --network app-network \
  postgres:15-alpine

在引入新服务时特别有用。不再需要问“你能发给我运行命令吗？”，而是可以直接要求提供 compose 文件——如果他们没有，可以从他们现有的内容生成。

services:
  postgres-db:
    image: postgres:15-alpine
    container_name: postgres-db
    restart: unless-stopped
    environment:
      POSTGRES_USER: myapp
      POSTGRES_PASSWORD: secretpassword
      POSTGRES_DB: myapp_production
    volumes:
      - postgres_data:/var/lib/postgresql/data
    ports:
      - 5432:5432
    networks:
      - app-network

volumes:
  postgres_data:

networks:
  app-network:

工具 2：Dockerfile 生成器

为新服务从零开始编写 Dockerfile，要么需要复制另一个项目的示例（并继承其不良习惯），要么需要花费二十分钟进行文档编写。该工具跳过了这两种情况，根据你选择的语言和运行时，提供一个生产就绪的起点。

选择 Node.js、Python、Go、PHP 或其他运行时，生成器会生成一个已经包含以下内容的 Dockerfile：

一个特定的、锁定的基镜像版本，而不是 Dockerfile 生成器 适用于情况的多阶段构建（构建阶段与运行阶段分离）

一个非 root 用户来运行应用程序

• 合理的分层顺序以最大化缓存效率 latest
• 安全友好的结构
• 这些是开发者在时间压力下编写 Dockerfile 时经常跳过的事项，当安全审计发现问题时，他们又匆忙去修复。从一个生成的模板开始，意味着你已经具备了基础的正确性。
• 输出并非直接部署——你仍然需要自定义入口点、环境变量和构建命令。但结构决策已经合理，你是在编辑而非从零开始编写。
• A .dockerignore工具 3：Dockerfile 检查器

即使是经验丰富的工程师也会写出带有细微问题的 Dockerfile。其中一些最常见的问题包括：使用

作为基镜像标签，使用

是正确的，以 root 身份运行进程，或在安装包后未清理 apt 缓存。这些问题不会导致构建失败，只是会带来安全风险、膨胀的镜像或不可重现的构建。

在进入生产环境前就发现这些问题。将你的 Dockerfile 粘贴进去，它会返回一系列警告和解释——不仅说明哪里错了，还解释了为什么重要以及应该如何修正。 latest 你在实际 Dockerfile 中常见的标志包括： ADD 当 COPY 锁定你的基镜像

这 Dockerfile检查工具 每次构建都会拉取不同的镜像；使用

以确保可重现性

• 使用 COPY 而不是 ADD — FROM node:latest 具有隐含行为（自动解压 tar 包、获取 URL）会创建不可预测的构建结果 node:20-alpine 放弃 root 权限
• 添加一个 — ADD 指令，使你的应用程序在容器中不以 root 身份运行
• 清理包缓存 会为每个镜像层增加不必要的几兆字节 USER 运行检查器需要三十秒，通常能发现任何未按清单编写 Dockerfile 的至少两个或三个问题。这是在提交 PR 之前进行部分安全性和正确性审查的廉价方式。
• 工具 4：Docker 容器资源计算器 — apt-get install 没有 && rm -rf /var/lib/apt/lists/* 开发者最常发现内存限制配置错误的时刻，是某个容器在生产环境中被 OOM 杀死，导致服务随之中断。该工具是防止这种情况发生的前置步骤。

你输入容器类型、预期负载、并发请求或进程数量以及每个工作进程的基础内存。计算器会返回带有峰值缓冲的推荐

限制。

这很重要，因为默认行为——未设置任何限制——意味着一个行为异常的容器可能会耗尽主机上所有其他服务的资源。在共享基础设施上，这就是一次事故。计算器帮助你设定现实而非随意的限制，从而避免猜测 Docker 容器资源计算器 和希望。

它在主机规模方面也很有用。如果你知道你的应用程序每个工作进程需要 256MB，并且希望运行四个工作进程，你可以在部署前计算出最小实例大小，而不是部署一个太小的实例并在负载下进行扩容。 --memory 且 --cpus 将工作流整合在一起

当设置新服务或继承旧服务时，这四个工具自然形成一个顺序： 512m 从运行命令开始。

如果你有一个可用的

命令，首先将其转换为 compose 文件。这会给你一个可审查、可版本控制的内容。

如果没有 Dockerfile，就生成一个。

1. 选择运行时，获得一个坚实的基础，然后根据你的应用进行定制。 检查 Dockerfile。 docker run 在提交前通过检查器运行它。修复它标记的问题——大多数问题可以在一分钟内解决。
2. 设置资源限制。 在部署到共享主机前，计算出现实的内存和 CPU 限制，并将其添加到你的 compose 文件中。
3. 这个流程描述起来比实际执行要长。在实践中，步骤二到四每个服务大约需要五分钟。最终结果是一个可重现、可审查且适合其运行主机的容器配置。 Docker 工作流工具：转换、生成、检查、设置容器大小 2
4. Docker 工作流工具：转换、生成、检查、设置容器大小 1 在将容器部署到共享主机之前，请计算出实际的内存和CPU限制，并将其添加到您的compose文件中。

这个流程描述起来比实际执行要长。实际上，第二到第四步每个服务大约需要五分钟。其回报是获得一个可重复、可审查，并且与运行主机配置相匹配的容器环境。

你可能也会喜欢