Docker Hub Là Gì? Cách Tìm, Tải Và Đẩy Image Lên Docker Hub

Suốt các bài trước, mỗi lần docker pull nginx hay docker pull alpine, Docker đều lặng lẽ tải image từ một nơi về máy của bạn. Nơi đó là Docker Hub — kho chứa image lớn nhất của hệ sinh thái Docker. Vậy Docker Hub là gì, làm sao tìm và tải image đúng cách, và làm thế nào để đẩy image của chính bạn lên đó?

Bài viết này đi qua 5 thao tác cốt lõi với Docker Hub: tìm image bằng docker search, tải image theo đúng phiên bản, gắn tag theo chuẩn của Hub, đăng nhập và đẩy (push) image lên, cuối cùng là quản lý các tag sau khi đẩy. Image dùng để thực hành push chính là web-custom:1.0 chúng ta đã build ở Bài 2 về Dockerfile.

1. Docker Hub là gì?

Docker Hub là gì? Đó là một registry — dịch vụ lưu trữ và phân phối Docker image — do Docker Inc. vận hành công cộng tại địa chỉ hub.docker.com. Nó là registry mặc định của mọi bản cài Docker: khi bạn pull một image không ghi rõ nguồn, Docker hiểu là lấy từ Hub; khi bạn push mà không chỉ định registry khác, image cũng đi lên Hub.

Ba khái niệm cần phân biệt ngay từ đầu để khỏi nhầm lẫn. Registry là dịch vụ lưu trữ image (Docker Hub là một registry, GHCR là một registry khác). Repository là một “kho con” trong registry, chứa một image cùng mọi phiên bản của nó. Còn image là bản đóng gói cụ thể được xác định bởi tên, tag và mã digest. Khi nói “đẩy image lên Hub”, thực chất bạn đang push các layer của image vào đúng repository của mình trên registry đó.

Trên Docker Hub, mỗi tài khoản (cá nhân hoặc tổ chức) sở hữu các repository — mỗi repository chứa một image cùng các phiên bản (tag) của nó, ví dụ repository nginx có các tag latest, 1.27, alpine… Repository có hai chế độ: public (ai cũng tải được) và private (chỉ tài khoản được cấp quyền mới thấy và tải được). Gói miễn phí của Hub có những giới hạn nhất định về private repository và lượng pull — bạn nên kiểm tra trang pricing hiện hành của Docker khi bắt đầu dùng nghiêm túc.

Ngoài Hub còn nhiều registry khác như GitHub Container Registry (GHCR), Amazon ECR hay registry tự host, nhưng hiểu rõ Docker Hub là gì và dùng thành thạo nó là bước đầu tiên, vì đây là nơi tập trung gần như toàn bộ image mã nguồn mở phổ biến: hệ điều hành (ubuntu, alpine), web server (nginx, httpd), database (mysql, postgres, redis) và hàng triệu image do cộng đồng đóng góp.

2. Tìm image bằng docker search và trên web Hub

Cách nhanh nhất để khám phá Hub ngay từ terminal là lệnh docker search. Hãy tìm thử các image liên quan đến nginx:

Kết quả đứng đầu chính là image nginx chính thức (official) — do chính đội ngũ nginx/Docker duy trì. Trên giao diện web của Hub, mỗi image còn hiển thị số lượt tải (pulls), số sao và nhãn “Docker Official Image” hoặc “Verified Publisher” — đây là những dấu hiệu uy tín quan trọng nhất khi chọn image. Quy tắc an toàn: ưu tiên image official hoặc của nhà phát hành đã xác thực, kiểm tra thời gian cập nhật gần nhất, và tránh các image vô danh không rõ nguồn gốc vì chúng có thể chứa mã độc hoặc cấu hình nguy hiểm.

Lệnh search trên terminal tiện cho tra cứu nhanh, nhưng khi cần đọc tài liệu của image (biến môi trường, thư mục dữ liệu, cách chạy khuyến nghị), hãy mở trang của image đó trên hub.docker.com — phần mô tả ở đó chính là “sách hướng dẫn” chính thức đi kèm mỗi image.

