Tại sao Jenkins vẫn là "vị vua" không ngai cho hệ thống SaaS On-premise triển khai trên Kubernetes?

1. Bối cảnh: Khi SaaS "lên sàn" On-premise

Đặc thù của khách hàng doanh nghiệp lớn: Pháo đài bảo mật và bài toán "Air-gapped"

Đối với các doanh nghiệp thuộc khối Tài chính, Ngân hàng hoặc Chính phủ, việc đưa dữ liệu đào tạo lên Public Cloud đôi khi là một "mission impossible" vì các rào cản pháp lý và bảo mật. Hệ thống CLS khi triển khai cho các đơn vị này thường phải vận hành trong môi trường Air-gapped – những hạ tầng biệt lập hoàn toàn, không có kết nối Internet.

Tại đây, mọi quy trình từ Deployment đến cập nhật phiên bản đều phải diễn ra trong mạng nội bộ. Điều này đặt ra một thách thức cực đại cho các kỹ sư DevOps: Làm sao để duy trì tính nhất quán của một sản phẩm SaaS trong khi mỗi khách hàng lại sở hữu một "pháo đài" hạ tầng riêng biệt?

Sự trỗi dậy của các giải pháp Cloud-native: Tại sao chúng lại "vấp" khi gặp On-premise?

Trong kỷ nguyên Kubernetes, những cái tên như GitHub Actions, GitLab CI hay các giải pháp quản lý như CircleCI đã trở thành tiêu chuẩn vàng nhờ sự tiện lợi và khả năng tích hợp mượt mà. Tuy nhiên, khi đối mặt với mô hình On-premise, các "ngôi sao" này bắt đầu bộc lộ điểm yếu:

GitHub Actions/CircleCI: Phụ thuộc nặng nề vào kết nối Cloud của nhà cung cấp. Việc thiết lập các Runner nội bộ (Self-hosted runners) trong môi trường chặn hoàn toàn outbound traffic là một cực hình về mặt cấu hình và duy trì.
GitLab CI: Rất mạnh mẽ nhưng đi kèm với một bộ "tải trọng" (overhead) tài nguyên khổng lồ. Để vận hành trơn tru trên một Cluster K8s vốn đã bị giới hạn về Resource Quota tại On-premise, việc cài đặt toàn bộ Stack của GitLab đôi khi là quá xa xỉ.
Tekton: Một giải pháp thuần K8s-native đầy hứa hẹn, nhưng độ phức tạp trong việc quản lý YAML và đường cong học tập (learning curve) quá dốc khiến nó khó trở thành lựa chọn ưu tiên khi cần triển khai nhanh và ổn định cho hàng chục khách hàng khác nhau.

Chính lúc này, một "cựu binh" dày dạn kinh nghiệm như Jenkins lại xuất hiện như một lựa chọn tối ưu nhất cho bài toán của CLS.

2. 4 Lý do Jenkins là lựa chọn chiến lược cho CLS

Khả năng tùy biến vô hạn (Extensibility) với hệ sinh thái Plugin đồ sộ

Với hơn 1,800 plugins, Jenkins không chỉ là một công cụ CI/CD; nó là một "bộ khung" cho phép đội ngũ CLS "may đo" quy trình theo đúng hiện trạng hạ tầng của khách hàng. Từ việc tích hợp với các hệ thống lưu trữ nội bộ (MinIO, Nexus) đến việc đẩy Image vào Private Registry của doanh nghiệp, Jenkins luôn có sẵn giải pháp. Trong khi các công cụ hiện đại thường ép người dùng tuân theo một "Standard Pipeline", Jenkins cho phép chúng tôi can thiệp sâu vào từng Stage, đáp ứng cả những yêu cầu bảo mật khắt khe nhất từ phía Stakeholders.

Chế độ "Air-gapped" thân thiện: Làm chủ hoàn toàn luồng dữ liệu

Đây là điểm "ăn tiền" nhất khi triển khai cho các đơn vị tài chính. Jenkins có thể vận hành hoàn hảo trong môi trường Offline. Chúng tôi đóng gói toàn bộ Jenkins Master, các Plugin cần thiết và Build Tools vào các Container Images. Khi vào mạng nội bộ của khách hàng, chỉ cần một lệnh helm install, toàn bộ hệ thống CI/CD sẽ sẵn sàng hoạt động mà không cần "với" ra Internet để tải bất kỳ Dependency nào. Sự phụ thuộc vào Cloud của GitHub Actions hay CircleCI hoàn toàn bị triệt tiêu tại đây.

Tích hợp sâu với Kubernetes qua Kubernetes Agent

