Docker में Potato चलाएँ

यह पृष्ठ बताता है कि Potato एनोटेशन प्रोजेक्ट को कंटेनर में कैसे चलाएँ, पहले docker run से लेकर चालू अध्ययन को नई रिलीज़ पर ले जाने तक। यह पृष्ठ उन शोधकर्ताओं और लैब एडमिन के लिए लिखा गया है जो अध्ययन को अपनी मशीन या अपने सर्वर से चलाते हैं और होस्ट पर Python इंस्टॉल किए बिना Potato चाहते हैं। Potato इमेज को GitHub Container Registry पर ghcr.io/davidjurgens/potato के नाम से प्रकाशित करता है, और इमेज में सर्वर और उसकी निर्भरताएँ हैं, इसके अलावा कुछ नहीं। कंटेनर शुरू होने पर आपका प्रोजेक्ट फ़ोल्डर /app पर माउंट होता है, इसलिए एक ही इमेज हर टास्क को चलाती है।

potato deploy उसी इमेज को उन क्लाउड होस्ट पर चलाता है जिन्हें यह कमांड सेट करती है, और आपके इंस्टॉल किए Potato संस्करण से मेल खाता टैग चुनता है। Potato को लोकल या क्लाउड में चलाना उस रास्ते को कवर करता है, और प्रोडक्शन सेटअप आपके अपने सर्वर पर gunicorn, रिवर्स प्रॉक्सी और TLS को कवर करता है।

इमेज प्राप्त करना

pip से Potato की numpy, pandas, scipy और scikit-learn निर्भरताएँ इंस्टॉल करने पर 1 GB की मशीन में मेमोरी कम पड़ जाती है और 2 GB की मशीन में पाँच से दस मिनट लगते हैं। इमेज में ये निर्भरताएँ पहले से इंस्टॉल मिलती हैं:

docker pull ghcr.io/davidjurgens/potato:2.14.0

इमेज दो रूपों में आती है, और हर रूप के लिए एक चलता हुआ टैग, हर रिलीज़ के लिए एक टैग और हर कमिट के लिए एक टैग है:

दोनों रूप linux/amd64 और linux/arm64 के लिए बनाए जाते हैं, और arm64 बिल्ड Apple Silicon पर सीधे चलता है। किसी भी रूप में vision extra शामिल नहीं है, जिसके torch wheel कई गीगाबाइट के हैं। ब्राउज़र-साइड सेगमेंटेशन इस extra के बिना भी काम करता है, क्योंकि ONNX Runtime Web Potato पैकेज के भीतर आता है।

जो अध्ययन एक दिन से अधिक चलेगा, उसके लिए संस्करण वाला टैग पिन करें। latest टैग master ब्रांच से हर बदलाव पर दोबारा बनता है, और एक हफ़्ते के अंतर पर चलाए दो docker pull अलग कोड ला सकते हैं। 2.14.0 जैसा संस्करण टैग रिलीज़ के समय एक बार पुश होता है और उसके बाद दोबारा नहीं बनता।

इमेज को ख़ुद बनाना

जब आपको ऐसा extra चाहिए जो प्रकाशित दोनों रूपों में नहीं है, तो रिपॉज़िटरी के क्लोन से बिल्ड करें। POTATO_EXTRAS बिल्ड आर्ग्युमेंट Potato की setup.py में नामित कोई भी extra लेता है, या कई extra अल्पविराम से अलग करके:

git clone https://github.com/davidjurgens/potato
cd potato
docker build -t potato .
docker build --build-arg POTATO_EXTRAS=all -t potato:all .
docker build --build-arg POTATO_EXTRAS=all,saml -t potato:all-saml .

SAML साइन-इन के लिए saml extra all का हिस्सा नहीं है। Dockerfile वह libxmlsec1 लाइब्रेरी, जिसके विरुद्ध यह extra कंपाइल होता है, केवल तब इंस्टॉल करता है जब POTATO_EXTRAS में saml नामित हो। इस पृष्ठ पर जहाँ भी ghcr.io/davidjurgens/potato:2.14.0 नामित है, वहाँ लोकल बिल्ड को उसके टैग से चलाएँ, जैसे potato:all।

प्रोजेक्ट चलाना

प्रोजेक्ट फ़ोल्डर में config.yaml और वे सब फ़ाइलें होती हैं जिन्हें कॉन्फ़िग नाम से बताता है। इस पृष्ठ के उदाहरण तीन आइटम वाले सेंटिमेंट टास्क का उपयोग करते हैं, जिसका लेआउट यह है:

myproject/
├── config.yaml
└── data/
    └── items.jsonl

कॉन्फ़िग हर पाथ को प्रोजेक्ट फ़ोल्डर के सापेक्ष रखता है:

annotation_task_name: "Sentiment pilot"
task_dir: .
data_files:
  - data/items.jsonl
item_properties:
  id_key: id
  text_key: text
output_annotation_dir: annotation_output/
user_config:
  allow_all_users: true
annotation_schemes:
  - annotation_type: radio
    name: sentiment
    description: "What is the sentiment of this sentence?"
    labels: [positive, neutral, negative]

data/items.jsonl की हर पंक्ति एक आइटम है:

{"id": "1", "text": "The battery lasts all day."}
{"id": "2", "text": "The screen cracked within a week."}
{"id": "3", "text": "It arrived on Tuesday."}

सर्वर उस फ़ोल्डर से शुरू करें जिसमें myproject है:

docker run -d --name potato -p 8000:7860 \
  -v "$PWD/myproject:/app" \
  ghcr.io/davidjurgens/potato:2.14.0

टास्क तब http://localhost:8000 पर होता है। -p 8000:7860 आर्ग्युमेंट आपकी मशीन के पोर्ट 8000 को पोर्ट 7860 से जोड़ता है, जिस पर सर्वर कंटेनर के भीतर सुनता है। -v आर्ग्युमेंट प्रोजेक्ट फ़ोल्डर को /app पर माउंट करता है। होस्ट की ओर $PWD/myproject जैसा पाथ होना ज़रूरी है, क्योंकि Docker myproject जैसे सादे नाम को नए, ख़ाली वॉल्यूम का नाम मानता है। docker logs -f potato सर्वर लॉग का पीछा करता है, और docker stop potato सर्वर को रोकता है।

कई कॉन्फ़िग वाला प्रोजेक्ट POTATO_CONFIG से एक चुनता है, जो /app के सापेक्ष एक पाथ है:

docker run -d --name potato -p 8000:7860 \
  -v "$PWD/myproject:/app" \
  -e POTATO_CONFIG=configs/pilot.yaml \
  ghcr.io/davidjurgens/potato:2.14.0

हफ़्तों चलने वाला अध्ययन

जो अध्ययन हफ़्तों चलता है, उसे ऐसी सत्र हस्ताक्षर कुंजी चाहिए जो रीस्टार्ट और अपडेट के बाद भी वही रहे। POTATO_SECRET_KEY के बिना सर्वर हर शुरुआत पर नई यादृच्छिक कुंजी चुनता है और हर एनोटेटर को साइन आउट कर देता है। प्रोजेक्ट फ़ोल्डर के बाहर एक बार env फ़ाइल बनाएँ, और हर docker run को वही फ़ाइल दें:

printf 'POTATO_SECRET_KEY=%s\nPOTATO_ADMIN_API_KEY=%s\n' \
  "$(openssl rand -hex 32)" "$(openssl rand -hex 32)" > potato.env
chmod 600 potato.env
 
docker run -d --name potato -p 8000:7860 \
  -v "$PWD/myproject:/app" \
  --env-file potato.env \
  --restart unless-stopped \
  ghcr.io/davidjurgens/potato:2.14.0

फ़ाइल की दूसरी पंक्ति को कंटेनर में एडमिन कुंजी खंड समझाता है। --restart unless-stopped क्रैश या होस्ट के रीबूट के बाद कंटेनर को वापस ले आता है।

इमेज में अन्य कमांड

इमेज के नाम के बाद लिखी कोई भी चीज़ सर्वर की जगह ले लेती है। इमेज के साथ आने वाले वैलिडेटर से कॉन्फ़िग जाँचें, या कंटेनर के भीतर शेल खोलें:

docker run --rm -v "$PWD/myproject:/app" \
  ghcr.io/davidjurgens/potato:2.14.0 potato validate config.yaml --strict
 
docker run --rm -it -v "$PWD/myproject:/app" \
  ghcr.io/davidjurgens/potato:2.14.0 sh

Linux पर फ़ाइल स्वामित्व

इमेज में सर्वर uid 1000 के रूप में चलता है, और बाइंड माउंट फ़ोल्डर का वही स्वामित्व रखता है जो होस्ट पर है। Linux पर आपका बनाया फ़ोल्डर आपके अपने uid का होता है, और root का बनाया फ़ोल्डर root का। जब तक फ़ोल्डर का स्वामी uid 1000 नहीं है, सर्वर फ़ोल्डर में एनोटेशन नहीं लिख सकता। कंटेनर सर्वर शुरू होने से पहले फ़ोल्डर जाँचता है और स्टार्टअप के बीच में विफल होने के बजाय ERROR: /app is not writable by uid 1000 के साथ रुक जाता है। नीचे की कोई भी कमांड समस्या ठीक करती है:

sudo chown -R 1000:1000 myproject                  # hand the folder to the container user
docker run --user "$(id -u):$(id -g)" ...          # or run the container as yourself

--user के साथ, Potato जो एनोटेशन और एडमिन कुंजी फ़ाइल लिखता है वे भी आपके अपने खाते की होती हैं। macOS और Windows पर Docker Desktop बाइंड माउंट पर स्वामित्व की उपेक्षा करता है, और जो प्रोजेक्ट Mac पर चलता है वह Linux सर्वर पर फिर भी विफल हो सकता है। POTATO_ALLOW_READONLY_APP=1 इस जाँच को छोड़ देता है। Potato फिर भी एनोटेशन, potato.log और अपने SQLite डेटाबेस प्रोजेक्ट के भीतर लिखता है, इसलिए यह वेरिएबल तभी सेट करें जब ये पाथ अलग माउंट के ज़रिए लिखने योग्य हों।

कुछ होस्ट हर कंटेनर को root के रूप में शुरू करते हैं, इमेज जो भी तय करे। जब कंटेनर root के रूप में शुरू होता है, तो कंटेनर /app को इमेज के potato उपयोगकर्ता को दे देता है और सर्वर को उसी उपयोगकर्ता के रूप में शुरू करता है। root बनाए रखने के लिए POTATO_RUN_AS_ROOT=1 सेट करें।

एनोटेशन सुरक्षित रखना

अध्ययन जो कुछ भी इकट्ठा करता है, Potato उसे प्रोजेक्ट फ़ोल्डर में लिखता है। एनोटेशन output_annotation_dir के नीचे जाते हैं, हर एनोटेटर की एक डायरेक्टरी में, जिसमें उस एनोटेटर की user_state.json होती है। दो SQLite डेटाबेस config.yaml के बगल में रहते हैं। project.sqlite में मेमो, कोडबुक, केस, खोज इंडेक्स और समीक्षा वर्कफ़्लो हैं, और datasets.sqlite में मूल्यांकन डेटासेट और उनके संस्करण हैं। इनमें से कोई डेटाबेस डेटा फ़ाइलों से दोबारा नहीं बनाया जा सकता। बाइंड माउंट के साथ ये सब फ़ाइलें आपकी डिस्क पर होती हैं और कंटेनर हटाने पर भी वहीं रहती हैं।

output_annotation_dir का पाथ प्रोजेक्ट फ़ोल्डर के भीतर ही बनना चाहिए। /data/annotations जैसा पाथ सर्वर को स्टार्टअप पर इस संदेश के साथ रोक देता है: output_annotation_dir: Path '/data/annotations' resolves to '/data/annotations' which is outside the project directory '/app'। annotation_output/ जैसा सापेक्ष पाथ रखें। इमेज का /data वॉल्यूम भी प्रोजेक्ट के बाहर है, और Potato वहाँ कुछ नहीं लिखता।

चालू कंटेनर से डेटाबेस SQLite की backup कमांड से निकालें, सादी फ़ाइल की तरह कभी नहीं। जब सर्वर डेटाबेस में लिखता है, तब project.sqlite WAL मोड में चलता है, और सादी प्रति बिना किसी चेतावनी के दूषित हो सकती है या हाल का काम छोड़ सकती है। स्नैपशॉट के लिए इमेज में sqlite3 टूल शामिल है:

docker exec potato sqlite3 /app/project.sqlite ".backup /tmp/snap.sqlite"
docker cp potato:/tmp/snap.sqlite ./project.sqlite

अधिकांश मैनेज्ड कंटेनर होस्ट कंटेनर के रीस्टार्ट होने पर उसका फ़ाइलसिस्टम मिटा देते हैं। ऐसे होस्ट पर प्रोजेक्ट को /app पर माउंट किए गए स्थायी स्टोरेज में रखें, या कॉन्फ़िग में backup ब्लॉक जोड़ें। यह ब्लॉक एनोटेशन और डेटाबेस स्नैपशॉट को तय समय पर S3 बकेट या Hugging Face डेटासेट में कॉपी करता है, और सर्वर ख़ाली डिस्क के साथ शुरू होने पर उन्हें बहाल करता है। इमेज का हर रूप वे क्लाइंट शामिल करता है जिनकी इस ब्लॉक को ज़रूरत है।

एनवायरनमेंट वेरिएबल

कंटेनर शुरू होते समय ये वेरिएबल पढ़ता है:

जो कंटेनर PORT बदलता है, उसे -p के दाएँ भाग में वही पोर्ट चाहिए, जैसे PORT=9000 के लिए -p 8000:9000।

वर्कर और थ्रेड की संख्या

कंटेनर एक से अधिक gunicorn वर्कर के साथ शुरू होने से मना कर देता है। Potato अपना आइटम पूल, असाइनमेंट कतार और हर एनोटेटर की स्थिति एक प्रोसेस की मेमोरी में रखता है। दूसरे वर्कर के पास इन तीनों की अपनी प्रति होगी, और वह ऐसे आइटम बाँट देगा जो पहला वर्कर पहले ही बाँट चुका है। हर सेव user_state.json को पूरा दोबारा लिखता है, इसलिए जो वर्कर आख़िर में सेव करेगा वह दूसरे वर्कर के एनोटेशन बिना किसी त्रुटि के मिटा देगा। एक साथ अधिक अनुरोधों के लिए इसके बजाय GUNICORN_THREADS बढ़ाएँ, क्योंकि थ्रेड स्थिति की एक ही प्रति साझा करते हैं।

बनाए गए टेम्पलेट

Potato स्टार्टअप पर हर टास्क के एनोटेशन पृष्ठ का टेम्पलेट बनाता है। कंटेनर के बाहर, पैकेज डायरेक्टरी लिखने योग्य होने पर टेम्पलेट इंस्टॉल किए गए पैकेज में जाता है। इमेज Potato को root के रूप में इंस्टॉल करती है और सर्वर को uid 1000 के रूप में चलाती है, इसलिए सर्वर पैकेज डायरेक्टरी में नहीं लिख सकता। Potato इसके बजाय टेम्पलेट /tmp के नीचे की ऐसी डायरेक्टरी में लिखता है जिसे केवल सर्वर का उपयोगकर्ता पढ़ या लिख सकता है, और स्टार्टअप लॉग उस डायरेक्टरी का नाम बताता है। Potato हर शुरुआत पर कॉन्फ़िग से टेम्पलेट दोबारा बनाता है, और डायरेक्टरी खो जाने से कुछ नहीं बिगड़ता। टेम्पलेट कहीं और रखने के लिए, जैसे tmpfs माउंट पर, POTATO_GENERATED_TEMPLATES_DIR सेट करें।

