एनोटेशन सर्वर तैनात करना
एनोटेशन अध्ययन का होस्ट उसकी अवधि, ख़र्च उठाने वाले और आपके सर्वरों के आधार पर चुनें, फिर HTTPS, बैकअप और डेटा वापस पाने के लिए potato deploy इस्तेमाल करें।
किसी असली अध्ययन के एनोटेशन सर्वर को एक सार्वजनिक HTTPS पता चाहिए, ऐसा साइन-इन चाहिए जो केवल आपके एनोटेटरों को अंदर आने दे, ऐसा स्टोरेज चाहिए जो रीस्टार्ट के बाद बचा रहे, और अध्ययन ख़त्म होने पर एनोटेशन वापस पाने का एक तरीका चाहिए। Potato में potato deploy up पायलट में आज़माए गए कॉन्फ़िग से होस्ट और प्रमाणपत्र बनाता है, डिस्क मिटाने वाले होस्ट पर बैकअप सेट करता है, और अगर लिंक वाला कोई भी व्यक्ति साइन इन कर सकता हो तो तैनाती से पहले चेतावनी देता है।
यहाँ एनोटेशन सर्वर का मतलब वह वेब ऐप्लिकेशन है जिसे आपके एनोटेटर ब्राउज़र में खोलते हैं, और जो आपके लैपटॉप के बजाय कहीं और चलता है ताकि अध्ययन के हफ़्तों के दौरान एनोटेटर उस तक पहुँच सकें। पायलट में आज़माए गए टास्क को ऐसे सर्वर पर ले जाने से उसका पता, उसका साइन-इन, उसका डेटा रखने की जगह, और मशीन की देखभाल किसके ज़िम्मे है, ये सब बदल जाते हैं।
अध्ययन सर्वर की चार ज़रूरतें
नीचे दी गई हर ज़रूरत या तो एनोटेटरों की रक्षा करती है या डेटा की:
- एक सार्वजनिक HTTPS पता। एनोटेटर टास्क में पासवर्ड और लेबल टाइप करते हैं, इसलिए कनेक्शन HTTPS से एन्क्रिप्ट होना चाहिए। Let's Encrypt का प्रमाणपत्र मुफ़्त है, और उसके लिए सर्वर का एक सार्वजनिक पता होना चाहिए।
- ऐसा साइन-इन जो केवल आपके एनोटेटरों को अंदर आने दे। सार्वजनिक पता ढूँढा जा सकता है, और खुले पंजीकरण वाला टास्क उसे ढूँढने वाले हर व्यक्ति को स्वीकार कर लेता है। नामित खातों की सूची (पासवर्ड प्रबंधन), Google, GitHub या अपने संस्थान से साइन-इन (SSO और OAuth प्रमाणीकरण), या क्राउडसोर्स किए गए अध्ययन के लिए वे लिंक इस्तेमाल करें जो कोई प्लेटफ़ॉर्म अपने वर्करों को देता है (क्राउडसोर्सिंग एकीकरण)।
- ऐसा स्टोरेज जो रीस्टार्ट के बाद बचा रहे। कुछ होस्ट सर्वर के हर रीस्टार्ट पर डिस्क मिटा देते हैं। उनमें से किसी पर चलने वाले अध्ययन को ऐसा बैकअप चाहिए जो अपने आप रीस्टोर हो, वरना लौटने वाले एनोटेटर को टास्क खाली मिलेगा।
- डेटा वापस पाने का एक तरीका। Potato हर एनोटेटर का काम फ़ाइलों में रखता है और प्रोजेक्ट डेटा SQLite डेटाबेस में रखता है। सर्वर चलते समय SQLite फ़ाइल कॉपी करने पर हाल का काम छूट सकता है, इसलिए डेटा वापस पाने के लिए SQLite का अपना backup कमांड इस्तेमाल होना चाहिए।
आम अध्ययन स्थितियों के लिए होस्ट
कौन-सा होस्ट ठीक बैठेगा, यह इस पर निर्भर करता है कि अध्ययन कितने समय चलता है, ख़र्च कौन उठाता है, और आपका संस्थान पहले से सर्वर चलाता है या नहीं। तालिका आम स्थितियों को एक होस्ट से जोड़ती है, साथ में वह मासिक लागत भी देती है जो Potato हर टारगेट के डिफ़ॉल्ट आकार के लिए प्रिंट करता है:
| स्थिति | होस्ट | मासिक लागत | गाइड |
|---|---|---|---|
| AWS खाते के साथ एक अध्ययन | AWS Lightsail, 2 GB | $12 | AWS Lightsail |
| किसी अमेरिकी संस्थान में बिना बजट का अध्ययन | Jetstream2 | ACCESS आवंटन के साथ मुफ़्त | Jetstream2 |
| सबसे कम कीमत पर एक अध्ययन | Hetzner Cloud, 4 GB | लगभग €6 | Hetzner, Vultr और Linode |
| एक सार्वजनिक डेमो, या पहले से Hugging Face पर मौजूद लैब | एक Hugging Face Docker Space | PRO या Team प्लान | Hugging Face Spaces |
| कुछ लोगों के साथ एक दोपहर का पायलट | potato share के ज़रिए आपका लैपटॉप | मुफ़्त | Potato को लोकल या क्लाउड में चलाना |
| आपके संस्थान का पहले से चल रहा सर्वर | रिवर्स प्रॉक्सी के पीछे Docker इमेज | Potato की ओर से कुछ नहीं | प्रोडक्शन सेटअप |
पहले तीन वर्चुअल मशीनें हैं जिनकी डिस्क रीस्टार्ट के बाद बची रहती है, इसलिए हफ़्तों चलने वाले अध्ययन के लिए यही डिफ़ॉल्ट विकल्प हैं। Hugging Face Space हर रीस्टार्ट पर अपनी डिस्क खो देता है, इसलिए Potato हर पाँच मिनट में एनोटेशन का बैकअप एक निजी Hugging Face डेटासेट में लेता है और Space शुरू होने पर उन्हें रीस्टोर करता है। Potato को लोकल या क्लाउड में चलाना सभी तेरह क्लाउड टारगेट की सूची देता है, जिनमें Fly, Railway, Render और Heroku शामिल हैं।
नए होस्ट पर potato deploy
potato deploy up पायलट में आज़माया गया आपका कॉन्फ़िग लेता है और वह सब करता है जो वरना किसी व्यक्ति को हाथ से करना पड़ता। VM पर यह मशीन बनाता है, केवल पोर्ट 22, 80 और 443 खोलता है, Docker और Caddy वेब सर्वर इंस्टॉल करता है, Let's Encrypt प्रमाणपत्र लेता है, प्रोजेक्ट अपलोड करता है और Potato को सर्विस के रूप में शुरू करता है। पहले अपने होस्ट का pip extra इंस्टॉल करें, यानी वे वैकल्पिक निर्भरताएँ जिनकी उस होस्ट पर तैनाती को ज़रूरत है, फिर कॉन्फ़िग को उसी तरह जाँचें जैसे होस्ट उसे पढ़ेगा:
pip install 'potato-annotation[deploy-aws]'
potato deploy check myproject/config.yaml --provider aws
potato deploy up myproject/config.yaml --provider aws --dry-runpotato deploy check कॉन्फ़िगरेशन की त्रुटियाँ बताता है और ऐसे पाथ ढूँढता है जो केवल आपकी मशीन पर मौजूद हैं। --dry-run के लिए किसी क्लाउड खाते की ज़रूरत नहीं है, और यह हर वह संसाधन प्रिंट करता है जो तैनाती बनाएगी, मासिक लागत, और यह कि कौन साइन इन कर पाएगा। सार्वजनिक पते पर खुले पंजीकरण को यह चेतावनी D003 से चिह्नित करता है। तैनात करने के लिए वही कमांड --dry-run के बिना चलाएँ। Potato योजना फिर से दिखाता है, आपकी पुष्टि तक कुछ नहीं बनाता, और फिर वह URL प्रिंट करता है जो आपको अपने एनोटेटरों को भेजना है।
तैनाती केवल होस्टिंग से जुड़ी सेटिंग्स बदलती है। यह डीबग मोड बंद करती है, रीस्टार्ट के पार सत्र बनाए रखती है, और एक ही वर्कर प्रोसेस चलाती है, क्योंकि Potato आइटम पूल और असाइनमेंट कतार मेमोरी में रखता है और दूसरा प्रोसेस वही आइटम दो बार बाँट देगा। यह user_config, authentication और require_password को वैसा ही छोड़ती है जैसा आपने लिखा था। यह तैनाती के लिए एक एडमिन कुंजी बनाती है और उसे आपके कॉन्फ़िग के बगल में .potato/secrets.json में रखती है, और यह कुंजी /admin पर एडमिन डैशबोर्ड खोलती है।
आपके संस्थान के पहले से चल रहे सर्वर पर Potato
अगर आपका संस्थान पहले से कोई सर्वर चलाता है, तो नया होस्ट बनाने के बजाय प्रकाशित Docker इमेज को उसकी रिवर्स प्रॉक्सी के पीछे चलाएँ। nginx जैसी रिवर्स प्रॉक्सी प्रमाणपत्र रखती है और अनुरोधों को Potato तक आगे भेजती है। प्रोडक्शन सेटअप में Docker Compose फ़ाइल, nginx कॉन्फ़िगरेशन और gunicorn सेटिंग्स हैं। gunicorn को एक ही वर्कर पर रखें और समवर्तिता के लिए threads जोड़ें, क्योंकि दूसरा वर्कर प्रोसेस वही आइटम दो बार बाँट देगा।
Potato का backup ब्लॉक डेटा की एक प्रति उस सर्वर से बाहर रखता है। यह डिफ़ॉल्ट रूप से हर पाँच मिनट में एनोटेशन आउटपुट और प्रोजेक्ट डेटाबेस के स्नैपशॉट को Hugging Face डेटासेट या S3-संगत बकेट में कॉपी करता है, और जब सर्वर खाली डिस्क के साथ शुरू होता है तो उन्हें रीस्टोर करता है। कॉन्फ़िग में यह ब्लॉक जोड़ें, hosting extra इंस्टॉल करें, और सर्वर के एनवायरनमेंट में HF_TOKEN सेट करें:
backup:
schedule_minutes: 5
restore_on_boot: true
sinks:
- type: huggingface
repo_id: lab/pilot-annotationsअगर डेटासेट मौजूद नहीं है, तो Potato उसे एक निजी रिपॉज़िटरी के रूप में बनाता है। रीस्टोर एनोटेशन के साथ खातों की सूची भी वापस लाता है, इसलिए एनोटेटर उन्हीं पासवर्ड से साइन इन करते हैं, और यह डिस्क पर पहले से मौजूद एनोटेशन को कभी ओवरराइट नहीं करता।
स्थिति की जाँच और डेटा वापस पाना
potato deploy status बताता है कि सर्वर चालू है या नहीं और उसका प्रमाणपत्र ठीक है या नहीं। डोमेन नाम के बिना VM पर प्रमाणपत्र IP पते के लिए जारी होता है और लगभग छह दिन चलता है। यह अपने आप नवीनीकृत होता है, इसलिए अगर अध्ययन बिना निगरानी के चलता है तो हर कुछ दिनों में स्थिति जाँचें, या सर्वर की ओर इशारा करने वाले DNS रिकॉर्ड के साथ --domain दें। potato deploy logs myproject/config.yaml -f सर्वर लॉग पर नज़र रखता है, और एनोटेटरों के काम करते समय एडमिन डैशबोर्ड प्रगति, काम की रफ़्तार और इंटर-एनोटेटर सहमति दिखाता है।
अध्ययन ख़त्म होने पर होस्ट हटाने से पहले डेटा निकाल लें:
potato deploy pull myproject/config.yaml
potato deploy destroy myproject/config.yamlpull एनोटेशन आउटपुट और प्रोजेक्ट डेटाबेस को एक नई potato-pull-<name>-<timestamp> डायरेक्टरी में कॉपी करता है और जाँचता है कि क्या पहुँचा। destroy ऐसी तैनाती को नहीं हटाता जिसका कभी pull नहीं हुआ, और जिस pull में कोई फ़ाइल नहीं आई वह गिना नहीं जाता, इसलिए कुछ भी नष्ट करने से पहले निकाली गई डायरेक्टरी खोलें और जाँचें कि आख़िरी एनोटेशन उसमें हैं।
आगे पढ़ें
- Potato को लोकल या क्लाउड में चलाना, हर क्लाउड टारगेट और बैकअप फ़्लैग के लिए
- प्रोडक्शन सेटअप, आपके अपने सर्वर पर gunicorn, Docker और nginx के लिए
- Prolific और MTurk पर अध्ययन चलाना, तैनात टास्क पर क्राउडवर्करों को भेजने के लिए
- मशीन लर्निंग के लिए एनोटेशन एक्सपोर्ट करना, निकाले गए डेटा को ट्रेनिंग फ़ाइलों में बदलने के लिए