Đổi pool mặc định của Docker không đánh số lại các mạng

Đổi default-address-pools không đánh số lại các mạng bạn đã có, và chính kỳ vọng đó là cách một kế hoạch cẩn thận biến thành sự cố bất ngờ. Cấu hình này chi phối việc cấp phát tự động cho các mạng được tạo sau khi daemon khởi động lại với cấu hình mới. Mọi thứ đang chạy vẫn giữ nguyên subnet đã được cấp, vì subnet đó là một phần trong định nghĩa lưu trữ của mạng. Huyền thoại này tiện lợi vì nó gợi ý rằng một chỉnh sửa duy nhất sửa mọi chồng lấn, còn thực tế là công việc hai phần: chọn một dải thực sự trống, rồi chuyển các mạng không trống.

Huyền thoại: một thay đổi pool sửa được chồng lấn

Huyền thoại có một hình dạng cụ thể. Ai đó đọc rằng pool mặc định của Docker có thể thay đổi, đổi nó, khởi động lại daemon và kết luận rằng mạng container không còn xung đột với VPN văn phòng. Mạng cũ vẫn ở đó, vẫn được gắn và vẫn giữ địa chỉ xung đột.

Điều đã thay đổi là hành vi tương lai của bộ cấp phát, vốn thực sự hữu ích và thực sự hạn chế. Các mạng mới tạo mà không có --subnet rõ ràng được cắt ra từ pool mới; các mạng hiện có chưa bao giờ nằm trong pool đó. Khởi động lại không dựng lại mạng và không di chuyển container giữa chúng. Nếu triệu chứng vẫn còn sau thay đổi, thì thay đổi là thật và chẩn đoán chưa đầy đủ.

Dải cơ sở và tiền tố được cấp

Cấu hình có hai trường dễ nhầm lẫn. base là dải mà bộ cấp phát cắt ra, còn size là độ dài tiền tố của mỗi mạng được cấp, nên một cơ sở 10.10.0.0/16 với kích thước 24 chia các /24 bên trong /16 đó. Đảo ngược vai trò sẽ tạo ra một mẫu cấp phát mà bạn không định, thường là một mạng khổng lồ hoặc một pool cạn kiệt.

Pool là một sự đặt trước, không phải bằng chứng. Docker tránh các xung đột mà nó thấy trong bảng định tuyến của máy chủ, và nó không thể thấy một VPN mà bạn chưa kết nối.

Hạn chế đó chính là toàn bộ lý do để chọn một cách có chủ đích. Các dải để so sánh là những dải mà máy chủ phải tới được: LAN văn phòng, các subnet nội bộ của VPN doanh nghiệp, các tiền tố lab hoặc staging và bất kỳ máy chủ container nào khác trên cùng overlay. Hãy viết chúng dưới dạng CIDR trước khi chạm vào daemon, vì một danh sách trong đầu sẽ bỏ sót đúng cái quan trọng. Sau đó chọn một cơ sở không chồng lấn với bất kỳ dải nào, và giữ danh sách cùng với triển khai để người sau không lặp lại bài tập từ trí nhớ.

Kiểm kê trước khi chọn

Trước hết hãy kiểm kê những gì đang tồn tại. docker network ls liệt kê các mạng, và docker network inspect bridge -f '{{.IPAM.Config}}' in ra subnet mà một mạng cụ thể đang dùng. Lặp lại cho mọi mạng do người dùng định nghĩa, vì các dự án Compose tạo mạng riêng và một --subnet rõ ràng trong tệp compose bỏ qua pool hoàn toàn.

Điểm cuối cùng đó là điểm sống sót qua cuộc chuyển đổi. Thay đổi pool không ngăn đồng nghiệp ghim 172.18.0.0/16 trong tệp compose, và xung đột quay lại với một tác giả khác.

Chuyển những gì đã tồn tại

Chuyển các mạng hiện có là một thao tác riêng và được hỗ trợ. Mỗi mạng bị ảnh hưởng phải được tạo lại với subnet mới, nghĩa là tháo và gắn lại các container dùng nó, và việc tạo lại một mạng sẽ xóa các gắn kết container thay vì di chuyển chúng. Giữ nguyên volume và cấu hình, và coi việc tạo lại là một lần triển khai chứ không phải đặt lại dữ liệu. Hãy làm trong một cửa sổ bảo trì, vì các container trên mạng được tạo lại sẽ khởi động lại dù bạn có dự tính hay không.

Hãy theo cấu hình daemon và quy trình khởi động lại đã được ghi tài liệu, và phối hợp gián đoạn. Trên máy chủ một daemon, systemctl restart docker khởi động lại container theo chính sách khởi động lại của chúng, và đó là hành vi nên biết trước chứ không phải sau.

Sau đó xác minh hai điều mà thay đổi lẽ ra phải sửa. Kiểm tra subnet mới bằng docker network inspect và xác nhận nó nằm trong cơ sở đã chọn, rồi kiểm tra tuyến tới một đích VPN đại diện bằng ip route get 10.20.30.40 và xác nhận nó đi tới nơi bạn mong đợi chứ không vào một bridge. Cũng hãy thử khám phá dịch vụ và giao tiếp giữa container, vì một mạng được tạo lại với địa chỉ khác có thể phá vỡ phân giải tên theo cách trông như lỗi ứng dụng.

Điều gì vẫn hỏng sau đó

Phần bền vững là bản ghi. Giữ danh sách cấp phát, cơ sở và kích thước đã chọn, và các mạng được tạo lại ở cùng nơi với triển khai.

Việc một dải là riêng tư không khiến nó an toàn để dùng lại. 10.0.0.0/8 là riêng tư và đồng thời là thứ dễ đã được dùng ở đâu đó trên đường đi nhất, nên câu trả lời là một sự đặt trước cụ thể chứ không phải thiên vị một khối. Tài liệu mạng của Docker mô tả việc cấp subnet tự động và các trường của pool. Chọn dải theo điều bạn phải tới được, không theo điều trông gọn gàng.