Làm ngay trong 5 phút (Quick Start)
Muốn “bê” gấp một container từ Server A sang Server B mà không muốn lằng nhằng qua Docker Hub? Đây là lộ trình ngắn nhất để bạn thực hiện trong vài nốt nhạc. Giả sử container của bạn tên là web_app và dữ liệu nằm ở volume web_data.
- Tại Server cũ: Cho container “hạ cánh an toàn” để tránh lỗi corrupt dữ liệu khi copy.
docker stop web_app docker commit web_app web_app_backup docker save -o web_app_image.tar web_app_backup - Bắn file sang Server mới: Dùng
rsyncđể tận dụng khả năng nén và tiếp tục nếu mất mạng.rsync -avzP web_app_image.tar [email protected]:/root/ - Tại Server mới: Nạp lại image và chạy.
docker load -i web_app_image.tar docker run -d --name web_app web_app_backup
Đó là kịch bản màu hồng. Thực tế, nếu ứng dụng của bạn có Volume (dữ liệu), việc chỉ chuyển Image chả khác nào dọn sang nhà mới mà bỏ lại toàn bộ nội thất ở nhà cũ cả.
Tại sao phải làm thủ công khi đã có Docker Registry?
Dùng Docker Hub hay Private Registry thì quá nhàn rồi. Nhưng trong giới làm hệ thống, bạn sẽ sớm đụng phải những ca “khó đỡ” buộc phải dùng tay chân:
- Môi trường Air-gapped: Server nằm trong mạng nội bộ, bị “cắt cơm” internet hoàn toàn.
- Bảo mật ngặt nghèo: Image chứa cấu hình nhạy cảm, mã nguồn độc quyền không được phép đẩy lên bất kỳ cloud nào.
- Sửa “nóng” (Hotfix): Bạn lỡ nhảy vào container sửa vài dòng code trực tiếp và ngại việc phải build lại Dockerfile từ đầu.
- Tiết kiệm băng thông: Chuyển file 2GB qua mạng LAN 1Gbps nhanh hơn nhiều so với việc upload rồi download từ Registry.
Quy trình di chuyển an toàn: Chậm mà chắc
Bước 1: Đóng gói phần “Xác” (Container Image)
Nhiều bạn cứ thế docker save image gốc từ Docker Hub về. Sai lầm! Nếu bạn đã cài thêm tool hay sửa config bên trong container, những thay đổi đó sẽ bốc hơi sạch. Lệnh commit mới là chìa khóa.
# Chụp ảnh trạng thái hiện tại của container thành image mới
docker commit web_app web_app_migrated:v1
# Xuất ra file tar
docker save -o web_app_migrated.tar web_app_migrated:v1Lưu ý: commit chỉ đóng gói tầng layer có thể ghi (writable layer), nó hoàn toàn không đụng chạm gì đến dữ liệu nằm trong Volume.
Bước 2: Di dời phần “Hồn” (Volume Data)
Dữ liệu mới là thứ đáng giá nhất. Đầu tiên, hãy soi xem volume đang nằm ở đâu trên ổ cứng:
docker inspect web_app | grep -A 10 "Mounts"Khi đụng phải mấy đoạn JSON loằng ngoằng này, mình thường dùng JSON Formatter để định dạng lại cho dễ nhìn, đỡ mỏi mắt tìm đường dẫn Source.
Thường thì dữ liệu nằm ở /var/lib/docker/volumes/. Hãy dùng rsync thay vì scp. Tại sao? Vì rsync bảo toàn được quyền sở hữu (owner) và permissions – thứ cực kỳ quan trọng để Database như MySQL 8.0 không bị lỗi “Permission denied” khi khởi động ở máy mới.
# Đẩy folder dữ liệu sang server mới, giữ nguyên quyền hạn file
rsync -avzP /data/my_app/ [email protected]:/data/my_app/Xử lý khi dữ liệu nặng hàng chục GB
Nếu volume của bạn nặng tầm 50GB trở lên, rsync đơn thuần có thể mất cả tiếng. Kinh nghiệm xương máu của mình là dùng zstd để nén. Nó nhanh hơn gzip gấp 3 lần và tỷ lệ nén cực tốt.
tar -I zstd -cf web_data.tar.zst /var/lib/docker/volumes/my_volume/_data
rsync -avzP web_data.tar.zst [email protected]:/root/Tại server mới, sau khi giải nén, hãy check lại UID/GID. Nếu máy cũ dùng user mysql có ID 999, máy mới cũng phải tương ứng để container đọc được file.
Vài lưu ý “nhỏ nhưng có võ”
- Check ổ cứng: Một file tar 5GB có thể làm đầy phân vùng
/rootnếu bạn không để ý. Hãydf -htrước khi chạy lệnh. - Lôi kéo Docker Compose theo: Đừng cố nhớ lệnh
docker rundài 5 dòng. Hãy copy filedocker-compose.ymlsang máy mới, sửa tên image là xong. - Đối chiếu dung lượng: Chạy
du -shở cả hai server sau khi copy. Nếu lệch dù chỉ vài KB, hãy kiểm tra lại log củarsyncngay. - Dọn rác: Xong việc thì xóa ngay file
.tar. Đừng để chúng chiếm dụng tài nguyên máy chủ vô ích.
Di chuyển Docker kiểu thủ công không hề lạc hậu. Đó là kỹ năng sinh tồn cần thiết khi bạn không thể dựa dẫm vào Cloud hay Registry bên thứ ba. Chỉ cần tỉ mỉ với rsync và save/load, bạn sẽ làm chủ hoàn toàn hệ thống của mình.
