Django 2.1 - Deployment checklist

तैनाती चेकलिस्ट




django

तैनाती चेकलिस्ट

इंटरनेट एक शत्रुतापूर्ण वातावरण है। अपने Django प्रोजेक्ट को तैनात करने से पहले, आपको अपनी सेटिंग्स की समीक्षा करने के लिए कुछ समय लेना चाहिए, सुरक्षा, प्रदर्शन और संचालन को ध्यान में रखते हुए।

Django में कई सुरक्षा विशेषताएं शामिल हैं । कुछ अंतर्निहित और हमेशा सक्षम होते हैं। अन्य वैकल्पिक हैं क्योंकि वे हमेशा उपयुक्त नहीं होते हैं, या क्योंकि वे विकास के लिए असुविधाजनक हैं। उदाहरण के लिए, जबरन HTTPS सभी वेबसाइटों के लिए उपयुक्त नहीं हो सकता है, और यह स्थानीय विकास के लिए अव्यावहारिक है।

प्रदर्शन अनुकूलन सुविधा के साथ व्यापार-नापसंद की एक और श्रेणी है। उदाहरण के लिए, कैशिंग उत्पादन में उपयोगी है, स्थानीय विकास के लिए कम। त्रुटि रिपोर्टिंग की जरूरतें भी व्यापक रूप से भिन्न हैं।

निम्न चेकलिस्ट में सेटिंग्स शामिल हैं:

  • Django के लिए सुरक्षा के अपेक्षित स्तर प्रदान करने के लिए ठीक से सेट किया जाना चाहिए;
  • प्रत्येक वातावरण में अलग होने की उम्मीद है;
  • वैकल्पिक सुरक्षा सुविधाएँ सक्षम करें;
  • प्रदर्शन अनुकूलन सक्षम करें;
  • त्रुटि रिपोर्टिंग प्रदान करें।

इनमें से कई सेटिंग्स संवेदनशील हैं और इन्हें गोपनीय माना जाना चाहिए। यदि आप अपनी परियोजना के लिए स्रोत कोड जारी कर रहे हैं, तो विकास के लिए उपयुक्त सेटिंग्स प्रकाशित करना और उत्पादन के लिए एक निजी सेटिंग मॉड्यूल का उपयोग करना एक आम बात है।

manage.py check --deploy

नीचे वर्णित कुछ चेकों को check --deploy विकल्प का उपयोग करके स्वचालित किया जा सकता है। विकल्प के दस्तावेज़ीकरण में वर्णित अपनी उत्पादन सेटिंग फ़ाइल के विरुद्ध इसे चलाना सुनिश्चित करें।

महत्वपूर्ण सेटिंग्स

SECRET_KEY

गुप्त कुंजी एक बड़ा यादृच्छिक मान होना चाहिए और इसे गुप्त रखा जाना चाहिए।

सुनिश्चित करें कि उत्पादन में प्रयुक्त कुंजी कहीं और उपयोग नहीं की गई है और इसे स्रोत नियंत्रण में रखने से बचें। इससे वैक्टर की संख्या कम हो जाती है जिससे एक हमलावर कुंजी प्राप्त कर सकता है।

अपनी सेटिंग मॉड्यूल में गुप्त कुंजी को हार्डकोड करने के बजाय, इसे पर्यावरण चर से लोड करने पर विचार करें:

import os
SECRET_KEY = os.environ['SECRET_KEY']

या एक फ़ाइल से:

with open('/etc/secret_key.txt') as f:
    SECRET_KEY = f.read().strip()

DEBUG

आपको उत्पादन में डीबग को कभी भी सक्षम नहीं करना चाहिए।

आप निश्चित रूप से DEBUG साथ अपनी परियोजना का विकास कर रहे हैं, क्योंकि यह आपके ब्राउज़र में पूर्ण ट्रेसबैक जैसी आसान सुविधाओं को सक्षम करता है।

एक उत्पादन वातावरण के लिए, हालांकि, यह वास्तव में एक बुरा विचार है, क्योंकि यह आपकी परियोजना के बारे में बहुत सारी जानकारी लीक करता है: आपके स्रोत कोड, स्थानीय चर, सेटिंग्स, प्रयुक्त पुस्तकालयों, आदि के अंश।

पर्यावरण-विशिष्ट सेटिंग्स

ALLOWED_HOSTS

जब DEBUG , Django ALLOWED_HOSTS लिए एक उपयुक्त मूल्य के बिना बिल्कुल भी काम नहीं करता है।

कुछ CSRF हमलों के खिलाफ आपकी साइट की सुरक्षा के लिए यह सेटिंग आवश्यक है। यदि आप वाइल्डकार्ड का उपयोग करते हैं, तो आपको Host HTTP हेडर का अपना सत्यापन करना चाहिए, या अन्यथा यह सुनिश्चित करना चाहिए कि आप इस श्रेणी के हमलों के लिए असुरक्षित नहीं हैं।

