अपग्रेड नीति
स्थिरता एक उत्पाद सिद्धांत है, किसी बाद की सोच नहीं। AiHummer इसका पालन करता है सैमवर, लागू होता है फ़ॉरवर्ड-सुरक्षित डेटाबेस माइग्रेशन स्वचालित रूप सेऔर कर सकते हैं स्वयं-अपडेट एक CDN से — इसलिए उन्नयन नियमित होते हैं न कि जोखिम भरे।
संस्करण प्रबंधन (सेमवर)
रिलीज़ सेमान्टिक वर्ज़निंग का पालन करती हैं। संस्करण की रिपोर्ट द्वारा की जाती है /healthz और द्वारा aihummer version, ताकि आप हमेशा अपग्रेड से पहले और बाद में ठीक क्या चल रहा है, इसकी पुष्टि कर सकें।
माइग्रेशन अग्रिम-सुरक्षित और स्वचालित हैं
स्टार्टअप पर गेटवे स्वचालित रूप से लंबित डेटाबेस माइग्रेशन लागू करता है। दो गुण इसे सुरक्षित रखते हैं:
- सामने सुरक्षित। माइग्रेशन इस तरह से लिखे जाते हैं कि नया बाइनरी इसके खिलाफ काम करे स्कीमा में यह माइग्रेट करता है, जो ऑटो-एप्लाई और रोलिंग अपग्रेड्स को सुरक्षित बनाता है।
- सलाहकारी लॉक के माध्यम से एकल-आवेदक। माइग्रेशन एक के तहत चलते हैं पोस्टग्रेसक्यूएल सलाहकार लॉक, इसलिए जब कई गेटवे एक साथ शुरू होते हैं तो केवल एक ही उन्हें लागू करता है और बाकी इंतजार करते हैं — कभी भी दोहरी प्रवास नहीं।
[!NOTE] माइग्रेशन हमेशा मालिक डेटाबेस पूल पर चलते हैं। प्रतिबंधित RLS भूमिका (
AIHUMMER_DB_APP_URL) ट्रैफ़िक देने के लिए है, स्कीमा परिवर्तनों के लिए नहीं।
अपडेट
नए संस्करण विक्रेता के रिलीज़ CDN से लिए जाते हैं। अपडेट करने का समर्थित तरीका सर्वर पर चलने वाला एक ही आदेश है:
aihummer update --check # report whether a newer version is available
aihummer update # download and apply the update--check कुछ भी नहीं लिखता, इसलिए उसे root की ज़रूरत नहीं। अपडेट लागू करना स्थापना मूल को दोबारा लिखता है और सेवा पुनः आरंभ करता है, इसलिए उसे sudo के साथ चलाइए।
अपेक्षित परिणाम: --check मौजूदा और उपलब्ध संस्करण छापकर, बिना कुछ बदले समाप्त हो जाता है। aihummer update आर्टिफैक्ट उतारता है, उसका sha256 चेकसम और cosign हस्ताक्षर जाँचता है, बाइनरी बदलता है और सेवा पुनः आरंभ करता है; इसके बाद aihummer version नया संस्करण दिखाता है। जाँच न मिलने पर अपडेट फ़ाइल बदलने से पहले ही रुक जाता है: चल रहा संस्करण अछूता रहता है।
[!NOTE] स्वचालित अपडेट विक्रेता चालू करता है, आप नहीं। स्वतः-अपडेट का ढंग और समय-सारणी रिलीज़ के रखरखाव का हिस्सा हैं और विक्रेता के हस्ताक्षरित निर्देश से तय होती हैं। इसके लिए न वेब इंटरफ़ेस में स्विच हैं और न
aihummer settingsमें; औरgateway.envमें लिखे स्वतः-अपडेट वाले चर गेटवे पढ़ता ही नहीं — यदि वे आपको वहाँ दिखें, तो उनका कोई असर नहीं होता। अपनी सुविधा के अनुसार अपडेट करने के लिए ऊपर दियाaihummer updateआदेश इस्तेमाल कीजिए।
रोलबैक
एक-एक करके, वापस क्या लौटाया जा सकता है:
- बाइनरी — पिछले संस्करण पर लौटाई जा सकती है (पुराने रिलीज़ के आर्टिफैक्ट CDN पर बने रहते हैं; जो संस्करण चाहिए उसे दोबारा स्थापित कीजिए)।
- डेटाबेस स्कीमा — माइग्रेशन अग्रिम-सुरक्षित हैं, इसलिए पिछली बाइनरी नई स्कीमा के साथ भी चलती है; स्कीमा का अलग रोलबैक होता ही नहीं।
- प्लगइन — संस्करण हर स्थापना के हिसाब से सँभाले जाते हैं; ज़रूरत पड़ने पर कैटलॉग से किसी प्लगइन को पिछले संस्करण पर लौटाइए।
- कॉन्फ़िगरेशन — अपडेट इसे छूता नहीं; ज़रूरत हो तो बैकअप से बहाल कीजिए।
शून्य-डाउनटाइम रोलआउट
AiHummer को बिना किसी अवरोध के अपग्रेड करने के लिए बनाया गया है:
- 2+ गेटवे को प्रॉक्सी के पीछे चलाएँ। इन्हें एक-एक करके घुमाएँ; तैयारी जांच
(
/readyz) एक नोड को रोटेशन से बाहर रखता है जब तक कि वह सेवा नहीं दे रहा होता। - अनुसूचक एकल-नेता है। पृष्ठभूमि शेड्यूलिंग एक एकल नेता चुनती है पोस्टग्रेसक्यूएल सलाहकारी लॉक के माध्यम से, ताकि कई गेटवे चलाने पर डुप्लीकेट न हो निर्धारित कार्य।
- डिलीवरी आइडेम्पोटेंट है। विश्वसनीय डिलीवरी प्लस आइडेम्पोटेंसी कुंजियाँ का मतलब है एक उत्तर कभी भी पुनः प्रारंभ के दौरान दो बार नहीं भेजा जाता, यही एक रोलिंग बनाता है सुरक्षित रूप से अपने गेटवे पर पुनः प्रारंभ करें।
अगला कहाँ
- जाँच उपकरण जो एक क्रमिक पुनःप्रारंभ को नियंत्रित करते हैं: systemd और स्वास्थ्य जांच.
- मुख्य अपडेट से पहले बैक अप लें: बैकअप और आपदा पुनर्प्राप्ति.
- रोलआउट देखें: निरीक्षण योग्यता.