EU में सेल्फ-होस्टेड GitHub Actions रनर
वही वर्कफ़्लो, प्राग या कोविल्हा की एक मशीन पर जो आपकी प्रति मिनट के बजाय प्रति माह है - बिल्ड कैश अभी भी वार्म है और एक ऐसा पता है जिसे फ़ायरवॉल वास्तव में अनुमति दे सकता है।
यह किसके लिए है
मिनट काउंटर देखने वाली एक टीम
एक Linux 2-कोर मिनट USD 0.006 है और एक 16-कोर मिनट USD 0.042 है, इसलिए जिस मैट्रिक्स बिल्ड ने सूट को तेज़ बनाया वही चीज़ इनवॉइस को दिलचस्प बना देती है।
एक वर्कफ़्लो जिसे किसी निजी चीज़ तक पहुँचना है
डिप्लॉय चरण को किसी डेटाबेस, रजिस्ट्री या ऐसे उपकरण से बात करनी है जो केवल ज्ञात पते स्वीकार करता है, और GitHub होस्टेड रनर एक ऐसी रेंज से आते हैं जो अनुमति देने के लिए बहुत बड़ी है।
एक बिल्ड जिसे इमेज में शिप की गई चीज़ से ज़्यादा चाहिए
एक लाइसेंस युक्त कंपाइलर, एक एमुलेटर, 30 GB का फ़िक्सचर सेट, या बस होस्टेड रनर से ज़्यादा डिस्क - और हर जॉब पर इसे फिर से इंस्टॉल करना पाइपलाइन का अधिकांश हिस्सा है।
जब रनर आपका हो तो क्या बदलता है
- वर्कस्पेस और कैश जॉब्स के बीच बनी रहती हैं, इसलिए डिपेंडेंसी रीस्टोर वर्कफ़्लो का सबसे लंबा चरण नहीं रहता।
- AS204057 से एक स्थिर IPv4 जिसे आपका डेटाबेस, रजिस्ट्री या VPN पते के अनुसार अनुमति दे सकता है।
- जो भी आप इंस्टॉल करते हैं वह इंस्टॉल रहता है - टूलचेन, लाइसेंस युक्त SDK, एमुलेटर, बड़े फ़िक्सचर सेट, वह सब कुछ जो होस्टेड इमेज नहीं रखती।
- रिपॉज़िटरी, संगठन या एंटरप्राइज़ स्तर पर पंजीकृत रनर, आपके चुने गए लेबल के साथ और एक वर्कफ़्लो जो runs-on से इन्हें चुनता है।
- एक होस्टेड रनर जिस स्थिर रूप में आता है उसके बजाय आपके द्वारा चुनी गई डिस्क और RAM।
- एक साइप्रस अनुबंध के अंतर्गत प्राग या कोविल्हा में एक मशीन, जो एक क्षेत्र सेटिंग के बजाय एक डेटा-रेज़िडेंसी उत्तर है।
पाइपलाइन वास्तव में क्या करती है उसके अनुसार आकार
एक रनर सेवा एक बार में एक जॉब लेती है, इसलिए यहाँ समवर्तिता एक प्लान स्तर के बजाय रनर प्रोसेस की गिनती है - एक होस्ट पर कई, हर एक अपनी डायरेक्टरी में, यही सामान्य रूप है। औसत के बजाय सबसे भारी जॉब से आकार तय करें, और डिस्क में जगह छोड़ें: वर्कस्पेस, टूल कैश और कंटेनर लेयर सभी इस पर रहते हैं, और यही टिकाऊपन शुरुआत में सेल्फ-होस्ट करने का कारण है। व्यापार का ईमानदार आधा हिस्सा ध्यान दें: एक फ़्लैट मासिक होस्ट उस हफ़्ते भी उतना ही खर्च करता है जब कोई पुश नहीं करता, जहाँ होस्टेड मिनट कुछ खर्च नहीं करते। यह उस बिंदु से फ़ायदेमंद है जहाँ पाइपलाइन अधिकांश दिनों में चलती है।
एक नए होस्ट पर GitHub Actions रनर कैसे इंस्टॉल करें
Linux x64, GitHub जिस क्रम में दस्तावेज़ीकृत करता है उसमें। पंजीकरण टोकन प्रति रनर जनरेट होता है और पेज खोलने के एक घंटे बाद समाप्त हो जाता है, इसलिए इसे आखिर में लें।
-
इसके लिए एक अप्रिविलेज्ड उपयोगकर्ता बनाएं
sudo adduser --disabled-password --gecos "" runner sudo -iu runnerरनर जो भी वर्कफ़्लो इसे बताता है वह करता है, इसलिए इसे रूट नहीं होना चाहिए और इसे किसी और चीज़ के साथ होम शेयर नहीं करना चाहिए। नीचे सब कुछ इस उपयोगकर्ता के रूप में चलता है।
-
रनर डाउनलोड करें और अनपैक करें
mkdir actions-runner && cd actions-runner curl -O -L https://github.com/actions/runner/releases/download/v2.336.0/actions-runner-linux-x64-2.336.0.tar.gz echo "04cf0be1aff4c3ec3554466c39124ca250e3effd8873bb7e8d68535aa9505d5d actions-runner-linux-x64-2.336.0.tar.gz" | shasum -a 256 -c tar xzf ./actions-runner-linux-x64-2.336.0.tar.gzवह वर्शन और वह चेकसम रिलीज़ v2.336.0 के साथ प्रकाशित हैं। इसे कॉपी करने से पहले किसी नए के लिए रिलीज़ पेज देखें: रनर बाद में स्वयं-अपडेट होता है, लेकिन पहला डाउनलोड आपको सत्यापित करना है।
-
इसे किसी रिपॉज़िटरी या संगठन के विरुद्ध कॉन्फ़िगर करें
./config.sh --url https://github.com/YOUR-ORG/YOUR-REPO --token AXXXXXXXXXXXXXXXXXXXXXXXXX --labels self-hosted,linux,x64,euटोकन को Settings, फिर Actions, फिर Runners, फिर New self-hosted runner से लें - यह समय-सीमित है और जारी होने के एक घंटे बाद समाप्त हो जाता है। रिपॉज़िटरी के बजाय संगठन पर URL पॉइंट करें ताकि रिपॉज़िटरी में एक रनर साझा किया जा सके।
-
इसे एक सेवा के रूप में चलाएं
sudo ./svc.sh install runner sudo ./svc.sh start sudo ./svc.sh statussvc.sh वह उपयोगकर्ता लेता है जिसके रूप में सेवा चलनी चाहिए, इसीलिए रनर उपयोगकर्ता पहले बनाया गया था। यदि आप किसी सेवा के लिए प्रतिबद्ध होने से पहले केवल एक जॉब को लैंड होते देखना चाहते हैं तो इसके बजाय ./run.sh का उपयोग करें।
-
needrestart को बीच रन में जॉब को मारने से रोकें
echo '$nrconf{override_rc}{qr(^actions\.runner\..+\.service$)} = 0;' | sudo tee /etc/needrestart/conf.d/actions_runner_services.confDebian और Ubuntu पर, needrestart उन सेवाओं को रीस्टार्ट करता है जिनकी लाइब्रेरी अपडेट की गई थीं - जिसमें जॉब के बीच में एक रनर भी शामिल है। GitHub इस बिल्कुल यही फ़ाइल को इसे छूट देने के तरीके के रूप में दस्तावेज़ीकृत करता है।
-
इस पर एक वर्कफ़्लो पॉइंट करें
name: smoke on: [push] jobs: build: runs-on: [self-hosted, linux, x64, eu] steps: - uses: actions/checkout@v6 - run: cat /etc/os-releaseruns-on सूची में हर लेबल से मेल खाता है, इसलिए चार लेबल माँगने वाला जॉब केवल उस रनर पर लैंड होता है जिसके पास चारों हैं। यदि यह कतार में रहता है, तो एक लेबल गायब है - और 24 घंटे से ज़्यादा कतार में रहा जॉब फ़ेल हो जाता है।
आधिकारिक दस्तावेज़ीकरण के विरुद्ध जाँचा गया 2026-08-15 — स्रोत पढ़ें
हम क्या नहीं हैं
- हम GitHub नहीं हैं। GitHub, GitHub Actions और रनर उनके हैं, और इस पेज पर कुछ भी उनके द्वारा समर्थित नहीं है। हम वह मशीन बेचते हैं जिस पर रनर चलता है।
- यह आपके GitHub प्लान की जगह नहीं लेता। सेल्फ-होस्टेड रनर में कोई Actions मिनट खर्च नहीं होता, जो कि मुद्दा है, लेकिन सीटें, स्टोरेज और बाकी सब कुछ उनके इनवॉइस पर ही रहता है।
- जब तक आप न पूछें, हम रनर का प्रबंधन नहीं करते। इसे आप इंस्टॉल करते हैं, या आप हमारी प्रशासन सेवा जोड़ते हैं और हम इसे पैच्ड, पंजीकृत और निगरानी में रखते हैं।
- सेल्फ-होस्टेड रनर सार्वजनिक रिपॉज़िटरी के लिए एक खराब फ़िट के रूप में दस्तावेज़ीकृत हैं: एक फ़ोर्क एक वर्कफ़्लो परिवर्तन प्रस्तावित कर सकता है और इसे आपकी मशीन पर चला सकता है। जब तक आपने इसके बारे में पूरी तरह सोच न लिया हो, इन्हें निजी रिपॉज़िटरी पर ही रखें।
- यहाँ कोई ऑटोस्केलिंग कंट्रोल प्लेन नहीं है। यदि आप चाहते हैं कि रनर प्रति जॉब बनें और नष्ट हों, तो वह Kubernetes क्लस्टर पर Actions Runner Controller है - जिसे हम एक अलग पेज पर खुशी से होस्ट करेंगे।
वे हिस्से जो टीमें देर से खोजती हैं
- एक रनर सेवा एक बार में एक जॉब चलाती है। समवर्तिता किसी सेटिंग से नहीं, बल्कि कई इंस्टॉल करने से आती है, हर एक अपनी डायरेक्टरी में अपनी सेवा के साथ।
- पंजीकरण टोकन जारी होने के एक घंटे बाद समाप्त हो जाता है, इसलिए दोपहर की शुरुआत में नहीं बल्कि जब आप config.sh चलाने के लिए तैयार हों तब इसे जनरेट करें।
- लेबल पूरा रूटिंग तंत्र हैं। runs-on सूची के हर लेबल से मेल खाता है, इसलिए एक टाइपो त्रुटि नहीं देता - जॉब बस प्रतीक्षा करता है, और कतार में 24 घंटे बाद फ़ेल हो जाता है।
- रनर को lttng-ust, OpenSSL, Kerberos, zlib और libicu की उपस्थिति चाहिए। Debian और Ubuntu इन्हें रखते हैं; एक न्यूनतम कंटेनर इमेज अक्सर नहीं रखती।
- Linux पर x64 और ARM64 सपोर्टेड हैं, और ARM32 केवल Linux पर। Debian 10 और बाद के, और Ubuntu 20.04 और बाद के, दस्तावेज़ीकृत आधार हैं।
- वर्कफ़्लो जो कुछ भी पीछे छोड़ता है वह डिस्क पर रहता है - यही सुविधा है, और यही कारण भी है कि एक सेल्फ-होस्टेड रनर को एक शेड्यूल्ड क्लीन-अप जॉब और एक स्नैपशॉट चाहिए।
होस्टेड CI मिनट बनाम आपका अपना रनर
| प्रोवाइडर-होस्टेड CI मिनट | DCXV पर एक रनर | |
|---|---|---|
| आप किसके लिए भुगतान करते हैं | जब तक प्रोजेक्ट रहता है, हर जॉब के चलने का हर मिनट | उस महीने पाइपलाइन जो भी करे, एक फ़्लैट मासिक होस्ट |
| एक बिल्ड जो धीमी हो जाती है | हर महीने जब तक यह धीमी रहती है ज़्यादा खर्च होता है | और कुछ खर्च नहीं होता - मशीन का भुगतान पहले से हो चुका है |
| Docker लेयर कैश | जब तक आप इसे स्वयं अपलोड और डाउनलोड न करें हर जॉब पर कोल्ड | स्थानीय NVMe पर वार्म, जॉब्स के बीच और दिनों के बीच |
| समवर्तिता | एक प्लान स्तर जिसे आप अपग्रेड करते हैं | एक संख्या जिसे आप अपनी कॉन्फ़िगरेशन फ़ाइल में सेट करते हैं |
| चेकआउट कहाँ लैंड होता है | एक साझा फ्लीट, अक्सर एक ऐसे क्षेत्र में जिसे आप पिन नहीं कर सकते | प्राग या कोविल्हा में एक मशीन, एक साइप्रस अनुबंध के अंतर्गत |
| आउटबाउंड पता | एक बड़ी साझा रेंज जिसे कोई अनुमति नहीं दे सकता | AS204057 से एक स्थिर IPv4, अनुमति देने के लिए आपका |
| मशीन क्या रख सकती है | जो भी रनर इमेज संयोग से साथ में शिप हो | कोई भी टूलचेन, लाइसेंस या फ़िक्सचर सेट जिसे आप एक बार इंस्टॉल करते हैं |
यह आपके होस्ट पर कैसे शुरू होता है
बताएं कि पाइपलाइन क्या करती है
आज आप जो सबसे भारी जॉब चलाते हैं, एक साथ कितने चाहिए, और क्या यह कंटेनर इमेज बनाता है। बिना अनुमान लगाए होस्ट का आकार तय करने के लिए इतना पर्याप्त है।
हम मशीन सौंपते हैं
प्राग या कोविल्हा, रूट एक्सेस और एक स्थिर IPv4, दस मिनट से कम में। यदि रनर पहले से किसी इमेज में बना हुआ है तो अपनी इमेज लाएं।
इस पेज पर दिए गए वॉकथ्रू का पालन करें
यह विक्रेता का क्रम है, किसी ब्लॉग पोस्ट के बजाय उनके वर्तमान दस्तावेज़ीकरण से लिया गया है, और एक स्वच्छ होस्ट पर इसमें कुछ मिनट लगते हैं।
इसका स्नैपशॉट लें, फिर दूसरा जोड़ें
पहली पाइपलाइन के हरी होते ही एक स्नैपशॉट लें, ताकि अगली मशीन एक रीबिल्ड के बजाय एक रीस्टोर हो। एक पूल होस्ट जोड़कर बढ़ता है, एक को विशाल बनाकर नहीं।
हमें क्यों चुनें
- टियर III प्रमाणित फ़ैसिलिटी, 99.982% फ़ैसिलिटी SLA
- स्वयं का नेटवर्क, AS204057, IPv4 और IPv6 ड्यूल-स्टैक
- ~10 मिनट की औसत प्रतिक्रिया के साथ 24/7/365 सहायता
- साइप्रस कंपनी, EU क्षेत्राधिकार, 2007 से GDPR-अनुरूप
FAQ
- सेल्फ-होस्टिंग की तुलना में GitHub होस्टेड रनर की कीमत कितनी है?
GitHub होस्टेड Linux रनर को प्रति मिनट बिल करता है: 2-कोर के लिए USD 0.006, 4-कोर के लिए 0.012, 8-कोर के लिए 0.022 और 16-कोर के लिए 0.042, Windows 2-कोर के लिए 0.010 पर और macOS 3 या 4-कोर मशीन के लिए 0.062 पर। सेल्फ-होस्टेड रनर कोई Actions मिनट खर्च नहीं करते। यहाँ एक होस्ट EUR 16.49 प्रति माह से शुरू होता है, जो लगभग उतना ही है जितना 2-कोर होस्टेड रनर पर 2,700 मिनट की कीमत - इसलिए क्रॉसओवर महीने में लगभग 45 घंटे की बिल्ड समय पर है
- मैं एक सेल्फ-होस्टेड GitHub Actions रनर कैसे सेटअप करूँ?
एक अप्रिविलेज्ड उपयोगकर्ता बनाएं, actions/runner रिलीज़ से linux-x64 के लिए रनर टारबॉल डाउनलोड करें और इसका चेकसम सत्यापित करें, अपने रिपॉज़िटरी या संगठन के URL और Settings फिर Actions फिर Runners से पंजीकरण टोकन के साथ ./config.sh चलाएं, फिर इसे sudo ./svc.sh install से एक सेवा के रूप में इंस्टॉल करें और इसे शुरू करें। सटीक कमांड इस पेज पर हैं। पंजीकरण टोकन जारी होने के एक घंटे बाद समाप्त हो जाता है
- एक रनर एक साथ कितने जॉब चला सकता है?
एक। एक रनर सेवा एक बार में एक ही जॉब लेती है, इसलिए समवर्तिता का मतलब है होस्ट पर कई रनर सेवाएं इंस्टॉल करना, हर एक अपनी डायरेक्टरी में। इसीलिए इस पेज पर आकार निर्धारण जॉब के बजाय रनर सेवाओं की गिनती करता है, और इसीलिए एक 8 vCPU मशीन आराम से एक छोटी मैट्रिक्स बिल्ड ले जा सकती है
- कौन-से ऑपरेटिंग सिस्टम और आर्किटेक्चर समर्थित हैं?
Linux पर, Debian 10 और बाद के, Ubuntu 20.04 और बाद के, RHEL 8 और बाद के, CentOS 8 और बाद के, Fedora 29 और बाद के, openSUSE 15.2 और बाद के और इनके संबंधित, x64, ARM64 और ARM32 पर। रनर को lttng-ust, OpenSSL, Kerberos, zlib और libicu की उपस्थिति भी चाहिए, जिन्हें Debian और Ubuntu मानक रूप में रखते हैं
- क्या सार्वजनिक रिपॉज़िटरी पर सेल्फ-होस्टेड रनर का उपयोग करना सुरक्षित है?
GitHub इसकी सलाह नहीं देता, और कारण ठोस है: कोई भी एक पुल रिक्वेस्ट खोल सकता है जो वर्कफ़्लो फ़ाइल बदल देता है, और वह बदला हुआ वर्कफ़्लो आपकी मशीन पर चलेगा। जब तक आपने इसे पूरी तरह पढ़ न लिया हो और असली आइसोलेशन न लगाया हो, सेल्फ-होस्टेड रनर को निजी रिपॉज़िटरी पर ही रखें। एक जॉब जो कुछ भी पीछे छोड़ता है वह डिस्क पर भी बना रहता है, जो कैशिंग के लिए एक सुविधा है और सीक्रेट्स के लिए एक जोखिम
- क्या एक रनर कई रिपॉज़िटरी की सेवा कर सकता है?
हाँ। इसे रिपॉज़िटरी स्तर के बजाय संगठन स्तर पर पंजीकृत करें और संगठन की हर रिपॉज़िटरी इसे चुन सकती है, काम को रूट करने के लिए runs-on में लेबल का उपयोग करते हुए। एक जॉब जो ऐसे लेबल की माँग करता है जो कोई रनर नहीं रखता वह बस प्रतीक्षा करता है, और कतार में 24 घंटे बाद फ़ेल हो जाता है - runs-on में टाइपो ऐसा ही दिखता है
यदि आपको सहायता चाहिए या अतिरिक्त प्रश्न हैं, तो कृपया मैनेजरों से संपर्क करें या सहायता टीम को इस पते पर लिखें support@dcxv.com
शुरू करने के लिए तैयार हैं?
मासिक बिलिंग, कोई सेटअप शुल्क नहीं, कोई लॉक-इन नहीं