होस्ट को मान्य करने के लिए आपको Django के सामने बैठने वाले वेब सर्वर को भी कॉन्फ़िगर करना चाहिए। यह एक स्थिर त्रुटि पेज के साथ जवाब देना चाहिए या Django के अनुरोध को अग्रेषित करने के बजाय गलत मेजबानों के अनुरोधों को अनदेखा करना चाहिए। इस तरह से आप अपने Django लॉग्स (या ईमेल में त्रुटिपूर्ण त्रुटियों से बचेंगे यदि आपके पास उस तरह से कॉन्फ़िगर की गई त्रुटि रिपोर्टिंग है)। उदाहरण के लिए, nginx पर आप एक गैर मान्यता प्राप्त होस्ट पर "444 कोई प्रतिक्रिया नहीं" देने के लिए एक डिफ़ॉल्ट सर्वर सेटअप कर सकते हैं:

server {
    listen 80 default_server;
    return 444;
}

CACHES

यदि आप कैश का उपयोग कर रहे हैं, तो कनेक्शन पैरामीटर विकास और उत्पादन में भिन्न हो सकते हैं। Django प्रति-प्रक्रिया स्थानीय-मेमोरी कैशिंग को डिफॉल्ट करता है जो वांछनीय नहीं हो सकता है।

कैश सर्वर में अक्सर कमजोर प्रमाणीकरण होता है। सुनिश्चित करें कि वे केवल आपके एप्लिकेशन सर्वर से कनेक्शन स्वीकार करते हैं।

यदि आप मेमकाटेड का उपयोग कर रहे हैं, तो प्रदर्शन को बेहतर बनाने के लिए कैश्ड सत्रों का उपयोग करने पर विचार करें।

DATABASES

डेटाबेस कनेक्शन पैरामीटर शायद विकास और उत्पादन में भिन्न हैं।

डेटाबेस पासवर्ड बहुत संवेदनशील होते हैं। आपको SECRET_KEY तरह ही उनकी सुरक्षा करनी चाहिए।

अधिकतम सुरक्षा के लिए, सुनिश्चित करें कि डेटाबेस सर्वर केवल आपके एप्लिकेशन सर्वर से कनेक्शन स्वीकार करते हैं।

यदि आपने अपने डेटाबेस के लिए बैकअप सेट नहीं किया है, तो अभी करें!

डिफ़ॉल्ट रूप से, Django वेबमास्टर @ लोकलहोस्ट और रूट @ लोकलहोस्ट से ईमेल भेजता है। हालाँकि, कुछ मेल प्रदाता इन पतों से ईमेल को अस्वीकार कर देते हैं। विभिन्न प्रेषक पतों का उपयोग करने के लिए, DEFAULT_FROM_EMAIL और SERVER_EMAIL सेटिंग्स संशोधित करें।

STATIC_ROOT और STATIC_URL

स्टैटिक फाइलें विकास सर्वर द्वारा स्वचालित रूप से परोसी जाती हैं। उत्पादन में, आपको एक STATIC_ROOT निर्देशिका को परिभाषित करना होगा जहां STATIC_ROOT उन्हें कॉपी किया जाएगा।

अधिक जानकारी के लिए स्थैतिक फ़ाइलों (जैसे चित्र, जावास्क्रिप्ट, सीएसएस) का प्रबंधन देखें।

MEDIA_ROOT और MEDIA_URL

मीडिया फ़ाइलें आपके उपयोगकर्ताओं द्वारा अपलोड की जाती हैं। वे अविश्वसनीय हैं! सुनिश्चित करें कि आपका वेब सर्वर कभी भी उनकी व्याख्या करने का प्रयास नहीं करता है। उदाहरण के लिए, यदि कोई उपयोगकर्ता .php फ़ाइल अपलोड करता है, तो वेब सर्वर उसे निष्पादित नहीं करना चाहिए।

अब इन फ़ाइलों के लिए अपनी बैकअप रणनीति की जांच करने का एक अच्छा समय है।

FILE_UPLOAD_PERMISSIONS

डिफ़ॉल्ट फ़ाइल अपलोड सेटिंग के साथ, FILE_UPLOAD_MAX_MEMORY_SIZE तुलना में छोटी फ़ाइलों को FILE_UPLOAD_PERMISSIONS में वर्णित बड़ी फ़ाइलों की तुलना में भिन्न मोड के साथ संग्रहीत किया जा सकता है।

FILE_UPLOAD_PERMISSIONS सेट करना सुनिश्चित करता है कि सभी फाइलें समान अनुमतियों के साथ अपलोड की गई हैं।

HTTPS

