रिमोट कैशिंग

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

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

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

खास जानकारी

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

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

रिमोट कैश मेमोरी में सेव करने की सुविधा इस्तेमाल करने के लिए:

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

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

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

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

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

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

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

अगर आपके पास ऐसा Basel बिल्ड है कि वह रिमोट कैश मेमोरी में सेव डेटा को पढ़ और उसमें बदलाव कर सकता है, तो बिल्ड इस तरीके का इस्तेमाल करता है:

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

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

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

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

  • नेटवर्किंग की स्पीड. उदाहरण के लिए, अगर आपकी टीम एक ही ऑफ़िस में है, तो हो सकता है कि आप अपना लोकल सर्वर चलाना चाहें.
  • सुरक्षा. रिमोट कैश में आपकी बाइनरी होंगी, इसलिए यह सुरक्षित होना चाहिए.
  • मैनेज करने में आसान. उदाहरण के लिए, 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;
}

बेज़ल-रिमोट

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

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

GitHub इस्तेमाल करने के निर्देशों के लिए, यह पेज देखें.

Google Cloud Storage

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

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

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

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

  3. एक सीक्रेट JSON कुंजी जनरेट करें और उसे पुष्टि के लिए Basel को दें. कुंजी को सुरक्षित तरीके से सेव करें, क्योंकि जिस व्यक्ति के पास कुंजी है वह आपके GCS (जीसीएस) बकेट से लिए आर्बिट्रेरी डेटा पढ़ और लिख सकता है.

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

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

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

अन्य सर्वर

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

पुष्टि करना

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

एचटीटीपी कैश मेमोरी का प्रोटोकॉल

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

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

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

सीएएस में, SHA256 हैश 15e2b0d3... के साथ आउटपुट फ़ाइल अपलोड करने का Baज़र अनुरोध कुछ इस तरह दिखेगा:

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

0x310x320x330x340x350x360x370x380x39

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

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

आपको कॉन्फ़िगर ऑथेंटिकेशन की भी ज़रूरत पड़ सकती है, जो आपके चुने हुए सर्वर के लिए खास होता है.

हो सकता है कि आप इन फ़्लैग को किसी .bazelrc फ़ाइल में जोड़ना चाहें, ताकि हर बार Basel को चलाते समय आपको इन्हें तय करने की ज़रूरत न पड़े. अपने प्रोजेक्ट और टीम डाइनैमिक के आधार पर, किसी .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 फ़्लैग जैसा होता है. Unix डोमेन सॉकेट को कॉन्फ़िगर करने के लिए, इनका इस्तेमाल करें:

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

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

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

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

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

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

पहले से मालूम समस्याएं

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

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

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

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

Baज़ल, फ़ाइल फ़ोल्डर के बाहर टूल को ट्रैक नहीं करता

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

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