2
3
1
0
专栏/.../

TiUP cluster 用到的三个账户

 buptzhoutian  发表于  2021-08-03

【是否原创】是
【首发渠道】asktug

为什么写这篇文章

  • 论坛里经常看到对 tiup 集群管理的讨论,其中 ssh 相关的账户/权限问题比较多;
  • 理解了 tiup cluster 的 ssh 操作,才能更好地使用 cluster 组件;
  • 希望能给排查 ssh 问题的朋友一些思路。

目标读者

如果你:

  • 了解 SSH 客户端的基础,知道常用的认证/登录机器方式
  • 使用 tiup cluster 管理集群
  • 对 tiup 如何连接集群节点有疑惑
  • 遇到过 ssh 的问题,不知道为啥报错,不知道如何解决或者不知道最佳方案
  • 遇到过 ssh 的问题,能试出"让问题消失"的办法,但是不知道背后的原因
  • 没有遇到过 ssh 的问题,但是希望进一步了解 tiup ssh 的细节

那么你可以读一下这篇文章,我用了一个简单的、贯穿全文的例子,将 tiup cluster 工具用到的三个账户作为切入点,跟大家说说 tiup 如何连接远程机器,以及用什么方法来确认我们已经做好了集群部署准备。

而对 tiup cluster 和 ssh 很熟悉的朋友,就不需要往下看了。

一句话概述 tiup cluster 部署

管理员在中控机上执行 tiup 命令,把从 mirror 下载的发布包拷贝到集群机器上,分发配置和脚本,创建运行服务的账户,并使用 systemd 管理各种服务。

image

实际上这些操作就是经典的配置管理(configuration management) 操作,
也就是被 tiup 取代的 tidb-ansible 所做的事情。

例子

我们以这份 abc.topo.yaml 拓扑文件为例,直接用例子来说话

global:
  user: ti-service
  ssh_port: 2222
tidb_servers:
  - host: 10.2.1.3
tikv_servers:
  - host: 10.2.1.3
pd_servers:
  - host: 10.2.1.3

另外,集群部署的命令行如下:

ti-ctr@host:~$ whoami
ti-ctr

ti-ctr@host:~$ tiup cluster deploy abc v5.1.1 abc.topo.yaml -u admin -i tidb.id_rsa

仔细看这个简单的例子,这里提到了三个账户:

账户 说明 用户的位置
ti-ctr 运行 tiup 的账户 中控机上
admin 集群节点上的高权限账户 集群节点上
ti-service 集群服务账户 集群节点上

也许你部署集群的时候,这三个账户全是 root 或者全是 tidb (没必要,也不推荐)
但是也没关系,不影响以下的讨论,自己代入合适的角色即可

运行 tiup 的账户

即例子中的 ti-ctr 账户,这个账户的存在"理所当然",毕竟你总要先有一个账户,用这个账户去安装 tiup 和配置 tiup mirror,然后才可能发生后面的事。

tiup 对这个 ti-ctr 账户都有哪些必需的要求呢?

  1. 能执行 tiup
  2. 能访问 mirror
  3. 能 ssh 登录集群节点

你可能觉得有点少,但是确实不需要更多了。

  • 不需要 ti-ctr 在中控机上有高权限。对中控机来说,ti-ctr 可以是一个普普通通的账户,因为使用 tiup 不需要高权限。
  • 不需要 ti-ctr 能免密码登录集群节点

关于 ssh 认证和登录,社区里很多人说,要提前配置好密钥对认证,让 ti-ctr 可以免密码登录集群节点。其实完全没必要。执行一下 tiup cluster deploy -h 就能看到,你可以在部署的时候,命令行指定如何认证(密钥对认证 or 密码认证)。

image

如果命令行没有指定私钥文件位置,也没有指定密码。那么 tiup 会尝试用 $HOME/.ssh/id_rsa 做密钥对认证,也会尝试交互询问你 ssh 密码。

📝 集群节点上,ti-ctr 账户可以不存在,比如例子中,ti-ctr 登录集群节点是用的 admin 账户。可以用下面的 ssh 命令来理解这一点(也可以作为部署前的验证手段):

ti-ctr@host:~$ ssh 10.246.201.3 -l admin -i tidb.id_rsa -p 2222
admin@host:~$ whoami
admin

思考

  1. 和 Ansible 默认使用系统原生的 OpenSSH 不同,tiup 默认使用了 go 实现的 SSH(某个开源的方案),损失了一些 OpenSSH 的功能,遇到复杂的认证环境,也许会出问题。(其实 tiup 也提供了实验性功能来支持用户选择 system ssh)
  2. tiup 把 ssh 连接的端口信息当成了集群配置(写死在拓扑文件里),TiDB集群上的服务,本应该和 sshd 服务无关的,现在把 sshd 的端口信息绑到了 TiDB 集群配置里,这样合理吗?

