මට Nginx සහ Gunicorn වැනි දෙයක් අවශ්‍ය ඇයි?


236

මම පහත සඳහන් ප්‍රශ්නයට ඕනෑවට වඩා සරල පිළිතුරක් සොයමි. මම උත්සාහ කරන්නේ ගුනිකෝන් වැනි දෙයක් සමඟ එන්ජින්ක්ස් ක්‍රියා කරන ආකාරය පිළිබඳ පදනම් අවබෝධයක් ගොඩනැගීමට ය.

Nginx හි ජැන්ගෝ යෙදුම් යෙදවීමට මට Nginx සහ Gunicorn වැනි යමක් අවශ්‍යද?

එසේ නම්, ඇත්ත වශයෙන්ම HTTP ඉල්ලීම් හසුරුවන්නේ කුමක්ද?

ගීතා. මට Apache සහ mod_wsgi භාවිතා කිරීමට අවශ්‍ය නැත!


Apache සහ mod_wsgi යනු ඔබේ ජැන්ගෝ යෙදුම සහ http ඉල්ලීම් අතර පාලම ක්‍රියාත්මක කිරීමේ සරලම ක්‍රමය වන අතර එය නිෂ්පාදන පරිසරයකද ඉතා දක්ෂ වේ. බොහෝ සංවර්ධකයින් සඳහා, මෙයින් අදහස් කරන්නේ ඔවුන් දැන සිටියේ නම් 'අපාචේ එන්ජින්එක්ස් වලට වඩා හොඳයි', නමුත් 'බීඑච්ඒඑම් වීඑච්එස් වලට වඩා හොඳයි', අහෝ, ඩොග්මා රීති
මැජික්ලෑම්ප්

Answers:


339

ඕනෑවට වඩා සරල කිරීම: ඔබට පයිතන් ක්‍රියාත්මක කරන යමක් අවශ්‍ය නමුත් සියලු ආකාරයේ ඉල්ලීම් හැසිරවීමට පයිතන් හොඳම නොවේ.

[වියාචනය: මම ගුණිකෝන් සංවර්ධකයෙක්]

අඩු සරල කර ඇත: ඔබ භාවිතා කරන යෙදුම් සේවාදායකය කුමක් වුවත් (Gunicorn, mod_wsgi, mod_uwsgi, cherrypy) ඕනෑම ආකාරයක සුළු නොවන යෙදවීමකට ඔබගේ ජැන්ගෝ යෙදුම හැසිරවිය යුතු නොවන ඉල්ලීම් හසුරුවන උඩුමහලේ යමක් ඇත. එවැනි ඉල්ලීම්වල සුළු උදාහරණ වන්නේ ස්ථිතික වත්කම් (රූප / css / js) සේවය කිරීමයි.

මෙහි ප්‍රති results ලය වන්නේ සම්භාව්‍ය “තට්ටු තුනේ ගෘහ නිර්මාණ ශිල්පයේ” පළමු ස්ථර දෙකකට ය. එනම්, වෙබ් සේවාදායකය (ඔබේ නඩුවේ Nginx) රූප සහ ස්ථිතික සම්පත් සඳහා බොහෝ ඉල්ලීම් ඉටු කරනු ඇත. ගතිකව ජනනය කළ යුතු ඉල්ලීම් පසුව යෙදුම් සේවාදායකයට යවනු ලැබේ (ඔබේ උදාහරණයේ Gunicorn). (අනෙක් අතට, ස්ථර තුනෙන් තුනෙන් එකක් දත්ත සමුදායයි)

Ically තිහාසිකව ගත් කල, මෙම සෑම ස්ථරයක්ම වෙනම යන්ත්‍ර මත සත්කාරකත්වය සපයනු ඇත (තවද බොහෝ විට පළමු ස්ථර දෙකේ බහු යන්ත්‍ර තිබිය හැක, එනම්: 5 වෙබ් සේවාදායකයන් යෙදුම් සේවාදායකයන් දෙදෙනෙකුට ඉල්ලීම් යවන අතර එමඟින් එක් දත්ත සමුදායක් විමසයි).

නූතන යුගයේ දී අපට දැන් සියලු හැඩයන් සහ ප්‍රමාණයන්හි යෙදුම් තිබේ. සෑම සති අන්ත ව්‍යාපෘතියකටම හෝ කුඩා ව්‍යාපාරික වෙබ් අඩවියකටම බහු යන්ත්‍රවල අශ්වබල අවශ්‍ය නොවන අතර තනි පෙට්ටියක සතුටින් ක්‍රියාත්මක වේ. මෙය සත්කාරක විසඳුම් පෙළට නව ඇතුළත් කිරීම් ඇති කර තිබේ. සමහර විසඳුම් යෙදුම් සේවාදායකය වෙබ් සේවාදායකයට විවාහ කර දෙනු ඇත (Apache httpd + mod_wsgi, Nginx + mod_uwsgi, ආදිය). මෙම වෙබ් / යෙදුම් සේවාදායක සංයෝජනයන්ගෙන් එකක් ලෙස එකම යන්ත්‍රයක දත්ත සමුදාය සත්කාරකත්වය සැපයීම සාමාන්‍ය දෙයක් නොවේ.

දැන් ගුනිකෝන් සම්බන්ධයෙන් ගත් කල, අපි නිශ්චිත තීරණයක් ගත්තෙමු (රූබීගේ යුනිකෝන් වෙතින් පිටපත් කිරීම) එන්ජින්ක්ස් වෙතින් වෙන් වෙන්ව තබා ගැනීමට එන්ජින්ක්ස් හි ප්‍රොක්සි හැසිරීම මත රඳා සිටිමු. විශේෂයෙන්, ගුනිකෝන් කිසි විටෙකත් අන්තර්ජාලයෙන් සෘජුවම සම්බන්ධතා කියවන්නේ නැතැයි අපට උපකල්පනය කළ හැකි නම්, මන්දගාමී සේවාදායකයින් ගැන අපට කරදර විය යුතු නැත. මෙයින් අදහස් කරන්නේ ගුනිකෝන් සඳහා සැකසුම් ආකෘතිය ලැජ්ජා සහගත ලෙස සරල බවයි.

වෙන්වීම මඟින් ගුනිකෝන් පිරිසිදු පයිතන් වලින් ලිවීමට ඉඩ සලසයි. එමඟින් සංවර්ධන පිරිවැය අවම වන අතර කාර්ය සාධනය කෙරෙහි සැලකිය යුතු බලපෑමක් සිදු නොවේ. එමඟින් පරිශීලකයන්ට වෙනත් ප්‍රොක්සි භාවිතා කිරීමේ හැකියාව ද ලබා දේ (ඒවා නිවැරදිව බෆරය යැයි උපකල්පනය කරයි).

HTTP ඉල්ලීම සැබවින්ම හසුරුවන්නේ කුමක් ද යන්න පිළිබඳ ඔබගේ දෙවන ප්‍රශ්නයට, සරල පිළිතුර වන්නේ Gunicorn ය. සම්පූර්ණ පිළිතුර Nginx සහ Gunicorn යන දෙකම ඉල්ලීම හසුරුවයි. මූලික වශයෙන්, Nginx වෙත ඉල්ලීම ලැබෙනු ඇති අතර එය ගතික ඉල්ලීමක් නම් (සාමාන්‍යයෙන් URL රටා මත පදනම්ව) එය එම ඉල්ලීම Gunicorn වෙත ලබා දෙනු ඇත, එය එය ක්‍රියාවට නංවනු ඇත, පසුව Nginx වෙත ප්‍රතිචාරයක් ලබා දෙන අතර එමඟින් ප්‍රතිචාරය මුල් පිටපත වෙත යොමු කරයි. සේවාදායකයා.

ඉතින් වසා දැමීමේදී, ඔව්. නිසි ජැන්ගෝ යෙදවීම සඳහා ඔබට Nginx සහ Gunicorn යන දෙකම අවශ්‍ය වේ (හෝ ඊට සමාන දෙයක්). ඔබ විශේෂයෙන් එන්ජින්ක්ස් සමඟ ජැන්ගෝට සත්කාරකත්වය සැපයීමට බලාපොරොත්තු වන්නේ නම්, මම ගුනිකෝන්, මොඩ්_උස්ගි සහ සමහර විට චෙරිපී යන අය ගැන සොයා බලමි.


14
එවැනි සවිස්තරාත්මක පිළිතුරක් ලිවීමට කාලය ගැනීම ගැන ස්තූතියි! මෙම "තට්ටු තුනේ ගෘහ නිර්මාණ ශිල්පය" පිළිබඳ නිර්දේශිත කියවීමක් තිබේද?
am

