Docker: định tuyến một container qua VPN và giữ container kia kết nối trực tiếp

Một máy chủ, hai khối lượng công việc và một yêu cầu chia tách chúng: một ứng dụng tải xuống phải đi ra qua VPN thương mại, và một giao diện quản trị phải tiếp tục dùng kết nối của máy chủ. Cài ứng dụng VPN trên máy chủ sẽ vi phạm yêu cầu ngay lập tức, vì khi đó cả hai khối lượng công việc dùng chung một lối ra. Mẫu thực sự hoạt động là chuyển đường hầm vào container riêng và chỉ cho những khối lượng công việc cần đến nó tham gia không gian tên mạng của container đó. Mọi thứ khác giữ con đường Docker thông thường, và những chi tiết tiếp theo là hệ quả của việc ai sở hữu không gian tên.

Tại sao không gian tên dùng chung lại thay đổi luật chơi

Một container tham gia không gian tên của container khác không có ngăn xếp mạng riêng. Nó thấy cùng các giao diện, cùng bảng định tuyến và cùng loopback như container mà nó tham gia, và chính vì thế mẫu này hữu ích: khối lượng công việc phân giải và kết nối bình thường, còn đường hầm bên dưới bắt lấy lưu lượng mà ứng dụng không hay biết. Cái giá là mọi thiết lập liên quan đến mạng nay chỉ có một chủ sở hữu, và container tham gia không phải chủ đó.

Quy tắc sở hữu này trả lời phần lớn câu hỏi cấu hình trước khi chúng được đặt ra. Nếu một thiết lập sống trong ngăn xếp mạng, nó thuộc về container phụ. Nếu nó mô tả tiến trình, nó ở lại với khối lượng công việc.

Loopback là phần khiến người ta ngạc nhiên. Bên trong container tham gia, localhost được phân giải thành loopback của container phụ, không phải loopback riêng của chính nó, nên một dịch vụ gắn vào 127.0.0.1 với mong đợi cách ly nay chia sẻ địa chỉ đó với container đường hầm.

Công bố cổng trên container sở hữu không gian tên

Ánh xạ cổng thuộc về chủ sở hữu không gian tên, kể cả khi tiến trình lắng nghe chạy trong container kia. Hãy khai báo ánh xạ trên container phụ, và để khối lượng công việc giữ nguyên cấu hình tiến trình của nó. Ánh xạ trên dịch vụ tham gia không thể có hiệu lực, dù công cụ từ chối nó hay lặng lẽ bỏ qua tùy theo cách container được khởi động, và đó là lý do một giao diện vừa truy cập được lúc trước biến mất ngay khi mẫu được áp dụng.

services:
  gluetun:
    image: qmcgaw/gluetun
    cap_add: [NET_ADMIN]
    ports: ["8080:8080"]
  client-vpn:
    image: example/client
    network_mode: "service:gluetun"
  client-direct:
    image: example/client
    ports: ["8081:8080"]

Hãy đọc khối đó như ba quyết định chứ không phải ba dịch vụ. Container phụ sở hữu đường hầm và cổng đã công bố; ứng dụng tham gia không khai báo mạng nào cả; ứng dụng trực tiếp giữ ánh xạ riêng trên mạng mặc định. Khả năng NET_ADMIN là thứ cho phép container phụ tạo giao diện và thay đổi tuyến đường, và đó là lý do container này cần nhiều quyền hơn các khối lượng công việc mà nó phục vụ.

Dịch vụ vẫn trực tiếp giữ mạng riêng của nó

Khối lượng công việc không được đi qua đường hầm giữ cầu mặc định hoặc mạng do người dùng định nghĩa riêng, với cổng đã công bố và lối ra riêng. Thật hấp dẫn khi gắn nó vào mạng của container phụ để hai container nói chuyện được bằng tên, nhưng chính bước đó lại lặng lẽ chuyển lưu lượng của nó vào đường hầm. Nếu chúng cần đến nhau, hãy tạo một mạng do người dùng định nghĩa riêng, gắn cả hai vào đó, và để container phụ là con đường duy nhất ra ngoài.

Hãy tách hai câu hỏi: container nào đến được nhau, và container nào đi ra ở đâu. Gộp chúng lại chính là cách phổ biến nhất khiến thiết kế này trở lại thành VPN cho toàn bộ máy chủ.

Ma trận sự cố cho giờ đầu tiên

Phần lớn lần thử đầu tiên thất bại theo một trong bốn cách, và mỗi cách có nguyên nhân khác nhau. Hãy kiểm tra theo thứ tự này, vì hai cách đầu giải thích gần như mọi báo cáo.

Hàng thứ tư là thứ người ta chẩn đoán nhầm thành lỗi ứng dụng. Một phép kiểm tra viết theo loopback riêng của khối lượng công việc nay đang kiểm tra container đường hầm, nên nó hoặc thất bại hoặc báo về một dịch vụ hoàn toàn sai.

Khi một tên máy chủ cần đường hầm

Đôi khi đường hầm đầy đủ là quá nhiều: một tên nội bộ phải đi qua VPN doanh nghiệp trong khi socket cục bộ hoặc kết nối màn hình vẫn hoạt động. Đường hầm đầy đủ bên trong container phá vỡ con đường đó và mọi thứ hướng đến máy chủ, nên chỉ định tuyến tiền tố cần đến nó. Một lớp bọc định tuyến chia tách quanh ứng dụng làm điều đó, gửi máy chủ được chỉ định qua đường hầm và để nguyên tuyến trước đó cho mọi thứ khác.

Chọn cách này khi bạn chỉ cần đến một dịch vụ và không cố chuyển toàn bộ lưu lượng của container. Đây là công cụ khác với container phụ và trả lời một câu hỏi khác.

Hãy xác minh, rồi làm cho nó sống sót qua lần khởi động lại

Hỏi từng container xem nó dường như đến từ địa chỉ nào. Cái trong đường hầm phải in ra địa chỉ của nhà cung cấp và cái trực tiếp in ra lối ra của máy chủ. Câu trả lời giống nhau nghĩa là dịch vụ trực tiếp đã thừa hưởng sai không gian tên hoặc VPN ở cấp máy chủ vẫn đang bắt toàn bộ, và hai bản sửa đó khác nhau. Chạy lại phép kiểm tra sau mỗi lần sửa compose, vì chỉ một khối dịch vụ bị sao chép là đủ để tái diễn vấn đề.

Ba thứ thường hỏng về sau. DNS đi theo chủ sở hữu không gian tên, nên thiết lập bộ phân giải và miền tìm kiếm thuộc về container phụ chứ không phải máy chủ. VPN có chuyển tiếp cổng đổi cổng lắng nghe khi kết nối lại, nên cổng được nhà cung cấp chuyển tiếp và cổng lắng nghe phía container phải được ghi lại vào cấu hình ứng dụng hoặc ánh xạ cổng, thường nhờ một trình cập nhật nhỏ đọc API của nhà cung cấp. Và mọi phép kiểm tra viết theo localhost nay hỏi container đường hầm chứ không phải khối lượng công việc.

Hãy ghi lại mẫu, kể cả container nào sở hữu không gian tên và những cổng nào thuộc về nó. Người tiếp theo sẽ thêm một dịch vụ, sao chép sai khối và tái tạo sự cố đầu tiên trong bài viết này.