रिमोट कैशिंग

समस्या की शिकायत करें सोर्स देखें

इस पेज में, रिमोट कैशिंग और कैश मेमोरी को होस्ट करने के लिए सर्वर सेट अप करने की जानकारी शामिल होती है. साथ ही, इस पेज में रिमोट कैश का इस्तेमाल करके बिल्ड करने की सुविधा भी होती है.

बिल्ड आउटपुट शेयर करने के लिए, रिमोट कैश का इस्तेमाल डेवलपर की टीम और/या एक लगातार इंटिग्रेशन (सीआई) सिस्टम करता है. अगर आपका बिल्ड फिर से बनाया जा सकता है, तो एक मशीन से आउटपुट सुरक्षित रूप से किसी दूसरी मशीन पर फिर से इस्तेमाल किए जा सकते हैं. इससे बिल्डिंग काफ़ी तेज़ी से हो सकती है.

खास जानकारी

बैज़ल, एक बिल्ड को अलग-अलग कदमों से तोड़ता है, जिन्हें ऐक्शन कहा जाता है. हर कार्रवाई में इनपुट, आउटपुट नाम, कमांड लाइन, और एनवायरमेंट वैरिएबल होते हैं. हर कार्रवाई के लिए, ज़रूरी इनपुट और अनुमानित आउटपुट का एलान अलग से किया जाता है.

आप बिल्ड आउटपुट के लिए किसी रिमोट कैश सर्वर के रूप में सर्वर सेट अप कर सकते हैं. इसमें, आउटपुट फ़ाइल के नामों और उनके कॉन्टेंट के हैश की एक सूची दी जाती है. रिमोट कैश के साथ, आप हर नए आउटपुट को स्थानीय रूप से बनाने के बजाय किसी दूसरे उपयोगकर्ता के बिल्ड के आउटपुट का फिर से इस्तेमाल कर सकते हैं.

रिमोट कैशिंग का इस्तेमाल करने के लिए:

  • कैश मेमोरी के बैकएंड के तौर पर सर्वर सेट अप करना
  • रिमोट कैश मेमोरी का इस्तेमाल करने के लिए, Bazel बिल्ड को कॉन्फ़िगर करें
  • Bazel का 0.10.0 या इसके बाद का वर्शन इस्तेमाल करना

कैश मेमोरी में सेव किए गए डेटा दो तरह के होते हैं:

  • ऐक्शन कैश, जो ऐक्शन हैश से जुड़ा ऐक्शन मैप का मैप है.
  • आउटपुट फ़ाइलों का, कॉन्टेंट का पता लगाने वाला स्टोर (सीएएस).

ध्यान दें कि रिमोट कैश स्टोरेज में, हर कार्रवाई के लिए stdout और stderr को सेव किया जाता है. बाज़ल के stdout/stderr की जांच करने के लिए, कैश हिट का अनुमान लगाना होना सही नहीं है.

बिल्ड रिमोट कैशिंग का इस्तेमाल कैसे करता है

रिमोट कैश के तौर पर सर्वर सेट अप हो जाने के बाद, कैश मेमोरी का इस्तेमाल कई तरीकों से किया जा सकता है:

  • रिमोट कैश में पढ़ें और लिखें
  • खास टारगेट को छोड़कर, किसी दूसरी जगह की कैश मेमोरी में सेव किए गए डेटा को पढ़ना और/या उसमें बदलाव करना
  • सिर्फ़ रिमोट कैश की मदद से पढ़ा गया
  • रिमोट कैश को कभी भी इस्तेमाल न करें

जब आप Bazel बिल्ड को चलाते हैं, जो रिमोट कैश को पढ़ सकता है और लिख सकता है, तो बिल्ड इन चरणों का पालन करता है:

  1. Bazel, उन टारगेट का ग्राफ़ बनाता है जिन्हें बनाने की ज़रूरत होती है. इसके बाद, यह ज़रूरी कार्रवाइयों की सूची बनाता है. इनमें से हर एक कार्रवाई के लिए इनपुट और आउटपुट फ़ाइल नामों का इस्तेमाल किया जाता है.
  2. Bazel, मौजूदा बिल्ड आउटपुट की जांच करने के लिए, आपकी लोकल मशीन की जांच करता है. साथ ही, उसे मिलने वाली बैटरी का भी फिर से इस्तेमाल करता है.
  3. Bazel, मौजूदा बिल्ड आउटपुट के लिए कैश मेमोरी की जांच करता है. अगर आउटपुट मिलता है, तो बाज़ल आउटपुट को पा लेता है. यह एक कैश हिट है.
  4. ज़रूरी कार्रवाइयां, जहां आउटपुट नहीं मिलते थे, उनके लिए बैज़ल स्थानीय तौर पर कार्रवाइयां करता है. साथ ही, ज़रूरी बिल्ड आउटपुट बनाता है.
  5. नए बिल्ड आउटपुट, रिमोट कैश मेमोरी पर अपलोड होते हैं.

सर्वर को कैश मेमोरी के बैकएंड के तौर पर सेट करना

कैश के बैकएंड के तौर पर काम करने के लिए, आपको एक सर्वर सेट अप करना होगा. एचटीटीपी/1.1 सर्वर से Bazel के डेटा को अपारदर्शिता बाइट माना जा सकता है. इसलिए, कई मौजूदा सर्वर, रिमोट कैशिंग बैकएंड के तौर पर इस्तेमाल किए जा सकते हैं. Bazel का एचटीटीपी कैशिंग प्रोटोकॉल रिमोट कैशिंग के लिए काम करता है.

आप बैकएंड सर्वर को चुनने, सेट करने और उसे बनाए रखने के लिए ज़िम्मेदार हैं जो कैश किए गए आउटपुट संग्रहित करेगा. सर्वर चुनते समय, इन बातों का ध्यान रखें:

  • नेटवर्क की स्पीड. उदाहरण के लिए, अगर आपकी टीम उसी ऑफ़िस में है, तो आप अपना स्थानीय सर्वर चलाना चाहेंगे.
  • सुरक्षा. रिमोट कैश मेमोरी में आपकी बाइनरी फ़ाइलें होंगी और इसलिए उन्हें सुरक्षित रखना होगा.
  • आसान मैनेजमेंट. उदाहरण के लिए, Google Cloud Storage पूरी तरह से मैनेज की जाने वाली सेवा है.

रिमोट बैकएंड के लिए कई बैकएंड इस्तेमाल किए जा सकते हैं. कुछ विकल्पों में ये शामिल हैं:

nginx

nginx एक ओपन सोर्स वेब सर्वर है. इसके [WebDAV मॉड्यूल] से, इसे Bazel के रिमोट कैश के तौर पर इस्तेमाल किया जा सकता है. 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;
}

बाज़ल-रिमोट

bazel-remote एक ऐसा ओपन सोर्स रिमोट बिल्ड कैश है जिसका इस्तेमाल आप अपने इन्फ़्रास्ट्रक्चर के लिए कर सकते हैं. साल 2018 की शुरुआत से ही कई कंपनियों में इसका इस्तेमाल हो रहा है. ध्यान दें कि Bazen प्रोजेक्ट, बेज़ल-रिमोट के लिए तकनीकी सहायता नहीं देता है.

इस कैश में, कॉन्टेंट को डिस्क में स्टोर किया जाता है. साथ ही, कचरा इकट्ठा करने से कामों में इस्तेमाल होने वाली ऊपरी सीमा को लागू किया जाता है. साथ ही, इस्तेमाल नहीं किए गए आर्टफ़ैक्ट को हटाया जाता है. कैश मेमोरी [डॉकर इमेज] के तौर पर उपलब्ध होती है और इसका कोड GitHub पर उपलब्ध है. REST और gRPC रिमोट कैश एपीआई, दोनों ही काम करते हैं.

इसे इस्तेमाल करने का तरीका जानने के लिए, GitHub पेज पर जाएं.

Google Cloud Storage

[Google Cloud Storage] पूरी तरह से मैनेज किया गया ऑब्जेक्ट स्टोर है. यह एक ऐसा एचटीटीपी एपीआई उपलब्ध कराता है जो Bazel के रिमोट कैशिंग प्रोटोकॉल के साथ काम करता है. इसके लिए ज़रूरी है कि आपके पास ऐसा Google Cloud खाता हो जिसमें बिलिंग की सुविधा चालू हो.

Cloud Storage को कैश मेमोरी के तौर पर इस्तेमाल करने के लिए:

  1. स्टोरेज बकेट बनाएं. पक्का करें कि आपने सबसे नज़दीक की बकेट चुनी हो, क्योंकि रिमोट कैश के लिए नेटवर्क बैंडविड्थ अहम है.

  2. Cloud Storage पर पुष्टि करने के लिए, Bazel से जुड़ा सेवा खाता बनाएं. सेवा खाता बनाना देखें.

  3. एक गुप्त JSON कुंजी जनरेट करें और उसे पुष्टि के लिए Bazel पर पास करें. कुंजी को सुरक्षित तरीके से सेव करें, क्योंकि कोई भी व्यक्ति जिसके पास कुंजी हो वह आपकी GCS (जीसीएस) बकेट में/से डेटा लिख सकता है और लिख सकता है.

  4. अपने Bazel कमांड में ये फ़्लैग जोड़कर Cloud Storage से कनेक्ट करें:

    • नीचे दिए गए यूआरएल को Bazel से चुनकर फ़्लैग का इस्तेमाल करें: --remote_cache=https://storage.googleapis.com/bucket-name जहां bucket-name आपके स्टोरेज बकेट का नाम है.
    • ऐप्लिकेशन की पुष्टि करने की सुविधा का इस्तेमाल करने के लिए, फ़्लैग: --google_credentials=/path/to/your/secret-key.json या --google_default_credentials का इस्तेमाल करके, पुष्टि करने वाली कुंजी पास करें.

  5. पुरानी फ़ाइलों को अपने-आप मिटाने के लिए, Cloud Storage को कॉन्फ़िगर किया जा सकता है. ऐसा करने के लिए, ऑब्जेक्ट की लाइफ़साइकल मैनेज करना देखें.

अन्य सर्वर

आप PUT के साथ काम करने वाले किसी भी एचटीटीपी/1.1 सर्वर को सेट अप कर सकते हैं. साथ ही, कैश मेमोरी के बैकएंड के तौर पर GET का इस्तेमाल कर सकते हैं. उपयोगकर्ताओं ने, Hazelcast, Apache httpd, और AWS S3, जैसे कैश मेमोरी वाले बैकएंड के बारे में बताया है.

पुष्टि करना

Bazel में एचटीटीपी बेसिक ऑथेंटिकेशन के लिए, 0.11.0 वर्शन जोड़ा गया. रिमोट कैश यूआरएल के ज़रिए, आपको Bazel पर उपयोगकर्ता नाम और पासवर्ड भेजा जा सकता है. https://username:password@hostname.com:port/path का टैक्स है. ध्यान दें कि एचटीटीपी बेसिक ऑथेंटिकेशन, नेटवर्क पर उपयोगकर्ता नाम और पासवर्ड को सादे टेक्स्ट में भेजता है. इसलिए, एचटीटीपीएस के साथ हमेशा इसका इस्तेमाल करना ज़रूरी है.

एचटीटीपी कैशिंग प्रोटोकॉल

Bazel, एचटीटीपी/1.1 के ज़रिए रिमोट कैश मेमोरी में सेव करने की सुविधा देता है. सैद्धांतिक रूप से प्रोटोकॉल आसान है: बाइनरी डेटा (BLOB) को PUT अनुरोधों के ज़रिए अपलोड किया जाता है. इसके अलावा, इसे GET अनुरोधों के ज़रिए डाउनलोड भी किया जाता है. कार्रवाई के नतीजे का मेटाडेटा, /ac/ पाथ में सेव किया गया है. आउटपुट फ़ाइलें, पाथ /cas/ में स्टोर की गई हैं.

उदाहरण के लिए, http://localhost:8080/cache से जुड़ी रिमोट कैश मेमोरी का इस्तेमाल करें. SHA256 हैश 01ba4719... वाली कार्रवाई के लिए कार्रवाई नतीजे का मेटाडेटा डाउनलोड करने का बेज़ल अनुरोध इस तरह दिखेगा:

GET /cache/ac/01ba4719c80b6fe911b091a7c05124b64eeece964e09c058ef8f9805daca546b HTTP/1.1
Host: localhost:8080
Accept: */*
Connection: Keep-Alive

15e2b0d3...

PUT /cache/cas/15e2b0d3c33891ebb0f1ef609ec419420c20e320ce94c65fbc8c3312448eb225 HTTP/1.1
Host: localhost:8080
Accept: */*
Content-Length: 9
Connection: Keep-Alive

0x310x320x330x340x350x360x370x380x39

रिमोट कैश का इस्तेमाल करके Bazel चलाएं

किसी सर्वर को रिमोट कैश के तौर पर सेट करने के बाद, रिमोट कैश का इस्तेमाल करने के लिए, आपको अपने Bazel कमांड में फ़्लैग जोड़ने होंगे. नीचे कॉन्फ़िगरेशन और उनके फ़्लैग की सूची देखें.

आपको कॉन्फ़िगर करने की पुष्टि भी करनी पड़ सकती है. यह पुष्टि खास तौर पर आपके चुने गए सर्वर के लिए होती है.

हो सकता है कि आप इन फ़्लैग को .bazelrc फ़ाइल में जोड़ना चाहें, ताकि आपको हर बार Bazel चलाते समय उन्हें बताने की ज़रूरत न पड़े. आपके प्रोजेक्ट और टीम डाइनैमिक के आधार पर, फ़्लैग को .bazelrc फ़ाइल में जोड़ा जा सकता है. यह है:

  • आपकी स्थानीय मशीन पर
  • आपके प्रोजेक्ट के फ़ाइल फ़ोल्डर में, टीम के साथ शेयर किया गया है
  • सीआई सिस्टम पर

रिमोट कैश से पढ़ें और लिखें

इस बात का ध्यान रखें कि रिमोट कैश में कौन लिख सकता है. हो सकता है कि आप चाहते हों कि आपका सीआई सिस्टम रिमोट कैश मेमोरी में डेटा लिखे.

रिमोट कैश को पढ़ने और उसमें लिखने के लिए निम्न फ़्लैग का उपयोग करें:

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-socket फ़्लैग जैसा ही होता है. Unix डोमेन सॉकेट कॉन्फ़िगर करने के लिए, इनका इस्तेमाल करें:

   build --remote_cache=http://your.host:port
   build --remote_cache_proxy=unix:/path/to/socket

यह सुविधा Windows पर काम नहीं करती.

डिस्क की कैश मेमोरी

Bazel, रिमोट कैश मेमोरी के तौर पर फ़ाइल सिस्टम की डायरेक्ट्री का इस्तेमाल कर सकता है. इससे ब्रांच स्विच करते समय और/या एक ही प्रोजेक्ट के एक से ज़्यादा फ़ाइल फ़ोल्डर में काम करते समय बिल्ड आर्टफ़ैक्ट शेयर करने में मदद मिलती है. हालांकि, Bazel, डायरेक्ट्री को कूड़े से इकट्ठा नहीं करता, इसलिए हो सकता है कि आप समय-समय पर इस डायरेक्ट्री को अपने-आप साफ़ करना चाहें. डिस्क की कैश मेमोरी को इस तरह चालू करें:

build --disk_cache=path/to/build/cache

