在阿里云Kubernetes上运行SpringCloud示例PiggyMetrics

阿里云Kubernetes服务运行SpringCloud

osswangxining大侠在 阿里云Kubernetes SpringCloud 实践进行时 系列文章中系统地介绍了如何在阿里云Kubernetes容器服务上搭建基于SpringCloud的微服务应用，其中涉及了从Eureka注册，配置中心，网关Zuul，到服务追踪和容错等诸多内容，洋洋洒洒六篇文章，让你充分领略在阿里云Kubernetes上运行SpringCloud的风采。

实践进行时系列展示了SpringCloud的基本组件及如何部署和使用，本文则是从另外一个角度让大家了解一个具有一定复杂度的应用是如何部署到阿里云Kubernetes容器服务上的。我们准备从基础设施和应用部署的不同组合方式上来展示一个复杂的SpringCloud应用是如何部署到容器服务上的。

（一）基础设施（Eureka，ConfigServer）和应用一起部署。

（二）在容器服务上搭建好基础设施后，再部署应用

示例应用PiggyMetrics

PiggyMetrics是github上的一个SpringCloud应用项目，Star数目3400多。这个项目主体DockerCompose部署，包含了完整的源代码以及构建好的容器镜像，是非常不错的SpringCloud容器化示例。

这个项目包含了3个业务微服务，分别是统计服务（Statistics Service）、账户服务（Account Service）和通知服务（Notification Service）。每个服务分别对应一个独立的MongoDB。微服务架构图示（采用作者原图）如下：

SpringCloud基础组件为负责服务注册和registry服务（Eureka服务注册），config服务（配置管理），gateway（API网关，同时也是JavaScript Web界面），monitor服务（Hystrix Dashboard/Turbine）等。

本文所用到的部署描述文件地址在github上，感兴趣的读者请移步 https://github.com/binblee/PiggyMetrics/tree/master/charts。

（一）用helm部署一键部署所有服务

PiggyMetrics的部署采用docker-compose YAML部署到单机，如果要部署到Kubernetes上，需要转换成为K8S deployment YAML。社区有个docker compose转k8s的转换工具kompose，可以一键将compose文件转换为k8s部署文件。

PiggyMetrics中的docker compose模版为2.1版kompose不支持，所以需要把compose文件改为版本2，去除kompose不支持的语法，如

    depends_on:
      config:
        condition: service_healthy  # 不支持 condition

增加k8s server type annotation：

    labels: 
      kompose.service.type: loadbalancer 

读者可以参考已经更改好的compose文件 https://github.com/binblee/PiggyMetrics/blob/master/charts/docker-compose.yml。

在执行kompose之前还需要设定PiggyMetrics部署所需的环境变量。

$ export NOTIFICATION_SERVICE_PASSWORD=passw0rd
$ export CONFIG_SERVICE_PASSWORD=passw0rd
$ export STATISTICS_SERVICE_PASSWORD=passw0rd
$ export ACCOUNT_SERVICE_PASSWORD=passw0rd
$ export MONGODB_PASSWORD=passw0rd
$ kompose convert -f docker-compose.yml -o piggymetrics -c

kompose的选项-c可以生成helm chart格式目录结果，读者可以用helm命令行把所有服务全部部署上去。

charts $ helm install -n piggymetrics piggymetrics/

部署后可以看到类似如下输出：

NAME:   piggymetrics
LAST DEPLOYED: Fri Jul 13 23:20:30 2018
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/Service
NAME                  TYPE          CLUSTER-IP     EXTERNAL-IP  PORT(S)                         AGE
account-mongodb       ClusterIP     172.19.12.220  <none>       27017/TCP                       1s
account-service       ClusterIP     172.19.3.168   <none>       6000/TCP                        1s
auth-mongodb          ClusterIP     172.19.10.232  <none>       27017/TCP                       1s
auth-service          ClusterIP     172.19.7.184   <none>       5000/TCP                        1s
config                ClusterIP     172.19.7.86    <none>       8888/TCP                        1s
gateway               LoadBalancer  172.19.7.183   <pending>    4000:32457/TCP                  1s
monitoring            NodePort      172.19.8.129   <none>       9000:30688/TCP,8989:30437/TCP   1s
notification-mongodb  ClusterIP     172.19.0.154   <none>       27017/TCP                       1s
notification-service  ClusterIP     172.19.8.69    <none>       8000/TCP                        1s
rabbitmq              NodePort      172.19.8.192   <none>       5672:31438/TCP,15672:30001/TCP  1s
registry              LoadBalancer  172.19.12.23   <pending>    8761:32224/TCP                  1s
statistics-mongodb    ClusterIP     172.19.7.53    <none>       27017/TCP                       1s
statistics-service    ClusterIP     172.19.13.210  <none>       8888/TCP                        1s

==> v1beta1/Deployment
NAME                  DESIRED  CURRENT  UP-TO-DATE  AVAILABLE  AGE
account-mongodb       1        0        0           0          1s
account-service       1        0        0           0          1s
auth-mongodb          1        0        0           0          1s
auth-service          1        0        0           0          1s
config                1        0        0           0          1s
gateway               1        0        0           0          1s
monitoring            1        0        0           0          1s
notification-mongodb  1        0        0           0          1s
notification-service  1        0        0           0          1s
rabbitmq              1        0        0           0          1s
registry              1        0        0           0          1s
statistics-mongodb    1        0        0           0          1s
statistics-service    1        0        0           0          1s

