案例项目素材可以拉取我github上的:
https://github.com/AcademicTECHNERD/SpringCoudEurekaDemo
下面的案例将把我的product-service(也就是提供者)打包为镜像
执行maven命令:
mvn clean package -DskipTests

在根目录加一个dockerfile文件,内容如下:
我这里用的是本地的镜像,因为国内镜像的问题,在此之前可以运行docker pull openjdk:17-jdk-slim拉取到本地,具体可以看报错帖子
# 使用你已经拉取成功的本地镜像
FROM openjdk:17-jdk-slim
ENV TZ=Asia/Shanghai
WORKDIR /app
# 替换成你的实际 JAR 文件名
COPY target/product-service-0.0.1-SNAPSHOT.jar app.jar
EXPOSE 8081
ENTRYPOINT ["java", "-jar", "app.jar"]

这里发生了报错,具体报错和解决方法在另外一篇帖子:
报错: => ERROR [internal] load metadata for docker.io/library/openjdk:17-jdk-slim 解决探索与最终解决方案
执行构建命令:
docker build -t product-service:latest .
运行镜像:
docker run -d -p 8081:8081 --name product-service product-service:latest
查看服务是否运行:
docker ps
展示:
浏览器访问http://localhost:8081/products
此时就表明已经完全成功地将 product-service 打包为 Docker 镜像并运行起来了。
然后你去docker-desktop即可看到:
思考时间:
为什么要把微服务打包成 Docker 镜像,而不是本地运行?
docker打包后实现了以下环境一致性的效果:
- 无论在谁的电脑、什么系统、什么云平台运行,都是一样的;
- 消除了 "我这能跑你那不行" 的经典开发痛点;
- 包括 JDK版本、依赖、配置都封装在镜像里,不再靠系统环境。
后面部署只需要一句话的事,还可以很方便发的可以部署到 Kubernetes、云平台、远程服务器;也支持自动化部署(CI/CD),配合 Jenkins、GitHub Actions 等,用 docker-compose 可以一键启动/停止所有服务;多个微服务用一个 YAML 管理,更接近实际生产环境。
还有一个很重要的一点:本地跑只是"看着能用",但不代表部署后也没问题。
而Docker 化后的服务结构更接近线上的部署结构,还可以提前发现网络连接、端口暴露、配置差异等问题。