Ngày nào tôi cũng dùng cả hai. Ollama chạy trên laptop của tôi và trên máy trạm có GPU ở văn phòng, phục vụ việc phát triển và mấy công cụ tôi tự làm cho mình. Còn vLLM thì phục vụ một mô hình chat cho một dự án freelance, trên một GPU 96 GB duy nhất, lúc đầu chạy bằng Docker Compose và bây giờ chạy trong một cụm Kubernetes nhỏ.

So sánh nhanh vLLM và Ollama

#

Ollama là gì

#

Trong những cách tôi biết, Ollama là cách dễ nhất để có một mô hình trả lời được ngay trên máy của bạn. Nó được xây trên nền llama.cpp và chạy các mô hình GGUF đã lượng tử hóa, vì vậy một mô hình 8B chỉ chiếm khoảng 5 GB và chạy thoải mái trên một chiếc MacBook. Bạn tải mô hình về theo tên, mô hình được nạp vào bộ nhớ ở lần gọi đầu tiên, và sau năm phút không có việc gì làm thì nó tự rời khỏi bộ nhớ. Nhờ vậy, Ollama chia sẻ máy một cách lịch sự với mọi thứ khác bạn đang chạy.

Nhưng chính sự lịch sự đó cũng là cái giá phải trả. Ollama được thiết kế xoay quanh việc phục vụ từng người một. Mặc định nó chỉ xử lý mỗi lần một yêu cầu; OLLAMA_NUM_PARALLEL cho thêm khe xử lý, nhưng mỗi khe tốn trọn một ngữ cảnh bộ nhớ, và ngay từ đầu nó không được làm ra để gộp hàng chục người dùng lên cùng một GPU.

vLLM là gì

#

vLLM là một engine phục vụ mô hình (serving engine), và nó được làm ra chính là để gộp lô như vậy. Phần lớn sức mạnh của nó đến từ hai ý tưởng. Thứ nhất là PagedAttention: nó lưu KV cache của mỗi yêu cầu (bộ nhớ đệm chứa trạng thái attention mà mô hình tích lũy dần trong lúc đọc và sinh token) thành những khối nhỏ có kích thước cố định, nhờ đó bộ nhớ GPU không bị hao phí vì phần đệm (padding) và phân mảnh. Thứ hai là gộp lô liên tục: yêu cầu mới được đưa vào lô giữa các bước sinh token, thay vì phải chờ lô hiện tại chạy xong. Kết hợp hai ý tưởng này, một GPU chạy vLLM phục vụ được số người dùng đồng thời nhiều hơn hẳn so với chính GPU đó khi xử lý lần lượt từng yêu cầu một. Tôi chưa tự đo hai bên với nhau, nên bài này không có con số thông lượng (throughput) của riêng mình. Phiên bản đo thực tế của nhận định này là bài benchmark Ollama vs. vLLM của Red Hat: một card A100 chạy Llama 3.1 8B với 1 đến 256 người dùng đồng thời, dù đã nâng OLLAMA_NUM_PARALLEL lên 32, vLLM vẫn đạt đỉnh khoảng 793 token đầu ra mỗi giây còn Ollama là 41.

Cái giá phải trả là vLLM cư xử như thể nó là chủ của cả card GPU. Vừa khởi động, nó đã chiếm phần bộ nhớ GPU dành cho mình, dùng toàn bộ phần mà trọng số mô hình không cần đến để làm KV cache, và giữ hết chỗ đó dù có ai gọi tới hay không. Nó cũng đòi trọng số đầy đủ từ Hugging Face, hoặc một kiểu lượng tử hóa thân thiện với GPU như FP8 hay AWQ. Nó nạp được tệp GGUF, nhưng tài liệu của chính vLLM gọi phần hỗ trợ đó là “highly experimental and under-optimized”, nên đừng tính chuyện dùng lại các tệp đã tải bằng Ollama.

Cần bao nhiêu bộ nhớ GPU

#

Kích thước ước tính, chỉ tính riêng phần trọng số:

Tức là khoảng 2 byte cho mỗi tham số ở 16-bit, 1 byte ở 8-bit, và hơn nửa byte một chút ở Q4_K_M. Cộng thêm vào phần trọng số là KV cache, thứ tăng theo độ dài ngữ cảnh và theo số yêu cầu đang được xử lý cùng lúc. Chính yếu tố sau, tức số yêu cầu chạy cùng lúc, là lý do cùng một mô hình lại cần nhiều bộ nhớ hơn hẳn khi chạy trên vLLM phục vụ năm mươi người dùng, so với khi chạy trên Ollama chỉ phục vụ mình bạn.

Một API, hai máy chủ

#

Vì cả hai đều cung cấp API chat completions của OpenAI, code của tôi không cần biết nó đang nói chuyện với bên nào. URL và tên mô hình được lấy từ biến môi trường:

import os
from openai import OpenAI

# Laptop:      LLM_URL=http://localhost:11434/v1  LLM_MODEL=qwen3:8b
# Máy chủ GPU: LLM_URL=http://localhost:8000/v1   LLM_MODEL=qwen3-8b
client = OpenAI(base_url=os.environ["LLM_URL"], api_key="not-needed")

reply = client.chat.completions.create(
    model=os.environ["LLM_MODEL"],
    messages=[{"role": "user", "content": "Say hello in Korean."}],
)
print(reply.choices[0].message.content)

Trên laptop, vốn không có GPU mạnh, ứng dụng trỏ tới Ollama. Trên máy chủ thì nó trỏ tới vLLM. Ngoài hai biến đó ra không có gì thay đổi, và tôi có thể phát triển ứng dụng mà không cần bật máy GPU lên chút nào. Ở phía vLLM, --served-model-name đặt cho mô hình một cái tên ngắn, để client không phải gửi nguyên đường dẫn Hugging Face đầy đủ.

Có một điều cần lưu ý, vì rất dễ quên: cùng một mô hình nhưng chạy trên hai bên sẽ không cho ra cùng câu trả lời. qwen3:8b của Ollama là bản lượng tử hóa 4-bit, trong khi trên vLLM bạn thường chạy trọng số 16-bit hoặc FP8. Một prompt đã được tinh chỉnh trên bên này có thể cư xử khác trên bên kia, nên bất cứ thứ gì bạn đang đo, dù là chất lượng câu trả lời, việc mô hình có từ chối trả lời hay không, hay JSON có parse được không, đều phải được kiểm tra trên đúng máy chủ mà môi trường production sẽ thật sự dùng.

Cách cài đặt Ollama

