在日常工作中，维护运行某些程序，需要通过配置文件，更改软件的行为逻辑，比如Nginx的配置文件、Prometheus的配置文件等。在较复杂的一些真实业务场景中，可能还涉及多机房的加载不同配置文件。
熟悉配置管理工具的同学，可能脑子已经想到Ansible、Puppet等了，此类工具的确擅长做这样的事情。
本文主要介绍，如何使用Git + Ansible + Gitlab Pipeline实现自动管理多机房的配置文件，适合小公司维护不复杂业务的场景，大公司打螺丝的多、工具管理软件成熟、合规要求等不推荐。
好处是显而易见的，Git有版本管理功能，Ansible方便部署、轮子多滚起来很愉快、Pipeline自动推送省事，是个公司都有这些条件。
这里假设你要维护多个机房的Prometheus监控配置文件，读者理解后可自行运用，有一定的通用性。
创建一个Gitlab仓库，把Ansible playbook 和 Prometheus 配置管理起来。
按照下面的示例组织Prometheus配置文件：
1➜ prometheus git:(main) tree
2.
3├── idc_A
4│ ├── prometheus.service
5│ ├── prometheus.yml
6│ ├── rules
7│ │ ├── demoA.yml
8│ │ └── upB.yml
9│ └── sd_config
10 ├── my_target.yml
11
12│── idc_B
13│ ├── prometheus.service
14│ ├── prometheus.yml
15│ ├── rules
16│ │ ├── demoB.yml
17│ │ └── upB.yml
18│ └── sd_config
19│ ├── my_targetB.yml
上面的意思就是，假设你要维护机房A 和 B 的Prometheus监控文件，分别放到Git仓库的两个子目录中，后续会通过目录名称区分触发Pipeline，运行不同的Ansible分支任务。
文件的内容就不一一列举了，意义不大。
Ansible不详细介绍了，网上一大堆资料，不懂问AI也可以。
只写核心区分机房的逻辑:
1➜ ansible git:(main) cat hosts
2[prom:children]
3a_host_group
4b_host_group
5
6[a_host_group]
7192.168.1.1
8
9[a_host_group:vars]
10idc=idc_A
11
12[b_host_group]
13192.168.2.1
14
15[b_host_group:vars]
16idc=idc_B
用变量idc区分不同机房, 传输不同配置。
1
2- name: Copy 'rules' file
3 ansible.builtin.copy:
4 src: "{{ item }}"
5 dest: "/opt/prometheus/rules/"
6 mode: 0644
7 validate: /opt/prometheus/promtool check rules %s # 常校验是好习惯，防止离谱提交
8 with_fileglob:
9 - '{{ config_path }}/{{ idc }}/rules/*' # 这里引用了idc变量
10 notify: Reload Prometheus
如果你不懂上面是什么意思，建议读一读ansible的教程文章，找个环境实验下。
付费咨询也可以，关注公众号留言联系，商业协作，双赢😄。
1➜ cat .gitlab-ci.yml
2stages:
3 - checkout
4 - deploy
5
6checkout_code:
7 stage: checkout
8 tags:
9 - your_ci_runner # 你的ci runner
10 script:
11 - |
12 if [ ! -d "/data/your_code_path" ]; then
13 echo "目录不存在, git clone"
14 git clone git@xxx.git /data/your_code_path
15 else
16 echo "目录存在, git pull"
17 cd /data/your_code_path && git pull
18 fi
19 only:
20 - main
21
22prometheus-deploy-A: # A 机房的部署逻辑
23 stage: deploy
24 tags:
25 - your_ci_runner
26 rules:
27 - changes:
28 - prometheus/idc_A/**/* # 目录A有变动就触发
29 before_script:
30 - pwd
31 - cd /data/ansible
32 - source .venv/bin/activate
33 script:
34 - echo "Deploying Prometheus A"
35 - ansible-playbook -i hosts deploy.yml -l a_host_group # 执行具体的ansible playbook
36
37prometheus-deploy-B: # B 机房的逻辑类似A，不再解释
38 stage: deploy
39 tags:
40 - your_ci_runner
41 rules:
42 - changes:
43 - prometheus/idc_B/**/*
44 before_script:
45 - pwd
46 - cd /data/ansible
47 - source .venv/bin/activate
48 script:
49 - echo "Deploying Prometheus B"
50 - ansible-playbook -i hosts deploy.yml -l b_host_group
上述代码我删掉了部分隐私信息(职业操守还在，底线守住)，并没有测试运行，主要介绍逻辑思路。真实环境已经修改提交过几十次，平稳顺滑，大幅节约时间。
为了安全，最好在Ansible里面加上各种Lint或者说Check逻辑，防止配置一推上去，全干崩了！其实干崩了也没关系，毕竟是Git管理的配置，可以回滚嘛。
回滚不了，你还以复制到服务器上去嘛，真走到这一步，得反思下，停下来学点真本领。
不尬不吹，互联网上，我还没搜到类似细节文章，懂的人不一定愿意分享，又是牺牲周末时间在写这个破文章，有时候也不知道是为了什么。
总之，当你更改A、B机房配置的时候，直接在对应的Git目录修改文件，提交后，会促发对应的Ansible部署操作。
所有逻辑都是自己定义的，简单清晰，没有什么外部依赖，一开始可能会遇到错误，逐步修复跑顺后，绝对能舒心放心。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。