यह पेज, उन Bazel उपयोगकर्ताओं के लिए है जो कस्टम बिल्ड और टेस्ट नियम लिखते हैं और जिन्हें रिमोट तौर पर प्रोग्राम चलाने के संदर्भ में, Bazel नियमों की ज़रूरी शर्तों को समझना है.
रिमोट तरीके से प्रोग्राम चलाने की सुविधा की मदद से, Bazel किसी दूसरे प्लैटफ़ॉर्म पर कार्रवाइयां कर सकता है. जैसे, डेटासेंटर. Bazel, रिमोट तरीके से प्रोग्राम चलाने के लिए gRPC प्रोटोकॉल का इस्तेमाल करता है. bazel-buildfarm की मदद से, रिमोट तौर पर प्रोग्राम चलाने की कोशिश की जा सकती है. यह एक ओपन सोर्स प्रोजेक्ट है, जिसका मकसद डिस्ट्रिब्यूटेड रिमोट तौर पर प्रोग्राम चलाने का प्लैटफ़ॉर्म उपलब्ध कराना है.
इस पेज पर, अलग-अलग तरह के एनवायरमेंट या प्लैटफ़ॉर्म के बारे में बताते समय, इन शब्दों का इस्तेमाल किया जाता है:
- होस्ट प्लैटफ़ॉर्म - जहां Bazel काम करता है.
- कार्रवाई करने वाला प्लैटफ़ॉर्म - जहां Bazel ऐक्शन चलते हैं.
- टारगेट प्लैटफ़ॉर्म - जहां बिल्ड आउटपुट (और कुछ कार्रवाइयां) चलती हैं.
खास जानकारी
रिमोट तरीके से चलाने के लिए Bazel बिल्ड को कॉन्फ़िगर करते समय, आपको इस पेज पर बताए गए दिशा-निर्देशों का पालन करना होगा. इससे यह पक्का किया जा सकेगा कि बिल्ड, रिमोट तरीके से बिना किसी गड़बड़ी के चलेगा. ऐसा, रिमोट तरीके से प्रोसेस करने की सुविधा की वजह से होता है. जैसे:
अलग-अलग बिल्ड ऐक्शन. बिल्ड टूल, स्टेट को सेव नहीं करते और डिपेंडेंसी के बीच कोई डेटा लीक नहीं हो सकता.
अलग-अलग तरह के एक्ज़ीक्यूशन एनवायरमेंट. लोकल बिल्ड कॉन्फ़िगरेशन, हमेशा रिमोट एक्ज़ीक्यूशन एनवायरमेंट के लिए सही नहीं होता.
इस पेज पर, रिमोट तरीके से प्रोग्राम चलाने के लिए, कस्टम Bazel बिल्ड और टेस्ट नियम लागू करने पर होने वाली समस्याओं और उनसे बचने के तरीके के बारे में बताया गया है. इसमें ये विषय शामिल हैं:
- टूलचेन के नियमों की मदद से, बिल्ड टूल को शुरू करना
- अहम डिपेंडेंसी मैनेज करना
- प्लैटफ़ॉर्म पर निर्भर बाइनरी मैनेज करना
- कॉन्फ़िगर-स्टाइल WORKSPACE के नियमों को मैनेज करना
टूलचेन के नियमों की मदद से, बिल्ड टूल को शुरू करना
Bazel टूलचेन का नियम, कॉन्फ़िगरेशन देने वाला एक टूल है. यह बिल्ड नियम को बताता है कि कंपाइलर और लिंकर जैसे कौनसे बिल्ड टूल इस्तेमाल करने हैं और नियम बनाने वाले के तय किए गए पैरामीटर का इस्तेमाल करके, उन्हें कैसे कॉन्फ़िगर करना है. टूलचेन नियम की मदद से, बिल्ड और टेस्ट नियमों को बिल्ड टूल को पहले से कॉन्फ़िगर किए गए तरीके से, अनुमानित तरीके से इस्तेमाल करने की अनुमति मिलती है. यह तरीका, रिमोट से प्रोग्राम चलाने के साथ काम करता है. उदाहरण के लिए, PATH, JAVA_HOME या अन्य स्थानीय वैरिएबल के ज़रिए बिल्ड टूल को शुरू करने के बजाय, टूलचेन नियम का इस्तेमाल करें. ऐसा इसलिए, क्योंकि हो सकता है कि ये वैरिएबल, रिमोट रनिंग एनवायरमेंट में एक जैसी वैल्यू पर सेट न हों या बिलकुल भी सेट न हों.
फ़िलहाल, टूलचेन के नियम, Scala, Rust, और Go के लिए, Bazel के बिल्ड और टेस्ट के नियमों के लिए मौजूद हैं. साथ ही, bash जैसी अन्य भाषाओं और टूल के लिए, टूलचेन के नए नियम तैयार किए जा रहे हैं. अगर आपके नियम में इस्तेमाल किए गए टूल के लिए, टूलचेन का कोई नियम मौजूद नहीं है, तो टूलचेन का नियम बनाएं.
इंप्लिसिट डिपेंडेंसी मैनेज करना
अगर कोई बिल्ड टूल, सभी बिल्ड ऐक्शन में डिपेंडेंसी ऐक्सेस कर सकता है, तो उन ऐक्शन को रिमोट तौर पर लागू करने पर वे काम नहीं करेंगे. इसकी वजह यह है कि हर रिमोट बिल्ड ऐक्शन, दूसरों से अलग से लागू किया जाता है. कुछ बिल्ड टूल, बिल्ड ऐक्शन के दौरान स्टेटस को बनाए रखते हैं और उन डिपेंडेंसी को ऐक्सेस करते हैं जिन्हें टूल को शुरू करने के दौरान साफ़ तौर पर शामिल नहीं किया गया है. इस वजह से, रिमोट से चलाए गए बिल्ड ऐक्शन पूरा नहीं हो पाएंगे.
उदाहरण के लिए, जब Bazel किसी स्टेटफ़ुल कंपाइलर को foo को लोकल तौर पर बनाने का निर्देश देता है, तो कंपाइलर, foo के बिल्ड आउटपुट के रेफ़रंस को सेव रखता है. जब Bazel, foo पर निर्भर bar को बनाने के लिए कंपाइलर को निर्देश देता है, तो वह कार्रवाई तब तक पूरी हो जाती है, जब तक दोनों कार्रवाइयों के लिए एक ही कंपाइलर इंस्टेंस काम करता है. ऐसा स्थानीय तौर पर प्रोग्राम चलाने के दौरान होता है. हालांकि, रिमोट तौर पर प्रोग्राम चलाने की स्थिति में, हर बिल्ड ऐक्शन एक अलग कंपाइलर इंस्टेंस को चलाता है. इसलिए, कंपाइलर की स्थिति और bar की foo पर मौजूद डिपेंडेंसी हट जाएगी और बिल्ड पूरा नहीं हो पाएगा.
डिपेंडेंसी से जुड़ी इन समस्याओं का पता लगाने और उन्हें ठीक करने में मदद करने के लिए, Bazel 0.14.1 में लोकल Docker सैंडबॉक्स की सुविधा उपलब्ध है. इसमें डिपेंडेंसी के लिए वही पाबंदियां हैं जो रिमोट तौर पर प्रोग्राम चलाने के लिए होती हैं. रिमोट तौर पर चलाए जाने के लिए, अपने बिल्ड को तैयार करने के लिए सैंडबॉक्स का इस्तेमाल करें. इसके लिए, डिपेंडेंसी से जुड़ी बिल्ड गड़बड़ियों का पता लगाएं और उन्हें ठीक करें. ज़्यादा जानकारी के लिए, Docker सैंडबॉक्स की मदद से, Bazel के रिमोट तरीके से प्रोग्राम चलाने से जुड़ी समस्या हल करना देखें.
प्लैटफ़ॉर्म पर निर्भर बाइनरी मैनेज करना
आम तौर पर, होस्ट प्लैटफ़ॉर्म पर बनाई गई बाइनरी को किसी भी रिमोट प्लैटफ़ॉर्म पर सुरक्षित तरीके से एक्ज़ीक्यूट नहीं किया जा सकता. इसकी वजह यह है कि होस्ट प्लैटफ़ॉर्म और रिमोट प्लैटफ़ॉर्म पर, डिपेंडेंसी मेल नहीं खाती हैं. उदाहरण के लिए, Bazel के साथ दिया गया SingleJar बाइनरी, होस्ट प्लैटफ़ॉर्म को टारगेट करता है. हालांकि, किसी प्रोग्राम को किसी दूसरी जगह पर चलाने के लिए, कोड बनाने की प्रोसेस के तहत SingleJar को भी कंपाइल करना होगा, ताकि वह किसी दूसरी जगह पर चलाने के लिए उपलब्ध प्लैटफ़ॉर्म को टारगेट कर सके. (टारगेट चुनने का लॉजिक देखें.)
अपने सोर्स कोड के साथ, बिल्ड टूल की बाइनरी को तब तक शिप न करें, जब तक आपको यह पक्का न हो जाए कि वे आपके एक्सीक्यूशन प्लैटफ़ॉर्म पर सुरक्षित तरीके से काम करेंगी. इसके बजाय, इनमें से कोई एक काम करें:
टूल के सोर्स कोड को शिप करें या बाहरी तौर पर रेफ़रंस दें, ताकि उसे रिमोट तौर पर चलाने वाले प्लैटफ़ॉर्म के लिए बनाया जा सके.
अगर टूल पूरी तरह से काम कर रहा है, तो उसे रिमोट इक्विज़िक्यूशन एनवायरमेंट (उदाहरण के लिए, टूलचेन कंटेनर) में पहले से इंस्टॉल करें. साथ ही, अपने बिल्ड में इसे चलाने के लिए, टूलचेन के नियमों का इस्तेमाल करें.
कॉन्फ़िगर-स्टाइल WORKSPACE नियमों को मैनेज करना
Bazel के WORKSPACE नियमों का इस्तेमाल, होस्ट प्लैटफ़ॉर्म पर उन टूल और लाइब्रेरी के लिए जांच करने के लिए किया जा सकता है जो बिल्ड के लिए ज़रूरी हैं. लोकल बिल्ड के लिए, यह Bazel का एक्ज़ीक्यूशन प्लैटफ़ॉर्म भी है. अगर बिल्ड, लोकल बिल्ड टूल और आर्टफ़ैक्ट पर पूरी तरह से निर्भर करता है, तो रिमोट तरीके से बिल्ड करने के दौरान यह काम नहीं करेगा. ऐसा तब होगा, जब रिमोट तरीके से बिल्ड करने का प्लैटफ़ॉर्म, होस्ट प्लैटफ़ॉर्म से मेल न खाता हो.
WORKSPACE नियमों से की गई ये कार्रवाइयां, रिमोट तौर पर लागू करने की सुविधा के साथ काम नहीं करतीं:
बाइनरी बनाना.
WORKSPACEनियमों में कंपाइलेशन ऐक्शन को लागू करने पर, ऐसी बाइनरी बनती हैं जो होस्ट प्लैटफ़ॉर्म से अलग होने पर, रिमोट एक्सीक्यूशन प्लैटफ़ॉर्म के साथ काम नहीं करती हैं.pipपैकेज इंस्टॉल किए जा रहे हैं.WORKSPACEके नियमों के ज़रिए इंस्टॉल किए गएpipपैकेज के लिए, यह ज़रूरी है कि उनकी डिपेंडेंसी, होस्ट प्लैटफ़ॉर्म पर पहले से इंस्टॉल हों. खास तौर पर होस्ट प्लैटफ़ॉर्म के लिए बनाए गए ऐसे पैकेज, रिमोट तौर पर प्रोग्राम चलाने वाले प्लैटफ़ॉर्म के साथ काम नहीं करेंगे. ऐसा तब होगा, जब होस्ट प्लैटफ़ॉर्म और रिमोट तौर पर प्रोग्राम चलाने वाला प्लैटफ़ॉर्म अलग-अलग हों.स्थानीय टूल या आर्टफ़ैक्ट से सिंक करना.
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 के ज़रिए की जाती थी, जैसा कि यहां दिखाया गया है.