Vượt qua rào cản 'Chạy tốt trên máy tôi': Kiểm thử Ansible Playbook với Molecule và Docker

Table of Contents

Cái bẫy triển khai lúc 4:45 chiều thứ Sáu

Tôi nhớ rõ một buổi chiều thứ Sáu nọ, một thay đổi nhỏ trong cấu hình Nginx đã làm sập toàn bộ môi trường staging của chúng tôi. Trên máy cục bộ của tôi, Ansible playbook đã chạy hoàn hảo trên một máy ảo Ubuntu mới tinh. Tuy nhiên, server staging lại có kernel cũ hơn một chút và xung đột với một package cũ mà tôi không hề biết là có tồn tại. Đây chính là cái bẫy kinh điển của Hạ tầng dưới dạng mã (Infrastructure as Code – IaC). Chúng ta tự động hóa việc triển khai, nhưng lại quên tự động hóa việc kiểm thử chính công cụ tự động hóa đó.

Dựa dẫm vào việc kiểm tra xác suất thủ công hoặc “kiểm thử trên môi trường production” là một rủi ro cực lớn. Khi hạ tầng của bạn phát triển lên đến hàng chục hoặc hàng trăm node, bạn không thể cho phép mình phỏng đoán. Bạn cần một quy trình có thể khởi tạo một môi trường sạch, áp dụng cấu hình, xác minh trạng thái và sau đó xóa sạch mọi thứ. Sự kết hợp giữa Molecule và Docker mang lại chính xác mức độ tin cậy đó.

Chi phí tiềm ẩn khi kiểm thử trên Server tĩnh

Nhiều đội ngũ bắt đầu bằng cách kiểm thử playbook trên một server phát triển cố định, chạy lâu dài. Mặc dù ban đầu việc này có vẻ tiện lợi, nhưng nó tạo ra một số nút thắt cổ chai về kỹ thuật:

Configuration Drift (Lệch cấu hình): Theo thời gian, các server kiểm thử tích tụ các “tạp chất”—những chỉnh sửa thủ công, các package cũ và file tạm. Playbook của bạn có thể chỉ hoạt động nhờ một thay đổi thủ công mà bạn đã thực hiện từ sáu tháng trước.
State Contamination (Nhiễm chéo trạng thái): Việc kiểm thử một role database có thể để lại các file gây nhiễu cho việc kiểm thử role web server sau đó.
Phản hồi chậm: Việc chờ đợi 5 đến 10 phút để một máy ảo (VM) khởi động hoàn chỉnh sẽ làm mất đà làm việc của nhà phát triển.
Kết quả dương tính giả: Nếu không có một môi trường sạch hoàn toàn, gần như không thể xác minh xem playbook của bạn có thực sự đạt tính nhất quán (idempotent) hay không.

Vấn đề cốt lõi là thiếu một môi trường tạm thời (ephemeral) và có khả năng tái lập. Nếu bạn không thể đảm bảo một “trạng thái sạch” cho mỗi lần chạy kiểm thử, kết quả của bạn về cơ bản chỉ là những thông tin nhiễu.

So sánh các lựa chọn: VM thủ công vs. Vagrant vs. Molecule

Tôi đã thử nghiệm nhiều quy trình làm việc khác nhau trong nhiều năm qua. Mặc dù mỗi loại đều có trường hợp sử dụng cụ thể, nhưng khoảng cách về hiệu quả là rất đáng kể.

1. Snapshot máy ảo thủ công

Bạn tạo một VM, chụp snapshot, chạy code và khôi phục lại. Việc này cực kỳ chậm chạp. Nó cũng không thể tích hợp vào pipeline CI/CD, khiến nó trở thành một lựa chọn không khả thi cho các đội ngũ hiện đại.

2. Vagrant

Vagrant mô phỏng phần cứng production khá tốt, nhưng nó lại ngốn tài nguyên. Chạy kiểm thử một cụm ba node có thể dễ dàng tiêu tốn 6GB RAM và làm quạt laptop kêu như động cơ phản lực. Nó cũng nổi tiếng là khó chạy bên trong các CI runner dựa trên cloud như GitHub Actions nếu không có ảo hóa lồng (nested virtualization).

3. Molecule với Docker

Molecule là một framework được xây dựng chuyên biệt để kiểm thử các Ansible role. Khi kết hợp với Docker, tốc độ là không đối thủ. Bạn có thể khởi tạo một container, chạy role và xác minh kết quả trong vòng chưa đầy 60 giây. Sau khi triển khai quy trình này cho một khách hàng lớn, chúng tôi thấy các bản vá lỗi “khẩn cấp” cho các role hạ tầng giảm gần 70%.

Quy trình chuyên nghiệp: Molecule + Docker

Để thực hiện theo, hãy đảm bảo bạn đã cài đặt Python và Docker. Tôi thực sự khuyên bạn nên sử dụng môi trường ảo Python (venv) để tránh xung đột phụ thuộc với các công cụ hệ thống.

1. Thiết lập môi trường