~ उपनाम का इस्तेमाल करके, उपयोगकर्ता के खास पाथ को --disk_cache फ़्लैग में पास किया जा सकता है (Bazel, मौजूदा उपयोगकर्ता की होम डायरेक्ट्री को बदल देगा). यह प्रोजेक्ट के सभी डेवलपर के लिए डिस्क कैश को चालू करने पर काम करता है. ऐसा प्रोजेक्ट की .bazelrc फ़ाइल में सही का निशान लगाकर चुना जाता है.

आम तौर पर होने वाली समस्याएं

बिल्ड के दौरान फ़ाइल में बदलाव करना

जब किसी बिल्ड के दौरान इनपुट फ़ाइल में बदलाव किया जाता है, तो Bazel, रिमोट कैश मेमोरी में अमान्य नतीजे अपलोड कर सकता है. --experimental_guard_against_concurrent_changes फ़्लैग की मदद से बदलाव का पता लगाने की सुविधा चालू की जा सकती है. ऐप्लिकेशन की कोई समस्या नहीं है. आने वाले वर्शन में, यह सुविधा डिफ़ॉल्ट रूप से चालू हो जाएगी. अपडेट के लिए, [समस्या #3360] देखें. आम तौर पर, बिल्ड के दौरान सोर्स फ़ाइल में बदलाव करने से बचें.

किसी कार्रवाई में लीक हो रहे एनवायरमेंट वैरिएबल

कार्रवाई की परिभाषा में, एनवायरमेंट वैरिएबल शामिल हैं. इससे सभी मशीनों पर रिमोट कैश हिट शेयर करने में समस्या आ सकती है. उदाहरण के लिए, अलग-अलग $PATH वैरिएबल वाले एनवायरमेंट, कैश हिट नहीं शेयर करेंगे. सिर्फ़ --action_env से साफ़ तौर पर व्हाइटलिस्ट किए गए एनवायरमेंट वैरिएबल, ही ऐक्शन डेफ़िनिशन में शामिल होते हैं. Bazel का Debian/Ubuntu पैकेज, /etc/bazel.bazelrc के साथ $PATH जैसे एनवायरमेंट वैरिएबल की व्हाइटलिस्ट के साथ इंस्टॉल करने के लिए इस्तेमाल किया गया. अगर आपको उम्मीद से कम कैश हिट मिल रही हैं, तो देखें कि आपके एनवायरमेंट में कोई पुरानी /etc/bazel.bazelrc फ़ाइल तो नहीं है.

Bazel, Workspace से बाहर के टूल को ट्रैक नहीं करता

फ़िलहाल, Bazel, फ़ाइल फ़ोल्डर के बाहर मौजूद टूल को ट्रैक नहीं करता. यह समस्या हो सकती है, उदाहरण के लिए, अगर किसी कार्रवाई में /usr/bin/ के कंपाइलर का इस्तेमाल किया जाता है. इसके बाद, अलग-अलग कंपाइलर इंस्टॉल करने वाले दो उपयोगकर्ता, गलत तरीके से कैश हिट शेयर करेंगे, क्योंकि आउटपुट अलग-अलग होते हैं, लेकिन उनका ऐक्शन हैश एक ही होता है. अपडेट के लिए समस्या #4558 देखें.

डॉकर कंटेनर के अंदर बिल्ड चलाते समय, इन-मेमोरी स्थिति का डेटा मिट जाता है एक ही डॉकर कंटेनर में चलने पर भी, सर्वर/क्लाइंट आर्किटेक्चर का इस्तेमाल करता है. सर्वर साइड पर, Bazel एक मेमोरी स्थिति में रहता है, जो बिल्ड की प्रोसेस को तेज़ करता है. जब सीआई जैसे डॉकर कंटेनर में बिल्ड बनाया जाता है, तो इन-मेमोरी स्थिति खत्म हो जाती है और बेज़ल को रिमोट कैश का इस्तेमाल करने से पहले उसे फिर से बनाना होगा.