SQL审核平台 Archery 之简单使用篇 _使用

幽映每白日，清辉照衣裳。这篇文章主要讲述SQL审核平台 Archery 之简单使用篇相关的知识，希望能为你提供帮助。
一、相关概念说明 1、资源组? 资源这里的意思，其实指的是 " 数据库资源 " ，那么资源组，就是说这个组与之相关联的数据库。创建资源组的时候，直接创建就好了，设置组名就好了，别的没什么信息要填写的了。具体见下面 " 添加资源组的截图 " 。

? 创建用户账号的时候必须指定这个账号 " 归属 " 的资源组，有些账号同时属于多个资源组，或者说这个账号是关联着多个资源组。这个是在创建用户账号或者修改用户账号时再制定。( 做过 Archery 和 Ldap " 打通 " 的，Ldap 所有账号都没有关联过资源组，所以后续必须有对要登录使用 Archery 的账号的指定相关资源组的这个操作 )。

? Archery 平台刚部署之后，系统这里是没有任何资源组的，所以必须要手动添加资源组，依照要设定的审核流程，设置相应的资源组个数，本次实验审核流程有三步，故这里要添加三个资源组。

? 如果要使用 Archery 结合 DingDing ，在配置 Webhook 的过程中，要在相关资源组设置 Access_Token，才能够完成在整个审核流程中 DingDing 的通知提醒功能。或者是 Archery 结合飞书、企业微信，都是在这里进行设置。
2、权限组? 权限组的意思就很简单明了，就是对用户账号的操作做权限限定，限定哪些用户账号能够干什么，哪些用户账号不能够干什么，具体在 Archery 平台上的体现就是，哪些账号只能提交审核，哪些账号可以审批已提交的审核，又哪些用户账号可以执行已提交的审核，等等例如这些。

? 创建用户账号的时候，必须指定这个账号所关联的权限组，一个账号只能够关联到一个权限组。( 做过Archery 和 Ldap " 打通 " 的，Ldap 所有账号都没有关联过权限组，所以后续必须有对要登录使用 Archery 的账号的指定相关权限组的这个操作 )

? Archery 平台刚部署之后，系统这里是有五个系统自带的权限组 ---RD 、PM 、QA 、DBA 、Default , 每个组都有各自对应的权限。使用系统自带的组，就能够完成一个完整的审核流程。当然也可以自己定定义权限组，用一些比较有个性化的名字，然后设置相对应的权限，也是可以完成一个完整的审核流程的。
3、实例与数据库? 实例，指的就是哪个服务器上面的数据库管理系统 (通常大家称呼习惯了为数据库)，而这里提到的数据库，才是真正的数据库，是这个数据库管理系统里面的各个数据库，是我们使用命令 " show databases 或者 show dbs " 得到的结果。

? 这里，我们要区别一下, 在没有接触使用 Archery 审核平台之前，我们接触到的 " 实例" 这个概念。例如在我们服务器 (地址：172.16.1.10)上安装了一个 mysql 的数据库管理系统，并且部署好了两个实例，使用的端口分别是 3306、3308 ，那么一般都说这里是个多实例 MYSQL，每个实例下面有各自的数据库，这个没有毛病，老铁！结合 Archery 的实例描述起来，同样也是两个实例，比方说实例 172.16.1.10_3306 实例、172.16.1.10_3308 实例，这个并不冲突和矛盾。数据库呢，也就是两个实例里面各自包含的数据库。
4、用户账号? 用户账号，就是登录 Archery 平台的账号了，用来操作、使用 Archery 平台，进行相关的审核操作。
? 创建用户账号的时候，必须指定这个账号所关联的权限组、资源组。一个用户账号只能关联一个权限组，但是可以关联到多个资源组，在审核流程中，除了提交SQL审核上线的那个用户账号，后面的账号必须是关联到多个资源组，也就是说后面的用户账号除了自身的资源组之外，还必须关联到前面一个用户账号所关联到的资源组。

? 用户账号的来源：一个是中 Archery 平台有管理员创建，第二是 Ldap 里面的账号，但是 Ldap 里面的用户账号必须登录过一次 Archery 平台，才能够中用户管理里面看得到，稍后再编辑这些账号并配置相关的权限组、资源组。
二、添加资源组 " 系统管理 " ---" 资源组管理 " ---" 添加组 " ---" 组名称 " ---" 保存 "
三、添加用户? " 系统管理 " ---" 其他配置管理 " ---" 用户管理 " ---右上角的位置 " 增加用户管理 + " ---" 认证信息（用户名、口令、口令确认）" ---" 个人信息（显示中文名、电子邮件信息） " ---" 权限信息（组，指的是从系统默认的五个权限组中选择一个、用户权限这里不操作） " ---" 资源组（选择一个或者多个资源组） " ---" 保存 "

? " 用户权限" 这里不做任何的操作，因为用户权限这里由用户账号所属的权限组来限定，所有这里就先不指定了
四、添加实例和数据库? " 实例管理 " ---" 实例列表 " ---" 添加实例 " ---" 增加实例配置（实例名称、实例类型、数据库类型、实例连接、端口、用户名、口令、数据库、字符集、资源组、实例标签(支持上线、支持查询都加上) ） " ---" 保存 "

? " 数据库管理 " ---" 请选择实例 " ---" 创建数据库 " ---" 数据库名称 " ---" 负责人 " ---" 备注 " ---" 创建 "
五、系统配置? 左边的操作： " 系统管理 " ---" 配置项管理 " ---" 选择操作 " ---" 配置项 ( 系统设置 ) "
? 右边的操作： " Inception配置 " ---" GO_INCEPTION_HOST " 填写 " goinception " 、" GO_INCEPTION_PORT " 填写 " 4000 " ---最下面点击" 保存配置 "

说明：

此处配置是使用goinception 或者 inception 来实现对 SQL语句的检测功能，配置这两项即可
配置好上面之后，++不要点击++ 配置项后面的 " 测试连接 " ，点击是会报错的，这个是结合下面要填写的备份数据库的信息，来实现对审核的SQL语句进行备份操作的，不要理解错了，不设置备份操作的话，在这里就不需要填写

六、工单审核流配置提示说明：

这里记录下 Archery 刚安装后，资源组、用户账号、实例和数据库都没有的情况下，把这些都完整的添加一下，只有这些必要的组都存在了，方能进行下面的配置审核流的操作
正确的添加顺序是
- 第一步是先创建资源组
- 第二步是添加数据库实例和数据库
- 第三步才是添加用户账号
- 第四步才是设置工单审核流
Archery是使用了Django框架实现的。数据库实例及数据库操作、资源组的操作操作，都是在 " 前台 " 实现的。而用户账号的操作、权限组的操作则是在 " 后台" 实现的，下面放上一个" 后台" 操作的截图，大家先感受一下。

文章图片

1、添加资源组、用户账号

添加三个资源组 --- 测试组、开发组、运维组
添加两个数据库实例和实例下的测试数据库并指定数据库对应的资源组
- MYSQL 数据库的实例 ( 名称为：MYSQL129 ) ，数据库为 test1290
- MONGODB 数据库的实例( 名称为：MONGODB130 ) ，数据库为 test130
- 以上两个数据库实例下的数据库都指定资源组为测试组
创建三个测试账号：archery001 、archery002 、archery003 , 并指定组
- archery001加入到 RD 组，资源组为测试组
- archery002加入到 PM 组，资源组为测试组、开发组
- archery003加入到 DBA组，资源组为测试组、运维组
这里提出个疑问： ( 答案在文章的最后面 )
能否指定数据库实例里面的数据库同时属于多个资源组，这样就不需要让用户账号关联多个资源组了？？？

2 、定义工单审核流程? 我们设定工单审核流为：RD ---> PM---> DBA（使用 Archery 平台自带的权限组就可以了）

? 左边的操作： " 系统管理 " ---" 配置项管理" ---" 选择操作 " ---" 配置项 ( 工单审核流配置 ) " ---" 工单类型 ( SQL上线申请 ) " ---" 组 (测试组) "
? 右边的操作： " 操作 " ---" 请选择审批权限组 " 下拉框---第一次选择 PM 组，第二次选择 DBA 组---" 变更 "
3、进行工单审核流程测试这里就不再多 BB了，直接上图：
1） archery001 的操作

文章图片

文章图片

2） archery002 的操作

文章图片

文章图片

【SQL审核平台 Archery 之简单使用篇】

文章图片

3） archery003 的操作?在此环节, archery003 账号的操作其实有两个步骤的，截图这里没有第一个步骤的截图 ( 感觉没必要 )

第一个步骤：其实很上面的 archery002 一样的，也是有一个 " 审核通过" 的按钮的执行界面
第二个步骤：才是下面第二、三个截图里面的 " 立即执行" 的界面，然后点击执行

文章图片

文章图片

? 分别去实例MYSQL129 、MONGODB130 各自的数据库 test1290 、test130 里面查看，就会看到，一个SQL审核流程走完，对应的数据库里面都有SQL提交的相关信息。至此，整个 Archery 的简单使用就完成了。
七、疑问解答 1、奇怪的现象? 本次中学习 Archery 的过程中，曾出现一个 " 奇怪的现象 " ，不论系统配置如何调整；不管审核流程怎么设置；不管各个用户账号权限这么修改，最后都是出现同一个问题---那就是最初的SQL上线人提交的上线审核，最终都只有管理员才看得到这个SQL审核申请,除此之外，任何账号都看不到已经提交了的SQL上线申请。
? 到后面去查阅了开发者的 GITHUB ，才找到了解决办法。那就是账号--- 具体的说，就是审核流程中后面的审批操作的账号，必须在自己是属于一个资源组的时候，同时还要关联到审批上线申请人所在的资源组，这样才能够看到这个申请者提交的上线审批。这个是作者的标准回答，也因此，才出现了一个账号关联多个资源组的情形。

? 假设： " 违反一下 " 开发者的意愿，不遵循他设计并开发这个软件的要求，试试另外一种情况，会如何呢？？
2、自定义场景? 假设的设计是这样的：
? 一个数据库实例里面的某个数据库，关联到多个资源组，而用户账号只关联到一个资源组，那么当一个SQL申请提交后，因为这个数据库已经关联到了多个资源组了，那这样属于( 关联了）别的组的用户账号，应该是可以看见已经提交的SQL上线请求的，并且是可以进行审批，下面试试看。。。

?就以 MYSQL 数据为例：

实例 MYSQL129 里面的数据库 test1290 ，关联到测试组、开发组、运维组
testuser001加入到 RD 组 ,资源组为测试组
testuser002加入到 RD 组 ,资源组为开发组
testuser003加入到 RD 组 ,资源组为运维组

3、进行测试以 testuser001 登录 Archery 平台，进行SQL 上线申请的提交：

文章图片

? 提交成功，如下图

文章图片

? 用 testuser002 账号登录，进行审核操作，会发现，找不到任何人已经提交了的申请。

文章图片

? 换用 testuser003 登录，发现结果是同样如此。。。

文章图片

切换到使用管理员 admin 账号登录，才可以看到 testuser001 提交的SQL 上线申请，即验证了上面说明的问题。

文章图片

4、问题总结? 上面的测试，完美的说了两个问题：

第一，审核流程中除SQL审核提交人之外，后面的审核人，都必须关联到SQL提交人所在的资源组
第二，实例数据库和资源组及用户账号之间的关联关系，只能够是软件作者设计的那套流程，即用实例数据库下的数据库只关联到SQL审核提交人的资源组，而用户账号再关联到这个审核流程中自己所在组以及前面一个用户账号所在的资源组。