Docker容器化部署实战：宁德项目CI/CD流水线搭建
容器化技术已经彻底改变了软件的交付方式。在我们团队为宁德企业客户开发和部署的项目中Docker已成为标准化的打包和部署工具。结合GitLab CI/CD（或GitHub Actions）可以实现从代码提交到生产上线的全自动流水线大大提升了交付效率和部署可靠性。本文将以一个前后端分离的Web项目为例完整演示Docker容器化和CI/CD流水线的搭建过程。
Dockerfile编写最佳实践
好的Dockerfile是容器化的基础。前端Vue/React项目的Dockerfile典型写法：第一阶段使用node:alpine镜像执行npm install和npm build构建产物输出到dist目录；第二阶段使用nginx:alpine镜像将构建产物复制到nginx的html目录暴露80端口。这种多阶段构建（Multi-stage Build）的好处是最终镜像只包含nginx和静态文件不含node_modules等构建依赖镜像体积通常不超过50MB。后端Node.js项目的Dockerfile类似只是最终镜像保留node运行时和node_modules依赖。Python项目推荐使用python:slim镜像而非完整的python镜像以减小体积。每个Dockerfile都应该加入`.dockerignore`排除node_modules .git .env等不需要的文件。
docker-compose编排多容器应用
实际项目往往由多个服务组成需要docker-compose进行统一编排。一个典型的Web项目compose文件包含以下服务：`frontend`前端静态文件服务（nginx镜像）、`backend`后端API服务（node/python镜像）、`db`数据库服务（mysql/postgres镜像）、`redis`缓存服务（redis镜像）、`nginx`反向代理服务（负责路由分发和SSL终止）。每个服务通过内部网络互相通信外部只暴露nginx服务的80/443端口。使用`docker-compose up -d`一条命令即可启动全部服务极大简化了开发环境的搭建和生产环境的部署。数据卷（Volume）用于持久化数据库数据和上传文件即使容器重建数据也不会丢失。
CI/CD流水线设计
我们使用GitLab CI/CD作为自动化流水线工具（GitHub Actions逻辑类似）。`.gitlab-ci.yml`文件定义了以下几个Stage：lint（代码风格检查）、unit-test（单元测试）、build（Docker镜像构建并推送到私有镜像仓库）、deploy-staging（部署到预发布环境）、integration-test（集成测试和E2E测试）、deploy-production（部署到生产环境）。每个Stage可以设置触发条件（如只有master分支才触发生产部署）和环境变量（如数据库密码通过GitLab CI/CD Variables安全管理）。整个流水线从代码push到生产部署完成通常在10-15分钟以内具体取决于测试套件的复杂度。
生产环境部署策略
生产环境的容器部署需要考虑高可用和零停机更新。我们采用的方案是在应用服务器上部署Docker Swarm集群（小型项目3台节点足够）使用Stack方式管理服务。更新时通过`docker service update --update-parallelism 1 --update-delay 10s`实现滚动更新每次停止并重启一个容器等待健康检查通过后再更新下一个确保服务始终可用。数据库的升级则需要更加谨慎先备份再在从库测试确认无误后切换主库。所有的部署操作都通过CI/CD流水线触发不手动SSH到服务器执行避免了人为失误。日志收集通过ELK Stack（Elasticsearch + Logstash + Kibana）集中查看和分析所有容器的运行日志。