集群节点上的高权限账户

即例子中的 admin 账户

如果命令行中不指定的话,默认是本地当前账户,即执行 tiup 的用户,这也是常见的 ssh 客户端行为

这个账户是初始部署/扩容时的核心账户,没有这个账户,tiup 就无法在集群节点上:

  • 创建服务账户(例子中的 ti-service)
  • 创建目录,分发配置文件、脚本等
  • 配置系统级 systemd units, 管理进程
  • 管理操作系统和硬件的参数和配置

这些操作必须得高权限账户才能做,因此可以比较自然地列出,tiup 对这个 admin 账户的要求:

  • 部署集群前,集群所有节点上都必须存在
  • 可以免密码 sudo as root 执行所有命令

🛠️ 部署之前,你可以在所有集群节点上使用 admin 账户执行 sudo -ll 命令,来确认一下是否满足部署条件:
注意,执行该命令不能输入密码。从结果里重点看有没有 !authenticate 的条目,以及能否以 root 身份执行所有命令。比如类似这样的:

Sudoers entry:
    RunAsUsers: root
    Options: !authenticate
    Commands:
        ALL

或者这样的:

Sudoers entry:
    RunAsUsers: ALL
    RunAsGroups: ALL
    Options: !authenticate
    Commands:
        ALL

如果你能从中控机登录到集群各节点(登录账户为admin),而且 admin 的 sudo 规则也都完整,那么恭喜你!tiup cluster deploy 的操作起码不会遇到连接问题和权限问题了。

📝 重要!在 cluster deploy 操作完成之后,tiup 就抛弃了这个 admin 账户。后续的 tiup cluster 管理操作,直接使用了下面讨论的 ti-service 账户。

集群服务账户

即例子中的 ti-service 账户

如果配置文件中不写的话,默认是 tidb

这个账户是 tiup 用 admin 账户创建出来的。也就是说,admin 账户在集群节点上拥有高权限,可以创建和管理别的账户;admin 账户在集群节点上创建了 ti-service,并赋予了 ti-service 高权限(足以管理集群内部服务,事实上它拥有最高的权限)。

虽然上面的例子里,为了文章的主题 我显式指定了账户名 ti-service,但是,其实不用太关心这个账户,大部分情况下保持默认值即可。tiup 对它的要求也几乎没有,如果非要配置的话,起一个有效的用户名即可。

显然, ti-service 没有必要在部署前存在(最好是部署前不存在)。

部署之后这个账户的作用有两个:

  1. 在集群节点上,运行像 tikv-server, tidb-server 这样的进程
  2. tiup 使用该账户管理集群

最关键的就是这第二点。

刚开始部署集群时,tiup 就自己生成了一对密钥对,保存在 <tiup_home>/storage/cluster/clusters/abc/ssh/ 目录下,并把公钥放到了集群各节点上 ti-service 账户的 authorized_keys 中。

$ tiup cluster list

🛠️ 执行 cluster list,注意看第二列 User 和最后一列 PrivateKey,就是管理集群的 ssh 账户和它的私钥位置。集群部署/扩容完之后,tiup 的集群管理操作就都是用这个账户了。

因此如果集群部署后 tiup 还遇到了 ssh 认证失败的问题,而你想用 ssh 客户端来做一下验证,那你得像这样验证(忘掉之前的admin吧,tiup 今后用的都是 ti-service):

$ ssh -i <tiup_home>/storage/cluster/clusters/abc/ssh/id_rsa -l ti-service -p 2222

思考

如果总结一下 tiup 的这个做法:就是它把运行服务的账户 ti-service 同时也当成管理服务的账户。

这跟典型的服务部署思路不太一致,一般的做法是仅分配一个普通账户来运行服务,这个账户跟管理用的高权限账户无关。以本文的例子来说,就是 ti-service 只用来跑服务,当用户使用 tiup cluster 组件来管理集群时(比如 reload/stop/start 等),用户需要告诉 tiup 用哪个账户连接、如何连接集群。我觉得这样更好,可惜 tiup 不是这样做的。

另外, tiup 固定使用一个账户来管理集群,该账户的私钥文件还是单点存储在 tiup 中控机上的,那这算不算整个集群中单点故障风险最高的地方呢?所以,如果你不知道 tiup 本地数据丢了怎么办,那就积极做备份吧。

2
3
1
0

版权声明:本文为 TiDB 社区用户原创文章,遵循 CC BY-NC-SA 4.0 版权协议,转载请附上原文出处链接和本声明。

评论
暂无评论