इस पेज पर, रिमोट कैश मेमोरी में सेव करने, कैश मेमोरी को होस्ट करने के लिए सर्वर सेट अप करने, और इसके बारे में जानकारी दी गई है बिल्ड बनाने के लिए रिमोट कैश का इस्तेमाल करें.
रिमोट कैश मेमोरी का इस्तेमाल डेवलपर की टीम और/या लगातार इंटिग्रेशन करती है (सीआई) सिस्टम का इस्तेमाल करें. अगर आपका बिल्ड फिर से बनाया जा सकता है, तो एक मशीन के आउटपुट को दूसरी मशीन पर सुरक्षित रूप से फिर से इस्तेमाल किया जा सकता है, जो बनाने में ज़्यादा तेज़ी से काम करता है.
खास जानकारी
Basel ने एक बिल्ड को अलग-अलग चरणों में बांटा है, जिन्हें ऐक्शन कहा जाता है. हर कार्रवाई इसमें इनपुट, आउटपुट के नाम, एक कमांड लाइन, और एनवायरमेंट वैरिएबल शामिल होते हैं. ज़रूरी है हर कार्रवाई के लिए, इनपुट और अनुमानित आउटपुट की जानकारी साफ़ तौर पर दी जाती है.
बिल्ड आउटपुट के लिए किसी सर्वर को रिमोट कैश के तौर पर सेट अप किया जा सकता है. ये कार्रवाई आउटपुट. इन आउटपुट में आउटपुट फ़ाइल नामों की सूची और हैश किए जा सकते हैं. रिमोट कैश की मदद से, बिल्ड आउटपुट का फिर से इस्तेमाल किया जा सकता है स्थानीय तौर पर हर नया आउटपुट बनाने के बजाय, उन्हें किसी अन्य यूज़र के बिल्ड से जोड़ें.
रिमोट कैश मेमोरी में सेव करने की सुविधा इस्तेमाल करने के लिए:
- कैश मेमोरी के बैकएंड के तौर पर सर्वर सेट अप करना
- रिमोट कैश का इस्तेमाल करने के लिए, Basel बिल्ड को कॉन्फ़िगर करें
- Basel का 0.10.0 या इसके बाद वाला वर्शन इस्तेमाल करें
रिमोट कैश मेमोरी दो तरह का डेटा सेव करती है:
- ऐक्शन कैश मेमोरी, जो कार्रवाई के नतीजे के मेटाडेटा से लेकर ऐक्शन हैश का मैप होती है.
- आउटपुट फ़ाइलों का कॉन्टेंट-पता वाले स्टोर (सीएएस)
ध्यान दें कि रिमोट कैश मेमोरी, हर कार्रवाई. इसलिए, Basel के stdout/stderr का निरीक्षण करने से, कैश मेमोरी हिट का अनुमान लगाना.
बिल्ड कैसे रिमोट कैशिंग का इस्तेमाल करता है
सर्वर को रिमोट कैश के तौर पर सेट अप करने के बाद, कैश मेमोरी को एक से ज़्यादा मामलों में इस्तेमाल किया जा सकता है तरीके:
- रिमोट कैश मेमोरी में सेव करें और उसमें बदलाव करें
- चुनिंदा टारगेट को छोड़कर, रिमोट कैश मेमोरी में सेव डेटा को पढ़ें और/या उसमें लिखें
- सिर्फ़ रिमोट कैश मेमोरी से पढ़ें
- रिमोट कैश का बिलकुल इस्तेमाल न करें
जब आपके पास ऐसा Basel बिल्ड है कि वह रिमोट कैश मेमोरी में सेव डेटा को पढ़ और उसमें बदलाव कर सकता है, बिल्ड इन चरणों का पालन करता है:
- बेज़ल उन टारगेट का ग्राफ़ बनाता है जिन्हें बनाने की ज़रूरत होती है. इसके बाद, ज़रूरी कार्रवाइयों की सूची. इनमें से हर कार्रवाई में एलान किए गए इनपुट हैं और आउटपुट फ़ाइल नामों में शामिल होगा.
- Baze, आपकी लोकल मशीन में मौजूदा बिल्ड आउटपुट की जांच करता है और किसी भी मशीन का इस्तेमाल दोबारा करता है मिलता है.
- Baज़ल, मौजूदा बिल्ड आउटपुट के लिए कैश मेमोरी की जांच करता है. अगर आउटपुट मिलता है, Basel, आउटपुट को वापस लाता है. यह कैश मेमोरी हिट है.
- जिन ज़रूरी कार्रवाइयों में आउटपुट नहीं मिले उनके लिए, Baज़ल कार्रवाइयां स्थानीय तौर पर की जाती हैं और ज़रूरी बिल्ड आउटपुट बनाती हैं.
- नए बिल्ड आउटपुट, रिमोट कैश मेमोरी में अपलोड किए जाते हैं.
कैश मेमोरी के बैकएंड के तौर पर सर्वर सेट अप करना
कैश मेमोरी के बैकएंड के तौर पर काम करने के लिए, आपको सर्वर सेट अप करना होगा. एचटीटीपी/1.1 सर्वर बेज़ल के डेटा को ओपेक बाइट और कई मौजूदा सर्वर के तौर पर ट्रीट कर सकता है का इस्तेमाल रिमोट कैशिंग बैकएंड के तौर पर किया जा सकता है. बेज़ल एचटीटीपी कैशिंग प्रोटोकॉल, रिमोट के साथ काम करता है कैश मेमोरी.
बैकएंड को चुनने, उसे सेट अप करने, और उसका रखरखाव करने की ज़िम्मेदारी आपकी है ऐसा सर्वर जो कैश मेमोरी में सेव किए गए आउटपुट को सेव करेगा. सर्वर चुनते समय, इन बातों का ध्यान रखें:
- नेटवर्किंग की स्पीड. उदाहरण के लिए, अगर आपकी टीम उसी ऑफ़िस में है, तो अपना लोकल सर्वर चलाना चाहते हैं.
- सुरक्षा. रिमोट कैश में आपकी बाइनरी होंगी, इसलिए यह सुरक्षित होना चाहिए.
- मैनेज करने में आसान. उदाहरण के लिए, Google Cloud Storage पूरी तरह से मैनेज की जाने वाली सेवा है.
रिमोट कैश के लिए कई बैकएंड इस्तेमाल किए जा सकते हैं. कुछ विकल्प शामिल करें:
nginx
nginx एक ओपन सोर्स वेब सर्वर है. अपने [WebDAV मॉड्यूल] की मदद से, यह
का इस्तेमाल बेज़ल के लिए रिमोट कैश के तौर पर किया जाता है. Debian और Ubuntu पर आप इंस्टॉल कर सकते हैं
nginx-extras
पैकेज. macOS पर nginx, Homebrew के ज़रिए उपलब्ध है:
brew tap denji/nginx
brew install nginx-full --with-webdav
नीचे nginx के लिए कॉन्फ़िगरेशन का एक उदाहरण दिया गया है. ध्यान दें कि आपको
/path/to/cache/dir
को ऐसी मान्य डायरेक्ट्री में बदलें जिसमें nginx को ऐक्सेस करने की अनुमति हो
लिखने और पढ़ने के लिए. आपको client_max_body_size
विकल्प को बदलकर, किसी और को करना पड़ सकता है
बड़ी वैल्यू का इस्तेमाल किया जा सकता है. सर्वर को अन्य
पुष्टि करने जैसा कॉन्फ़िगरेशन.
nginx.conf
में server
सेक्शन के लिए कॉन्फ़िगरेशन का उदाहरण:
location /cache/ {
# The path to the directory where nginx should store the cache contents.
root /path/to/cache/dir;
# Allow PUT
dav_methods PUT;
# Allow nginx to create the /ac and /cas subdirectories.
create_full_put_path on;
# The maximum size of a single file.
client_max_body_size 1G;
allow all;
}
बेज़ल-रिमोट
baez-remote एक ओपन सोर्स रिमोट बिल्ड कैश है जिसका इस्तेमाल आप इन पर कर सकते हैं इस्तेमाल हो रहा है. इसका इस्तेमाल प्रोडक्शन में इस जगह पर हुआ है कई कंपनियां हैं. ध्यान दें कि Basel प्रोजेक्ट basel-remote के लिए तकनीकी सहायता उपलब्ध नहीं कराता है.
यह कैश मेमोरी, डिस्क पर कॉन्टेंट सेव करती है और गै़रबेज इकट्ठा भी करती है ज़्यादा स्टोरेज की सीमा लागू करें और इस्तेमाल न किए गए आर्टफ़ैक्ट को हटाएं. कैश मेमोरी यह है [docker Image] के तौर पर उपलब्ध होती है और इसका कोड GitHub. REST और gRPC रिमोट कैश एपीआई, दोनों काम करते हैं.
GitHub देखें पेज पर जाएं.
Google Cloud Storage
[Google Cloud Storage] एक पूरी तरह से मैनेज किया गया ऑब्जेक्ट स्टोर है. यह वह एचटीटीपी API जो Basel के रिमोट कैशिंग प्रोटोकॉल के साथ काम करता है. इसके लिए ज़रूरी है यह पक्का करें कि आपके पास बिलिंग वाला Google Cloud खाता हो.
Cloud Storage का इस्तेमाल कैश मेमोरी के तौर पर करने के लिए:
स्टोरेज बकेट बनाएं. पक्का करें कि आपने नेटवर्क बैंडविथ के तौर पर, अपने सबसे नज़दीक बकेट की जगह चुनी हो रिमोट कैश के लिए ज़रूरी है.
Cloud Storage के लिए पुष्टि करने के लिए, Bagel के लिए सेवा खाता बनाएं. यहां जाएं: सेवा खाता बनाना.
एक सीक्रेट JSON कुंजी जनरेट करें और उसे पुष्टि के लिए Basel को दें. स्टोर कुंजी को सुरक्षित रखा जाता है, क्योंकि जिसके पास भी कुंजी है वह आर्बिट्रेरी डेटा पढ़ और लिख सकता है आपके GCS (जीसीएस) बकेट तक/से.
अपने Basel कमांड में इन फ़्लैग को जोड़कर, Cloud Storage से कनेक्ट करें:
- फ़्लैग का इस्तेमाल करके नीचे दिए गए यूआरएल को बेज़ल को पास करें:
--remote_cache=https://storage.googleapis.com/bucket-name
जहांbucket-name
आपकी स्टोरेज बकेट का नाम है. - इस फ़्लैग का इस्तेमाल करके पुष्टि करने वाली कुंजी पास करें:
--google_credentials=/path/to/your/secret-key.json
या ऐप्लिकेशन की पुष्टि करने का इस्तेमाल करने के लिए--google_default_credentials
.
- फ़्लैग का इस्तेमाल करके नीचे दिए गए यूआरएल को बेज़ल को पास करें:
पुरानी फ़ाइलों को अपने-आप मिटाने के लिए, Cloud Storage को कॉन्फ़िगर किया जा सकता है. ऐसा करने के लिए, यह देखें ऑब्जेक्ट लाइफ़साइकल मैनेज करना.
अन्य सर्वर
आप कोई भी HTTP/1.1 सर्वर सेट अप कर सकते हैं, जो PUT और GET को कैश मेमोरी के बैकएंड. उपयोगकर्ताओं ने Hazelcast, Apache httpd और AWS S3.
पुष्टि करना
वर्शन 0.11.0 के बाद से, एचटीटीपी बेसिक पुष्टि करने की सुविधा Basel में जोड़ दी गई है.
रिमोट कैश यूआरएल की मदद से, Basel का उपयोगकर्ता नाम और पासवर्ड पास किया जा सकता है. कॉन्टेंट बनाने
सिंटैक्स https://username:password@hostname.com:port/path
है. ध्यान दें कि
एचटीटीपी बेसिक ऑथेंटिकेशन, उपयोगकर्ता नाम और पासवर्ड को सादे टेक्स्ट में
नेटवर्क है और इसलिए इसका इस्तेमाल हमेशा एचटीटीपीएस के साथ करना ज़रूरी है.
एचटीटीपी कैश मेमोरी का प्रोटोकॉल
Baज़ल, एचटीटीपी/1.1 के ज़रिए रिमोट कैशिंग की सुविधा देता है. प्रोटोकॉल सैद्धांतिक रूप से आसान है:
बाइनरी डेटा (BLOB) को PUT अनुरोधों की मदद से अपलोड किया जाता है और जीईटी अनुरोधों के ज़रिए डाउनलोड किया जाता है.
कार्रवाई के नतीजे का मेटाडेटा, पाथ /ac/
में सेव किया जाता है और आउटपुट फ़ाइलें सेव की जाती हैं
पथ /cas/
के अंतर्गत.
उदाहरण के लिए, http://localhost:8080/cache
से चलने वाली रिमोट कैश मेमोरी का इस्तेमाल करें.
SHA256 की मदद से, किसी कार्रवाई के नतीजे का मेटाडेटा डाउनलोड करने के लिए, Basel का अनुरोध
हैश 01ba4719...
इस तरह दिखेगा:
GET /cache/ac/01ba4719c80b6fe911b091a7c05124b64eeece964e09c058ef8f9805daca546b HTTP/1.1
Host: localhost:8080
Accept: */*
Connection: Keep-Alive
SHA256 हैश 15e2b0d3...
के साथ एक आउटपुट फ़ाइल अपलोड करने के लिए, Basel का अनुरोध
सीएएस इस तरह दिखेगा:
PUT /cache/cas/15e2b0d3c33891ebb0f1ef609ec419420c20e320ce94c65fbc8c3312448eb225 HTTP/1.1
Host: localhost:8080
Accept: */*
Content-Length: 9
Connection: Keep-Alive
0x310x320x330x340x350x360x370x380x39
रिमोट कैश का इस्तेमाल करके Basel को चलाएं
रिमोट कैश के तौर पर सर्वर सेट अप होने के बाद, रिमोट कैश मेमोरी का इस्तेमाल करने के लिए को आपके बेज़ेल कमांड में फ़्लैग जोड़ने होंगे. कॉन्फ़िगरेशन की सूची देखें और फ़्लैग कर दिया जाता है.
आपको कॉन्फ़िगर ऑथेंटिकेशन की भी ज़रूरत पड़ सकती है, जो कि आपके चुना गया सर्वर.
आप शायद इन फ़्लैग को किसी .bazelrc
फ़ाइल में जोड़ना चाहें, ताकि आप ये काम न करें
जब भी आप Bagel चलाते हैं, तो उन्हें उन्हें बताने की ज़रूरत होती है. आपके प्रोजेक्ट और
टीम डाइनैमिक के लिए, आप किसी ऐसी .bazelrc
फ़ाइल में फ़्लैग जोड़ सकते हैं जो:
- आपके कंप्यूटर पर
- आपके प्रोजेक्ट के फ़ाइल फ़ोल्डर में, टीम के साथ शेयर किया गया
- सीआई सिस्टम पर
रिमोट कैश मेमोरी से डेटा पढ़ें और उसमें बदलाव करें
इस बात का ध्यान रखें कि रिमोट कैश में सेव करने की सुविधा किसके पास है. शायद आपको ये काम करना चाहिए ताकि आपका CI सिस्टम रिमोट कैश पर डेटा लिख सके.
रिमोट कैश मेमोरी से पढ़ने और उसमें लिखने के लिए, नीचे दिए गए फ़्लैग का इस्तेमाल करें:
build --remote_cache=http://your.host:port
HTTP
के अलावा, ये प्रोटोकॉल भी काम करते हैं: HTTPS
, grpc
, grpcs
.
ऊपर दिए गए फ़्लैग के साथ-साथ नीचे दिए गए फ़्लैग का इस्तेमाल करें. रिमोट कैश मेमोरी:
build --remote_upload_local_results=false
कुछ टारगेट को रिमोट कैश मेमोरी का इस्तेमाल करने से रोकना
रिमोट कैश मेमोरी का इस्तेमाल करने से कुछ खास टारगेट को बाहर रखने के लिए, टारगेट को
no-remote-cache
. उदाहरण के लिए:
java_library(
name = "target",
tags = ["no-remote-cache"],
)
रिमोट कैश मेमोरी से कॉन्टेंट मिटाएं
रिमोट कैश से कॉन्टेंट मिटाना आपके सर्वर को मैनेज करने का हिस्सा है. रिमोट कैश से कॉन्टेंट कैसे मिटाया जाता है, यह आपके सर्वर पर निर्भर करता है को कैश मेमोरी के तौर पर सेट अप करें. आउटपुट को मिटाते समय, या तो कैश मेमोरी का पूरा हिस्सा मिटाएं, या पुराने आउटपुट मिटाएं.
कैश मेमोरी में सेव किए गए आउटपुट, नाम और हैश के सेट के तौर पर सेव किए जाते हैं. मिटाते समय है, तो यह पता लगाने का कोई तरीका नहीं है कि कौनसा आउटपुट बिल्ड.
कॉन्टेंट को कैश मेमोरी से मिटाकर, ये काम किए जा सकते हैं:
- कैश मेमोरी में डाले जाने के बाद, कैश मेमोरी में सेव डेटा को हटाने का तरीका
- पुराने आउटपुट मिटाकर, इस्तेमाल किया जा रहा स्टोरेज कम करें
यूनिक्स सॉकेट
रिमोट एचटीटीपी कैश मेमोरी, Unix डोमेन सॉकेट पर कनेक्ट करने की सुविधा देती है. व्यवहार
कर्ल के --unix-socket
फ़्लैग के समान है. यूनिक्स को कॉन्फ़िगर करने के लिए, इनका इस्तेमाल करें
डोमेन सॉकेट:
build --remote_cache=http://your.host:port
build --remote_cache_proxy=unix:/path/to/socket
यह सुविधा Windows पर काम नहीं करती.
डिस्क की कैश मेमोरी
Basel, फ़ाइल सिस्टम पर मौजूद डायरेक्ट्री का इस्तेमाल, रिमोट कैश के तौर पर कर सकता है. यह है यह विकल्प, ब्रांच स्विच करने और/या काम करने के दौरान, बिल्ड आर्टफ़ैक्ट शेयर करने के लिए मददगार है का इस्तेमाल एक ही प्रोजेक्ट के कई फ़ाइल फ़ोल्डर पर किया जा सकता है, जैसे कि एक से ज़्यादा चेकआउट. से Basel, डायरेक्ट्री को ट्रैश में नहीं डालता है. हालांकि, हो सकता है कि आपको अपने-आप इस डायरेक्ट्री का समय-समय पर क्लीनअप करने की सुविधा. डिस्क कैश को इस प्रकार सक्षम करें:
build --disk_cache=path/to/build/cache
~
उपनाम का इस्तेमाल करके, --disk_cache
फ़्लैग के लिए एक उपयोगकर्ता पाथ पास किया जा सकता है
(Basel मौजूदा उपयोगकर्ता की होम डायरेक्ट्री का स्थान लेगा). यह काफ़ी काम का है
जब किसी प्रोजेक्ट के सभी डेवलपर के लिए डिस्क कैश को चालू किया जाता है
.bazelrc
फ़ाइल में चेक इन किया गया.
पहले से मालूम समस्याएं
बिल्ड के दौरान फ़ाइल में बदलाव इनपुट करना
बिल्ड के दौरान किसी इनपुट फ़ाइल में बदलाव किए जाने पर, Basel अमान्य अपलोड कर सकता है
से जुड़े नतीजे रिमोट कैश मेमोरी में सेव हो जाते हैं. बदलाव का पता लगाने की सुविधा को इनके साथ चालू किया जा सकता है
--experimental_guard_against_concurrent_changes
फ़्लैग. यह लीजिए
हैं और यह सुविधा आने वाली रिलीज़ में डिफ़ॉल्ट रूप से चालू हो जाएगी.
अपडेट के लिए [समस्या #3360] देखें. आम तौर पर,
बिल्ड.
एनवायरमेंट वैरिएबल का किसी कार्रवाई में लीक होना
किसी कार्रवाई की परिभाषा में, एनवायरमेंट वैरिएबल शामिल होते हैं. यह समस्या हो सकती है:
मशीन के बीच रिमोट कैश हिट शेयर करना. उदाहरण के लिए, ऐसे एनवायरमेंट जिनमें
अलग-अलग $PATH
वैरिएबल, कैश मेमोरी हिट को शेयर नहीं करेंगे. सिर्फ़ एनवायरमेंट वैरिएबल
--action_env
के ज़रिए साफ़ तौर पर अनुमति वाली सूची में शामिल हैं
परिभाषा शामिल नहीं है. /etc/bazel.bazelrc
को इंस्टॉल करने के लिए, Bagel के Debian/Ubuntu पैकेज का इस्तेमाल किया गया
एनवायरमेंट वैरिएबल की वाइटलिस्ट के साथ जिसमें $PATH
शामिल हैं. अगर आपको
कैश मेमोरी हिट उम्मीद से कम हैं. जांच लें कि आपके एनवायरमेंट में कोई पुराना वर्शन तो नहीं है
/etc/bazel.bazelrc
फ़ाइल.
Baज़ल, फ़ाइल फ़ोल्डर के बाहर टूल को ट्रैक नहीं करता
फ़िलहाल, Basel एक वर्कस्पेस के बाहर टूल को ट्रैक नहीं करता है. यह काम किया जा सकता है:
उदाहरण के लिए, अगर कोई कार्रवाई /usr/bin/
के कंपाइलर का इस्तेमाल करती है, तो यह समस्या होती है. इसके बाद,
अलग-अलग कंपाइलर इंस्टॉल किए हुए दो उपयोगकर्ता गलत तरीके से कैश हिट शेयर करेंगे
क्योंकि आउटपुट अलग-अलग हैं, लेकिन उनका ऐक्शन हैश एक ही है. यहां जाएं:
समस्या #4558 अपडेट करें.
डॉकर कंटेनर के अंदर बिल्ड चलाने पर, मेमोरी में मौजूद इंक्रीमेंटल स्थिति हट जाती है एकल डॉकर कंटेनर में चलते समय भी Basel, सर्वर/क्लाइंट आर्किटेक्चर का इस्तेमाल करता है. सर्वर साइड पर, Basel की मेमोरी में स्थिति बनी रहती है. इससे बिल्ड की स्पीड बढ़ती है. जब रनिंग, सीआई जैसे डॉकर कंटेनर के अंदर बनाई जाती है, तब मेमोरी की इन-मेमोरी स्थिति मिट जाती है और रिमोट कैश का इस्तेमाल करने से पहले Basel को इसे फिर से बनाना होगा.
बाहरी लिंक
Your Build in a Datacenter: Basel टीम ने FOSDEM 2018 में, रिमोट कैशिंग और एक्ज़ीक्यूशन के बारे में बातचीत की.
रिमोट कैश मेमोरी की मदद से, तेज़ रफ़्तार से काम करने वाली बेज़ल फ़ाइलें: एक बेंचमार्क:निकोलो वलीगी ने एक ब्लॉग पोस्ट लिखा जिसमें वे बेज़ल में रिमोट कैशिंग के लिए मानदंड बनाते हैं.