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

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

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

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

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

खास जानकारी

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

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

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

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

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

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

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

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

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

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