Docker Minimus migration sang Docker Hardened Images

Nếu hệ thống của bạn đang chạy image từ Minimus, hãy bắt đầu Docker Minimus migration ngay thay vì chờ đến sát hạn. Docker cho biết registry Minimus dự kiến ngừng hoạt động vào ngày 22 tháng 10 năm 2026; sau thời điểm này, image đã kéo về vẫn có thể chạy nhưng không còn nhận bản cập nhật, khiến các lỗ hổng mới không được vá (theo docker.com).

Hướng đi ít thay đổi nhất là chuyển sang Docker Hardened Images (DHI) tương ứng, sau đó xác minh lại quyền truy cập, người dùng chạy container, cổng dịch vụ, entrypoint, pipeline CI/CD và kết quả quét lỗ hổng. Với nhiều ứng dụng, thay đổi ban đầu chỉ nằm ở dòng FROM, nhưng không nên xem đây là thao tác thay thế mù quáng.

Vì sao Minimus registry end of life cần được xử lý sớm?

Việc registry ngừng cung cấp image không đồng nghĩa container đang chạy sẽ dừng ngay. Rủi ro lớn hơn là quy trình phát hành và bảo mật bị đứt gãy: máy chủ mới không thể kéo image, pipeline không dựng được bản phát hành, còn image cũ tiếp tục tích lũy CVE theo thời gian.

Trong giai đoạn chuyển tiếp, Minimus vẫn được duy trì cập nhật theo thông báo của Docker cho đến ngày 22/10/2026. Điều đó tạo ra một khoảng thời gian phù hợp để kiểm kê, thử nghiệm và triển khai theo từng nhóm dịch vụ thay vì thực hiện một lần trên toàn bộ hệ thống.

Docker Hardened Images được Docker mô tả là các image tối giản, được gia cố và duy trì liên tục. Danh mục DHI có các nền tảng Alpine và Debian, cùng biến thể dùng cho giai đoạn build và runtime. DHI Community cung cấp danh mục image mã nguồn mở theo giấy phép Apache 2.0; các gói trả phí bổ sung SLA xử lý CVE, biến thể FIPS/STIG, tùy biến và hỗ trợ vòng đời mở rộng (theo docs.docker.com).

Không nên mặc định rằng DHI là bản sao hoàn toàn của Minimus. Tên tag, đường dẫn registry, entrypoint, user mặc định và các công cụ có sẵn có thể khác. Mục tiêu của kế hoạch là duy trì hành vi ứng dụng, đồng thời cải thiện khả năng kiểm chứng nguồn gốc và quy trình vá lỗi.

Kiểm kê image Docker trước khi di chuyển

Bước đầu tiên của di chuyển image container là lập danh sách đầy đủ, bao gồm cả image được tham chiếu gián tiếp trong Dockerfile, Docker Compose, Helm chart, manifest Kubernetes, pipeline CI/CD và script triển khai.

Danh sách thông tin cần thu thập

Tên image, registry, repository và tag hoặc digest đang sử dụng.
Dịch vụ sử dụng image: production, staging, development hay công cụ nội bộ.
Nền tảng cơ sở: Alpine, Debian, Ubuntu, Wolfi hoặc image tùy chỉnh.
Kiến trúc cần hỗ trợ: linux/amd64, linux/arm64 hoặc nhiều kiến trúc.
Các lệnh RUN, apt, apk, bash, curl và công cụ debug đang phụ thuộc vào.
User, group, cổng lắng nghe, volume, biến môi trường và entrypoint hiện tại.
Người sở hữu dịch vụ, mức độ quan trọng, cửa sổ bảo trì và phương án rollback.

Bạn có thể bắt đầu bằng việc tìm các tham chiếu image trong mã nguồn:

grep -RInE '(^|[[:space:]])(FROM|image:)[[:space:]]' 
  Dockerfile* docker-compose*.yml .github/ helm/ k8s/ 2>/dev/null

Tiếp theo, dùng Docker để ghi nhận cấu hình image đang chạy:

docker ps --format '{{.Image}} {{.Names}}'
docker image ls
docker image inspect <image:tag>

Kết quả kiểm kê nên được đưa vào bảng theo dõi với các cột: image Minimus, image DHI dự kiến, tag/digest, dịch vụ, owner, trạng thái kiểm thử, ngày triển khai và phương án quay lui. Đây là phần quan trọng nhất để tránh bỏ sót worker, cronjob hoặc image chỉ được gọi trong một pipeline hiếm khi chạy.

Nếu hệ thống đang vận hành trên máy chủ riêng hoặc VPS, bạn cũng nên ghi nhận cách registry được cho phép qua firewall, proxy và secret. Xem thêm hướng dẫn lựa chọn VPS nếu môi trường triển khai của bạn phụ thuộc vào máy chủ tự quản trị.

Quy trình chuyển sang Docker Hardened Images

1. Chọn image DHI cùng hệ sinh thái

Ưu tiên image DHI dựa trên cùng họ hệ điều hành với image hiện tại. Nếu image Minimus dựa trên Alpine, chọn biến thể Alpine; nếu dựa trên Debian, chọn biến thể Debian. Cách này giảm nguy cơ khác biệt về thư viện, trình quản lý gói và hành vi runtime.

Đăng nhập registry trước khi thử kéo image:

docker login dhi.io
docker pull dhi.io/<repository>:<tag>

Tên repository và tag cụ thể cần được tra cứu trong danh mục DHI, không nên tự suy đoán từ tên image Minimus. Với các image cần cài dependency, hãy chọn biến thể có tag dev hoặc sdk cho build stage; image runtime thường không có package manager hoặc shell (theo docs.docker.com).

2. Sửa Dockerfile theo mô hình build và runtime

Ví dụ đơn giản khi image hiện tại có thể thay thế trực tiếp:

# Trước
FROM minimus/base-image:1.2

# Sau, cần thay bằng repository/tag DHI đã xác minh
FROM dhi.io/<dhi-image>:<tag>

Với ứng dụng cần biên dịch hoặc cài gói, dùng multi-stage build:

FROM dhi.io/<runtime>:dev AS build
WORKDIR /src
COPY . .
RUN <lệnh cài dependency và build>

FROM dhi.io/<runtime>:latest
WORKDIR /app
COPY --from=build /src/<artifact> /app/<artifact>
USER 65532
EXPOSE 8080
ENTRYPOINT ["/&app/<artifact>"]

DHI runtime chạy non-root mặc định với UID 65532. Vì vậy, mọi thư mục cần ghi phải được tạo và cấp quyền phù hợp trong build stage hoặc khi khởi động volume. Ứng dụng cũng không nên lắng nghe cổng đặc quyền dưới 1024; hãy chuyển sang cổng từ 1025 trở lên, chẳng hạn 8080.

DHI đã bao gồm chứng chỉ TLS tiêu chuẩn, nên nhiều Dockerfile không cần tiếp tục cài ca-certificates. Tuy nhiên, chứng chỉ nội bộ của doanh nghiệp vẫn phải được đưa vào theo quy trình riêng. Runtime image cũng có thể không chứa shell, vì vậy các lệnh kiểm tra hoặc chỉnh sửa bằng /bin/sh cần chuyển sang build stage hoặc thực hiện từ bên ngoài container (theo docs.docker.com).

Kiểm thử, triển khai và rollback an toàn

Không nên đánh giá migration chỉ bằng việc image kéo thành công. Một image mới đạt yêu cầu khi ứng dụng khởi động đúng, xử lý được request, ghi log bình thường, kết nối được dependency và đáp ứng các kiểm soát bảo mật đã đặt ra.

Bộ kiểm thử tối thiểu

Kiểm tra build: dựng image từ đầu trong môi trường sạch, không dùng layer cache của image Minimus.
Kiểm tra runtime: chạy container với user mặc định, volume, biến môi trường và giới hạn tài nguyên giống production.
Kiểm tra chức năng: gọi healthcheck, API chính, job nền, kết nối cơ sở dữ liệu và hệ thống hàng đợi.
Kiểm tra bảo mật: quét image bằng công cụ đang dùng, kiểm tra SBOM, chữ ký, provenance và digest.
Kiểm tra triển khai: thử pipeline, registry mirror, secret và quyền pull trên Kubernetes hoặc máy chủ đích.
Kiểm tra rollback: giữ lại digest image Minimus đã được kiểm thử trong thời gian chuyển tiếp, nhưng không xem đó là phương án bảo mật dài hạn.

Hãy triển khai theo nhóm nhỏ: môi trường development, staging, một dịch vụ ít rủi ro, sau đó mới đến production quan trọng. Theo dõi tỷ lệ lỗi, thời gian khởi động, mức sử dụng CPU/RAM, log và cảnh báo trong ít nhất một chu kỳ phát hành trước khi mở rộng.

Nếu dùng Kubernetes, cần tạo hoặc cập nhật image pull secret cho registry DHI. Docker lưu ý rằng việc xác thực là cần thiết khi kéo image từ dhi.io, mirror Docker Hub hoặc registry bên thứ ba (theo docs.docker.com).

Về bảo mật chuỗi cung ứng, migration này nên được gắn với chính sách chỉ cho phép image theo digest, yêu cầu quét trước khi phát hành và giới hạn registry được phép truy cập. Bạn có thể tham khảo thêm bài viết về bảo vệ chuỗi cung ứng để mở rộng kiểm soát từ image đến máy chủ.

Các lỗi thường gặp

Build thất bại vì thiếu shell hoặc package manager: chuyển lệnh cài đặt sang image dev/sdk và dùng multi-stage build.
Ứng dụng không ghi được file: kiểm tra quyền thư mục với UID 65532, volume và thư mục tạm.
Container khởi động rồi thoát: so sánh ENTRYPOINT, CMD và biến môi trường với image cũ.
Healthcheck lỗi vì cổng thay đổi: kiểm tra ứng dụng có đang bind vào cổng 1025 trở lên và manifest có trỏ đúng cổng hay không.
Pipeline không kéo được image: cập nhật secret, quyền registry, allowlist firewall và credential helper.
Scanner báo kết quả khác trước: xác định scanner đang đọc CVE, SBOM và VEX như thế nào; không so sánh chỉ dựa trên một con số tổng.

Checklist hoàn tất gồm: mọi tham chiếu Minimus đã được lập danh sách; từng image có image DHI thay thế; Dockerfile build thành công; test chức năng đạt; quyền non-root được xác minh; registry credential hoạt động; digest được ghi nhận; kế hoạch rollback được phê duyệt; và không còn pipeline production phụ thuộc vào Minimus sau ngày 22/10/2026.

Kết luận: Minimus registry end of life là một thay đổi hạ tầng cần được xử lý như dự án quản trị chuỗi cung ứng, không chỉ là sửa một dòng Dockerfile. Hãy kiểm kê image Docker trong tuần đầu, thử một dịch vụ ít rủi ro trong tuần tiếp theo, rồi mở rộng theo digest sau khi kiểm thử. DHI có thể giảm thay đổi kỹ thuật nhờ duy trì nền tảng Alpine và Debian, nhưng chính sách non-root, runtime tối giản và xác thực registry vẫn đòi hỏi bạn kiểm tra có chủ đích.

Minimus sắp ngừng hoạt động: Chuyển sang Docker Hardened Images thế nào?