कोई भी वेबसाइट जो उपयोगकर्ताओं को लॉग-इन करने की अनुमति देती है, उन्हें स्पष्ट रूप से पहुँच टोकन को प्रेषित करने से बचने के लिए साइट-वाइड HTTPS को लागू करना चाहिए। Django में, एक्सेस टोकन में लॉगिन / पासवर्ड, सत्र कुकी और पासवर्ड रीसेट टोकन शामिल हैं। (यदि आप उन्हें ईमेल द्वारा भेज रहे हैं तो आप पासवर्ड रीसेट टोकन की सुरक्षा के लिए बहुत कुछ नहीं कर सकते।)

उपयोगकर्ता खाते या व्यवस्थापक जैसे संवेदनशील क्षेत्रों की सुरक्षा करना पर्याप्त नहीं है, क्योंकि HTTP और HTTPS के लिए एक ही सत्र कुकी का उपयोग किया जाता है। आपके वेब सर्वर को सभी HTTP ट्रैफ़िक को HTTPS पर पुनर्निर्देशित करना चाहिए, और केवल HTTPS अनुरोधों को Django तक पहुँचाया जाना चाहिए।

एक बार जब आप HTTPS सेट कर लेते हैं, तो निम्नलिखित सेटिंग्स सक्षम करें।

प्रदर्शन अनुकूलन

DEBUG स्थापना करना DEBUG कई सुविधाएँ अक्षम करना जो केवल विकास में उपयोगी हैं। इसके अलावा, आप निम्न सेटिंग्स को ट्यून कर सकते हैं।

CONN_MAX_AGE

लगातार डेटाबेस कनेक्शन को सक्षम करने के परिणामस्वरूप अनुरोध प्रसंस्करण समय के एक महत्वपूर्ण भाग के लिए डेटाबेस खातों से कनेक्ट करते समय एक अच्छी गति हो सकती है।

यह सीमित नेटवर्क प्रदर्शन के साथ वर्चुअलाइज्ड होस्ट पर बहुत मदद करता है।

TEMPLATES

कैश्ड टेम्प्लेट लोडर को सक्षम करने से अक्सर प्रदर्शन में सुधार होता है, क्योंकि यह हर बार प्रत्येक टेम्पलेट को संकलित करने से बचता है जिसे उसे प्रदान करने की आवश्यकता होती है। अधिक जानकारी के लिए टेम्प्लेट लोडर डॉक्स देखें।

त्रुटि की सूचना देना

जब तक आप उत्पादन के लिए अपने कोड को धक्का देते हैं, तब तक यह उम्मीद के मुताबिक मजबूत होता है, लेकिन आप अप्रत्याशित त्रुटियों से इंकार नहीं कर सकते। शुक्र है, Django त्रुटियों को पकड़ सकता है और तदनुसार आपको सूचित कर सकता है।

LOGGING

अपनी वेबसाइट को उत्पादन में लगाने से पहले अपने लॉगिंग कॉन्फ़िगरेशन की समीक्षा करें, और जांचें कि जैसे ही आपको कुछ ट्रैफ़िक प्राप्त हुआ है, यह अपेक्षा के अनुरूप काम करता है।

Logging पर विवरण के लिए Logging देखें।

ADMINS और MANAGERS

ईमेल द्वारा ADMINS को 500 त्रुटियों की सूचना दी जाएगी।

MANAGERS को 404 त्रुटियों की सूचना दी जाएगी। IGNORABLE_404_URLS नकली रिपोर्टों को फ़िल्टर करने में मदद कर सकते हैं।

ईमेल द्वारा त्रुटि रिपोर्टिंग पर विवरण के लिए त्रुटि रिपोर्टिंग देखें।

ईमेल द्वारा रिपोर्ट करने में त्रुटि बहुत अच्छी तरह से मापी नहीं गई है

रिपोर्ट द्वारा बाढ़ आने से पहले Sentry जैसे त्रुटि निगरानी प्रणाली का उपयोग करने पर विचार करें। संतरी भी लॉग एकत्र कर सकते हैं।

डिफ़ॉल्ट त्रुटि विचारों को अनुकूलित करें

Django में कई HTTP त्रुटि कोड के लिए डिफ़ॉल्ट दृश्य और टेम्पलेट शामिल हैं। आप अपने रूट टेम्प्लेट डायरेक्टरी में निम्नलिखित टेम्प्लेट बनाकर डिफ़ॉल्ट टेम्प्लेट को ओवरराइड करना चाहते हैं: 404.html , 500.html , 403.html और 400.html । डिफ़ॉल्ट विचारों को 99% वेब अनुप्रयोगों के लिए पर्याप्त होना चाहिए, लेकिन यदि आप उन्हें अनुकूलित करना चाहते हैं, तो इन निर्देशों को देखें जिनमें डिफ़ॉल्ट टेम्पलेट्स के बारे में विवरण शामिल हैं: