从马车到电动车，TiDB 部署工具变形记

时间  2020-06-17
标签 马车 动车 tidb 部署 工具 变形 繁體版
原文   原文链接
做者：Heng Long

打造优秀产品的信念渗透在每个 TiDB 开发者的血液中，衡量产品的优秀有多个维度：易用性、稳定性、性能、安全性、开放性、拓展性等等。**在部署易用性方面，TiDB 开发者们通过诸多探索和尝试，通过了命令行时代、Ansible 时代，终于在 TiDB 4.0 发布了新一代具备里程碑意义的解决方案——TiUP。linux

TiUP 的意义不只仅在于提供了里程碑式的解决方案，更是对 TiDB 开源社区活力的有力证实。TiUP 从 3 月立项进入 PingCAP Incubator 进行孵化，从零开发到最终发布 TiUP 1.0 GA 仅仅只花了两个月。两个月内 40+ 位 Contributor 新增了 690+ 次提交，最终沉淀接近 40k 行代码。git

本文会描述整个演进过程，并介绍 TiUP 设计过程当中的一些理念和实现细节。github

以史为鉴

TiUP 的诞生并不是一蹴而就，而是有一个演变过程。简要描述这个演变过程，有助于你们更加深刻理解 TiUP 的设计和取舍。json

纯命令行

在没有 TiDB Ansible 的时代，要运行一个 TiDB 集群只能经过命令行的方式。TiDB 集群包含 TiDB/TiKV/PD 三个核心组件， 和 Promethues/Grafana/Node Exporter 监控组件。手动构建一个集群运行须要的全部命令行参数和配置文件比较复杂的。好比，咱们想要搭建一个集群，其中启动三个 PD 的命令行参数就有下面这么复杂（能够忽略命令行，仅演示复杂性）：bootstrap

$ bin/pd-server --name=pd-0
--data-dir=data/Rt1J27k/pd-0/data
--peer-urls=http://127.0.0.1:2380
--advertise-peer-urls=http://127.0.0.1:2380 --client-urls=http://127.0.0.1:2379 --advertise-client-urls=http://127.0.0.1:2379 --log-file=data/Rt1J27k/pd-0/pd.log --initial-cluster=pd-0=http://127.0.0.1:2380,pd-1=http://127.0.0.1:2381,pd-2=http://127.0.0.1:2383

$ bin/pd-server --name=pd-1
--data-dir=data/Rt1J27k/pd-1/data
--peer-urls=http://127.0.0.1:2381 --advertise-peer-urls=http://127.0.0.1:2381 --client-urls=http://127.0.0.1:2382 --advertise-client-urls=http://127.0.0.1:2382 --log-file=data/Rt1J27k/pd-1/pd.log --initial-cluster=pd-0=http://127.0.0.1:2380,pd-1=http://127.0.0.1:2381,pd-2=http://127.0.0.1:2383

$ bin/pd-server --name=pd-2
--data-dir=data/Rt1J27k/pd-2/data
--peer-urls=http://127.0.0.1:2383 --advertise-peer-urls=http://127.0.0.1:2383 --client-urls=http://127.0.0.1:2384 --advertise-client-urls=http://127.0.0.1:2384 --log-file=data/Rt1J27k/pd-2/pd.log --initial-cluster=pd-0=http://127.0.0.1:2380,pd-1=http://127.0.0.1:2381,pd-2=http://127.0.0.1:2383
注：以 $ 开头的表示在命令行执行的命令

以上仅仅是启动 PD 就能够发现这种方式显然太复杂、使用门槛过高。尽管咱们能够经过把这些东西脚本化，在脚本构建好这些内容，每次执行对应脚原本简化这个过程，可是对于第一次构建脚本的用户来讲，也是不小的挑战。vim

另外在生产环境部署时还须要在多个主机上分发下载对应组件，以及初始化环境，对于扩容又须要各类初始化，至关繁琐。安全

TiDB Ansible

第二代方案 TiDB Ansible 基于 Ansible playbook 功能编写的集群部署工具，简化以后，只须要用户提供拓扑文件，便可提供集群部署和运维功能（启动、关闭、升级、重启、扩容、缩容）。可是 TiDB Ansible 的使用依然很是繁琐，提供的错误消息也不友好，同时只能串行处理，对于大集群的运维和管理尤为不方便。app

