在Kubernetes上运行SAP UI5应用(上）

摘要：在上海研究院的同事们如果想参加这个内部培训，可以联系同事。第三行命名执行命令，生成新的镜像文件。说句题外话虽然今年月份被微软收购了，但是用户体验一点也没变，一如既往的优秀。关于更多另类用法，请参阅的文章写在被微软收购之际的那些另类用法。

2018年只剩最后30天了。Jerry在2017年的最后一天，曾经立下一个目标：这个微信公众号在2018年保证至少每周发布一篇SAP原创技术文章。

从Jerry在后台统计的2018全年文章数量来看，这个目标已经提前实现了。为了感谢大家的支持，在2018年的最后一天，Jerry会发布一个合集：《SAP成都研究院2018年XX篇原创文章合集》，包含了2018年全年SAP成都研究院的同事们发布过的文章。

Jerry在11月份中旬去SAP上海研究院参加了Kubernetes的内部培训(详情参考我的前一篇文章：站在巨人肩膀上的牛顿：Kubernetes和SAP Kyma)。在SAP上海研究院的同事们如果想参加这个内部培训，可以联系同事Yang Katie。

为了避免很快就把三位老师传授的知识忘得精光，我得给自己找点练习来巩固所学的东西。

Jerry 2014年底加入SAP CRM Fiori开发团队时，我们开发的CRM Fiori应用，还是部署在传统的SAP Netweaver上的，详情参考我的文章：SAP Fiori应用的三种部署方式。

后来，我陆续接触了Salesforce的云平台Heroku，也学着很多程序员一样把自己的博客搭在github上，再后来接触了SAP自己的云平台，自然而然地就会试着把SAP UI5部署到这些平台上：

Step by step to host your UI5 application in Heroku

Step by step to host your web application to Github

Deploy your web application to Cloud Foundry which can access resource from On-Premise ABAP system

现在既然学了Kubernetes，那么就来试试将SAP UI5应用运行在Kubernetes上面吧。

我用来部署的UI5应用名叫Jerry"s Service Order, 是一个典型的Master-Detail风格的应用，左边Master List是所有服务订单列表，选中任意一个，在右边的Detail页面显示选中的服务订单的明细。

这个UI5应用的外观如上图所示。为简单起见，所有显示的数据都是从项目里的一个json文件读取的，不支持新订单的创建或修改。该应用可以从我的github获取：

https://github.com/i042416/je...

如本文标题所示，这个练习的终极目标就是让该UI5应用运行于Kubernetes上，那么第一步就是先让它运行于容器里。和SAP Kubernetes内部培训一样，我选择了Docker这个非常受欢迎的容器引擎作为这个Kubernetes练习的容器技术。

关于Docker的简介和安装介绍，请参阅阮一峰大神的文章：Docker 入门教程

http://www.ruanyifeng.com/blo...

为什么我们要使用Docker容器？下面这段话摘自阮一峰的博客：

“Docker 属于 Linux 容器的一种封装，提供简单易用的容器使用接口。它是目前最流行的 Linux 容器解决方案。

Docker 将应用程序与该程序的依赖，打包在一个文件里面。运行这个文件，就会生成一个虚拟容器。程序在这个虚拟容器里运行，就好像在真实的物理机上运行一样。有了 Docker，就不用担心环境问题。

总体来说，Docker 的接口相当简单，用户可以方便地创建和使用容器，把自己的应用放入容器。容器还可以进行版本管理、复制、分享、修改，就像管理普通的代码一样。”

Jerry梳理了一下将SAP UI5应用运行在Docker容器里的全过程，总共分三个步骤：

1. 让UI5应用运行在本地容器内

2. 将包含了UI5应用的本地容器打成一个新镜像

3. 将本地镜像上传到Docker hub，再下载测试

下面是详细步骤。

1. 让UI5应用运行在本地容器内

如果仅仅只会跑Docker的Hello World(其实Jerry两周前就是这个水平，囧)，拿到这个需求，从什么地方入手？

当然是从包含了能运行UI5应用的那些web服务器的镜像入手，这里我选择了Nginx镜像，在Docker hub上有10.4k个stars。

用下面的命令直接运行这个镜像：

docker run -it nginx

用docker ps拿到实例化的容器id：

然后进入处于运行状态中的容器，执行shell命令：

docker exec -it bbc5d48a761c /bin/sh

看到#提示符后，进入容器内部的目录：/usr/share/nginx/html

如果我们能将github上的UI5应用的文件想办法拷贝到这个目录下面，就达到了在本地Docker容器运行UI5应用的目的了。

有很多种办法可以把github里的资源下载到Docker容器内部这个指定的目录下， 这里Jerry用一种我觉得最简单的方式，即通过Docker Volume技术将宿主机上的某个目录A以Volume的方式挂接到容器内部的html文件夹上，这样我们直接把github仓库上的webapp文件夹下载到宿主机的文件夹A即可，这个文件夹会以Volume的形式自动出现在容器内部映射好的目录内。

docker run -d -p 1081:80 -v pwd/webapp:/usr/share/nginx/html/webapp –name jerry-custom nginx

使用参数-p 1081:80将Nginx服务通过端口1081暴露出来，因此我这次要使用http://localhost:1081测试新启动的容器实例。

再次执行docker exec进入docker容器内部，确保/usr/share/nginx/html文件夹下确实包含了期望看到的UI5应用。

浏览器里输入localhost:1081/webapp，确保UI5应用能够正常访问，至此这个应用已经在本地docker容器里成功运行起来了。

2. 将包含了UI5应用的本地容器打成一个新镜像

到目前为止这个本地docker实例是没有办法给其他人使用的，为此我们得先利用dockerfile制作一个包含了UI5应用的docker镜像，上传到docker hub上，以便其他人下载。

随便创建一个文件夹，比如jerry-build, 然后把webapp文件夹放进去，再创建一个dockerfile文件，内容就三行:

FROM nginx:stable 

COPY webapp/ /usr/share/nginx/html/webapp/ 

RUN ls -la /usr/share/nginx/html/webapp*

这三个指令从语义上不难理解，第一行FROM命令告诉docker镜像构建例程使用nginx的stable版本作为基础镜像进行新镜像的构建。第二行COPY命令负责把webapp文件夹下的所有UI5资源文件拷贝到nginx docker镜像的对应目录内。第三行RUN命名执行shell命令ls，生成新的镜像文件。

dockerfile的详细语法请参考Docker 官方文档：

https://docs.docker.com/engin...

执行命令docker build ., 最后一个.代表“当前目录”。

看到上图"Successfully built(成功构建)"的输出信息后，我们加上参数-t jerry-nginx-image:1.0重新构建一个名为jerry-nginx-image的镜像:

成功构建后，使用参数-p暴露一个新的端口1082：

docker run -d -p 1082:80 jerry-nginx-image:1.0

现在localhost:1082/webapp也能访问UI5应用了。

使用docker images, 现在我们能看到这个构建好的镜像了，接下来我们会将其推送到Docker hub上。

3. 将本地镜像上传到Docker hub

Docker hub的使用方式几乎和github完全一致。说句题外话：虽然github今年6月份被微软收购了，但是用户体验一点也没变，一如既往的优秀。

关于github更多另类用法，请参阅Jerry的文章：写在Github被微软收购之际 - Github的那些另类用法。

首先在Docker hub上注册一个帐号：

创建一个新仓库：

取名i042416/ui5-nginx:

新建好的空的仓库看起来是这样的：

使用docker ps得到本地正在运行的docker容器的ID：

使用commit命令提交这个本地容器的修改(类比git commit )：

docker commit 53de4188b702 i042416/ui5-nginx

现在准备将这个本地提交过后的镜像推送到Docker hub了。

执行命令docker login:

在CloudFoundry上部署应用的朋友们可以把docker login类比成cf login(下面是cf login的截图)：

最后一步就是用docker push将本地镜像推送到Docker hub：

刷新Docker hub上新建的仓库，能观察到刚才的本地推送记录和镜像尺寸。

现在可以通知您的朋友，在其电脑上消费这个镜像了。当然您也可以把自己电脑上的本地镜像删除，再使用docker run执行。

在两种情况下，由于本地镜像检索失败，我们都将看到提示信息：Unable to find image ‘i042416/ui5-nginx:latest" locally, 然后观察到远端镜像的下载过程。

使用1080端口基于镜像i042416/ui5-nginx启动一个新的容器：

localhost:1080/webapp能够正常工作：

docker inspect命令证实了这个启动的容器确实是基于镜像i042416/ui5-nginx的。

在这个主题的下半部分，我们将使用这个i042416/ui5-nginx镜像，开始我们的Kubernetes之旅。敬请期待。

更多阅读

写在Github被微软收购之际 - Github的那些另类用法

SAP Fiori应用的三种部署方式

站在巨人肩膀上的牛顿：Kubernetes和SAP Kyma

要获取更多Jerry的原创文章，请关注公众号"汪子熙":