GitHub Actions ستاسو VPN ته نشي رسېدلی: خپل runner یا ټنل

ستاسو د deploy مرحله په یو داخلي hostname باندې ځړېده، په داسې حال کې چې هماغه امر ستاسو له لیپ ټاپ څخه سمدلاسه ځواب ورکوي، او د client build په دواړو ماشینونو کې یو شان دی. job په GitHub میزباني شوي runner باندې ځي: یوه مجازي ماشین چې هماغه یو job لپاره د GitHub په ورېځ کې جوړ شوی، ستاسو خصوصي پتې فضا ته هیڅ لاره نلري، د داخلي زون لپاره resolver ننوتنه نلري او هیڅ سند نلري چې خصوصي endpoint یې ومني. یوازې دوه ډیزاینونه دې محدودیت ته ځایېږي او هیڅ یو یې هم وروسته د workflow بیا جوړولو پرته نشي بل کېدلی. د YAML له لومړي کرښې مخکې ترمنځ غوره کړئ، ځکه وروسته مهاجرت له لومړي هڅې څخه ډېر لګښت لري.

غوره توب د هغه runner ترمنځ دی چې هلته ځای پر ځای کېږي چې شبکه لا دمخه پای ته رسېږي، او د هغه ټنل ترمنځ چې د یو job تر مودې پورې وي. دواړه کلونه کلونه production deployونه وړي او په بېلو لارو ناکامېږي.

پوله واقعاً چېرته ده

هر څه چې په لیپ ټاپ نصب کړئ په لیپ ټاپ باندې ودرېږي، او هر څه چې د job په جریان کې نصب کړئ له runner سره ورکېږي. د شبکې داسې دوامداره namespace نشته چې client د چلونو ترمنځ پرې وتړل شي، نو هر چلون له هماغه نه رسېدونکي حالت څخه پیلېږي. 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 کوي. د شبکې کار یو ځل، د نصب پر مهال ترسره کېږي، نه په هر چلون کې.

کله چې لاسرسی کله ناکله وي او نه غواړئ یو اوږد ژوندی agent ستاسو شبکې ته credential ونيسي، ټنل د 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 لا دمخه یې لري، نو د چمتووالي لوپ کولای شي هغه log له دویم sudo پرته ولولي. --writepid هغه PID ثبتوي چې ویجاړول به یې هدف وګرځوي.

هغه profile چې د client سند سره تصدیق کوي خپل کیلي ورته ورته لیکلې غواړي، او static-challenge profile اړوند auth حالت غواړي. هغه profiles چې د DNS اختیارونه push کوي په 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 کېدای شي هغه client ولري چې هماغه binary او ورته دلیلونه لري. ناکامي بیا پر هغه job لګېږي چې دویم چل شوی، او log یې هغه workflow ته اشاره کوي چې هېڅ غلطي نه وه کړې.

ساتنه مهمه ده ځکه ناکام deploy سره له دې هم ژوندی ټنل پرېږدي. پرته له always() د پاکولو مرحله په هماغه وخت کې پرېښودل کېږي چې ورته اړتیا وي، او بل چلون له هغه client سره پیلېږي چې لا دمخه تړل شوی.

له دواړو ډیزاینونو له یوه منلو دمخه یوه پوښتنه پاتې ده: ایا د build مرحلې واقعاً خصوصي لارې ته اړتیا لري؟ هغه deployment agent چې لا دمخه د شبکې دننه ناست وي کولای شي منظور شوی artifact راکش کړي، چې عادي builds له خصوصي لارې لرې ساتي. لږ jobونه چې ټنل لري یعنې لږ ځایونه چې پخوانی لار پکې پټېدلی شي.