Manage Configuration Files with Git and Ansible

In daily work, to maintain and run certain programs, you need to change the behavior logic of the software through configuration files, such as Nginx configuration files, Prometheus configuration files, etc. In some more complex real business scenarios, it may also involve loading different configuration files in multiple computer rooms.

Students who are familiar with configuration management tools may have thought of Ansible, Puppet, etc., and such tools are indeed good at doing such things.

This article mainly introduces how to use Git + Ansible + Gitlab Pipeline to automatically manage configuration files in multiple computer rooms. It is suitable for small companies to maintain uncomplicated business scenarios. It is not recommended for large companies with many screws, mature tool management software, and compliance requirements.

The benefits are obvious. Git has version management functions, Ansible is easy to deploy, it is fun to roll wheels, and Pipeline automatically pushes and saves trouble. All companies have these conditions.

Here, it is assumed that you want to maintain Prometheus monitoring configuration files for multiple computer rooms. Readers can use them by themselves after understanding, which has a certain degree of versatility.

1. Create a Git repository

Create a Gitlab repository to manage Ansible playbook and Prometheus configuration.

Organize the Prometheus configuration files as follows:

 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

The above means that if you want to maintain the Prometheus monitoring files of computer rooms A and B, you can put them in two subdirectories of the Git repository respectively. Later, the Pipeline will be triggered by distinguishing the directory names and running different Ansible branch tasks.

The contents of the files will not be listed one by one, as they are not very meaningful.

2. Write Ansible playbook

I will not introduce Ansible in detail. There are a lot of information on the Internet. If you don’t understand, you can ask AI.

Only write the core logic of distinguishing computer rooms:

 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

Use the variable idc to distinguish different computer rooms and transmit different configurations.

 1
 2- name: Copy 'rules' file
 3ansible.builtin.copy:
 4src: "{{ item }}"
 5dest: "/opt/prometheus/rules/"
 6mode: 0644
 7validate: /opt/prometheus/promtool check rules %s # Frequent validation is a good habit to prevent outrageous submission
 8with_fileglob:
 9- '{{ config_path }}/{{ idc }}/rules/*' # The idc variable is referenced here
10notify: Reload Prometheus

If you don't understand what the above means, it is recommended to read the tutorial article of ansible and find an environment to experiment.

Paid consultation is also available. Follow the public account and leave a message to contact us. Business collaboration is a win-win situation😄.

3. gitlab ci writing

 1➜ cat .gitlab-ci.yml
 2stages:
 3- checkout
 4- deploy
 5
 6checkout_code:
 7stage: checkout
 8tags:
 9- your_ci_runner # your ci runner
10script:
11- |
12if [! -d "/data/your_code_path"]; then
13echo "directory does not exist, git clone"
14git clone git@xxx.git /data/your_code_path
15else
16echo "directory exists, git pull"
17cd /data/your_code_path && git pull
18fi
19only:
20- main
21
22prometheus-deploy-A: # A computer room deployment logic
23stage: deploy
24tags:
25- your_ci_runner
26rules:
27- changes:
28- prometheus/idc_A/**/* # triggered when directory A changes
29before_script:
30- pwd
31- cd /data/ansible
32- source .venv/bin/activate
33script:
34- echo "Deploying Prometheus A"
35- ansible-playbook -i hosts deploy.yml -l a_host_group # Execute a specific ansible playbook
36
37prometheus-deploy-B: # The logic of the B computer room is similar to A, no further explanation
38stage: deploy
39tags:
40- your_ci_runner
41rules:
42- changes:
43- prometheus/idc_B/**/*
44before_script:
45- pwd
46- cd /data/ansible
47- source .venv/bin/activate
48script:
49- echo "Deploying Prometheus B"
50- ansible-playbook -i hosts deploy.yml -l b_host_group

4. Summary

I deleted some private information from the above code (professional ethics are still there, the bottom line is maintained), and did not test it. I mainly introduce the logical thinking. The real environment has been modified and submitted dozens of times, which is smooth and saves a lot of time.

For safety, it is best to add various Lint or Check logic in Ansible to prevent the configuration from collapsing once it is pushed up! In fact, it doesn’t matter if it collapses, after all, it is a configuration managed by Git, and it can be rolled back.

If you can’t roll back, you can copy it to the server. If you really come to this step, you have to reflect and stop to learn some real skills.

Don’t be embarrassed or brag. I haven’t found similar detailed articles on the Internet. People who understand may not be willing to share. I am sacrificing my weekend time to write this broken article, and sometimes I don’t know why.

In short, when you change the configuration of the A and B computer rooms, modify the files directly in the corresponding Git directory. After submitting, the corresponding Ansible deployment operation will be triggered.

All logic is defined by yourself, simple and clear, without any external dependencies. You may encounter errors at the beginning. After gradually repairing and running smoothly, you can definitely feel comfortable and assured