运维自动化基础建设|主机名规划篇

运维自动化基础建设|主机名规划篇

在 K8S 还没有那么普及的年代，主机名的定义真的是一门大学问，随便找个技术群，把这个问题丢进去，分分钟就能得出N多种不一样的答案，接下来我们讨论下主机名定义的问题。

如何定义主机名

默认情况下如果是自建 IDC 的场景下，创建的机器大多数以 localhost 来命名，公有云的话，主机名多半是随机的一个字符串来标识主机名，这个时候如果关联 CMDB 应用的话，这个时候你就会发现，一堆的 localhost 机器，辨识度很低，使用 IP 的话，又没法很好的区分这台或这组机器到底和什么服务是有关联的。

我们来看下当前 Google 上关于主机名定义规范的文档

在上图示例中，我们可以看到，输入关键字 linux 主机名规范 + 企业运维，Google 搜索弹出来了3,610,000条结果，看来这个大家对这个问题的讨论还是满热烈的。

那么问题来了，如何定义主机名

关联部署方式,专机专用

专机专用的场景下，主机名的定义多半和应用名称有关系，比如我开设2c/4g的机器两台专门给 A 应用，这个时候主机名的定义类似这种appname-languagetype-ip后两位-0x.domain这种方式来定义主机名，这个场景下在堡垒机上和 CMDB 上相对来说还是比较清晰的，可以做到见名知意~

在前面文档我们也提到约定大于配置, 如上所说，如果我们订好了标准，在后续的CI/CD的使用中，我们只需要关注appname这一列即可，因为appname在CMDB中是唯一的关键字，通过这个关键字去检索对应的元数据去做下一步的动作，另外一个层面来说，定义好标准之后在新建主机或机器初始化的时候都能够用到，方便快捷~

关联部署模式，混合部署

这种场景下，多个应用部署在同一个机器上，这个时候的主机命名就没办法很好的做到见名知意，同比上面说的专机专用的方式来说我们只能依托于CMDB来实现对应应用的元数据的获取，这个时候使用IP作为关键字去检索，拿到对应的所有的appname, 然后再反推appname对应的元数据信息，或者使用ip:port方式去联合检索，这个时候也是唯一的，同比上面的方式，资源利用率相对来说会上升一些，但是在一些没有CMDB基础建设的场景下，也是加重了 OPS 的负担~

总结

ip地址规划，主机名规划和后续自动化运维息息相关，但是随着K8S的流行开来，这些东西会被逐渐的淡化，一天不上K8S, 肯定还是会被这些东西困扰，所以要认真规划，避免自己给自己挖坑~