කන්ටේනරයට VPN-පමණක් API වෙත ළඟා විය නොහැකිද? එය සත්කාරකයේ ප්‍රොක්සි කරන්න

එකම යන්ත්‍රයේ බ්‍රවුසරය කිසිදු පැමිණිල්ලක් නොමැතිව විවෘත කරන API එකකට එරෙහිව ඔබේ Compose සේවාව කාල සීමාව ඉක්මවා යයි. එම වෙනසම සලකුණයි: වැඩ කරන ඉල්ලීම 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 එකේ ලියන්න. එසේ නොවුනහොත් මෙම කාල සීමාවට මුහුණ දෙන ඊළඟ පුද්ගලයාද ටනලය සත්කාරකයේ ජීවත් වන බව නැවත සොයා ගනිමින් එම දහවලම ගත කරනු ඇත.