Tự động hoá công việc DevOps với Ansible

Anh em làm devops chắc cũng không lạ gì các công việc lặp đi lặp lại hàng ngày: triển khai một update bản vá mới, dựng thêm server cho team dev, hay rà soát lại cấu hình bảo mật trên cả trăm server. Mấy việc này làm thủ công vừa tốn thời gian, vừa có rủi ro sai sót.

Thì hôm nay, mình muốn nói về một công cụ đã giúp mình và team tiết kiệm rất nhiều công sức: Ansible.

Nhiều anh em biết tới Docker hay Kubernetes, nhưng Ansible lại giải quyết một bài toán khác. Nó là công cụ tự động hóa, giúp kết nối và quản lý mọi thứ, từ việc cấp phát server cho đến khi triển khai code của anh em lên đó. Điểm mạnh của nó là:

Dựng server mới rất nhanh.
Đảm bảo việc triển khai ứng dụng nhất quán trên các môi trường.
Dễ tiếp cận hơn so với các công cụ như Chef/Puppet.
Không cần cài đặt agent, chỉ cần kết nối SSH là đủ.

Để anh em dễ hình dung, mình sẽ đi vào 5 ví dụ thực tế mà gần như team nào cũng cần giải quyết.

5 kịch bản thực tế mà Ansible giải quyết ngon ơ

1. Triển khai ứng dụng không downtime

Vấn đề: Một trong những rủi ro khi deploy là gây downtime. Việc cập nhật code mới một cách thủ công trên nhiều server cùng lúc rất dễ làm sập ứng dụng, ảnh hưởng trực tiếp đến người dùng.

Cách Ansible xử lý: Nó dùng cơ chế rolling update. Tức là cập nhật dần dần từng nhóm server. Ví dụ, serial: "30%" trong playbook có nghĩa là Ansible sẽ chỉ thực thi trên 30% số server trong danh sách. Khi nhóm này xong và ổn định, nó mới chuyển sang nhóm tiếp theo.

# playbook.yml
- name: Deploy app với rolling updates
  hosts: webservers
  serial: "30%" # Cập nhật mỗi lần 30% tổng số server
  tasks:
    - name: Kéo code mới nhất
      git:
        repo: https://github.com/devopsvietnam/app.git
        dest: /opt/app
        version: "{{ app_version }}"

    - name: Cài đặt các thư viện phụ thuộc
      pip:
        requirements: /opt/app/requirements.txt

    - name: Khởi động lại service
      systemd:
        name: myapp
        state: restarted
      notify: verify_health_check # Sau khi restart thì gọi handler để check health

2. Infrastructure as Code

Vấn đề: Môi trường staging và production không đồng nhất là nguyên nhân của rất nhiều lỗi. Server staging thì chạy ổn, nhưng lên production lại gặp vấn đề do thiếu một gói thư viện nào đó, hoặc cấu hình sai một tham số. Cái server kiểu này, mỗi con một phách, hay còn gọi là “snowflake server”.

Cách Ansible xử lý: Nó giúp anh em định nghĩa hạ tầng dưới dạng code. Mọi server được tạo ra từ một playbook sẽ có cấu hình y hệt nhau, từ các gói package, rule firewall cho tới các tác vụ định kỳ.

# provision_server.yml
- name: Cấp phát server mới cho production
  hosts: new_servers
  become: yes # Chạy với quyền root
  tasks:
    - name: Cài đặt các package cần thiết
      package:
        name: "{{ item }}"
        state: present
      loop:
        - nginx
        - docker
        - monitoring-agent
        - security-tools

    - name: Mở các port cần thiết trên firewall
      ufw:
        rule: allow
        port: "{{ item }}"
      loop: [22, 80, 443]

    - name: Thiết lập cronjob để backup hàng ngày
      cron:
        name: "daily backup"
        hour: "2"
        job: "/scripts/backup.sh"

3. Quản lý cấu hình cho nhiều môi trường

Vấn đề: Cấu hình ứng dụng thường thay đổi giữa các môi trường (dev, staging, prod). Ví dụ như chuỗi kết nối database. Việc quản lý thủ công các file config này rất dễ nhầm lẫn, có thể gây ra lỗi nghiêm trọng, ví dụ như app production ghi nhầm dữ liệu vào database dev.

Cách Ansible xử lý: Nó cho phép tách riêng các biến cấu hình cho từng môi trường vào thư mục group_vars. Khi chạy, Ansible sẽ dùng file mẫu .j2 và tự động điền các giá trị tương ứng với môi trường đang triển khai.