#

Trên Mac hoặc Windows, hãy tải ứng dụng về từ ollama.com. Trên Linux thì chạy:

curl -fsSL https://ollama.com/install.sh | sh
ollama run qwen3:8b

Thế là xong. API giờ đã có ở http://localhost:11434. Nó chỉ lắng nghe trên localhost, trừ khi bạn đặt OLLAMA_HOST, và như thế là đúng điều bạn muốn. Ollama của tôi chạy trên máy trạm ở văn phòng, bind vào 127.0.0.1, và tôi truy cập nó từ bất cứ đâu qua một đường hầm (cách tôi thiết lập việc đó bằng Cloudflare WARP).

Cách cài đặt vLLM

#

Trên Linux, với GPU NVIDIA và driver đời mới:

python -m venv .venv && source .venv/bin/activate
pip install vllm
vllm serve Qwen/Qwen3-8B --served-model-name qwen3-8b --max-model-len 16384

Lần chạy đầu tiên sẽ tải trọng số mô hình về từ Hugging Face. Khi log hiện dòng Application startup complete, lệnh curl localhost:8000/v1/models sẽ liệt kê mô hình, và đoạn Python ở trên chạy được với nó.

Chạy vLLM bằng Docker

#

Với bất cứ thứ gì phải chạy liên tục, tôi dùng image chính thức thay vì cài bằng pip, chủ yếu để CUDA, PyTorch và vLLM đi kèm nhau với phiên bản đã được ghim cố định. Dưới đây là một service Compose dạng chung chung:

services:
  vllm:
    image: vllm/vllm-openai:v0.30.0   # tag tôi đã chạy; hãy ghim bản mới nhất hiện có. Image nặng khoảng 30 GB
    restart: unless-stopped
    ipc: host                          # PyTorch cần bộ nhớ dùng chung (shared memory)
    command: >
      --model Qwen/Qwen3-8B
      --served-model-name qwen3-8b
      --gpu-memory-utilization 0.85
      --max-model-len 16384
    volumes:
      - ${HOME}/.cache/huggingface:/root/.cache/huggingface
    ports:
      - "127.0.0.1:8000:8000"          # truy cập qua ssh -L, không qua mạng LAN
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
    healthcheck:
      test: ["CMD", "python3", "-c", "import urllib.request; urllib.request.urlopen('http://localhost:8000/health')"]
      interval: 10s
      timeout: 5s
      retries: 90
      start_period: 120s

Hãy ghim tag. vLLM thay đổi rất nhanh, các cờ (flag) và giá trị mặc định thay đổi giữa các bản phát hành, và bạn muốn chính mình là người quyết định khi nào những thay đổi đó xảy ra. ipc: host (hoặc một shm_size thật rộng rãi) có sẵn trong hướng dẫn Docker của chính vLLM. Còn lý do start_period dài như vậy chính là điều đầu tiên trong phần tiếp theo.

Những chỗ khiến tôi vấp khi chạy vLLM

#

Khởi động mất vài phút

#

Nạp trọng số, biên dịch và ghi lại (capture) các CUDA graph mất 190 giây trên máy chủ của tôi, và với một mô hình lớn thì ba đến năm phút là chuyện bình thường. Một bài kiểm tra sức khỏe (health check) viết theo kiểu dành cho ứng dụng web sẽ giết nó trước khi nó kịp sẵn sàng. Trong Compose, điều đó có nghĩa là cần một start_period dài; trong Kubernetes thì cần một startup probe. Nó cũng có nghĩa là mỗi lần khởi động lại là vài phút không có mô hình nào phục vụ, nên đừng khởi động lại một cách tùy tiện.

Bạn cho bao nhiêu bộ nhớ GPU, nó lấy bấy nhiêu, ngay từ lúc khởi động

#

--gpu-memory-utilization là tỉ lệ bộ nhớ trên card mà vLLM được phép dùng, ở các bản gần đây mặc định là 0.92, và toàn bộ phần mà trọng số không cần đến sẽ trở thành KV cache. Như vậy không sao nếu vLLM chạy một mình trên card. Card của tôi thì không như vậy, vì có mấy mô hình nhỏ hơn chạy bên cạnh, nên tôi đặt 0.70 trên card 96 GB. Mô hình của tôi, một mô hình hỗn hợp chuyên gia (mixture-of-experts) 35B ở định dạng FP8, chiếm 47.7 GiB khi nạp xong và để lại 15 GiB cho KV cache, quá đủ cho độ dài ngữ cảnh (context) 16k. Nếu vLLM từ chối khởi động vì độ dài chuỗi tối đa không vừa trong KV cache, hãy giảm --max-model-len trước khi đi tìm một GPU lớn hơn.

Mỗi chỗ dành cho LoRA đều tốn bộ nhớ ngay từ đầu

#

vLLM có thể phục vụ một mô hình gốc (base model) kèm nhiều LoRA adapter và chuyển qua lại giữa chúng theo từng yêu cầu, dựa vào tên mô hình, điều mà Ollama gần như không làm được. Nhưng lúc khởi động, nó giữ sẵn chỗ cho số adapter bằng --max-loras, mỗi adapter ở rank bằng --max-lora-rank, và trên một mô hình mixture-of-experts thì phần giữ chỗ đó bao gồm cả các expert, nên con số cộng dồn rất nhanh. Bốn adapter ở rank 64 không vừa khi đặt 0.70. Hai adapter thì vừa.

Giới hạn số chuỗi mặc định không hợp với mô hình lai

#

Mô hình tôi đang phục vụ trộn các lớp kiểu Mamba vào giữa các lớp attention, và mỗi chuỗi (sequence) cần một khối bộ nhớ đệm riêng cho những lớp đó. Giá trị --max-num-seqs mặc định của vLLM là 1024 trên card từ 70 GB trở lên (256 với card nhỏ hơn), nên trên card đó nó không khởi động được; đặt --max-num-seqs 256 là hết lỗi. Nếu một kiến trúc mô hình mới hơn không chịu khởi động, hãy kiểm tra cờ này trước khi nghĩ tới những nguyên nhân cao siêu hơn.

Một Service Kubernetes tên vllm làm vLLM sập

#

Đây là vụ tôi khoái nhất. Kubernetes tự chèn biến môi trường cho mọi Service trong cùng namespace, đặt tên theo tên Service, nên một Service tên vllm sẽ đưa cho mọi pod biến VLLM_PORT=tcp://<cluster-ip>:8000. vLLM đọc VLLM_PORT như một thiết lập của chính nó, không hiểu nổi một URL nằm ở đó, và chết. Dĩ nhiên là chết sau khi đã nạp xong toàn bộ mô hình, nên mỗi lần thử tốn ba phút. Tài liệu của vLLM có cảnh báo chuyện này, nhưng tôi chỉ đọc thấy sau khi đã dính. Cách sửa là đặt enableServiceLinks: false trên pod, hoặc đặt cho Service một cái tên khác.

Dưới đây là khung của một Deployment chạy được, đã lược bớt chỉ còn những phần quan trọng:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm
spec:
  replicas: 1
  strategy:
    type: Recreate               # pod cũ phải giải phóng GPU trước
  selector:
    matchLabels: {app: vllm}
  template:
    metadata:
      labels: {app: vllm}
    spec:
      enableServiceLinks: false  # không nhận VLLM_PORT=tcp://... từ Service
      containers:
        - name: vllm
          image: vllm/vllm-openai:v0.30.0
          args: ["--model=Qwen/Qwen3-8B", "--served-model-name=qwen3-8b"]
          resources:
            limits:
              nvidia.com/gpu: "1"
              memory: 32Gi       # lúc nạp cần nhiều RAM máy host hơn hẳn lúc phục vụ
          volumeMounts:
            - {name: shm, mountPath: /dev/shm}
          startupProbe:          # đừng phán xét trước khi mô hình nạp xong
            httpGet: {path: /health, port: 8000}
            initialDelaySeconds: 120
            periodSeconds: 10
            failureThreshold: 90
          livenessProbe:         # khởi động lại là nạp lại từ đầu, nên hãy kiên nhẫn
            httpGet: {path: /health, port: 8000}
            periodSeconds: 30
            timeoutSeconds: 5
            failureThreshold: 10
      volumes:
        - name: shm
          emptyDir: {medium: Memory, sizeLimit: 16Gi}

Phần đáng sao chép nhất là các probe. Startup probe chờ hai phút, rồi cho mô hình thêm mười lăm phút nữa để khởi động xong, trước khi Kubernetes coi nó là đã chết. Liveness probe chỉ khởi động lại pod sau khoảng năm phút thất bại liên tục, vì /health có thể phản hồi chậm khi engine đang bận, và dù sao thì mỗi lần khởi động lại cũng tốn một lần nạp lại toàn bộ. Recreate rất quan trọng khi chỉ có một GPU: cập nhật cuốn chiếu (rolling update) sẽ khởi động pod mới trước, và pod đó cứ nằm chờ một GPU mà pod cũ vẫn đang giữ. Giới hạn bộ nhớ trông có vẻ hào phóng, vì nó đúng là hào phóng thật; khi trọng số đã nằm trên GPU, pod của tôi ổn định ở khoảng 7 GiB RAM của máy host, nhưng riêng quá trình nạp thì cần nhiều hơn thế rất nhiều.

Những điều nên biết về Ollama

#

Với Ollama thì ít bất ngờ hơn, chủ yếu là vì nó làm ít việc hơn.

Yêu cầu đầu tiên sau một khoảng thời gian không ai dùng sẽ chậm, vì mô hình đã bị gỡ khỏi bộ nhớ và phải nạp lại. OLLAMA_KEEP_ALIVE quy định một mô hình được giữ trong bộ nhớ bao lâu sau yêu cầu cuối cùng; hãy tăng giá trị này lên nếu khoảng chờ đó làm bạn khó chịu, hoặc đặt thành -1 trên một máy không làm việc gì khác.

Cửa sổ ngữ cảnh (context window) phụ thuộc vào lượng bộ nhớ GPU bạn có. Dưới 24 GiB, Ollama mặc định chỉ dùng 4k token, ít hơn nhiều so với mức mà phần lớn mô hình hỗ trợ, và một prompt không vừa sẽ bị cắt bớt một cách lặng lẽ chứ không bị từ chối. Nếu câu trả lời có vẻ phớt lờ phần đầu của một prompt dài, hãy đặt OLLAMA_CONTEXT_LENGTH (hoặc num_ctx cho từng yêu cầu) bằng đúng mức bạn thật sự cần.

Nếu bạn chuyển tiếp (forward) một Ollama ở máy từ xa về laptop, đừng đặt nó ở cổng 11434. Đó là cổng mặc định của Ollama, và nếu có lúc một Ollama cục bộ trên laptop khởi động, hai bên sẽ tranh nhau cổng đó, và bạn có thể nói chuyện nhầm với bên kia mà không hề hay biết. Tôi chuyển tiếp Ollama của mình về cổng 11435.

Và Ollama không phải là máy chủ cho nhiều người dùng. Dùng cho một công cụ nội bộ chỉ vài người sử dụng thì ổn; khi lượng truy cập đồng thời thật sự xuất hiện, đó là lúc nên chuyển sang vLLM.

Nên dùng cái nào

#

Nếu bạn chỉ muốn có một mô hình chạy trên máy của chính mình, hãy cài Ollama và dừng ở đó; trong vòng mười phút là bạn đã có thứ trả lời được. Nếu bạn có một máy chủ GPU, cùng với người dùng hoặc một ứng dụng sẽ gọi tới nó suốt cả ngày, hãy dùng vLLM, chấp nhận việc nó khởi động chậm và chiếm nhiều bộ nhớ, rồi cấu hình các probe cho đúng. Rất nhiều hệ thống cuối cùng dùng cả hai, hệ thống của tôi cũng vậy: Ollama ở nơi viết code, vLLM ở nơi các yêu cầu đổ về.

Ngoài hai cái này vẫn còn những lựa chọn khác. SGLang là phương án thay thế vLLM mà người ta hay nhắc tới, nhưng tôi chưa chạy nó trên production, nên tôi để nó ra ngoài bài này thay vì đoán mò. Còn nếu mô hình phải chạy trên điện thoại thì lại quay về llama.cpp, như tôi đã viết trong bài chạy LLM ngay trên thiết bị với React Native.

Nếu bạn vào đây để tìm cách chạy Docker Compose trong GitHub Actions: tôi đã làm thế suốt hai năm rồi bỏ. Giờ CI khai báo cùng các image Postgres và Valkey đó dưới dạng services: và chạy thẳng trên runner đúng các lệnh uv run … và npm run …; Compose quay về làm thứ lập trình viên chạy ở máy mình. Phần còn lại là lý do, kèm các tệp.

