GitHub Actions உங்கள் VPN-ஐ அடையவில்லை: சொந்த runner அல்லது சுரங்கம்

உங்கள் deploy படி ஒரு உள் hostname-இல் தொங்குகிறது, அதே கட்டளை உங்கள் மடிக்கணினியிலிருந்து உடனே பதில் தருகிறது, இரண்டு இயந்திரங்களிலும் client build ஒரே மாதிரி உள்ளது. job GitHub-ஹோஸ்ட் செய்த runner-இல் இயங்குகிறது: அந்த ஒரு job-க்காக GitHub-இன் மேகத்தில் உருவாக்கப்பட்ட மெய்நிகர் இயந்திரம், உங்கள் தனியார் முகவரி வெளியில் எந்த வழித்தடமும் இல்லை, உள் மண்டலத்துக்கு resolver பதிவு இல்லை, தனியார் endpoint ஏற்கும் சான்றிதழும் இல்லை. இந்த கட்டுப்பாட்டுக்குள் இரண்டு வடிவமைப்புகள் மட்டுமே பொருந்தும், workflow-ஐ மீண்டும் கட்டாமல் எதையும் பின்னர் இயக்க முடியாது. YAML-இன் முதல் வரிக்கு முன்பே இவற்றில் தேர்ந்தெடுங்கள், ஏனெனில் பின்னர் இடம்பெயர்வது முதல் முயற்சியை விட அதிக செலவாகும்.

தேர்வு நெட்வொர்க் ஏற்கனவே முடியும் இடத்தில் வைக்கப்படும் runner-க்கும் ஒரு job அளவு வாழும் சுரங்கத்துக்கும் இடையில் உள்ளது. இரண்டும் பல ஆண்டுகளாக production deploy-களைச் சுமக்கின்றன, வெவ்வேறு வழிகளில் தோல்வியடைகின்றன.

எல்லை உண்மையில் எங்கே

மடிக்கணினியில் நீங்கள் நிறுவுவது எல்லாம் மடிக்கணினியிலேயே நிற்கிறது, job-இன் போது நிறுவுவது எல்லாம் runner-உடன் மறைகிறது. client-ஐ இயக்கங்களுக்கு இடையே இணைத்து வைக்கும் நிரந்தர நெட்வொர்க் namespace இல்லை, எனவே ஒவ்வொரு இயக்கமும் அதே அணுக முடியாத நிலையிலிருந்து தொடங்குகிறது. Azure இந்த எல்லையை Microsoft-ஹோஸ்ட் செய்த agents-க்கு ஆவணப்படுத்துகிறது, அங்கு தனியார் நெட்வொர்க்குகளுக்கான VPN மற்றும் ExpressRoute இணைப்புகள் ஆதரிக்கப்படுவதில்லை, GitHub-ஹோஸ்ட் செய்த runners அதே வகையான கட்டுப்பாட்டைச் சுமக்கின்றன, தனி முறை அல்ல. இதை தயாரிப்பின் பண்பாகப் படியுங்கள், தவிர்க்க வேண்டிய குறையாக அல்ல.

repository-இன் எந்த அமைப்பும் இதைத் தளர்த்துவதில்லை. job-இன் லேபிள் எந்த pool வேலையை எடுக்கும் என்பதை முடிவு செய்கிறது, ஹோஸ்ட் செய்த லேபிள் என்பது முழு இயக்கத்துக்கும் உங்கள் எல்லைக்கு வெளியே ஒரு இயந்திரம்.

எனவே தனியார் அணுகல் உங்கள் உடைமையான ஒன்றிலிருந்து வர வேண்டும். நெட்வொர்க் ஏற்கனவே முடியும் இடத்தில் வைக்கப்பட்ட runner, அல்லது ஒரு job வாழும் சுரங்கம். மீதமுள்ள கட்டுரை இவற்றில் ஒன்றுக்கு உணர்ந்து பணம் செலுத்துவது பற்றியது, production-இல் பில் கண்டுபிடிப்பதற்குப் பதிலாக.

இயக்க அலைவரிசையை வைத்து முடிவு செய்யுங்கள், பரிச்சயத்தை வைத்து அல்ல

