GitHub Actions nær ekki VPN-inu þínu: eigin runner eða göng

Deploy-skrefið þitt hangir á innra hýsitöluþekki á meðan sama skipun svarar samstundis frá fartölvunni, og client-buildið á báðum vélum er eins. Jobið keyrir á runner sem GitHub hýsir: sýndarvél sem var búin til fyrir þetta eina job í skýi GitHub, án leiðar inn í einkaaðressvæðið þitt, án resolver-færslu fyrir innra svæðið og án vottorðs sem einkaendapunkturinn myndi samþykkja. Aðeins tvær hönnur passi þessari takmörkun, og hvorugt er hægt að kveikja á síðar án þess að byggja workflowið upp að nýju. Veldu á milli þeirra fyrir fyrstu YAML-línuna, því flutningur síðar kostar meira en fyrsta tilraun.

Valið stendur milli runners sem er settur þar sem netið endar þegar, og gangs sem lifir aðeins eitt job. Bæði hafa borið framleiðsludeploy í mörg ár, og þau bregðast á mismunandi vegu.

Hvar mörkin liggja í raun

Allt sem þú setur upp á fartölvunni stöðvast á fartölvunni, og allt sem þú setur upp meðan á jobi stendur hverfur með runnerinum. Það er ekkert varanlegt netnafnrými sem client getur hangið á milli keyrslna, svo hver keyrsla byrjar í sama óaðgengilega ástandi. Azure skrásetur þessi mörk fyrir agena sem Microsoft hýsir, þar sem VPN- og ExpressRoute-tengingar inn í einkanet eru ekki studdar, og runnerar sem GitHub hýsir bera sömu tegund takmörkunar en ekki sérstakan gang. Lestu þetta sem eiginleika vörunnar, ekki sem galla sem á að komast hjá.

Engin stilling í geymslunni slakar á þessu. Merki jobsins ræður því hvaða pool tekur verkið, og hýst merki þýðir vél utan þíns jaðars alla keyrsluna.

Því verður einkaaðgangur að koma frá einhverju sem þú átt. Runner settur þar sem netið endar þegar, eða göng sem lifa eitt job. Afgangur greinarinnar fjallar um að borga viljandi fyrir annað hvort í stað þess að uppgötva reikninginn í framleiðslu.

Ákveddu eftir tíðni keyrslna, ekki eftir kunnugleika

Notaðu eigin runner inni í VPC eða skrifstofunetinu þegar deploy berast nokkrum sinnum á dag, þegar job snertir fleiri en eitt einkaport, eða þegar vettvangsteymið sér þegar um plástrun og snúning auðkenna. Job á þeirri vél leysir og beinir eins og hver önnur vél bak við eldvegg. Netvinnan fer fram einu sinni, við uppsetningu, ekki í hverri keyrslu.

Byggðu göngin inni í jobinu þegar aðgangur er stopull og þú vilt ekki langlífan agent sem heldur auðkenni inn í netið þitt. Jobið verður sinn eigin netclient í nokkrar mínútur og skilur ekkert eftir, sem er oft allur tilgangurinn.

Metið kostnað ganganna áður en þú velur þau. Sérhver keyrsla borgar fyrir mótun prófílsins, ræsingu clientsins, tilbúið stöðu og niðurrif. Göng sem rísa en eru aldrei staðfest framleiða deploy sem bregst við hálfa leið og skilja einkastöðuna eftir í formi sem enginn hafði skipulagt. Endurtilraunin eftir það er sjaldan hrein, og önnur bilunin er venjulega kennd client-útgáfunni.

Skrifa prófílinn svo skrefið geti ekki stöðvast

Haltu prófílum og auðkennum utan geymslunnar og mótaðu þau úr secret í því skrefi sem þarf á þeim að halda. Röðin ræður því hvort jobið lifir: skrá búin til undir sudo tilheyrir root, og óréttindalaus skel skrefsins getur þá ekki skrifað í hana.

- 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"

Báðir þættir í þeim blokk eru fyrir síðari skref. Með umask 077 lendir prófíllinn í 0600 ham og tilheyrir runner-notandanum, sudo getur enn lesið hann, og clientinn skrifar loggið í skrá sem runnerinn á þegar, svo tilbúið lykkjan getur lesið það logg án annars sudo. --writepid skráir PIDið sem niðurrifið miðar á.

Prófíll sem auðkennir sig með client-vottorði þarf lykilinn skrifaðan á sama hátt, og static-challenge prófíll þarf samsvarandi auth-ham. Prófílar sem ýta DNS-valkostum þurfa openvpn-systemd-resolved á Ubuntu og Debian, því ýtingin ein breytir engu á grunnmynd.

Tilbúið staða er mæling, ekki hlé

Föst sleep heldur nákvæmlega þangað til þéttirinn hægist, og þá keyrir deploy-skrefið áður en leiðin er til. Bilunin kemur þá fram inni í deploy-tólinu sem timeout á einkavélina, sem segir ekkert um göngin.

- 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

Lykkjan fylgist með tvennu því hvort tveggja getur verið brotni helmingurinn. getent hosts sannar að ýttur resolver svarar fyrir það nafn, og opnun socketsins sannar að eitthvað hlustar á gáttina sem deployið mun nota; prófíll með aðeins leið þarf bókstaflega vistfangið og strikaða getent línuna.

Þegar lykkjan rennur út er loggið eina sem aðgreinir þrjár ólíkar bilanir: hafnað vottorð, rangur auth-hamur og leið sem kom aldrei. Sía fyrir tail heldur þeirri úttakstölu nógu stuttri til að lesa meðan jobið bregst enn. Lestu fyrstu villuna frekar en síðustu línuna, því client sem getur ekki auðkennt sig endurtekur sig þangað til lykkjan gefst upp. ip -4 route show dev tun0 svarar þeirri einfaldari spurningu hvort leið var ýtt á annað borð, og það kostar eina línu í sömu lykkju.

Niðurrif og spurningin um artefaktinn

Lokaðu jobinu með skrefi sem if: always() verndar og keyrir sudo kill "$(sudo cat "$RUNNER_TEMP/openvpn.pid")" og ekkert annað. Á sameiginlegum eigin runner drepið aldrei eftir heiti ferlis: annað job getur átt client með sama tvíundarkóða og svipuðum rökum. Bilunin lendir þá á því jobi sem keyrði seinna, og logg þess bendir á workflow sem gerði ekkert rangt.

Vörnin skiptir máli því misheppnað deploy skilur samt eftir lifandi göng. Án always() er hreinsunarskrefinu sleppt nákvæmlega þegar þess er þörf, og næsta keyrsla byrjar á móti client sem er þegar tengdur.

Ein spurning er eftir áður en þú tekur aðra hönnunina: þarf byggingarstigið yfirhöfuð einkaleið? Deployment-agent sem situr þegar inni í netinu getur sótt samþykkta artefakt, og það heldur venjulegum buildum frá einkaleiðinni. Færri job sem halda göngum þýða færri staði þar sem gömul leið getur falið sig.