使用Git和Ansible管理配置文件

calendar 2024-10-19 · 2 分鐘 · Linux  ·
分享到: linkedin copy

在日常工作中，維護運行某些程序，需要通過配置文件，更改軟件的行爲邏輯，比如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

版權申明:

  • 未標註來源的內容皆為原創，未經授權請勿轉載（因轉載後排版往往錯亂、內容不可控、無法持續更新等）;
  • 非營利為目的，演繹本博客任何內容，請以'原文出處'或者'參考鏈接'等方式給出本站相關網頁地址(方便讀者)。

相關文章:

翻譯: