GitLab Runner होस्टिंग, ऐसी मशीन पर जो आपकी है
प्राग या कोविल्हा में एक सेल्फ-मैनेज्ड रनर, जिसके पास पूरी डिस्क अपने लिए है, ताकि दिन की दूसरी पाइपलाइन पर भी Docker लेयर कैश अभी भी वहाँ हो और बिल्ड के हिलने पर इनवॉइस न हिले।
यह किसके लिए है
कंप्यूट मिनट खरीदने वाली एक टीम
टेस्ट सूट बड़ा हो गया, इसलिए पाइपलाइन लंबी हो गई, इसलिए बिल बढ़ गया - और प्लान जो एकमात्र लीवर देता है वह ठीक उन्हीं मिनटों को और खरीदना है।
एक पाइपलाइन जो एक ही मशीन दो बार चाहती है
हर जॉब एक खाली डिस्क से शुरू होता है। बेस इमेज फिर खींची जाती है, डिपेंडेंसी फिर लाई जाती हैं, और कैश अपलोड करने में उस चरण से ज़्यादा समय लगता है जिसे यह बचाने वाला था।
एक रेज़िडेंसी नियम के अंतर्गत एक रिपॉज़िटरी
सोर्स, आर्टिफ़ैक्ट्स और डिप्लॉय की चाबियाँ सभी रनर से गुज़रती हैं, और "कहीं एक साझा फ्लीट" वह जवाब है जिस पर आपका ऑडिटर बार-बार लाल घेरा लगाता रहता है।
एक सेल्फ-मैनेज्ड रनर आपको वापस क्या देता है
- स्थानीय NVMe पर एक वार्म Docker लेयर कैश, ताकि दिन की दूसरी पाइपलाइन खाली डिस्क के बजाय वहीं से शुरू हो जहाँ पहली समाप्त हुई थी।
- आपकी पसंद का कोई भी executor - docker, shell, docker-autoscaler, instance या kubernetes - एक प्लान द्वारा सौंपे जाने के बजाय प्रति रनर चुना गया।
- अगले स्तर के रूप में खरीदने के बजाय config.toml में एक संख्या के रूप में सेट की गई आपकी अपनी समवर्तिता।
- जब आपको वास्तव में Docker-in-Docker की आवश्यकता हो तो प्रिविलेज्ड मोड, जो कोई साझा फ्लीट कभी नहीं देगा।
- AS204057 से एक स्थिर आउटबाउंड IPv4, ताकि एक डिप्लॉय लक्ष्य, पैकेज मिरर या डेटाबेस फ़ायरवॉल पते के अनुसार रनर को अनुमति दे सके।
- जो भी बिल्ड को होस्ट पर वास्तव में चाहिए: एक पुरानी टूलचेन, एक लाइसेंस युक्त SDK, या फ़िक्सचर सेट जिसे कोई हर जॉब में एक बार डाउनलोड नहीं करना चाहता।
पाइपलाइन वास्तव में क्या करती है उसके अनुसार आकार
GitLab रनर के लिए स्वयं कोई हार्डवेयर आवश्यकता प्रकाशित नहीं करता, और यह कोई चूक नहीं है: रनर प्रोसेस छोटा है और बिल्ड नहीं, इसलिए जो संख्या मायने रखती है वह जॉब है। आज आप जो सबसे भारी जॉब चलाते हैं वहाँ से शुरू करें, अपनी चाही गई समवर्तिता से गुणा करें, और डिस्क के साथ उदार रहें - लेयर कैश और बिल्ड वर्कस्पेस ही इसे भरते हैं, और एक भरी हुई डिस्क पाइपलाइन को इस तरह फ़ेल करती है जैसे टूटा हुआ टेस्ट लगे। एक चीज़ जो एक फ़्लैट मासिक होस्ट नहीं करता वह है शांत हफ़्ते में गायब हो जाना: जब कोई पुश नहीं करता तो होस्टेड मिनट कुछ खर्च नहीं करते, और इसकी कीमत उतनी ही रहती है। यह उस बिंदु से फ़ायदेमंद है जहाँ पाइपलाइन अधिकांश दिनों में चलती है।
एक नए होस्ट पर GitLab Runner कैसे इंस्टॉल करें
Debian या Ubuntu, एक स्वच्छ सर्वर से, GitLab जिस क्रम में दस्तावेज़ीकृत करता है उसमें। नीचे सब कुछ उनका क्रम है, हमारा नहीं।
-
आधिकारिक पैकेज रिपॉज़िटरी जोड़ें
curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" -o script.deb.sh less script.deb.sh sudo bash script.deb.shGitLab रिपॉज़िटरी को एक सेटअप स्क्रिप्ट के रूप में शिप करता है और आपसे इसे चलाने से पहले पढ़ने के लिए कहता है, इसीलिए उनके अपने निर्देश इसे सीधे शेल में पाइप करने के बजाय पहले डाउनलोड करते हैं।
-
रनर इंस्टॉल करें
sudo apt install gitlab-runnerपैकेज एक gitlab-runner सिस्टम उपयोगकर्ता बनाता है जिसकी होम डायरेक्टरी बिना किसी स्केलेटन फ़ाइल के खाली बनाई जाती है। एक वर्शन पिन करने के लिए, gitlab-runner और gitlab-runner-helper-images को एक साथ एक ही वर्शन में इंस्टॉल करें - 17.7.1 से वे एक जोड़ी हैं, और केवल एक का नाम लेने पर डिपेंडेंसी त्रुटि पर फ़ेल हो जाता है।
-
Docker इंस्टॉल करें, यदि जॉब कंटेनरों में चलते हैं
sudo apt install docker.io sudo systemctl enable --now dockerdocker executor API v1.25 पर एक स्थानीय Docker Engine से बात करता है, इसलिए डेमन को रनर होस्ट पर ही होना चाहिए। शुरुआत के लिए डिस्ट्रिब्यूशन पैकेज पर्याप्त है; यदि किसी बिल्ड को नई रिलीज़ चाहिए तो Docker की अपनी रिपॉज़िटरी उन्हें ले जाती है।
-
रनर पंजीकृत करें
sudo gitlab-runner register \ --non-interactive \ --url "https://gitlab.com/" \ --token "$RUNNER_TOKEN" \ --executor "docker" \ --docker-image alpine:latest \ --docker-pull-policy "if-not-present" \ --description "docker-runner"पहले GitLab में Settings, फिर CI/CD, फिर Runners के अंतर्गत रनर बनाएं, और यह glrt- से शुरू होने वाला एक ऑथेंटिकेशन टोकन वापस देता है जो --token में जाता है। जॉब टैग और run-untagged विकल्प उसी फ़ॉर्म में सेट करें: ऑथेंटिकेशन टोकन के साथ वे रनर के हैं, register कमांड के नहीं। पुराना --registration-token फ़्लो डेप्रिकेटेड है और GitLab 20.0 में हटाने के लिए निर्धारित है।
-
समवर्तिता सेट करें और इसे शुरू करें
sudo sed -i "s/^concurrent = .*/concurrent = 4/" /etc/gitlab-runner/config.toml sudo gitlab-runner restart sudo gitlab-runner statusजब रनर रूट के रूप में चलता है तो config.toml /etc/gitlab-runner में रहता है। concurrent प्रति-रनर सेटिंग के बजाय इस होस्ट पर पंजीकृत हर रनर पर एक ऊपरी सीमा है, और हर रनर उसके अंदर अपनी एक छोटी सीमा रख सकता है।
-
एक जॉब से इसे साबित करें
stages: [test] smoke: stage: test tags: [docker-runner] script: - cat /etc/os-release - echo "built on $CI_RUNNER_DESCRIPTION"इसे .gitlab-ci.yml के रूप में कमिट करें, पुश करें, और जॉब को कुछ सेकंड में आपके होस्ट पर लैंड हो जाना चाहिए। यदि यह कतार में रहता है, तो टैग UI में आपके सेट किए गए टैग से मेल नहीं खाते, या रनर किसी अन्य प्रोजेक्ट से लॉक है।
आधिकारिक दस्तावेज़ीकरण के विरुद्ध जाँचा गया 2026-08-15 — स्रोत पढ़ें
हम क्या नहीं हैं
- हम GitLab नहीं हैं। GitLab, GitLab CI/CD और GitLab Runner उनके हैं, और इस पेज पर कुछ भी उनके द्वारा समर्थित नहीं है। हम जो बेचते हैं वह वह मशीन है जिस पर एक रनर चलता है।
- यह पेज GitLab को स्वयं होस्ट करने के बारे में नहीं है। एक सेल्फ-मैनेज्ड GitLab इंस्टेंस एक बड़ा बॉक्स और एक अलग बातचीत है - पूछें और हम एक का आकार तय करेंगे, लेकिन यह वह नहीं है जिसकी कीमत यहाँ है।
- हम आपकी .gitlab-ci.yml नहीं लिखते। पाइपलाइन आपकी है; होस्ट, नेटवर्क और पता हमारे हैं।
- जब तक आप न पूछें, रनर आपके लिए प्रबंधित नहीं होता। इसे आप इंस्टॉल करते हैं, या आप हमारी प्रशासन सेवा जोड़ते हैं और हम इसे पैच्ड, पंजीकृत और मॉनिटर किया हुआ रखते हैं।
- आपकी GitLab सब्सक्रिप्शन GitLab के साथ ही रहती है। एक सेल्फ-मैनेज्ड रनर उनके कंप्यूट मिनट का उपयोग नहीं करता, जो कि मुद्दा है, लेकिन यह सीटों को भी नहीं बदलता।
वे हिस्से जो टीमें देर से खोजती हैं
- registration-token फ़्लो हटने की राह पर है। UI में बनाया गया एक रनर एक glrt- ऑथेंटिकेशन टोकन वापस देता है जिसे gitlab-runner register --token के रूप में लेता है, और --registration-token GitLab 20.0 में हटाने के लिए निर्धारित है।
- टैग इसके साथ स्थानांतरित हो गए। ऑथेंटिकेशन टोकन के साथ, जॉब टैग, run-untagged विकल्प और लॉक उस रनर ऑब्जेक्ट के हैं जिसे आपने UI में बनाया, इसलिए वे फ़्लैग जो पहले कमांड लाइन पर इन्हें सेट करते थे अब कुछ भी तय नहीं करते।
- एक वर्शन पिन करने का मतलब है दो पैकेज पिन करना। 17.7.1 से, एक स्पष्ट gitlab-runner वर्शन को उसी वर्शन में gitlab-runner-helper-images भी चाहिए, नहीं तो apt इंस्टॉल से इनकार कर देता है।
- check_interval डिफ़ॉल्ट रूप से 3 सेकंड है। कई पंजीकृत रनर वाले होस्ट पर यह बहुत सारा पोलिंग है; नेटवर्क को दोष देने से पहले इसे बढ़ाएं।
- Docker-in-Docker को प्रिविलेज्ड मोड चाहिए, जो प्रभावी रूप से जॉब को होस्ट पर रूट सौंप देता है। यदि पाइपलाइन केवल इमेज बनाती है, तो Kaniko या Buildah जैसा रूटलेस बिल्डर सस्ता विकल्प है।
- जब तक आप कैश को अपने स्वयं के S3-संगत बकेट पर पॉइंट न करें, आर्टिफ़ैक्ट और कैश अभी भी GitLab की ओर जाते हैं। जिस रनर को आपने जानबूझकर EU में स्थानांतरित किया है, उसमें यह आमतौर पर स्थानांतरित करने के लिए बचा अंतिम हॉप है।
होस्टेड CI मिनट बनाम आपका अपना रनर
| प्रोवाइडर-होस्टेड CI मिनट | DCXV पर एक रनर | |
|---|---|---|
| आप किसके लिए भुगतान करते हैं | जब तक प्रोजेक्ट रहता है, हर जॉब के चलने का हर मिनट | उस महीने पाइपलाइन जो भी करे, एक फ़्लैट मासिक होस्ट |
| एक बिल्ड जो धीमी हो जाती है | हर महीने जब तक यह धीमी रहती है ज़्यादा खर्च होता है | और कुछ खर्च नहीं होता - मशीन का भुगतान पहले से हो चुका है |
| Docker लेयर कैश | जब तक आप इसे स्वयं अपलोड और डाउनलोड न करें हर जॉब पर कोल्ड | स्थानीय NVMe पर वार्म, जॉब्स के बीच और दिनों के बीच |
| समवर्तिता | एक प्लान स्तर जिसे आप अपग्रेड करते हैं | एक संख्या जिसे आप अपनी कॉन्फ़िगरेशन फ़ाइल में सेट करते हैं |
| चेकआउट कहाँ लैंड होता है | एक साझा फ्लीट, अक्सर एक ऐसे क्षेत्र में जिसे आप पिन नहीं कर सकते | प्राग या कोविल्हा में एक मशीन, एक साइप्रस अनुबंध के अंतर्गत |
| आउटबाउंड पता | एक बड़ी साझा रेंज जिसे कोई अनुमति नहीं दे सकता | AS204057 से एक स्थिर IPv4, अनुमति देने के लिए आपका |
| मशीन क्या रख सकती है | जो भी रनर इमेज संयोग से साथ में शिप हो | कोई भी टूलचेन, लाइसेंस या फ़िक्सचर सेट जिसे आप एक बार इंस्टॉल करते हैं |
यह आपके होस्ट पर कैसे शुरू होता है
बताएं कि पाइपलाइन क्या करती है
आज आप जो सबसे भारी जॉब चलाते हैं, एक साथ कितने चाहिए, और क्या यह कंटेनर इमेज बनाता है। बिना अनुमान लगाए होस्ट का आकार तय करने के लिए इतना पर्याप्त है।
हम मशीन सौंपते हैं
प्राग या कोविल्हा, रूट एक्सेस और एक स्थिर IPv4, दस मिनट से कम में। यदि रनर पहले से किसी इमेज में बना हुआ है तो अपनी इमेज लाएं।
इस पेज पर दिए गए वॉकथ्रू का पालन करें
यह विक्रेता का क्रम है, किसी ब्लॉग पोस्ट के बजाय उनके वर्तमान दस्तावेज़ीकरण से लिया गया है, और एक स्वच्छ होस्ट पर इसमें कुछ मिनट लगते हैं।
इसका स्नैपशॉट लें, फिर दूसरा जोड़ें
पहली पाइपलाइन के हरी होते ही एक स्नैपशॉट लें, ताकि अगली मशीन एक रीबिल्ड के बजाय एक रीस्टोर हो। एक पूल होस्ट जोड़कर बढ़ता है, एक को विशाल बनाकर नहीं।
हमें क्यों चुनें
- टियर III प्रमाणित फ़ैसिलिटी, 99.982% फ़ैसिलिटी SLA
- स्वयं का नेटवर्क, AS204057, IPv4 और IPv6 ड्यूल-स्टैक
- ~10 मिनट की औसत प्रतिक्रिया के साथ 24/7/365 सहायता
- साइप्रस कंपनी, EU क्षेत्राधिकार, 2007 से GDPR-अनुरूप
FAQ
- एक साझा रनर और एक सेल्फ-मैनेज्ड रनर में क्या अंतर है?
एक साझा रनर GitLab की मशीन है और आप उन मिनटों के लिए भुगतान करते हैं जो यह आपके जॉब पर खर्च करता है। एक सेल्फ-मैनेज्ड रनर आपकी मशीन है: आप इस पर gitlab-runner इंस्टॉल करते हैं, इसे अपने प्रोजेक्ट, ग्रुप या इंस्टेंस के विरुद्ध पंजीकृत करते हैं, और यह बिल्कुल भी कंप्यूट मिनट का उपयोग नहीं करता। GitLab के मुफ़्त-स्तर नेमस्पेस को महीने में 400 कंप्यूट मिनट मिलते हैं, और एक व्यस्त पाइपलाइन कुछ दिनों में उन्हें खत्म कर देती है
- मैं GitLab Runner को कैसे इंस्टॉल और पंजीकृत करूँ?
packages.gitlab.com पर सेटअप स्क्रिप्ट से उनकी apt रिपॉज़िटरी जोड़ें, gitlab-runner पैकेज इंस्टॉल करें, फिर UI में रनर बनाने पर GitLab जो रनर ऑथेंटिकेशन टोकन देता है उसके साथ गैर-इंटरैक्टिव मोड में gitlab-runner register चलाएं। सटीक कमांड के साथ पूरा क्रम इस पेज पर है, किसी ब्लॉग पोस्ट के बजाय उनके दस्तावेज़ीकरण से लिया गया
- क्या रजिस्ट्रेशन टोकन अभी भी रनर पंजीकृत करने का तरीका है?
नहीं, और यही वह बदलाव है जो अधिकांश पुरानी गाइड को तोड़ता है। पहले GitLab UI में रनर बनाएं और यह glrt- से शुरू होने वाला एक ऑथेंटिकेशन टोकन वापस देता है, जिसे gitlab-runner register --token के रूप में लेता है। पुराना --registration-token फ़्लो डेप्रिकेटेड है और GitLab 20.0 में हटाने के लिए निर्धारित है। जॉब टैग, run-untagged विकल्प और लॉक अब उस रनर ऑब्जेक्ट के हैं जिसे आपने UI में बनाया, register कमांड के नहीं
- GitLab Runner को किस आकार के सर्वर की आवश्यकता है?
GitLab रनर के लिए स्वयं कोई हार्डवेयर आवश्यकता प्रकाशित नहीं करता, क्योंकि रनर प्रोसेस छोटा है और आपकी बिल्ड नहीं। सबसे भारी जॉब को आपकी चाही गई समवर्तिता से गुणा करके आकार तय करें। व्यवहार में 4 vCPU, 8 GB और 120 GB NVMe एक बार में दो या तीन जॉब रखता है; 8 vCPU, 16 GB और 240 GB छह से आठ रखता है। डिस्क के साथ उदार रहें - Docker लेयर कैश और वर्कस्पेस ही इसे भरते हैं
- क्या मुझे रनर होस्ट पर Docker चाहिए?
केवल यदि आप docker executor का उपयोग करते हैं, जो अधिकांश लोग करते हैं। यह API v1.25 पर एक स्थानीय Docker Engine से बात करता है, इसलिए डेमन को रनर होस्ट पर ही इंस्टॉल होना चाहिए। shell executor को बिल्कुल भी Docker की ज़रूरत नहीं होती, और instance तथा docker-autoscaler executor कहीं और मशीनें बनाते हैं
- क्या कई रनर एक होस्ट साझा कर सकते हैं?
हाँ, और यही सामान्य रूप है। उसी इंस्टॉलेशन के विरुद्ध जितने चाहें उतने पंजीकृत करें; /etc/gitlab-runner/config.toml में concurrent सेटिंग सभी पर एक ऊपरी सीमा है, और हर रनर अपनी एक छोटी सीमा रख सकता है। check_interval पर नज़र रखें, जो डिफ़ॉल्ट रूप से 3 सेकंड है और एक होस्ट पर एक दर्जन रनर होने पर बहुत सारा पोलिंग बन जाता है
यदि आपको सहायता चाहिए या अतिरिक्त प्रश्न हैं, तो कृपया मैनेजरों से संपर्क करें या सहायता टीम को इस पते पर लिखें support@dcxv.com
शुरू करने के लिए तैयार हैं?
मासिक बिलिंग, कोई सेटअप शुल्क नहीं, कोई लॉक-इन नहीं