基于CNAME解析实践的域名优雅方案
通常,我们针对域名管理,以及其下 NGINX 配置文件的管理,大多都是分散的,这种分散并不是刻意为之,而是随着业务发展以及需求的对接,不知不觉中,发现域名加了一个又一个,配置文件更是各不相同,这对标准化而言是个灾难,对未来的操作更是注入了不稳定因素。
所谓天下大势,分分合合。
形如 hosts 到 dns,jenkinsfile 到 share library,我统一把这种思路归到初中时的一个数学思路:提取公因式。
那么对于域名解析方面的实践,这里要介绍的,其实也是一次提取公因式。
# 1,CNAME
# 1,分析
通过 CNAME 的方式,我们能够轻松的将一些相对集中的域名进行更加优雅统一的管理,这种方案的思路大概如下:
假如我们的测试环境所有的域名有一个统一的入口 NGINX,此后所有的测试域名都在这里解析,如果按照传统的思路,那么一个域名对应一条 A 记录,那么如果测试环境有 100 个域名,就会需要添加 100 个 A 记录,这看起来似乎也没什么问题,但是,如果这个时候因为一些原因,此入口 NGINX 需要迁移,或者外网 IP 不得不更换,此时即便是有工具能够批量修改 100 个 A 记录,也是一个不够优雅便捷的方案。
我们稍微调整一下方案:解析一个统一的 A 记录在入口处,然后其他域名都通过 CNAME 的方式解析到统一的 A 记录上,这样一来,就算是测试入口需要变更,也只需要更改一条记录即可解决此问题,而不需要考虑那 100 个了。
# 2,示例
此时我拿个人域名 eryajf.net 举例,当前 wiki 站点域名解析如下:
$ dig wiki.eryajf.net
; <<>> DiG 9.10.6 <<>> wiki.eryajf.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15687
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;wiki.eryajf.net. IN A
;; ANSWER SECTION:
wiki.eryajf.net. 599 IN A 8.136.215.57
;; Query time: 253 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Jun 22 23:24:33 CST 2021
;; MSG SIZE rcvd: 60
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
可以看到是直接 A 记录解析到 8.136.215.57
。
现在,我在 DNS 解析中做一些调整:
先加一条 A 记录
prod.eryajf.net
:然后添加一条 CNAME 记录作为正常的服务域名
wiki.eryajf.net
:
这个时候我们可以将域名 CNAME 到上边定义的 A 记录,那么就能把 100 个域名进行统一解析管理了。
注意:
CNAME 记录值中域名最后位的点可带可不带。
此时该域名的解析链路如下:
$ dig wiki.eryajf.net
; <<>> DiG 9.10.6 <<>> wiki.eryajf.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40403
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;wiki.eryajf.net. IN A
;; ANSWER SECTION:
wiki.eryajf.net. 599 IN CNAME prod.eryajf.net.
prod.eryajf.net. 599 IN A 8.136.215.57
;; Query time: 440 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Jun 22 23:33:39 CST 2021
;; MSG SIZE rcvd: 79
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
其中的 ANSWER SECTION
很清晰地列出了整个链路解析流程。