GitHub Actions ನಿಮ್ಮ VPN ತಲುಪುವುದಿಲ್ಲ: ಸ್ವಂತ runner ಅಥವಾ ಸುರಂಗ

ನಿಮ್ಮ deploy ಹಂತವು ಒಳಾಂಗಣ hostname ನಲ್ಲಿ ನೇತಾಡುತ್ತದೆ, ಅದೇ ಆಜ್ಞೆ ನಿಮ್ಮ ಲ್ಯಾಪ್ಟಾಪ್ನಿಂದ ತಕ್ಷಣ ಉತ್ತರಿಸುತ್ತದೆ, ಎರಡೂ ಯಂತ್ರಗಳಲ್ಲಿ client build ಒಂದೇ ರೀತಿ ಇದೆ. job GitHub-ಹೋಸ್ಟ್ ಮಾಡಿದ runner ನಲ್ಲಿ ಚಲಿಸುತ್ತಿದೆ: ಅದೇ ಒಂದು job ಗಾಗಿ GitHub ನ ಕ್ಲೌಡ್ನಲ್ಲಿ ರಚಿಸಿದ ವರ್ಚುವಲ್ ಯಂತ್ರ, ನಿಮ್ಮ ಖಾಸಗಿ ವಿಳಾಸ ಸ್ಥಳಕ್ಕೆ ಯಾವುದೇ ಮಾರ್ಗವಿಲ್ಲ, ಒಳಾಂಗಣ ವಲಯಕ್ಕೆ resolver ನಮೂದಿಲ್ಲ, ಖಾಸಗಿ endpoint ಒಪ್ಪಿಕೊಳ್ಳುವ ಪ್ರಮಾಣಪತ್ರವಿಲ್ಲ. ಈ ಮಿತಿಗೆ ಎರಡು ವಿನ್ಯಾಸಗಳು ಮಾತ್ರ ಹೊಂದುತ್ತವೆ, workflow ಮತ್ತೆ ಕಟ್ಟದೆ ಯಾವುದನ್ನೂ ನಂತರ ಆನ್ ಮಾಡಲಾಗದು. YAML ನ ಮೊದಲ ಸಾಲಿಗೆ ಮೊದಲೇ ಇವುಗಳಿಂದ ಆರಿಸಿ, ಏಕೆಂದರೆ ನಂತರದ ಸ್ಥಳಾಂತರ ಮೊದಲ ಪ್ರಯತ್ನಕ್ಕಿಂತ ಹೆಚ್ಚು ಖರ್ಚು.

ಆಯ್ಕೆ ನೆಟ್ವರ್ಕ್ ಈಗಾಗಲೇ ಮುಗಿಯುವಲ್ಲಿ ಇಡುವ runner ಗೂ ಒಂದು job ಬದುಕುವ ಸುರಂಗಕ್ಕೂ ನಡುವೆ ಇದೆ. ಎರಡೂ ವರ್ಷಗಳಿಂದ production deploy ಹೊರುತ್ತಿವೆ, ಬೇರೆ ಬೇರೆ ರೀತಿಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ.

ಗಡಿ ನಿಜವಾಗಿ ಎಲ್ಲಿದೆ

ನೀವು ಲ್ಯಾಪ್ಟಾಪ್ನಲ್ಲಿ ಸ್ಥಾಪಿಸುವುದೆಲ್ಲ ಲ್ಯಾಪ್ಟಾಪ್ನಲ್ಲೇ ನಿಲ್ಲುತ್ತದೆ, job ಸಮಯದಲ್ಲಿ ಸ್ಥಾಪಿಸುವುದು runner ಜೊತೆ ಮಾಯವಾಗುತ್ತದೆ. ರನ್ಗಳ ನಡುವೆ client ಅಂಟಿಕೊಳ್ಳುವ ಶಾಶ್ವತ ನೆಟ್ವರ್ಕ್ namespace ಇಲ್ಲ, ಆದ್ದರಿಂದ ಪ್ರತಿ ರನ್ ಅದೇ ತಲುಪಲಾಗದ ಸ್ಥಿತಿಯಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. 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 ಮಾಡುತ್ತದೆ. ನೆಟ್ವರ್ಕ್ ಕೆಲಸ ಒಮ್ಮೆ, ಸ್ಥಾಪನೆಯ ಸಮಯದಲ್ಲಿ ನಡೆಯುತ್ತದೆ, ಪ್ರತಿ ರನ್ನಲ್ಲಿ ಅಲ್ಲ.

