Django साझा होस्टिंग, मॉडल एन

Django अनुप्रयोगों को एक * nix वातावरण में परिनियोजित करने के कई तरीके हैं। मैं मूल होने का नाटक नहीं करूँगा, बस सबसे अधिक-सबसे-सबसे साझा करूँगा।

परिचयात्मक स्थिति

पृष्ठभूमि:

• एक क्लाइंट (ग्राहक) - सर्वर पर सिस्टम में एक उपयोगकर्ता।
• सभी क्लाइंट प्रोजेक्ट एक फ़ाइल पदानुक्रम में हैं।
• Virtualenv अच्छा है और उपयोग करना चाहिए।
• Ftp बुराई है, हम आधुनिक साधनों (sftp) का उपयोग करते हैं।
• परियोजना प्रबंधन के लिए फाइलों की संख्या कम से कम होनी चाहिए।

प्रयुक्त सॉफ्टवेयर:

• nginx
• uwsgi
• क्रॉन
• virtualenv
• अधिभारित

और नेफ़िग़ इधर-उधर की अफवाह

अक्सर ऐसा होता है, डेवलपर्स के साथ-साथ उपयोगकर्ता / ग्राहक / ग्राहक भी अपनी परियोजनाओं के फ़ाइल ट्री तक पहुंच प्राप्त करना चाहते हैं (आप उन्हें अपनी पसंद के अनुसार कुछ भी कह सकते हैं), अर्थात्। “लगभग बाहरी लोग। इसका मतलब है कि सर्वर के डिस्क पर चारों ओर अफवाह फैलाने की संभावना के लिए तीसरे पक्ष के उपयोगकर्ताओं को सीमित करना एक अच्छा विचार है। पहली नज़र में, उपयोगकर्ता को अपने होम निर्देशिका में सीमित करने का विचार आता है। आपको इस आवेग के आगे नहीं झुकना चाहिए, क्योंकि आपके घर की निर्देशिका में उपयोगकर्ता राजा और भगवान है, और एक गलत कदम है और आप पिता परियोजना की निष्क्रियता को जन्म दे सकते हैं। इसलिए, आइए ट्रिक पर जाएं और निम्नलिखित पदानुक्रम बनाएं:

/home /client --      /client --    "client" /another_project /project /www-root /static /app1 /app2 manage.py settings.py django_wsgi.py ... /var /log --  nginx'a,      logrotate /tmp -- chmod 770 --    /run --      /client2 --      /client3 --       

उपयोगकर्ता "क्लाइंट" की होम निर्देशिका में अधिकार क्लाइंट है: क्लाइंट, बाकी निर्देशिकाएं, जब तक कि अन्यथा निर्दिष्ट न हो, रूट: क्लाइंट और कैमोड 750, क्रमशः। आपको क्लाइंट समूह में nginx उपयोगकर्ता को भी शामिल करना होगा ताकि nginx के पास प्रोजेक्ट के अंदर स्थिर फ़ाइलों तक पहुंच हो। सिस्टम में भी, एक sftponly समूह बनाएं जिसमें हम क्लाइंट शामिल करते हैं। Sshd config (/ etc / ssh / sshd_config) में निम्नलिखित जोड़ें:

 Match Group sftponly X11Forwarding no AllowAgentForwarding no AllowTcpForwarding no ChrootDirectory /home/%u ForceCommand internal-sftp 

और लाइन

 Subsystem sftp /usr/lib/misc/sftp-server 

के साथ बदलें

 Subsystem sftp internal-sftp 

नतीजतन, हमें एक ऐसी स्थिति मिलती है जब कोई उपयोगकर्ता sftp (उदाहरण के लिए, wincp का उपयोग करके) सर्वर पर लॉग इन करता है, अपने होम डायरेक्टरी में जाता है, एक स्तर तक जा सकता है, अपनी परियोजनाओं के बारे में घूम सकता है, लॉग देख सकता है। हालांकि, वह किसी भी महत्वपूर्ण निर्देशिका को बढ़ाने या हटाने में असमर्थ है (chmod 750 हालांकि)।

nginx - इस शब्द में कितना है

स्टैटिक कंटेंट डिलीवर करने और डायनामिक जेनरेशन से जुड़े मसलों को हल करने के लिए Nginx शायद सबसे बेहतर http- सर्वर है। हमारे मामले में, नग्नेक्स को यूवेसी-मॉड्यूल के साथ एक साथ इकट्ठा किया जाना चाहिए (मानक के रूप में आता है)। जब डिफ़ॉल्ट रूप से (कम से कम gentoo में) स्थापित किया जाता है, तो nginx / etc / nginx में इसके कॉन्फिगर को संग्रहीत करता है। हम इस परंपरा को नहीं तोड़ेंगे, और इसके विपरीत भी इसका उपयोग करने की कोशिश करेंगे। मुख्य nginx'a config (/etc/nginx/nginx.conf) में, http अनुभाग के अंत में लाइन जोड़ें

 include /etc/nginx/vhost.d/*.conf ; 

परिणामस्वरूप, हमारे पास प्रति प्रोजेक्ट एक कॉन्फ़िगरेशन फ़ाइल (/etc/nginx/vhost.d/project.conf) हो सकती है।
कुछ इस तरह:

 #uwsgi# USER client #uwsgi# PRJ cool_site.ru #uwsgi# HOME ~/../project #uwsgi# VE ~/.virtualenvs/project #uwsgi# SOCKET ../var/run/uwsgi-project #uwsgi# LOG ../var/log/uwsgi-project.log #uwsgi# PID ../var/run/uwsgi-project.pid #uwsgi# WORKERS 2 upstream wsgi_cluster__project { server unix:/home/client/var/run/uwsgi-project; } server { listen 80; server_name .cool_site.ru; charset utf8; autoindex off; root /home/client/project/www-root; access_log /home/client/var/log/nginx_access.log ; error_log /home/client/var/log/nginx_error.log error; location /static { root /home/client/project; expires 1d; } location / { try_files $uri @django; } location @django { uwsgi_pass wsgi_cluster__project; include uwsgi_params; } } 

# Uwsgi # से शुरू होने वाली पंक्तियों की व्याख्या nginx द्वारा टिप्पणियों के रूप में की जाएगी, हालाँकि, nust start script (जिसके बारे में नीचे चर्चा की गई है) इन पंक्तियों को अपने लिए निर्देश मानते हुए देखती है।

Nust - Nginx Uwsgi STarter

एक बार, जब uwsgi बस दिखाई देने लगा था, यह जानता था कि ऑपरेशन के दौरान कैसे गिरना है, इसमें "शाही" शासन नहीं था, लेकिन यह पहले से ही एक मांग के नरक में था - एक स्क्रिप्ट को जल्दबाजी में लिखने के लिए लिखा गया था, जो आमतौर पर एक ही कारण से नहीं मिलता है - वह काम कर रहा है। तो यह कैसे काम करता है और यह क्या करता है।
क्राउन पर नस्ट चलता है (क्रॉस्टेब-ई)

 */5 * * * * nust -s -c /etc/nust.conf 

आपकी कॉन्फ़िगरेशन फ़ाइल के साथ। कॉन्फ़िगरेशन फ़ाइल में दो खंड हैं, जिनमें से पहला सीधे nust'y से संबंधित है और इसे उपयोग करने वाले रास्तों और उपयोगिताओं को परिभाषित करता है, और दूसरा - uwsgi के लिए चूक।

 [nust] pstree = /usr/bin/pstree vhosts = /etc/nginx/vhost.d/*.conf uwsgi = /usr/bin/uwsgi uwsgi_def_args = --ini=/etc/nust.conf dbdir = /var/run kill = /bin/kill -s TERM kill_k9= /bin/kill -s KILL [uwsgi] master= disable-logging= vacuum= logfile-chown= chmod-socket=666 catch-exceptions= memory-report= 

आप सिस्टम में एनस्टस्ट निम्नानुसार स्थापित कर सकते हैं:

 sudo pip install nust 

"घुंघराले टिप्पणी" # uwsgi # का उपयोग करके nginx'a कॉन्फिगर में आप निम्नलिखित विकल्पों को ओवरराइड कर सकते हैं:

• श्रमिक - समानांतर वर्कफ़्लोज़ की संख्या
• MODULE - शुरू करने के लिए अजगर मॉड्यूल का नाम (django_wsgi.py)
• PRJ - परियोजना का नाम
• PID - वर्कफ़्लो ट्री की पीआईडी ​​फ़ाइल (var / run / uwsgi.pid)
• लॉग - uwsgi लॉग फ़ाइल का पथ (var / log / uwsgi.log)
• HARAKIRI - अधिकतम क्वेरी निष्पादन समय, सेकंड।
• MAX_REQ - संसाधित अनुरोधों की संख्या, जिसके बाद वर्कफ़्लो फिर से शुरू किया जाएगा

लेकिन इन विकल्पों की आवश्यकता है:

• USER - उपयोगकर्ता जिसमें से प्रोजेक्ट लॉन्च किया जाएगा
• घर - परियोजना की घर निर्देशिका (USER नहीं है!)
• VE - आभासी पर्यावरण का रास्ता (virtualenv का परिणाम)
• सॉकेट - जहां एक सॉकेट फ़ाइल बनाने के लिए। यदि निर्दिष्ट नहीं है, तो इसे अपस्ट्रीम सेक्शन से लिया जाएगा।

पथ तीन तरीकों से निर्दिष्ट किए जा सकते हैं:

• निरपेक्ष पथ एक स्लेश के साथ शुरू होता है
  (/ tmp)
• उपयोगकर्ता के घर निर्देशिका के सापेक्ष पथ
  (~ / gde-to / tam /)
• परियोजना घर निर्देशिका के सापेक्ष पथ
  (var / run / uwsgi.pid)

Uwsgi के तहत किसी भी अजगर कोड को शुरू करने के लिए, आपको एक तथाकथित मॉड्यूल की आवश्यकता होती है। Django चलाने के लिए, निम्न कोड django_wsgi.py में स्थित है:

 #!/usr/bin/env python # -*- coding: utf-8 -*- from __future__ import unicode_literals import os os.environ['DJANGO_SETTINGS_MODULE'] = 'settings' import django.core.handlers.wsgi application = django.core.handlers.wsgi.WSGIHandler() 

सिस्टम की स्टार्टअप लिपियों में नस्ट के लॉन्च को पंजीकृत करने की आवश्यकता नहीं है, क्योंकि क्राउन पर समय-समय पर नस्ट लॉन्च किया जाता है। सिर्फ प्रोजेक्ट्स शुरू करने के अलावा, नस्ट उनकी स्थिति पर नज़र रखता है (क्रैश, नहीं चल रहा है, चल रहा है, लेकिन प्रतिक्रिया नहीं करता है), साथ ही साथ nginx वर्चुअल होस्ट कॉन्फ़िगरेशन फ़ाइलों की स्थिति भी। यदि वर्चुअल होस्ट कॉन्फ़िगरेशन बदल दिया गया है, तो संबंधित प्रोजेक्ट को फिर से शुरू किया जाएगा।

एक आफ्टरवर्ड के बजाय

खैर, बस इतना ही। मुझे उम्मीद है कि मैं कुछ भी महत्वपूर्ण नहीं भूल गया हूं। आपका ध्यान देने के लिए धन्यवाद।