故事梗概

Java程序员马意浓在互联网公司维护老旧电商后台系统。

渴望学习新技术的他在工作中无缘Docker和K8s。

他开始自学Vue3并使用SpringBoot3完成了一个前后端分离的Web应用系统，并打算将其用Docker容器化后用K8s上云。

6 夺取宝剑

🔥阅读Nigel Poulton的书，自学完Docker后，马意浓知道，前后端App，各自都要制作成docker image，先部署到本地docker compose里，之后再部署到k8s云集群里。

✅这是因为Docker提供了一个完整打包app所有依赖项的一致的环境，确保应用在开发、测试和生产环境中的行为一致。

这就能实现在测试环境中所测试的image，就是在生产环境所部署的。

这是解决“在我这运行得好好的，怎么在你那不行”的问题的关键。

✅此外，将前端和后端应用容器化，需要使用等同于代码的配置文件。

这种基础设施即代码的实践，能让配置的更改广而告之，配置的执行有据可查。

这是解决“谁改了配置又不告诉大家？”问题的关键。如图1。

图1 Docker能提供完整打包app所有依赖项的一致的环境，以及让配置的更改广而告之，配置的执行有据可查

6.1 前后端App均部署到本地docker compose中的架构图

马意浓稍微修改了之前绘制的前后端App部署到本地Gradle/npm开发环境的架构图。

其实只是将前后端App的部署环境，都改成了docker compose。如图2。

图2 前后端App的部署环境都改成了docker compose

该如何让前后端App，都在本地docker compose里运行起来呢？

马意浓启动了Docker Desktop，并确认已经用自己的docker hub账号登录。

6.2 用gradle构建后端app并生成jar包

马意浓想要让所生成的后端app的docker image，仅包含刚好够运行的jar包，及其依赖项。

这样的docker image就能做到尽可能地小，以节省将其推送到Docker Hub的时间。

他于是决定，先用gradle命令构建后端app并生成jar包，然后再设法将其构建为docker image。

他打开一个Ubuntu终端窗口，进入项目文件夹中的infrastructure子文件夹。

接着运行命令docker compose up postgres pgadmin，启动了postgres数据库和pgadmin管理工具，为gradle构建做好了准备。

他又新打开一个Ubuntu终端窗口，进入项目文件夹中的back-end子文件夹。

他运行命令sdk use java 17.0.10-tem，设置好jdk当前版本。

之后，他运行命令./gradlew clean build，开始构建后端app。

等到屏幕出现了BUILD SUCCESSFUL字样后，他在文件夹build\\libs里，找到了刚刚生成的jar包shoppinglist-0.0.1-SNAPSHOT.jar。

6.3 构建后端app的docker image

马意浓又回到了back-end文件夹。因为他知道，这个文件夹里有运行docker命令所需的Dockerfile文件。

他打算使用docker buildx build命令，因为这是对旧的docker build命令的扩展。

他从资料中发现，相比后者，前者提供了多平台构建、改进的构建缓存机制以及灵活的构建结果输出等新功能。

他输入命令docker buildx build --build-arg JAR_FILE=build/libs/shoppinglist-0.0.1-SNAPSHOT.jar -t <docker-hub-username>/shopping-list-api:v1.1.local-docker-compose .，来构建后端docker image。

（注：需要把<docker-hub-username>换成你的docker hub账号名。下同。）

他特别留心命令最后的一个不起眼的小数点没有忘记写。

因为他知道，小数点代表把当前文件夹。

这作为build命令的上下文，以找到所需的jar文件，作为构建资源。

在执行这个命令前，他又仔细检查了参数-t <docker-hub-username>/shopping-list-api:v1.1.docker-compose。

他知道，-t指的是，给image加一个tag，用于标识这个image。

如果以冒号:分界，这个参数的前半段<docker-hub-username>/shopping-list-api，是这个image将来要推送到的Docker Hub上的镜像库（repository）的名称。

他觉得把后端app的docker image命名为shopping-list-api，会更加简洁。

而参数的后半段v1.1.local-docker-compose，是这个image的tag，用来标识image的这次构建的版本号。

他按下回车，执行这个命令。

等这个命令执行完，他运行命令docker image ls，验证后端app的docker image是否构建成功。

屏幕显示出新构建的image，确实带有<docker-hub-username>/shopping-list-api的repository，以及v1.1.local-docker-compose 的tag。这表明image构建成功了。

他在Docker Desktop的Images里，也看到了这个新构建的后端app的docker image。如图3。

图3 他在Docker Desktop的Images里，也看到了shopping-list-api这个新构建的后端app的docker image

6.4 在git代码库打同名的tag以对应刚刚构建的docker image版本

马意浓紧接着，运行命令git tag -a v1.1.local-docker-compose -m "v1.1.local-docker-compose"，在git库里打了一个与docker image的tag同名的tag。

他知道，随着不断提交，代码库中的代码总是在不断变化。

总有一天，他推送到Docker Hub中的image会有bug。那时若想打开对应的源代码看一下，那该看git代码库中哪一次提交后的代码？

但如果他当时在构建docker image后，立即在git库里打一个同名的tag，那么就好定位代码了。

他又运行命令git push origin v1.1.local-docker-compose，把这个tag推送到远程git库中。

他接着运行命令git ls-remote --tags origin，确认这个tag已经成功推送到远程git库中了。

6.5 将后端app的docker image推送到docker hub

