Git と Ansible を使った設定ファイルの管理

2024-10-19 · 2 分で読了 · Linux ·

日常業務において、特定のプログラムの保守・運用には、Nginx 設定ファイルや Prometheus 設定ファイルなどの設定ファイルを介してソフトウェアの動作ロジックを変更する必要があります。より複雑な実ビジネスシナリオでは、複数のデータセンターにまたがる異なる設定ファイルのロードが必要になる場合があります。

構成管理ツールに精通している方は、Ansible や Puppet などを既に思い浮かべているかもしれません。これらのツールはまさにこの用途に最適です。

この記事では、主に Git + Ansible + GitLab Pipeline を使用して複数のデータセンターにまたがる設定ファイルを自動的に管理する方法を紹介します。これは、比較的シンプルなビジネスシナリオを維持している小規模企業に適しています。より複雑な構成、成熟したツール管理ソフトウェア、コンプライアンス要件を持つ大企業には推奨されません。

メリットは明らかです。Git にはバージョン管理機能があり、Ansible はデプロイが容易で、複数のツールがあるため管理が容易、そして Pipeline の自動プッシュ機能は便利です。これらはほとんどの企業が備えている機能です。

これは、複数のデータセンターの Prometheus 監視設定ファイルを保守していることを前提としています。読者は理解した上でこれを応用できます。ある程度の汎用性があります。

1. Git リポジトリを作成する

Ansible プレイブックと Prometheus 設定を管理するための GitLab リポジトリを作成します。

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│── idc_B
12│   ├── prometheus.service
13│   ├── prometheus.yml
14│   ├── rules
15│   │   ├── demoB.yml
16│   │   └── upB.yml
17│   └── sd_config
18│   ├── my_targetB.yml

上記の意味は、データセンター A と B の Prometheus 監視ファイルを管理する必要がある場合、それらを Git リポジトリの 2 つのサブディレクトリに配置するということです。パイプラインは後ほど、これらのディレクトリを区別してトリガーされ、異なる Ansible ブランチタスクを実行します。

ファイルの内容は、あまり重要ではないため、ここでは詳しく説明しません。

2. Ansible Playbook の作成

Ansible については、ここでは詳しく説明しません。オンラインで多くの情報が得られます。わからない場合は、AI に問い合わせることもできます。

データセンターを区別するためのコアロジックのみが記述されています。

 1➜ Ansible git:(main) cat hosts
 2[prom:children]
 3a_host_group
 4b_host_group
 5[a_host_group]
 6192.168.1.1
 7[a_host_group:vars]
 8idc=idc_A
 9[b_host_group]
10192.168.2.1
11[b_host_group:vars]
12idc=idc_B

変数 idc を使用して、異なるデータセンターを区別し、異なる設定を送信します。

 1
 2- name: 'rules' ファイルをコピー
 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: Prometheus をリロード

上記の意味がわからない場合は、Ansibleチュートリアル記事をお読みになり、実際の環境で試してみることをお勧めします。

有料相談も承っております。公式WeChatアカウントをフォローして、メッセージをお送りください。ビジネスコラボレーションはWin-Winです！ 😄

3. GitLab CI 開発

 1
 2➜ cat .gitlab-ci.yml
 3stages:
 4  - checkout
 5  - deploy
 6
 7checkout_code:
 8  stage: checkout
 9  tags:
10    - your_ci_runner    # 你的ci runner
11  script:
12    - |
13      if [ ! -d "/data/your_code_path" ]; then
14        echo "目录不存在, git clone"
15        git clone git@xxx.git /data/your_code_path
16      else
17        echo "目录存在, git pull"
18        cd /data/your_code_path && git pull
19      fi
20  only:
21    - main
22
23prometheus-deploy-A:         # A 机房的部署逻辑
24  stage: deploy
25  tags:
26    - your_ci_runner
27  rules:
28    - changes:
29        - prometheus/idc_A/**/*            # 目录A有变动就触发
30  before_script:
31    - pwd
32    - cd /data/ansible
33    - source .venv/bin/activate
34  script:
35    - echo "Deploying Prometheus A"
36    - ansible-playbook -i hosts deploy.yml -l a_host_group # 执行具体的ansible playbook
37
38prometheus-deploy-B:        # B 机房的逻辑类似A，不再解释
39  stage: deploy
40  tags:
41    - your_ci_runner
42  rules:
43    - changes:
44        - prometheus/idc_B/**/*
45  before_script:
46    - pwd
47    - cd /data/ansible
48    - source .venv/bin/activate
49  script:
50    - echo "Deploying Prometheus B"
51    - ansible-playbook -i hosts deploy.yml -l b_host_group

4. まとめ

上記のコードから一部の個人情報を削除しました（職業倫理は維持し、最終的な目標は達成しています）。また、テストは行っていません。主な焦点は論理的な流れです。実際の環境では、数十回にわたって変更とコミットが行われており、スムーズに動作し、大幅な時間節約につながっています。

セキュリティの観点から、設定をプッシュする際にクラッシュしないように、Ansibleに様々なlintまたはチェックロジックを追加するのが最善です。実際には、クラッシュしたとしても、それは問題ではありません。 Git で管理された設定なので、ロールバックは可能ですが、大した問題ではありません。

ロールバックできないのであれば、サーバーにコピーするだけではだめですよね？そうなってしまったら、じっくり考えて立ち止まり、真のスキルを学ぶ必要があります。

誇張表現ではなく、オンラインで同様の詳細な記事を見つけたことはありません。理解している人は共有したくないかもしれませんし、私は週末の時間を犠牲にしてこの記事を書いています。私自身もその理由がわからないこともあります。

つまり、データセンター A と B の設定を変更する場合、対応する Git ディレクトリ内のファイルを直接変更し、コミット後に、対応する Ansible デプロイメント操作がトリガーされます。

すべてのロジックは自己定義的で、シンプルで明確であり、外部依存関係はありません。最初はエラーが発生するかもしれませんが、徐々に修正してスムーズに動作するようになったら安心してください。

最終更新日: Friday, October 31, 2025

著作権に関する声明:

出典のないコンテンツはすべてオリジナルです。、無断転載はご遠慮ください（転載後にレイアウトが崩れたり、内容が制御不能になったり、継続的に更新できない等の理由から）。
このブログのコンテンツを非営利目的で解釈したい場合は、(読者の便宜のため)「オリジナルソース」または「参照リンク」の形式でこのサイトの関連 Web ページアドレスを提供してください。