$ vim hosts.ini                                                
$ ansible-playbook -i hosts.ini create_users.yml -u root -k   
$ vim inventory.ini                                        
$ ansible-playbook local_prepare.yml 
$ ansible-playbook bootstrap.yml
$ ansible-playbook deploy.yml
$ ansible-playbook start.yml

以上是部署启动一个集群，扩缩容操做更加繁琐。而且因为 Ansible 自身命令执行的特色，整个部署过程的时间较长。运维

TiUP

TiUP 在 TiDB Ansible 的基础上进一步对整个集群的部署和运维操做进行了简化。因为 TiUP 从零开发，能够掌控全部实现细节，针对部署 TiDB 集群的须要定制、避免非必需的动做，内部作到最大程度的并行化，同时提供更加友好错误提示。curl

利用 TiUP 部署集群经过简单的命令便可完成，且执行速度较 TiDB Ansible 大幅提升：

$ tiup cluster deploy <cluster-name> <version> <topology.yaml> [flags]   # 部署集群
$ tiup cluster start prod-cluster                                        # 启动集群

其余经常使用的运维操做也一样能够经过一个命令完成：

$ tiup cluster scale-in prod-cluster -N 172.16.5.140:20160               # 缩容节点
$ tiup cluster scale-out tidb-test scale.yaml                            # 扩容节点
$ tiup cluster upgrade tidb-test v4.0.0-rc                               # 升级集群

深刻 TiUP

首先使用下面这行脚本安装 TiUP：

$ curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh

你会发现，使用 tiup help 命令时，咱们并无 tiup cluster 这个子命令，这是怎么回事儿呢？这就要从 TiUP 的设计理念聊起。

TiUP 理念

以上虽然演示了经过 TiUP 快速部署运维集群，可是 TiUP 的定位历来就不是一个运维工具，而是 TiDB 组件管理器。TiUP 之于 TiDB，相似 yum 之于 CentOS，Homebrew 之于 MacOS。

TiUP 的理念为：简单易用、可扩展、开放、安全。

简单易用

TiUP 自己只包含不多几个命令，几乎不用专门学习、记忆，彻底依靠经验和肌肉记忆就能正确使用：

命令 解释
tiup install <component> 安装一个组件
tiup uninstall <component> 卸载一个组件
tiup update 更新组件
tiup list 显示组件列表
tiup status 运行的组件状态
tiup clean 清理组件运行数据

可扩展

TiUP 最核心之处就是高度可扩展、可定制，除了自带的几个命令以外，还能够经过安装不一样的组件，对 TiUP 进行定制，一千我的就有一千种 TiUP，将 TiUP 打形成一把属于本身的瑞士军刀。以上演示 集群部署运维 就是经过 TiUP-Cluster 组件提供的功能完成的，除了 TiUP-Cluster 组件以后，还有很是多有用的组件，例如如下两个开发中最经常使用的组件：

1. TiUP-Playground 组件，能够一条命令直接运行一个本地 TiDB 集群：

$ tiup playground                  # 运行最新稳定版 TiDB 集群
$ tiup playground v3.0.15          # 运行版本为 v3.0.15 TiDB 集群
$ tiup playground --kv 3           # 启动三个 TiKV 节点
$ tiup playground --monitor        # 启动 Prometheus 监控
$ ...

2. TiUP-Bench 组件，能够快速进行基准测试：

$ tiup bench tpcc                         # 进行 TPC-C 性能基准测试
$ tiup bench tpch prepare
$ tiup bench tpch run                     # 进行 TPC-H 性能基准测试

开放

TiUP 的组件模式不只仅为可扩展性设计的，也但愿构建一个开放生态，用户能够根据本身的使用场景，编写本身的组件，而且将组件提交到 TiUP 的镜像仓库。也能够在镜像仓库中根据本身的需求选择由社区开发的组件。

目前 TiUP 镜像仓库已经包含 20+ 组件，但愿经过开放的生态基因和 TiDB 庞大的开发者生态创意碰撞，能为 TiUP 提交愈来愈多优质的组件。

为此，TiUP 提供了一个命令 tiup mirror publish 可以将本地组件经过一个命令发布到 TiUP 的镜像仓库。