# Khởi tạo môi trường ảo của bạn
python3 -m venv venv
source venv/bin/activate

# Cài đặt Molecule và Docker driver
pip install "molecule-plugins[docker]" ansible-lint pytest-testinfra

2. Khởi tạo một Role mới

Molecule có thể tạo cấu trúc khung (scaffolding) cần thiết cho bạn. Nếu bạn đang làm việc trên một role đã có sẵn, hãy chạy lệnh này bên trong thư mục gốc của role đó:

molecule init scenario default --driver-name docker

Lệnh này tạo ra thư mục molecule/default. Bên trong, file molecule.yml định nghĩa các nền tảng kiểm thử, trong khi verify.yml đảm nhận các bước kiểm tra cuối cùng.

3. Cấu hình nền tảng kiểm thử

Mở file molecule/default/molecule.yml. Tại đây, bạn định nghĩa các bản phân phối OS muốn kiểm thử. Kiểm thử đồng thời trên nhiều phiên bản là cách tuyệt vời để sớm phát hiện các lỗi tương thích.

dependency:
  name: galaxy
driver:
  name: docker
platforms:
  - name: ubuntu-2204
    image: geerlingguy/docker-ubuntu2204-ansible:latest
    pre_build_image: true
    privileged: true
    volumes:
      - /sys/fs/cgroup:/sys/fs/cgroup:rw
provisioner:
  name: ansible
verifier:
  name: ansible

Mẹo nhỏ: Hãy sử dụng các image của geerlingguy. Chúng được cấu hình sẵn with systemd, cho phép bạn kiểm thử các dịch vụ như Nginx hoặc MySQL vốn thường thất bại trong các Docker container tiêu chuẩn.

4. Thực hiện chu trình kiểm thử

Bạn có thể kích hoạt toàn bộ chuỗi tự động hóa chỉ bằng một lệnh:

molecule test

Molecule sau đó sẽ xử lý các công việc nặng nhọc. Nó kiểm tra cú pháp (lint) code của bạn, tạo các instance Docker, chạy playbook (Converge) và sau đó chạy lại lần nữa để kiểm tra tính nhất quán (idempotence). Cuối cùng, nó thực thi các script xác minh và hủy bỏ các container.

Chiến lược nâng cao cho tự động hóa tin cậy

Viết một bài kiểm thử thì dễ; viết một bài kiểm thử mang lại giá trị thực sự đòi hỏi nhiều chiến lược hơn.

Làm chủ tính nhất quán (Idempotence)

Kiểm tra idempotence là tính năng mạnh mẽ nhất của Molecule. Nếu playbook của bạn báo trạng thái “changed” ở lần chạy thứ hai, nghĩa là quy trình tự động hóa của bạn về mặt kỹ thuật đang bị lỗi. Điều đó có nghĩa là bạn đang chạy một script thay vì định nghĩa một trạng thái. Nếu bạn bắt buộc phải sử dụng module shell hoặc command, hãy luôn sử dụng các đối số creates hoặc removes để đảm bảo chúng chỉ chạy khi cần thiết.

Xác minh chuyên sâu với Testinfra

Mặc dù verify.yml rất tiện lợi, nhưng pytest-testinfra cho phép bạn viết mã Python thực thụ để kiểm tra server. Cách này biểu cảm hơn nhiều và cung cấp báo cáo lỗi tốt hơn.

def test_nginx_config(host):
    # Kiểm tra file cấu hình Nginx
    conf = host.file("/etc/nginx/nginx.conf")
    assert conf.user == "www-data"
    assert conf.contains("worker_connections 768;")

def test_port_80_is_listening(host):
    # Kiểm tra xem cổng 80 có đang lắng nghe không
    socket = host.socket("tcp://0.0.0.0:80")
    assert socket.is_listening

Tích hợp CI/CD

Chạy Molecule cục bộ rất tốt cho quá trình phát triển, nhưng sức mạnh thực sự đến từ việc tích hợp. Hãy thiết lập một GitHub Action để chạy molecule test trên mỗi Pull Request. Điều này tạo ra một rào chắn chất lượng ngăn chặn các lỗi tự động hóa tiếp cận vào nhánh chính của bạn.

Lời kết

Tự động hóa chuyên nghiệp không chỉ dừng lại ở việc biết cú pháp Ansible. Đó là về việc xây dựng một hệ thống mà bạn có thể tin tưởng. Bằng cách áp dụng Molecule và Docker, bạn chuyển từ cách triển khai “dựa trên hy vọng” sang một phương pháp tiếp cận được xác thực, ưu tiên kỹ thuật. Có thể bạn sẽ mất thêm một giờ để cấu hình bộ kiểm thử đầu tiên, nhưng nó sẽ giúp bạn tiết kiệm hàng chục giờ xử lý sự cố sau này. Hãy chọn role quan trọng nhất của bạn và khởi tạo Molecule ngay hôm nay—phiên bản tương lai của bạn sẽ biết ơn vì có thêm thời gian để ngủ ngon hơn.