GitHub Actions ereecht Äre VPN net: eegene Runner oder Tunnel

Äre Deploy-Schrëtt hänkt un enger interner Hostnumm, während déiselwecht Kommando vun Ärem Laptop aus direkt äntwert, an de Client-Build op béide Maschinne gläich ass. De Job leeft op engem Runner, deen GitHub hostet: enger virtueller Maschinn, déi fir just dee engen Job an der Cloud vun GitHub ugeluecht gouf, ouni Route an Ären private Adressraum, ouni Resolver-Andrag fir déi intern Zon an ouni Zertifikat, dat den private Endpoint akzeptéiere wäert. Nëmmen zwee Entwäerfer passen an dës Aschränkung, an keen vun deenen zwee kann méi spéit ageschalt ginn, ouni de Workflow nei ze bauen. Wielt tëschent hinnen virun der éischter YAML-Zeil, well d'Migratioun duerno méi kascht wéi den éischte Versuch.

D'Wiel ass tëschent engem Runner, dee do opgestallt gëtt, wou d'Netz schonn ophält, an engem Tunnel, deen genau ee Job laang besteet. Béid droen zënter Joren Produktiounsdeployen, an si versoen op verschidde Manéieren.

Wou d'Grenz tatsächlech läit

Alles, wat Dir um Laptop installéiert, hält um Laptop op, an alles, wat Dir während engem Job installéiert, verschwënnt mam Runner. Et gëtt keen dauerhaften Netz-Namespace, un deen e Client tëschent de Läif hänke bleift, dofir fänkt all Laf am selwechten onerreechbare Zustand un. Azure dokumentéiert dës Grenz fir Agenten, déi vu Microsoft gehost ginn, wou VPN- an ExpressRoute-Verbindungen an privat Netzer net ënnerstëtzt ginn, an d'Runneren, déi vu GitHub gehost ginn, droen déiselwecht Form vun Aschränkung an net en eegene Mechanismus. Liest dat als Produkteigenschaft, net als Defekt, deen een ëmgoe misst.

Keng Repository-Astellung entspaant dat. D'Etikett vum Job entscheet, wéi ee Pool d'Aarbecht hëlt, an en gehosteten Etikett heescht eng Maschinn baussent Ärem Perimeter fir de ganzen Laf.

Dofir muss déi privat Erreechbarkeet vun eppes kommen, wat Dir besëtzt. En Runner, deen do steet, wou d'Netz schonn ophält, oder en Tunnel, deen ee Job lieft. De Rescht vum Artikel geet dorëms, bewosst fir eng vun deenen zwee ze bezuelen, amplaz d'Rechnung an der Produktioun ze entdecken.

Entscheet no der Laf-Frequenz, net no der Vertrautheet

Benotzt en eegene Runner an der VPC oder am Büro-Netz, wann d'Deployen e puer Mol den Dag kommen, wann de Job méi wéi eng privat Port beréiert, oder wann en Plattform-Team schonn d'Patchen an d'Credential-Rotatioun huet. En Job op där Maschinn léist a routéiert wéi all aneren Host hannert der Firewall. D'Netzaarbecht geschitt eemol, bei der Installatioun, an net bei all Laf.

Baut den Tunnel bannent dem Job, wann den Zougang heiansdo ass an Dir keen laangliewegen Agent wëllt, deen en Credential an Äert Netz hält. De Job gëtt fir e puer Minutten säin eegene Netzclient an hannerléisst näischt, wat dacks de ganzen Zweck ass.

Schätzt d'Käschte vum Tunnel, ier Dir hien auswielt. All Laf bezilt fir d'Materialiséierung vum Profil, de Start vum Client, d'Bereetschaft an den Ofbau. En Tunnel, deen eropkënnt awer ni iwwerpréift gëtt, produzéiert en Deploy, deen op hallwem Wee versot an de private Zustand a enger Form hannerléisst, déi keen geplangt huet. Den neien Versuch duerno ass selten propper, an den zweeten Ausfall gëtt meeschtens op d'Client-Versioun geschwat.