Năm 2024 tôi có viết bài Dùng Docker Compose cho CI/CD thay vì YAML riêng của từng nền tảng, với ý chính là để logic dựng trong Compose, còn công cụ CI chỉ việc gọi nó. Hai năm sau, tôi xem lại toàn bộ các kho mã mà tôi đang dùng để phát hành. Có bốn kho có workflow, kho nào cũng chỉ có một người commit là tôi, và trong số các workflow đó không còn cái nào gọi docker compose nữa. Nguyên tắc thì vẫn đứng vững, còn cách làm thì không. Dưới đây là những thứ đã thay thế nó: phiên bản ví dụ đã cắt gọn của các tệp, thời gian từng bước mà GitHub ghi lại, và cả những phần ít tự động hơn so với mong đợi của mấy sơ đồ CI/CD.

Mọi quy trình tôi đang chạy, gói trong một bảng

#

Nói theo sách vở thì hai trang Hugo là triển khai liên tục, còn ứng dụng kia (một ứng dụng chợ kiêm cộng đồng mà tôi đang làm) là tích hợp liên tục cộng với phát hành bằng đúng một lệnh, tức là chuyển giao liên tục: phần kiểm tra báo cho tôi biết khi có gì sai, nhưng không chặn tôi triển khai. Tôi cố ý chia như vậy. Một bản cập nhật OTA sẽ đến mọi điện thoại đang dùng phiên bản ứng dụng mà nó nhắm tới, nên việc phát hành phải là một quyết định, chứ không phải tác dụng phụ của một lần merge. Còn API là nơi chạy migration cơ sở dữ liệu. Hai ứng dụng Django còn lại của tôi thì hoàn toàn không có workflow nào.

Phần CI: một workflow, hai job

#

Toàn bộ CI của ứng dụng nằm trong một tệp, .github/workflows/checks.yml. Trước ngày 11 tháng 10, ngay cả tệp này cũng chưa có. Đây là một ví dụ đã cắt gọn cho thấy hình dạng của nó:

# Lint, types and tests on every push and pull request to main.
# Nothing here deploys.
name: Checks

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

concurrency:
  group: checks-${{ github.ref }}
  cancel-in-progress: true

jobs:
  python:
    runs-on: ubuntu-latest
    timeout-minutes: 30
    services:
      postgres:
        image: postgres:17
        env:
          POSTGRES_USER: myapp
          POSTGRES_PASSWORD: myapp
          POSTGRES_DB: myapp
        ports: ["5432:5432"]
        options: >-
          --health-cmd "pg_isready -U myapp"
          --health-interval 5s --health-timeout 5s --health-retries 20
      valkey:
        image: valkey/valkey:8-alpine
        ports: ["6379:6379"]
    env:
      DEBUG: "True"
      DATABASE_URL: postgresql://myapp:myapp@localhost:5432/myapp
      REDIS_URL: redis://localhost:6379
      PYTHON_JIT: "0"   # match production
    steps:
      - uses: actions/checkout@v7
      - uses: astral-sh/setup-uv@v10
        with:
          enable-cache: true
          prune-cache: true
      - run: uv sync --locked
      - run: uv run ruff check .
      - run: uv run mypy myapp/
      - run: uv run python manage.py test --parallel 4 --noinput

  app:
    runs-on: ubuntu-latest
    timeout-minutes: 20
    defaults:
      run:
        working-directory: frontend
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 24
          cache: npm
          cache-dependency-path: frontend/package-lock.json
      - run: npm ci
      # Expo writes this on `expo start` and it is gitignored,
      # so a fresh checkout doesn't have it.
      - run: printf '/// <reference types="expo/types" />\n' > expo-env.d.ts
      - run: npm run typecheck
      - run: npx jest --ci

Hai job chạy song song. Trong 35 lần chạy thành công tính đến giờ, trung vị của job ứng dụng là khoảng bảy phút, còn job Python là khoảng mười hai phút rưỡi.

Khối services: chính là chỗ tệp Compose đã chuyển tới, phần sau sẽ nói rõ. Môi trường chỉ có vài biến và một cờ. Mọi thứ còn lại đều rơi về giá trị mặc định cho môi trường phát triển mà lập trình viên có được khi chạy docker compose up, nên bộ kiểm thử không cần bí mật (secret) nào. Để chắc chắn, tôi đã chạy thử một phần bộ kiểm thử với đúng môi trường đó và không có gì khác.

CI chạy cùng trình thông dịch với laptop của tôi và với image production, tức là bản Python 3.15.0 do chính uv dựng, vì uv sync đọc .python-version và tải về đúng bản đó. (Tệp thật của tôi còn truyền cho setup-uv một tham số python-version-file, thật ra chẳng làm gì cả: setup-uv v6 không có tham số nào như vậy, và lần chạy nào cũng kèm một cảnh báo nói đúng điều đó. Viết bài này tôi mới để ý.)

Việc dùng chung trình thông dịch đã chứng minh giá trị chỉ tám ngày sau khi workflow ra đời. Ngày 19 tháng 10, tôi bật trình biên dịch JIT của 3.15, và ngay lần chạy đầu tiên có JIT, một bài kiểm thử đã thất bại: một câu yield from rất bình thường, nằm trên đoạn code mà lần lưu dữ liệu nào của ứng dụng cũng đi qua, lại ném ra AttributeError: 'list' object has no attribute 'send'. Cùng commit đó mà tắt JIT thì qua. Máy Mac của tôi là arm64 nên chưa bao giờ gặp lỗi này; còn máy chạy CI (runner) là x86_64, giống các máy production. JIT giờ đã được tắt lại, cả trong CI lẫn trong Dockerfile, và lỗi này chưa bao giờ lọt lên production. Đó là lỗi python/cpython#155823, đã được sửa ở upstream vào ngày 13 tháng 10, sau khi 3.15.0 phát hành.

Thật ra ngay lần chạy đầu tiên cũng đã thất bại, nhưng vì một lý do tẻ nhạt hơn. Expo tạo tệp expo-env.d.ts khi bạn chạy expo start, mà tệp này lại nằm trong gitignore. Vì vậy bản làm việc nào tôi từng dùng cũng có nó, còn một bản checkout mới tinh thì không. TypeScript báo năm lỗi chưa từng xuất hiện trên máy tôi. Bước tạo tệp đó chính là cách sửa.

concurrency sẽ hủy lần chạy cũ khi có một lần push mới hơn lên cùng nhánh. Cả mười hai lần chạy bị hủy tính đến giờ đều kết thúc theo cách này. Một hook trước commit (pre-commit) chạy công cụ lint, và chạy thêm bộ kiểm tra kiểu khi có tệp Python hoặc TypeScript được stage, nên phần lớn lỗi không đi được tới lúc push.

