Yêu cầu hệ thống

Mục lụcCopy Anchor Link

• Phạm vi và nguyên tắc
  • Controller và agent có vai trò khác nhau
• Java cho Jenkins LTS
  • Kiểm tra policy trước khi chọn JDK
  • Kiểm tra Java trên máy đích
• CPU, RAM, disk và storage
  • Baseline cho lab
  • Storage bền vững và quyền truy cập
• Network, DNS và cổng
  • Các luồng kết nối cần lập kế hoạch
  • Kiểm tra DNS, HTTPS và cổng
• Capacity planning ban đầu
  • Bảng sizing khởi điểm
  • Đo workload để điều chỉnh
• Lab kiểm tra sẵn sàng
  • Thu thập thông tin host
  • Xác thực luồng mạng và storage
  • Ghi lại kết quả
• Checklist trước khi cài
• Nguồn Jenkins chính thức

Phạm vi và nguyên tắcCopy Anchor Link

Jenkins gồm controller — nơi giữ cấu hình, credential, queue và điều phối Pipeline — cùng agent — nơi thực thi build, test và workspace. Tách hai vai trò ngay từ đầu giúp một build nặng không làm giao diện hay queue của controller chậm đi.

Controller và agent có vai trò khác nhauCopy Anchor Link

Java cho Jenkins LTSCopy Anchor Link

Controller và agent Java cần một Java runtime phù hợp với bản Jenkins đang chạy. JDK để chạy Jenkins là một quyết định độc lập với JDK mà Pipeline dùng để compile ứng dụng: agent có thể cần nhiều JDK theo dự án.

Kiểm tra policy trước khi chọn JDKCopy Anchor Link

Không ghi cứng một số phiên bản Java vào runbook vì Java support thay đổi giữa các dòng Jenkins LTS. Trước mỗi lần cài mới hoặc nâng cấp, thực hiện theo thứ tự sau:

1. Chọn chính xác bản Jenkins LTS sẽ triển khai.
2. Đối chiếu bản đó với Java Support Policy và release notes của Jenkins LTS.
3. Cài một JDK/JRE nằm trong danh sách được hỗ trợ; dùng cùng họ Java cho controller và agent Java nếu không có lý do tương thích đã kiểm thử để khác nhau.
4. Chạy một controller thử nghiệm, kết nối một agent thử và kiểm tra plugin/toolchain quan trọng trước khi đổi production.

Nếu một agent được chạy bằng Java, Java của agent cũng phải nằm trong policy cho phiên bản Jenkins controller tương ứng. Agent khởi chạy bằng SSH hoặc inbound agent vẫn cần runtime Java trên chính máy agent.

Kiểm tra Java trên máy đíchCopy Anchor Link

java -version
command -v java
readlink -f "$(command -v java)"

CPU, RAM, disk và storageCopy Anchor Link

Yêu cầu tài nguyên phụ thuộc mạnh vào plugin, số job chạy đồng thời, kích thước repository, cache, số build được giữ và artifact. Hardware Recommendations là điểm tham chiếu chính thức; hãy dùng số liệu quan sát từ workload thật thay vì suy diễn từ số executor trên UI.

Baseline cho labCopy Anchor Link

Cho một lab học Jenkins LTS với một controller, ít job mẫu và không build trên controller, có thể bắt đầu với 2 vCPU, 4 GiB RAM và 20 GiB persistent storage cho controller. Một agent lab chạy một executor có thể bắt đầu cùng mức 2 vCPU, 4 GiB RAM và 20 GiB workspace nếu toolchain không nặng.

Đây là giả định baseline cho lab, không phải mức tối thiểu hay cam kết cho production. Ví dụ, build Android, Docker image, phân tích mã hoặc test song song thường cần RAM, CPU và disk lớn hơn đáng kể. Đo rồi tăng kích thước cho từng loại agent.

Storage bền vững và quyền truy cậpCopy Anchor Link