Một phần quan trọng khi tìm hiểu Docker Hub là gì là biết phân biệt mức độ tin cậy của image. Tầng cao nhất là Docker Official Images — tập hợp image được chính Docker cùng nhà phát hành gốc tuyển chọn, rà soát bảo mật và cập nhật đều đặn (nginx, ubuntu, mysql, postgres đều thuộc nhóm này). Tầng tiếp theo là Verified Publisher — image do các công ty đã được Docker xác thực danh tính phát hành, ví dụ các hãng phần mềm thương mại. Phần còn lại là image cộng đồng: bất kỳ ai cũng đăng được, chất lượng và độ an toàn chênh lệch rất lớn.

Với image cộng đồng, hãy tự kiểm chứng trước khi dùng: xem số lượt pull (image phổ biến thường đã được nhiều người “thử lửa”), ngày cập nhật gần nhất, có link về kho mã nguồn và Dockerfile công khai hay không. Một image bị bỏ hoang nhiều năm hoặc không rõ ai đứng sau là rủi ro bảo mật thực sự, vì container bạn chạy sẽ thừa hưởng mọi thứ bên trong image đó — kể cả mã độc nếu có.

3. Tải image đúng phiên bản: đừng lạm dụng tag latest

Lệnh tải image bạn đã quen từ Bài 1 là docker pull <tên>:<tag>. Vấn đề nằm ở tag: khi bỏ trống, Docker tự dùng latest — một nhãn “phiên bản mới nhất” luôn thay đổi theo thời gian. Hôm nay latest là nginx 1.31, vài tháng nữa nó có thể là 1.33 với những thay đổi không lường trước.

# Tải đúng một phiên bản cụ thể, kết quả ổn định theo thời gian
docker pull nginx:1.27-alpine

Sau khi tải thêm bản theo phiên bản chỉ định, danh sách image trên máy lab hiện tại trông như sau:

Cùng một repository nginx giờ có nhiều dòng với các tag khác nhau: latest (bản đầy đủ mới nhất), bản theo số phiên bản và các bản alpine nhẹ hơn hẳn (khoảng 64 MB so với 167 MB).

Trên hệ thống thật, hãy luôn ghi rõ tag phiên bản trong lệnh pull, trong Dockerfile (chỉ thị FROM) và trong file Compose — đó là thói quen giúp hệ thống của bạn chạy ổn định và tái lập được, thay vì “hôm qua chạy tốt, hôm nay tự nhiên lỗi” chỉ vì latest đã âm thầm đổi. Đây cũng là bộ mặt thực tế nhất của câu hỏi Docker Hub là gì trong công việc hằng ngày: một kho image mà bạn phải quản lý phiên bản nghiêm túc như quản lý mã nguồn vậy.

Ở mức chặt chẽ cao nhất, bạn có thể tham chiếu image bằng digest — mã băm SHA-256 của chính nội dung image, dạng nginx@sha256:.... Khác với tag (vốn có thể bị chủ repository trỏ sang một bản khác), digest là bất biến: hai lần pull cùng một digest ở hai thời điểm bất kỳ luôn cho ra đúng một nội dung. Các hệ thống production khắt khe thường ghi digest trong file triển khai để khóa chặt phiên bản.

Một điểm cộng nữa của các image phổ biến trên Hub là chúng thường được build cho nhiều kiến trúc CPU cùng lúc (multi-arch): cùng một tag nginx:1.27-alpine nhưng Hub tự trả về bản cho máy Intel/AMD (amd64) khi bạn pull trên VPS thông thường, và bản cho chip ARM (arm64) khi bạn pull trên Raspberry Pi hay máy Mac chip M. Bạn gần như không phải quan tâm đến việc này khi dùng — Docker và Hub tự phối hợp chọn đúng bản — nhưng nó giải thích vì sao cùng một lệnh pull lại hoạt động trơn tru trên nhiều loại máy khác nhau.

4. Gắn tag theo chuẩn Docker Hub bằng docker tag

Muốn đẩy image lên Hub, image phải mang tên theo chuẩn <username>/<tên-image>:<tag> — tiền tố username cho Hub biết image thuộc về tài khoản nào. Image web-custom:1.0 của chúng ta chưa có tiền tố này, nên cần gắn thêm một cái tên chuẩn bằng lệnh docker tag (dùng username mẫu demo-user, bạn hãy thay bằng username Docker Hub của mình):

Khi đặt tag cho image của mình, hãy dùng số phiên bản theo chuẩn ngữ nghĩa (semantic version) như 1.0, 1.1, 2.0 thay vì những cái tên tùy hứng kiểu moi, test2, final-ok. Số phiên bản tăng dần giúp người dùng image của bạn (và chính bạn sau vài tháng) biết ngay đâu là bản mới, đâu là bản cũ để quay lui khi cần. Nhiều dự án còn gắn thêm tag theo mã commit của Git cho các bản build tự động.

Quan sát cột IMAGE ID: hai dòng web-custom và demo-user/web-custom có cùng một ID — vì tag không hề nhân bản image, nó chỉ tạo thêm một cái tên (một nhãn tham chiếu) trỏ về cùng một image. Hệ quả thú vị sẽ thấy ở mục 6: xóa một tag không làm mất image khi vẫn còn tag khác trỏ tới nó.

5. Đăng nhập và đẩy image lên Docker Hub

Đẩy image cần xác thực danh tính. Trước hết, tạo tài khoản miễn phí tại hub.docker.com nếu bạn chưa có, rồi đăng nhập từ terminal:

docker login
# Nhập Username và Password (hoặc Access Token) của bạn
# Thao tác này chỉ cần làm một lần, thông tin được lưu cho các lần sau

Để thấy rõ vì sao bước đăng nhập là bắt buộc, hãy thử push khi chưa đăng nhập — Docker Hub sẽ từ chối ngay lập tức với lỗi unauthorized: authentication required (yêu cầu xác thực), vì máy của bạn chưa chứng minh được mình là chủ của namespace demo-user. Sau khi docker login thành công, lệnh đẩy chỉ còn một dòng đơn giản:

docker push demo-user/web-custom:1.0

Docker sẽ tải lên từng layer còn thiếu trên Hub (các layer thuộc image nền nginx:alpine đã có sẵn trên Hub sẽ được bỏ qua nhờ cơ chế dùng chung layer) và in dòng tổng kết kèm mã digest của image. Từ thời điểm đó, bất kỳ máy nào trên thế giới cũng có thể chạy web của bạn bằng một lệnh duy nhất: docker pull demo-user/web-custom:1.0 rồi docker run. Khi không dùng nữa, docker logout sẽ xóa thông tin đăng nhập khỏi máy — thao tác nên làm trên các máy dùng chung.

Một cải tiến bảo mật bạn nên áp dụng ngay: thay vì dùng mật khẩu tài khoản khi docker login, hãy tạo Access Token trong phần Settings > Security trên web Hub và dùng token đó làm “mật khẩu” khi đăng nhập. Token có thể đặt tên theo từng máy (ví dụ “VPS production”), giới hạn quyền chỉ pull hoặc cả push, và thu hồi riêng lẻ bất cứ lúc nào mà không ảnh hưởng các máy khác — điều không thể làm được nếu mọi nơi dùng chung một mật khẩu tài khoản.

6. Quản lý repository trên giao diện web của Docker Hub

Ngoài terminal, giao diện web của Hub là nơi bạn quản lý các repository của mình một cách trực quan. Sau khi đăng nhập, mục Repositories liệt kê mọi kho image thuộc tài khoản, phân biệt rõ public/private. Bạn có thể tạo repository trước ngay trên web (đặt tên, chọn chế độ hiển thị, viết mô tả ngắn) rồi push image vào đúng tên đó; hoặc cứ push thẳng từ terminal — Hub sẽ tự tạo repository tương ứng ở chế độ public.