5
නියම පිළිතුර, කෙසේ වෙතත් මන්දගාමී සේවාදායකයින් සමඟ ඇති ගැටලුව මට තේරෙන්නේ නැත.
මැඩ්ස් ස්කජර්න්

3
AdMadsSkjern මම මෙහි අනුමාන කරමි, නමුත් ඔබ සියලු සේවාදායකයින් වේගවත් යැයි උපකල්පනය කරන්නේ නම්, ඔබට ස්ථාවර සේවක ක්‍රියාවලීන් සංචිතයක් භාවිතා කළ හැකි අතර, බොහෝ හෝ සියල්ලන්ම සේවාදායකයෙකු එනතෙක් බලා සිටීම අවහිර වූ අවස්ථාව සඳහා කේත කිරීමට අවශ්‍ය නැත.
ජොනතන් හාර්ට්ලි


9
මගේ django යෙදුම json ට පමණක් සේවය කරයි කිසිදු ස්ථිතික අන්තර්ගතයක් මට තුවක්කුව සමඟ යා නොහැකි අතර nginx නැත
Sar009

34

මම මෙම පැහැදිලි කිරීම එහි සරලත්වයට කැමතියි:

Nginx බාහිර ලෝකයට මුහුණ දෙනු ඇත. එය මාධ්‍ය පද්ධතියෙන් (රූප, CSS, ආදිය) කෙලින්ම ගොනු පද්ධතියෙන් සේවය කරනු ඇත. කෙසේ වෙතත්, එයට ජැන්ගෝ යෙදුම් සමඟ කෙලින්ම කතා කළ නොහැක; එයට යෙදුම ක්‍රියාත්මක කිරීම, වෙබයෙන් ඉල්ලීම් පෝෂණය කිරීම සහ ප්‍රතිචාර දැක්වීම වැනි යමක් අවශ්‍ය වේ.

ඒක ගුනිකෝන්ගේ රැකියාව. Gunicorn විසින් යුනික්ස් සොකට් එකක් සාදනු ඇති අතර wsgi ප්‍රොටෝකෝලය හරහා nginx වෙත ප්‍රතිචාර දක්වනු ඇත - සොකට්ටුව දත්ත දෙපැත්තටම යවයි:

The outside world <-> Nginx <-> The socket <-> Gunicorn

https://gist.github.com/Atem18/4696071


1
අනෙක් අය කල්පනා කරන්නේ නම් එය සොකට් විය යුතු නැත.
අක්ෂේ

වෙනත් වචන වලින් කිවහොත්, wsgi සේවාදායකය යනු පයිතන් යෙදුම් ක්‍රියාත්මක කරන්නෙකු හා සමාන වන අතර එය ගතික අන්තර්ගත ඉල්ලීමක් ලබා ගන්නා අතර ප්‍රතිදානය ජනනය කිරීම සඳහා පයිතන් යෙදුම අමතයි. මේක හරිද?
රෝයි ලින්ග්

0

මම ඕනෑවට වඩා සරල පිළිතුරක් සොයමි ...

Nginx හි ජැන්ගෝ යෙදුම් යෙදවීමට මට Nginx සහ Gunicorn වැනි යමක් අවශ්‍යද?

එසේ නම්, ඇත්ත වශයෙන්ම HTTP ඉල්ලීම් හසුරුවන්නේ කුමක්ද?

ඕනෑවට වඩා සරල පිළිතුර:

ඔව්.

Nginx සහ Gunicorn යන දෙකම.

ඔබ Nginx හි යොදවා ඇති බැවින්, ඇත්ත වශයෙන්ම ඔබට Nginx අවශ්‍ය වේ.

ඔබ වෙබ් රාමුවක් වන ජැන්ගෝව යොදවා ඇති හෙයින්, ඔබට වෙබ් සේවාදායකය (එන්ජින්ක්ස්) සහ වෙබ් රාමුව (ජැන්ගෝ) අතර කතාවට බාධා කිරීමට යමක් අවශ්‍ය වේ. පයිතන් ලෝකයේ එවැනි දෙයක් WSGI සේවාදායකයක් ලෙස හැඳින්වේ (නමුත් එය මධ්‍යම භාණ්ඩයක් ලෙස සිතන්න), උදාහරණ ලෙස Gunicorn සහ uWSGI ඇතුළත් වේ. ඉල්ලීමක් හසුරුවන විට, Nginx විසින් ඉල්ලීම Gunicorn හෝ uWSGI වෙත යොමු කරයි, එමඟින් ජැන්ගෝ කේතය අමතා ප්‍රතිචාරය ලබා දෙයි.

මෙම ලේඛනය සහ පාවුල්ගේ පිළිතුර ඔබට එය වඩා හොඳින් ඉගෙන ගැනීමට උපකාරී වනු ඇත.


0

ගුනිකෝන් යනු සම්පත් නාස්තියකි. ඔබට ඉහළ ජැන්ගෝ මත තුවක්කුවක් ධාවනය කරනවා වෙනුවට වරායක ජැන්ගෝ සවන්දීමට ප්‍රොක්සි පාස් කළ හැකි අතර ඒ සියල්ලටම ඉහළින් නැවතත් එන්ජීඑන්එක්ස්. මිණුම් සලකුණු වලදී, මම සැලකිය යුතු වේගයකින් වැඩි වීමක් දැක ඇත්තෙමි. Nginx හට පහසුවෙන් ජැන්ගෝ වෙත සෘජු ඉල්ලීම් හැසිරවිය හැකිය. ගුනිකෝන් යනු සාමාන්‍ය මාර්ගයට වඩා ඉහළින් ඇති ගුවන් පාලමක් (සැබවින්ම මන්දගාමී ගුවන් පාලමකි). එය වාඩි වී ඔබේ සම්පත් අනුභව කරන අතර ඔබේ වෙබ් අඩවිය බලගන්වන බව ප්‍රකාශ කිරීමට උත්සාහ කරයි.

nginx මූලික වශයෙන් සියලු ඉල්ලීම් ආරක්ෂා කරන අතර ස්ථිතික ගොනු ඉල්ලීම් තනිවම හසුරුවයි (ඔබ එය එසේ වින්‍යාස කර ඇත්නම්). සියලු ගතික අන්තර්ගතයන් වෙනත් සේවාදායකයකට ප්‍රොක්සි කරයි (gunicorn / django).

ඉල්ලීම ඉල්ලුම් පත්‍රය වෙත යැවීම හැර ගුනිකෝර්න්ට වෙනත් ප්‍රයෝජනයක් නොමැත. එය ඔබට වීදුරුවලින් කෙලින්ම පානය කළ හැකි හෝ පිදුරු වලින් සීමිත වේගයකින් පානය කළ හැකි පිදුරු වැනි ය (මෙහි පානය කරන පුද්ගලයා ජැන්ගෝ වේ). එන්ජින්ක්ස් යනු ඔබට යුෂ වීදුරුව ගෙනා වේටර් ය.

මම මිණුම් සලකුණු කර මෙය සොයාගෙන ඇත - තුවක්කුව සමඟ: තුවක්කුවකින් තොරව 22k req / s: 34k req / s

ඔබේ වෙබ් අඩවියට අමතර බරක් අවශ්‍ය වේ.


3
ඔබ කතා කරන්නේ සංවර්ධන සේවාදායකය නිෂ්පාදනයේදී ක්‍රියාත්මක කිරීම ගැනද?
මයිකල් හැම්ප්ටන්

සංවර්ධන සේවාදායකය නිෂ්පාදන සේවාදායකයක් පිටුපස ධාවනය කළ හැකිය (nginx වැනි). මන්ද එය නිවැරදි ස්ථානයේ ඉල්ලීම් ලැබෙනු ඇති අතර නිෂ්පාදන සේවාදායකයා විසින් ආරක්ෂාව සහ කාර්යක්ෂමතාව හසුරුවනු ඇත. එය හරියට WSGI + flask භාවිතා කිරීම හා සමානයි. ඒ වෙනුවට ඔබට nginx + django භාවිතා කළ හැකිය (කිසිදු මිඩ්ල්වෙයාර් හොග් කිරීමකින් තොරව, තුවක්කුව වැනි). කරුණාකර සැකසුම අධික බරකින් පරීක්ෂා කරන්න, එවිට ඔබට වැටහෙනු ඇත.
ShadowDoom

3
github.com/django/channels/issues/142 (TLDR: එහි නරක අදහසක්)
igor
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.