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

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

यह पेज Basel के उन उपयोगकर्ताओं के लिए है जो अपनी ज़रूरत के हिसाब से बिल्ड और टेस्ट के नियम लिख रहे हैं. ये उन लोगों के लिए हैं जो रिमोट तौर पर एक्ज़ीक्यूट करने के लिए, Basel के नियमों की ज़रूरी शर्तों को समझना चाहते हैं.

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

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

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

खास जानकारी

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

  • बिल्ड से जुड़ी अलग-अलग कार्रवाइयां. बिल्ड टूल की स्थिति बरकरार नहीं रहती है और डिपेंडेंसी उनके बीच लीक नहीं हो सकती.

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

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

टूलचेन के नियमों की मदद से, बिल्ड टूल इस्तेमाल करने की शुरुआत करना

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

फ़िलहाल, टूलचेन के नियम, Scala, Rust, और Go के लिए बेज़ल के बिल्ड और टेस्ट के नियमों के लिए मौजूद हैं. बैश जैसे अन्य भाषाओं और टूल के लिए भी टूलचेन के नए नियम लागू होने वाले हैं. अगर आपके नियम में इस्तेमाल होने वाले टूल के लिए कोई टूलचेन नियम मौजूद नहीं है, तो टूलचेन नियम बनाने के बारे में सोचें.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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