Lỗi trùng lặp pool của Docker không phải vấn đề tuyến VPN

Docker từ chối tạo mạng với thông báo rằng pool trùng lặp với pool khác trong không gian địa chỉ này, và ai đó kết luận rằng tuyến VPN phải là nguyên nhân. Không thể như vậy. Lỗi đó được sinh ra trong khi một pool đang được cấp phát, trước khi có dù chỉ một gói tin, và một tuyến kernel thủ công không ảnh hưởng gì tới nó. VPN mới quan trọng ở bước sau, khi một container đã có địa chỉ trở nên không thể truy cập sau khi một tuyến xuất hiện. Hai vấn đề, hai bộ bằng chứng, và trộn chúng tạo ra một thay đổi không sửa được cái nào.

Hai lỗi trông giống nhau

Lỗi cấp phát là số học. Docker so sánh subnet bạn yêu cầu với các subnet nó đã quản lý, tìm thấy giao nhau và từ chối. Chưa có gì chạy, nên không có tuyến, không có container và không có lưu lượng để kiểm tra.

Triệu chứng lúc chạy là câu hỏi về khả năng truy cập. Một container trả lời hôm qua nay không trả lời, và có gì đó đã thay đổi trong bảng định tuyến của máy chủ. Container vẫn giữ địa chỉ của nó; câu hỏi là địa chỉ đó đi theo đường nào.

Cả hai đều là vấn đề quy hoạch địa chỉ. Chỉ một trong hai là vấn đề của Docker.

Đọc các pool đã cấp phát trước

Liệt kê các mạng và kiểm tra những mạng có thể giao nhau. Subnet nằm trong cấu hình IPAM, và các container gắn vào được liệt kê riêng:

docker network ls
docker network inspect EXISTING_NETWORK

So sánh subnet đó với pool mà mạng mới yêu cầu, và nhớ rằng Compose tạo mạng mặc định riêng cho từng dự án. Xung đột với một dự án bạn quên hệt như xung đột với daemon.

Một ipv4_address tĩnh trên dịch vụ là địa chỉ của một container, không phải định nghĩa pool. Đổi nó không xóa được trùng lặp, vì trùng lặp là giữa các subnet của mạng chứ không phải giữa các container. Tài liệu tham chiếu network-create của Docker yêu cầu các subnet không trùng lặp cho việc cấp phát cầu thông thường và ghi lại cách chọn một subnet một cách rõ ràng.

Chọn một tiền tố sống sót qua VPN

Xung đột trước mắt và tuyến trong tương lai được quyết định bởi cùng một lựa chọn, nên hãy chọn một lần. So sánh dải ứng viên với LAN, với mọi đích VPN mà máy chủ có thể tới, và với mọi overlay khác đang dùng.

Một tiền tố thỏa mãn Docker nhưng đụng mạng từ xa cho bạn một container khởi động sạch và trở nên không thể truy cập ngay khi đường hầm lên. Đó là lỗi thứ hai trong bài này, và khó chẩn đoán về sau hơn nhiều so với tránh ngay bây giờ.

Ghi các dải đã chọn ở nơi dự án tiếp theo có thể đọc. Một sổ đăng ký một dòng các tiền tố đã cấp phát rẻ hơn một tuần thời gian chờ không giải thích được.

Cho nghỉ hưu hoặc thay đổi mạng một cách có chủ đích

Với mạng Compose mới, đặt tiền tố chưa dùng trong cấu hình IPAM của mạng. Với dự án đang có, lập kế hoạch đánh số lại: địa chỉ cố định, dịch vụ phụ thuộc và bước tạo lại mạng đều phải được tính đến, vì sửa YAML không đánh số lại một mạng đang chạy.

Nếu một mạng cũ sở hữu việc cấp phát xung đột, hãy kiểm tra ai đang gắn vào trước khi gỡ nó. docker network rm từ chối khi còn endpoint hoạt động, và docker stop nhận tên hoặc ID container chứ không phải tên mạng. Dừng một container cũng không xóa định nghĩa mạng đang giữ pool.

Một prune rộng không phải công cụ chẩn đoán. Nó với tới các dự án không liên quan và phá hủy bằng chứng bạn sắp thu thập.

Pool mặc định chỉ giúp lần cấp phát kế tiếp

Cài đặt pool địa chỉ mặc định của daemon cải thiện các lần cấp phát tự động trong tương lai bằng cách giữ chúng ngoài các dải bạn dành riêng. Nó không gán lại địa chỉ cho các mạng đã tồn tại một cách hồi tố, và nó không giải quyết một subnet rõ ràng trùng lặp với một subnet rõ ràng khác.

Hãy coi cài đặt đó là một thay đổi riêng, có kế hoạch với lần khởi động lại riêng, không phải một phần của việc sửa một dự án. Trộn hai việc nghĩa là một lần khởi động lại daemon rơi vào giữa một cuộc điều tra không liên quan. Hãy lên lịch nó trong cửa sổ riêng. Sau đó xác nhận rằng một lần cấp phát tự động mới thực sự rơi ra ngoài các dải bạn đã dành riêng.

Khi tạo thành công, xác minh subnet thực sự đang chạy rồi thực hiện một yêu cầu ứng dụng thật với VPN ở trạng thái dự định. Nếu pool hợp lệ mà truy cập vẫn thất bại, công việc còn lại là chọn tuyến, lọc và đường về. Đó là một cuộc điều tra lúc chạy, và nó không làm cho lỗi cấp phát trở nên vô nghĩa một cách hồi tố.

Thứ tự công việc: đọc các pool đã cấp phát, chọn một tiền tố tránh cả Docker lẫn các đích VPN, tạo lại mạng một cách có chủ đích, rồi thử một yêu cầu khi đường hầm đã lên.