GitHub Actions ඔබේ VPN වෙත ළඟා නොවේ: ඔබේම runner එකක් හෝ උමං මාර්ගයක්

සත්කාරක runner යනු ඔබේ ජාලයට පිටතින් ඇති නව VM එකකි. එම ජාලය තුළ runner එකක් තබන්න, නැතහොත් job එකෙන් උමං මාර්ගයක් සාදා සැබෑ මාර්ගයක් එනතුරු රැඳී සිටින්න.

ඔබේ 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 එකකට වඩා පෞද්ගලික වරායක් ස්පර්ශ කරන විට, නැතහොත් වේදිකා කණ්ඩායම දැනටමත් 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 සහ සමාන තර්ක සහිත client එකක් තිබිය හැක. එවිට අසාර්ථකත්වය දෙවනුව ධාවනය වූ job එකට වැටේ, එහි log කිසිදු වරදක් නොකළ workflow එකකට යොමු කරයි.

ආරක්ෂාව වැදගත් වන්නේ අසාර්ථක deploy එකක් වුවද ජීවමාන උමං මාර්ගයක් තබන බැවිනි. always() නොමැතිව පිරිසිදු කිරීමේ පියවර අවශ්‍ය වන අවස්ථාවේදීම මඟ හරිනු ලැබේ, ඊළඟ ධාවනය දැනටමත් සම්බන්ධිත client එකකට එරෙහිව ආරම්භ වේ.

ඕනෑම නිර්මාණයක් භාර ගැනීමට පෙර එක් ප්‍රශ්නයක් ඉතිරිය: build අදියරට ඇත්තෙන්ම පෞද්ගලික මාර්ගයක් අවශ්‍යද? දැනටමත් ජාලය තුළ වාඩි වී සිටින deployment agent එකකට අනුමත artifact එකක් ඇද ගත හැක, එය සාමාන්‍ය builds පෞද්ගලික මාර්ගයෙන් ඈත් කර තබයි. අඩු job උමං මාර්ගයක් රඳවා ගැනීම යනු පැරණි මාර්ගයකට සැඟවිය හැකි අඩු ස්ථාන.

අදාළ ලිපි