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 ਸੇਵਾ ਦਾ ਆਪਣਾ ਪਤਾ ਕਿਉਂ ਨਹੀਂ ਇਹ ਵੀ ਸਮੇਤ।