Tự Động Quản Lý Nhiều VPS Bằng Ansible: Từ Inventory Đến Playbook

Khi chỉ có một VPS, đăng nhập SSH rồi chạy từng lệnh thủ công vẫn khá đơn giản. Nhưng khi số máy tăng lên 5, 10 hoặc 50, việc cập nhật package, tạo user, cấu hình service hay triển khai file giống nhau dễ dẫn tới sai lệch giữa các máy.

Ansible giải quyết bài toán này theo hướng agentless: máy điều khiển kết nối tới VPS chủ yếu qua SSH, đọc inventory để biết danh sách host và chạy playbook mô tả trạng thái mong muốn.

Bài viết tập trung vào một quy trình an toàn cho người mới: cài Ansible, dùng SSH key, tạo inventory, kiểm tra kết nối, chạy ad-hoc command, viết playbook đầu tiên và hạn chế rủi ro khi thao tác hàng loạt.

Khi nào nên dùng Ansible cho VPS?

Ansible phù hợp khi bạn thường xuyên lặp lại các tác vụ như:

• cập nhật package trên nhiều máy;
• tạo user quản trị giống nhau;
• triển khai SSH public key;
• cài Nginx, Docker hoặc agent monitoring;
• đồng bộ file cấu hình;
• restart service có kiểm soát;
• chuẩn hóa môi trường dev, staging và production.

Nếu bạn mới quản trị Linux, hãy nắm trước các lệnh cơ bản trong bài Các lệnh Linux cơ bản cho người mới dùng VPS Ubuntu. Ansible giúp tự động hóa, nhưng bạn vẫn cần hiểu tác động của từng task.

Mô hình Ansible cơ bản

Một hệ thống đơn giản gồm:

• Control node: máy cài Ansible, thường là laptop Linux/macOS hoặc một VPS quản trị;
• Managed nodes: các VPS được Ansible kết nối tới;
• Inventory: danh sách host và group;
• Playbook: file YAML mô tả task cần thực thi.

Ansible thường kết nối bằng SSH. Tài liệu chính thức khuyến khích sử dụng SSH key thay vì password trong quy trình tự động hóa.

Nếu hạ tầng của bạn đang dùng SSH key, có thể tham khảo thêm bài Dùng SSH key cho VPS Ubuntu và tắt password.

Chuẩn bị SSH key

Trên control node, kiểm tra xem đã có key chưa:

ls -la ~/.ssh

Nếu chưa có, có thể tạo Ed25519 key:

ssh-keygen -t ed25519 -C "ansible-control"

Sau đó copy public key lên VPS:

ssh-copy-id admin@IP_VPS

Kiểm tra đăng nhập không cần password:

ssh admin@IP_VPS

Chỉ chuyển sang Ansible khi SSH trực tiếp đã hoạt động ổn định.

Cài Ansible trên control node

Trên Ubuntu/Debian, bạn có thể cài theo package manager hoặc theo hướng dẫn chính thức. Một cách phổ biến là dùng Python package trong môi trường riêng.

Ví dụ với pipx:

sudo apt update
sudo apt install -y pipx
pipx ensurepath
pipx install --include-deps ansible

Mở terminal mới rồi kiểm tra:

ansible --version

Nếu dùng môi trường production, nên cố định phiên bản Ansible và collection thay vì tự động lấy bản mới nhất không kiểm soát.

Tạo project Ansible đầu tiên

Tạo thư mục riêng:

mkdir -p ~/ansible-vps
cd ~/ansible-vps

Tạo file inventory.ini:

[web]
web01 ansible_host=203.0.113.10
web02 ansible_host=203.0.113.11

[db]
db01 ansible_host=203.0.113.20

[all:vars]
ansible_user=admin

Các IP trên chỉ là ví dụ. Hãy thay bằng IP hoặc hostname thật của bạn.

Inventory giúp nhóm host theo chức năng. Khi số lượng máy tăng, có thể chia theo:

• ứng dụng: web, db, monitoring;
• môi trường: dev, staging, prod;
• khu vực hoặc datacenter.

Kiểm tra inventory

Ansible có lệnh để hiển thị cấu trúc inventory:

ansible-inventory -i inventory.ini --list

Nếu YAML/INI sai cú pháp hoặc group không đúng, nên phát hiện ở bước này trước khi chạy task thật.

Kiểm tra kết nối bằng module ping

Chạy:

ansible all -i inventory.ini -m ping

Nếu thành công, kết quả sẽ có SUCCESS hoặc pong cho từng host.

Nếu lỗi, kiểm tra SSH trước:

ssh admin@203.0.113.10

Các lỗi phổ biến gồm:

• sai user SSH;
• key chưa được cài;
• firewall chặn port;
• host key chưa được xác nhận;
• Python trên managed node không phù hợp.