JENKINS_HOME của controller chứa cấu hình, job, plugin, build record và dữ liệu nhạy cảm. Đặt nó trên storage persistent có snapshot/backup theo chính sách của tổ chức. Không xem disk cục bộ tạm thời, workspace agent hay snapshot cùng failure domain là bản backup duy nhất.

Tách dung lượng cần theo dõi:

• JENKINS_HOME: tăng theo lịch sử build, plugin, logs và dữ liệu giữ lại.
• Workspace/cache trên agent: tăng theo repository, dependency cache và build output; đặt chính sách cleanup phù hợp.
• Artifact: ưu tiên kho artifact chuyên dụng khi retention lớn, thay vì giữ mọi artifact trong controller.
• Backup: dự trù storage và băng thông ở failure domain khác; kiểm thử restore định kỳ.

/var/lib/jenkins và C:\Jenkins\Home dưới đây chỉ là ví dụ cho JENKINS_HOME; thay bằng đường dẫn đã chọn. Trước khi cài package, tài khoản dịch vụ jenkins và thư mục đích có thể chưa tồn tại. Khi đó chỉ kiểm tra filesystem/đường dẫn cha và dung lượng. Chỉ chạy kiểm tra bằng tài khoản dịch vụ sau khi package hoặc quy trình cài đặt đã tạo tài khoản và JENKINS_HOME.

JENKINS_HOME=/var/lib/jenkins # Ví dụ, thay bằng đường dẫn đã chọn.
existing_path="$JENKINS_HOME"
while [ ! -e "$existing_path" ]; do existing_path="$(dirname "$existing_path")"; done

printf 'Kiểm tra filesystem và parent path đang tồn tại: %s\n' "$existing_path"
df -hT "$existing_path"
df -i "$existing_path"
namei -l "$existing_path"

JENKINS_HOME=/var/lib/jenkins # Ví dụ, thay bằng đường dẫn đã chọn.
if id jenkins >/dev/null 2>&1 && [ -d "$JENKINS_HOME" ]; then
  namei -l "$JENKINS_HOME"
  sudo -u jenkins test -r "$JENKINS_HOME" && echo 'read: OK'
  sudo -u jenkins test -w "$JENKINS_HOME" && echo 'write: OK'
  sudo -u jenkins test -x "$JENKINS_HOME" && echo 'traverse: OK'
else
  echo 'Bỏ qua: tài khoản jenkins hoặc JENKINS_HOME chưa tồn tại; đây là kiểm tra post-install.'
fi

Network, DNS và cổngCopy Anchor Link

Lập allowlist theo luồng thực tế. Controller thường cần outbound HTTPS tới update center, SCM, kho plugin/artifact và dịch vụ xác thực mà tổ chức sử dụng. Agent thường cần outbound HTTPS tới SCM, kho dependency/artifact và các endpoint của Pipeline. Không mở internet hai chiều hoặc Any/Any chỉ để xử lý lỗi kết nối.

Các luồng kết nối cần lập kế hoạchCopy Anchor Link

direction: right
browser: Browser
proxy: Reverse proxy
controller: Controller
services: Update center / SCM / artifact / IdP
ssh: Agent SSH
inbound: Inbound agent
registry: SCM / dependency / artifact registry
browser -> proxy: HTTPS
proxy -> controller: HTTPS/HTTP nội bộ
controller -> services: HTTPS
controller -> ssh: SSH khi launch bằng SSH
inbound -> controller: TCP đã cấu hình
ssh -> registry: HTTPS
inbound -> registry: HTTPS

• Người dùng nên truy cập controller qua HTTPS và reverse proxy; không public trực tiếp port nội bộ của Jenkins nếu không cần thiết.
• Với SSH agent, controller phải tới được SSH port của agent. Với inbound agent, agent phải tới được TCP agent port đã cấu hình trên controller; không giả định một port cố định.
• Với WebSocket agent, agent kết nối qua HTTPS tới controller/reverse proxy; kiểm tra proxy hỗ trợ WebSocket.
• DNS phải phân giải được hostname controller từ agent, và các hostname external từ host cần truy cập chúng. Dùng hostname ổn định thay vì IP thay đổi.

