Cách khắc phục lỗi Docker "No Space Left on Device": Hướng dẫn đầy đủ

Lỗi Docker "no space left on device" thường ập đến vào lúc tệ nhất: giữa quá trình triển khai, lúc build quan trọng, hoặc khi kéo về một image thiết yếu. Tôi đã gặp lỗi này vài lần, và có thể nói rằng vội vàng xóa file mà chưa chẩn đoán kỹ là công thức dẫn đến mất dữ liệu.

Điều khiến lỗi này khó xử lý là hiếm khi chỉ có một nguyên nhân. Bạn có thể đang đối mặt với việc tích tụ Docker image, log container tăng không kiểm soát, cạn kiệt inode do hàng triệu file nhỏ, hoặc thậm chí dung lượng "ảo" bị chiếm bởi các file đã xóa nhưng vẫn còn được quy trình đang chạy giữ mở. Mỗi kịch bản lại cần một cách giải quyết khác nhau.

Vì vậy tôi luôn nhấn mạnh việc chẩn đoán trước khi hành động. Hiểu đúng nguyên nhân gốc giúp bạn áp dụng giải pháp đúng đích, hiệu quả và tránh làm gián đoạn môi trường sản xuất. Trong hướng dẫn này, tôi sẽ cùng bạn đi qua một quy trình có hệ thống để chẩn đoán, khắc phục và phòng ngừa vấn đề khó chịu này.

Nếu bạn mới dùng Docker, tôi khuyên bạn nên tham gia khóa học thực hành Introduction to Docker của chúng tôi, bao quát mọi thứ bạn cần để bắt đầu với container hóa.

Lỗi Docker "No Space Left on Device" là gì?

Khi Docker ném ra lỗi này, nó đang báo hiệu một trong hai vấn đề cốt lõi với lưu trữ của hệ thống bạn:

• Hết block dung lượng đĩa vật lý
• Hết inode

Hiểu sự khác biệt giữa hai nguyên nhân này là chìa khóa để áp dụng giải pháp đúng.

Nguyên nhân gốc phía sau lỗi “no space left on device”

Nguyên nhân đầu tiên và dễ hiểu nhất là hết block dung lượng đĩa vật lý. Hệ thống tệp của bạn đã hết không gian lưu trữ thực để ghi dữ liệu. Đây là kịch bản trực quan hơn: bạn đơn giản đã lấp đầy đĩa bằng Docker image, container, log, hoặc các file khác.

Nguyên nhân thứ hai, ít hiển nhiên hơn là hết inode. Dù còn hàng GB trống, hệ thống tệp của bạn có thể hết inode (cấu trúc siêu dữ liệu dùng để theo dõi file và thư mục). Mỗi file và thư mục tiêu tốn một inode, vì vậy các ứng dụng tạo ra hàng triệu file nhỏ (như file session PHP hoặc thư mục node_modules của npm) có thể làm cạn inode trong khi dung lượng đĩa vẫn chưa dùng hết.

Hiểu về driver lưu trữ overlay2

Docker thường sử dụng driver lưu trữ overlay2, dựa trên OverlayFS của Linux. OverlayFS xếp chồng nhiều thư mục trên một máy chủ và trình bày chúng như một hệ thống tệp hợp nhất. Các lớp image được mount dưới dạng thư mục thấp hơn chỉ đọc, trong khi mỗi container đang chạy thêm một lớp mỏng ghi được ở phía trên. Chế độ xem hợp nhất này được cung cấp cho container dưới dạng một thư mục duy nhất.

Driver overlay2 hỗ trợ gốc tối đa 128 lớp OverlayFS ở tầng thấp về mặt lý thuyết, nhưng kho lớp của Docker áp dụng giới hạn thực tế là 125 lớp cơ sở cho mỗi image. Nó cho phép ghép ảnh hiệu quả và cải thiện hiệu năng cho các thao tác như docker build và docker commit. 

Dù overlay2 được thiết kế để tiêu tốn ít inode hơn các driver lưu trữ trước đây, các môi trường Docker liên tục build image, kéo layer, hoặc tạo container vẫn có thể gây áp lực đáng kể lên cả block đĩa và inode theo thời gian, đặc biệt khi image hoặc lớp ứng dụng chứa nhiều file nhỏ.

Cách lỗi này xuất hiện phụ thuộc vào môi trường triển khai:

• Trên hệ thống Linux native, nó ảnh hưởng đến hệ thống tệp đứng sau /var/lib/docker. 

• Trên Docker Desktop cho Windows hoặc macOS, giới hạn tồn tại bên trong file đĩa máy ảo của Docker (như file .raw hoặc .vhdx), điều này tạo thêm một số cân nhắc khi thu hồi hoặc thay đổi kích thước lưu trữ.

Bước 1: Chẩn đoán nguyên nhân gốc

Trước khi xóa bất cứ thứ gì, tôi luôn bắt đầu với chẩn đoán kỹ. Bỏ ra vài phút lúc đầu có thể tiết kiệm hàng giờ xử lý sự cố và tránh mất dữ liệu ngoài ý muốn.

Kiểm tra dung lượng ở cấp hệ thống

Bắt đầu bằng cách kiểm tra mức sử dụng đĩa của máy chủ với df -H (df là viết tắt của disk free):

df -HĐược hỗ trợ bởi

Kiểm tra dung lượng đĩa trống trong WSL

Lệnh này hiển thị mức sử dụng đĩa ở định dạng dễ đọc. Hãy tìm các hệ thống tệp ở mức hoặc gần 100% dung lượng. 

Trên cài đặt Linux native, hãy chú ý đặc biệt đến phân vùng nơi /var/lib/docker nằm. Thường đây là phân vùng root (/) hoặc một phân vùng Docker riêng. 

Trên Docker Desktop (Windows/Mac), hãy tìm mount hệ thống tệp chính (thường là /dev/sdf hoặc tương tự), nơi chứa dữ liệu của VM Docker, thay vì các tham chiếu cụ thể đến /var/lib/docker, vì Docker chạy bên trong một máy ảo.

Tiếp theo, kiểm tra tình trạng cạn inode bằng df -i:

df -iĐược hỗ trợ bởi

Kiểm tra cạn inode

Nếu bạn thấy mức sử dụng inode (IUse%) đạt 100% trên bất kỳ hệ thống tệp nào, bạn đã tìm ra vấn đề. Kịch bản này khá phổ biến trong máy chủ build và môi trường CI/CD, nơi Docker liên tục tạo và hủy container với rất nhiều file nhỏ.

Phân tích mức sử dụng riêng của Docker

Sau khi xác định vấn đề là dung lượng đĩa hay inode, hãy đi sâu hơn và kiểm tra mức tiêu thụ tài nguyên cụ thể của Docker. Lệnh docker system df cung cấp tóm tắt cấp cao và dùng được trên mọi cài đặt Docker:

docker system dfĐược hỗ trợ bởi

Kết quả này chia nhỏ mức sử dụng không gian thành bốn nhóm: Image, container, volume cục bộ và build cache.

Cột RECLAIMABLE đặc biệt hữu ích. Nó cho thấy bạn có thể thu hồi bao nhiêu dung lượng mà không ảnh hưởng đến các container đang chạy. Hiểu sự khác biệt giữa hai chỉ số này là chìa khóa: không gian "active" hiện do container đang chạy sử dụng, trong khi không gian "reclaimable" có thể giải phóng an toàn.

Để có chi tiết sâu hơn, thêm cờ verbose:

docker system df -vĐược hỗ trợ bởi

Phân tích mức sử dụng Docker

Kết quả chi tiết này liệt kê từng image, container và volume cùng kích thước của chúng, cung cấp phân tích đủ chi tiết để xác định thành phần ngốn dung lượng. Dưới đây là những gì cần tìm trong mỗi phần:

• Images: Hiển thị kích thước mỗi image và liệu nó đang được dùng. Tìm các image lớn không dùng hoặc bị trùng với tag khác. Các image được đánh dấu "unused" có thể xóa an toàn mà không ảnh hưởng container đang chạy.

• Containers: Hiển thị kích thước lớp ghi cho mỗi container. Nếu một container đã dừng có SIZE đáng kể, nghĩa là nó đã ghi dữ liệu vào hệ thống tệp. Cột CREATED giúp nhận diện các container cũ có thể đã bị quên.

• Volumes: Liệt kê kích thước volume và tình trạng sử dụng. Volume không dùng là ứng viên an toàn để xóa, nhưng luôn kiểm tra kỹ để đảm bảo không chứa dữ liệu quan trọng trước khi prune.

• Build Cache: Thường là thành phần tiêu thụ lớn nhất và hay bị bỏ qua. Đây là các lớp trung gian từ thao tác docker build mà Docker giữ lại để tăng tốc các lần build sau.

Lệnh đặc thù theo hệ điều hành

Với người dùng Linux native muốn có cái nhìn sâu hơn về hệ thống tệp, bạn có thể tùy chọn kiểm tra trực tiếp các thư mục con để xem thư mục nào (overlay2, containers, volumes) tiêu tốn nhiều dung lượng nhất:

sudo du -h --max-depth=1 /var/lib/docker | sort -hĐược hỗ trợ bởi

Tuy nhiên, với người dùng Docker Desktop, /var/lib/docker nằm bên trong máy ảo ẩn của Docker và không thể truy cập trực tiếp. Tin tốt là docker system df -v cung cấp toàn bộ thông tin có thể hành động được, bất kể nền tảng của bạn, khiến nó trở thành cách chẩn đoán đáng tin cậy nhất.

Bước 2: Dọn hệ thống với Docker Prune 

Sau khi xác định nơi bị chiếm dụng, tôi có thể thu hồi an toàn bằng các lệnh prune tích hợp của Docker. Những thao tác này được thiết kế chỉ loại bỏ tài nguyên không sử dụng, giảm thiểu rủi ro gián đoạn dịch vụ đang chạy.

Prune tài nguyên dangling

Docker phân biệt giữa tài nguyên "dangling" và "unused". Image dangling là image không có tag và không được container nào tham chiếu. Thường là lớp trung gian từ một lần build thất bại hoặc đã bị thay thế. Những cái này luôn có thể xóa an toàn.

Bắt đầu với lệnh prune cơ bản:

docker system pruneĐược hỗ trợ bởi

Lệnh này xóa toàn bộ container không dùng, network không dùng và image dangling. Nó sẽ không động đến image có tag hoặc volume trừ khi chỉ định rõ. Docker sẽ yêu cầu xác nhận trước khi thực hiện.

Để mạnh tay hơn và xóa tất cả image không dùng (không chỉ dangling), thêm cờ --all:

docker system prune --allĐược hỗ trợ bởi

Docker system prune

Lệnh này xóa bất kỳ image nào hiện không liên kết với container. Hãy thận trọng: các lần triển khai sau sẽ cần kéo lại các image đã bị xóa.

Nếu bạn muốn đưa cả volume vào diện dọn dẹp (chứa dữ liệu bền vững), thêm cờ --volumes:

docker system prune --all --volumesĐược hỗ trợ bởi

Cảnh báo: Thao tác này sẽ xóa vĩnh viễn dữ liệu trong các volume không dùng. Luôn xác minh volume không chứa dữ liệu quan trọng trước khi dùng cờ này.

Quản lý build cache

Đây mới là phần thú vị. Build cache, nơi lưu các lớp trung gian từ thao tác build Docker, thường là thành phần ngốn dung lượng lớn nhất, nhưng docker system prune cố ý bỏ qua nó để giữ hiệu năng build.

Để nhắm mục tiêu build cache:

docker builder pruneĐược hỗ trợ bởi

Nếu muốn lựa chọn và giữ lại các lớp cache gần đây, dùng bộ lọc theo thời gian:

docker builder prune --filter "until=24h"Được hỗ trợ bởi

Lệnh này chỉ xóa các lớp cache cũ hơn 24 giờ, giữ nguyên phần việc gần đây của bạn.

Dọn volume một cách an toàn

Volume cần đặc biệt cẩn trọng vì chứa dữ liệu bền vững, như cơ sở dữ liệu, file tải lên, và trạng thái ứng dụng. Xóa nhầm volume đồng nghĩa mất dữ liệu vĩnh viễn.

Đầu tiên, xác định các volume dangling (không gắn với container nào):

docker volume ls -f dangling=trueĐược hỗ trợ bởi

Xem kỹ danh sách này. Nếu bạn chắc chắn các volume này không cần thiết, hãy prune chúng:

docker volume pruneĐược hỗ trợ bởi

Docker sẽ yêu cầu xác nhận trước khi thực hiện. Khi do dự, hãy sao lưu volume trước khi prune.

Bước 3: Xử lý việc log Docker phình to

Log của container có thể âm thầm ngốn lượng đĩa rất lớn, đôi khi vượt 50 GB cho mỗi container.

Xác định file log phình to

Trình điều khiển logging mặc định json-file của Docker ghi toàn bộ stdout và stderr của container vào file JSON. Nếu không đặt giới hạn kích thước (mặc định là -1, không giới hạn), các file này sẽ tăng vô hạn.

Kiểm tra kích thước container trên mọi môi trường:

docker ps -a --format "table {{.ID}}\t{{.Names}}\t{{.Size}}"Được hỗ trợ bởi

Để kiểm tra kích thước file log của một container cụ thể:

ls -lh $(docker inspect --format='{{.LogPath}}' <container-name>)Được hỗ trợ bởi

Chỉ với Linux native, tìm trực tiếp các file log lớn nhất:

sudo find /var/lib/docker/containers/ -name "*-json.log" -exec du -h {} + | sort -h | tail -10Được hỗ trợ bởi

Nếu docker logs trở nên chậm hoặc container không khởi động được, log quá khổ có thể là nguyên nhân. Để khắc phục, bạn có thể cắt ngắn (truncate) log.

Cắt ngắn log an toàn

Cắt ngắn log sẽ giải phóng thêm dung lượng. Tuy nhiên, không bao giờ xóa file log bằng rm khi container đang chạy. Docker daemon giữ các handle mở tới các log này, và việc xóa sẽ tạo ra file "đã xóa nhưng còn mở" tiếp tục chiếm dung lượng cho đến khi daemon được khởi động lại.

Cách an toàn là cắt ngắn log về 0:

sudo truncate -s 0 $(docker inspect --format='{{.LogPath}}' <container-name>)Được hỗ trợ bởi

Thao tác này giải phóng dung lượng ngay mà không làm đứt handle file. Container tiếp tục ghi log vào cùng file.

Bước 4: Xử lý sự cố nâng cao và vấn đề ẩn

Khi các bước dọn dẹp tiêu chuẩn không hiệu quả, rất có thể bạn đang gặp một trong các vấn đề ít phổ biến hơn nhưng tác động tương tự dưới đây:

• Hết inode: Hệ thống tệp của bạn đã hết cấu trúc siêu dữ liệu file dù còn dung lượng trống

• File đã xóa nhưng còn mở: Các tiến trình giữ handle tới file đã xóa, tạo ra mức sử dụng dung lượng "ảo"

• Phình to đĩa ảo Docker Desktop: File .raw hoặc .vhdx trên host không thu nhỏ sau khi bạn xóa dữ liệu trong VM

Hãy xử lý lần lượt từng tình huống.

Giải quyết việc hết inode

Điều này có thể do ứng dụng tạo ra hàng triệu file nhỏ, như session PHP, npm node_modules, hoặc artifact build tiêu tốn inode với tốc độ đáng báo động.

Trước hết, xác minh tình trạng hết inode:

df -iĐược hỗ trợ bởi

Dùng các lệnh Docker (mọi môi trường):

docker ps -a | wc -l             # Check container count
docker images | wc -l         # Check image count
docker image prune -a      # Remove unused images to free inodesĐược hỗ trợ bởi

Đối với cài đặt Linux, xác định các thư mục tiêu tốn inode nặng:

for dir in /var/lib/docker/*/; do
    echo "$dir: $(sudo find $dir -type f 2>/dev/null | wc -l) files"
doneĐược hỗ trợ bởi

Xóa image không dùng với docker rmi cũng giải phóng inode. Với vấn đề ở cấp ứng dụng, hãy triển khai dọn dẹp bên trong container hoặc dùng mount volume cho file tạm.

Xử lý file đã xóa nhưng còn mở (chỉ Linux)

Khi một file bị xóa trong khi tiến trình vẫn giữ nó mở, hệ thống tệp sẽ không giải phóng dung lượng cho đến khi tiến trình đóng handle (mức sử dụng dung lượng "ảo").

Với người dùng Linux, bạn có thể xác minh điều này bằng cách tìm các mục "deleted" trong danh sách file đang mở.

Trước tiên, xác định các file này:

sudo lsof | grep deleted Được hỗ trợ bởi

Các file Docker đã xóa

Sau đó, để giải phóng dung lượng, hãy khởi động lại tiến trình cụ thể (dùng PID từ lsof) hoặc khởi động lại Docker. Sau khi làm vậy, nếu bạn chạy lại lệnh, các file sẽ không còn xuất hiện nữa, nghĩa là chúng đã được xóa đúng cách.

Giờ hãy xem đến chiến lược xử lý sự cố nâng cao cuối cùng, chỉ áp dụng cho Docker Desktop: quản lý đĩa ảo.

Quản lý đĩa ảo Docker Desktop

Docker Desktop lưu dữ liệu trong một file đĩa ảo (.raw trên Mac, .vhdx trên Windows) tăng kích thước động nhưng không tự thu nhỏ khi bạn xóa dữ liệu. Bạn prune image và container, thấy dung lượng trống trong VM tăng, nhưng đĩa trên host vẫn đầy.

Để xử lý, cách an toàn nhất là dùng fstrim để nén gọn đĩa mà không mất dữ liệu:

docker run --privileged --pid=host alpine nsenter -t 1 -m -u -i -n fstrim /Được hỗ trợ bởi

Lệnh này trim hệ thống tệp của VM Docker Desktop, trả các block không dùng về máy chủ của bạn. Image, container và volume của bạn vẫn nguyên vẹn.

Ngoài ra, nếu bạn muốn bắt đầu hoàn toàn mới (thao tác này xóa tất cả dữ liệu), hãy dùng Docker Desktop Settings → Troubleshoot → Reset to factory defaults. 

Cảnh báo: Thao tác này mang tính hủy dữ liệu và xóa toàn bộ image, container, volume và cài đặt. Chỉ dùng như lựa chọn cuối cùng khi mọi cách khác đều thất bại.

Khôi phục cài đặt gốc

Bước 5: Phòng ngừa lỗi Docker “No Space Left on Device”

Sau khi xử lý khủng hoảng tức thời, hãy triển khai các thay đổi mang tính cấu trúc để ngăn tái diễn. Các cấu hình này cần lên kế hoạch nhưng mang lại lợi ích lớn cho độ ổn định hệ thống.

Di chuyển thư mục gốc dữ liệu Docker (chỉ Linux)

Người dùng Docker Desktop không thể dễ dàng thay đổi vị trí data root. Thay vào đó, bạn có thể:

• Tăng dung lượng đĩa: Dùng các phương pháp nén gọn đĩa ảo như mô tả ở Bước 4

• Với backend WSL2: Quản lý giới hạn qua file .wslconfig như hiển thị trong Docker Desktop Settings → Resources

Tuy nhiên, nếu bạn dùng Linux và phân vùng root bị hạn chế, nhưng có một phân vùng lớn hơn (có thể là đĩa dữ liệu riêng), di dời thư mục dữ liệu của Docker là giải pháp lâu dài.

Trước tiên, dừng Docker:

sudo systemctl stop dockerĐược hỗ trợ bởi

Chỉnh /etc/docker/daemon.json để chỉ định vị trí mới:

{
  "data-root": "/mnt/docker-data"
}Được hỗ trợ bởi

Di chuyển dữ liệu hiện có để giữ lại image và container của bạn:

sudo rsync -aP /var/lib/docker/ /mnt/docker-data/Được hỗ trợ bởi

Cuối cùng, khởi động lại Docker:

sudo systemctl start dockerĐược hỗ trợ bởi

Docker giờ sẽ lưu toàn bộ dữ liệu ở vị trí mới. Xác minh bằng docker info | grep "Docker Root Dir" để kiểm tra đường dẫn đến thư mục mới.

Cấu hình xoay vòng log toàn cục

Xoay vòng log là chiến lược phòng ngừa hiệu quả nhất mà tôi từng triển khai. Mặc định, driver json-file của Docker có max-size: -1 (không giới hạn), là mầm họa trong môi trường sản xuất.

Với cài đặt Linux native, chỉnh /etc/docker/daemon.json để áp dụng giới hạn toàn cục:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}Được hỗ trợ bởi

Sau khi chỉnh file, hãy khởi động lại Docker.

Với người dùng Docker Desktop, bạn không chỉnh trực tiếp /etc/docker/daemon.json. Thay vào đó:

1. Mở Docker Desktop
2. Vào Settings → Docker Engine
3. Bạn sẽ thấy trình soạn JSON với cấu hình daemon
4. Thêm thiết lập xoay vòng log vào JSON hiện có:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}Được hỗ trợ bởi

Cuối cùng, nhấp Apply & Restart.

Cấu hình ví dụ này giới hạn mỗi container ở 3 file log, mỗi file 10MB (tổng 30MB mỗi container).

Lưu ý quan trọng: Các thiết lập này chỉ áp dụng cho container được tạo mới. Container hiện có giữ cấu hình log ban đầu. Bạn phải tạo lại container để áp dụng giới hạn mới.

Để có khả năng nén tốt hơn và hiệu năng cao hơn, cân nhắc dùng driver logging local:

{
  "log-driver": "local",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3",
    "compress": "true"
  }
}Được hỗ trợ bởi

Ngoài ra, bạn cũng có thể ghi đè thiết lập log theo từng dịch vụ trong docker-compose.yml:

services:
  web:
    image: nginx
    logging:
      driver: "json-file"
      options:
        max-size: "50m"
        max-file: "5"Được hỗ trợ bởi

Tự động hóa bảo trì

Một thực hành tốt khác là tự động hóa một số quy trình. Phòng ngừa thường tốt hơn xử lý khủng hoảng. Do đó, tôi khuyến nghị tự động dọn dẹp bằng cron job chạy trong khung bảo trì:

# Create a cleanup script
sudo cat > /usr/local/bin/docker-cleanup.sh << 'EOF'
#!/bin/bash
docker system prune -f
docker builder prune -f --filter "until=168h"
EOF

sudo chmod +x /usr/local/bin/docker-cleanup.sh

# Add to crontab to run weekly on Sundays at 2 AM
echo "0 2 * * 0 /usr/local/bin/docker-cleanup.sh" | sudo crontab -Được hỗ trợ bởi

Script này tạo một tác vụ theo lịch tự động xóa container đã dừng và dữ liệu không dùng vào 2 giờ sáng Chủ Nhật hàng tuần. Nó cũng xóa an toàn các lớp build cache cũ hơn một tuần (168 giờ) để ngăn dung lượng đĩa tăng vô hạn.

Ngoài ra, tối ưu Dockerfile của bạn bằng multi-stage build để giảm kích thước image. Multi-stage build cho phép bạn dùng một stage để biên dịch và build (với đầy đủ công cụ phát triển nặng), rồi chỉ copy artifact cuối cùng sang stage sản xuất sạch, tối giản. 

Cách này loại bỏ phụ thuộc build, mã nguồn và file trung gian khỏi image sản xuất cuối, giúp giảm đáng kể kích thước và bề mặt tấn công.

# Build stage
FROM node:16 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build

# Production stage
FROM node:16-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
CMD ["node", "dist/index.js"]Được hỗ trợ bởi

Mẫu này giảm kích thước image sản xuất bằng cách loại trừ công cụ build và mã nguồn.

Kết luận

Khắc phục lỗi "no space left on device" theo một trình tự dễ dự đoán: chẩn đoán trước để hiểu bạn đang gặp vấn đề block đĩa hay inode, prune an toàn để thu hồi dung lượng mà không mất dữ liệu, rồi tối ưu cấu hình để ngăn tái diễn.

Qua nhiều năm quản lý môi trường Docker, tôi nhận thấy xoay vòng log là chiến lược phòng ngừa hiệu quả nhất. Một cấu hình daemon.json đơn giản có thể ngăn hầu hết sự cố cạn dung lượng.

Tôi khuyến khích bạn kiểm tra cấu hình daemon.json ngay bây giờ. Nếu bạn chưa đặt max-size và max-file cho driver logging, hãy bổ sung ngay. Bạn sẽ tự cảm ơn mình khi tránh được khủng hoảng dung lượng tiếp theo.

Sẵn sàng trở thành pro về Docker? Bước tiếp theo là đăng ký Containerization and Virtualization with Docker and Kubernetes, lộ trình kỹ năng mà tôi rất khuyến nghị.