Podman pasta: rootless കണ്ടെയ്നറിൽ നിന്ന് ഹോസ്റ്റ് ലൂപ്പ്ബാക്ക് പ്രോക്സിയിലേക്ക് എത്തുക

നിലവിലുള്ള ലൂപ്പ്ബാക്ക് പ്രോക്സിക്ക് pasta യുടെ namespace-to-host TCP ഫോർവേഡിംഗ് ഉപയോഗിക്കുക, കൂടാതെ കണ്ടെയ്നർ പോർട്ട് പ്രസിദ്ധീകരിക്കുന്നതിൽ നിന്ന് ഇതിനെ വേർതിരിക്കുക.

ഹോസ്റ്റിന്റെ 127.0.0.1:8118 ഉം കണ്ടെയ്നറിന്റെ 127.0.0.1:8118 ഉം സാധാരണയായി വേറിട്ട ലൂപ്പ്ബാക്ക് എൻഡ്പോയിന്റുകൾ ആണ്. rootless കണ്ടെയ്നറിലേക്ക് പ്രോക്സി വേരിയബിൾ കൈമാറുന്നത് ആ ലൂപ്പ്ബാക്ക് ഇന്റർഫേസുകളെ ബന്ധിപ്പിക്കുന്നില്ല.

pasta ഉപയോഗിക്കുന്ന Podman വിന്യാസത്തിൽ, അതിന്റെ namespace-to-host TCP ഫോർവേഡിംഗിന് ഉദ്ദേശിച്ച ഹോസ്റ്റ് പോർട്ട് namespace-നുള്ളിൽ തുറന്നുകാണിക്കാം:

podman run --network=pasta:-T,8118 \
  --env http_proxy=http://127.0.0.1:8118 \
  --env https_proxy=http://127.0.0.1:8118 \
  existing-image application-command

ആപ്ലിക്കേഷന്റെ നിലവിലുള്ള ഇമേജും കമാൻഡും ഉപയോഗിക്കുക. ഹോസ്റ്റ് വശത്ത് 8118 പോർട്ടിൽ പ്രവർത്തിക്കുന്ന HTTP പ്രോക്സിയും കാണിച്ചിരിക്കുന്ന ഫോർവേഡിംഗ് ഓപ്ഷൻ പിന്തുണയ്ക്കുന്ന Podman/pasta പതിപ്പും ഉണ്ടെന്ന് ഉദാഹരണം അനുമാനിക്കുന്നു.

pasta യുടെ വലിയ -T ലക്ഷ്യ namespace-ൽ നിന്ന് ഹോസ്റ്റ് namespace-ലേക്ക് ഫോർവേഡ് ചെയ്യുന്നു. ചെറിയ -t ഉം Podman ന്റെ --publish ഉം വിപരീത ദിശയിലാണ്. അതിനാൽ കണ്ടെയ്നർ പോർട്ട് 8118 പ്രസിദ്ധീകരിക്കുന്നത് സ്വയം ഹോസ്റ്റിന്റെ പ്രോക്സിയെ കണ്ടെയ്നറിന് ലഭ്യമാക്കുന്നില്ല.

Podman സ്വതവേ namespace-ൽ നിന്ന് ഹോസ്റ്റിലേക്കുള്ള യാന്ത്രിക പോർട്ട് ഫോർവേഡിംഗ് അപ്രാപ്തമാക്കുന്നു; വ്യക്തമായ പോർട്ട് ഇവിടെ ആവശ്യമായ സേവനം തിരഞ്ഞെടുക്കുന്നു. വേറിട്ട pasta:--map-gw ഓപ്ഷൻ ഗേറ്റ്വേ വിലാസത്തിലൂടെ ഹോസ്റ്റിലേക്ക് എത്തുന്നതിനെക്കുറിച്ചാണ്, അത് മറ്റൊരു ക്രമീകരണമാണ്.

Compose-നൊപ്പം യഥാർത്ഥ ദാതാവും സൃഷ്ടിച്ച നെറ്റ്വർക്ക് കോൺഫിഗറേഷനും പരിശോധിക്കുക. പേരുള്ള ബ്രിഡ്ജ് നെറ്റ്വർക്ക് സ്വയം pasta namespace ആകുന്നില്ല, ഒരു സ്വതന്ത്ര podman run കമാൻഡ് pasta വിജയകരമായി ഉപയോഗിച്ചു എന്ന കാരണത്താൽ മാത്രം. ഒരു റിമോട്ട് Podman എഞ്ചിനും “ഹോസ്റ്റ്” എഞ്ചിന്റെ സ്ഥാനത്ത് വയ്ക്കുന്നു.

അനുബന്ധ ലേഖനങ്ങൾ