# Ansible: cấu hình cả cụm máy on-prem của khách mà không SSH vào từng máy

> Một dòng inventory thay cho hai mươi dòng liệt kê máy, một playbook chạy lại bao nhiêu lần cũng ra cùng kết quả: khi phải động vào server của khách, FDE cần đúng hai thứ đó.

Bản gốc: https://fdetimes.net/vi/cong-cu/ansible-cau-hinh-may-chu-on-prem-cua-khach/

Thử hình dung tuần đầu ở nhà máy của khách. Phòng server có hai mươi máy chủ Linux, và bạn phải cài cùng một runtime, cùng một file cấu hình, cùng một service lên tất cả. Mở hai mươi cửa sổ SSH thì rất dễ cấu hình sai một máy mà không ai biết.

Ansible sinh ra cho đúng loại việc này. Red Hat mô tả nó là engine tự động hóa IT mã nguồn mở, lo cả provisioning lẫn quản lý cấu hình. Với một FDE làm deployment on-prem, giá trị của nó là bạn chỉ mô tả trạng thái mong muốn một lần rồi áp lên cả cụm máy.

## Vì sao "không cần agent" là điểm quyết định ở site khách?

Tài liệu chính thức gọi Ansible là công cụ agentless, chỉ cài trên một máy duy nhất gọi là control node. Máy được quản lý chỉ cần một tài khoản SSH vào được shell POSIX tương tác. Bạn không phải cài thêm phần mềm Ansible lên từng máy chủ của khách.

Ở môi trường doanh nghiệp, điều này rất có lợi: mỗi phần mềm phải cài thêm lên server của khách là thêm một thứ phải giải thích và xin phép. Trên freeCodeCamp, Idris Olubisi giải thích rằng Ansible đẩy module qua SSH và xóa chúng ngay khi chạy xong, nên không cần agent hay một hạ tầng bảo mật riêng.

Vì thế, câu đầu tiên bạn nên hỏi đội IT của khách rất cụ thể: bạn có được cấp tài khoản SSH vào các máy này không. Nếu playbook cần quyền quản trị như ví dụ bên dưới (dòng `become: true`), hỏi luôn xem tài khoản đó có được nâng quyền hay không.

## Một ví dụ tối thiểu: inventory và playbook

Mọi thứ bắt đầu từ inventory, tức danh sách máy được quản lý mà bạn tạo trên control node. Nhóm host cho phép nhắm nhiều máy cùng lúc hoặc đặt biến cho cả loạt máy, nên chia nhóm theo site khách là cách tự nhiên. Plugin INI và YAML còn hỗ trợ dải host, nên bạn không phải liệt kê từng máy giống hệt nhau.

```ini
[site_a]
srv[01:20].site-a.local
```

Một dòng này thay cho hai mươi dòng. Tiếp theo là playbook, viết bằng YAML, mô tả trạng thái bạn muốn các máy đạt tới. Đoạn dưới đây là ví dụ minh họa, cài một gói lên toàn bộ nhóm `site_a`:

```yaml
- hosts: site_a
become: true
tasks:
- name: Cài Python 3 trên mọi máy của site A
ansible.builtin.package:
name: python3
state: present
```

Lệnh chạy là `ansible-playbook -i inventory.ini site.yml`. Mặc định, Ansible chạy từng tác vụ theo thứ tự, mỗi lần một tác vụ, trên tất cả máy khớp với host pattern. Tác vụ đầu xong trên cả hai mươi máy rồi mới sang tác vụ sau, nên máy nào cho kết quả khác số đông sẽ lộ ra ngay.

## Chạy lại có làm hỏng máy của khách không?

Khi động vào hệ thống production của người khác, đây là nỗi lo thực tế nhất. Tài liệu Ansible nêu nguyên tắc idempotent: chạy playbook một lần hay nhiều lần thì kết quả cũng phải như nhau. Dòng `state: present` ở trên có nghĩa là "gói này phải có mặt", không phải "cài thêm một lần nữa".

Nhờ vậy, nếu mạng chập chờn làm ba máy rớt giữa chừng, bạn chỉ cần chạy lại cả playbook. Máy đã đúng trạng thái thì giữ nguyên, máy còn thiếu thì được bổ sung. Bàn giao theo cách này dễ hơn nhiều so với việc phải nhớ mình đã SSH vào những máy nào.