因为已经在Docker Desktop里登录Docker Hub了，所以马意浓直接运行命令docker push <docker-hub-username>/shopping-list-api:v1.1.local-docker-compose，将构建好的image推送到Docker hub。

等命令执行完，没有看到错误信息，他就在浏览器访问自己的Docker hub页面。

他在自己的shopping-list-api这个repository里，找到了tag是v1.1.local-docker-compose的image。这表明image推送成功。

下一步，他要构建前端app到docker image，并将其推送到docker hub。

6.6 用Dockerfile里的npm构建前端app的docker image

马意浓知道，构建前端app的docker image的过程，与后端app有些不同。

不同点就是前端app的构建命令npm run build，已经纳入前端app的Dockerfile文件里了。而不像后端app那样，构建命令在Dockerfile之外。

他运行命令进入前端文件夹front-end。

他又运行命令docker buildx build -t <docker-hub-username>/shopping-list-front-end:v1.1.local-docker-compose .，来构建前端app的docker image。

等命令执行完，他运行命令docker image ls，查看新构建的image，确实带有<docker-hub-username>/shopping-list-front-end的repository，以及v1.1.local-docker-compose 的tag。

这表明image构建成功了。

他在Docker Desktop里的Images里，也看到了这个新构建的前端app的docker image。

按理说，构建完前端app后，也应该在git代码库打同名的tag，以对应刚刚构建的docker image版本。

但他觉得从现在到上次在git库打tag这段时间，没有改代码，而且tag的名称也没变，所以他决定省略这一步。

6.7 将前端app的docker image推送到docker hub

马意浓运行命令docker push <docker-hub-username>/shopping-list-front-end:v1.1.local-docker-compose，将构建好的image推送到Docker hub。

他访问自己的Docker hub，在自己的shopping-list-front-end这个repository里，找到了tag是v1.1.local-docker-compose的image。这表明image推送成功。

6.8 在本地docker compose里运行前后端App

做足了前面的功课，马意浓知道，现在该是享受胜利果实的时候了。

因为在本地docker compose里运行前后端app的命令，超级简单。

他进入项目文件夹，然后运行命令cd infrastructure，进入这个子文件夹，

他打开docker-compose.yml文件，仔细确认了shopping-list-api和shopping-list-front-end的image中配置的v1.1.local-docker-compose这样的tag，确实与之前的命令中的tag一致。

他又检查了一下docker desktop的Containers界面，发现之前为后端app打包而准备的postgres和pgadmin容器还在运行，于是他运行清理现场的命令docker compose down，将两个容器关闭并删除。

之后他运行命令docker compose up，来启动docker-compose.yml文件中配置好的那4个容器。

他特意在这个命令中，没有添加表示detach的-d参数，以便观察命令执行中的输出信息是否有错误。

屏幕输出没有任何错误信息，而且最后显示Started ShoppingListApplication字样。这表示前后端App已经成功运行。

他在docker desktop里，能看到这4个容器都在正常运行。

他于是在里面用鼠标点击shopping-list-front-end-1那一行右侧的8080:8080链接，浏览器应声打开，显示了购物清单Web应用的界面。

🔥他在里面添加了一个购物项an apple。这个购物项便顺利地出现在下面的购物清单中！

他兴奋地挥拳庆贺。

至此，前后端分离的Shopping List Web App在本地docker compose里运行成功了。

6.9 清理现场

他又新打开一个Ubuntu终端窗口，进入项目文件夹中的infrastructure子文件夹，然后运行命令docker compose down。

他打开docker desktop，看到Containers界面已经没有任何容器在运行了。现场清理结束。

😃马意浓很兴奋。现在前后端分离的Web应用的容器化这把宝剑，他已经拿到手里了。

接下来，他要挥剑，向k8s上云的新目标迈进。

💔但他心里隐隐有些不安。

因为对他来说，K8s云集群是个完全陌生的环境。他预感会碰到更大的障碍。

🔥【未完待续】

---

❤️欲读系列故事的全集内容，可搜用户“程序员吾真本”，找到“2024程序员容器化上云之旅”专栏阅读。

🔥后面连载内容大纲先睹为快：

🔥7 上云之路

7.1 注册Azure k8s service云平台账号

7.2 打开docker desktop kubernetes让kubectl能正常工作

🔥8 复活重生

8.1 在k8s云集群中运行shopping list web app时如何配置前端app在k8s云集群中的对外域名和端口号以解决CORS问题

8.2 在全绽园的帮助下为前端app配置ingress后解决了这个问题

8.3 在k8s云集群中的软件架构

8.4 如何新增k8s的deployment、service和ingress的配置文件，以便使用kubectl命令将ingress和postgres、shopping-list-api和shopping-list-front-end这3个微服务部署到k8s上

8.5 构建后端docker image并推送到docker hub

8.6 构建前端docker image并推送到docker hub

8.7 在k8s云集群上配置postgres、shopping-list-api和shopping-list-front-end三个微服务和ingress并运行

8.8 清理现场

🔥9 取经归来

当最终把前后端分离的web应用成功部署到azure k8s云集群上，并能顺利使用后，马意浓把整个容器化和上云之旅，写成系列文章，分享给其他程序员。

---

😃你能否跟着马意浓一步步做下来？在阅读中有任何疑问，欢迎在留言区留言。我会一一回复。

❤️如果喜欢本文，那么点赞和留言，并转发给身边有需要的朋友，就是对我的最大支持😃🤝🙏。