runnerهای میزبانیشدهٔ GitHub تا وقتی که صورتحساب یا زمان انتظار آزاردهنده نشده راحتاند. بالای سهمیهٔ رایگان دقیقهای میپردازید، هر job «سرد» شروع میشود و هر بار وابستگیها را دوباره دانلود میکند. یک runner خودمیزبان روی VPS خودتان هر سه را برعکس میکند: هزینهٔ ماهانهٔ ثابت، ماشینی «گرم» با کشهای شما که همین حالا روی دیسک است، و محیط ساختی که کاملاً کنترلش میکنید — نسخههای ابزار مشخص، RAM بیشتر، و کش لایههای Docker که واقعاً باقی میماند.
یک runner فقط به دسترسی خروجی به GitHub نیاز دارد، پس روی ارزانترین پلنهای ما کار میکند، با کریپتو پرداخت میشود و KYC نمیخواهد.
یک runner به چه چیزی نیاز دارد
- CPU و RAM برای ساختهای شما. Small (۸ دلار در ماه — ۴ vCPU، ۴ گیگابایت RAM، ۳۵ گیگابایت NVMe) پیشفرض راحت برای بیشتر CIهاست: ساختهای Node/Go/Rust، مجموعههای تست، ساخت ایمیج Docker. کامپایل سنگین یا jobهای موازی؟ به Medium یا پلن Pro ارتقا دهید.
- دیسک NVMe برای کش. کل هدف خودمیزبانی، ماندگاری است — کش وابستگیها، لایههای Docker و آرتیفکتهای ساخت میان اجراها روی دیسک میمانند. NVMe بازیابی را سریع نگه میدارد.
- IP اختصاصی لازم نیست. runner از طریق HTTPS به GitHub وصل میشود؛ دسترسی ورودی لازم نیست. یک پلن NAT (از ۳ دلار در ماه) کافی است. IP اختصاصی را فقط زمانی بگیرید که چیزی هم میزبانی میکنید که ترافیک ارائه میدهد.
راهاندازی یک runner (Ubuntu 24.04)
runner را در مخزن (یا سازمان) خود بسازید: Settings → Actions → Runners → New self-hosted runner → Linux. GitHub یک دستور دانلود و یک توکن ثبت یکبارمصرف نشان میدهد. روی VPS:
# بهعنوان کاربر غیر root (runner از اجرا بهعنوان root خودداری میکند)
adduser --disabled-password --gecos "" runner
su - runner
mkdir actions-runner && cd actions-runner
curl -o actions-runner-linux-x64.tar.gz -L \
https://github.com/actions/runner/releases/latest/download/actions-runner-linux-x64.tar.gz
tar xzf actions-runner-linux-x64.tar.gz
# با URL + توکن از رابط GitHub ثبت کنید
./config.sh --url https://github.com/YOUR_ORG/YOUR_REPO --token YOUR_TOKEN
نگهداشتنش بهعنوان سرویس
./run.sh را در ترمینال اجرا نکنید — runner را بهعنوان سرویس systemd نصب کنید تا در برابر ریبوت دوام بیاورد:
sudo ./svc.sh install runner
sudo ./svc.sh start
sudo ./svc.sh status
runner اکنون در رابط GitHub بهصورت Idle ظاهر میشود و هر jobای را که هدفش اوست برمیدارد.
استفاده از یک workflow
با runs-on یک job را به runner خود هدایت کنید:
jobs:
build:
runs-on: self-hosted # یا یک برچسب سفارشی که هنگام ثبت تنظیم میکنید
steps:
- uses: actions/checkout@v4
- run: make build && make test
jobهای مبتنی بر Docker
Docker را یک بار نصب کنید تا workflowهای شما بتوانند ایمیج بسازند یا کانتینرهای سرویس اجرا کنند، در حالی که کش لایهها میان اجراها باقی میماند:
sudo apt update && sudo apt install -y docker.io
sudo usermod -aG docker runner # اجازه دهید runner بدون sudo از Docker استفاده کند
برای ایزولاسیون یکبارمصرف در هر job، خود runner را داخل یک کانتینر اجرا کنید و در هر اجرا آن را بازسازی کنید — الگویی رایج برای ساختهای نامعتمد یا ماتریسی.
چرا EQVPS برای CI
- هزینهٔ ثابت، دقیقههای نامحدود. بدون شمارش دقیقهای — یک pipeline پرکار هزینهای برابر با حالت بیکار دارد.
- کشهای «گرم». وابستگیها و لایههای Docker میان اجراها روی NVMe میمانند؛ ساختها سریعتر میشوند نه کندتر.
- root در ~۶۰ ثانیه، ایمیجهای تمیز. Ubuntu، Debian و بیشتر از طریق cloud-init؛ دقیقاً همان زنجیرهٔ ابزاری را که نیاز دارید نصب کنید.
- بدون KYC، پرداخت با کریپتو. ایمیل برای ثبتنام، USDC/USDT برای پرداخت. برای اوجهای انتشار، runnerهای اضافی راه بیندازید و بعد لغو کنید — زمان پرداختشدهٔ استفادهنشده به موجودی شما بازمیگردد.
نظرات
هنوز نظری نیست. اولین نفر باشید.