GitHub Actions ba ya isa VPN ɗinka: runner naka ko rami

Matakinka na deploy yana rataye a kan hostname na ciki yayin da wannan umarnin ke amsawa nan take daga kwamfutar tafi-da-gida, kuma client build a kan injuna biyu ɗaya ne. Job ɗin yana gudana a kan runner da GitHub ke shiryawa: inji mai kama-da-wane da aka ƙirƙira don wannan job ɗaya a cikin girgijen GitHub, ba tare da hanya zuwa sararin adireshinka na sirri ba, ba tare da resolver record na yankin ciki ba kuma ba tare da takardar shaida da endpoint na sirri zai karɓa ba. Ƙira biyu ne kawai suka dace da wannan ƙuntatawa, kuma babu ɗaya da za a iya kunna shi daga baya ba tare da sake gina workflow ba. Zaɓi tsakaninsu kafin layin YAML na farko, domin ƙaura daga baya ta fi ƙoƙarin farko tsada.

Zaɓin yana tsakanin runner da aka sanya a inda cibiyar sadarwa ta riga ta ƙare da rami da ke rayuwa tsawon job ɗaya. Dukansu sun ɗauki deploy na samarwa shekaru da yawa, kuma suna kasawa ta hanyoyi daban-daban.

A ina iyakar take a haƙiƙa

Duk abin da ka saka a kwamfutar tafi-da-gida yana tsayawa a kwamfutar, kuma duk abin da ka saka yayin job yana ɓacewa tare da runner. Babu namespace na cibiyar sadarwa na dindindin da client zai manne da shi tsakanin gudanarwa, don haka kowace gudanarwa tana farawa daga wannan yanayin da ba za a iya isa ba. Azure ta rubuta wannan iyaka ga agents da Microsoft ke shiryawa, inda ba a tallafa wa haɗin VPN da ExpressRoute zuwa cibiyoyin sadarwa na sirri, kuma runners da GitHub ke shiryawa suna ɗaukar irin wannan ƙuntatawa maimakon wata hanya dabam. Karanta wannan a matsayin siffa ta samfur, ba a matsayin lahani da za a guje masa ba.

Babu wani saitin repository da zai sassauta wannan. Alamar job ce ke yanke shawarar wace pool ce za ta ɗauki aikin, kuma alamar da aka shirya tana nufin inji a wajen iyakarka duk tsawon gudanarwar.

Don haka isa ga na sirri dole ya fito daga wani abu da ka mallaka. Runner da aka sanya a inda cibiyar sadarwa ta riga ta ƙare, ko rami da ke rayuwa job ɗaya. Sauran labarin game da biyan kuɗi da gangan don ɗaya daga cikin waɗannan, maimakon gano lissafin a samarwa.

Yanke shawara bisa yawan gudanarwa, ba bisa saba ba

Yi amfani da naka runner cikin VPC ko cibiyar sadarwar ofis lokacin da deploy ke zuwa sau da yawa a rana, lokacin da job ya taɓa fiye da ɗaya port na sirri, ko lokacin da ƙungiyar dandamali ta riga ta mallaki patch da jujjuya shaidar shiga. Job a kan wannan inji yana warwarewa kuma yana bin hanya kamar kowane host a bayan firewall. Aikin cibiyar sadarwa yana faruwa sau ɗaya, a lokacin shigarwa, ba a kowace gudanarwa ba.

Gina ramin cikin job lokacin da shiga ba ta yau da kullum kuma ba ka son wakili mai dogon rai da ke riƙe shaidar shiga cikin cibiyar sadarwarka. Job ɗin ya zama nasa client na cibiyar sadarwa na minti kaɗan kuma ba ya barin komai, wanda sau da yawa shi ne dukan manufar.

Yi kiyasin kuɗin ramin kafin ka zaɓe shi. Kowace gudanarwa tana biya don ƙirƙirar profile, fara client, shirye-shirye da rushewa. Ramin da ke tashi amma ba a taɓa tabbatar da shi ba yana haifar da deploy da ke kasawa a tsakiyar hanya kuma ya bar yanayin sirri a siffar da babu wanda ya tsara. Sake gwadawa bayan haka ba safai yake da tsabta ba, kuma ana ɗora gazawar ta biyu a kan sigar client.

Rubuta profile ta yadda matakin ba zai iya katsewa ba

Riƙe profiles da shaidar shiga a wajen repository kuma ƙirƙira su daga secret a matakin da suke buƙata. Tsari ne ke yanke shawarar ko job zai tsira: fayil da aka ƙirƙira a ƙarƙashin sudo na root ne, kuma shell ɗin matakin da ba shi da izini ba zai iya rubutu a ciki ba.

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

Duk bayanan biyu a cikin wannan block na matakai na gaba ne. Da umask 077 profile yana sauka a yanayin 0600 mallakar mai amfani da runner, sudo har yanzu yana iya karanta shi, kuma client yana rubuta log ɗinsa cikin fayil da runner ya riga ya mallaka, don haka zagayowar shirye-shiryen na iya karanta wannan log ba tare da sudo na biyu ba. --writepid yana rubuta PID da rushewa za ta nufa.

Profile da ke tabbatarwa da takardar shaidar client yana buƙatar a rubuta maɓallinsa haka, kuma profile na static-challenge yana buƙatar yanayin auth da ya dace. Profiles da ke tura zaɓuɓɓukan DNS suna buƙatar openvpn-systemd-resolved a Ubuntu da Debian, domin turawa ita kaɗai ba ta canza komai a kan hoton tushe.

Shirye-shirye bincike ne, ba dakatawa ba

Sleep da aka kayyade yana jimre har zuwa lokacin da mai tattarawa ya yi jinkiri, sannan matakin deploy yana gudana kafin hanya ta wanzu. Gazawar tana bayyana a cikin kayan aikin deploy a matsayin timeout zuwa host na sirri, wanda ba ya faɗi komai game da ramin.

- 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

Zagayowar tana kallon abubuwa biyu domin kowanne daga cikinsu zai iya zama rabin da ya karye. getent hosts yana tabbatar da cewa resolver da aka tura yana amsa ga wannan suna, kuma buɗe socket yana tabbatar da cewa wani abu yana saurara a port ɗin da deploy zai yi amfani da shi; profile mai hanya kawai yana buƙatar adireshin zahiri da share layin getent.

Lokacin da zagayowar ta ƙare, log ne kawai abin da ke raba kurakurai uku daban-daban: takardar shaida da aka ƙi, yanayin auth da ba daidai ba da hanya da ba ta taɓa zuwa ba. Tacewa kafin tail yana riƙe wannan fitarwa gajarta isa a karanta yayin da job ke ci gaba da kasawa. Karanta kuskure na farko ba layin ƙarshe ba, domin client da ba zai iya tabbatarwa ba yana maimaita kansa har zagayowar ta hakura. ip -4 route show dev tun0 yana amsa tambaya mafi sauƙi ko an tura hanya kwata-kwata, kuma yana ɗaukar layi ɗaya cikin wannan zagayowar.

Rushewa da tambayar artifact

Rufe job da matakin da if: always() ke kariya kuma yana gudanar da sudo kill "$(sudo cat "$RUNNER_TEMP/openvpn.pid")" ba wani abu ba. A kan naka runner da aka raba kada ka taɓa kashewa da sunan tsari: wani job na iya mallakar client da irin wannan binary da hujja makamantansu. Gazawar tana faɗowa kan job ɗin da ya gudana na biyu, log ɗinsa kuma yana nuni ga workflow da bai yi kuskure ba.

Kariyar tana da muhimmanci domin deploy da ya gaza har yanzu yana barin rami mai rai. Idan babu always() ana tsallake matakin tsaftacewa daidai lokacin da ake buƙatarsa, gudanarwa ta gaba kuma tana farawa da client da ya riga ya haɗu.

Tambaya ɗaya ta rage kafin ka karɓi ɗaya daga cikin ƙira biyu: shin matakin build yana buƙatar hanyar sirri kwata-kwata? Wakilin deployment da ya riga ya zauna cikin cibiyar sadarwa zai iya ɗebo artifact da aka amince, wanda ke nisantar da build na yau da kullum daga hanyar sirri. Ƙananan job da ke riƙe da rami na nufin ƙananan wuraren da tsohuwar hanya za ta iya ɓoyewa.