一行代码部署你的测试环境-附完整docker脚本及踩坑经验

15 阅读5分钟

🚀 Docker 部署全流程经验总结:从本地打包到服务器上线

本文中将分享一系列使用 Docker 部署 Nuxt 应用的实战经验。从本地构建镜像到将其上传到服务器并成功运行,我们逐步详细地讲解了每个环节,涵盖了遇到的问题与解决方案。无论你是初学者还是经验丰富的开发者,都能从中获得帮助和启发。

💡
0509更新!!!!
为了后续CI/CD建设,最好还是选择直接从服务器拉远程仓库以及构建镜像,一个是上传太多测试包不好管理,二是每次都要手动操作很久,先本地上传,再到服务器上解析,非常麻烦,所以问了后端docker镜像用的啥,给了一个稳定的镜像之后网络问题就解决了,再完善下仓库中的runtest脚本,每次部署只要拉取更新,然后执行脚本即可,只需要一行命令运行docker脚本就可以完成测试环境的部署!!!

#!/bin/bash

# 构建并运行 Docker 镜像的脚本
# 使用此脚本前,请确保 Dockerfile 已准备好,并已安装 Docker

APP_NAME="my-nuxt-app"
IMAGE_TAG="v1.0.0"
CONTAINER_PORT=3000
HOST_PORT=yourport

echo "🔄 开始构建镜像: ${APP_NAME}:${IMAGE_TAG}"
docker build -t ${APP_NAME}:${IMAGE_TAG} .

echo "🧹 清理旧容器(如存在)"
docker rm -f ${APP_NAME} 2>/dev/null || true

echo "🚀 启动新容器..."
docker run -d \
  --name ${APP_NAME} \
  -p ${HOST_PORT}:${CONTAINER_PORT} \
  ${APP_NAME}:${IMAGE_TAG}

echo "✅ 部署完成!访问地址: http://<your-server-ip>:${HOST_PORT}"

1. ✅ 成功的链路:一气呵成的打包与部署

1.1 🔧 本地打包配置:确保跨架构兼容

目标:确保 Docker 镜像能够在不同架构的机器上平稳运行,不会因为架构差异导致运行失败。

步骤

  1. 修改 Dockerfile 配置

    为了确保在不同架构机器上顺利运行,我们在 Dockerfile 中加入了 --platform=linux/amd64 参数。这是为了指定构建的镜像使用 amd64 架构,避免架构不一致的问题。

    FROM --platform=linux/amd64 node:18-alpine AS builder
    
  2. 在本地构建 Docker 镜像

    通过以下命令构建镜像,确保在本地生成的镜像符合目标架构。

    docker build -t <my-app>:v1.0.0 .
    
  3. 导出镜像为 .tar

    本地构建完成后,我们将镜像导出为 .tar 包,这样就可以方便地上传到远程服务器进行部署。

    docker save -o <my-app>.tar <my-app>:v1.0.0
    

1.2 🚚 将镜像上传到服务器:快速部署

目标:将本地构建的 Docker 镜像上传至服务器,并确保在服务器上成功加载。

步骤

  1. 上传 .tar 包到服务器

    我们使用 scp 命令将 .tar 包从本地上传到服务器,路径选择在服务器的 /home/wanglu/ 目录。

    scp <my-app>.tar <myip>:/home/xxx/
    
  2. 加载 Docker 镜像

    上传完成后,登录服务器并使用 docker load 命令加载镜像:

    docker load -i /home/xxx/<my-app>.tar
    

1.3 🚀 启动 Docker 容器:快速访问

目标:确保容器在服务器上成功启动,并能够通过端口映射访问。

步骤

  1. 启动容器并映射端口

    使用以下命令启动容器并将容器的 3000 端口映射到服务器的 3009 端口:

    docker run -p 3009:3000 <my-app>:v1.0.0
    
  2. 验证容器状态

    使用 docker ps 命令确认容器的状态为 Up,确保容器正在运行。

    docker ps
    
  3. 访问应用

    在浏览器中访问服务器的 IP 地址与端口,确保应用能够正常运行:

    http://<服务器IP>:3009
    

2. ❌ 不成功的链路:遇到问题的反思与解决

2.1 🚫 使用不一致架构的 .tar

问题

第一次上传时,上传了一个与目标服务器架构不匹配的 .tar 包(错误使用了 ARM 架构的包),导致容器无法启动,出现 exec format error 错误。

解决方案

确保本地构建镜像时,使用 --platform=linux/amd64 来明确指定架构为 amd64。上传前确认 .tar 包的架构与目标服务器一致。


2.2 🛑 在服务器上打包失败

问题

尝试将代码库上传到服务器,并在服务器上重新构建 Docker 镜像的链路,这种办法更有利于CI/CD建设,但由于服务器的网络环境问题,始终无法拉取基础镜像(例如nuxt应用需要的 node:18-alpine)。所以几次尝试未果之后就放弃了,选择了直接上传tar包到服务器然后再解析。

解决方案

由于服务器的网络限制,建议直接在本地构建并导出 .tar 包。这样可以避免因网络问题无法访问 Docker Hub。


3. 🧠 总结经验:成功部署的关键

  1. 确保架构一致性:避免架构不匹配引发的 exec format error,始终确认本地构建的镜像与目标服务器的架构一致。特别是 amd64arm64 架构之间的差异,要谨慎处理。
  2. 利用 .tar 包上传:在网络问题或拉取镜像失败的情况下,使用 docker save 导出镜像为 .tar 包,避免直接在服务器上拉取镜像或构建。
  3. 避免在服务器上构建镜像:当服务器网络环境不稳定时,最好先在本地构建好镜像并通过 .tar 包上传到服务器,这比在服务器上重新构建镜像更加高效。

4. 📈 展望未来:如何避免常见问题

  • 镜像架构的选择:始终确认目标服务器的架构,选择适合的镜像版本。对于大多数云服务平台,amd64 架构通常更为常见,因此推荐优先使用该架构。
  • 网络问题解决方案:如果遇到网络问题无法从 Docker Hub 拉取镜像,可以尝试搭建本地镜像仓库,或者使用镜像加速器来提高镜像拉取速度。

希望这篇文章能让你在实际操作中更加得心应手不踩今天让我吐血的坑!🚀