स्टार्टअप पर प्रोजेक्ट डाउनलोड करना

जो होस्ट केवल इमेज चलाते हैं, जैसे Render, Fly, Railway और ECS, उनके पास माउंट करने के लिए कोई फ़ोल्डर नहीं होता। POTATO_BUNDLE_URL सेट होने पर कंटेनर प्रोजेक्ट की .tar.gz डाउनलोड करता है, डाउनलोड को POTATO_BUNDLE_SHA256 से मिलाकर जाँचता है, और सर्वर शुरू होने से पहले प्रोजेक्ट को /app में खोलता है। कंटेनर चेकसम को /app/.potato-bundle-sha में लिखता है, और स्थायी डिस्क पर रीस्टार्ट उस डाउनलोड को छोड़ देता है जिसका चेकसम मेल खाता है। potato deploy से बने बंडल में, प्रोजेक्ट का नया संस्करण डिस्क पर पहले से मौजूद एनोटेशन आउटपुट या SQLite डेटाबेस को कभी नहीं बदलता। potato deploy up ये वेरिएबल आपके लिए सेट करता है।

कंटेनर में एडमिन कुंजी

/admin पर एडमिन डैशबोर्ड और एडमिन API एक साझा कुंजी लेते हैं, जो X-API-Key हेडर के रूप में भेजी जाती है या एडमिन लॉगिन पृष्ठ पर टाइप की जाती है। Potato कुंजी को पहले शीर्ष-स्तर की admin_api_key कॉन्फ़िग कुंजी से पढ़ता है, फिर POTATO_ADMIN_API_KEY एनवायरनमेंट वेरिएबल से। कंटेनर में एनवायरनमेंट वेरिएबल कुंजी को config.yaml से और प्रोजेक्ट रखने वाली किसी भी रिपॉज़िटरी से बाहर रखता है। हफ़्तों चलने वाले अध्ययन वाले खंड की potato.env फ़ाइल यह वेरिएबल सेट करती है, और तब एडमिन कुंजी वही है जो उस फ़ाइल में है:

grep POTATO_ADMIN_API_KEY potato.env

जब न कॉन्फ़िग और न एनवायरनमेंट कुंजी सेट करता है, तो Potato पहली बार किसी के /admin खोलने या एडमिन एंडपॉइंट बुलाने पर कुंजी बना देता है। Potato बनाई गई कुंजी को टास्क डायरेक्टरी में admin_api_key.txt में लिखता है। कंटेनर में टास्क डायरेक्टरी /app है, यानी माउंट किया गया प्रोजेक्ट फ़ोल्डर। फ़ाइल केवल सर्वर के उपयोगकर्ता द्वारा पढ़ी जा सकती है, और Potato रीस्टार्ट के बाद वही फ़ाइल पढ़ता है। सर्वर लॉग फ़ाइल का नाम बताता है और कुंजी कभी नहीं छापता। कुंजी कंटेनर के ज़रिए पढ़ें:

docker exec potato cat /app/admin_api_key.txt

जिस Linux होस्ट पर आपने प्रोजेक्ट फ़ोल्डर uid 1000 को दिया है, वहाँ आपका अपना खाता sudo के बिना admin_api_key.txt नहीं पढ़ सकता। --user "$(id -u):$(id -g)" के साथ शुरू किया कंटेनर फ़ाइल को आपके अपने खाते के रूप में लिखता है। कुंजी क्या खोलती है, इसके लिए एडमिन डैशबोर्ड पृष्ठ देखें।

कंटेनर में डीबग मोड

अध्ययन चलाने वाले किसी भी कंटेनर में debug: false रखें। कॉन्फ़िग में debug: true होने पर Potato दो सुविधाओं का व्यवहार बदल देता है:

• बिना कुंजी के एडमिन पृष्ठ। एडमिन डैशबोर्ड और एडमिन API उस अनुरोध के लिए कुंजी छोड़ देते हैं जो लूपबैक पते से आता है और जिसमें X-Forwarded-For, X-Real-IP या Forwarded हेडर नहीं है। Docker के डिफ़ॉल्ट ब्रिज नेटवर्क पर, प्रकाशित पोर्ट पर आया अनुरोध ब्रिज के पते से कंटेनर तक पहुँचता है और फिर भी कुंजी माँगता है। --network host के साथ, होस्ट मशीन से आया अनुरोध लूपबैक अनुरोध है और उसे कुंजी नहीं चाहिए। उसी नेटवर्क नेमस्पेस में चलने वाला रिवर्स प्रॉक्सी, जो कोई फ़ॉरवर्डिंग हेडर नहीं जोड़ता, अपने भेजे हर अनुरोध को लोकल जैसा दिखा देता है।
• साझा डीबग खाता। debug_phase भी सेट होने पर हर आगंतुक एक साझा खाते debug_user के रूप में साइन इन होता है और उसी फ़ेज़ पर पहुँचा दिया जाता है। यह खाता एडमिन नहीं है, लेकिन हर आगंतुक इस खाते के उत्तर साझा करता है।

debug चालू होने पर सर्वर स्टार्टअप पर चेतावनी लॉग करता है। docker exec से कंटेनर के भीतर चलाई कमांड लूपबैक अनुरोध है। इसलिए डीबग मोड में docker exec potato curl -s http://127.0.0.1:7860/admin/health बिना कुंजी के एडमिन हेल्थ रिपोर्ट लौटा देती है।

हेल्थ चेक

GET /health को प्रमाणीकरण नहीं चाहिए और यह केवल यह बताता है कि सर्वर चालू है या नहीं। सर्वर तैयार होने पर यह रूट {"status": "ok"} लौटाता है, और जब तक सर्वर डेटा लोड कर रहा हो तब तक स्टेटस 503, और लोड बैलेंसर या ऑर्केस्ट्रेटर इस रूट को अपनी तैयारी जाँच के रूप में पोल कर सकता है। इमेज का अपना HEALTHCHECK हर 30 सेकंड पर /health पोल करता है और बड़े टास्क के लिए 90 सेकंड की शुरुआती अवधि देता है, और docker ps नतीजा दिखाता है। GET /admin/health टास्क का नाम और आइटम व एनोटेटर मैनेजरों की स्थिति बताता है, और इस रूट को X-API-Key हेडर में एडमिन कुंजी चाहिए।

Docker Compose

Potato रिपॉज़िटरी में कोई Compose फ़ाइल नहीं आती। प्रोडक्शन सेटअप एक Compose फ़ाइल दिखाता है जो इस इमेज को nginx के पीछे चलाती है, जिसमें प्रोजेक्ट फ़ोल्डर /app पर माउंट है और सत्र व एडमिन कुंजियाँ एनवायरनमेंट से पढ़ी जाती हैं।

नए संस्करण पर अपडेट करना

Potato अपडेट करने से कंटेनर बदलता है और प्रोजेक्ट फ़ोल्डर, हर एनोटेशन और डेटाबेस के साथ, जस का तस रहता है। बदलने से पहले नई रिलीज़ खींचें, नई रिलीज़ के वैलिडेटर से कॉन्फ़िग जाँचें, और प्रोजेक्ट डेटाबेस का स्नैपशॉट लें। 2.14.0 को उस रिलीज़ से बदलें जिस पर आप जा रहे हैं:

