使用Git和Ansible管理配置文件

2024-10-19 · 2 分钟 · Linux ·

分享到:

在日常工作中，维护运行某些程序，需要通过配置文件，更改软件的行为逻辑，比如Nginx的配置文件、Prometheus的配置文件等。在较复杂的一些真实业务场景中，可能还涉及多机房的加载不同配置文件。

熟悉配置管理工具的同学，可能脑子已经想到Ansible、Puppet等了，此类工具的确擅长做这样的事情。

本文主要介绍，如何使用Git + Ansible + Gitlab Pipeline实现自动管理多机房的配置文件，适合小公司维护不复杂业务的场景，大公司打螺丝的多、工具管理软件成熟、合规要求等不推荐。

好处是显而易见的，Git有版本管理功能，Ansible方便部署、轮子多滚起来很愉快、Pipeline自动推送省事，是个公司都有这些条件。

这里假设你要维护多个机房的Prometheus监控配置文件，读者理解后可自行运用，有一定的通用性。

1. 创建一个Git仓库

创建一个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分支任务。

文件的内容就不一一列举了，意义不大。

2. 编写Ansible playbook

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的教程文章，找个环境实验下。

付费咨询也可以，关注公众号留言联系，商业协作，双赢😄。

3. gitlab ci 编写

 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

4. 总结

上述代码我删掉了部分隐私信息(职业操守还在，底线守住)，并没有测试运行，主要介绍逻辑思路。真实环境已经修改提交过几十次，平稳顺滑，大幅节约时间。

为了安全，最好在Ansible里面加上各种Lint或者说Check逻辑，防止配置一推上去，全干崩了！其实干崩了也没关系，毕竟是Git管理的配置，可以回滚嘛。

回滚不了，你还以复制到服务器上去嘛，真走到这一步，得反思下，停下来学点真本领。

不尬不吹，互联网上，我还没搜到类似细节文章，懂的人不一定愿意分享，又是牺牲周末时间在写这个破文章，有时候也不知道是为了什么。

总之，当你更改A、B机房配置的时候，直接在对应的Git目录修改文件，提交后，会促发对应的Ansible部署操作。

所有逻辑都是自己定义的，简单清晰，没有什么外部依赖，一开始可能会遇到错误，逐步修复跑顺后，绝对能舒心放心。

最后修改于： Saturday, October 19, 2024

版权申明:

未标注来源的内容全部为原创，未经授权请勿转载（因转载后排版往往错乱、内容不可控、无法持续更新等）;
非营利为目的，演绎本博客任何内容，请以'原文出处'或者'参考链接'等方式给出本站相关网页地址(方便读者)。