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

Tối ưu hóa quy trình phát triển: Hướng dẫn triển khai Gitea và Gitea Actions làm giải pháp CI/CD thay thế GitHub Enterprise

1 tháng 6, 2026

Giới thiệu về xu hướng Self-hosting trong kỷ nguyên DevOps

Trong bối cảnh chuyển đổi số hiện nay, quản lý mã nguồn và tích hợp/triển khai liên tục (CI/CD) đã trở thành xương sống của mọi quy trình phát triển phần mềm. Tuy nhiên, khi quy mô doanh nghiệp mở rộng, việc phụ thuộc hoàn toàn vào các nền tảng SaaS như GitHub Enterprise thường đi kèm với những thách thức đáng kể về chi phí bản quyền theo người dùng và các rủi ro về quyền riêng tư dữ liệu.

Gitea nổi lên như một giải pháp thay thế hoàn hảo. Với đặc tính nhẹ, hiệu năng cao và khả năng tùy biến mạnh mẽ, Gitea không chỉ dừng lại ở việc lưu trữ Git mà còn cung cấp hệ thống Gitea Actions – một cơ chế CI/CD tương thích ngược với GitHub Actions, giúp đội ngũ kỹ thuật chuyển đổi mượt mà mà không cần thay đổi quá nhiều tư duy lập trình.

Tại sao chọn Gitea cho doanh nghiệp?

Trước khi đi sâu vào kỹ thuật, chúng ta cần hiểu tại sao Gitea lại là lựa chọn hàng đầu cho các hệ thống tự host:

  • Tiết kiệm tài nguyên: Viết bằng ngôn ngữ Go, Gitea có thể chạy mượt mà trên các máy chủ có cấu hình thấp, thậm chí là Raspberry Pi, trong khi vẫn đáp ứng hàng nghìn người dùng.
  • Tương thích cao: Gitea Actions sử dụng định dạng YAML tương tự GitHub Actions, cho phép tái sử dụng các workflow có sẵn.
  • Chủ quyền dữ liệu: Toàn bộ mã nguồn và lịch sử build nằm trong hạ tầng nội bộ của doanh nghiệp, đáp ứng các tiêu chuẩn khắt khe về bảo mật (ISO 27001, SOC2).

Bước 1: Chuẩn bị hạ tầng và Cài đặt Gitea

Để đảm bảo tính ổn định và dễ quản lý, phương pháp triển khai thông qua Docker Compose là lựa chọn tối ưu nhất cho môi trường doanh nghiệp.

Yêu cầu hệ thống tối thiểu:

  • CPU: 2 Cores
  • RAM: 4GB (để chạy tốt cả Gitea và Runner)
  • OS: Ubuntu 22.04 LTS hoặc tương đương
  • Docker và Docker Compose đã được cài đặt

Cấu hình Docker Compose

Tạo tệp docker-compose.yml với cấu hình bao gồm Gitea và cơ sở dữ liệu PostgreSQL:

version: "3"
services:
  server:
    image: gitea/gitea:latest
    container_name: gitea
    environment:
      - USER_UID=1000
      - USER_GID=1000
      - GITEA__database__DB_TYPE=postgres
      - GITEA__database__HOST=db:5432
    ports:
      - "3000:3000"
      - "222:22"
    depends_on:
      - db
  db:
    image: postgres:14
    restart: always
    environment:
      - POSTGRES_USER=gitea
      - POSTGRES_PASSWORD=gitea

Sau khi khởi chạy bằng lệnh docker-compose up -d, hãy truy cập vào cổng 3000 để hoàn tất các thiết lập ban đầu như cấu hình Domain, SSH Port và tài khoản Admin.

Bước 2: Kích hoạt và Cấu hình Gitea Actions