Đừng bỏ qua lỗi SSH bằng cách tắt host key checking một cách tùy tiện trên production. Nên xác minh fingerprint host đúng trước.

Chạy ad-hoc command

Ad-hoc command phù hợp với thao tác nhanh, không cần lưu thành playbook.

Ví dụ kiểm tra uptime:

ansible all -i inventory.ini -m command -a "uptime"

Kiểm tra disk:

ansible all -i inventory.ini -m command -a "df -h"

Không nên dùng shell nếu command đã đáp ứng được, vì shell có thêm lớp parsing và dễ tạo rủi ro injection khi biến đầu vào không được kiểm soát.

Playbook đầu tiên: cập nhật package cache

Tạo file update-cache.yml:

---
- name: Update apt cache on Ubuntu servers
  hosts: all
  become: true
  tasks:
    - name: Refresh apt cache
      ansible.builtin.apt:
        update_cache: true
        cache_valid_time: 3600

Chạy:

ansible-playbook -i inventory.ini update-cache.yml --ask-become-pass

Nếu tài khoản sudo cần password, tùy chọn --ask-become-pass sẽ hỏi password tại terminal thay vì lưu thẳng vào file.

Không nên ghi sudo password dạng plaintext trong inventory.

Vì sao nên dùng module thay vì chạy lệnh thủ công?

Playbook có thể viết như sau:

- name: Install Nginx
  ansible.builtin.apt:
    name: nginx
    state: present
    update_cache: true

Thay vì:

- name: Install Nginx with shell
  ansible.builtin.shell: apt update && apt install -y nginx

Module apt hiểu trạng thái package. Nếu Nginx đã cài đúng, Ansible thường không cần thực hiện lại. Đây là ý tưởng idempotency: chạy playbook nhiều lần nhưng hệ thống vẫn hội tụ về trạng thái mong muốn.

Tạo user quản trị bằng Ansible

Ví dụ:

---
- name: Create admin user
  hosts: all
  become: true
  tasks:
    - name: Ensure ops user exists
      ansible.builtin.user:
        name: ops
        shell: /bin/bash
        groups: sudo
        append: true
        state: present

Không nên tự động tạo password yếu hoặc nhúng password trực tiếp vào Git repository.

Nếu cần quản lý secret, dùng Ansible Vault hoặc secret manager phù hợp.

Triển khai SSH public key

Ví dụ:

- name: Add SSH key for ops user
  ansible.posix.authorized_key:
    user: ops
    state: present
    key: "{{ lookup('file', '~/.ssh/id_ed25519.pub') }}"

Trước khi vô hiệu hóa password login trên nhiều máy, hãy test user mới và SSH key trên một nhóm nhỏ trước.

Một cấu hình sai hàng loạt có thể khiến bạn tự khóa khỏi toàn bộ VPS.

Chạy playbook theo nhóm thay vì toàn bộ server

Chỉ chạy web server:

ansible-playbook -i inventory.ini update-cache.yml --limit web

Chỉ chạy một host:

ansible-playbook -i inventory.ini update-cache.yml --limit web01

Cách an toàn hơn trong production:

1. chạy trên một máy canary;
2. kiểm tra kết quả;
3. chạy trên một group nhỏ;
4. sau đó mới mở rộng toàn bộ fleet.

Dùng check mode trước khi áp dụng

Một số module hỗ trợ check mode:

ansible-playbook -i inventory.ini update-cache.yml --check

Check mode mô phỏng thay đổi nhưng không phải lúc nào cũng phản ánh 100% tác động thực tế. Không xem đây là bản sao hoàn hảo của production run.

Có thể xem thay đổi file rõ hơn với:

ansible-playbook -i inventory.ini playbook.yml --check --diff

Đừng dùng --diff với task có secret nếu output có nguy cơ lộ thông tin nhạy cảm.

Quản lý biến theo group

Cấu trúc project dễ mở rộng:

ansible-vps/
├── inventory.ini
├── group_vars/
│   ├── all.yml
│   ├── web.yml
│   └── db.yml
├── playbooks/
│   ├── baseline.yml
│   └── update.yml
└── roles/

Ví dụ group_vars/web.yml:

nginx_worker_connections: 2048

Khi project lớn hơn, roles giúp chia task, handler, template và variable theo chức năng.

Không lưu secret plaintext

Tránh:

mysql_password: super-secret-password

Nếu repository bị lộ, secret cũng bị lộ.

Ansible Vault có thể mã hóa file hoặc biến nhạy cảm. Ví dụ tạo file Vault:

ansible-vault create group_vars/prod/vault.yml

Khi chạy playbook:

ansible-playbook -i inventory.ini playbook.yml --ask-vault-pass

Với môi trường lớn, có thể tích hợp Vault/secret manager chuyên dụng.

Tránh restart service không cần thiết

Ansible hỗ trợ handlers. Handler chỉ chạy khi task liên quan báo changed.

Ví dụ:

- name: Deploy Nginx config
  ansible.builtin.template:
    src: nginx.conf.j2
    dest: /etc/nginx/nginx.conf
    mode: '0644'
  notify: Reload Nginx

handlers:
  - name: Reload Nginx
    ansible.builtin.service:
      name: nginx
      state: reloaded

Reload thường ít gián đoạn hơn restart nếu ứng dụng hỗ trợ, nhưng bạn vẫn cần validate config trước.

Với Nginx, có thể kiểm tra:

sudo nginx -t

Nếu bạn đang triển khai reverse proxy, bài Cài Nginx reverse proxy trên VPS Ubuntu sẽ hữu ích để hiểu cấu trúc cấu hình trước khi tự động hóa.

Quy trình production nên có

Một pipeline Ansible an toàn thường gồm:

• lưu playbook trong Git;
• review thay đổi;
• lint YAML/playbook;
• chạy test trên staging;
• chạy --check khi phù hợp;
• triển khai canary;
• theo dõi metric/log;
• mở rộng rollout;
• có phương án rollback.

Ansible giúp thao tác nhanh hơn, nhưng điều đó cũng có nghĩa lỗi có thể lan rộng nhanh hơn nếu playbook sai.

Sai lầm thường gặp

Chạy thẳng hosts: all trên production

Nếu task nguy hiểm, lỗi sẽ áp dụng lên mọi máy. Dùng --limit và rollout theo nhóm.

Nhúng private key vào repository

Private key không nên nằm trong Git. Dùng SSH agent hoặc secret storage phù hợp.

Dùng shell cho mọi task

Ưu tiên module chuyên dụng như apt, service, file, copy, template, user và authorized_key.

Không kiểm tra backup

Automation không thay thế backup. Trước migration hoặc thay đổi lớn, vẫn cần backup và kiểm tra restore.

Không phân biệt dev/staging/prod

Một inventory phẳng dễ khiến thao tác nhầm môi trường. Hãy group rõ ràng và dùng naming nhất quán.

Ví dụ playbook baseline đơn giản

---
- name: Baseline Ubuntu VPS
  hosts: all
  become: true

  tasks:
    - name: Update apt cache
      ansible.builtin.apt:
        update_cache: true
        cache_valid_time: 3600

    - name: Install useful packages
      ansible.builtin.apt:
        name:
          - curl
          - vim
          - htop
        state: present

    - name: Ensure time synchronization service is running
      ansible.builtin.service:
        name: systemd-timesyncd
        state: started
        enabled: true

Không nên copy nguyên playbook này lên mọi distro. Tên package và service có thể khác.

FAQ

Ansible có cần cài agent trên từng VPS không?

Trong mô hình Linux phổ biến, không. Ansible kết nối từ control node qua SSH và sử dụng các công cụ có sẵn trên managed node.

Ansible có quản lý được hàng trăm VPS không?

Có, inventory và group giúp tổ chức số lượng host lớn. Tuy nhiên cần thiết kế concurrency, rollout, logging và kiểm soát lỗi phù hợp.

Có nên dùng root trực tiếp trong inventory?

Không nên nếu không cần. Thường nên dùng user quản trị riêng có SSH key và nâng quyền bằng become/sudo.

Ansible có thay Terraform không?

Không hoàn toàn. Terraform thường tập trung provisioning hạ tầng, còn Ansible mạnh ở configuration management và orchestration sau khi máy đã tồn tại. Hai công cụ có thể bổ trợ nhau.

Playbook chạy lại nhiều lần có an toàn không?

Nếu dùng module idempotent và task được thiết kế đúng, thường có. Nhưng shell, script tùy biến hoặc thao tác dữ liệu vẫn có thể không idempotent, nên cần kiểm tra riêng.

Kết luận

Ansible bắt đầu phát huy giá trị ngay khi bạn có nhiều VPS hoặc phải lặp lại cùng một cấu hình. Hãy khởi đầu nhỏ: SSH key, inventory rõ ràng, module ping, một playbook đơn giản và rollout theo từng nhóm.

Khi quy trình đã ổn định, bạn có thể mở rộng sang roles, template, Vault, CI/CD và baseline bảo mật cho toàn bộ hạ tầng.

Nếu bạn cần thêm VPS để tách môi trường dev, staging hoặc production, có thể tham khảo các dịch vụ VPS trên HUONG CLOUD và lựa chọn tài nguyên theo workload thực tế.

Nguồn tham khảo

• Ansible Community Documentation — Start automating with Ansible: https://docs.ansible.com/projects/ansible/latest/getting_started/get_started_ansible.html
• Ansible Community Documentation — Build your inventory: https://docs.ansible.com/projects/ansible/latest/network/getting_started/first_inventory.html
• Ansible Community Documentation — Connection methods and SSH keys: https://docs.ansible.com/projects/ansible/latest/inventory_guide/connection_details.html