Nid yw GitHub Actions yn cyrraedd eich VPN: runner eich hun neu dwnnel

Mae eich cam deploy yn hongian ar hostname mewnol tra bod yr un gorchymyn yn ateb ar unwaith o’ch gliniadur, ac mae build y cleient ar y ddwy beiriant yn union yr un fath. Mae’r job yn rhedeg ar runner a gynhelir gan GitHub: peiriant rhithwir a grëwyd ar gyfer yr un job hwnnw yng nghwmwl GitHub, heb lwybr i mewn i’ch gofod cyfeiriadau preifat, heb gofnod resolver ar gyfer y parth mewnol ac heb dystysgrif y byddai’r endpoint preifat yn ei derbyn. Dim ond dau ddyluniad sy’n ffitio’r cyfyngiad hwnnw, ac ni ellir troi’r naill na’r llall ymlaen yn ddiweddarach heb ailadeiladu’r workflow. Dewiswch rhyngddynt cyn y llinell gyntaf o YAML, oherwydd mae mudo wedyn yn costio mwy na’r ymgais gyntaf.

Mae’r dewis rhwng runner a osodir lle mae’r rhwydwaith eisoes yn gorffwys a thwnnel sy’n byw am un job yn unig. Mae’r ddau wedi cario deploy cynhyrchu ers blynyddoedd, ac maent yn methu mewn ffyrdd gwahanol.

Lle mae’r ffin mewn gwirionedd

Mae popeth a osodwch ar y gliniadur yn stopio ar y gliniadur, ac mae popeth a osodwch yn ystod job yn diflannu gyda’r runner. Nid oes namespace rhwydwaith parhaol i’r cleient lynu wrtho rhwng rhediadau, felly mae pob rhediad yn dechrau o’r un cyflwr anghyraeddadwy. Mae Azure yn dogfennu’r ffin hon ar gyfer asiantau a gynhelir gan Microsoft, lle nad yw dolenni VPN ac ExpressRoute i rwydweithiau preifat yn cael eu cefnogi, ac mae runners a gynhelir gan GitHub yn cario’r un ffurf o gyfyngiad yn hytrach na mecanwaith ar wahân. Darllenwch hyn fel nodwedd gynnyrch, nid diffyg i’w osgoi.

Nid oes unrhyw osodiad repositoriw yn llacio hyn. Mae label y job yn penderfynu pa bwll sy’n cymryd y gwaith, ac mae label a gynhelir yn golygu peiriant y tu allan i’ch perimedr am y rhediad cyfan.

Felly rhaid i gyraeddadwyedd preifat ddod o rywbeth sy’n eiddo i chi. Runner wedi’i osod lle mae’r rhwydwaith eisoes yn gorffwys, neu dwnnel sy’n byw un job. Mae gweddill yr erthygl yn ymwneud â thalu am un o’r rhain yn fwriadol yn lle darganfod y bil mewn cynhyrchu.

Penderfynwch yn ôl amlder rhediadau, nid yn ôl cyfarwyddyd

Defnyddiwch runner eich hun o fewn y VPC neu rwydwaith y swyddfa pan fydd deploy yn cyrraedd sawl gwaith y dydd, pan fydd y job yn cyffwrdd mwy nag un porth preifat, neu pan fydd tîm platfform eisoes yn gofalu am batsio a chylchdroi credynau. Mae job ar y peiriant hwnnw yn datrys ac yn llwybro fel unrhyw host arall y tu ôl i’r mur gwarchod. Mae’r gwaith rhwydwaith yn digwydd unwaith, ar adeg gosod, yn lle ar bob rhediad.

Adeiladwch y twnnel y tu mewn i’r job pan fydd mynediad yn achlysurol ac nad ydych am asiant hirhoedlog yn dal credyd i mewn i’ch rhwydwaith. Mae’r job yn dod yn glient rhwydwaith ei hun am ychydig funudau ac nid yw’n gadael dim ar ôl, sef yn aml y pwynt cyfan.

Amcangyfrifwch gost y twnnel cyn ei ddewis. Mae pob rhediad yn talu am fateroli’r proffil, cychwyn y cleient, parodrwydd a dymchwel. Mae twnnel sy’n codi ond na chaiff byth ei wirio yn cynhyrchu deploy sy’n methu hanner ffordd ac yn gadael cyflwr preifat ar ffurf na chynlluniodd neb. Anaml y mae’r ail ymgais wedyn yn lân, ac mae’r ail fethiant fel arfer yn cael ei briodoli i fersiwn y cleient.

Ysgrifennu’r proffil fel na all y cam gael ei dorri

Cadwch broffiliau a chredynau y tu allan i’r repositoriw ac wedyn eu materoli o secret yn y cam sydd eu hangen. Mae’r drefn yn penderfynu a yw’r job yn goroesi: mae ffeil a grëwyd o dan sudo yn eiddo i root, ac ni all shell y cam heb fraint ysgrifennu iddi mwyach.

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

Mae’r ddau fanylion yn y bloc hwnnw ar gyfer camau diweddarach. Gyda umask 077 mae’r proffil yn glanio ym modd 0600 ac yn eiddo i ddefnyddiwr y runner, gall sudo ei ddarllen o hyd, ac mae’r cleient yn ysgrifennu ei log i ffeil sydd eisoes gan y runner, felly gall y ddolen parodrwydd ddarllen y log hwnnw heb ail sudo. Mae --writepid yn cofnodi’r PID y bydd y dymchwel yn anelu ato.

Mae proffil sy’n dilysu gyda thystysgrif cleient angen ei allwedd wedi’i hysgrifennu yr un ffordd, ac mae proffil static-challenge angen y modd auth cyfatebol. Mae proffiliau sy’n gwthio opsiynau DNS angen openvpn-systemd-resolved ar Ubuntu a Debian, oherwydd nid yw’r gwthiad ar ei ben ei hun yn newid dim ar ddelwedd sylfaen.

Mae parodrwydd yn archwiliad, nid yn seibiant

Mae sleep sefydlog yn dal yn union hyd nes y bydd y concentrator yn arafu, ac yna mae’r cam deploy yn rhedeg cyn bod y llwybr yn bodoli. Mae’r methiant wedyn yn codi y tu mewn i’r offeryn deploy fel timeout i’r host preifat, nad yw’n dweud dim am y twnnel.

- 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

Mae’r ddolen yn gwylio dau beth oherwydd gall y naill neu’r llall fod yr hanner sydd wedi torri. Mae getent hosts yn profi bod y resolver a wthiwyd yn ateb ar gyfer yr enw hwnnw, ac mae agor y socket yn profi bod rhywbeth yn gwrando ar y porth y bydd y deploy yn ei ddefnyddio; mae proffil llwybr yn unig angen y cyfeiriad llythrennol a’r llinell getent wedi’i dileu.

Pan fydd y ddolen yn dod i ben, y log yw’r unig beth sy’n gwahanu tri ffai gwahanol: tystysgrif a wrthodwyd, modd auth anghywir a llwybr na chyrhaeddodd erioed. Mae hidlo cyn y tail yn cadw’r allbwn hwnnw’n ddigon byr i’w ddarllen tra bod y job yn dal i fethu. Darllenwch y gwall cyntaf yn lle’r llinell olaf, oherwydd mae cleient na all ddilysu yn ailadrodd ei hun nes bod y ddolen yn rhoi’r gorau iddi. Mae ip -4 route show dev tun0 yn ateb y cwestiwn symlach a wthiwyd llwybr o gwbl, ac mae’n costio un llinell o fewn yr un ddolen.

Dymchwel, a chwestiwn yr artifact

Caewch y job gyda cham a warchodir gan if: always() sy’n rhedeg sudo kill "$(sudo cat "$RUNNER_TEMP/openvpn.pid")" a dim arall. Ar runner eich hun a rennir, peidiwch byth â lladd wrth enw proses: gall job arall fod â cheient gyda’r un binary a dadleuon tebyg. Mae’r methiant wedyn yn glanio ar y job a redodd yn ail, ac mae ei log yn pwyntio at workflow na wnaeth ddim o’i le.

Mae’r warchod yn bwysig oherwydd mae deploy wedi methu yn gadael twnnel byw o hyd. Heb always() mae’r cam glanhau yn cael ei hepgor yn union pan fo ei angen, ac mae’r rhediad nesaf yn dechrau yn erbyn cleient sydd eisoes yn gysylltiedig.

Mae un cwestiwn yn weddill cyn mabwysiadu’r naill ddyluniad neu’r llall: a oes angen llwybr preifat ar y cam build o gwbl? Gall asiant deployment sydd eisoes y tu mewn i’r rhwydwaith dynnu artifact a gymeradwywyd, ac mae hynny’n cadw builds cyffredin oddi wrth y llwybr preifat. Mae llai o jobau’n dal twnnel yn golygu llai o lefydd lle gall llwybr hen ffasiwn guddio.