Hướng dẫn Setup Jenkins cho hệ thống Monolith - Bài 2: Kiến trúc và nguyên lý hoạt động của Jenkins (Master - Agent)

1. Bản chất kiến trúc Master - Agent (Controller - Node) trong Jenkins

Jenkins hoạt động dựa trên mô hình phân tán (Distributed Architecture), chia làm hai thành phần chính:

• Jenkins Master (nay thường gọi là Controller):

  • Đây là "bộ não" điều phối của toàn bộ hệ thống.

  • Nhiệm vụ: Lưu trữ cấu hình các Job, quản lý lịch sử build, cung cấp giao diện Web UI, điều phối hàng đợi (build queue) và phân công công việc cho các Agent.

  • Nguyên tắc vàng: Master không nên trực tiếp chạy các tác vụ build nặng (như mvn clean install, npm run build, hay chạy hàng nghìn Unit Test) để tránh làm nghẽn cổ chai, sập giao diện hoặc treo toàn bộ hệ thống.

• Jenkins Agent (trước đây gọi là Slave):

  • Đây là "cơ bắp" thực thụ thực hiện công việc.

  • Nhiệm vụ: Nhận lệnh từ Master, kéo mã nguồn về không gian làm việc riêng (workspace), cài đặt thư viện và tiến hành build/test trên máy của chính nó, sau đó trả kết quả về cho Master.

2. Tại sao mô hình Master - Agent lại sống còn đối với hệ thống Monolith?

Hệ thống Monolith có đặc điểm là mã nguồn lớn, nhiều dependencies cồng kềnh (ví dụ: dự án Laravel chứa hàng trăm gói Composer, dự án Java Spring Boot cần tải hàng loạt thư viện Maven, hoặc dự án Node.js nặng node_modules).

Nếu bạn chạy tất cả trên một máy chủ duy nhất (Standalone):

• Tràn bộ nhớ (OOM - Out of Memory): Quá trình build dự án Monolith cỡ lớn có thể ngốn sạch RAM và CPU, làm sập cả Jenkins Master và ứng dụng đang chạy chung server.

• Xung đột môi trường: Nếu trên server cài nhiều phiên bản công cụ khác nhau (ví dụ: Project A cần Node 16, Project B cần Node 20), chúng sẽ đá nhau và gây lỗi build khó lường.

• Thiếu khả năng mở rộng: Khi công ty phát triển thêm nhiều nhánh Monolith khác, một máy chủ đơn lẻ sẽ nhanh chóng quá tải.

Việc tách rời Master và Agent giúp cách ly hoàn toàn môi trường build, bảo vệ hệ thống trung tâm luôn an toàn và ổn định.

3. Cơ chế giao tiếp giữa Master và Agent hoạt động ra sao?

Quá trình Jenkins Master tương tác với Agent diễn ra qua các bước bảo mật và tự động sau:

1. Khởi tạo kết nối: Agent có thể kết nối về Master thông qua SSH hoặc giao thức JNLP (Java Network Launch Protocol) / WebSocket.

2. Cấp phát Workspace: Khi một Pipeline được kích hoạt, Master chọn một Agent rảnh rỗi và phù hợp (thông qua nhãn - label), sau đó yêu cầu Agent tạo một thư mục làm việc riêng biệt (workspace).

3. Thực thi và Báo cáo: Agent thực thi tuần tự các câu lệnh trong Jenkinsfile, đồng thời stream log thời gian thực về cho Master hiển thị lên giao diện Web để lập trình viên theo dõi.

4. Mô hình triển khai Agent thực tế cho Monolith

Tùy vào quy mô hạ tầng của công ty, bạn có thể áp dụng 1 trong 2 mô hình Agent sau cho hệ thống Monolith:

• Static Agent (Agent tĩnh): Sử dụng các máy chủ ảo (VM) hoặc VPS riêng biệt được cấu hình sẵn môi trường (Cài sẵn JDK, Maven, Docker, Composer...). Phù hợp với hệ thống Monolith truyền thống ít thay đổi công nghệ nền tảng.

• Dynamic Docker Agent (Agent động trên Docker): Mỗi khi có lệnh build, Jenkins tự động bật lên một Docker Container chứa đúng môi trường cần thiết (ví dụ: php:8.2-fpm hoặc maven:3.8-eclipse-temurin-17), chạy xong sẽ tự hủy. Mô hình này cực kỳ sạch sẽ và hiện đại.