docker pull ghcr.io/davidjurgens/potato:2.14.0
docker run --rm -v "$PWD/myproject:/app" \
  ghcr.io/davidjurgens/potato:2.14.0 potato validate config.yaml --strict
docker exec potato sqlite3 /app/project.sqlite ".backup /tmp/snap.sqlite"
docker cp potato:/tmp/snap.sqlite ./project-before-update.sqlite

फिर चालू कंटेनर को नए टैग वाले कंटेनर से बदलें, वही माउंट और वही env फ़ाइल इस्तेमाल करते हुए:

docker stop potato
docker rm potato
docker run -d --name potato -p 8000:7860 \
  -v "$PWD/myproject:/app" \
  --env-file potato.env \
  --restart unless-stopped \
  ghcr.io/davidjurgens/potato:2.14.0

क्योंकि potato.env में POTATO_SECRET_KEY वही रहती है, एनोटेटर बदलाव के दौरान साइन इन रहते हैं, और एडमिन कुंजी नहीं बदलती।

समस्या निवारण

ERROR: config file not found: config.yaml। प्रोजेक्ट वहाँ माउंट नहीं हुआ जहाँ सर्वर ने देखा। त्रुटि आपके -v आर्ग्युमेंट से तुलना के लिए /app की सामग्री सूचीबद्ध करती है। ख़ाली सूची का आमतौर पर मतलब है कि -v myproject:/app जैसा सादा नाम दिया गया। Docker सादे नाम को आपके फ़ोल्डर के बजाय नया, ख़ाली वॉल्यूम मानता है।

ERROR: /app is not writable by uid 1000। सर्वर प्रोजेक्ट फ़ोल्डर में नहीं लिख सकता। फ़ोल्डर uid 1000 को दें या कंटेनर को --user के साथ चलाएँ। Linux पर फ़ाइल स्वामित्व दोनों कमांड देता है।

output_annotation_dir ... is outside the project directory '/app'। कॉन्फ़िग एनोटेशन आउटपुट को माउंट किए फ़ोल्डर के बाहर इंगित करता है। annotation_output/ जैसा सापेक्ष पाथ इस्तेमाल करें।

रीस्टार्ट के बाद सब साइन आउट हो जाते हैं। कोई हस्ताक्षर कुंजी सेट नहीं है, और सर्वर ने स्टार्टअप पर नई यादृच्छिक कुंजी चुन ली। env फ़ाइल में POTATO_SECRET_KEY सेट करें और फ़ाइल को हर docker run को दें।

कंटेनर GUNICORN_WORKERS का नाम लेती त्रुटि के साथ बंद हो जाता है। वर्कर की संख्या 1 से ऊपर है। GUNICORN_WORKERS=1 सेट करें, या वेरिएबल हटा दें, और इसके बजाय GUNICORN_THREADS बढ़ाएँ।

एडमिन लॉगिन पृष्ठ हर कुंजी ठुकरा देता है। कॉन्फ़िग की admin_api_key को POTATO_ADMIN_API_KEY पर प्राथमिकता मिलती है, और दोनों को admin_api_key.txt पर। पहले कॉन्फ़िग जाँचें, फिर docker exec potato printenv POTATO_ADMIN_API_KEY।

आगे पढ़ें

• Potato को लोकल या क्लाउड में चलाना - potato deploy के टारगेट जो यह इमेज आपके लिए चलाते हैं
• प्रोडक्शन सेटअप - अपने सर्वर पर gunicorn, nginx, TLS, सत्र और बैकअप
• रिवर्स प्रॉक्सी - Potato को URL पाथ प्रीफ़िक्स के नीचे चलाना
• एडमिन डैशबोर्ड - एडमिन कुंजी क्या खोलती है

कार्यान्वयन विवरण के लिए स्रोत दस्तावेज़ीकरण देखें।