[案例分享] 使用Rainbond部署和运维项目

原文链接

本篇文章主要介绍我为什么使用Rainbond平台构建和运维项目,其实在Rainbond比较早期的时候我就开始关注了当初的版本还是3.6.0,一开始我还以为Rainbond会想Rancher的早期版本一样,
安装就是一道坎,结果出乎预料的顺利,我在我们阿里云的测试机非常简单的安装了Rainbond,然后很顺利的运行了静态demo。

对比rancher和kubernetes原生运维项目,有几个难点:

  1. 学习曲线比较陡峭(注: 因为平常项目很忙,公司也不会给你那么多时间等你学习完了再上系统,当然需要学习下k8s原理和配置,这样才能更好使用它解决问题)。
  2. 使用rancher的时候,安装可能会有问题,管理容器响应慢,会有一些莫名其妙的问题,使用了一段时间以后,测试都有问题,所以生产就不要谈了。
  3. kubernetes如果要使用起来安装和升级比较困扰,这块需要研究,我在本地安装个k8s学习环境就研究了好久,而且翻墙或者下载本地包安装才能成功。

使用Rainbond的好处

  1. 安装简单
  2. 使用和运行应用简单
  3. 应用市场丰富,监控和备份插件健全
  4. docker对于docker一些默认日志配置,不需要去烦恼,举个例子:因为docker的log没有配置好是会一直增长的,之前使用docker swarm的时候,碰到的问题。
  5. 应用图谱和应用之间的依赖关系,清晰明了
  6. 操作简单,在开发环境,应用的发布和更新,开发自己能很简单的去操作

使用docker相关经历

因为是互联网创业公司,所有的都是要求快,所以没那么多时间去研究k8s,公司的运维又是比较传统的,项目都是直接用jenkins构建,直接在服务器上部署。
之前公司一直在使用docker部署和运维项目,所以到了新公司也不例外。

一开始和运维配合使用jenkins搭建了一个自动构建,自动上传镜像,自动运行docker swarm的集群,但是操作起来不方便,还经常出问题,去修改脚本什么的。
因为k8s比较火,然后就尝试寻找一个支持k8s的开源paas服务平台。因为有过Rancher的使用经历,遇到坑出问题也很难在社区找到解决办法,所以Rancher被果断放弃了。

当然使用Rainbond也有遇到了一些问题,但是在云帮的社区以及官方交流群,一般花个2~3个小时就能很好的得到解决,目前我们生产部分的支付流量已经切换到Rainbond上。

使用Rainbond曾经遇到的问题以及解决方案

1,安装升级后,执行 grctl cluster 命令,发现storage健康检查有问题。

1. 检查存储检查文件的内容,是否存在,字符串的值是什么, cat /grdata/.check。
2. 检查存储检测脚本中,check_key 字符串的值是什么,是否与存储检测文件中的内容一致。
3. cat /opt/rainbond/health/storage.sh, 查看check_key。
4. 只有1和2两个key一致的情况下,才能保证storage检测通过。
说明:之前环境的具体原因是虚拟机恢复了快照,重新安装后,检测脚本的内容发生了变化。
而外接的glusterfs内的检测文件 .check 内容没有实时更新。
重新挂接后,二者内容不一致,导致健康检测失败。

2, 修改Rainbond后台绑定的默认域名

  1. docker exec rbd-db mysql -e ‘use console;update region_info set httpdomain=“自定义域名”’
  2. 云帮后台使用域名访问,添加nginx服务代理
    server {
    listen 80;
    server_name apps.rainbond.com;
    error_page 500 502 503 504 /50x.html;
    location = /50x.html {
    root /usr/share/nginx/html;
    }
    location / {
    proxy_pass http://xx.xx.xx.xx:7070;
    }
    }

3,使用源码构建报错,版本5.1.2,我在云帮社区发了解决办法,具体链接

Rainbond社区解决方案

4,应用连不上数据库问题

1,处理ServiceMesh的容器确实可能后启动,所以业务代码最好做好重连,重试。
因为在微服务或云原生情况下,依赖的服务,不管是数据库还是其他服务,都有可能暂时无法连接。
需要做一定的容错。
2,最新版本的Rainbond可以定义启动依赖可以解决此问题,但是建议应用做好容错机制,以免依赖重启造成问题。

5,CPU和内存比例问题,导致空闲大部分内存,可以通过以下办法解决

Rainbond为了服务的有效性,在启动的时候预留了一部分CPU/内存给云帮自身的服务,但是一般QA环境和DEV环境不需要这样的预留。
所以需要修改配置文件,把这部分预留的资源释放出来
具体操作如下:
vi /opt/rainbond/scripts/kubelet.sh
修改其中两句,以下是我修改后的:
–kube-reserved=cpu=100m,memory=256Mi,ephemeral-storage=1Gi
–system-reserved=cpu=200m,memory=512Mi,ephemeral-storage=1Gi
修改完成后,重启
systemctl restart kubelet
(以上生产环境不建议修改)

说明:由于公司的测试环境是2台2核8G的服务器,但是在部署了几个云帮的应用以后,发现提示cpu不足。
原因是因为云帮对应应用的伸缩设定了CPU/内存的比例,这个比例只有在企业版下面才有界面修改。
云帮一般服务器CPU和内存应该购买2核4G或者4核8G这样的比例,这样才不会浪费过多的内存。

云帮CPU和内存解释文章

我是怎么使用Rainbond发布服务的

一开始是使用Harbor搭建的私有镜像仓库,但是镜像仓库随着发布越来越庞大,虽然会去清理,但是还是有存储的问题。
小公司用的服务器资源比较紧张。

可以使用阿里云的镜像构建功能,而且针对构建的镜像,免费存储,所以后面就直接使用了阿里云的镜像构建功能,
用阿里云的镜像构建功能有个好处,可以使用阿里云境外服务器构建,这样会用到一些国外的公共包也不用走国内的镜像源了,构建也快。

每次发版都通过打标签,阿里云自动根据项目下的Dockerfile进行构建
云帮镜像仓库根据设定的Webhook自动触发重新构建发布,当然生产环境为了稳定都是通过手动修改构建镜像版本进行发布。

这种部署方式可以保证生产和测试使用的是同一个版本号的镜像文件

希望Rainbond优化的功能

  1. 通过外部存储配置文件希望能够直接通过后台修改,目前只有上传配置文件的功能,要修改,必须进入容器中取的文件内容重新上传。
  2. 云帮能够开放部分企业后台的Api接口,社区用户可以用这些api,开发一个简单的监控UI,创业初期实在是没预算购买云帮服务,只能厚着脸皮了,嘿嘿。

感谢Rainbond一直以来的努力,Rainbond对我们的帮助很大,特别是初创公司,可以使用Rainbond快速搭建基础运维环境,节约很大的人力和成本。

1 Like

本主题现在是横幅主题。它将出现在每页的顶部,除非用户将其隐藏。

本主题已经不再是横幅主题。它将不在每个页面的顶部显示。