配置文件那些事

Posted wbjxxzx

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了配置文件那些事相关的知识,希望对你有一定的参考价值。

深夜的办公室灯火通明,为了今晚的大版本上线,同事们已经连续奋战了几十个日日夜夜。"但愿今晚平安上线,接下来就能休息几天了",小明这样想着,打开终端登录服务器,等待操作时间到来。

作为一名运维工和师,这样的版本升级小明经历过无数次,况且在之前进行过数次模拟升级,这次想必也不会出什么太大的问题。

升级时间到了,小明深吸一口气,手指开始在键盘上飞舞,停止进程、备份文件、更新程序、启动、验证,一系列步骤有条不紊的进行着……

“小明,为什么我这里vi打开文件是乱码?”小明停下手中的事情,循声望去,原来是开发人员小刚。“把你的终端编码改一下” “在哪里改?” “就在设置那里” “找不到啊,过来帮忙看看啦” 小明无奈起身,走到小刚身边,教他修改终端字符编码……

同事们都在紧张的忙碌着,墙上挂钟那红色的指针也在不知疲惫的一圈又一圈的行进。。。

“警告警告,XX服务器 /data 占用率 100%,请及时处理。”小明赶紧登录检查,发现该目录下的一个 log 占了90%的磁盘空间,里面的 xx.debug.log 占用达几十个G。看来是有人打开了调试模式,小明一边清理日志,一边在群里发问。
原来是小刚验证的时候发两点逻辑有点对不上,然后把调试模式打开了,大量的信息很快就把磁盘空间撑爆。处理完这个问题,小明继续之前的工作。。。

“小明,我加了个配置项,需要同步一下全部服务器。”小刚走了过来,“好,没问题。”小明平静的说到,心想这家伙又来搞事。

过了一会,小刚又过来了:“不好意思啊,刚刚那个配置项要改一下,改成xxx。” 小明有点想骂人了,但还是平淡的说:“要改成什么?”

……

配置文件那些痛

故事有些夸大的成份,但里面的场景确实有发生过,相信很多运维同学也是深有体会。维护一套系统,少不了的就是配置文件,故事里修改配置的几大痛点就是我想要解决的:

  • 连接服务器的终端字符编码不一,配置内容可能显示乱码
  • 不同的人修改了配置项,不知道改了什么内容
  • 修改了配置项后如何同步
  • 同步后又反悔了,怎样快速改回之前的内容

如果我们提供一个统一的修改入口,那么编码不一的问题是不是就解决了?
有人修改了内容,我们就保存一个快照;后面若是反悔,可以马上使用这个快照,是不是同时满足了保存修改和修改历史?
快速同步,从主控端分发过去行不行?

我看行!

配置文件管理

使用B/S架构来做配置管理是很自然的事情,实现起来也比较简单:

  • 浏览器作为统一的修改入口
  • 后端保存文件的修改历史,每一次修改都生成一个新的修订号
  • 同步到相关服务器就是将配置内容下发

那么问题又来了:
单个配置文件管理起来不难,要是多个不同的文件呢?多个文件我只改了其中一个呢?新增加一个文件又不想改动原来的呢?

配置文件包

上述问题,我们可以引入“包”这个概念,一个“包”里可以有一个或多个配置文件,我们对“包”作一个快照,也就是历史版本,那么问题就迎刃而解。

比如可以设计成下图的样子:

技术图片

A B C 代表3个配置文件包,里面的 a.con b.conf aa.txt 就是具体的文件,数字代表修订号。这样就保存了修改历史,方便回溯,对应的数据模型用 django 的 models 来表示:

class ConfRevision(models.Model):
    name = models.CharField(max_length=48, help_text='名称')
    revision = models.PositiveIntegerField(help_text='修订号')
    is_default = models.BooleanField(default=False, help_text='是否默认')
    created = models.DateTimeField(auto_now_add=True)
    created_by = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.DO_NOTHING)
    description = models.CharField(max_length=120, blank=True, null=True)

class ConfDetail(models.Model):
    FILE_TYPE = (
        ('ini', 'ini'),
        ('conf', 'conf'),
        ('json', 'json'),
        ('yml', 'yml'),
        ('toml', 'toml'),
    )
    name = models.CharField(max_length=48, help_text='配置文件名称')
    type = models.CharField(max_length=4, choices=FILE_TYPE)
    content = models.TextField(null=True, blank=True)
    created = models.DateTimeField(auto_now_add=True)
    created_by = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.DO_NOTHING)
    description = models.CharField(max_length=120, blank=True, null=True)
    rev = models.ForeignKey(ConfRevision, on_delete=models.DO_NOTHING)

内容下发

有句名言如是说:“手里拿着锤子,看什么都像是钉子”。

ansible 作为运维利器简直是深得我心,一开始就是想着用ansible去同步全部主机的内容,但是一些情况下会有问题:

  • 假如当前有个待同步的主机宕机,本次的同步会漏掉一部分主机
  • 资源抢占问题:多个人同时修改,如果后面的修改先同步到目标主机,而前面的修改延迟到达,导致内容覆盖,本来应该全网统一的内容在个别机器上不一致

为了尽量避免上面情况发生,我们需要另一种方式,即使出现极端情况也能保证配置文件全网一致性:
在每台主机上启动一个代理,从一个中心存储拉取内容,当中心存储的内容变化时通知代理。

分析配置文件,全部是文本内容,很方便使用 key-value 存储,进而想到业界知名的 k-v 存储redis,然而数据持久化并非redis擅长,排除。

etcd 倒是一个不错的选择,满足我们所有要求:

  • 支持 key-value
  • 分布式、强一致性
  • 支持发布-订阅模式

那么决定是他了。

配置同步代理

主机上的代理程序要简单、支持etcd、少依赖,有现成的 confd 就不用重新造轮子了。

功能实现

当收到新增请求(因为做了版本管理,所以每次的修改请求都是创建一个新的版本),后台的处理流程:

  1. 校验数据:非空校验、内容格式校验
  2. 写入数据库,同时将内容写入etcd
  3. 主机上的 confd 监听到对应 key 的内容变化,同步内容到本地

若要回退,只需要将对应的历史版本内容写入etcd
而且记录历史版本,搞事的人就无法甩锅,大家可以尽情的嘲讽他~~~

这里实现了全网配置统一,但是如果有某个新功能需要个性化的配置,又该怎么办呢?欲知方法如何,且听下回分解。

以上是关于配置文件那些事的主要内容,如果未能解决你的问题,请参考以下文章

阿粉想和你详细聊聊 Jenkins 配置那些事

php安装配置那些事(本文纯属个人记事与技术无关)

mybatis的那些事

聊聊视频播放那些事1

数仓开发遇到的那些事

docker镜像那些事!您懂多少?