למה להריץ runner משלי במקום מאוחסן-GitHub?

שלוש סיבות אמיתיות: התלויות וה-toolchain שלכם מובנים (ללא התקנה מחדש בכל ריצה), גישה למשאבים פרטיים כמו registry פנימי או מסד נתונים, ושליטה על המכונה — הגודל שלה, ה-caches שלה, הרשת שלה. אם דקות מאוחסנות-GitHub וסביבה נקייה מתאימות לכם, הישארו עליהן. אחסנו-בעצמי כשאתם ספציפית צריכים אחת מהשלוש.

האם זה בטוח להשתמש ב-runner באחסון-עצמי?

על repo פרטי, כן. על repo ציבורי, לא — לעולם לא. workflow מריץ קוד שרירותי ממי שמפעיל אותו, ועל repo ציבורי pull request של זר יכול להריץ את הקוד שלו על ה-runner שלכם. התיעוד של GitHub עצמו אומר אותו דבר. שמרו runners באחסון-עצמי ל-repos פרטיים, או קבלו שאתם מוסרים את הארגז שלכם לאינטרנט.

כמה CPU ו-RAM runner צריך?

תלוי לגמרי ב-build שלכם. job טיפוסי של קומפילציה-ובדיקה נוח עם 2 ליבות ו-4-8 GB — Small או Medium כאן. builds כבדים (קומפילציות native גדולות, images גדולים של Docker, חבילות בדיקה רעבות-זיכרון) רוצים יותר, וכדאי שתמדדו ל-job האמיתי שלכם, לא לניחוש. צפו בריצה אמיתית אחת ותדעו.

האם runner אחד יכול לטפל בכמה repos?

runner יכול להירשם לארגון ולהילקח על ידי כמה repos, job אחד בכל פעם כברירת מחדל. ליותר מקביליות, הריצו יותר runners — כל אחד הוא שירות systemd משלו. פשוט שמרו את כולם על repos פרטיים.

האם אני צריך לתת לכם תעודה?

לא. אימייל להרשמה, USDC או USDT לתשלום. ללא מסמכים, root בערך תוך דקה.

הרצת runner של GitHub Actions באחסון-עצמי על VPS

runners מאוחסני-GitHub הם ברירת מחדל בסדר. אתם מפסיקים לצטרך אותם ברגע ש-build רוצה משהו שאין להם — ה-registry הפרטי של החבילות שלכם, גרסת toolchain ספציפית שנמאס לכם להתקין מחדש בכל ריצה, מסד נתונים ברשת שלכם, או פשוט יותר שליטה על המכונה. אז runner באחסון-עצמי על VPS מרוויח את מקומו.

המדריך הזה מביא אחד למצב רץ כמו שצריך: מותקן, רשום, חי תחת systemd, ו — החלק שאנשים טועים בו — בטוח. בואו נתחיל עם האחרון, כי זה החלק שנושך.

כלל האבטחה האחד

workflow של GitHub Actions מריץ קוד שרירותי — מה שיש בקובץ ה-workflow, ומה שהקוד הזה מושך. על ה-repo שלכם זה הקוד שלכם, וזה בסדר. על repo ציבורי, pull request מזר יכול להריץ את הקוד שלו על ה-runner שלכם. זה לא באג; ככה CI עובד. התיעוד של GitHub עצמו אומר בבירור: אל תשתמשו ב-runners באחסון-עצמי עם repositories ציבוריים.

אז הכלל פשוט ובלתי-ניתן-למשא-ומתן: runners באחסון-עצמי הם ל-repos פרטיים. אם ה-repo שלכם ציבורי, השתמשו ב-runners מאוחסני-GitHub והמשיכו הלאה. כל מה שלמטה מניח repo פרטי.

מה runner צריך מהארגז

זה תלוי ב-build, וכדאי שתמדדו לשלכם ולא למספר מעמוד:

job טיפוסי של קומפילציה-ובדיקה — 2 ליבות ו-4-8 GB נוח. Small ($8, 4 vCPU / 4 GB) או Medium ($12, 6 vCPU / 6 GB) מכסה את רוב אלה.
builds כבדים יותר — קומפילציות native גדולות, builds גדולים של image ב-Docker, חבילות בדיקה רעבות-זיכרון — רוצים יותר מרווח. צפו בריצה אמיתית אחת (htop בזמן שהיא בונה) ומדדו למה שאתם באמת רואים, לא לתקווה.