Để tối ưu hóa tài nguyên On-premise vốn hạn hẹp, CLS tận dụng sức mạnh của Kubernetes Agent. Thay vì duy trì các máy chủ Build (Slave) chạy 24/7 gây lãng phí CPU/RAM, Jenkins sẽ:

Tự động khởi tạo một Ephemeral Pod (Pod tạm thời) trên Cluster K8s ngay khi có yêu cầu Build.
Thực thi các Job (Compile, Unit Test, Dockerize) ngay trong Pod đó.
Terminate (Hủy) Pod ngay sau khi hoàn tất để trả lại tài nguyên cho các dịch vụ chính của hệ thống CLS. Cơ chế này giúp duy trì hiệu năng cao nhất cho Cluster mà không đòi hỏi khách hàng phải nâng cấp phần cứng quá mức.

Chi phí vận hành (TCO - Total Cost of Ownership) tối ưu

Trong mô hình SaaS On-premise, việc kiểm soát chi phí là sống còn. Sử dụng Jenkins – một giải pháp Mã nguồn mở (Open-source) – giúp CLS loại bỏ hoàn toàn gánh nặng phí bản quyền tính theo đầu User (như GitLab Enterprise hay Azure DevOps). Điều này cho phép chúng tôi tập trung ngân sách vào việc nâng cấp tính năng sản phẩm thay vì trả tiền cho các Tooling thương mại. Việc tự chủ mã nguồn cũng giúp đội ngũ DevOps xử lý sự cố (Troubleshooting) nhanh hơn khi có lỗi phát sinh từ lõi hệ thống.

3. Từ tư duy Sản phẩm đến thực thi Kỹ thuật

Cân bằng giữa ổn định và linh hoạt: Jenkins trong vai trò "Người gác cổng" (Gatekeeper)

Trong mô hình SaaS, Product Owner (PO) luôn chịu áp lực phải đẩy tính năng mới (New Features) ra thị trường nhanh nhất có thể. Tuy nhiên, khách hàng doanh nghiệp vận hành On-premise lại đặt sự Ổn định (Stability) lên bàn cân hàng đầu. Họ không chấp nhận bất kỳ rủi ro nào làm gián đoạn hệ thống đào tạo của hàng nghìn nhân sự.

Jenkins giải quyết mâu thuẫn này bằng các Pipeline phức tạp, thiết lập các "chốt chặn" kiểm định nghiêm ngặt:

Automated Testing: Tự động chạy Unit Test, Integration Test ngay trên Cluster K8s trước khi cho phép đóng gói Image.
Security Scanning: Tích hợp các công cụ quét lỗ hổng (SCA, SAST) trực tiếp vào quy trình CI.
Approval Gates: Thiết lập các bước xác nhận thủ công (Manual Input) từ Tech Lead hoặc Stakeholder ngay trong Pipeline trước khi thực hiện lệnh helm upgrade lên môi trường Production của khách hàng.

Jenkins Shared Libraries: Chuẩn hóa quy trình triển khai cho hàng chục khách hàng

Một trong những "vũ khí" bí mật giúp CLS quản lý hàng chục khách hàng On-premise khác nhau mà không bị "đuối" về nguồn lực chính là Jenkins Shared Libraries.

Thay vì viết lại hàng trăm file Jenkinsfile rời rạc cho từng dự án, chúng tôi đóng gói toàn bộ logic triển khai (từ Build, Push Image đến Deploy Helm Chart) vào một bộ thư viện dùng chung (Shared Lib) viết bằng Groovy.

Tái sử dụng cao: Khi cần cập nhật quy trình bảo mật mới, chúng tôi chỉ cần chỉnh sửa code tại một nơi duy nhất.
Giảm thiểu sai sót: Kỹ sư chỉ cần gọi các hàm chuẩn hóa như clsDeployToK8s() với các tham số tương ứng cho từng Client. Điều này giúp việc vận hành hệ thống SaaS On-premise trở nên công nghiệp hóa, giảm thiểu tối đa các lỗi cấu hình thủ công (Human Error).

4. Bài học thực tế: Không có "viên đạn bạc"

Những "nỗi đau" kinh điển khi vận hành Jenkins

Dù là "vị vua", Jenkins không thiếu những vết sẹo khiến các kỹ sư DevOps phải đau đầu. Tại CLS, chúng tôi cũng không ngoại lệ khi đối mặt với:

Plugin Hell: Việc phụ thuộc vào quá nhiều Plugin dẫn đến xung đột phiên bản (Dependency Hell). Chỉ cần nâng cấp một Plugin nhỏ cũng có thể khiến toàn bộ Pipeline "gãy" (Break).
Giao diện cổ điển & Click-ops: Giao diện người dùng của Jenkins thực sự đã lỗi thời. Việc cấu hình Job bằng cách "click chuột" trên UI là một thảm họa khi cần quản lý hàng loạt khách hàng On-premise, vì nó không thể kiểm soát phiên bản (Version Control) và dễ sai sót.
Cấu hình nặng nề (Stateful): Jenkins truyền thống lưu trữ mọi thứ trong JENKINS_HOME. Nếu Pod bị die mà không có cơ chế Backup/Restore chuẩn, toàn bộ lịch sử build và cấu hình sẽ bay màu.

Cách đội ngũ CLS khắc phục: Hiện đại hóa Jenkins trên K8s

Để biến Jenkins thành một hệ thống Cloud-native thực thụ, chúng tôi áp dụng tư duy Configuration as Code (JCasC):

Jenkins Configuration as Code (JCasC): Mọi cấu hình từ Credential, Cloud Provider (K8s) đến danh sách Plugin đều được định nghĩa bằng YAML. Khi triển khai cho khách hàng mới, chúng tôi chỉ cần đẩy file YAML này vào Cluster. Jenkins sẽ tự cấu hình chính nó trong vài giây, đảm bảo tính Reproducible (có thể tái lập) tuyệt đối.
Job DSL & Pipeline Scripting: Tuyệt đối không có "Click-ops". Mọi Job được định nghĩa bằng code (Groovy). Nếu một Cluster của khách hàng gặp sự cố, chúng tôi có thể dựng lại nguyên trạng hệ thống CI/CD chỉ bằng một lệnh triển khai.
Persistent Volume Claims (PVC): Tận dụng Storage Class của K8s On-premise để gắn các ổ đĩa bền vững cho Jenkins Master, đảm bảo dữ liệu cấu hình luôn an toàn ngay cả khi Pod bị tái khởi động.

Góc nhìn chuyên gia (Lessons Learned)

Đừng dùng Jenkins nếu đội ngũ chưa sẵn sàng

Cần phải thẳng thắn: Jenkins cực kỳ mạnh mẽ nhưng nó không dành cho những tay mơ. Để "thuần hóa" Jenkins trên Kubernetes, đội ngũ của bạn cần kỹ năng DevOps vững vàng hơn nhiều so với việc dùng các công cụ "mỳ ăn liền" như GitHub Actions. Nếu bạn không có nhân sự am hiểu về Groovy, K8s RBAC, và Container Orchestration, Jenkins sẽ nhanh chóng trở thành một "gánh nặng kỹ thuật" (Technical Debt) khổng lồ thay vì là một công cụ hỗ trợ.

Luôn dùng Jenkins Pipeline (Groovy) – Tuyệt đối không "Click-ops"

Bài học đắt giá nhất khi quản lý hàng loạt khách hàng On-premise là: Đừng bao giờ cấu hình bằng tay trên giao diện. Nếu bạn muốn hệ thống có khả năng mở rộng và dễ dàng bảo trì, mọi thứ phải nằm trong Code. Sử dụng Jenkinsfile và Shared Libraries không chỉ giúp quy trình trở nên minh bạch mà còn cho phép bạn kiểm soát phiên bản (Version Control) mọi thay đổi trong luồng triển khai. Khi có sự cố tại hạ tầng khách hàng, Code là thứ duy nhất giúp bạn tái lập hệ thống một cách chính xác nhất.

Sự phối hợp: Khi DevOps ngồi cùng Product Owner

Tại CLS, chúng tôi nhận ra rằng CI/CD không chỉ là câu chuyện của kỹ sư. Kỹ sư DevOps phải ngồi lại với Product Owner để định nghĩa rõ: "Thế nào là một đợt deploy thành công trên hạ tầng khách hàng?".

Liệu khách hàng có chấp nhận Downtime 30 giây không?
Quy trình Rollback sẽ diễn ra tự động hay cần sự phê duyệt từ phía bảo mật của họ? Jenkins cung cấp công cụ, nhưng chính sự phối hợp chặt chẽ giữa các Stakeholders mới là yếu tố quyết định sự thành công của một sản phẩm SaaS On-premise.

Kết luận: Jenkins có thể "già" về mặt giao diện, nhưng với khả năng tùy biến vô hạn và sự tương thích tuyệt vời với Kubernetes trong môi trường Air-gapped, nó vẫn là "vị vua" không thể thay thế cho hệ thống CLS. Trong cuộc chơi On-premise khắc nghiệt, sự ổn định và khả năng tự chủ chính là chìa khóa để chiếm trọn lòng tin của những khách hàng khó tính nhất.