Контейнер зөвхөн VPN-ээр хүрэх API-д хүрэхгүй байна уу? Үүнийг хост дээр прокси хий

Туннель хост дээр амьдардаг тул контейнерт хувийн хаяг руу явах зам байхгүй. Нарийн урвуу прокси нийтэлж, үүнийг host.docker.internal гэж дууд.

Таны Compose үйлчилгээ нэг машин дээрх хөтөч ямар ч гомдолгүй нээдэг API-тай харьцахад хугацаа хэтэрдэг. Тэр ялгаа нь сэжүүр: ажиллаж буй хүсэлт VPN туннельтай хостээс гардаг, харин гацдаг хүсэлт өөрийн сүлжээний стектэй контейнерээс гардаг. Контейнерийн дотор юу ч туннелийн замыг мэдэхгүй тул нэрийг хэрхэн бичсэн ч хувийн очих газар хүрэхгүй хэвээр байна. Шийдэл нь хостээр дамжуулсан санаатай үсрэлт бөгөөд илүү ухаантай маршрутын хүснэгт биш.

Хоёр зам яагаад ялгаатайгаас эхэлж, дараа нь туннель хаана амьдрах ёстойг шийд.

Хост яагаад ажилладаг, контейнер яагаад үгүй

Туннель босгох нь хостод интерфэйс, замын багц, ихэвчлэн VPN-ийн өгдөг шийдвэрлэгчийн бичлэг өгдөг. Контейнер үүнээс юу ч өвлөдөггүй: энэ нь хөдөлгүүрийн гүүрэн дээр нэг интерфэйс, тэр гүүр рүү чиглэсэн анхдагч замтай эхэлдэг. Хост дээр суулгасан замууд тэр нэрийн орон зайн дотор ажиллаж буй бүхэнд үл үзэгдэх юм.

Тиймээс шинж тэмдгүүд зүгээр эвдэрсэн биш, зөрчилтэй харагддаг. Хост хувийн нэрийг шийдэж холбогддог, учир нь тэнд нэр болон зам хоёулаа бий. Контейнер гүүрэн замаар юу ч хүрч чадахгүй хувийн хаяг руу пакетаа илгээж, хүсэлт хугацаа хэтэрдэг. Контейнерийн hosts файлд нэрийг нэмэх нь юу ч өөрчлөхгүй, учир нь хаяг өөрөө контейнер байгаа газраас хүрэхгүй.

Контейнерийн дотроос хост руу хүр

Контейнер доторх процесс localhost-ийг залгавал контейнерийг өөрөө залгаж байна. Docker Desktop host.docker.internal-ийг хөдөлгүүр ажиллуулж буй машин руу буцааж заасан нэр болгон нийтэлдэг; Linux хөдөлгүүрүүд үйлчилгээ гуйхгүй л бол үүнийг тодорхойгүй орхидог бөгөөд доорх буулгалт яг үүнийг хийдэг. Үүгээр апп хувийн хаягийн оронд нэр, портыг зорьдог.

services:
  app:
    extra_hosts:
      - "host.docker.internal:host-gateway"
    environment:
      INTERNAL_API_HOST: "host.docker.internal:8666"

Туннель үсрэлтийн хост талд үлддэг бөгөөд тэр хувьсагч дахь порт нь прокси сонсох порт юм. Туннелээ алдсан контейнер одоо хэзээ ч байгаагүй замыг туршихын оронд нэг мэдэгдэх үсрэлт дээр бүтэлгүйтдэг.

Туннель хаана амьдрахыг сонго

Хувийн API хэрэгтэй Compose үйлчилгээнд гурван хэлбэр боломжтой бөгөөд аль процесс туннелийг эзэмшиж байгаагаараа ялгаатай. VPN клиент контейнерийн дүрс дотор ажиллаж болох бөгөөд энэ нь туннелийн төхөөрөмжийг ил гаргаж, түүнтэй хамт ирэх сүлжээний удирдлагын чадварыг өгөхийг шаарддаг. Апп тусдаа туннель контейнерийн сүлжээний нэрийн орон зайг хуваалцаж болно, ингэснээр хоёр процесс нэг стек, нэг маршрутын хүснэгт харна. Эсвэл туннель хост дээр үлдэж, хостээс контейнер руу нарийн дамжуулагчтай байж болно.

Эхний хоёр нь профайл файл, дахин холбогдох зан төлөв, шийдвэрлэгчийн бодлогыг төсөлд татаж, файл дахь үйлчилгээ бүрийг туннелийн эрүүл мэндээс хамааралтай болгодог. Нэг API дуудлагад энэ хэтэрхий их холболт юм. Нэг дотоод төгсгөлийн цэг уншдаг хөгжүүлэлтийн стект платформын баг удирддаг газарт нь итгэмжлэлийг үлдээдэг хамгийн бага өөрчлөлт бол хост талын дамжуулагч юм.

Хост дээр нэг нарийн зам нийтэл

Дамжуулагч өвлөдөг зүйлээс эхэл: туннелийг эзэмшдэг бүртгэлээр ажиллуул, тэгвэл түүний гадагш чиглэсэн сокетууд хост-ийн замууд болон хост-ийн шийдвэрлэгчийг авна. nginx-ийн нэг location блок нэг замыг хамардаг.

server {
    listen 8666;
    location /search/ {
        proxy_pass http://10.20.30.40:8090/;
        proxy_set_header Host internal-api.example;
        proxy_read_timeout 60s;
    }
}

Хаяг болон портыг түр орлуулагч гэж үзэж, API үнэхээр сонсдог хосыг тавь. Нэмэлт upstream бүр өөрийн location блоктой байх ёстой бөгөөд блок бүр зөвхөн энэ үйлчилгээ дууддаг замуудыг нэвтрүүлэх ёстой, ингэснээр прокси хувийн сүлжээ рүү ерөнхий хаалга болохгүй. Сонсогчийг host-gateway-ээр ирж буй клиентүүдэд гүүрэн хаягт, клиент хост-ийн сүлжээний нэрийн орон зайг хуваалцаж байгаа үед л loopback-т, хэзээ ч 0.0.0.0-д холбохгүй. Мөн чөлөөтэй байгаа порт сонго: аль хэдийн эзэлсэн дугаар проксийг сонсохгүй орхиж, контейнер хугацаа хэтэрсээр байх бөгөөд үүнийг таны эхэлсэн сүлжээний гэмтлээс ялгах боломжгүй.

Портууд, нэрс ба TLS шийдвэр

Нэрийн шийдэл нь маршрут шиг л хуваагдана. Контейнерийн нийтийн хайлтууд хөдөлгүүрийн шийдвэрлэгчээр дамждаг тул хост дээр шийдэгддэг хувийн нэр контейнерийн дотор шийдэгдэхгүй. Прокси нь хувийн нэрийг шийддэг бүрэлдэхүүн хэсэг, учир нь хост-ийн шийдвэрлэгчийг өвлөдөг.

TLS бол хойшлуулагдаж, дараа нь дараагийн алдааг тайлбарладаг шийдвэр. Прокси байтуудыг хөндөхгүй дамжуулбал контейнер API-ийн өөрийн гэрчилгээг харж, итгэлцлийн сандаа дотоод CA хэрэгтэй болно. Прокси TLS-ийг дуусгавал тэр итгэлцэл хост руу шилжиж, апп хүлээн авсан host толгойгоос холбоос бүтээж эхэлнэ. Нэг зохион байгуулалт сонгоод бүх нөөцөд хэрэглэ, учир нь нөгөөгийн гаргасан чиглүүлэлт контейнер шийдэж чадахгүй хост нэр рүү заадаг.

Үйлчилгээний дотроос шалга

Хүсэлтийг хостээс биш, контейнерээс илгээ: прокси замын энгийн curl, дараа нь аппын өөрийн эрүүл мэндийн шалгалт. Прокси хариулж байтал апп бүтэлгүйтсээр байвал гурван зүйлийг харьцуул: аппын бүтээж буй үндсэн URL, орчинд байгаа прокси хувьсагч, аппын итгэдэг CA. Бүгд контейнерийн орчин, лог дотор байдаг бөгөөд аль нэгийг нь зассад VPN хөндөгдөхгүй.

Сонгосон зохион байгуулалтыг төслийн README-д шинэ байхад нь бич. Эс бөгөөс энэ хугацаа хэтэрэлтэй таарсан дараагийн хүн туннель хост дээр амьдардаг гэдгийг дахин нээхэд мөн адил үдээс хойшийг өнгөрөөнө.

Холбоотой нийтлэлүүд