Mở một repository, bạn sẽ thấy các thẻ chức năng chính: phần mô tả (nội dung README mà chủ image cung cấp — hãy viết tử tế cho image của mình vì đây là “mặt tiền” của nó), và mục Tags liệt kê mọi phiên bản đã push kèm dung lượng, kiến trúc hỗ trợ, mã digest và thời gian cập nhật. Từ mục Tags bạn cũng xóa được từng tag cụ thể, còn phần cài đặt của repository cho phép chuyển đổi public/private, đổi tên hoặc xóa toàn bộ repository — các thao tác không thể làm từ lệnh Docker phía máy khách.

Với tài khoản tổ chức, Hub còn có cơ chế phân quyền theo nhóm (team) — ai được pull, ai được push lên từng repository. Đây là tính năng biến Hub thành kho image nội bộ nghiêm túc cho công ty, thay vì mọi người dùng chung một tài khoản cá nhân.

7. Dọn tag thừa và các lỗi thường gặp

Sau khi push xong, cái tag mang tiền tố username trên máy local có thể xóa đi cho gọn bằng docker rmi — image gốc vẫn còn nguyên nhờ tag web-custom:1.0:

Một số lỗi quanh Docker Hub mà người mới hay gặp. Push báo “denied” hoặc “unauthorized”: chưa đăng nhập, đăng nhập nhầm tài khoản, hoặc tên image thiếu/sai tiền tố username — Hub chỉ cho bạn đẩy vào namespace của chính mình. Pull báo “manifest unknown”: tag không tồn tại, hãy kiểm tra lại đúng tên và tag trên trang web của image. Pull bị chậm hoặc báo lỗi giới hạn (rate limit / toomanyrequests): Hub áp giới hạn số lượt pull cho mỗi IP/tài khoản trong một khoảng thời gian — đăng nhập tài khoản khi pull và tránh pull lặp lại không cần thiết (tận dụng cache image ở máy) sẽ giảm hẳn tình trạng này.

Một lớp bảo vệ nữa khi pull image là kiểm tra tính toàn vẹn: mỗi image trên Hub đều có mã digest duy nhất, và Docker tự đối chiếu digest này sau khi tải về để chắc chắn nội dung không bị thay đổi trên đường truyền. Với các hệ thống yêu cầu cao, bạn có thể bật cơ chế ký số Docker Content Trust để chỉ chấp nhận những image đã được chính nhà phát hành ký xác thực — pull phải image giả mạo khi đó sẽ bị từ chối ngay từ đầu.

Cuối cùng, một nguyên tắc bảo mật khi làm việc với bất kỳ registry nào:

mật khẩu đăng nhập Hub nên được thay bằng Access Token tạo trong phần cài đặt tài khoản trên web, và tuyệt đối không ghi mật khẩu/token vào Dockerfile hay mã nguồn. Thông tin đăng nhập docker login được lưu trong file cấu hình của Docker trên máy — hãy bảo vệ nó như mọi thông tin xác thực khác.

8. Lời kết

Tóm lại, Docker Hub là gì — đó là registry mặc định và lớn nhất của Docker, nơi bạn tìm image bằng docker search, tải về bằng docker pull với tag phiên bản rõ ràng, và xuất bản image của mình bằng bộ ba docker tag → docker login → docker push. Nắm vững vòng này là bạn đã đi hết hành trình cơ bản của một image: từ máy của người khác về máy mình, và từ máy mình ra thế giới.

Bài cuối của series sẽ quay lại một vấn đề rất thực tế: dùng Docker một thời gian, ổ đĩa VPS phình lên vì image, container và volume rác — chúng ta sẽ học cách dọn dẹp Docker và tối ưu dung lượng trong Bài 6.