提高开发生产力的利器：宜信开源基于Docker的PaaS平台LAIN

作者：宜信大数据创新中心LAIN团队 王超一

在金融的场景下，LAIN 是为解放各个团队和业务线的生产力而设计的一个云平台。LAIN 正式上线已经大约两年，基本已经成熟，为宜信大数据创新中心各个团队提供了统一的测试和生产环境，简化了服务的部署与上线流程，也降低了运维人员对系统管理的复杂度。

LAIN 规范了一个应用的开发、测试、上线工作流，提供了为应用做的容器编排、权限控制、SDN、流量管理、监控报警、备份、日志等 devops 问题的整体解决方案。

在 LAIN 上，应用是一个基本的概念，某个应用的开发者只需要定义一个 lain.yaml 即可定义应用的编译和运行方式，对应用代码侵入性很低。LAIN 基于容器技术，面向多样化的技术栈，并且天然隔离系统和应用的依赖。

当 LAIN 用户创建一个应用（服务）时，可以到 LAIN 上注册该应用，当前的用户自动成为了该应用的维护者，拥有了进一步操作该应用的权限。构建应用的环境需要 docker 和 lain 命令行工具，为了方便，我们创建了一个 vagrant box 即 lain-box. 在构建应用时，除了工程代码外，还需要一个 Docker 镜像作为基础镜像，即编译的环境。如果是二进制的工程，如 golang，则可以在运行时换掉一个底，否则会使用 build 镜像为 release 镜像。准备好镜像和编译／运行的脚本后，就可以编辑 lain.yaml 了。具体来说，lain.yaml 主要做了如下四件事：

1. 应用名称的确定，体现一个应用的边界

2. 应用的基础技术栈，即编译和运行的镜像

3. 构建过程（如何编译）

4. 微服务拆分及服务内部配置（如何运行、运维）

关于第4点，LAIN 上有一个 Proc 的概念，即每个应用都有一个或多个 Proc，Proc 在应用内有唯一的名字和类型，Proc 在底层对应于一组容器，一个应用之间的各个 Proc 的各个容器的网络是互通的，所以应用就是可以互相信任的几个 Proc，对外表现为现实中的某项功能。Proc 的类型是 LAIN 内置的，worker 类型是最简单的类型，LAIN 处理其它的 Proc 类型会做一些额外的事情。

在应用的层面上，LAIN 除了用 lain.yaml 将一个应用的依赖和行为固化外，还有以下几大亮点：

1. SDN 网络安全隔离

• 使用 calico 项目构建 SDN 网络

• 高效率的应用内网络互通

• 应用间网络默认隔离

• 显式声明应用间的服务互访

应用权限的控制

• sso 单点登录，统一认证

• 利用 sso 的组管理，console 进行应用维护者的权限管理，包括 registry 的镜像的权限和应用维护的权限

接下来，我们以一个最简单的 web 服务为例，来说明 LAIN 的工作原理。

首先，用 go 写一个简单的 web 服务，hello.go

下一步，编辑 lain.yaml 文件：

可以看出，lain.yaml 定义了如何编译，发布，测试一个应用。注意到 hello 应用只有一个 Proc，web 是 web.web 的简写形式，即 Proc 类型和名字都是 web. 对于每一个 Proc，LAIN 提供了几个杀手级功能：

1. 动态扩容缩容：可以在 lain.yaml 中定义一个 Proc 的实例数量，即 num_instances，可以定义每个实例所用的内存，也可以在命令行或 console 的 UI 上动态对实例个数以及所用内存大小进行调整。动态扩容缩容会自动注入一些 swarm 的 filters，保证同一个 Proc 的实例调度到不同的节点上。

2. volumes: 即 docker 的 volume，如果配置了该字段，每一个实例都对应拥有一个节点上的文件目录。虽然大部分情况下，加入 volume 意味着加入了状态，不利于 HA，但有些特殊情况比如数据库容器化时，volume 还是必须的。LAIN 的 volume 的精彩之处是可以配置一个备份策略，lain 有一个组件可以支持自定义备份，在备份过程前后还可以自定义脚本，这些自定义脚本何时运行的配置类同 crontab 的调度策略，相当于可以在容器里定义一些 cron job。

3. cloud_volumes: 由于某些数据需要高可用，另外 Proc 中不同的实例可能需要共享一个 volume，LAIN 集成了分布式文件系统，比方说 ceph 和 MooseFS，cloud_volume 比普通的 volume 多一种使用方式，即所有的 instance 共享同一个分布式文件系统目录。

4. logs: 本质上还是 docker volume，但是定义在 logs 字段下目录包含的文件会被 lain 的日志收集系统收集，效果等同于输出到标准输入输出。这样我们可以统一管理、查询所有应用的日志。

