रिमोट एक्ज़ीक्यूशन के लिए, Bazel के नियमों को अपनाना

Nightly · 9.1 · 9.0 · 8.7 · 8.6 · 8.5 · 8.4 · 8.3 · 8.2 · 8.1

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

रिमोट एक्ज़ीक्यूशन की मदद से, Bazel किसी दूसरे प्लैटफ़ॉर्म पर कार्रवाइयां कर सकता है. जैसे, डेटा सेंटर. Bazel, रिमोट एक्ज़ीक्यूशन के लिए gRPC प्रोटोकॉल का इस्तेमाल करता है. bazel-buildfarm की मदद से, रिमोट एक्ज़ीक्यूशन आज़माया जा सकता है. यह एक ओपन सोर्स प्रोजेक्ट है, जिसका मकसद डिस्ट्रिब्यूटेड रिमोट एक्ज़ीक्यूशन प्लैटफ़ॉर्म उपलब्ध कराना है.

इस पेज पर, अलग-अलग एनवायरमेंट टाइप या प्लैटफ़ॉर्म के बारे में बताते समय, इन शब्दों का इस्तेमाल किया गया है:

  • होस्ट प्लैटफ़ॉर्म - जहां Bazel चलता है.
  • एक्ज़ीक्यूशन प्लैटफ़ॉर्म - जहां Bazel की कार्रवाइयां चलती हैं.
  • टारगेट प्लैटफ़ॉर्म - जहां बिल्ड आउटपुट (और कुछ कार्रवाइयां) चलती हैं.

खास जानकारी

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

  • आइसोलेटेड बिल्ड ऐक्शन. बिल्ड टूल, स्टेट को बनाए नहीं रखते. साथ ही, उनके बीच डिपेंडेंसी लीक नहीं हो सकती.

  • अलग-अलग एक्ज़ीक्यूशन एनवायरमेंट. लोकल बिल्ड कॉन्फ़िगरेशन, रिमोट एक्ज़ीक्यूशन एनवायरमेंट के लिए हमेशा सही नहीं होता.

इस पेज पर, रिमोट एक्ज़ीक्यूशन के लिए, Bazel के कस्टम बिल्ड और टेस्ट के नियम लागू करते समय आने वाली समस्याओं के बारे में बताया गया है. साथ ही, यह भी बताया गया है कि इन समस्याओं से कैसे बचा जा सकता है. इसमें इन विषयों के बारे में बताया गया है:

टूलचेन के नियमों के ज़रिए, बिल्ड टूल को लागू करना

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

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

इम्प्लिसिट डिपेंडेंसी मैनेज करना

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

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

डिपेंडेंसी से जुड़ी इन समस्याओं का पता लगाने और उन्हें ठीक करने के लिए, Bazel 0.14.1 में लोकल Docker सैंडबॉक्स की सुविधा दी गई है. इसमें, डिपेंडेंसी के लिए वही पाबंदियां लागू होती हैं जो रिमोट एक्ज़ीक्यूशन के लिए होती हैं. सैंडबॉक्स का इस्तेमाल करके, अपने बिल्ड को रिमोट एक्ज़ीक्यूशन के लिए तैयार करें. इसके लिए, डिपेंडेंसी से जुड़ी बिल्ड की गड़बड़ियों की पहचान करें और उन्हें ठीक करें. ज़्यादा जानकारी के लिए, Docker सैंडबॉक्स की मदद से, Bazel के रिमोट एक्ज़ीक्यूशन से जुड़ी समस्याएं हल करना लेख पढ़ें.

प्लैटफ़ॉर्म पर निर्भर बाइनरी मैनेज करना

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

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

  • टूल के लिए सोर्स कोड शिप करें या उसका बाहरी रेफ़रंस दें, ताकि उसे रिमोट एक्ज़ीक्यूशन प्लैटफ़ॉर्म के लिए बनाया जा सके.

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

कॉन्फ़िगर-स्टाइल वाले WORKSPACE के नियम मैनेज करना

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