$ tiup mirror publish -h
Publish a component to the repository

Usage:
  tiup mirror publish <comp-name> <version> <tarball> <entry> [flags]

Flags:
      --arch string       the target system architecture (default "amd64")
      --desc string       description of the component
      --endpoint string   endpoint of the server (default "https://tiup-mirrors.pingcap.com/")
  -h, --help              help for publish
  -k, --key string        private key path
      --os string         the target operation system (default "linux")

Global Flags:
      --repo string          Path to the repository
      --skip-version-check   Skip the strict version check, by default a version must be a valid SemVer string

安全

安全是软件分发系统（组件管理器）的基石，若是分发的组件没有安全保障，那么上面提到简单易用、可扩展、开放都会为恶意软件提供便利。TiUP 做为 TiDB 生态的入口，好比提供企业级安全保障，须要防范在软件分发各个环节中可能出现的各类攻击。

要防范组件分发过程当中的各类攻击，须要很是谨慎和精细的设计，得益于 TUF 规范的优良设计，咱们在 TUF 规范的基础上设计了 TiUP 的软件分发方案，详细的设计文档超过 10 页，本文不会详细讨论全部细节，有兴趣的朋友能够参考 设计文档。

如下是对软件分发过程一个简要的描述（如何在各个环节防范不一样类型的攻击，能够参考 TUF 规范和 TiUP 设计文档）：

  1. 元信息分级：

    a. root 保存对元信息签名的公钥信息；

    b. index 保存各个组件信息和组件 Owner 的公钥信息；

    c. component 保存组件的版本信息；

    d. snapshot 保存其余元信息的最新版本号和 Hash 值；

    e. timestamp 保存最新 snapshot 的版本号和 Hash 值。

  2. 全部的元信息和组件包在 CDN 是不可变的，不一样版本的元信息使用 ${version}.${name}.json 的文件名保存。
  3. 全部组件包的的 Hash 值保存在组件的元信息文件中 （sha256/sha512）。
  4. 全部的元信息文件都包含该被签名内容和签名信息。
  5. 根证书使用 5 个密钥签名，5 个密钥分别由 5 位不一样的 TiDB 开发者离线保存。
  6. 初始分发的 TiUP 中包含一份由 5 位 TiDB 开发者签名的 root.json，后续信息校验会保证 root.json 中至少有三个签名是正确的。
  7. index/snashot/timestamp 的不可篡改性由 root.json 中的对应的密钥信息保证。
  8. component 的不可篡改性由 index.json 中对应的 Owner 密钥保证（社区经过 tiup mirror publish 发布的组件，只有做者拥有私钥）。
  9. 各个组件包的不可篡改性由元信息中的 sha256/sha512 Hash 值保证（目前的算力状况下是安全的）。

经过上面的机制，咱们能保证用户下载的组件不会通过任何中间环节篡改，从而提供安全的组件分发机制。

但愿上面的介绍能让你们对 TiUP 的演进和理念有初步的认识，同时 TiUP 开源在 Github 而且随着 TiDB 4.0 GA 版本一块儿发布，对于 TiUP 有兴趣的小伙伴能够阅读源码，有任何问题均可以经过 Issue 提问或直接在 Slack 的 #sig-tiup 中提问。

附：TiUP 贡献者名单

序号 GitHub ID
1 5kbpers
2 AstroProfundis
3 baurine
4 birdstorm
5 bobotu
6 breeswish
7 BusyJay
8 c4pt0r
9 chenlx0
10 fewdan
11 flowbehappy
12 fredchenbj
13 hhkbp2
14 HunDunDM
15 ilovesoup
16 JaySon-Huang
17 july2993
18 King-Dylan
19 kissmydb
20 kolbe
21 lhy1024
22 lichunzhu
23 liubo0127
24 lonng
25 lucklove
26 mahjonp
27 mapleFU
28 marsishandsome
29 nrc
30 overvenus
31 qinzuoyan
32 rleungx
33 siddontang
34 sticnarf
35 Win-Man
36 wjhuang2016
37 YangKeao
38 yeya24
39 yikeke
40 zhangjinpeng1987
41 zyguan

原文阅读：https://pingcap.com/blog-cn/t...

若对 TiDB 使用上有疑问，能够在 https://asktug.com 上搜索or发帖提问～

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程