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 не мае ўласнага адраса.