docker image prune báo thu hồi 0 B — nhưng vùng lớn nhất vẫn còn nguyên ở chỗ khác
Dựng một hệ thống bừa bộn rồi chạy từng lệnh prune, đo dung lượng thật thu hồi được sau mỗi lệnh. Hai cái bẫy lộ ra ngay.
#docker-compose
69 bài viết
Tôi tar nóng một volume PostgreSQL đang ghi giữa chừng rồi khôi phục — nó chạy, 0 dòng hỏng, nhưng con số dừng ở một mốc tôi không chọn
Ba cách sao lưu volume, đo thời gian và dung lượng từng cách. Phép thử cái bẫy sao lưu nóng cho kết quả ngược lời đồn — và ba lý do thật sự khiến nó vẫn nguy hiểm.
Tệp do container tạo ra lại thuộc về root và bạn không xoá nổi: nhân Linux chỉ ghi một con số, còn cái tên là chuyện của mỗi bên
Vì sao build trong container xong thì tệp trên máy chủ thuộc về root và bạn không sửa được, bốn cách vá đã đo, và cái bẫy khi dùng --user với một uid không có tên.
Trên Mac, bind mount stat 3.000 tệp chậm gấp 87 lần volume — nhưng ghi tuần tự thì ngang nhau
Đo tệp nhỏ, siêu dữ liệu và fsync trên hai nền tảng. Kèm hai lời khuyên phổ biến bị số đo bác bỏ.
Gắn volume rỗng vào nginx thì cấu hình mặc định còn nguyên, gắn thư mục rỗng thì mất sạch: ba kiểu lưu trữ Docker và chỗ chúng cư xử ngược nhau
Ba kiểu lưu trữ của Docker: cái gì sống sót khi xoá container, ai sở hữu tệp, vì sao volume rỗng được nạp mồi còn bind mount thì che thẳng, và vì sao -v với --mount không tương đương.
Ba container hỏng ba kiểu, một mã lỗi duy nhất — cái thang tách chúng ra từng bậc
Dựng sẵn bốn container hỏng theo bốn kiểu rồi chạy thang chẩn đoán. Kèm cách gỡ lỗi container distroless không có shell.