DPTCloud
Quay lại danh sách
Tin tức công nghệ

Xây Dựng Hệ Thống CI/CD Không Máy Chủ (Runnerless) Bằng Dagger Và Podman Quadlets

7 tháng 6, 2026

Giới Thiệu Về Xu Hướng Runnerless CI/CD

Trong kỷ nguyên của điện toán đám mây và kiến trúc microservices, tốc độ và sự linh hoạt của quy trình CI/CD (Continuous Integration/Continuous Delivery) đóng vai trò quyết định đến sự thành bại của một sản phẩm công nghệ. Tuy nhiên, việc duy trì và quản lý các hệ thống CI/CD truyền thống luôn đi kèm với những thách thức không nhỏ về chi phí và tài nguyên vận hành.

Thông thường, các doanh nghiệp phải duy trì các cụm máy chủ ảo (VM) hoặc các node Kubernetes liên tục hoạt động chỉ để chờ đợi và thực thi các pipeline. Mô hình này không chỉ gây lãng phí ngân sách lớn khi hệ thống ở trạng thái rảnh rỗi mà còn tạo ra gánh nặng lớn cho đội ngũ quản trị hệ thống trong việc cập nhật bảo mật, vá lỗi hệ điều hành và quản lý scaling. Chính từ thực tế này, khái niệm Runnerless CI/CD (CI/CD không máy chủ) ra đời như một bước đột phá, thay đổi hoàn toàn cách chúng ta tiếp cận tự động hóa luồng công việc.

Bài viết này sẽ hướng dẫn chi tiết cách kết hợp hai công nghệ tiên tiến: Dagger (Engine lập trình pipeline bằng mã nguồn) và Podman Quadlets (Công cụ quản lý container dạng khai báo của Red Hat) để xây dựng một kiến trúc CI/CD tối giản, bảo mật, hiệu năng cao và hoàn toàn độc lập với các nền tảng đám mây lớn.

---

Tại Sao Lại Là Dagger Và Podman Quadlets?

1. Dagger: Đưa Pipeline Trở Thành Mã Nguồn Thực Thụ

Hầu hết các kỹ sư DevOps đều đã từng trải qua cảm giác mệt mỏi khi phải debug các file cấu hình YAML dài hàng ngàn dòng của GitHub Actions, GitLab CI hay Jenkins. YAML không có tính năng kiểm tra lỗi cú pháp mạnh mẽ, không thể tái sử dụng mã nguồn một cách linh hoạt và cực kỳ khó để chạy thử nghiệm (test) dưới máy cục bộ (local).

Dagger giải quyết triệt để bài toán này bằng cách cho phép bạn viết toàn bộ pipeline CI/CD bằng các ngôn ngữ lập trình phổ biến như Go, Python, hoặc TypeScript. Quy trình xử lý của Dagger dựa trên CUE và công nghệ Core của BuildKit, giúp tối ưu hóa bộ nhớ đệm (caching) đến từng layer cấu phần. Điều này có nghĩa là:

  • Chạy mọi nơi như nhau: Pipeline chạy dưới máy cục bộ của lập trình viên hoàn toàn giống hệt khi chạy trên server sản xuất. Không còn tình trạng "It works on my machine" nhưng lại lỗi trên CI.
  • Tận dụng sức mạnh của ngôn ngữ lập trình: Sử dụng vòng lặp, câu lệnh điều kiện, quản lý package và viết unit test cho chính luồng CI/CD của bạn.

2. Podman Quadlets: Quản Lý Container Tối Giản Qua Systemd

Nếu như Docker yêu cầu một daemon trung tâm (Docker Daemon) chạy với quyền root – tiềm ẩn nhiều nguy cơ bảo mật – thì Podman nổi tiếng với kiến trúc rootless (không cần quyền root). Tuy nhiên, việc quản lý vòng đời của các container Podman trên các server production đôi khi gặp khó khăn do thiếu một cơ chế quản lý dịch vụ chuẩn chỉnh.

Đó là lý do Red Hat giới thiệu Quadlets. Quadlets cho phép bạn khai báo cấu hình container thông qua các file unit được đơn giản hóa, sau đó tự động biên dịch chúng thành các service của systemd. Nhờ đó, việc quản lý container trở nên đồng nhất với việc quản lý các dịch vụ hệ thống của Linux:

  • Tự động khởi động lại container khi crash hoặc khi server reboot.
  • Quản lý logs tập trung thông qua journalctl.
  • Không cần duy trì một daemon quản lý container chạy ngầm liên tục, tiết kiệm tối đa RAM và CPU.
---

Kiến Trúc Tổng Quan Của Hệ Thống CI/CD Runnerless

Mô hình CI/CD truyền thống dựa vào các Agent (hoặc Runner) liên tục kết nối với máy chủ trung tâm (như GitLab Runner, GitHub Actions Runner). Ngược lại, kiến trúc Runnerless sử dụng phương pháp Event-Driven (Hướng sự kiện) kết hợp với hạ tầng theo yêu cầu (On-demand infrastructure).

Sự kết hợp giữa Dagger và Podman Quadlets tạo ra một mô hình lai tối ưu: Hệ thống chỉ tiêu thụ tài nguyên phần cứng đúng bằng thời gian thực thi pipeline, sau đó giải phóng hoàn toàn bộ nhớ.

