हर्मिटिटी

किसी समस्या की शिकायत करें सोर्स देखें Nightly · 8.0 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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

खास जानकारी

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

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

हर्मेटिकिटी के दो अहम पहलू हैं:

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

फ़ायदे

हर्मेटिक बिल्ड के मुख्य फ़ायदे ये हैं:

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

गैर-हर्मेटिकिटी की पहचान करना

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

  • .mk फ़ाइलों में मनमुताबिक प्रोसेसिंग
  • ऐसी कार्रवाइयां या टूल जो फ़ाइलें बनाते समय, तय नहीं करते कि उन्हें कब बनाया जाए. आम तौर पर, इनमें बिल्ड आईडी या टाइमस्टैंप शामिल होते हैं
  • सिस्टम बाइनरी, जो अलग-अलग होस्ट पर अलग-अलग होती हैं. जैसे, /usr/bin बाइनरी, सटीक पाथ, और नेटिव C++ नियमों के ऑटोकॉन्फ़िगरेशन के लिए सिस्टम C++ कंपाइलर
  • बिल्ड के दौरान सोर्स ट्री में लिखना. इससे, एक ही सोर्स ट्री का इस्तेमाल किसी दूसरे टारगेट के लिए नहीं किया जा सकता. पहला बिल्ड, सोर्स ट्री में लिखता है और टारगेट A के लिए सोर्स ट्री को ठीक करता है. ऐसा होने पर, टारगेट B बनाने की कोशिश करने पर, हो सकता है कि वह काम न करे.

ऐसे बिल्ड से जुड़ी समस्या हल करना जो पूरी तरह से सुरक्षित नहीं हैं

लोकल एक्सीक्यूशन से शुरू होकर, लोकल कैश मेमोरी में हिट करने वाली समस्याओं से, ऐसी कार्रवाइयों का पता चलता है जो पूरी तरह से सुरक्षित नहीं हैं.

  • यह पक्का करें कि सीक्वेंशियल बिल्ड नल हों: अगर make को चलाने पर बिल्ड पूरा हो जाता है, तो फिर से बिल्ड चलाने पर किसी टारगेट को फिर से बिल्ड नहीं किया जाना चाहिए. अगर बिल्ड के हर चरण को दो बार या अलग-अलग सिस्टम पर चलाया जाता है, तो फ़ाइल के कॉन्टेंट के हैश की तुलना करें और अलग-अलग नतीजे पाएं. ऐसा होने पर, बिल्ड को फिर से नहीं बनाया जा सकता.
  • संभावित क्लाइंट मशीनों से, लोकल कैश मेमोरी में हिट को डीबग करने के लिए ये चरण अपनाएं. इससे, यह पक्का किया जा सकता है कि ऐक्शन में क्लाइंट एनवायरमेंट लीक होने के किसी भी मामले का पता चल जाए.
  • ऐसे Docker कंटेनर में बिल्ड को पूरा करें जिसमें सिर्फ़ चेक आउट किया गया सोर्स ट्री और होस्ट टूल की साफ़ तौर पर दी गई सूची शामिल हो. गड़बड़ी की वजह से बिल्ड न हो पाना और गड़बड़ी के मैसेज, सिस्टम की लागू डिपेंडेंसी को पकड़ लेंगे.
  • रिमोट से प्रोग्राम चलाने के नियमों का इस्तेमाल करके, पूरी सुरक्षा से जुड़ी समस्याओं का पता लगाएं और उन्हें ठीक करें.
  • हर कार्रवाई के लेवल पर, सैंडबॉक्सिंग की सख्त सुविधा चालू करें. ऐसा इसलिए, क्योंकि बिल्ड में की गई कार्रवाइयां स्टेटफ़ुल हो सकती हैं और बिल्ड या आउटपुट पर असर डाल सकती हैं.
  • वर्कस्पेस के नियमों की मदद से, डेवलपर बाहरी वर्कस्पेस में डिपेंडेंसी जोड़ सकते हैं. हालांकि, ये नियम इतने बेहतर हैं कि इनकी मदद से, प्रोसेस में मनमुताबिक प्रोसेसिंग की जा सकती है. Bazel वर्कस्पेस के नियमों में, ऐसी कुछ कार्रवाइयों का लॉग पाया जा सकता है जो शायद पूरी तरह से सुरक्षित न हों. इसके लिए, अपने Bazel कमांड में --experimental_workspace_rules_log_file=PATH फ़्लैग जोड़ें.

Bazel के साथ हर्मेटिकिटी

Bazel के साथ हेर्मेटिक बाइल्ड का इस्तेमाल करके, अन्य प्रोजेक्ट को कैसे सफलता मिली, इस बारे में ज़्यादा जानने के लिए, BazelCon के ये टॉक देखें: