Mục tiêu: Hiểu Ad-Hoc Command là gì, cách Ansible thực thi module trực tiếp trên Managed Node, biết sử dụng các module phổ biến để quản trị server, hiểu khi nào nên dùng Ad-Hoc Command và khi nào phải chuyển sang Playbook.

---

1. Bối cảnh thực tế

Ở Lab 1, chúng ta đã biết Ansible có thể quản lý server.

Ở Lab 2, chúng ta đã biết cách:

• Khai báo server trong Inventory.
• Nhóm server.
• Kết nối server qua SSH.
• Kiểm tra connectivity bằng ansible.builtin.ping.

Nhưng hãy tưởng tượng bạn đang trực vận hành production.

Một đồng nghiệp báo:

"Server web-02 đang có vấn đề. Kiểm tra giúp tôi CPU, RAM và disk."

Bạn không nhất thiết phải viết một Playbook mới chỉ để chạy:

uptime
free -h
df -h

Trong trường hợp này, Ad-Hoc Command rất phù hợp.

Thay vì:

SSH
  │
  ├── web-01
  ├── web-02
  └── web-03

chúng ta có thể:

                Ansible
                   │
                   ▼
             Ad-Hoc Command
                   │
          ┌────────┼────────┐
          ▼        ▼        ▼
       web-01   web-02   web-03

Một command có thể thực hiện trên một hoặc nhiều server.

---

2. Ad-Hoc Command là gì?

Ad-Hoc Command là cách sử dụng Ansible để thực hiện một tác vụ trực tiếp từ command line mà không cần tạo Playbook.

Cú pháp cơ bản:

ansible <pattern> -m <module> -a "<arguments>"

Ví dụ:

ansible webservers \
  -m ansible.builtin.command \
  -a "hostname"

Có thể hiểu:

ansible
   │
   ├── webservers
   │      └── Target
   │
   ├── -m
   │      └── Module
   │
   └── -a
          └── Module arguments

---

3. Ad-Hoc Command khác Playbook như thế nào?

Đây là concept rất quan trọng.

Ad-Hoc

ansible webservers -m ansible.builtin.command -a "uptime"

Phù hợp cho:

• Kiểm tra nhanh.
• Troubleshooting.
• Thực hiện một tác vụ đơn giản.
• Investigation.
• Operations khẩn cấp.
• Thử nghiệm module.

Playbook

- name: Configure web servers
  hosts: webservers
  tasks:
    - ...

Phù hợp cho:

• Automation.
• Deployment.
• Configuration Management.
• Các quy trình nhiều bước.
• Công việc cần repeat.
• Infrastructure as Code.

Có thể nhớ:

Ad-Hoc
   ↓
Quick Operation

Playbook
   ↓
Reusable Automation

---

4. Một nguyên tắc thực tế

Nếu bạn chỉ cần:

"Kiểm tra hostname của server."

Ad-Hoc rất phù hợp.

Nếu bạn cần:

"Cài Nginx, tạo user, copy configuration, enable service, start service và kiểm tra health."

Hãy viết Playbook.

Một cách suy nghĩ đơn giản:

One-time / Investigation
        ↓
     Ad-Hoc

Repeatable / Automation
        ↓
     Playbook

---

5. Chuẩn bị môi trường

Tiếp tục project từ Lab 2:

ansible-lab-02/
├── ansible.cfg
└── inventory.ini

Inventory ví dụ:

[webservers]
web-01 ansible_host=192.168.56.101
web-02 ansible_host=192.168.56.102

[appservers]
app-01 ansible_host=192.168.56.103

[dbservers]
db-01 ansible_host=192.168.56.104

[production:children]
webservers
appservers
dbservers

Nếu đã có ansible.cfg:

[defaults]
inventory = ./inventory.ini

thì không cần thêm:

-i inventory.ini

vào mỗi command.

---

6. Kiểm tra kết nối

Trước tiên:

ansible all -m ansible.builtin.ping

Kết quả mong muốn:

web-01 | SUCCESS
web-02 | SUCCESS
app-01 | SUCCESS
db-01  | SUCCESS

Nếu bước này fail, hãy xử lý SSH trước.

Không nên tiếp tục chạy các Ad-Hoc Command khác khi connectivity chưa hoạt động.

---

7. Ad-Hoc Command đầu tiên

Kiểm tra hostname:

ansible all \
  -m ansible.builtin.command \
  -a "hostname"

Kết quả:

web-01 | CHANGED | rc=0 >>
web-01

web-02 | CHANGED | rc=0 >>
web-02

app-01 | CHANGED | rc=0 >>
app-01

db-01 | CHANGED | rc=0 >>
db-01

Bạn vừa thực hiện cùng một command trên nhiều server.

---

8. Hiểu -m

-m là viết tắt của:

module

Ví dụ:

-m ansible.builtin.command

cho Ansible biết:

Hãy sử dụng command module.

Một số module chúng ta sẽ sử dụng:

ansible.builtin.command
ansible.builtin.shell
ansible.builtin.package
ansible.builtin.apt
ansible.builtin.service
ansible.builtin.systemd
ansible.builtin.user
ansible.builtin.file
ansible.builtin.copy
ansible.builtin.setup

---

9. Hiểu -a

-a là:

module arguments

Ví dụ:

ansible all \
  -m ansible.builtin.command \
  -a "hostname"

Trong đó:

module:
ansible.builtin.command

argument:
hostname

Ví dụ khác:

ansible webservers \
  -m ansible.builtin.command \
  -a "uptime"

---

10. Module command

command dùng để thực thi command trên Managed Node.

Ví dụ:

ansible all \
  -m ansible.builtin.command \
  -a "uptime"

Kiểm tra kernel:

ansible all \
  -m ansible.builtin.command \
  -a "uname -a"

Kiểm tra hostname:

ansible all \
  -m ansible.builtin.command \
  -a "hostname"

Kiểm tra memory:

ansible all \
  -m ansible.builtin.command \
  -a "free -h"

Kiểm tra disk:

ansible all \
  -m ansible.builtin.command \
  -a "df -h"

---

11. command không phải shell

Đây là một điểm rất quan trọng.

Ví dụ:

ansible all \
  -m ansible.builtin.command \
  -a "echo hello"

hoạt động.

Nhưng các shell feature như:

echo hello | grep hello

không nên được dùng với command.

Ví dụ:

ansible all \
  -m ansible.builtin.command \
  -a "cat /etc/os-release | grep VERSION"

có thể không hoạt động như bạn mong muốn vì command không chạy thông qua shell.

Nếu thực sự cần shell features, có thể dùng:

ansible.builtin.shell

Nhưng không nên mặc định sử dụng shell.

---

12. Module shell

Ví dụ:

ansible all \
  -m ansible.builtin.shell \
  -a "cat /etc/os-release | grep VERSION"

Ở đây:

|

được shell xử lý.

Có thể dùng:

ansible all \
  -m ansible.builtin.shell \
  -a "ps aux | grep nginx"

Tuy nhiên:

Nếu có module Ansible phù hợp, hãy ưu tiên module đó thay vì shell.

Ví dụ không nên:

ansible all \
  -m ansible.builtin.shell \
  -a "systemctl restart nginx"

Nếu mục tiêu là quản lý service, nên dùng:

ansible.builtin.service

---

13. Command vs Shell

	command	shell
Chạy command	✅	✅
Shell pipe \|	❌	✅
Redirect >	❌	✅
&&	❌	✅
Shell variable	Hạn chế	✅
Security	An toàn hơn	Cần cẩn thận
Nên ưu tiên	✅	Khi thực sự cần

Nguyên tắc:

Có module phù hợp?
       │
       ├── Có → Dùng module
       │
       └── Không
             │
             ▼
        command?
             │
             ▼
        shell nếu cần

---

14. Kiểm tra CPU

Một số cách nhanh:

ansible all \
  -m ansible.builtin.command \
  -a "nproc"

Hoặc:

ansible all \
  -m ansible.builtin.command \
  -a "uptime"

Trong production, các command kiểu này rất hữu ích khi investigation.

Ví dụ:

web-01 | SUCCESS
  load average: 0.15

web-02 | SUCCESS
  load average: 8.92

Bạn có thể phát hiện web-02 đang có load bất thường.

---

15. Kiểm tra Memory

ansible all \
  -m ansible.builtin.command \
  -a "free -h"

Ví dụ:

web-01
Mem:  7.7Gi  2.1Gi  ...

web-02
Mem:  7.7Gi  7.5Gi  ...

Đây có thể là dấu hiệu cần investigation thêm.

---

16. Kiểm tra Disk

ansible all \
  -m ansible.builtin.command \
  -a "df -h"

Nếu production server gần đầy:

Filesystem      Size  Used Avail Use%
/dev/root        50G   48G    2G  96%

Ad-Hoc Command có thể giúp kiểm tra nhanh nhiều server.

---

17. Module setup

Một module cực kỳ quan trọng:

ansible.builtin.setup

Module này thu thập thông tin về Managed Node.

Chạy:

ansible web-01 \
  -m ansible.builtin.setup

Output sẽ khá dài.

Nó có thể chứa:

OS
Architecture
CPU
Memory
Network
Hostname
IP
Kernel
Python
Filesystem

Các thông tin này được gọi là:

Facts

Facts sẽ được học sâu hơn trong Lab 5 — Variables & Facts.

---

18. Lọc Facts

Không nhất thiết phải xem toàn bộ output.

Ví dụ:

ansible web-01 \
  -m ansible.builtin.setup \
  -a "filter=ansible_distribution"

Hoặc:

ansible web-01 \
  -m ansible.builtin.setup \
  -a "filter=ansible_hostname"

Kiểm tra architecture:

ansible web-01 \
  -m ansible.builtin.setup \
  -a "filter=ansible_architecture"

---

19. Module package

package là abstraction module cho package manager.

Ví dụ:

ansible webservers \
  -b \
  -m ansible.builtin.package \
  -a "name=nginx state=present"

Trong đó:

-b

là:

--become

tức là sử dụng privilege escalation.

---

20. Module apt

Nếu Managed Node là Ubuntu/Debian:

ansible webservers \
  -b \
  -m ansible.builtin.apt \
  -a "name=nginx state=present"

Sau đó kiểm tra:

ansible webservers \
  -m ansible.builtin.command \
  -a "nginx -v"

---

21. state=present nghĩa là gì?

Đây là concept rất quan trọng.

state=present

không có nghĩa:

"Install package mỗi lần."

Nó có nghĩa:

"Package phải tồn tại."

Nếu package chưa tồn tại:

Install

Nếu đã tồn tại:

No change

Đây chính là Idempotency mà chúng ta đã giới thiệu ở Lab 1.

---

22. Module service

Quản lý service:

ansible webservers \
  -b \
  -m ansible.builtin.service \
  -a "name=nginx state=started"

Có thể:

started
stopped
restarted
reloaded

Ví dụ stop:

ansible webservers \
  -b \
  -m ansible.builtin.service \
  -a "name=nginx state=stopped"

Start lại:

ansible webservers \
  -b \
  -m ansible.builtin.service \
  -a "name=nginx state=started"

---

23. Enable Service

Có thể kết hợp:

ansible webservers \
  -b \
  -m ansible.builtin.service \
  -a "name=nginx state=started enabled=true"

Ý nghĩa:

state=started
    ↓
Nginx đang chạy

enabled=true
    ↓
Nginx tự động start khi boot

---

24. Module user

Tạo user:

ansible webservers \
  -b \
  -m ansible.builtin.user \
  -a "name=deploy state=present"

Kiểm tra:

ansible webservers \
  -m ansible.builtin.command \
  -a "id deploy"

Kết quả:

uid=1001(deploy) gid=1001(deploy)

Xóa:

ansible webservers \
  -b \
  -m ansible.builtin.user \
  -a "name=deploy state=absent"

---

25. Module file

Tạo directory:

ansible webservers \
  -b \
  -m ansible.builtin.file \
  -a "path=/opt/myapp state=directory"

Kiểm tra:

ansible webservers \
  -m ansible.builtin.command \
  -a "ls -ld /opt/myapp"

---

26. Module copy

Tạo một file từ Control Node:

echo "Hello from Ansible" > hello.txt

Sau đó:

ansible webservers \
  -b \
  -m ansible.builtin.copy \
  -a "src=hello.txt dest=/tmp/hello.txt"

Kiểm tra:

ansible webservers \
  -m ansible.builtin.command \
  -a "cat /tmp/hello.txt"

Flow:

Control Node
     │
     │ copy
     ▼
Managed Node
     │
     ▼
/tmp/hello.txt

---

27. Ad-Hoc và Idempotency

Hãy chạy:

ansible webservers \
  -b \
  -m ansible.builtin.file \
  -a "path=/opt/myapp state=directory"

Lần đầu:

changed=1

Chạy lần hai:

changed=0

Điều này cho thấy module biết cách kiểm tra trạng thái hiện tại.

Đây là một lý do quan trọng tại sao:

Ansible Module

tốt hơn:

Raw shell command

trong nhiều trường hợp.

---

28. Module command và Idempotency

Hãy thử:

ansible webservers \
  -m ansible.builtin.command \
  -a "mkdir -p /tmp/test"

Bạn có thể thấy behavior khác với các module quản lý resource.

Đây là một bài học quan trọng:

Không phải mọi command đều có cùng mức độ idempotency.

Ví dụ:

systemctl restart nginx

mỗi lần chạy đều thực hiện restart.

Trong khi:

state: started

mô tả trạng thái mong muốn.

Đây là lý do trong automation production, chúng ta nên ưu tiên declarative modules.

---

29. Privilege Escalation

Một số task cần root:

Install package
Create system user
Modify /etc
Manage service
Change ownership

Sử dụng:

-b

Ví dụ:

ansible webservers \
  -b \
  -m ansible.builtin.apt \
  -a "name=nginx state=present"

Nếu cần sudo password:

ansible webservers \
  -b -K \
  -m ansible.builtin.apt \
  -a "name=nginx state=present"

Trong đó:

-b = become
-K = ask become password

---

30. Chạy trên một server cụ thể

ansible web-01 \
  -m ansible.builtin.command \
  -a "uptime"

Điều này rất hữu ích khi troubleshooting.

Ví dụ:

web-01
web-02
web-03

nhưng chỉ web-02 có vấn đề.

Không cần chạy:

all servers

mà chỉ:

ansible web-02 \
  -m ansible.builtin.command \
  -a "uptime"

---

31. Chạy trên nhiều group

Ví dụ:

ansible 'webservers:appservers' \
  -m ansible.builtin.command \
  -a "uptime"

Có thể loại trừ database:

ansible 'production:!dbservers' \
  -m ansible.builtin.command \
  -a "uptime"

Đây là lúc kiến thức Inventory Pattern từ Lab 2 bắt đầu trở nên hữu ích.

---

32. --limit

Một option rất hữu ích:

ansible production \
  --limit web-01 \
  -m ansible.builtin.command \
  -a "uptime"

Mặc dù target là:

production

nhưng:

--limit web-01

giới hạn execution chỉ còn:

web-01

Trong production, --limit là một cơ chế rất hữu ích để giảm phạm vi ảnh hưởng.

---

33. --check

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

ansible webservers \
  -b \
  -m ansible.builtin.apt \
  -a "name=nginx state=present" \
  --check

Ý tưởng:

Normal
   ↓
Make changes

Check mode
   ↓
Predict changes

Không phải mọi module đều hỗ trợ check mode hoàn hảo.

Đây là lý do cần đọc documentation của module trước khi dựa vào kết quả --check.

---

34. --diff

Với các module hỗ trợ diff:

ansible webservers \
  -m ansible.builtin.copy \
  -a "src=hello.txt dest=/tmp/hello.txt" \
  --diff

Có thể giúp xem nội dung thay đổi.

Điều này rất hữu ích khi làm configuration management.

---

35. --become

Thay vì:

-b

có thể viết:

--become

Ví dụ:

ansible webservers \
  --become \
  -m ansible.builtin.service \
  -a "name=nginx state=started"

Trong tài liệu hoặc CI/CD, sử dụng dạng đầy đủ đôi khi giúp command dễ đọc hơn.

---

36. --ask-become-pass

Nếu cần nhập sudo password:

ansible webservers \
  --become \
  --ask-become-pass \
  -m ansible.builtin.service \
  -a "name=nginx state=started"

Không nên lưu password trực tiếp trong command hoặc Git.

---

37. Một số module quan trọng cần nhớ

Module	Công dụng
ping	Kiểm tra Ansible connectivity
command	Chạy command
shell	Chạy shell command
setup	Thu thập Facts
package	Quản lý package
apt	Package Debian/Ubuntu
dnf	Package Fedora/RHEL
service	Quản lý service
systemd	Quản lý systemd
user	Quản lý user
group	Quản lý group
file	File/directory/permission
copy	Copy file
fetch	Lấy file từ Managed Node
stat	Kiểm tra file
debug	Hiển thị thông tin

Không cần học thuộc toàn bộ module.

Điều quan trọng hơn là biết:

Ansible có module cho hầu hết các resource phổ biến và biết cách tìm module phù hợp.

---

38. Cách tìm module phù hợp

Khi cần làm một việc, đừng ngay lập tức viết:

shell: ...

Hãy tự hỏi:

"Ansible có module cho việc này không?"

Ví dụ:

Cài package
    ↓
apt / dnf / package

Quản lý service
    ↓
service / systemd

Tạo user
    ↓
user

Tạo directory
    ↓
file

Copy file
    ↓
copy

Template
    ↓
template

Đây là một thói quen rất quan trọng đối với DevOps Engineer.

---

39. Troubleshooting Ad-Hoc Command

Khi command fail, kiểm tra theo thứ tự:

Command
   │
   ▼
Target đúng?
   │
   ▼
SSH OK?
   │
   ▼
User đúng?
   │
   ▼
Có cần sudo?
   │
   ▼
Module đúng?
   │
   ▼
Arguments đúng?
   │
   ▼
OS có hỗ trợ?

Ví dụ:

ansible webservers \
  -m ansible.builtin.service \
  -a "name=nginx state=started"

Nếu fail:

Nginx có tồn tại không?

Kiểm tra:

ansible webservers \
  -m ansible.builtin.command \
  -a "which nginx"

---

40. -v, -vv, -vvv

Khi cần debug:

ansible webservers \
  -m ansible.builtin.ping \
  -vvv

Verbosity:

-v
-vv
-vvv
-vvvvv

Thông thường:

Normal
  ↓
-v
  ↓
-vvv

Chỉ tăng verbosity khi cần.

---

41. Lab thực chiến — Server Health Check

Hãy tưởng tượng bạn nhận ticket:

"Kiểm tra nhanh toàn bộ production server."

Thay vì SSH từng server:

ssh web-01
ssh web-02
ssh app-01
ssh db-01

hãy sử dụng Ansible.

Bước 1 — Uptime

ansible production \
  -m ansible.builtin.command \
  -a "uptime"

Bước 2 — Memory

ansible production \
  -m ansible.builtin.command \
  -a "free -h"

Bước 3 — Disk

ansible production \
  -m ansible.builtin.command \
  -a "df -h"

Bước 4 — OS

ansible production \
  -m ansible.builtin.setup \
  -a "filter=ansible_distribution"

Bước 5 — Architecture

ansible production \
  -m ansible.builtin.setup \
  -a "filter=ansible_architecture"

Bây giờ bạn có thể kiểm tra nhiều server chỉ bằng vài command.

---

42. Lab thực chiến — Kiểm tra Nginx

Giả sử team yêu cầu:

"Kiểm tra Nginx có đang chạy trên tất cả Web Server không."

Chạy:

ansible webservers \
  -b \
  -m ansible.builtin.service \
  -a "name=nginx state=started"

Sau đó:

ansible webservers \
  -m ansible.builtin.command \
  -a "systemctl is-active nginx"

Nếu server nào không chạy, Ansible sẽ giúp bạn xác định server đó.

---

43. Lab thực chiến — Tạo user deploy

Yêu cầu:

Tạo user deploy trên toàn bộ Web Server.

ansible webservers \
  -b \
  -m ansible.builtin.user \
  -a "name=deploy state=present"

Kiểm tra:

ansible webservers \
  -m ansible.builtin.command \
  -a "id deploy"

Chạy lại command:

ansible webservers \
  -b \
  -m ansible.builtin.user \
  -a "name=deploy state=present"

Quan sát changed.

Đây là một lần nữa bạn thấy:

Desired State
     +
Idempotency

---

44. Khi nào không nên dùng Ad-Hoc Command?

Không nên dùng Ad-Hoc để xây dựng một quy trình deployment lớn.

Ví dụ:

Install Docker
      ↓
Create user
      ↓
Create directory
      ↓
Copy config
      ↓
Pull image
      ↓
Start application
      ↓
Health check
      ↓
Rollback

Nếu bạn thực hiện hàng chục Ad-Hoc Command:

ansible ...
ansible ...
ansible ...
ansible ...
ansible ...

thì automation sẽ trở nên khó:

• Review.
• Reuse.
• Version control.
• Test.
• Debug.
• Rollback.

Lúc này phải chuyển sang:

Playbook

---

45. Quy tắc thực tế

Có thể sử dụng quy tắc:

                 Task
                   │
          ┌────────┴────────┐
          ▼                 ▼
       One-time          Repeatable
          │                 │
          ▼                 ▼
       Ad-Hoc           Playbook

Ví dụ:

Ad-Hoc

"Kiểm tra disk trên server web-02."

Playbook

"Đảm bảo tất cả Web Server có disk monitoring agent."

---

46. 🧠 Senior Thinking

Người mới có thể nghĩ:

"Ad-Hoc Command giúp tôi chạy command trên nhiều server."

Đúng.

Nhưng Engineer nên nghĩ:

"Tôi đang dùng Ansible để interact với infrastructure thông qua abstraction layer."

Senior sẽ hỏi thêm:

"Tại sao tôi đang dùng shell thay vì module?"

"Task này có idempotent không?"

"Tôi có đang tạo configuration drift không?"

"Nếu command chạy thành công trên 9/10 server thì trạng thái hệ thống là gì?"

"Có nên thực hiện thay đổi trên toàn bộ production cùng lúc không?"

"Có thể giới hạn bằng --limit không?"

"Có nên biến operation này thành Playbook để có thể audit và repeat không?"

Đây là sự khác biệt giữa:

Command Executor

và:

Infrastructure Engineer

---

47. Production Safety

Ad-Hoc Command rất mạnh.

Vì vậy nó cũng có thể nguy hiểm.

Ví dụ:

ansible all \
  -b \
  -m ansible.builtin.command \
  -a "rm -rf /some/path"

Một command sai target có thể ảnh hưởng toàn bộ infrastructure.

Vì vậy trước khi chạy command thay đổi production:

1. Kiểm tra target

ansible-inventory --graph

2. Kiểm tra host

ansible production \
  -m ansible.builtin.ping

3. Giới hạn phạm vi

--limit web-01

4. Kiểm tra command

5. Chạy trên một server trước

web-01
  ↓
Verify
  ↓
web-02
  ↓
Verify
  ↓
Remaining servers

Đây là một thói quen rất tốt trong production.

---

48. Exercise 1 — Basic Commands

Thực hiện trên tất cả server:

hostname
uptime
free -h
df -h

Nhưng không SSH thủ công.

Chỉ sử dụng Ansible Ad-Hoc Commands.

---

49. Exercise 2 — Package Management

Trên Web Server:

• Kiểm tra Nginx đã cài chưa.
• Nếu chưa có, cài Nginx.
• Kiểm tra version.
• Đảm bảo service đang chạy.

Sử dụng:

apt
service
command

---

50. Exercise 3 — User Management

Tạo:

deploy

trên tất cả Web Server.

Yêu cầu:

User exists

Chạy lại command và đảm bảo không có thay đổi không cần thiết.

---

51. Exercise 4 — File Management

Tạo:

/opt/myapp

và:

/opt/myapp/README.txt

với nội dung:

Managed by Ansible

Sau đó kiểm tra:

cat /opt/myapp/README.txt

---

52. Exercise 5 — Troubleshooting

Cố tình:

1. Target một host không tồn tại.
2. Sử dụng SSH user sai.
3. Sử dụng service không tồn tại.
4. Thử chạy task cần root mà không dùng -b.

Với mỗi lỗi:

Error
 ↓
Understand
 ↓
Find root cause
 ↓
Fix
 ↓
Verify

Không chỉ sửa cho command chạy được.

Hãy hiểu tại sao nó fail.

---

53. Exercise 6 — Production Challenge

Bạn nhận được yêu cầu:

"Web Server web-02 đang sử dụng gần đầy disk. Hãy kiểm tra server mà không thay đổi bất kỳ configuration nào."

Hãy sử dụng Ad-Hoc Commands để thu thập:

Hostname
Uptime
Disk
Memory
OS
Kernel
IP

Không được sử dụng Playbook.

Mục tiêu là thực hành read-only investigation.

---

54. Exercise 7 — Safe Production Change

Giả sử Nginx cần được restart trên production.

Không được restart toàn bộ server cùng lúc.

Thực hiện:

web-01
   ↓
Restart
   ↓
Verify
   ↓
web-02
   ↓
Restart
   ↓
Verify

Sử dụng:

--limit

để kiểm soát phạm vi.

Ví dụ:

ansible production \
  --limit web-01 \
  -b \
  -m ansible.builtin.service \
  -a "name=nginx state=restarted"

Sau đó kiểm tra:

ansible web-01 \
  -m ansible.builtin.command \
  -a "systemctl is-active nginx"

---

55. Checklist hoàn thành Lab

• [ ] Hiểu Ad-Hoc Command.
• [ ] Hiểu -m.
• [ ] Hiểu -a.
• [ ] Sử dụng command.
• [ ] Sử dụng shell.
• [ ] Hiểu sự khác nhau giữa command và shell.
• [ ] Sử dụng ping.
• [ ] Sử dụng setup.
• [ ] Sử dụng package.
• [ ] Sử dụng apt.
• [ ] Sử dụng service.
• [ ] Sử dụng user.
• [ ] Sử dụng file.
• [ ] Sử dụng copy.
• [ ] Hiểu -b / --become.
• [ ] Hiểu -K / --ask-become-pass.
• [ ] Biết sử dụng --limit.
• [ ] Biết sử dụng verbosity để debug.
• [ ] Biết khi nào dùng Ad-Hoc.
• [ ] Biết khi nào phải chuyển sang Playbook.

---

56. Tổng kết

Sau Lab 3, chúng ta đã đi qua:

Lab 1
Ansible Fundamentals
        │
        ▼
Lab 2
Inventory + SSH
        │
        ▼
Lab 3
Ad-Hoc Commands

Bây giờ bạn đã có thể:

                  Control Node
                       │
                 ┌─────┴─────┐
                 │  Ansible  │
                 └─────┬─────┘
                       │
            ┌──────────┼──────────┐
            ▼          ▼          ▼
          Web          App         DB
            │          │          │
         Commands    Commands   Commands

Bạn không còn phải:

SSH
 ↓
Command
 ↓
SSH
 ↓
Command
 ↓
SSH
 ↓
Command

mà có thể quản lý nhiều server từ một Control Node.

Tuy nhiên, chúng ta vẫn đang có một vấn đề:

Ad-Hoc Command chỉ phù hợp cho những tác vụ đơn lẻ.

Khi quy trình trở nên phức tạp:

Install
   ↓
Configure
   ↓
Create User
   ↓
Copy Files
   ↓
Start Service
   ↓
Verify

chúng ta cần một cách để lưu toàn bộ automation thành code.

Đó chính là lúc Playbook xuất hiện.

Lab tiếp theo — Ansible Playbook Fundamentals sẽ chuyển chúng ta từ việc "ra lệnh cho server" sang việc mô tả trạng thái mong muốn của server bằng code.

Đây là bước chuyển rất quan trọng:

Ad-Hoc Commands
       ↓
"Do this now"
       ↓
Playbook
       ↓
"Keep the system in this state"

Và từ đây, Ansible bắt đầu trở thành một công cụ Configuration Management & Infrastructure Automation, thay vì chỉ đơn giản là một công cụ chạy command từ xa.