Tệp Docker Compose đã đi đâu

#

Đây là phần trong tệp docker-compose.yml của ứng dụng mà CI quan tâm, viết lại dưới dạng ví dụ. Tệp thật còn nhiều dịch vụ hơn và nhiều biến môi trường hơn hẳn.

services:
  valkey:
    image: valkey/valkey:8-alpine
    ports:
      - "6379:6379"

  # Host port 55432, not 5432, so it can't collide with a local Postgres.
  postgres:
    image: postgres:17-alpine
    environment:
      - POSTGRES_USER=myapp
      - POSTGRES_PASSWORD=myapp
      - POSTGRES_DB=myapp
    ports:
      - "55432:5432"
    volumes:
      - postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U myapp -d myapp"]
      interval: 5s
      retries: 10

  api:
    build: .
    command: python manage.py runserver 0.0.0.0:8000
    volumes:
      - .:/app
    ports:
      - "8000:8000"
    environment:
      - DATABASE_URL=postgresql://myapp:myapp@postgres:5432/myapp
      - REDIS_URL=redis://valkey:6379
    depends_on:
      postgres:
        condition: service_healthy
      valkey:
        condition: service_started

volumes:
  postgres_data:

Đặt nó cạnh khối services: trong checks.yml thì thấy đó là cùng hai image: Postgres 17 (ở đây là bản Alpine, trong CI là bản Debian) và valkey/valkey:8-alpine. Quan hệ giữa hai bên bây giờ là vậy. Tệp Compose là thứ lập trình viên chạy; còn CI khai báo cùng các image đó dưới dạng service container, rồi chạy thẳng trên runner đúng những lệnh mà lập trình viên vẫn chạy, uv run … và npm run ….

So với bài năm 2024, phần tôi quan tâm nhất vẫn đứng vững: công cụ CI vẫn mỏng, và các bước kiểm tra lẫn triển khai đều là những lệnh tôi tự chạy được. Thứ không trụ lại được là để CI gọi Compose.

CI của ứng dụng hoàn toàn không dựng Docker image. Image được dựng đúng một lần, lúc triển khai, trên máy dựng (builder) của Fly, còn CI chỉ cần trả lời code có ổn không, và khi bộ công cụ đã có sẵn trong bộ nhớ đệm (cache) thì việc đó chỉ tốn sáu giây cài đặt. Ngoài ra, tệp Compose còn bind-mount bản làm việc và nạp dữ liệu mẫu, những việc một lần chạy kiểm thử không nên làm. Vậy nên CI sẽ cần một tệp Compose riêng, tức là một bản mô tả thứ hai cho cùng các dịch vụ, phải giữ cho khớp nhau bằng tay.

Thêm nữa, ví dụ năm 2024 có một lỗi mà lúc đó tôi không để ý. docker compose build chỉ dựng image, chứ không bao giờ chạy command của dịch vụ. Thế nên lệnh npm test trong tệp đó chưa từng chạy trong CI, và workflow vẫn xanh dù kiểm thử có qua hay không.

Rủi ro mà bài đó lo nhất, tức là đổi nhà cung cấp CI, rốt cuộc chưa bao giờ xảy ra. Cuộc chuyển dịch thật sự lại diễn ra ở đầu bên kia: blog này và trang của khách hàng kia đã đổi nơi lưu trữ sang Cloudflare Pages, và với blog thì chỉ cần viết mới một workflow dài 45 dòng, vì khâu dựng vốn đã chỉ là một lệnh. Còn cái workflow ba trăm dòng mà tôi từng cảnh báo? Tôi có đúng một cái, của pyhtml2text. Nó dài vì wheel phải được dựng trên runner Linux, macOS và Windows, mỗi loại cho nhiều kiến trúc, và cũng vì vậy mà đây là việc duy nhất mà YAML riêng của nền tảng là công cụ đúng.

Bộ nhớ đệm: đọc thời gian từng bước trước đã

#

GitHub ghi lại thời gian của từng bước, và gh api repos/<owner>/<repo>/actions/runs/<run-id>/jobs sẽ trả về cho bạn. Đây là số liệu từ lần chạy thành công gần nhất của ứng dụng, ngày 20 tháng 10:

Cả hai bộ nhớ đệm cho thư viện phụ thuộc đều đang bật, và cả hai đều là phần rẻ. Bộ nhớ đệm uv mà GitHub giữ cho kho này chỉ khoảng 200 KB, vì setup-uv dọn đi những gì uv chỉ cần tải lại là xong; còn của npm thì gần 400 MB. Thời gian nằm ở bộ kiểm thử, mà bộ kiểm thử thì đã chạy song song bốn luồng rồi. Muốn chạy nhanh hơn, tôi sẽ sửa bộ kiểm thử chứ không phải bộ nhớ đệm.

Blog thì ngược lại. Ảnh đã được Hugo xử lý nằm trong thư mục resources/_gen vốn bị gitignore, nên runner mới nào cũng phải mã hóa lại toàn bộ ảnh bìa, ảnh trong bài và ảnh giữ chỗ. Workflow ở phía dưới khôi phục chúng bằng actions/cache, với khóa là mã băm của chính các bức ảnh; nếu khóa không khớp thì dùng bản cache cũ mới nhất, vì Hugo chỉ xử lý phần còn thiếu. Trong tám lần chạy cuối cùng trước khi có cache, bước dựng mất từ 33 đến 76 giây; trong 26 lần kể từ đó là 6 đến 20 giây, chỉ một lần ngoại lệ là 94 giây, dù chính commit đó còn thêm ảnh giữ chỗ và một cỡ thẻ thứ hai.

Image của ứng dụng được dựng trên builder của Fly: các tệp khai báo thư viện phụ thuộc được chép vào trước code, còn bộ nhớ đệm tải về của uv nằm trong một cache mount của BuildKit (RUN --mount=type=cache,target=/root/.cache/uv). Nhưng cải thiện lớn nhất ở đây lại không phải là bộ nhớ đệm. Tệp .dockerignore cũ là danh sách chặn (blocklist), và nó bỏ sót một thư mục chứa các git worktree phụ, mỗi worktree lại có thư viện phụ thuộc và sản phẩm dựng của riêng nó. Kết quả là 7,7 GB với 277.000 tệp bị đẩy lên builder mỗi lần triển khai. Viết lại thành danh sách cho phép (allowlist), ngữ cảnh dựng giờ chỉ còn khoảng 40 MB. Một ví dụ cho cách làm này:

# Exclude everything, then let back in only what the Dockerfile COPYs.
*

!pyproject.toml
!uv.lock
!manage.py
!myapp
!static

# Rules match the whole relative path and the last match wins,
# so these re-excludes apply inside the allowed directories too.
**/__pycache__/
**/*.pyc
**/.DS_Store
**/*.log

Bí mật, đặt ở càng ít chỗ càng tốt

#

Bí mật nằm ở ba nơi. Bí mật của GitHub Actions dành cho những việc workflow làm, và hai kho Hugo mỗi kho chỉ có đúng một cái, CLOUDFLARE_API_TOKEN. Bí mật của Fly là cấu hình lúc chạy của ứng dụng, được đặt bằng flyctl secrets set, và không bao giờ đi qua Actions. Cuối cùng là tệp .env bị gitignore trên laptop của tôi, chứa token mà script triển khai dùng để xóa cache của Cloudflare.

PyPI thì hoàn toàn không cần bí mật. pyhtml2text dùng cơ chế trusted publishing: PyPI chấp nhận token OIDC ngắn hạn mà GitHub cấp cho workflow, nên job phát hành chỉ xin quyền id-token: write, và trang bí mật của kho thì trống trơn. Không có gì để rò rỉ, cũng không có gì phải xoay vòng.

Token chỉ được cấp đúng quyền cần thiết. Token Fly của ứng dụng trên GitHub phục vụ một bước kiểm tra định kỳ chỉ liệt kê máy, nên nó được tạo bằng fly tokens create readonly. Các lần triển khai lên Pages chỉ xin contents: read và deployments: write, không hơn.

Dữ liệu đầu vào luôn đi qua env:, không bao giờ nhét thẳng vào script. Workflow OTA nhận ghi chú phát hành dạng văn bản tự do. Nếu viết ${{ inputs.notes }} ngay trong run:, đoạn văn bản sẽ được dán thẳng vào script trước khi bash đọc, nên một ghi chú có dấu nháy và dấu chấm phẩy sẽ biến thành code. Truyền qua biến môi trường thì nó vẫn chỉ là dữ liệu. Một ví dụ cho cách làm này:

      - name: Publish
        env:
          OTA_API_TOKEN: ${{ secrets.OTA_API_TOKEN }}
          INPUT_PLATFORM: ${{ inputs.platform }}
          INPUT_ROLLOUT: ${{ inputs.rollout }}
          INPUT_NOTES: ${{ inputs.notes }}
        run: |
          args=("$INPUT_PLATFORM")
          [ -n "$INPUT_ROLLOUT" ] && args+=(--rollout "$INPUT_ROLLOUT")
          [ -n "$INPUT_NOTES" ] && args+=(--notes "$INPUT_NOTES")
          ./scripts/publish-ota.sh "${args[@]}"

Có những khóa tôi để hẳn bên ngoài GitHub. Một bản báo cáo định kỳ cần một khóa có quyền quản trị phần đăng nhập của ứng dụng, nên nó đã chuyển từ một workflow định kỳ sang một tác vụ định kỳ trên máy Mac của tôi. Workflow vẫn còn đó làm phương án dự phòng chạy tay, và bỏ qua những mục cần đến khóa đó.

Triển khai: mỗi lần push, bằng script, và theo tag

#

Các trang Hugo được triển khai mỗi lần push

#

Đây là phiên bản ví dụ của workflow cho blog, đã lược bỏ bước tạo dự án Pages ở lần chạy đầu tiên:

name: Deploy to Cloudflare Pages

on:
  push:
  workflow_dispatch:

env:
  HUGO_VERSION: "0.165.0"
  PAGES_PROJECT: my-site

concurrency:
  group: deploy-${{ github.ref }}
  cancel-in-progress: true

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      deployments: write
    steps:
      - uses: actions/checkout@v7
        with:
          submodules: true

      - uses: peaceiris/actions-hugo@v3
        with:
          hugo-version: ${{ env.HUGO_VERSION }}
          extended: true

      # Processed images are gitignored; restore them so Hugo only
      # re-encodes what is new. An older cache still helps.
      - uses: actions/cache@v6
        with:
          path: resources/_gen
          key: hugo-resources-${{ hashFiles('content/**/*.jpg', 'content/**/*.png', 'assets/img/**') }}
          restore-keys: |
            hugo-resources-

      # A multilingual site has no root 404.html; without one, Pages
      # answers unknown paths with index.html and a 200.
      - name: Build
        run: |
          hugo --gc
          cp public/en/404.html public/404.html

      # ...

      - name: Deploy
        uses: cloudflare/wrangler-action@v4
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          accountId: ${{ vars.CLOUDFLARE_ACCOUNT_ID }}
          command: pages deploy public --project-name=${{ env.PAGES_PROJECT }} --branch=${{ github.ref_name }}

--branch=${{ github.ref_name }} làm cho main thành production và cho mọi nhánh khác một URL xem trước. Workflow cho trang của khách hàng có cùng cấu trúc, chỉ thêm một dòng rm -rf public trước khi dựng, vì bên đó thư mục public/ được commit, nếu không thì các trang đã xóa sẽ cứ nằm lại trong bản tải lên.

Phiên bản Hugo chỉ được ghim ở đây, không ở đâu khác. Tháng 10, một lần cập nhật của trình quản lý gói đã nâng Hugo trên laptop của tôi lên 0.168, cao hơn một bậc so với bản mới nhất mà theme hỗ trợ. Các lần triển khai vẫn ở 0.165 và chẳng hề hấn gì.

Và bước dựng chính là bài kiểm thử. Ngày 14 tháng 9, bản triển khai xem trước của một nhánh thất bại ba lần liên tiếp: một bài viết trên nhánh đó dùng ref của Hugo để liên kết tới một bài vẫn còn là bản nháp. CI dựng đúng như production dựng, tức là bỏ bản nháp ra, nên liên kết trỏ vào hư không và Hugo dừng lại với lỗi REF_NOT_FOUND. Trong lúc đó, main vẫn triển khai bình thường.

API của ứng dụng được triển khai bằng script

#

Phần cốt lõi của script triển khai, viết dưới dạng ví dụ:

IMAGE_LABEL="deploy-$(git rev-parse --short HEAD)-$(date +%Y%m%d%H%M%S)"

# Build first, then wake a spare machine, then roll out exactly that image.
flyctl deploy --config fly.toml --build-only --push --image-label "$IMAGE_LABEL"
curl -fsS --retry 5 https://myapp.fly.dev/health > /dev/null
flyctl deploy --config fly.toml --image "registry.fly.io/myapp:$IMAGE_LABEL"

Và các dòng tương ứng trong fly.toml:

[deploy]
  # max_unavailable only counts machines that are running,
  # which is why the script wakes one first.
  strategy = "rolling"
  max_unavailable = 1

Image được dựng đúng một lần, đẩy lên registry của Fly với một nhãn ghép từ commit và thời điểm, rồi được triển khai theo đúng nhãn đó, nên thứ được tung ra chính xác là thứ đã được dựng.

Thứ giúp triển khai không gián đoạn (zero-downtime) là việc đánh thức một máy dự phòng trước. max_unavailable = 1 chỉ đếm những máy đang chạy, mà ứng dụng lại không giữ máy nào chạy khi rảnh (một máy đang tạm dừng chỉ mất khoảng một giây để tỉnh lại). Vì vậy, trước đây cái máy duy nhất đang thức bị thay cùng đợt với các máy đang ngủ, và đằng sau nó không còn máy nào sẵn sàng. Ngày 28 tháng 9, tôi cho một đầu dò gửi yêu cầu liên tục tới origin: khi chạy flyctl deploy trơn thì có 7 lần hết thời gian chờ và một khoảng trống 7,3 giây, còn với script triển khai, vốn dựng trước và có sẵn một máy đang thức trước khi bắt đầu tung ra, thì không có lỗi nào trong 2.514 yêu cầu.

Phần còn lại của script đánh dấu lần triển khai trên kênh chat của đội, nơi các cảnh báo lỗi gửi về, để khi lỗi dồn dập thì có thể đối chiếu với thứ vừa thay đổi, rồi xóa cache Cloudflare và làm nóng các máy. Giao diện web thì hoàn toàn không đi qua image; chuyện đó tôi đã viết trong Triển khai frontend và backend riêng biệt, không cần triển khai lại API.

Migration không phải là một bước trong quy trình. release_command của Fly bị treo trong trường hợp của tôi, nên máy đầu tiên khởi động với image mới sẽ giữ khóa và chạy migration, trong khi các máy khác chờ. Vì thế, migration nào cũng phải tương thích với code vẫn đang chạy: thêm cột ở lần triển khai này, ngừng dùng nó ở lần sau, và xóa nó ở lần thứ ba.

Script này không có chỗ nào bắt buộc phải là laptop của tôi, nhưng có vài tệp chỉ nằm trên máy đang giữ nó ở đó: thông tin đăng nhập Cloudflare, và một bản ghi về thứ đã được triển khai lần gần nhất, thứ mà một runner mới tinh sẽ không có. Nó còn triển khai cả những thay đổi chưa commit, và có báo điều đó trên kênh chat, trong khi script phát hành web thì từ chối một cây làm việc chưa sạch.

Trong bài Môi trường xem trước cho từng nhánh, tôi viết rằng làm những việc này bằng tay thì ổn khi chỉ có một mình bạn làm, nhưng từ lập trình viên thứ hai trở đi thì nó phải xảy ra vì có gì đó xảy ra trong git. Ứng dụng vẫn chỉ có một lập trình viên. Các workflow môi trường theo nhánh trong bài đó vẫn nằm trên chính nhánh mà tôi đã dựng chúng.

Workflow OTA chỉ chạy tay, vì việc phát hành phải là một quyết định, và vì dịch vụ cập nhật từ chối bản phát hành mới khi đang có một đợt tung ra từng phần (partial rollout) còn mở, nên nếu kích hoạt theo push thì đợt canary nào cũng sẽ vướng. Workflow này chưa từng chạy lần nào. Mọi bản cập nhật OTA cho đến nay đều được đẩy đi từ laptop của tôi, qua chính script mà workflow gọi. Lý do nên giữ workflow mỏng gói gọn trong một câu: phát hành bắt đầu bằng cách nào thì cũng là cùng một script.

pyhtml2text phát hành theo tag

#

Job phát hành, với tên gói đã được đổi thành tên chung chung:

  release:
    runs-on: ubuntu-latest
    if: ${{ startsWith(github.ref, 'refs/tags/') || github.event_name == 'workflow_dispatch' }}
    needs: [linux, macos, windows, sdist]
    environment:
      name: pypi
      url: https://pypi.org/p/mypackage
    permissions:
      id-token: write       # trusted publishing and signing
      contents: write
      attestations: write
    steps:
      - uses: actions/download-artifact@v8
      - uses: actions/attest@v4
        with:
          subject-path: 'wheels-*/*'
      - uses: astral-sh/setup-uv@v10
        if: ${{ startsWith(github.ref, 'refs/tags/') }}
        with:
          prune-cache: true
      - name: Publish to PyPI
        if: ${{ startsWith(github.ref, 'refs/tags/') }}
        run: uv publish --trusted-publishing always 'wheels-*/*'

