Cập nhật container không gián đoạn

Cập nhật container không phải là “kéo image mới về” mà là “thay thế phiên bản đang chạy bằng phiên bản mới và có thể khôi phục lại.” Sự khác biệt này chỉ lộ ra đúng một lần: khi phiên bản mới không khởi động được.

Một quy trình hiệu quả

cd /opt/myapp
docker compose pull
docker compose up -d
docker compose ps
docker compose logs -f --tail 100

Compose chỉ tạo lại những service có image thay đổi và giữ nguyên phần còn lại. Thời gian chết chỉ là vài giây để khởi động lại container.

Nhưng trước khi làm điều này, bạn cần thỏa mãn hai điều kiện.

Thứ nhất: phiên bản được ghim cố định. File phải ghi rõ postgres:17.2, không phải postgres:latest. Nếu không, một ngày nào đó pull sẽ mang về một phiên bản major viết lại định dạng dữ liệu, và việc khôi phục trở nên bất khả thi.

Thứ hai: bản sao lưu còn mới. Một bản cập nhật làm hỏng cơ sở dữ liệu sẽ làm hỏng nó vĩnh viễn. Trước khi đổi phiên bản major, hãy dump dữ liệu — xem cần sao lưu những gì.

Thay thế mà không có khoảng gián đoạn

Với một web service nằm sau reverse proxy, thời gian chết gần như bằng không nếu container có health check: proxy sẽ chỉ bắt đầu gửi request đến instance đã sẵn sàng.

services:
  app:
    image: ghcr.io/example/app:1.5.0
    healthcheck:
      test: ["CMD", "curl", "-fsS", "http://localhost:8080/health"]
      interval: 5s
      timeout: 3s
      retries: 6
      start_period: 20s

docker inspect -f '{{.State.Health.Status}}' <container>

Không có health check, Compose coi container đã sẵn sàng ngay khi tiến trình khởi động — trong khi ứng dụng vẫn đang đọc cấu hình và chạy migration.

Đừng xóa image cũ cho đến khi phiên bản mới chạy được ít nhất một giờ. Khôi phục nghĩa là đặt lại image: ...:1.4.2 và chạy docker compose up -d, nhưng chỉ khi image cũ vẫn còn trên đĩa. Chạy docker image prune -a ngay sau khi cập nhật sẽ tước mất lựa chọn đó của bạn.

Khôi phục

sed -i 's|app:1.5.0|app:1.4.2|' compose.yaml
docker compose up -d app
docker compose logs -f --tail 50 app

Nếu phiên bản mới đã thay đổi schema cơ sở dữ liệu, chỉ khôi phục image là không đủ — bạn sẽ cần phục hồi từ bản sao lưu. Đó là lý do các bản cập nhật major được thực hiện vào thời điểm ít người dùng và với bản sao lưu đã kiểm chứng: xem diễn tập khôi phục.

Tự động hóa: hãy cẩn thận

Watchtower có thể tự cập nhật container. Với các service tại nhà thì tiện; với môi trường production thì đó là rủi ro: bản cập nhật đến vào ban đêm, làm hỏng cơ sở dữ liệu, và không ai phát hiện. Một thỏa hiệp hợp lý là chỉ nhận thông báo:

services:
  watchtower:
    image: containrrr/watchtower
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    command: --monitor-only --schedule "0 0 6 * * *"

Bạn biết có phiên bản mới và cập nhật thủ công vào thời điểm phù hợp với mình.

Khởi động lại máy

Các gói hệ thống được cập nhật tách biệt với container. Sau khi cập nhật kernel bạn cần khởi động lại, và các container có restart: unless-stopped sẽ tự khởi động lại. Hãy thử điều này trước — bằng sudo reboot vào thời điểm ít người dùng, không phải trong lúc có sự cố. Khởi động lại mềm từ bảng điều khiển hoạt động miễn là hệ thống đã cài qemu-guest-agent.

Những lỗi thường gặp

• pull mà không up -d. Image mới đã được tải về, nhưng container cũ vẫn đang chạy.
• Đĩa bị lấp đầy bởi image cũ. Chạy docker image prune mỗi tháng một lần — nhưng không phải ngay sau khi cập nhật. Xem dung lượng đĩa.
• Bạn cập nhật mọi thứ cùng lúc. Có thứ gì đó hỏng — và bạn không thể biết là cái nào. Hãy cập nhật từng service một.
• Bạn không đọc ghi chú phát hành. File cấu hình không tương thích là nguyên nhân thất bại phổ biến nhất sau khi đổi phiên bản major; xem phân tích trong các vấn đề Docker thường gặp.