5. secret_files: 考虑到一次编译要在不同集群（如测试、生产集群）上运行，那必然会导致一个问题，就是如何加载某些配置，如数据库用户名和密码，将这些配置写入代码仓库会带来明显的安全问题，也不方便自动集成和不同集群上的部署，LAIN 通过内置的 lvault 组件实现了代码与配置的分离，每一个 LAIN 集群都有一个自带的配置中心 lvault，加密存储着所有该集群应用的配置文件。只有应用管理者有权限管理应用的配置文件。这样，用户将不同集群的配置分别写到对应的 lvault 中，即可用将同一个镜像推送到不同的集群中并部署运行。

6. web 类型的 Proc

• 相关 nginx 配置的自动化：web 类型的 Proc 的流量会由一个基于 nginx 的组件 webrouter 做负载均衡，对于不同的 Proc，集群有默认的 mount point，也可以自定义新的 mount point，即 servername 或 baseurl; 也可以定义 health check 等诸多实践上必须的功能。

• watcher 会自动刷新 nginx 配置

• 日志系统会自动收集 nginx 日志

虚 IP: 虚 IP 是为了保证某个 Proc 的高可用而设计的一套机制。

• Proc 可以注册一个或多个虚 IP，应用可以通过虚 IP 对外服务，比如 webrouter 可以用虚 IP 机制去除 nginx 的单点

• networkd 动态维护虚 IP：在 etcd 配置虚 ip 后，各个节点的 networkd 会得到通知，如果对应的 Proc 的实例调度到本节点上，则 networkd 会激活该节点配置 vip 和 iptables 规则，保证流量可以到达实例容器。如果一个 Proc 注册了多个虚 IP，networkd 会尽量将不同的虚 IP 分配到不同的节点上，由于容器是默认分散到不同的节点上的，所以这样可以保证很严格的高可用。

Filters: LAIN 支持 swarm 的 constraint 和 affinity 等容器调度的参数，使得容器的调度更加合理，比方说默认同一个 Proc 的容器尽量调度到不同的节点上，最新的 LAIN 还支持用户自定义 Proc 的 label 以及 Filters。

容器的监控和报警：利用自己开发的 collectd 插件，监控容器的基本运行时数据，集成了 Carbon，Whisper，Graphite-Web，Grafana，icinga2 等开源组件，团队开发了 hedwig，hagrid 两个组件，提供了一整套监控报警系统。

对集群而言，一个应用的部署大致经过这么几个阶段：

1. console 通过 lain-sdk 对 lain.yaml 进行解析，为应用创建 network，创建 calico profile, 创建 sso 的应用维护者组.

2. console 调用 deployd 的接口，deployd 完成容器的编排，也提供了应用在线扩容缩容等 API，进行自动维持和灾难恢复，并将一些重要的数据写入 etcd 中

3. lainlet 监听 etcd，networkd 和 webrouter 里的 watcher 通过 lainlet 拿到集群的最新配置，来完成虚 IP 的自动漂移和 nginx 配置的自动更新等。

总之，LAIN 在最开始的设计中较多地考虑了安全性，包括了 SDN 网络和应用权限的管理，秘密文件配置系统；在实现中，考虑到了多种技术栈的支持和容器化带来的优势，提供了包括备份、日志、监控报警等一揽子解决方案，能够让应用使用者方便地开发各种特性的应用，提高了生产力；最后，对于 LAIN 集群维护者，LAIN 提供了很多运维工具，包括 LAIN 节点的加入删除，应用容器的手动迁移，节点的维护模式等等，基本上满足了从日常运维到灾难恢复的方方面面。

当然，最重要的是，LAIN 所有的组件都已经开源，或者本身利用开源的项目，只要有兴趣，完全可以自己搭建一个 LAIN 集群，并且可以在 gitter [1] 或 github [2] 上讨论以及参与 LAIN 的开发。

参考资料：

1. gitter: https://gitter.im/laincloud/opensource

2. github: https://github.com/laincloud
   

3. LAIN 白皮书: https://laincloud.gitbooks.io/white-paper/content/

推荐阅读

• 管理数万个实例，服务上百个业务：kubernetes在腾讯游戏的使用及演进历程

• 2016年容器技术思考: Docker, Kubernetes, Mesos将走向何方?

• 数据库不适合Docker及容器化的7大原因

• 数据库容器化的价值——反驳数据库不适合容器化的错误观点

本文作者：宜信大数据创新中心LAIN团队王超一，技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿。

高可用架构

改变互联网的构建方式

长按二维码 关注「高可用架构」公众号