D'Profil sou schreiwen, datt de Schrëtt net ofbrieche kann

Halt d'Profiler an d'Credentialen ausserhalb vum Repository a materialiséier se aus Secret an deem Schrëtt, deen se brauch. D'Reiefolleg entscheet, ob den Job iwwerlieft: eng Datei, déi ënner sudo ugeluecht gëtt, gehéiert dem root, an d'Shell vum Schrëtt ouni Privilegien kann duerno net méi dräi schreiwen.

- 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éid Detailer an deem Block si fir spéider Schrëtt. Mat umask 077 lant d'Profil am Modus 0600 an ass am Besëtz vum Runner-Benotzer, sudo kann se nach liesen, an de Client schreift säi Log an eng Datei, déi de Runner schonn huet, sou datt d'Bereetschaftsschleef dat Log ouni en zweet sudo liesen kann. --writepid registréiert de PID, op deen den Ofbau zilt.

En Profil, deen sech mat engem Client-Zertifikat authentifizéiert, brauch säi Schlëssel op déi selwecht Manéier geschriwwen, an e Static-Challenge-Profil brauch de passenden Auth-Modus. Profiler, déi DNS-Optiounen pushen, brauchen openvpn-systemd-resolved op Ubuntu an Debian, well de Push eleng um Basis-Image näischt ännert.

Bereetschaft ass eng Probe, keng Paus

E feste Sleep hält just bis de Konzentrator lues gëtt, an dann leeft den Deploy-Schrëtt, ier d'Route existéiert. Den Ausfall kënnt duerno am Deploy-Tool als Timeout géint den private Host eraus, wat näischt iwwer den Tunnel seet.

- 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

D'Schleef kuckt op zwee Saachen, well jidderee vun deenen déi gebrachen Halschent ka sinn. getent hosts beweist, datt de gepushten Resolver fir déi Numme äntwert, an d'Opmaache vum Socket beweist, datt eppes op der Port lauschtert, déi den Deploy benotze wäert; e Profil nëmme mat Route brauch d'literalesch Adress an déi geläschte getent Linn.

Wann d'Schleef ofleeft, ass d'Log dat eenzegt, wat dräi verschidde Feeler trennt: en ofgeleente Zertifikat, en falschen Auth-Modus an eng Route, déi ni ukomm ass. Filtréieren virum Tail hält dësen Ausgab kuerz genuch fir ze liesen, während den Job nach versot. Liest den éischte Feeler an net déi lescht Linn, well e Client, deen sech net authentifizéiere kann, widderhëlt sech, bis d'Schleef opgëtt. ip -4 route show dev tun0 äntwert op déi méi einfach Fro, ob iwwerhaapt eng Route gepusht gouf, an et kascht eng Linn an der selwechter Schleef.

Ofbau an d'Fro nom Artefakt

Maacht den Job zou mat engem Schrëtt, deen duerch if: always() geschützt ass an deen sudo kill "$(sudo cat "$RUNNER_TEMP/openvpn.pid")" ausféiert an näischt anescht. Op engem gedeelten eegene Runner dout ni no Prozessnumm: en aneren Job kann e Client mat demselwechte Binary an ähnlechen Argumenter hunn. Den Ausfall fält dann op dee Job, deen als zweeten gelaf ass, an säi Log weist op e Workflow, deen näischt falsch gemaach huet.

D'Schutz ass wichteg, well en Deploy, deen ausfält, trotzdeem en liewegen Tunnel hannerléisst. Ouni always() gëtt den Opraumschrëtt just dann iwwersprongen, wann en néideg ass, an den nächste Laf fänkt géint e Client un, dee schonn verbonnen ass.

Eng Fro bleift, ier Dir ee vun den zwee Entwäerfer unhëlt: brauch d'Build-Phase iwwerhaapt eng privat Route? En Deployment-Agent, deen schonn am Netz sëtzt, kann en approuvéierten Artefakt zéien, an dat hält gewéinlech Builds vum private Wee fort. Méi wéineg Jobs, déi en Tunnel halen, bedeit méi wéineg Plazen, wou eng al Route sech ka verstoppen.