דיסק חשוב גם: build caches, שכבות Docker, ו-repos משוכפלים מצטברים. שמרו עין ו-prune.

1. הכינו את הארגז

צרו משתמש לא-root ל-runner — המתקין של GitHub מסרב לרוץ כ-root ממילא, ואתם רוצים את זה ככה:

sudo adduser --disabled-password --gecos "" runner
sudo usermod -aG sudo runner   # only if your builds genuinely need sudo

התקינו מה שה-builds שלכם צריכים — toolchain של שפה, Docker, כלי build. לדוגמה, אם ה-jobs שלכם בונים קונטיינרים:

sudo apt update && sudo apt install -y docker.io
sudo usermod -aG docker runner

2. הורידו ורשמו את ה-runner

ב-repo (או בארגון) שלכם ב-GitHub, לכו ל-Settings → Actions → Runners → New self-hosted runner. GitHub נותן לכם את פקודות ההורדה המדויקות וטוקן רישום (הוא קצר-חיים — תפסו אותו טרי). כמשתמש ה-runner:

sudo -iu runner
mkdir actions-runner && cd actions-runner
# use the exact URL GitHub shows you for your OS/arch:
curl -o actions-runner-linux-x64.tar.gz -L "URL_FROM_GITHUB"
tar xzf actions-runner-linux-x64.tar.gz
./config.sh --url https://github.com/YOUR_ORG/YOUR_REPO --token YOUR_TOKEN

config.sh מבקש שם runner, labels, ותיקיית עבודה — ברירות המחדל בסדר להתחיל. labels הם איך שה-workflow שלכם מכוון ל-runner הזה (runs-on: self-hosted).

3. הריצו אותו כשירות systemd

ה-runner מגיע עם עוזר שמתקין שירות systemd בשבילכם — השתמשו בו, כך שה-runner שורד אתחולים ומופעל מחדש בכשל. עדיין כהתקנה של משתמש ה-runner, אבל פקודות השירות צריכות root:

sudo ./svc.sh install runner
sudo ./svc.sh start
sudo ./svc.sh status

זה רושם את actions.runner.* כ-unit של systemd שרץ כמשתמש ה-runner, מתחיל באתחול. לוגים הולכים ל-journald:

sudo journalctl -u 'actions.runner.*' -f

בחזרה בעמוד ה-Runners של GitHub, ה-runner שלכם עכשיו מראה Idle — נקודה ירוקה. כוונו workflow אליו:

jobs:
  build:
    runs-on: self-hosted
    steps:
      - uses: actions/checkout@v4
      - run: make test

דחפו, וה-job רץ על הארגז שלכם.

4. שמרו אותו נקי

runner באחסון-עצמי משתמש מחדש במערכת הקבצים שלו בין jobs — זה ניצחון המהירות (caches חמים) והמלכודת (state שנשאר). שני הרגלים שומרים אותו בריא:

עשו prune באופן קבוע. Docker במיוחד — docker system prune ב-cron, או שהדיסק מתמלא בשקט בשכבות מתות.
אל תאחסנו סודות על הארגז. השתמשו ב-secrets של GitHub Actions, מוזרקים לכל-ריצה, לא קבצים שיושבים ב-home של ה-runner. אם ה-runner נפרץ, כל דבר על הדיסק הולך איתו.

אם אתם צריכים סביבה באמת נקייה לכל job, הריצו כל job בתוך שלב קונטיינר — ה-runner נשאר, הבלגן של ה-job לא.

מתי לאחסן-בעצמי, בכנות

אחסנו-בעצמי כשאתם צריכים את ה-toolchain שלכם מובנה, גישה למשאבי רשת פרטיים, או שליטה על המכונה. הישארו על runners מאוחסני-GitHub כשסביבה נקייה ולזריקה והדקות שלהם מתאימות לכם — זה באמת פשוט יותר, ופשוט יותר שווה משהו. ולעולם, על repo ציבורי, אל תאחסנו-בעצמי. זה לא העדפה.

אם runner ל-repo פרטי הוא מה שאתם צריכים: בחרו תוכנית — Small ($8) ל-builds קלים יותר, Medium ($12) כשהם נעשים כבדים יותר — שלמו ב-USDC או USDT (ללא KYC, ללא מסמכים), ויהיה לכם root בערך תוך 60 שניות. ואז עבדו במורד הדף הזה ויהיה לכם runner שלוקח jobs כמה דקות אחר כך.

ראו את התוכנית והזמינו VPS →