**Điểm mấu chốt:** Đừng viết playbook theo kiểu "làm bước này". Hãy viết theo kiểu "máy phải ở trạng thái này", rồi chạy lại bao nhiêu lần cũng được.

Red Hat xếp cách làm này vào Infrastructure as Code: playbook mô tả trạng thái mong muốn của hệ thống và thường được lưu trong source control. Với FDE, repo playbook chính là tài liệu bàn giao. Đội IT của khách đọc được, review được và tự chạy lại được sau khi bạn rời site.

## Giới hạn nào cần biết trước khi tới site?

Giới hạn đầu tiên nằm ngay trên laptop của bạn: nếu không có WSL, Windows không được hỗ trợ nguyên bản làm control node. Nếu máy công ty cấp cho bạn chạy Windows, hãy dựng WSL từ trước, đừng để đến ngày đầu ở site khách mới phát hiện.

Giới hạn thứ hai đến từ mạng. Mô hình mặc định là push: control node chủ động SSH vào từng máy. Khi mạng on-prem chặn kết nối từ ngoài vào, `ansible-pull` đảo kiến trúc push thành pull để chính các máy tự kéo cấu hình về. Tài liệu còn cho rằng kiến trúc pull này có khả năng mở rộng gần như vô hạn.

Giới hạn thứ ba là điều kiện tối thiểu ở phía máy được quản lý: phải có tài khoản SSH và shell POSIX. Thiếu một trong hai thì playbook viết kỹ đến đâu cũng không chạy được, nên hãy xác nhận điều này ngay trong cuộc gọi kickoff.

## Học gì trước, và ghi gì vào CV?

Nên học theo thứ tự: inventory, rồi playbook, rồi idempotency, sau đó mới đến các tính năng phức tạp hơn. Ba VM chạy trên máy cá nhân là đủ để luyện cả ba bước. Viết một playbook, chạy hai lần và kiểm tra lần thứ hai không còn thay đổi gì: bài tập nhỏ này cho bạn thấy tận mắt idempotency là gì.

Khi đọc JD FDE, bạn nên tự đối chiếu: nếu mô tả công việc có nhắc đến deployment on-prem hay quản lý cấu hình, kinh nghiệm Ansible là thứ đáng đưa lên đầu. Trong CV, đừng chỉ ghi "biết Ansible".

Hãy viết theo kết quả, ví dụ "viết playbook idempotent cấu hình đồng loạt N máy chủ, lưu trong Git để đội vận hành tự chạy lại", với N là con số thật của bạn.

Ở site khách, người được tin tưởng thường không phải người gõ lệnh nhanh nhất, mà là người để lại một hệ thống người khác chạy lại được. Một repo playbook trong Git mà đội IT của khách tự chạy được chính là thứ để lại như thế.

**Thử ngay tuần này:**

- Dựng 3 VM Linux, viết inventory có một nhóm dùng dải host, rồi từ một máy chạy playbook cài gói lên cả ba.
- Chạy playbook đó hai lần liên tiếp, kiểm tra lần thứ hai không còn thay đổi nào, rồi đưa playbook lên Git.
- Nếu laptop của bạn chạy Windows, cài WSL và dựng control node bên trong nó trước khi phải dùng thật ở site khách.

## Nguồn

- [Ansible Collaborative (Red Hat; ansible.com chuyển hướng về đây)](https://www.redhat.com/en/ansible-collaborative?intcmp=7015Y000003t7aWQAQ)

- [Installing Ansible (Ansible Documentation)](https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html)

- [What is Ansible? A Tool to Automate Parts of Your Job (Idris Olubisi)](https://www.freecodecamp.org/news/what-is-ansible/)

- [Getting started with Ansible (Ansible Documentation)](https://docs.ansible.com/ansible/latest/getting_started/index.html)

- [How to build your inventory (Ansible Documentation)](https://docs.ansible.com/ansible/latest/inventory_guide/intro_inventory.html)

- [Ansible playbooks (Ansible Documentation)](https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_intro.html)

- [ansible-pull (Ansible Documentation)](https://docs.ansible.com/ansible/latest/cli/ansible-pull.html)

- [What is Infrastructure as Code (IaC)?](https://www.redhat.com/en/topics/automation/what-is-infrastructure-as-code-iac)