Luồng hoạt động của hệ thống được mô tả như sau:

  1. Một sự kiện (ví dụ: Git Push hoặc Webhook từ Git Repository) được gửi đến một API Gateway hoặc Webhook Receiver siêu nhẹ trên server của bạn.
  2. Dịch vụ Webhook Receiver kích hoạt một service systemd tương ứng được định nghĩa bằng Podman Quadlet.
  3. Podman Quadlet khởi chạy một container chứa Dagger Engine và mã nguồn pipeline của dự án.
  4. Dagger thực thi các tác vụ (Linting, Testing, Building, Deploying) với tốc độ cao nhờ cơ chế cache thông minh.
  5. Sau khi hoàn thành, container tự động tắt và giải phóng 100% tài nguyên hệ thống.
---

Hướng Dẫn Triển Khai Từng Bước

Bước 1: Cấu Hình Mã Nguồn Pipeline Với Dagger

Đầu tiên, chúng ta cần khởi tạo một pipeline Dagger ngay trong mã nguồn dự án của bạn. Ở đây, chúng ta lấy ví dụ sử dụng ngôn ngữ Go để viết pipeline đơn giản nhằm kiểm tra và build ứng dụng.

Tạo file main.go bên trong thư mục .dagger/:

package main

import (
	"context"
	"fmt"
	"os"
	dagger "dagger.io/dagger"
)

func main() {
	ctx := context.Background()
	client, err := dagger.Connect(ctx, dagger.WithLogOutput(os.Stdout))
	if err != nil {
		panic(err)
	}
	defer client.Close()

	// Lấy thư mục mã nguồn hiện tại
	src := client.Host().Directory(".")

	// Định nghĩa môi trường build sử dụng Golang Container
	golang := client.Container().From("golang:1.21").
		WithMountedDirectory("/src", src).
		WithWorkdir("/src")

	// Thực hiện lệnh chạy test và build
	_ = golang.WithExec([]string{"go", "test", "./..."})
	build := golang.WithExec([]string{"go", "build", "-o", "myapp"})

	fmt.Println("Pipeline executed successfully!")
}

Bước 2: Viết Cấu Hình Podman Quadlet

Thay vì viết các kịch bản Bash phức tạp để gọi Docker hay Podman, chúng ta sẽ định nghĩa một file Quadlet có đuôi .container để hệ thống tự động quản lý thông qua systemd.

Tạo file cấu hình tại đường dẫn: /etc/containers/systemd/dagger-ci.container (hoặc tại thư mục user nếu chạy rootless):

[Unit]
Description=Dagger Runnerless CI Pipeline
After=network-online.target

[Container]
Image=registry.dagger.io/engine:v0.9.6
Environment=DAGGER_CLOUD_TOKEN=your_token_here
Volumes=/var/run/user/1000/podman/podman.sock:/var/run/buildkit/buildkitd.sock
Volume=/home/ubuntu/projects/myapp:/src:ro
Exec=go run .dagger/main.go

[Install]
WantedBy=multi-user.target default.target

Sau khi lưu file, bạn chỉ cần yêu cầu systemd tải lại cấu hình để tự động tạo ra một service hoàn chỉnh:

systemctl --user daemon-reload

Bước 3: Kích Hoạt Pipeline Theo Yêu Cầu (On-Demand)

Bây giờ, mỗi khi có một webhook gửi về báo có code mới, hệ thống của bạn (hoặc một script nhỏ lắng nghe webhook) chỉ cần thực hiện một lệnh hệ thống duy nhất để chạy toàn bộ pipeline:

systemctl --user start dagger-ci.service

Bạn có thể dễ dàng theo dõi toàn bộ quá trình thực thi và logs của pipeline thời gian thực bằng lệnh chuẩn của hệ điều hành Linux:

journalctl --user -u dagger-ci.service -f
---

Đánh Giá Ưu Điểm Và Nhược Điểm Của Giải Pháp

Tiêu chí đánh giá Ưu điểm nổi bật Nhược điểm cần lưu ý
Chi phí vận hành Cực kỳ tiết kiệm tài nguyên. Server rảnh rỗi tiêu thụ 0% CPU cho CI/CD. Không phù hợp nếu tần suất đẩy code (commit) diễn ra liên tục từng giây.
Quản lý và Bảo mật Kiến trúc Rootless của Podman cô lập hoàn toàn môi trường, giảm rủi ro tấn công. Đòi hỏi kỹ sư hệ thống phải hiểu sâu về hệ điều hành Linux và Systemd.
Khả năng di chuyển Pipeline viết bằng Go/Python có thể mang sang bất kỳ hạ tầng nào mà không cần sửa đổi. Cộng đồng hỗ trợ Quadlets còn tương đối mới so với Docker Compose truyền thống.
---

Kết Luận Và Xu Hướng Tương Lai

Xu hướng chuyển dịch từ các hệ thống CI/CD cồng kềnh, tiêu tốn tài nguyên sang kiến trúc Runnerless là tất yếu trong bối cảnh các doanh nghiệp đang tìm mọi cách để tối ưu hóa chi phí vận hành hạ tầng (Cloud FinOps). Việc kết hợp giữa tính linh hoạt của Dagger và khả năng quản lý dịch vụ gốc (native OS management) của Podman Quadlets mang lại một giải pháp mạnh mẽ, gọn nhẹ và có tính bảo mật cao.

Giải pháp này đặc biệt phù hợp cho các doanh nghiệp vừa và nhỏ (SMEs), các đội ngũ startup công nghệ, hoặc các dự án ưu tiên tính bảo mật dữ liệu nội bộ (On-premise) muốn sở hữu một hệ thống CI/CD đẳng cấp thế giới mà không cần phải chi trả những hóa đơn đắt đỏ cho các nhà cung cấp đám mây lớn.