Job phát hành chờ mọi job dựng xong, và chỉ khi có tag mới thật sự xuất bản; chạy tay thì chỉ dựng và tạo chứng thực (attestation) chứ không tải gì lên. actions/attest ghi lại workflow nào đã dựng từng wheel, còn uv publish --trusted-publishing always tải chúng lên bằng token OIDC thay vì mật khẩu. Bản thân gói thư viện này tôi đã viết trong Một pull request bị đóng, một bản fork và một gói PyPI.

Workflow định kỳ chỉ là “cố gắng hết sức”

#

Ứng dụng có một workflow chạy định kỳ, kiểm tra xem Fly có bật nhiều máy hơn mức cơ bản hay không, chuyện mà nếu không kiểm tra thì sẽ chỉ lộ ra trên hóa đơn. Nó cảnh báo bằng cách cố ý thất bại, vì GitHub sẽ gửi email cho chủ kho khi một lần chạy định kỳ thất bại.

Lịch được đặt là cron: '*/15 * * * *', tức 96 lần một ngày. Vậy mà trong hai tuần qua, mỗi ngày nó chỉ chạy từ ba đến tám lần, với khoảng cách trung vị giữa các lần chạy khoảng ba tiếng bốn mươi phút. Lời giải thích duy nhất trong tài liệu của GitHub là tải: lần chạy định kỳ có thể bị trễ khi Actions bận, và bị bỏ qua khi bận đến một mức nào đó. Với một đợt mở rộng quy mô kéo dài, vài tiếng là đủ. Còn với thứ gì cần báo trong vòng vài phút, cron của GitHub không phải là công cụ giám sát.