==> v1/Pod(related)
NAME                                  READY  STATUS             RESTARTS  AGE
account-mongodb-5c5dbb6d6c-b66r2      0/1    ContainerCreating  0         1s
account-service-7fd4976bfc-rngk5      0/1    ContainerCreating  0         1s
auth-mongodb-6555c4b88-d7mw4          0/1    ContainerCreating  0         1s
auth-service-7bdb99b5dc-l8sl5         0/1    ContainerCreating  0         1s
config-8555868f45-qsclf               0/1    ContainerCreating  0         1s
gateway-77857d9c49-dj7nt              0/1    ContainerCreating  0         1s
monitoring-85d97bcff5-lvl9w           0/1    ContainerCreating  0         1s
notification-mongodb-599648788-zfcl2  0/1    ContainerCreating  0         1s
notification-service-5d5859d7-q8x4g   0/1    ContainerCreating  0         1s
rabbitmq-545b846656-8mjpb             0/1    ContainerCreating  0         1s
registry-757db89bb4-2g9hh             0/1    ContainerCreating  0         1s


charts $

读者可以在自己的Minikube上尝试，或者部署到阿里云容器服务Kubernetes版：https://www.aliyun.com/product/kubernetes。部署完成后进入服务列表页面，可以看到所有服务以及对应LoadBalancer类型Service对外暴露的访问地址及端口号。

点击registry service可以进入到PiggyMetrics的界面。

PiggyMetrics是个人理财服务，用户输入收入和支出后可以展现漂亮的报表。不过现在使用会有一个问题：在使用过程中会出现“An error during data saving. Please, try again later”的错误提示，原因是PiggyMetrics所依赖汇率计算http://api.fixer.io API发生变化，而PiggyMetrics镜像还没有更新的缘故。

访问registry service，可以看到所有注册到Eureka Server上的服务。

将PiggyMetrics删除，为下个实验做准备：

charts $ helm delete --purge piggymetrics
release "piggymetrics" deleted

（二）部署应用到已有SpringCloud基础组件的环境中

上面我们看到的是如何将全部基础组件（Eureka，Zuul，ConfigServer，Hystrix Dashboard）和业务应用（gateway，notification，statistics）都统一用一个helm chart部署成功。在实际工作中，更常见的情况是在集群中已经有了Eureka等基础组件，用户日志只需部署和升级维护业务应用。

在阿里云Kubernetes版中的应用目录中包含了SpringCloud基本组件。

我们可以先从应用目录部署好Eureka服务。点击ack-springcloud-eureka组件，进入如下界面：

读者也可以进入参数页面，查看或更改配置：

在这里选择不改变任何参数直接部署。部署成功后进入阿里云Kubernetes控制台服务页面，可以看到，EurekaServer有两个示例，对外暴露的服务地址为ack-springcloud-eureka-default-ack-springcloud-eureka-svc。

回想起在PiggyMetrics中，所有容器启动时自动访问的的Eureka服务名为registry。一般情况下，可以在镜像中把Eureka服务名做为参数传递，但是在这个实验中我们不准备改变任何代码和镜像，所以可以采取另外一个措施，那就是为把Eureka再多暴露一个叫registry的服务。

利用容器服务部署如下YAML文件，注意，如果读者在应用目录部署过程中更改了发布名称，下面的内容也要做相应调整。

apiVersion: v1
kind: Service
metadata:
  name: registry
spec:
  type: LoadBalancer
  ports:
    - port: 8761
      targetPort: 8761
  selector:
    app: ack-springcloud-eureka-default-ack-springcloud-eureka
    release: ack-springcloud-eureka-default

您可以利用kubectl命令行：

$ kubectl apply -f registry-svc.yml

或者容器服务控制台界面完成：

部署完成后再次进入服务页面，可以看到reigstry创建成功：

好了，下面我们把PiggyMetrics的helm chart目录拷贝到一个新的目录piggymetrics-no-eureka，删除以下两个文件。

templates/registry-deployment.yaml
templates/registry-service.yaml

这两个文件是分别部署Eureka deployment/svc的YAML文件，由于我们在前面已经用应用目录部署成功了一个新的registry服务作为基础SpringCloud组件，这里就不要再重复部署了。

执行helm命令再次部署PiggyMetrics。

$ helm install -n piggymetrics piggymetrics-no-eureka/

所有服务启动成功后，访问registry服务，可以看到所有PiggyMetrics服务均已正确地注册到了EurekaServer中。

BINGO！PiggyMetrics应用已经部署到了含EurekaServer的环境上。访问gateway，读者可以看到熟悉的登陆界面。

示例代码

本文所用到的部署描述文件地址https://github.com/binblee/PiggyMetrics/tree/master/charts。

PiggyMetrics 代码地址在 https://github.com/sqshq/PiggyMetrics。

讨论: 可以考虑修改源代码中的调用解决api.fixer.io调用失败的问题。例如把https://github.com/sqshq/PiggyMetrics/blob/master/gateway/src/main/resources/static/js/launch.js 中的
$.getJSON("http://api.fixer.io/latest?base=RUB", function( data ) {

改为对exchangeratesapi.io调用

$.getJSON("https://exchangeratesapi.io/api/latest?base=RUB", function( data ) {。

不过这个改动超越了本文的范围，感兴趣的读者可以自行修改并重新构建镜像再测试。

小结

本文展示了将PiggyMetrics SpringCloud应用部署到阿里云容器服务上。阿里云容器服务的应用目录中提供常见的SpringCloud基础组件，用户可以很方便的部署一个SpringCloud环境。关于更多阿里云容器服务Kubernetes的内容，读者可以访问https://www.aliyun.com/product/kubernetes。