GitLab — कोड स्टोर करने और DevOps प्रक्रियाओं को प्रबंधित करने के लिए एक लोकप्रिय प्लेटफॉर्म है, जिसका उपयोग दुनिया भर में हजारों टीमों द्वारा किया जाता है। लेकिन अगर GitLab तक पहुंच सेवा प्रदाता, कॉर्पोरेट नेटवर्क या पूरे देश के स्तर पर ब्लॉक हो गई है तो क्या करें? और इससे भी बुरा — जब CI/CD पाइपलाइन रात के बीच में गिर जाती है बस इसलिए कि रनर रिपॉजिटरी तक नहीं पहुँच सकता।
इस लेख में, हम समझेंगे कि कैसे Git क्लाइंट, GitLab रनर और कॉर्पोरेट सर्वर के स्तर पर GitLab के लिए प्रॉक्सी सेटअप करें — ताकि पूरी टीम दुनिया के किसी भी कोने से स्थिरता से काम कर सके।
GitLab के लिए प्रॉक्सी की आवश्यकता: वास्तविक परिदृश्य
प्रॉक्सी सेटअप करने से पहले, यह समझना महत्वपूर्ण है कि आप किस समस्या को हल कर रहे हैं। परिस्थितियाँ भिन्न हो सकती हैं, और इससे प्रॉक्सी के प्रकार और इसके कनेक्शन के तरीके का चयन प्रभावित होता है।
परिदृश्य 1: GitLab सेवा प्रदाता या देश के स्तर पर ब्लॉक किया गया है
कई देशों और कॉर्पोरेट नेटवर्क में gitlab.com तक पहुंच सीमित है। एक डेवलपर टर्मिनल खोलता है, git pull लिखता है — और टाइमआउट प्राप्त करता है। इस मामले में, प्रॉक्सी एक मध्यस्थ के रूप में कार्य करती है: ट्रैफ़िक सीधे gitlab.com पर नहीं जाता, बल्कि उस देश में एक मध्यवर्ती सर्वर के माध्यम से जाता है जहां कोई प्रतिबंध नहीं है।
परिदृश्य 2: विभिन्न देशों में वितरित टीम
कल्पना करें: टीम का एक हिस्सा रूस से काम कर रहा है, एक हिस्सा कजाकिस्तान से, और एक हिस्सा यूरोप से। प्रत्येक के पास विभिन्न नेटवर्क स्थितियाँ और विभिन्न प्रतिबंध हैं। सभी को स्थिरता से और समान गति से काम करने के लिए, कंपनियाँ एक कॉर्पोरेट प्रॉक्सी सर्वर तैनात करती हैं, जिसके माध्यम से GitLab के लिए सभी ट्रैफ़िक एक ही चैनल से जाता है।
परिदृश्य 3: CI/CD रनर बाहरी निर्भरताओं तक नहीं पहुँच सकता
GitLab रनर पाइपलाइन शुरू करता है, और npm install या pip install के चरण पर सब कुछ गिर जाता है — क्योंकि जिस सर्वर पर रनर चल रहा है वह एक बंद नेटवर्क में है जिसमें सीधे इंटरनेट तक पहुँच नहीं है। प्रॉक्सी रनर को बाहरी निर्भरताएँ प्राप्त करने की अनुमति देती है, बिना पूरे सर्वर के लिए इंटरनेट तक पूर्ण पहुँच खोले।
परिदृश्य 4: कॉर्पोरेट फ़ायरवॉल के पीछे स्व-होस्टेड GitLab
कंपनी एक आंतरिक नेटवर्क में अपना GitLab सर्वर रखती है। दूरस्थ डेवलपर्स को इससे कनेक्ट करना चाहिए। पूरे ट्रैफ़िक के लिए VPN के बजाय, केवल GitLab ट्रैफ़िक के लिए प्रॉक्सी सेटअप करना अधिक तेज़ और प्रशासन में आसान है।
परिदृश्य 5: ट्रैफ़िक की निगरानी और ऑडिट
बड़े कंपनियाँ सभी ट्रैफ़िक को कॉर्पोरेट प्रॉक्सी के माध्यम से रिपॉजिटरी में भेजती हैं ताकि गतिविधियों को लॉग किया जा सके, यह नियंत्रित किया जा सके कि कौन क्या पुश कर रहा है, और अवांछित ऑपरेशनों को ब्लॉक किया जा सके। यह सुरक्षा की आवश्यकता है, न कि प्रतिबंधों को बायपास करने के लिए।
सेटअप से पहले समझना महत्वपूर्ण है:
GitLab के लिए प्रॉक्सी एक ही समय में तीन स्तरों पर आवश्यक हो सकता है: डेवलपर की मशीन (Git क्लाइंट), GitLab रनर के साथ सर्वर (CI/CD), और स्वयं GitLab सर्वर (यदि स्व-होस्टेड है)। प्रत्येक स्तर को अलग से सेटअप किया जाता है।
GitLab के लिए कौन सा प्रॉक्सी प्रकार उपयुक्त है
GitLab HTTPS और SSH प्रोटोकॉल पर काम करता है। यह तुरंत निर्धारित करता है कि कौन से प्रॉक्सी प्रकार लागू होते हैं और कौन से नहीं। विकल्पों पर चर्चा करते हैं।
| प्रॉक्सी प्रकार | प्रोटोकॉल | GitLab के लिए उपयुक्त | कब उपयोग करें |
|---|---|---|---|
| HTTP/HTTPS प्रॉक्सी | HTTP, HTTPS | ✓ हाँ | HTTPS के माध्यम से Git, GitLab का वेब इंटरफेस |
| SOCKS5 प्रॉक्सी | TCP (कोई भी) | ✓ हाँ (सर्वश्रेष्ठ विकल्प) | HTTPS और SSH के माध्यम से Git, CI/CD |
| SOCKS4 प्रॉक्सी | TCP | ~ आंशिक रूप से | केवल अगर SOCKS5 नहीं है |
| पारदर्शी प्रॉक्सी | HTTP | ✗ नहीं | उपयुक्त नहीं — प्रतिबंधों को बायपास नहीं करता |
GitLab के साथ काम करने के लिए सबसे अच्छा विकल्प — SOCKS5। यह TCP स्तर पर काम करता है, इसलिए यह HTTPS कनेक्शन (वेब इंटरफेस, HTTPS के माध्यम से git clone) और SSH कनेक्शन (SSH पर git push/pull पोर्ट 22 या 443) दोनों को समान रूप से अच्छी तरह से प्रॉक्सी करता है।
रिहायशी बनाम डेटा सेंटर प्रॉक्सी GitLab के लिए
यहाँ सब कुछ कार्य पर निर्भर करता है। यदि लक्ष्य — GeoIP द्वारा प्रतिबंध को बायपास करना या प्रमाणीकरण के लिए स्थिर IP प्राप्त करना, तो डेटा सेंटर प्रॉक्सी उपयुक्त हैं — वे तेज़, सस्ते हैं और कम विलंबता प्रदान करते हैं, जो बड़े रिपॉजिटरी के साथ काम करते समय महत्वपूर्ण है।
लेकिन यदि आपका कॉर्पोरेट IP GitLab के ब्लॉक लिस्ट में आ गया है (यह आक्रामक स्कैनिंग या सुरक्षा घटनाओं के बाद हो सकता है), तो रिहायशी प्रॉक्सी पर विचार करना चाहिए — उनके IP पते वास्तविक घरेलू उपयोगकर्ताओं के हैं और प्लेटफार्मों द्वारा बहुत कम ब्लॉक किए जाते हैं।
Git क्लाइंट के लिए प्रॉक्सी सेटअप (वैश्विक)
यह सबसे सामान्य परिदृश्य है: डेवलपर अपनी मशीन पर GitLab से कनेक्ट नहीं कर सकता। सेटअप Git की कॉन्फ़िगरेशन के माध्यम से किया जाता है — एक बार, और यह सभी रिपॉजिटरी के लिए काम करता है।
विकल्प A: Git के लिए HTTPS प्रॉक्सी
यदि आप HTTPS के माध्यम से GitLab के साथ काम कर रहे हैं (रिपॉजिटरी का पता https:// से शुरू होता है), तो टर्मिनल में निम्नलिखित कमांड चलाएँ:
# वैश्विक रूप से HTTP प्रॉक्सी सेट करें git config --global http.proxy http://आपका_प्रॉक्सी_IP:पोर्ट # यदि प्रॉक्सी प्रमाणीकरण की आवश्यकता है git config --global http.proxy http://लॉगिन:पासवर्ड@आपका_प्रॉक्सी_IP:पोर्ट # SOCKS5 प्रॉक्सी के लिए (अनुशंसित) git config --global http.proxy socks5://आपका_प्रॉक्सी_IP:पोर्ट # यह सुनिश्चित करने के लिए कि सेटिंग लागू हुई है git config --global --get http.proxy
विकल्प B: केवल gitlab.com के लिए प्रॉक्सी (अन्य रिपॉजिटरी को प्रभावित नहीं करता)
यदि आप नहीं चाहते कि प्रॉक्सी सभी Git ऑपरेशनों पर लागू हो (उदाहरण के लिए, GitHub या Bitbucket सामान्य रूप से काम करते हैं), तो आप केवल विशेष डोमेन के लिए प्रॉक्सी सेट कर सकते हैं:
# केवल gitlab.com के लिए प्रॉक्सी git config --global http.https://gitlab.com.proxy socks5://आपका_प्रॉक्सी_IP:पोर्ट # या आपके स्व-होस्टेड GitLab के लिए git config --global http.https://git.yourcompany.com.proxy socks5://आपका_प्रॉक्सी_IP:पोर्ट
विकल्प C: SSH के माध्यम से प्रॉक्सी (उनके लिए जो SSH के माध्यम से काम करते हैं)
यदि आप SSH के माध्यम से रिपॉजिटरी को क्लोन कर रहे हैं ([email protected]:...), तो प्रॉक्सी सेटअप SSH कॉन्फ़िग में किया जाता है, न कि Git में। फ़ाइल ~/.ssh/config खोलें और जोड़ें:
# Linux/macOS के लिए — nc (netcat) के माध्यम से
Host gitlab.com
HostName gitlab.com
User git
ProxyCommand nc -X 5 -x आपका_प्रॉक्सी_IP:पोर्ट %h %p
# Windows के लिए — connect.exe (Git for Windows) के माध्यम से
Host gitlab.com
HostName gitlab.com
User git
ProxyCommand connect -S आपका_प्रॉक्सी_IP:पोर्ट %h %p
सेटअप के बाद, कनेक्शन की जांच करने के लिए कमांड चलाएँ ssh -T [email protected]। यदि सब कुछ सही सेटअप किया गया है, तो आप GitLab से स्वागत संदेश देखेंगे।
जब प्रॉक्सी की आवश्यकता नहीं हो तो उसे कैसे बंद करें
# वैश्विक प्रॉक्सी हटाएँ git config --global --unset http.proxy # विशेष डोमेन के लिए प्रॉक्सी हटाएँ git config --global --unset http.https://gitlab.com.proxy
GitLab रनर और CI/CD पाइपलाइनों के लिए प्रॉक्सी
GitLab रनर एक एजेंट है जो .gitlab-ci.yml से कार्यों को निष्पादित करता है। यदि रनर एक बंद नेटवर्क में है या सीमित इंटरनेट पहुँच वाले सर्वर पर है, तो प्रॉक्सी को अलग से सेटअप करना आवश्यक है। यहाँ डेवलपर के Git क्लाइंट की सेटिंग मदद नहीं करेगी — रनर एक अलग मशीन पर काम करता है।
तरीका 1: रनर की कॉन्फ़िगरेशन में पर्यावरण चर
GitLab रनर की कॉन्फ़िगरेशन फ़ाइल खोलें (आमतौर पर /etc/gitlab-runner/config.toml) और [runners.env] सेक्शन में पर्यावरण चर जोड़ें:
[[runners]]
name = "my-runner"
url = "https://gitlab.com/"
token = "आपका_टोकन"
executor = "shell"
environment = [
"HTTP_PROXY=http://आपका_प्रॉक्सी_IP:पोर्ट",
"HTTPS_PROXY=http://आपका_प्रॉक्सी_IP:पोर्ट",
"NO_PROXY=localhost,127.0.0.1,आपका-आंतरिक-डोमेन.com"
]
कॉन्फ़िगरेशन में परिवर्तन करने के बाद, रनर को पुनः प्रारंभ करें: sudo gitlab-runner restart
तरीका 2: .gitlab-ci.yml में चर (पाइपलाइन स्तर पर)
यदि आप रनर के व्यवस्थापक नहीं हैं या केवल विशेष परियोजना के लिए प्रॉक्सी सेट करना चाहते हैं, तो पाइपलाइन फ़ाइल में सीधे चर जोड़ें:
variables:
HTTP_PROXY: "http://आपका_प्रॉक्सी_IP:पोर्ट"
HTTPS_PROXY: "http://आपका_प्रॉक्सी_IP:पोर्ट"
NO_PROXY: "localhost,127.0.0.1,.internal.company.com"
stages:
- build
- test
- deploy
build:
stage: build
script:
- npm install # अब प्रॉक्सी के माध्यम से जाएगा
- npm run build
तरीका 3: GitLab परियोजना सेटिंग्स में चर (रिपॉजिटरी में कमिट किए बिना)
संवेदनशील डेटा (प्रॉक्सी के साथ प्रमाणीकरण): अपने प्रोजेक्ट के Settings → CI/CD → Variables में जाएं और HTTP_PROXY, HTTPS_PROXY, NO_PROXY को सुरक्षित (masked) चर के रूप में जोड़ें। ये सभी पाइपलाइनों में स्वचालित रूप से उपलब्ध होंगे, लेकिन लॉग में दिखाई नहीं देंगे।
NO_PROXY के बारे में — मत भूलिए!
चर NO_PROXY महत्वपूर्ण है। इसमें सभी आंतरिक डोमेन और IP को जोड़ना चाहिए, जिनसे रनर को सीधे कनेक्ट करना चाहिए, प्रॉक्सी को बायपास करते हुए। अन्यथा, रनर आंतरिक सेवाओं के लिए भी प्रॉक्सी के माध्यम से जाने की कोशिश करेगा — और पाइपलाइन गिर जाएगी।
Docker executor के लिए प्रॉक्सी
यदि रनर Docker executor का उपयोग करता है, तो डिफ़ॉल्ट रूप से कंटेनर होस्ट की प्रॉक्सी सेटिंग्स को विरासत में नहीं लेते हैं। आपको या तो config.toml में [runners.docker] सेक्शन में चर जोड़ने की आवश्यकता है, या होस्ट पर एक फ़ाइल /etc/systemd/system/docker.service.d/proxy.conf बनानी होगी:
[Service] Environment="HTTP_PROXY=http://आपका_प्रॉक्सी_IP:पोर्ट" Environment="HTTPS_PROXY=http://आपका_प्रॉक्सी_IP:पोर्ट" Environment="NO_PROXY=localhost,127.0.0.1"
इसके बाद: sudo systemctl daemon-reload && sudo systemctl restart docker
स्व-होस्टेड GitLab सर्वर के लिए प्रॉक्सी
यदि आप अपने स्वयं के GitLab सर्वर (Omnibus या Helm के माध्यम से स्थापित) का प्रशासन कर रहे हैं, तो प्रॉक्सी की आवश्यकता होती है ताकि GitLab बाहरी सेवाओं से संपर्क कर सके: सूचनाएँ भेजना, बाहरी CI सिस्टम से कनेक्ट करना, उपयोगकर्ताओं के अवतार अपलोड करना, Jira या Slack के साथ एकीकृत होना।
gitlab.rb में सेटअप (Omnibus-स्थापना)
फ़ाइल /etc/gitlab/gitlab.rb खोलें और निम्नलिखित पंक्तियों को जोड़ें या अनकमेंट करें:
# GitLab के लिए प्रॉक्सी (Omnibus)
gitlab_rails['env'] = {
"http_proxy" => "http://आपका_प्रॉक्सी_IP:पोर्ट",
"https_proxy" => "http://आपका_प्रॉक्सी_IP:पोर्ट",
"no_proxy" => "localhost,127.0.0.1,आपका_आंतरिक_डोमेन"
}
# यदि प्रॉक्सी प्रमाणीकरण के साथ है:
gitlab_rails['env'] = {
"http_proxy" => "http://लॉगिन:पासवर्ड@आपका_प्रॉक्सी_IP:पोर्ट",
"https_proxy" => "http://लॉगिन:पासवर्ड@आपका_प्रॉक्सी_IP:पोर्ट",
"no_proxy" => "localhost,127.0.0.1"
}
कॉन्फ़िगरेशन में परिवर्तन करने के बाद, सेटिंग्स लागू करें: sudo gitlab-ctl reconfigure
व्यवस्थापक क्षेत्र के माध्यम से आउटबाउंड कनेक्शन सेटअप
GitLab 15.0+ में वेब इंटरफेस के माध्यम से प्रॉक्सी सेटअप करने की क्षमता आई है: Admin Area → Settings → Network → Outbound requests पर जाएं। यहाँ आप आउटबाउंड वेबहुक के लिए प्रॉक्सी निर्दिष्ट कर सकते हैं और उन IP रेंज को सीमित कर सकते हैं जिनसे GitLab संपर्क कर सकता है। यह सुरक्षा के लिए उपयोगी है — वेबहुक के माध्यम से SSRF हमलों को रोकता है।
पूरी टीम के लिए पहुंच का आयोजन प्रॉक्सी के माध्यम से
जब 5–50 लोगों की टीम के लिए GitLab तक स्थिर पहुंच सुनिश्चित करनी हो, तो प्रत्येक मशीन पर व्यक्तिगत सेटअप सबसे अच्छा दृष्टिकोण नहीं है। चलिए अधिक स्केलेबल समाधानों पर विचार करते हैं।
विधि 1: कॉर्पोरेट प्रॉक्सी सर्वर
एक प्रॉक्सी सर्वर (जैसे, Squid या 3proxy) तैनात किया जाता है जिसमें इंटरनेट तक पहुंच होती है। सभी डेवलपर्स इस सर्वर का उपयोग करने के लिए Git को सेटअप करते हैं। लाभ: केंद्रीकृत प्रबंधन, एकल नियंत्रण बिंदु, ट्रैफ़िक को लॉग करना संभव है। कमी: सर्वर एकल बिंदु विफलता बन जाता है।
विधि 2: रिपॉजिटरी का मिरर (mirror)
GitLab रिपॉजिटरी का मिररिंग का समर्थन करता है। आप आंतरिक नेटवर्क में स्व-होस्टेड GitLab को gitlab.com के रूप में मिरर सेटअप कर सकते हैं। डेवलपर्स आंतरिक सर्वर के साथ काम करते हैं, और यह प्रॉक्सी के माध्यम से बाहरी के साथ समन्वयित होता है। यह प्रत्येक डेवलपर के लिए प्रॉक्सी कनेक्शन की गुणवत्ता पर निर्भरता को कम करता है।
विधि 3: डॉटफाइल्स या ऑनबोर्डिंग स्क्रिप्ट के माध्यम से स्वचालित सेटअप
उन टीमों के लिए जहाँ प्रत्येक डेवलपर अपना वातावरण स्वयं सेट करता है, एक ऑनबोर्डिंग स्क्रिप्ट बनाना सुविधाजनक होता है, जो स्वचालित रूप से आवश्यक Git सेटिंग्स को लिखती है। स्क्रिप्ट कॉर्पोरेट रिपॉजिटरी में रखी जाती है और नए कार्यस्थल को सेट करते समय चलायी जाती है।
#!/bin/bash
# setup-git-proxy.sh — नए कार्यस्थल को सेट करते समय चलाएँ
PROXY_HOST="proxy.company.com"
PROXY_PORT="3128"
echo "GitLab तक पहुंच के लिए Git प्रॉक्सी सेटअप कर रहा हूँ..."
git config --global http.https://gitlab.com.proxy "socks5://${PROXY_HOST}:${PROXY_PORT}"
git config --global http.sslVerify true
echo "हो गया! जांचें: git config --global --list | grep proxy"
टीम तैनाती के लिए चेकलिस्ट
- यह निर्धारित करें कि क्या डेवलपर्स, रनर्स या GitLab सर्वर (या सभी तीनों) के स्तर पर प्रॉक्सी की आवश्यकता है
- प्रॉक्सी का प्रकार चुनें: अधिकतम संगतता के लिए SOCKS5
- सभी आंतरिक डोमेन और सेवाओं के लिए
NO_PROXYसेट करें - प्रॉक्सी के माध्यम से SSH कुंजियों के काम की जांच करें (अलग कदम!)
- कॉर्पोरेट विकी में सेटिंग्स को दस्तावेजित करें
- नए कर्मचारियों के लिए ऑनबोर्डिंग स्क्रिप्ट बनाएं
- प्रॉक्सी सर्वर की उपलब्धता की निगरानी सेट करें
आम समस्याएं और उनका समाधान
सही सेटअप के बाद भी कभी-कभी कुछ गलत हो जाता है। यहाँ सबसे सामान्य समस्याएँ और उनके निदान के तरीके हैं।
समस्या 1: SSL प्रमाणपत्र समस्या: स्थानीय जारीकर्ता प्रमाणपत्र प्राप्त करने में असमर्थ
यह त्रुटि तब होती है जब प्रॉक्सी सर्वर (विशेष रूप से कॉर्पोरेट) SSL निरीक्षण करता है — GitLab के प्रमाणपत्र को अपने द्वारा प्रतिस्थापित करता है। Git इस प्रमाणपत्र पर भरोसा नहीं करता। समाधान: कॉर्पोरेट रूट प्रमाणपत्र को विश्वसनीय में जोड़ें।
# अस्थायी समाधान (डिबगिंग के लिए, उत्पादन के लिए नहीं!) git config --global http.sslVerify false # सही समाधान: कॉर्पोरेट प्रमाणपत्र जोड़ें git config --global http.sslCAInfo /पथ/तक/corporate-ca-bundle.crt
समस्या 2: प्रॉक्सी HTTPS के लिए काम करता है, लेकिन SSH काम नहीं करता
यह एक क्लासिक स्थिति है: Git में http.proxy~/.ssh/config
विकल्प: SSH के बजाय HTTPS के माध्यम से GitLab के साथ काम करने के लिए स्विच करें। इसके लिए रिमोट URL को बदलें:
# वर्तमान रिमोट की जांच करें git remote -v # SSH से HTTPS पर बदलें git remote set-url origin https://gitlab.com/username/repo.git
समस्या 3: CI/CD पाइपलाइन रिपॉजिटरी क्लोनिंग के चरण पर लटकती है
रनर GitLab से सीधे रिपॉजिटरी को टोकन का उपयोग करके क्लोन करता है। यदि रनर प्रॉक्सी के पीछे है, तो यह क्लोनिंग भी प्रॉक्सी के माध्यम से होनी चाहिए। सुनिश्चित करें कि HTTP_PROXY और HTTPS_PROXY चर config.toml.gitlab-ci.yml
समस्या 4: प्रॉक्सी काम कर रहा है, लेकिन बहुत धीमा है
यदि पुश/पुल काम कर रहे हैं, लेकिन सामान्य से 5–10 गुना अधिक समय ले रहे हैं, तो समस्या प्रॉक्सी सर्वर की बैंडविड्थ या इसके भौगोलिक स्थान में हो सकती है। बड़े रिपॉजिटरी (100+ MB) के साथ काम करते समय, कम विलंबता और उच्च बैंडविड्थ वाले प्रॉक्सी का चयन करना महत्वपूर्ण है। इस मामले में डेटा सेंटर प्रॉक्सी रिहायशी प्रॉक्सी की तुलना में प्राथमिकता रखते हैं — वे अधिक स्थिर चैनल प्रदान करते हैं।
समस्या 5: प्रॉक्सी के माध्यम से प्रमाणीकरण के लिए पासवर्ड फिर से दर्ज करने की आवश्यकता है
यदि प्रॉक्सी बेसिक प्रमाणीकरण की आवश्यकता है, और Git हर बार पासवर्ड मांगता है, तो क्रेडेंशियल हेल्पर सेट करें:
# macOS — Keychain का उपयोग करें git config --global credential.helper osxkeychain # Windows — Windows Credential Manager का उपयोग करें git config --global credential.helper manager # Linux — 1 घंटे के लिए कैश करें git config --global credential.helper "cache --timeout=3600"
प्रॉक्सी के साथ समस्या का त्वरित निदान कैसे करें:
उपयोग करें GIT_TRACE=1 GIT_CURL_VERBOSE=1 git clone https://gitlab.com/... — यह सभी HTTP अनुरोधों और प्रतिक्रियाओं का विस्तृत लॉग प्रदर्शित करेगा, जिसमें प्रॉक्सी के बारे में जानकारी शामिल है।
निष्कर्ष और सिफारिशें
GitLab के लिए प्रॉक्सी सेटअप एक ऐसा कार्य है जो एक साथ कई स्तरों पर हल किया जाता है। डेवलपर को अपनी कार्य मशीन पर Git या SSH में कुछ पंक्तियाँ लिखने की आवश्यकता होती है। CI/CD के लिए, रनर की कॉन्फ़िगरेशन या परियोजना सेटिंग्स में पर्यावरण चर जोड़ने की आवश्यकता होती है। और स्व-होस्टेड GitLab के लिए — gitlab.rb
मुख्य नियम जो अधिकांश समस्याओं से बचने में मदद करेंगे:
- SOCKS5 का उपयोग करें — यह HTTPS और SSH दोनों के साथ काम करता है
- हमेशा आंतरिक सेवाओं के लिए
NO_PROXY - उत्पादन में SSL सत्यापन को बंद न करें — कॉर्पोरेट प्रमाणपत्र जोड़ें
- CI/CD के लिए
config.toml.gitlab-ci.yml में - सेटिंग्स को दस्तावेजित करें — टीम में नया डेवलपर धन्यवाद कहेगा
यदि आप दुनिया के किसी भी कोने से GitLab तक स्थिर पहुंच के लिए एक विश्वसनीय प्रॉक्सी की तलाश कर रहे हैं, तो हम डेटा सेंटर प्रॉक्सी पर विचार करने की सिफारिश करते हैं — वे उच्च डेटा ट्रांसफर गति और कम विलंबता प्रदान करते हैं, जो बड़े रिपॉजिटरी और गहन CI/CD पाइपलाइनों के साथ काम करते समय विशेष रूप से महत्वपूर्ण है। टीमों के लिए, जिन्हें अधिकतम गुमनामी या GeoIP प्रतिबंधों को बायपास करने की आवश्यकता है, रिहायशी प्रॉक्सी वास्तविक घरेलू उपयोगकर्ताओं के IP के साथ उपयुक्त हैं।
```