Những câu tôi sẽ hỏi về một quy trình CI/CD

#

Dù bạn đang dựng một quy trình mới hay xem lại quy trình đang có:

1. Nếu GitHub Actions ngừng hoạt động cả một ngày, bạn có còn phát hành được không? Nếu không, logic phát hành của bạn đang nằm trong YAML, và bài năm 2024 vẫn còn đúng.
2. CI có chạy cùng trình thông dịch, cùng kiến trúc CPU và cùng phiên bản chính của cơ sở dữ liệu với production không? CI của tôi bắt được một lỗi trình biên dịch chỉ vì runner và production đều là x86_64, còn laptop của tôi thì không.
3. Một bản checkout mới tinh có qua được không? Nếu không, thủ phạm thường là các tệp được sinh tự động và bị gitignore.
4. Thời gian của một lần chạy thật ra tiêu vào đâu? Hãy đọc thời gian từng bước trước khi thêm bộ nhớ đệm.
5. Mỗi bí mật đang nằm ở bao nhiêu chỗ, và nó có thật sự cần nằm trên GitHub không?

Đa số các đội đều viết thẳng các bước dựng (build) và kiểm thử vào tệp YAML của GitHub Actions. Cách này vẫn chạy tốt, cho đến khi bạn muốn chạy lại đúng bản dựng đó trên laptop của mình, hoặc có người đề xuất chuyển sang GitLab, và lúc đó bạn mới nhận ra cả quy trình CI/CD (pipeline) đã dính chặt vào định dạng cấu hình của một nhà cung cấp duy nhất. Cách tôi chọn thì khá nhàm: toàn bộ logic thật sự nằm trong Docker Compose, còn công cụ CI chỉ có mỗi việc gọi nó, ngoài ra không làm gì thêm.

Vì sao tôi không để các bước dựng trong YAML của Actions

#

Vấn đề dễ thấy nhất là bị phụ thuộc vào nhà cung cấp (vendor lock-in). GitLab, Bitbucket hay Jenkins đều không hiểu workflow của Actions, nên nếu các bước dựng nằm trong tệp workflow thì đổi nhà cung cấp cũng có nghĩa là viết lại từ đầu. Mà có ai lên kế hoạch chừa thời gian cho việc đó bao giờ đâu.

Vấn đề thứ hai ít ai để ý hơn: bạn không chạy được quy trình CI/CD trên máy mình. Nếu muốn thử một thay đổi trong bước dựng mà cách duy nhất là đẩy (push) commit lên rồi ngồi canh tab Actions, thì lịch sử git của bạn sẽ toàn những commit kiểu “fix ci”, “fix ci again”, “please”. Còn tệp Compose thì chạy trên laptop của tôi giống hệt như trên máy chạy CI (runner), nhờ vậy phần lớn những màn cãi nhau “máy tôi chạy được mà” bị dập tắt ngay từ đầu.

Chưa hết, tệp YAML còn cứ thế phình ra. Hai mươi dòng gọn gàng ban đầu sẽ thành ba trăm dòng khi các mẹo lưu đệm (caching) và điều kiện rẽ nhánh lần lượt được thêm vào, và giờ lập trình viên nào cũng phải học thêm một “phương ngữ” CI nữa, bên cạnh Git và đủ thứ khác. Một script chỉ nên làm một việc; còn một tệp workflow cồng kềnh thì rốt cuộc sẽ ôm đồm mọi việc cùng lúc.

Với Compose, trách nhiệm được chia rất rạch ròi: tệp Compose lo phần dựng và kiểm thử, còn nền tảng CI chỉ đơn giản là nơi chạy nó mỗi lần có commit mới được đẩy lên.

Cách thiết lập

#

1. Bắt đầu với một Dockerfile, để khâu dựng image chỉ nằm ở đúng một chỗ:

# Use an official Node.js runtime as the base image
FROM node:14

# Set the working directory in the container
WORKDIR /app

# Copy the package.json and package-lock.json files to the container
COPY package*.json ./

# Install the dependencies
RUN npm install

# Copy the rest of the application code to the container
COPY . .

# Expose the port the app runs on
EXPOSE 3000

# Define the command to run the application
CMD ["npm", "start"]

2. Sau đó tạo tệp docker-compose.build.yaml, khai báo các dịch vụ (service) cần cho việc dựng và kiểm thử:

   services:
     app:
       image: myprivaterepo.com/image:latest
       build: .
       volumes:
         - .:/app
       command: sh -c "npm install && npm test"

3. Chạy thử trên máy mình trước. Cả bài này thật ra chỉ xoay quanh bước này:

   docker compose -f docker-compose.build.yaml build

4. Khi bước trên đã chạy ổn, workflow của GitHub Actions (hay thứ tương đương trên bất kỳ nền tảng nào khác) chỉ còn đóng vai trò điều phối:

   name: CI/CD Pipeline
   on: [push, pull_request]
   jobs:
     build:
       runs-on: ubuntu-latest
       steps:
         - uses: actions/checkout@v2
         - name: Set up Docker Buildx
           uses: docker/setup-buildx-action@v1
         - name: Build and Test with Docker Compose
           run: docker compose -f docker-compose.build.yaml build
         - name: Push the image referenced in the docker compose file
           run: docker compose -f docker-compose.build.yaml push

Như vậy công cụ CI giờ chỉ làm hai việc là dựng và đẩy image lên. Mọi thứ đáng để hiểu đều nằm trong các tệp mà nền tảng nào cũng chạy trực tiếp được, và thành viên mới vào đội cũng vậy.

Đẩy image lên kho lưu trữ

#

Một cái lợi đi kèm của tệp Compose là việc đẩy image trở nên cực kỳ đơn giản. Docker tự biết image sẽ được đẩy lên đâu dựa vào tên của nó: image: myprivaterepo.com/image:latest nghĩa là image sẽ được đẩy lên myprivaterepo.com. Nếu dùng kho lưu trữ image riêng (private registry) thì bạn sẽ cần token truy cập, phần này bạn xem thêm tài liệu của kho lưu trữ mình đang dùng nhé.

Nếu bạn đang dùng GitHub Actions và thấy ổn thì cũng chẳng có gì phải vội. Nhưng đến ngày cần đổi nhà cung cấp, việc chuyển đổi chỉ là chép lại hai câu lệnh, chứ không phải chuyển ba trăm dòng YAML sang định dạng mới. Còn từ giờ đến lúc đó, ít ra bạn cũng được gỡ lỗi bản dựng ngay trên máy mình, đàng hoàng như một người văn minh.