Mặc định, tính năng Actions trong Gitea có thể chưa được bật. Bạn cần chỉnh sửa tệp cấu hình app.ini (thường nằm trong thư mục data của Gitea):

  1. Tìm đến mục [actions].
  2. Thiết lập ENABLED = true.
  3. Khởi động lại container Gitea.

Lúc này, giao diện Gitea sẽ xuất hiện tab "Actions", nhưng bạn vẫn cần một Runner để thực thi các tác vụ build.

Bước 3: Triển khai Gitea Runner (act_runner)

Gitea sử dụng một thành phần gọi là act_runner để nhận lệnh từ server và chạy các job trong container. Đây là bước quan trọng nhất để thay thế GitHub Enterprise.

Lấy Registration Token

Truy cập vào Site Administration -> Actions -> Runners và nhấn Registration Token. Hãy lưu lại mã này để sử dụng trong bước tiếp theo.

Cài đặt Runner qua Docker

Chúng ta sẽ thêm một service mới vào tệp Docker Compose để chạy Runner:

  runner:
    image: gitea/act_runner:latest
    environment:
      - GITEA_INSTANCE_URL=http://gitea:3000
      - GITEA_RUNNER_REGISTRATION_TOKEN=
      - GITEA_RUNNER_NAME=company-runner
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock

Việc gắn docker.sock cho phép Runner khởi tạo các container phụ để thực hiện quá trình build, test và deploy một cách độc lập.

Bước 4: Viết Workflow CI/CD đầu tiên

Cấu trúc thư mục workflow của Gitea hoàn toàn giống với GitHub. Bạn cần tạo tệp tại đường dẫn .gitea/workflows/deploy.yaml trong repository của mình.

Dưới đây là một ví dụ về workflow tự động kiểm tra mã nguồn (linting) và build Docker image:

name: Gitea CI Example
on: [push]
jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3
      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'
      - name: Install dependencies
        run: npm install
      - name: Run Tests
        run: npm test

Lưu ý quan trọng: Vì chúng ta đang chạy trong môi trường tự host, bạn có thể cấu hình Labels cho Runner (ví dụ: `ubuntu-latest`, `self-hosted`) để điều phối công việc đến đúng máy chủ có cấu hình mong muốn.

Tối ưu hóa bảo mật cho hệ thống CI/CD nội bộ

Khi tự vận hành hệ thống, trách nhiệm bảo mật thuộc về đội ngũ vận hành. Hãy lưu ý các điểm sau:

  • Sử dụng Reverse Proxy: Luôn đặt Gitea sau Nginx hoặc Traefik với cấu hình SSL/TLS (Let's Encrypt) để mã hóa dữ liệu truyền tải.
  • Quản lý Secret: Sử dụng tính năng Actions Secrets để lưu trữ API Key, mật khẩu database thay vì để trực tiếp trong mã nguồn.
  • Cô lập Runner: Nếu có thể, hãy chạy Runner trên các máy ảo (VM) riêng biệt với máy chủ chứa mã nguồn để tránh rủi ro leo thang đặc quyền qua Docker socket.

Kết luận và Lời khuyên cho doanh nghiệp

Việc chuyển đổi từ GitHub Enterprise sang Gitea và Gitea Actions là một bước đi chiến lược giúp doanh nghiệp tối ưu hóa chi phí vận hành và nâng cao năng lực tự chủ công nghệ. Mặc dù đòi hỏi nỗ lực thiết lập ban đầu, nhưng sự linh hoạt và quyền kiểm soát tuyệt đối mà nó mang lại là hoàn toàn xứng đáng.

Để bắt đầu, hãy triển khai thử nghiệm (PoC) cho một dự án nhỏ trước khi mở rộng ra toàn bộ tổ chức. Chúc các bạn xây dựng được một hệ thống CI/CD mạnh mẽ và hiệu quả!

Tối ưu hóa quy trình phát triển: Hướng dẫn triển khai Gitea và Gitea Actions làm giải pháp CI/CD thay thế GitHub Enterprise | DPTCloud