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 సేవకు సొంత చిరునామా ఎందుకు లేదో కూడా కలిపి.