Kiểm tra DNS, HTTPS và cổngCopy Anchor Link

Thay jenkins.example.internal bằng hostname controller/reverse proxy thật. URL https://updates.jenkins.io/ chỉ kiểm tra đường ra tới Jenkins Update Center; bổ sung các domain SCM, registry và IdP của tổ chức vào allowlist kiểm tra.

# DNS và outbound HTTPS từ controller hoặc agent.
getent hosts updates.jenkins.io
curl --fail --silent --show-error --connect-timeout 10 --head https://updates.jenkins.io/
getent hosts jenkins.example.internal

# Port đang lắng nghe trên controller; xem port Jenkins/reverse proxy đã cấu hình.
ss -ltnp

# Khi dùng SSH agent, chạy từ controller tới từng agent.
nc -vz agent-01.example.internal 22

Capacity planning ban đầuCopy Anchor Link

Bắt đầu từ concurrency, không phải chỉ từ số job. Ghi số executor đồng thời, thời lượng build ở p50/p95, peak queue time, RAM/CPU peak, I/O wait, disk growth và dung lượng artifact. Một agent có một executor là cách đơn giản để cô lập baseline; chỉ tăng executor khi đo cho thấy toolchain còn headroom.

Bảng sizing khởi điểmCopy Anchor Link

Các mức trên là điểm bắt đầu cần đo thực tế, dựa trên khuyến nghị phần cứng Jenkins và giả định workload nêu trong bảng, không phải sizing chính thức cho mọi cài đặt. Không cộng workspace agent vào dung lượng JENKINS_HOME; hai loại storage có tốc độ tăng khác nhau.

Đo workload để điều chỉnhCopy Anchor Link

Dùng một khoảng quan sát có peak thực tế, ví dụ một tuần release, rồi trả lời các câu hỏi sau:

1. Queue có tăng trong giờ cao điểm dù agent còn online không? Nếu có, thêm năng lực agent hoặc tối ưu job trước.
2. Controller có GC pause, CPU cao hoặc UI chậm khi lịch sử build tăng không? Nếu có, kiểm tra plugin, retention và tăng tài nguyên controller sau khi có số đo.
3. Disk có đủ headroom cho tăng trưởng trước chu kỳ cleanup/backup tiếp theo không? Đặt alert theo phần trăm trống và tốc độ tăng, không chờ tới lúc đầy disk.
4. Build nào tiêu thụ khác biệt? Gắn label để route build nặng vào agent phù hợp thay vì tăng mọi máy như nhau.

Một cách ước lượng đơn giản cho storage controller là lấy mức sử dụng JENKINS_HOME hiện tại, cộng tăng trưởng đã đo giữa hai chu kỳ cleanup, rồi chừa ít nhất phần headroom theo chính sách vận hành. Kiểm thử restore cho biết backup có đáp ứng được thời gian khôi phục mục tiêu hay không.

Lab kiểm tra sẵn sàngCopy Anchor Link

hostnamectl
nproc
lscpu
free -h
df -hT
df -i
java -version

Checklist trước khi càiCopy Anchor Link

• Đã chọn bản Jenkins LTS và đối chiếu Java runtime với Java Support Policy.
• Controller và agent đã được phân vai; controller production dự kiến có 0 executor.
• Baseline CPU/RAM/disk được ghi rõ là giả định khởi điểm và có kế hoạch đo workload thật.
• JENKINS_HOME nằm trên storage persistent; có retention, backup và kiểm thử restore.
• Tài khoản dịch vụ Jenkins có quyền truy cập tối thiểu cần thiết vào storage.
• DNS phân giải được các hostname cần dùng từ đúng host; outbound HTTPS tới các endpoint được allowlist hoạt động.
• Cổng cho browser, reverse proxy và kiểu kết nối agent đã được kiểm tra theo sơ đồ.
• Không có workstation cá nhân hoặc port public không kiểm soát trong thiết kế production.

Nguồn Jenkins chính thứcCopy Anchor Link

• Hardware Recommendations
• Java Support Policy
• Using Agents
• Controller Isolation
• Jenkins Update Center