ಪ್ರವೇಶ ಅಪರೂಪವಾದಾಗ, ನಿಮ್ಮ ನೆಟ್ವರ್ಕ್ಗೆ credential ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವ ದೀರ್ಘಾಯುಷ್ಯದ agent ಬೇಡವಾದಾಗ, ಸುರಂಗವನ್ನು 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 ಈಗಾಗಲೇ ಹೊಂದಿರುವ ಫೈಲ್ಗೆ ಬರೆಯುತ್ತದೆ, ಆದ್ದರಿಂದ ಸಿದ್ಧತೆಯ ಲೂಪ್ ಎರಡನೇ sudo ಇಲ್ಲದೆ ಆ log ಓದಬಲ್ಲದು. --writepid ಕಿತ್ತುಹಾಕುವಿಕೆ ಗುರಿಯಾಗಿಸುವ PID ದಾಖಲಿಸುತ್ತದೆ.

client ಪ್ರಮಾಣಪತ್ರದಿಂದ ದೃಢೀಕರಿಸುವ profile ತನ್ನ ಕೀಲಿಯನ್ನು ಅದೇ ರೀತಿ ಬರೆದಿರಬೇಕು, static-challenge profile ಗೆ ಹೊಂದುವ auth ಮೋಡ್ ಬೇಕು. DNS ಆಯ್ಕೆಗಳನ್ನು push ಮಾಡುವ profiles ಗೆ 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 ಬಳಿ ಅದೇ binary ಮತ್ತು ಹೋಲುವ argument ಗಳ client ಇರಬಹುದು. ಆಗ ವೈಫಲ್ಯ ಎರಡನೆಯದಾಗಿ ಚಲಿಸಿದ job ಮೇಲೆ ಬೀಳುತ್ತದೆ, ಅದರ log ಏನೂ ತಪ್ಪು ಮಾಡದ workflow ಕಡೆ ತೋರಿಸುತ್ತದೆ.

ಸಂರಕ್ಷಣೆ ಮುಖ್ಯ ಏಕೆಂದರೆ ವಿಫಲವಾದ deploy ಆದರೂ ಜೀವಂತ ಸುರಂಗ ಬಿಡುತ್ತದೆ. always() ಇಲ್ಲದೆ ಸ್ವಚ್ಛಗೊಳಿಸುವ ಹಂತ ಅಗತ್ಯವಿರುವ ಸರಿಯಾದ ಸಮಯದಲ್ಲೇ ಬಿಟ್ಟುಬಿಡುತ್ತದೆ, ಮುಂದಿನ ರನ್ ಈಗಾಗಲೇ ಸಂಪರ್ಕಗೊಂಡ client ಎದುರು ಪ್ರಾರಂಭವಾಗುತ್ತದೆ.

ಯಾವುದೇ ವಿನ್ಯಾಸ ಸ್ವೀಕರಿಸುವ ಮೊದಲು ಒಂದು ಪ್ರಶ್ನೆ ಉಳಿದಿದೆ: build ಹಂತಕ್ಕೆ ನಿಜವಾಗಿ ಖಾಸಗಿ ಮಾರ್ಗ ಬೇಕೇ? ಈಗಾಗಲೇ ನೆಟ್ವರ್ಕ್ ಒಳಗೆ ಕುಳಿತಿರುವ deployment agent ಅನುಮೋದಿತ artifact ಎಳೆಯಬಲ್ಲದು, ಇದು ಸಾಮಾನ್ಯ builds ಅನ್ನು ಖಾಸಗಿ ಮಾರ್ಗದಿಂದ ದೂರವಿರಿಸುತ್ತದೆ. ಕಡಿಮೆ job ಸುರಂಗ ಹಿಡಿದರೆ ಅಂದರೆ ಹಳೆಯ ಮಾರ್ಗ ಅಡಗಿಕೊಳ್ಳಬಲ್ಲ ಕಡಿಮೆ ಸ್ಥಳಗಳು.