# file: group_vars/production.yml
database_host: prod-db.company.com
api_timeout: 30
debug_mode: false

# file: group_vars/development.yml
database_host: dev-db.company.com
api_timeout: 5
debug_mode: true

# file: playbook.yml
- name: Áp dụng cấu hình cho ứng dụng
  template:
    src: app.conf.j2
    dest: /etc/app/config.yml
  vars:
    db_host: "{{ database_host }}"
    timeout: "{{ api_timeout }}"
    debug: "{{ debug_mode }}"

4. Áp dụng chính sách bảo mật hàng loạt (Security Hardening)

Vấn đề: Khi quản lý hàng chục, hàng trăm server, việc đảm bảo tất cả chúng đều tuân thủ chính sách bảo mật chung là một thách thức. SSH vào từng máy để tắt quyền đăng nhập của root hay cài đặt bản vá là việc không thể khả thi và rất dễ bỏ sót.

Cách Ansible xử lý: Chỉ với một playbook, anh em có thể áp dụng một loạt các quy tắc bảo mật cho toàn bộ hạ tầng của mình một cách đồng bộ.

- name: Tăng cường bảo mật cho infra
  hosts: all
  tasks:
    - name: Không cho phép user root đăng nhập qua SSH
      lineinfile:
        path: /etc/ssh/sshd_config
        line: "PermitRootLogin no"
        state: present

    - name: Lên lịch cập nhật bảo mật hàng tuần
      cron:
        name: "security updates"
        special_time: weekly
        job: "apt update &amp;&amp; apt upgrade -y"

    - name: Cấu hình fail2ban
      copy:
        src: jail.local
        dest: /etc/fail2ban/jail.local
      notify: restart fail2ban

5. Triển khai Monitoring & Alert

Vấn đề: Việc cài đặt và cấu hình các (monitoring agent trên từng server là một công việc thủ công, tốn nhiều thời gian, đặc biệt là khi hệ thống có quy mô lớn.

Cách Ansible xử lý: Nó tự động hóa hoàn toàn quá trình này, từ việc tải và cài đặt agent (ví dụ Prometheus node exporter) cho đến việc đẩy file cấu hình và các rule cảnh báo.

- name: Triển khai hệ thống giám sát
  hosts: all
  tasks:
    - name: Cài đặt Prometheus node exporter
      get_url:
        url: https://github.com/prometheus/node_exporter/releases/download/v1.3.1/node_exporter-1.3.1.linux-amd64.tar.gz
        dest: /tmp/

    - name: Áp dụng file cấu hình monitoring
      template:
        src: monitoring.yml.j2
        dest: /etc/monitoring/config.yml

    - name: Thiết lập rule cảnh báo CPU cao
      copy:
        content: |
          - alert: HighCPU
            expr: cpu_usage &gt; 80
            for: 5m
            annotations:
              summary: "CPU cao trên {{ $labels.instance }}"
        dest: /etc/alerts/rules.yml

Vài kinh nghiệm cá nhân khi dùng Ansible

Đây là vài điểm mình đúc kết được, anh em tham khảo để sử dụng hiệu quả hơn:

Không hardcode password hay API key. Việc này tiềm ẩn rủi ro bảo mật. Thay vào đó, hãy dùng Ansible Vault để mã hóa chúng một cách an toàn.
Nên kiểm tra kỹ trước khi áp dụng lên production. Anh em nên chạy với mode --check (dry run) để xem trước các thay đổi, tránh gây ra lỗi không lường trước.
Nên chia nhỏ playbook thành các roles thay vì viết tất cả trong một file. Cách này ban đầu có thể tốn thêm chút thời gian, nhưng về lâu dài sẽ giúp code dễ bảo trì và tái sử dụng hơn rất nhiều.

Kết luận

Tóm lại, Ansible không phải là công cụ giải quyết mọi vấn đề, nhưng nó cực kỳ hiệu quả trong việc tự động hóa các tác vụ quản trị hệ thống lặp đi lặp lại. Việc áp dụng nó giúp anh em:

Triển khai nhanh hơn.
Giảm thiểu lỗi do con người.
Quản lý hạ tầng quy mô lớn dễ dàng hơn.
Tăng tính ổn định và nhất quán cho hệ thống.

Nếu anh em mới bắt đầu, mình gợi ý hãy chọn một tác vụ thủ công tốn thời gian nhất để tự động hóa trước. Cứ cải tiến dần dần, rồi anh em sẽ thấy hiệu quả rõ rệt mà nó mang lại.