Skip to content

एनोटेशन सर्वर तैनात करना

एनोटेशन अध्ययन का होस्ट उसकी अवधि, ख़र्च उठाने वाले और आपके सर्वरों के आधार पर चुनें, फिर 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$12AWS Lightsail
किसी अमेरिकी संस्थान में बिना बजट का अध्ययनJetstream2ACCESS आवंटन के साथ मुफ़्तJetstream2
सबसे कम कीमत पर एक अध्ययनHetzner Cloud, 4 GBलगभग €6Hetzner, Vultr और Linode
एक सार्वजनिक डेमो, या पहले से Hugging Face पर मौजूद लैबएक Hugging Face Docker SpacePRO या 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 इंस्टॉल करें, यानी वे वैकल्पिक निर्भरताएँ जिनकी उस होस्ट पर तैनाती को ज़रूरत है, फिर कॉन्फ़िग को उसी तरह जाँचें जैसे होस्ट उसे पढ़ेगा:

bash
pip install 'potato-annotation[deploy-aws]'
potato deploy check myproject/config.yaml --provider aws
potato deploy up myproject/config.yaml --provider aws --dry-run

potato 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 सेट करें:

yaml
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 सर्वर लॉग पर नज़र रखता है, और एनोटेटरों के काम करते समय एडमिन डैशबोर्ड प्रगति, काम की रफ़्तार और इंटर-एनोटेटर सहमति दिखाता है।

अध्ययन ख़त्म होने पर होस्ट हटाने से पहले डेटा निकाल लें:

bash
potato deploy pull myproject/config.yaml
potato deploy destroy myproject/config.yaml

pull एनोटेशन आउटपुट और प्रोजेक्ट डेटाबेस को एक नई potato-pull-<name>-<timestamp> डायरेक्टरी में कॉपी करता है और जाँचता है कि क्या पहुँचा। destroy ऐसी तैनाती को नहीं हटाता जिसका कभी pull नहीं हुआ, और जिस pull में कोई फ़ाइल नहीं आई वह गिना नहीं जाता, इसलिए कुछ भी नष्ट करने से पहले निकाली गई डायरेक्टरी खोलें और जाँचें कि आख़िरी एनोटेशन उसमें हैं।

आगे पढ़ें