deploy-கள் நாளுக்கு பல முறை வரும்போது, job ஒன்றுக்கு மேற்பட்ட தனியார் போர்ட்டைத் தொடும்போது, அல்லது platform குழு ஏற்கனவே patching மற்றும் credential rotation-ஐ கவனிக்கும்போது, VPC அல்லது அலுவலக நெட்வொர்க்கில் சொந்த runner-ஐ பயன்படுத்துங்கள். அந்த இயந்திரத்தில் job மற்ற எந்த host போலவும் firewall-க்குப் பின்னால் resolve செய்து route செய்கிறது. நெட்வொர்க் வேலை ஒரு முறை, நிறுவலின் போது நடக்கிறது, ஒவ்வொரு இயக்கத்திலும் அல்ல.

அணுகல் அவ்வப்போது மட்டும் இருக்கும்போதும், உங்கள் நெட்வொர்க்குக்குள் credential வைத்திருக்கும் நீண்ட ஆயுள் agent வேண்டாம் என்றால், சுரங்கத்தை job-க்குள் கட்டுங்கள். job சில நிமிடங்கள் தன் சொந்த நெட்வொர்க் client ஆகி, பின்னால் எதையும் விட்டுச் செல்வதில்லை, அதுவே பெரும்பாலும் முழு நோக்கம்.

சுரங்கத்தைத் தேர்ந்தெடுப்பதற்கு முன் அதன் செலவை மதிப்பிடுங்கள். ஒவ்வொரு இயக்கமும் profile உருவாக்கம், client தொடக்கம், தயார்நிலை மற்றும் அழிப்புக்குக் கட்டணம் செலுத்துகிறது. ஏறும் ஆனால் ஒருபோதும் சரிபார்க்கப்படாத சுரங்கம், பாதியில் தோல்வியடையும் deploy-ஐ உருவாக்கி, யாரும் திட்டமிடாத வடிவில் தனியார் நிலையை விட்டுச் செல்கிறது. அதன் பின் மீண்டும் முயல்வது அரிதாகவே சுத்தமாக இருக்கும், இரண்டாவது தோல்வி பொதுவாக client பதிப்பின் மீது சுமத்தப்படுகிறது.

profile-ஐ படி நிற்க முடியாதபடி எழுதுதல்

profiles மற்றும் credentials-ஐ repository-க்கு வெளியே வைத்து, அவை தேவைப்படும் படியில் secrets-இலிருந்து உருவாக்குங்கள். வரிசை job தப்பிக்குமா என்பதை முடிவு செய்கிறது: sudo-வின் கீழ் உருவான கோப்பு root-க்கு சொந்தம், படியின் சிறப்புரிமை இல்லாத shell அதில் எழுத முடியாது.

- name: Bring up OpenVPN
  run: |
    umask 077
    profile="$RUNNER_TEMP/client.ovpn"
    printf '%s\n' "$VPN_PROFILE" > "$profile"
    : > "$RUNNER_TEMP/openvpn.log"
    printf '%s\n' "$VPN_CREDENTIALS" > "$RUNNER_TEMP/credentials.txt"
    sudo openvpn --daemon openvpn-job \
      --config "$profile" \
      --auth-user-pass "$RUNNER_TEMP/credentials.txt" \
      --writepid "$RUNNER_TEMP/openvpn.pid" \
      --log "$RUNNER_TEMP/openvpn.log"

அந்த தொகுதியின் இரண்டு விவரங்களும் பிந்தைய படிகளுக்கானவை. umask 077 உடன் profile 0600 பயன்முறையில் runner பயனரின் உடைமையில் வருகிறது, sudo இன்னும் படிக்க முடியும், client தன் log-ஐ runner ஏற்கனவே வைத்திருக்கும் கோப்பில் எழுதுகிறது, எனவே தயார்நிலை சுழற்சி இரண்டாவது sudo இல்லாமல் அந்த log-ஐ படிக்க முடியும். --writepid அழிப்பு இலக்காகக் கொள்ளும் PID-ஐ பதிவு செய்கிறது.

client சான்றிதழால் அங்கீகரிக்கப்படும் profile-க்கு அதன் விசை அதே வழியில் எழுதப்பட்டிருக்க வேண்டும், static-challenge profile-க்கு பொருந்தும் auth பயன்முறை தேவை. DNS விருப்பங்களை push செய்யும் profiles-க்கு Ubuntu மற்றும் Debian-இல் openvpn-systemd-resolved தேவை, ஏனெனில் push மட்டும் அடிப்படை இமேஜில் எதையும் மாற்றாது.

தயார்நிலை ஒரு ஆய்வு, இடைநிறுத்தம் அல்ல

