在实际软件工程和运维交付中很多开发者已经不再满足于只完成国内项目。海外市场尤其是欧美客户对 DevOps 自动化、容器化迁移和 CI/CD 流水线的需求明确预算也相对更高。一个典型的场景是帮助客户将老旧应用或本地部署的软件“搬家”到云上实现容器化封装和自动化部署。这类工作单笔报价可能在 80 到 800 美元不等但背后需要扎实的 Docker、持续集成和环境诊断能力。本文将以一个真实场景为例客户有一个旧的 Java Web 应用可能是 War 包直接部署在 Tomcat 上希望将它容器化并建立 GitLab CI/CD 流水线实现代码提交后自动构建镜像并部署到测试环境。我们将从环境准备、Dockerfile 编写、Compose 编排、CI/CD 配置、常见故障排查四个环节完整走通这个交付流程。1. 理解客户需求和交付标准在开始动手之前必须先明确客户要的到底是什么。海外客户通常不会只说“帮我弄一下 Docker”而是会给出明确的验收标准。1.1 常见需求清单客户需求可能包括将现有应用Java/Python/Node.js打包成 Docker 镜像。编写docker-compose.yml以便一键启动所有依赖服务如数据库、缓存。配置 GitLab CI/CD实现提交代码到特定分支自动构建镜像并推送到私有仓库。提供部署脚本或文档说明如何在生产服务器上拉取镜像并启动服务。确保容器内的应用日志可以导出到外部文件或日志收集系统。说明如何更新应用重新构建镜像、替换容器。1.2 环境与权限确认在报价和开工前必须确认以下信息客户代码库访问权限GitLab/GitHub 账号是否已授权。现有应用的开发语言、框架、依赖库清单。当前部署方式物理机、虚拟机、现有容器。目标环境客户自己的服务器、AWS、Azure 还是其他云。镜像仓库地址和凭证Docker Hub、私有仓库。生产服务器的 SSH 访问权限如果需要协助部署。如果客户无法提供完整信息建议先做一个简单的探索性交付例如只做 Docker 化再分阶段完成 CI/CD。2. 本地环境准备与工具链配置海外项目远程协作本地环境必须稳定且可复现。下面以 Windows/WSL2 或 Linux 环境为例。2.1 安装 Docker 并验证虚拟化支持Docker 安装本身不难但经常在 Windows 上因虚拟化未开启而失败。在 Windows 上安装 Docker Desktop确认虚拟化已开启重启电脑进入 BIOS/UEFI 设置通常在启动时按 F2、Del 或 Esc。找到 Virtualization TechnologyVT-x 或 AMD-V并启用。保存设置并重启。安装 Docker Desktop从 Docker 官网 下载安装包。安装过程中勾选“使用 WSL 2 而不是 Hyper-V”推荐兼容性更好。安装完成后重启。验证安装 打开命令行PowerShell 或 WSL2运行docker --version docker-compose --version如果出现版本号说明安装成功。如果遇到 “Virtualization support wasn’t detected” 错误说明虚拟化未正确开启或 WSL2 未安装。在 Linux 上安装 Docker Engine以 Ubuntu 20.04 为例# 更新包索引 sudo apt update # 安装依赖 sudo apt install apt-transport-https ca-certificates curl software-properties-common # 添加 Docker 官方 GPG 密钥 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - # 添加 Docker 仓库 sudo add-apt-repository deb [archamd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable # 安装 Docker Engine sudo apt update sudo apt install docker-ce docker-ce-cli containerd.io # 将当前用户加入 docker 组避免每次用 sudo sudo usermod -aG docker $USER # 重新登录或重启使分组生效 newgrp docker # 验证 docker --version2.2 配置镜像加速和常用工具国内访问 Docker Hub 可能较慢建议配置镜像加速器。修改或创建/etc/docker/daemon.json{ registry-mirrors: [ https://registry.docker-cn.com, https://docker.mirrors.ustc.edu.cn ] }重启 Docker 服务sudo systemctl daemon-reload sudo systemctl restart docker同时安装常用工具# 安装 docker-compose如果未随 Docker Desktop 安装 sudo curl -L https://github.com/docker/compose/releases/download/v2.24.0/docker-compose-$(uname -s)-$(uname -m) -o /usr/local/bin/docker-compose sudo chmod x /usr/local/bin/docker-compose3. 将一个典型 Java Web 应用容器化假设客户有一个基于 Spring Boot 的 Web 应用目前通过java -jar运行。目标是把它打包成 Docker 镜像。3.1 分析现有项目结构项目目录可能如下old-java-app/ ├── src/ ├── pom.xml ├── target/ │ └── app.jar └── application.yml3.2 编写 Dockerfile在项目根目录创建Dockerfile# 使用官方 OpenJDK 运行时作为父镜像 FROM openjdk:8-jre-slim # 设置工作目录 WORKDIR /app # 将 jar 文件复制到容器中 COPY target/app.jar app.jar # 复制配置文件如果有 COPY application.yml application.yml # 声明运行时容器暴露的端口 EXPOSE 8080 # 指定容器启动时运行的命令 ENTRYPOINT [java, -jar, app.jar]注意如果客户用的是 Java 11 或 17需要将基础镜像改为openjdk:11-jre-slim或openjdk:17-jre-slim。务必与客户确认 JDK 版本。3.3 构建镜像并测试在项目根目录执行docker build -t old-java-app:1.0 .构建完成后运行容器docker run -d -p 8080:8080 --name java-app-container old-java-app:1.0访问http://localhost:8080确认应用正常响应。3.4 处理常见容器化问题问题1应用启动需要连接数据库或缓存如果应用依赖 MySQL、Redis 等最佳做法是使用docker-compose.yml编排多个服务。创建docker-compose.ymlversion: 3.8 services: app: image: old-java-app:1.0 ports: - 8080:8080 depends_on: - mysql - redis environment: - SPRING_DATASOURCE_URLjdbc:mysql://mysql:3306/appdb - SPRING_REDIS_HOSTredis mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: rootpass MYSQL_DATABASE: appdb volumes: - mysql_data:/var/lib/mysql redis: image: redis:6.2-alpine volumes: mysql_data:然后使用docker-compose up -d启动所有服务。问题2时区不对在 Dockerfile 中设置时区FROM openjdk:8-jre-slim # 设置时区 RUN ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime echo Asia/Shanghai /etc/timezone WORKDIR /app COPY target/app.jar app.jar EXPOSE 8080 ENTRYPOINT [java, -jar, app.jar]问题3容器内应用日志看不到修改启动命令让日志输出到标准输出ENTRYPOINT [java, -jar, app.jar, --logging.file.name/dev/stdout]或者如果使用 Logback/Log4j配置日志输出到控制台。4. 配置 GitLab CI/CD 实现自动构建客户通常希望代码提交后自动构建 Docker 镜像并推送到仓库。这里以 GitLab CI 为例。4.1 准备 GitLab Runner客户可能已有 GitLab 实例也可能使用 GitLab.com。需要确认GitLab 项目地址。是否已安装并注册 GitLab Runner负责执行 CI 任务的组件。如果客户没有 Runner可以协助安装一个。以在 Ubuntu 服务器上安装为例# 添加 GitLab Runner 仓库 curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash # 安装 GitLab Runner sudo apt install gitlab-runner # 注册 Runner需要从 GitLab 项目设置中获取 URL 和 token sudo gitlab-runner register在注册过程中选择执行器executor时推荐使用docker这样每次任务都在干净的容器中运行。4.2 编写 .gitlab-ci.yml在项目根目录创建.gitlab-ci.yml# 定义流水线阶段 stages: - build - deploy # 变量定义 variables: DOCKER_IMAGE: registry.example.com/group/old-java-app # 替换为实际镜像仓库地址 DOCKER_TAG: $CI_COMMIT_REF_SLUG # 构建镜像任务 build_image: stage: build image: docker:20.10.16 services: - docker:20.10.16-dind variables: DOCKER_HOST: tcp://docker:2375 DOCKER_DRIVER: overlay2 before_script: - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY script: - docker build -t $DOCKER_IMAGE:$DOCKER_TAG . - docker push $DOCKER_IMAGE:$DOCKER_TAG only: - main - develop # 部署到测试环境示例 deploy_to_test: stage: deploy image: alpine:3.16 before_script: - apk add --no-cache openssh-client - eval $(ssh-agent -s) - echo $SSH_PRIVATE_KEY | tr -d \r | ssh-add - - mkdir -p ~/.ssh - chmod 700 ~/.ssh script: - ssh -o StrictHostKeyCheckingno deploytest-server.example.com docker pull $DOCKER_IMAGE:$DOCKER_TAG - ssh -o StrictHostKeyCheckingno deploytest-server.example.com docker stop java-app || true - ssh -o StrictHostKeyCheckingno deploytest-server.example.com docker run -d --rm --name java-app -p 8080:8080 $DOCKER_IMAGE:$DOCKER_TAG only: - develop4.3 配置 CI/CD 变量在 GitLab 项目设置中需要设置以下变量Settings → CI/CD → VariablesCI_REGISTRY_USER镜像仓库用户名。CI_REGISTRY_PASSWORD镜像仓库密码。SSH_PRIVATE_KEY用于登录测试服务器的 SSH 私钥。注意这些变量应标记为 Protected 或 Masked避免在日志中泄露。5. 交付前自检与客户验收清单完成代码和配置后不要直接交付。先按以下清单自检。5.1 镜像构建与运行检查[ ] Dockerfile 能否在干净环境中成功构建[ ] 构建的镜像是否尽可能小使用多阶段构建如果适用[ ] 容器启动后应用是否健康检查日志、端口响应[ ] 容器内时区、语言环境是否正确[ ] 如果有数据卷路径权限是否正确5.2 CI/CD 流水线检查[ ] 推送代码到对应分支后Pipeline 是否自动触发[ ] 构建阶段是否成功生成并推送镜像[ ] 部署阶段能否成功拉取镜像并启动容器[ ] 失败时是否有足够日志排查问题5.3 文档与交付物检查[ ] 是否提供Dockerfile和docker-compose.yml[ ] 是否提供.gitlab-ci.yml或相应 CI 配置[ ] 是否编写了部署指南包括环境要求、启动命令、更新流程[ ] 是否说明如何查看日志、调试容器6. 常见故障与排查路径即使测试通过客户在生产环境也可能遇到问题。提前准备好排查指南能减少后期支持成本。6.1 Docker 服务启动失败现象docker ps无输出或提示Cannot connect to the Docker daemon。排查步骤检查 Docker 服务状态sudo systemctl status docker如果未运行尝试启动sudo systemctl start docker查看启动日志sudo journalctl -u docker.service --since 1 hour ago常见原因磁盘空间不足、内存不足、虚拟化未开启。6.2 镜像构建失败现象docker build时提示找不到文件或依赖。排查步骤确认Dockerfile中的路径是否正确路径是相对于构建上下文的。确认基础镜像存在且版本可用。检查网络是否能够拉取基础镜像。如果使用私有镜像仓库确认已登录docker login。6.3 容器启动后立即退出现象docker run后容器状态变为 Exited。排查步骤查看容器日志docker logs container_id常见原因应用启动失败、端口冲突、环境变量缺失、依赖服务未就绪。如果使用docker-compose检查depends_on是否设置正确它只控制启动顺序不等待服务就绪。6.4 GitLab CI 任务失败现象Pipeline 显示红色失败状态。排查步骤点击失败的任务查看详细日志。常见原因镜像仓库登录失败、SSH 密钥权限错误、服务器连接超时。确认 CI/CD 变量已正确设置且未过期。检查 Runner 是否在线且资源充足。7. 从一次交付到长期合作的最佳实践完成一次“软件搬家”后如果客户满意很可能会有后续的运维、监控、安全加固需求。以下做法能增加长期合作机会。7.1 代码和配置版本化将 Dockerfile、docker-compose.yml、.gitlab-ci.yml 纳入代码库。使用标签或分支管理不同环境配置。对镜像使用语义化版本号如1.2.3或 Git 提交哈希作为标签。7.2 日志与监控建议客户配置日志收集如 ELK、Loki。在容器内添加健康检查接口Spring Boot 可用 Actuator。推荐使用 Prometheus 监控容器资源使用率。7.3 安全加固使用非 root 用户运行容器在 Dockerfile 中添加USER指令。定期更新基础镜像以获取安全补丁。扫描镜像中的漏洞可用docker scan或集成到 CI 中。7.4 文档与知识转移交付时提供简洁明了的技术文档。录制一段 10 分钟以内的屏幕录像演示如何更新应用。明确后续支持范围和响应时间。海外项目交付不仅仅是技术实现更是沟通、文档和可靠性的综合体现。从一个小需求开始用专业交付建立信任后续的 80-800 美元订单会自然增多。