network_mode: service:vpn болон алга болсон db хост нэр

Та апп-д network_mode: service:vpn нэмж, стекийг дахин эхлүүлэхэд db цаашид шийдэгдэхгүй байгаа тул апп үхнэ. compose файлд юу ч дахин нэрлэгдээгүй тул илт сэжигтнүүд нь DNS ба өгөгдлийн сан юм. Бодит өөрчлөлт нь бага бөгөөд хачин: апп тэр нэр байгаа Compose сүлжээний гишүүн байхаа больсон. Өгөгдлийн сан аль нэрийн огторгуйгаас хариулах ёстойг шийдэх хүртэл хост нэрийн засвар бүр таамаг юм.

db хост нэр яагаад шийдэгдэхээ болив

network_mode ашигладаг үйлчилгээ Compose сүлжээнд өөрийн хаяггүй; тэр нэрлэсэн үйлчилгээний нэрийн огторгуйг зээлнэ. Тэр огторгуй өөрийн интерфэйс, маршрут, портын орон зай, шийдэгчийг авчирч, апп-ын backend сүлжээтэй холбоог орлуулна. db нэр хэзээ ч хийсвэр байгаагүй: тэр сүлжээнд амьдарч, түүний суулгасан DNS-ээр шийдэгддэг байв. Холбоог авбал нэр шийдэгдэх газаргүй болно.

Үүнийг хост биш, контейнеруудын дотроос баталгаажуулна уу. Апп-д бүтэлгүйтэж, өгөгдлийн сангийн контейнерт амжилттай болох хайлт нь нэр зөв, гишүүнчлэл буруу гэсэн үг. Энэ үр дүн засварыг апп-ын шийдэгчийн тохиргоо биш, compose топологид байрлуулна.

Файлыг засахаас өмнөх гурван асуулт

Тэдгээрт дарааллаар нь хариулна уу, учир нь тус бүр топологийг нарийсгана. Өгөгдлийн сан юунд хариулах ёстой: бусад контейнеруудын ашигладаг хост нэрэнд үү, эсвэл loopback дээрх апп-д л уу? Апп хост руу порт нийтлэх ёстой юу, аль үйлчилгээ түүнийг эзэмших вэ? Өгөгдлийн сан хост эсвэл өөр машинаас хүрэх боломжтой байх ёстой юу, эсвэл зөвхөн туннелийн дотроос уу?

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

Өгөгдлийн санг байгаа газарт нь үлдээнэ үү

Бага өөрчлөлт нь нэрийн огторгуйн эзнийг өгөгдлийн сан аль хэдийн агуулж буй сүлжээнд холбоно. Апп vpn стекийг хуваалцдаг тул тэр холбоог өвлөн авч, db яг өмнөх шигээ шийдэгдэнэ.

services:
  vpn:
    networks:
      - backend
  app:
    network_mode: service:vpn
  db:
    networks:
      - backend
networks:
  backend:

networks-г мөн апп-д бүү нэм. Compose нэг үйлчилгээнд network_mode-ын хажууд тэр шинж чанарыг татгалзаж, алдаа нь хосыг биш файлыг заана. Хэрэв VPN клиент өөрийн нэрийн огторгуйд backend очих газрыг шүүж байвал түүний дэмждэг орон нутгийн сүлжээний бодлогыг ч тохируулна уу; хуваалцсан холбоо зам санал болгодог ч тэр шүүлтийг хүчингүй болгодоггүй.

Өгөгдлийн санг нэрийн огторгуйд зөөнө үү

Том өөрчлөлт нь өгөгдлийн санг ижил нэрийн огторгуйд хийж, апп-ыг жинхэнэ порттой 127.0.0.1 руу чиглүүлнэ. Хоёр процесс зөвхөн өөр контейнерт эхэлсэн учраас ижил хаяг, портыг хоёулаа холбож чадахгүй тул wildcard хаяг дээр ч сонсдог өгөгдлийн сан үүнийг хийдэг бусад бүхэнтэй мөргөлдөнө. Зөөхөөс өмнө сонсогчийг шалгана уу.

Нийтэлсэн портууд нэрийн огторгуйг эзэмшдэг үйлчилгээнд хамаарна. Апп-д ports нэмэх нь network_mode-ын хамт татгалзагдаж, тусдаа апп хаяг зохиох нь байхгүй интерфэйсийг дүрсэлнэ.

Бэлэн байдал, блоклолт ба шийдэгч

depends_on контейнеруудын эхлэлийг цэгцэлнэ; энэ нь туннель ажиллаж байгаагийн баталгаа биш бөгөөд туннель унах үед урсгалыг зогсоодоггүй. Хүрэх боломж, туннелийн бэлэн байдал, алдааны блоклолтыг гурван тусдаа шаардлага гэж үзнэ үү. Зөвхөн эхнийхийг хангадаг стек сайн өдөр гарын туршилтад тэнцэж, муу өдөр алдаг. Гурван хариултыг compose файлын хажууд бичээрэй, дараагийн хүн тэндээс харна.

Нэрийн огторгуйг хуваалцах нь мөн апп VPN контейнерын шийдэгчийг өвлөн авна гэсэн үг бөгөөд туннель DNS серверүүдийг тулгах үед тусалж, тулгахгүй үед төөрөгдүүлнэ. Хост-ын шийдэгч хүчинтэй гэж таамаглахын оронд нэрийн огторгуйд үнэндээ юу байгааг шалгана уу. Compose үйлчилгээний лавлагаа нэг газарт network_mode, ports болон хамаарлын зан төлөвийг баримтжуулж, network_mode үйлчилгээ яагаад өөрийн хаяггүйг ч багтаана.