WORKSPACE के नियमों से की जाने वाली ये कार्रवाइयां, रिमोट एक्ज़ीक्यूशन के साथ काम नहीं करती हैं:

  • बाइनरी बनाना. WORKSPACE के नियमों में कंपाइलेशन की कार्रवाइयां करने से, ऐसी बाइनरी बनती हैं जो रिमोट एक्ज़ीक्यूशन प्लैटफ़ॉर्म के साथ काम नहीं करती हैं. ऐसा तब होता है, जब रिमोट एक्ज़ीक्यूशन प्लैटफ़ॉर्म, होस्ट प्लैटफ़ॉर्म से अलग होता है.

  • पैकेज इंस्टॉल करना.pip pip पैकेज, WORKSPACE नियमों के ज़रिए इंस्टॉल किए गए पैकेज के लिए ज़रूरी है कि उनकी डिपेंडेंसी, होस्ट प्लैटफ़ॉर्म पर पहले से इंस्टॉल हों. ऐसे पैकेज, जो खास तौर पर होस्ट प्लैटफ़ॉर्म के लिए बनाए गए हैं, रिमोट एक्ज़ीक्यूशन प्लैटफ़ॉर्म के साथ काम नहीं करेंगे. ऐसा तब होगा, जब रिमोट एक्ज़ीक्यूशन प्लैटफ़ॉर्म, होस्ट प्लैटफ़ॉर्म से अलग होगा.

  • लोकल टूल या आर्टफ़ैक्ट से सिमलिंक करना. WORKSPACE के नियमों के ज़रिए, होस्ट प्लैटफ़ॉर्म पर इंस्टॉल किए गए टूल या लाइब्रेरी से बनाए गए सिमलिंक की वजह से, रिमोट एक्ज़ीक्यूशन प्लैटफ़ॉर्म पर बिल्ड पूरा नहीं होगा. ऐसा इसलिए, क्योंकि Bazel उन्हें ढूंढ नहीं पाएगा. इसके बजाय, स्टैंडर्ड बिल्ड ऐक्शन का इस्तेमाल करके सिमलिंक बनाएं, ताकि सिमलिंक किए गए टूल और लाइब्रेरी, Bazel के runfiles ट्री से ऐक्सेस किए जा सकें. टारगेट फ़ाइलों को, बाहरी रेपो डायरेक्ट्री के बाहर सिमलिंक करने के लिए, repository_ctx.symlink का इस्तेमाल न करें.

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

Workspace के नियमों के लॉग का इस्तेमाल करके, संभावित नॉन-हर्मेटिक व्यवहार का पता लगाया जा सकता है.

अगर कोई बाहरी डिपेंडेंसी, होस्ट प्लैटफ़ॉर्म पर निर्भर खास कार्रवाइयां करती है, तो आपको उन कार्रवाइयों को WORKSPACE और बिल्ड के नियमों के बीच इस तरह बांटना चाहिए:

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

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

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

उदाहरण के लिए, cuda और python के लिए, Tensorflow के नियमों के लिए, WORKSPACE के नियम, ये BUILD files बनाते हैं. लोकल एक्ज़ीक्यूशन के लिए, होस्ट एनवायरमेंट की जांच करके बनाई गई फ़ाइलों का इस्तेमाल किया जाता है. रिमोट एक्ज़ीक्यूशन के लिए, एनवायरमेंट वैरिएबल पर मौजूद शर्तों वाले स्टेटमेंट की मदद से, नियम उन फ़ाइलों का इस्तेमाल कर सकता है जिनकी जांच रेपो में की गई है.

BUILD फ़ाइलों में genrules का एलान किया जाता है. इन्हें लोकल और रिमोट, दोनों तरीकों से चलाया जा सकता है. साथ ही, ये ज़रूरी प्रोसेसिंग करती हैं. यह प्रोसेसिंग पहले repository_ctx.symlink के ज़रिए की जाती थी, जैसा कि यहां दिखाया गया है.