நிலையான sleep concentrator மெதுவாகும் வரை மட்டுமே தாக்குப்பிடிக்கும், பிறகு deploy படி வழித்தடம் உருவாவதற்கு முன்பே ஓடுகிறது. தோல்வி பிறகு deploy கருவிக்குள் தனியார் host-க்கு எதிரான timeout ஆக வெளிப்படுகிறது, அது சுரங்கம் பற்றி எதுவும் சொல்லாது.

- name: Await private endpoint
  run: |
    for attempt in $(seq 1 30); do
      if getent hosts private.example.internal > /dev/null && \
         timeout 3 bash -c 'exec 3<>/dev/tcp/private.example.internal/8443' 2>/dev/null; then
        echo "endpoint answered after $attempt attempts"
        exit 0
      fi
      sleep 2
    done
    grep -Ei 'error|verify|auth' "$RUNNER_TEMP/openvpn.log" | tail -40
    exit 1

சுழற்சி இரண்டு விஷயங்களைப் பார்க்கிறது, ஏனெனில் எதுவும் உடைந்த பாதியாக இருக்கலாம். getent hosts push செய்யப்பட்ட resolver அந்தப் பெயருக்குப் பதில் தருகிறது என்பதை நிரூபிக்கிறது, socket திறப்பது deploy பயன்படுத்தும் போர்ட்டில் ஏதோ கேட்பதை நிரூபிக்கிறது; வழித்தடம் மட்டும் உள்ள profile-க்கு நேரடி முகவரியும் நீக்கப்பட்ட getent வரியும் தேவை.

சுழற்சி முடிந்ததும், மூன்று வெவ்வேறு கோளாறுகளைப் பிரிப்பது log மட்டுமே: நிராகரிக்கப்பட்ட சான்றிதழ், தவறான auth பயன்முறை, ஒருபோதும் வராத வழித்தடம். tail-க்கு முன் வடிகட்டுவது அந்த வெளியீட்டை job இன்னும் தோல்வியடையும் போது படிக்கக்கூடிய அளவு சுருக்கமாக வைக்கிறது. முதல் பிழையைப் படியுங்கள், கடைசி வரியை அல்ல, ஏனெனில் அங்கீகரிக்க முடியாத client சுழற்சி விட்டுக்கொடுக்கும் வரை தன்னைத் திரும்பச் சொல்கிறது. ip -4 route show dev tun0 வழித்தடம் ஏதேனும் push ஆனதா என்ற எளிய கேள்விக்குப் பதில் தருகிறது, அதே சுழற்சியில் ஒரு வரி செலவாகும்.

அழித்தல் மற்றும் artifact கேள்வி

job-ஐ if: always() ஆல் பாதுகாக்கப்பட்ட படியில் மூடுங்கள், அது sudo kill "$(sudo cat "$RUNNER_TEMP/openvpn.pid")" மற்றும் வேறு எதையும் இயக்காது. பகிரப்பட்ட சொந்த runner-இல் ஒருபோதும் செயல்முறை பெயரால் கொல்லாதீர்கள்: மற்ற job-இடம் அதே binary மற்றும் ஒத்த argument-கள் கொண்ட client இருக்கலாம். பிறகு தோல்வி இரண்டாவதாக ஓடிய job மீது விழும், அதன் log எதுவும் தவறு செய்யாத workflow-ஐ சுட்டும்.

பாதுகாப்பு முக்கியம், ஏனெனில் தோல்வியடைந்த deploy இருந்தாலும் உயிருள்ள சுரங்கத்தை விட்டுச் செல்கிறது. always() இல்லாமல் சுத்தம் செய்யும் படி தேவைப்படும் போதே தவிர்க்கப்படுகிறது, அடுத்த இயக்கம் ஏற்கனவே இணைக்கப்பட்ட client-க்கு எதிராகத் தொடங்குகிறது.

எந்த வடிவமைப்பையும் ஏற்பதற்கு முன் ஒரு கேள்வி மீதம்: build நிலைக்கு உண்மையில் தனியார் வழித்தடம் தேவையா? ஏற்கனவே நெட்வொர்க்குக்குள் அமர்ந்திருக்கும் deployment agent அங்கீகரிக்கப்பட்ட artifact-ஐ இழுக்க முடியும், இது சாதாரண build-களைத் தனியார் பாதையிலிருந்து விலக்கி வைக்கிறது. சுரங்கத்தை வைத்திருக்கும் குறைவான job என்றால் பழைய வழித்தடம் ஒளியக்கூடிய குறைவான இடங்கள்.