Nginx؟ هدف، ویژگی‌ها، گزینه‌های تنظیمات - اینها مواردی هستند که هر توسعه‌دهنده وب باید با آنها آشنا باشد تا پیشرفت‌های خود را آزمایش کند.

بیایید یک کلمه در مورد nginx بگوییم

این ابزار دارای یک فرآیند اصلی و چندین فرآیند کارگری است. اولین مورد با خواندن و بررسی پیکربندی سروکار دارد. همچنین تحت کنترل او مدیریت فرآیندهای کاری است. وظیفه دومی پردازش درخواست های دریافتی است. Nginx از مدلی استفاده می کند که بر اساس رویدادها است. مکانیسم های خاص سیستم عامل نیز برای دستیابی به توزیع کارآمد درخواست ها به طور مستقیم بین فرآیندهای کارگر استفاده می شود. شماره آنها همیشه در فایل پیکربندی نشان داده شده است. با توجه به تعداد هسته‌های پردازنده‌ای که می‌توانید با آن‌ها کار کنید، مقدار می‌تواند ثابت یا به‌طور خودکار تنظیم شود. در nginx، سیستم و ماژول ها با استفاده از یک فایل پیکربندی پیکربندی می شوند. بنابراین، اگر نیاز به تغییر چیزی دارید، باید به دنبال آن باشید. معمولاً در دستورالعمل /etc/nginx قرار دارد (اما مسیر ممکن است در سیستم‌های دیگر تغییر کند) و پسوند .conf دارد.

راه اندازی، راه اندازی مجدد و لاگ

برای انجام این کار، باید فایل اجرایی را فعال کنید. راه اندازی سرور nginx تنها زمانی امکان پذیر است که در حال اجرا باشد. کنترل با فراخوانی فایل اجرایی با گزینه -s انجام می شود. برای این کار از ورودی زیر استفاده کنید:

سیگنال nginx -s

در این مورد، می توانید دستورات زیر را جایگزین کنید (باید از طرف کاربری باشد که ابزار را راه اندازی کرده است):

1. متوقف کردن. برای تکمیل سریع یک کار استفاده می شود.
2. بارگذاری مجدد دستور برای بارگیری مجدد فایل پیکربندی مورد نیاز است. نکته این است که هیچ تغییری در حین اجرای فایل اعمال نخواهد شد. و برای اعمال آنها، راه اندازی مجدد مورد نیاز است. به محض دریافت این سیگنال، فرآیند اصلی شروع به بررسی نحو صحیح فایل پیکربندی می کند و سعی می کند دستورالعمل ها را در آنجا اعمال کند. در صورت عدم موفقیت، تغییرات را برمی گرداند و با تنظیمات قبلی کار می کند. اگر همه چیز به خوبی پیش رفت، فرآیندهای کارگری جدید راه اندازی می شوند و موارد قدیمی برای تکمیل درخواست ارسال می شوند.
3. ترک برای خاموش شدن صاف استفاده می شود. اگر لازم باشد منتظر بمانید تا درخواست‌های فعلی به پایان برسد، استفاده می‌شود.
4. دوباره باز کنید. فایل های گزارش را ببندید و باز کنید.

با استفاده از خدمات شهری

فرآیندها را نیز می توان با استفاده از ابزارهای یونیکس پیکربندی کرد (ابزار kill به عنوان مثال در نظر گرفته می شود). آنها معمولاً از مکانیسم ارسال سیگنال به فرآیند به طور مستقیم با داده ها استفاده می کنند. آنها با یک شناسه مرتبط هستند. این داده ها در فایل nginx.pid ذخیره می شوند. فرض کنید به فرآیند شماره 134 علاقه مندیم. سپس برای تکمیل بدون مشکل، باید اطلاعات زیر را ارسال کنیم:

kill -s QUIT 1628

فرض کنید می خواهیم لیستی از تمام فایل های در حال اجرا را ببینیم. ما برای این کار از ابزار ps استفاده می کنیم. دستور به شکل زیر خواهد بود:

ps-ax | grep nginx

یعنی همانطور که می بینید هنگام استفاده از ابزارهای اضافی نشان داده می شود که برنامه آن است که در حال انجام است. حالا بیایید روی نحوه انجام تنظیمات nginx تمرکز کنیم.

ساختار فایل پیکربندی

نصب و پیکربندی nginx شامل کار با ماژول ها است. آنها با استفاده از دستورالعمل هایی که در فایل پیکربندی مشخص شده اند پیکربندی می شوند. آنها ساده و مسدود هستند. دستورات نوع اول شامل نام و پارامترهایی است که با فاصله از هم جدا شده اند و انتهای آنها با نقطه ویرگول - (;) نشان داده می شود. بلوک ساختار مشابهی دارد. اما در این بخشنامه، به جای پایان، مجموعه ای از دستورالعمل های اضافی وجود دارد که در بریس های فرفری ((دستورالعمل)) قرار می گیرند. اگر امکان قرار دادن نام ها و پارامترهای سایر فرآیندها در آنها وجود داشته باشد، چنین ساختارهایی قبلاً زمینه نامیده می شوند. به عنوان مثال می توان به http، موقعیت مکانی و سرور اشاره کرد.

ارائه محتوای ثابت

این یکی از مهمترین وظایفی است که پیکربندی nginx با آن روبرو است. توزیع محتوای آماری به معنای تصاویر و صفحات HTML (نه پویا) است. بیایید بگوییم که برای راه اندازی یک خوشه nix nginx به یک کار یک بار مصرف نیاز داریم. آیا انجام این کار سخت است؟ نه، و بیایید به یک مثال نگاه کنیم. قبل از اقدام به آن، لازم است شرایط مشکل را به تفصیل بیان کنید. بنابراین، بسته به درخواست ها، فایل ها از دایرکتوری های محلی مختلف می آیند. بنابراین، در /data/www ما اسناد HTML داریم. و دایرکتوری /data/images حاوی تصاویر است. پیکربندی بهینه nginx در این مورد نیاز به ویرایش فایل پیکربندی دارد که در آن باید بلوک سرور را در http پیکربندی کنید. از دو مکان نیز برای پشتیبانی استفاده خواهد شد.

پیاده سازی: سرور

بنابراین، برای شروع، باید خود دایرکتوری ها را ایجاد کنیم و فایل هایی با پسوندهای لازم را در آنها قرار دهیم (شما باید محتوا را به html اضافه کنید). سپس فایل پیکربندی را باز می کنیم. به‌طور پیش‌فرض، از قبل دارای چندین بلوک سرور است که اکثراً نظر داده می‌شوند. برای بهترین نتایج، این فرآیند باید برای تمام اجزای پیش فرض تکرار شود. سپس یک بلوک سرور جدید با کد زیر اضافه می کنیم:

فایل پیکربندی می تواند با چندین بلوک از این دست کار کند. اما آنها باید در نام و پورت های خود که از طریق آنها داده ها دریافت می شود متفاوت باشند.

اجرا: مکان

تعریف شده در داخل سرور:

وجود علامت "/" برای مقایسه داده های دریافتی و دیدن اینکه آیا چنین آدرسی از درخواست پردازش شده در اینجا وجود دارد ضروری است. اگر مشکلی وجود ندارد، مسیر / داده / www را به فایل ضروری که در این سیستم محلی قرار دارد مشخص می کنیم. اگر یک تطابق با چندین بلوک وجود داشته باشد، یکی با طولانی ترین پیشوند انتخاب می شود. در مثال بالا، طول آن برابر با یک است، یعنی فقط در صورت عدم وجود "رقیب" از آن استفاده می شود. حالا بیایید آن را بهبود ببخشیم:

مکان /تصاویر/ (

همانطور که می توانید بگویید، ما به دنبال تصاویر هستیم. و اکنون بیایید تمام پیشرفت‌هایی را که قبلاً بودند ترکیب کنیم، و پیکربندی در حال حاضر به این صورت است:

مکان /تصاویر/ (

این یک نسخه کارآمد است که اتفاقاً استاندارد است. اگر به آدرس http://localhost/ بروید، این سرور به راحتی در رایانه محلی قابل دسترسی است. همه اینها چگونه کار خواهد کرد؟

مثال چگونه کار می کند

بنابراین، هنگامی که درخواست‌هایی وارد می‌شوند که با /images شروع می‌شوند، سرور فایل‌هایی را از دایرکتوری مربوطه برای کاربر ارسال می‌کند. اگر وجود نداشته باشد، اطلاعاتی که نشان دهنده خطای 404 است منتقل می شود. اگر nginx روی رایانه محلی پیکربندی شده باشد، پس از درخواست http://localhost/images/example.png، فایلی را دریافت خواهیم کرد که مکان آن /data/ است. images/example.png. هنگام تعیین یک کاراکتر "/"، جستجو در فهرست /data/www انجام می شود. اما ما فقط تنظیمات را تغییر دادیم. برای اینکه شروع به کار کند، باید راه اندازی مجدد شود. برای این کار از دستور nginx -s reload استفاده کنید. در مواردی که عملکرد عادی امکان پذیر نیست، در فایل های error.log و access.log واقع در دستورالعمل /usr/local/nginx/logs، می توانید علت نقص را جستجو کنید.

ایجاد یک پروکسی سرور ساده

می توان در مورد nginx گفت - پیکربندی این شی یکی از کاربردهای رایج است (و اتفاقاً بسیار آسان). از اصل سروری استفاده می کند که درخواستی را دریافت می کند و سپس آنها را به سایت های ضروری هدایت می کند. پس از آن، پاسخی از آنها انتظار می رود که آنها را به سمت تعیین کننده هدایت می کند. بنابراین بیایید به مثالی از ایجاد یک نقطه پایه نگاه کنیم. درخواست های کاربر را رسیدگی می کند و تصاویری را از دایرکتوری محلی به آنها ارائه می دهد. بنابراین، سرور دیگری را با محتوای زیر به بلوک http اضافه کنید:

و حالا بیایید آن را برای شما رمزگشایی کنیم: یک سرور ساده در حال ایجاد است. گوش می دهد گوش را مشخص نکنید، سرور در 80 اجرا می شود. تمام درخواست های داخل فایل سیستم محلی که به دایرکتوری /data/up1 هدایت می شوند نمایش داده می شوند (البته قبل از این باید ایجاد شود). برای اینکه بتوانید آن را بررسی کنید، باید فایل index.html را در آنجا قرار دهید. با قرار دادن دستور root در زمینه سرور، می توانیم تحت هر شرایطی از مکان استفاده کنیم (زیرا محدودیت های دسترسی حذف می شوند). اکنون ما روی ایجاد یک سرور پروکسی کار می کنیم. برای کارکرد آن، به دستور proxy_pass نیاز داریم، که پروتکل، نام و پورت شی به عنوان پارامتر مشخص می‌شود (برای یک اتصال محلی، شبیه http://localhost:8080 خواهد بود). نتیجه زیر را دریافت خواهید کرد:

proxy_pass http://localhost:8080;

مکان /تصاویر/ (

اگر به کد نگاه کنید و آن را تجزیه و تحلیل کنید، ممکن است متوجه شوید که بلوک مکان دوم تغییر کرده است. بنابراین، در این مورد، می تواند با پسوندهای تصویر معمولی کار کند. به روشی کمی متفاوت، می توان آن را به صورت زیر نمایش داد:

مکان ~ \.(gif|jpg|png)$ (

root /data/images;

پیکربندی سرور پروکسی حاصل به صورت زیر است:

proxy_pass http://localhost:8080/;

مکان ~ \.(gif|jpg|png)$ (

root /data/images;

درخواست هایی را که پسوندهای مشخص شده را در انتها دارند فیلتر کرده و برای شخصی که فایل ها را درخواست کرده است ارسال می کند. فراموش نکنید که اگر می خواهید فایل پیکربندی را بررسی کنید، باید آن را دوباره بارگذاری کنید. و باور کنید، این ساده ترین راه اندازی nginx است. اگر فایل پیکربندی سرور Vkontakte یا یک شرکت بزرگ دیگر را باز کنید، کد آنها بیشتر از کلمات در این مقاله خواهد بود.

و دیگران). نسخه فعلی، 0.6.x، از نظر قابلیت اطمینان پایدار در نظر گرفته می شود، در حالی که نسخه های منتشر شده از شاخه 0.7 ناپایدار در نظر گرفته می شوند. در عین حال، مهم است که توجه داشته باشید که عملکرد برخی از ماژول ها تغییر می کند، در نتیجه ممکن است دستورالعمل ها نیز تغییر کنند، بنابراین سازگاری عقب مانده در nginx قبل از نسخه 1.0.0 تضمین نمی شود.

چرا nginx اینقدر خوب است و چرا مدیران پروژه های با بارگذاری بالا آن را بسیار دوست دارند؟ چرا فقط از آپاچی استفاده نمی کنید؟

چرا آپاچی بد است؟

ابتدا باید نحوه عملکرد سرورهای شبکه را به طور کلی توضیح دهیم. کسانی که با برنامه نویسی شبکه آشنا هستند می دانند که اساساً سه مدل از عملکرد سرور وجود دارد:

1. متوالی. سرور یک سوکت گوش دادن را باز می کند و منتظر می ماند تا یک اتصال ظاهر شود (در حالی که منتظر است، در حالت مسدود است). هنگامی که یک اتصال می رسد، سرور آن را در همان زمینه مدیریت می کند، اتصال را می بندد و دوباره منتظر اتصال می ماند. بدیهی است که این به دور از بهترین راه است، به خصوص زمانی که کار با مشتری زمان زیادی می برد و ارتباطات زیادی وجود دارد. علاوه بر این، مدل سریال دارای معایب بسیار بیشتری است (مثلاً عدم امکان استفاده از چندین پردازنده) و در شرایط واقعی عملاً از آن استفاده نمی شود.
2. چند فرآیندی (چند رشته ای). سرور یک سوکت گوش دادن را باز می کند. هنگامی که یک اتصال می رسد، آن را می پذیرد، پس از آن یک فرآیند یا رشته جدید ایجاد می کند (یا از مجموعه موارد از پیش ساخته شده می گیرد) که می تواند برای مدت زمان طولانی خودسرانه با اتصال کار کند و در پایان کار، خاتمه یا بازگشت به استخر. در همین حال، موضوع اصلی آماده پذیرش یک اتصال جدید است. این محبوب ترین مدل است زیرا اجرای آن نسبتاً آسان است، امکان انجام محاسبات پیچیده و طولانی را به ازای هر مشتری فراهم می کند و از تمام پردازنده های موجود استفاده می کند. نمونه ای از کاربرد آن وب سرور آپاچی است. با این حال، این رویکرد جنبه‌های منفی خود را دارد: تعداد زیادی از اتصالات همزمان، رشته‌ها (یا بدتر از آن، فرآیندها) زیادی ایجاد می‌کنند، و سیستم عامل منابع زیادی را برای سوئیچ‌های زمینه صرف می‌کند. به خصوص زمانی که مشتریان در پذیرش محتوا بسیار کند هستند بسیار بد است. در نهایت با صدها رشته یا فرآیند مواجه می‌شوید که فقط مشغول ارسال داده‌ها به کلاینت‌های کند می‌شوند، که بار اضافی روی زمان‌بندی سیستم‌عامل ایجاد می‌کند، تعداد وقفه‌ها را افزایش می‌دهد و حافظه زیادی را مصرف می‌کند.
3. سوکت های غیر مسدود کننده / دستگاه حالت. سرور در یک رشته کار می کند، اما از سوکت های غیر مسدود کننده و مکانیزم نظرسنجی استفاده می کند. آن ها سرور، در هر تکرار حلقه بی نهایت، از همه سوکت ها سوکتی را انتخاب می کند که با استفاده از تماس select () آماده دریافت / ارسال داده است. پس از انتخاب سوکت، سرور داده‌ها را به آن ارسال می‌کند یا آنها را می‌خواند، اما منتظر تأیید نمی‌ماند، بلکه به حالت اولیه می‌رود و منتظر یک رویداد در سوکت دیگری می‌شود یا رویداد بعدی را پردازش می‌کند که در آن رویداد رخ داده است. پردازش قبلی این مدل از نظر استفاده از CPU و حافظه بسیار کارآمد است، اما پیاده سازی آن بسیار پیچیده است. علاوه بر این، در این مدل، پردازش یک رویداد در یک سوکت باید بسیار سریع باشد - در غیر این صورت، رویدادهای زیادی در صف جمع می‌شوند و در نهایت سرریز می‌شوند. این مدلی است که nginx روی آن کار می کند. علاوه بر این، به شما امکان می دهد چندین فرآیند کارگری (به اصطلاح کارگران) را اجرا کنید. می تواند از چندین پردازنده استفاده کند.

بنابراین، وضعیت زیر را تصور کنید: 200 مشتری به یک سرور HTTP با یک کانال 1 گیگابیت بر ثانیه با یک کانال 256 کیلوبیت بر ثانیه متصل می شوند:

در مورد آپاچی چه اتفاقی می افتد؟ 200 رشته/فرآیند ایجاد می‌شود که محتوا را نسبتاً سریع تولید می‌کند (این محتوا می‌تواند هم صفحات پویا و هم فایل‌های استاتیک باشد که از دیسک خوانده می‌شوند)، اما به آرامی آن را به مشتریان می‌دهند. سیستم عامل باید با دسته ای از رشته ها و مسدود کردن ورودی/خروجی مقابله کند.

Nginx در چنین شرایطی یک مرتبه کمتر از سیستم عامل و منابع حافظه برای هر اتصال هزینه می کند. با این حال، در اینجا یک محدودیت مدل شبکه nginx آشکار می شود: نمی تواند محتوای پویا در درون خود تولید کند، زیرا این باعث ایجاد قفل در داخل nginx می شود. طبیعتاً یک راه حل وجود دارد: nginx می تواند چنین درخواست هایی را (برای تولید محتوا) به هر وب سرور دیگری (مثلاً همان آپاچی) یا یک سرور FastCGI پروکسی کند.

مکانیسم عملکرد بسته نرم افزاری nginx را به عنوان سرور "اصلی" و آپاچی را به عنوان سروری برای تولید محتوای پویا در نظر بگیرید:

Nginx اتصال یک کلاینت را می پذیرد و کل درخواست را از آن می خواند. در اینجا لازم به ذکر است که تا زمانی که nginx کل درخواست را نخواند، آن را به "پردازش" نمی دهد. به همین دلیل، تقریباً همه نشانگرهای پیشرفت آپلود فایل معمولاً "شکست می‌خورند" - با این حال، می‌توان آنها را با استفاده از ماژول upload_progress شخص ثالث برطرف کرد (این به اصلاح برنامه نیاز دارد).

پس از اینکه nginx کل پاسخ را خواند، یک اتصال به آپاچی باز می کند. دومی کار خود را انجام می دهد (محتوای پویا تولید می کند)، پس از آن پاسخ خود را به nginx می دهد، که آن را در حافظه یا یک فایل موقت بافر می کند. در همین حال، آپاچی منابع را آزاد می کند. علاوه بر این، nginx به آرامی محتوا را در اختیار مشتری قرار می دهد، در حالی که نسبت به آپاچی، منابع بزرگتری را صرف می کند.

این طرح frontend + backend (frontend + backend) نامیده می شود و اغلب استفاده می شود.

نصب و راه اندازی

زیرا nginx تازه شروع کرده است، مشکلاتی در مورد بسته های باینری وجود دارد، بنابراین آماده باشید تا خودتان آن را کامپایل کنید. معمولاً هیچ مشکلی در این مورد وجود ندارد، فقط باید خروجی دستور ./configure --help را با دقت بخوانید و گزینه های کامپایل مورد نیاز خود را انتخاب کنید، به عنوان مثال:

./پیکربندی\
--prefix=/opt/nginx-0.6.x \ # پیشوند نصب
--conf-path=/etc/nginx/nginx.conf \ # محل فایل پیکربندی
--pid-path=/var/run/nginx.pid \ # ... و pid-file
--user=nginx \ # نام کاربری که nginx تحت آن اجرا می شود
--with-http_ssl_module --with-http_gzip_static_module --with-http_stub_status_module \ # لیست مورد نیاز
—without-http_ssi_module —without-http_userid_module —without-http_autoindex_module —without-http_geo_module —without-http_referer_module —without-http_memcached_module —without-http_nedule_unimitary_module …

پس از پیکربندی، باید استاندارد make && make install را اجرا کنید، پس از آن می توانید از nginx استفاده کنید.

از طرف دیگر، در جنتو می‌توانید از یک ebuild از درخت پورت‌های استاندارد استفاده کنید. در RHEL/CentOS از طریق مخزن epel (حاوی nginx 0.6.x) یا srpm برای نسخه 0.7، که می توانید از اینجا دانلود کنید: http://blogs.mail.ru/community/nginx ; در دبیان، می توانید از بسته nginx از شاخه ناپایدار استفاده کنید.

فایل پیکربندی

فایل پیکربندی nginx بسیار مفید و شهودی است. معمولاً nginx.conf نامیده می شود و در صورتی که مکان در حین کامپایل بازنویسی نشده باشد در $prefix/conf/ قرار می گیرد. من دوست دارم آن را در /etc/nginx/ قرار دهم، و توسعه دهندگان تمام بسته های ذکر شده در بالا نیز همین کار را می کنند.

ساختار فایل پیکربندی به صورت زیر است:

کاربر nginx; # نام کاربری که حقوق nginx با آن اجرا می شود
worker_processes 1; # تعداد فرآیندهای کارگری
مناسبت ها (
<…># این بلوک مکانیسم نظرسنجی مورد استفاده (به زیر مراجعه کنید) و حداکثر تعداد اتصالات ممکن را مشخص می کند
}

http(
<глобальные директивы http-сервера, например настройки таймаутов и т.п.>;
<почти все из них можно переопределить для отдельного виртуального хоста или локейшена>;

# توضیحات سرورها (این همان چیزی است که VirtualHost در آپاچی نامیده می شود)
سرور(
# آدرس و نام سرور
گوش کن *:80;
نام سرور aaa.bbb;

<Директивы сервера. Здесь обычно указывают расположение докуменов (root), редиректы и переопределяют глобальные настройки>;

# و به این ترتیب می توانید مکان را تعریف کنید، که برای آن می توانید تقریباً همه دستورالعمل های مشخص شده در سطوح جهانی تر را دوباره تعریف کنید.
مکان /abcd/ (
<директивы>;
}
# متناوباً، می‌توانید مکانی را با یک عبارت منظم انجام دهید، مانند:
مکان ~ \.php$ (
<директивы>;
}
}

# سرور دیگر
سرور(
گوش کن *:80;
نام سرور ccc.bbb;

<директивы>
}
}

توجه داشته باشید که هر دستورالعمل باید با نقطه ویرگول خاتمه یابد.
پروکسی معکوس و FastCGI

بنابراین، در بالا به مزایای طرح frontend + backend نگاه کردیم، نصب، ساختار و نحو فایل پیکربندی را فهمیدیم، اکنون بیایید نحوه اجرای پروکسی معکوس در nginx را بررسی کنیم.

و خیلی ساده! به عنوان مثال مانند این:

محل / (
proxy_pass http://1.2.3.4:8080;
}

در این مثال، تمام درخواست‌هایی که به مکان / می‌رسند به پورت 8080 سرور 1.2.3.4 پراکسی می‌شوند. این می‌تواند آپاچی یا هر سرور http دیگری باشد.

با این حال، چندین ظرافت در رابطه با این واقعیت وجود دارد که برنامه در نظر می‌گیرد که اولاً، همه درخواست‌ها از یک آدرس IP به آن می‌رسند (که می‌توان به عنوان مثال، تلاش برای حمله DDoS یا حدس زدن رمز عبور در نظر گرفت) و ثانیاً ، در نظر بگیرید که روی هاست 1.2.3.4 و پورت 8080 اجرا می شود (به ترتیب، تغییر مسیرهای نادرست و پیوندهای مطلق ایجاد کنید). برای جلوگیری از این مشکلات بدون نیاز به بازنویسی برنامه، پیکربندی زیر را راحت می دانم:
Nginx به رابط خارجی در پورت 80 گوش می دهد.

اگر باطن (مثلاً آپاچی) در همان میزبان nginx قرار دارد، در پورت 80 در 127.0.0.1 یا برخی از آدرس های IP داخلی دیگر "گوش می دهد".

پیکربندی nginx در این مورد به صورت زیر است:

سرور(
گوش کن 4.3.2.1:80;
# هدر Host و X-Real-IP: را برای هر درخواست ارسال شده به backend تنظیم کنید
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header میزبان $host:$proxy_port;
# یا "proxy_set_header Host $host;" اگر برنامه به همه پیوندها اضافه شود:80
}

برای اینکه برنامه بتواند بین آدرس های IP بازدیدکنندگان تمایز قائل شود، باید ماژول mod_extract_forwarded را قرار دهید (اگر توسط سرور آپاچی اجرا شده باشد)، یا برنامه را طوری تغییر دهید که اطلاعات مربوط به آدرس IP کاربر را از X- بگیرد. هدر واقعی IP HTTP.

یکی دیگر از گزینه های Backend استفاده از FastCGI است. در این مورد، پیکربندی nginx چیزی شبیه به این خواهد بود:

سرور(
<…>

# مکانی که درخواست های اسکریپت های php در آن قرار می گیرند
مکان ~ .php$ (
fastcgi_pass 127.0.0.1:8888; # آدرس و پورت سرور fastcgi را تعیین کنید،
fastcgi_index index.php; # ... فایل فهرست

# و برخی از پارامترهایی که باید به سرور fastcgi ارسال شوند تا بفهمد کدام اسکریپت و با چه پارامترهایی باید اجرا شود:
fastcgi_param SCRIPT_FILENAME /usr/www/html$fastcgi_script_name; # نام اسکریپت
fastcgi_param QUERY_STRING $query_string; # رشته پرس و جو
# و پارامترهای پرس و جو:
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;
}

# با توجه به این واقعیت که مکان های عبارات منظم دارای "اولویت" بالایی هستند، تمام درخواست های غیر php به اینجا می روند.

محل / (
root /var/www/html/
}

استاتیک

برای اینکه باطن کمتر بارگیری شود، بهتر است فایل های استاتیک را فقط از طریق nginx بدهید - بهتر با این کار کنار می آید، زیرا. به طور قابل توجهی منابع کمتری را برای هر درخواست صرف می کند (نیازی به ایجاد یک فرآیند جدید نیست، و فرآیند nginx معمولاً حافظه کمتری مصرف می کند و بسیاری از اتصالات می توانند ارائه شوند).

در فایل کانفیگ به صورت زیر است:

سرور(
گوش کن *:80;
server_name myserver.com;

محل / (
proxy_pass


">http://127.0.0.1:80;

}

# فرض کنید همه فایل های استاتیک در فایل / هستند
مکان /فایل/ (
root /var/www/html/; # مسیر fs را مشخص کنید
14 روز منقضی می شود. # هدر Expires را اضافه کنید:
error_page 404 = @back; # و اگر فایل پیدا نشد، آن را به مکان نامگذاری شده @back ارسال کنید
}

# درخواست از فایل های / که هیچ فایلی برای آنها یافت نشد به باطن ارسال می شود و می تواند فایل مورد نظر را ایجاد کند یا یک پیام خطای زیبا نشان دهد.
مکان@بازگشت(
proxy_pass
»title=»http://127.0.0.1:80;

">http://127.0.0.1:80;

}

اگر تمام استاتیک در یک دایرکتوری خاص قرار نمی گیرد، از عبارت منظم استفاده کنید:

مکان ~* ^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|wav|bmp|rtf |js)$ (
# مشابه با بالا، فقط تمام درخواست هایی که به یکی از پسوندهای مشخص شده ختم می شوند در این مکان قرار می گیرند
root /var/www/html/;
error_page 404 = @back;
}

متأسفانه، nginx مدیریت فایل های ناهمزمان را پیاده سازی نمی کند. به عبارت دیگر، nginx worker در عملیات I/O مسدود شده است. بنابراین اگر فایل های ثابت زیادی دارید و به خصوص اگر از دیسک های مختلف خوانده می شوند، بهتر است تعداد پردازش های کارگر را افزایش دهید (تا تعداد 2 تا 3 برابر بیشتر از تعداد کل هدهای روی دیسک). دیسک). این البته منجر به افزایش بار روی سیستم عامل می شود، اما به طور کلی عملکرد افزایش می یابد. برای کار با مقدار معمولی استاتیک (تعداد بسیار زیاد فایل های نسبتاً کوچک: CSS، جاوا اسکریپت، تصاویر)، یک یا دو فرآیند کارگر کافی است.

ادامه دارد

پیوندها

در اینجا می توانید اطلاعات بیشتری در مورد nginx بیابید:

Nginx یک وب سرور و پروکسی ایمیل است که از سال 2004 در دسترس عموم قرار گرفته است. توسعه این پروژه در سال 2002 آغاز شد، در زبان روسی این نام شبیه موتور ex به نظر می رسد. Nginx به دلیل خلق دستان یک برنامه نویس معروف، ایگور سیسوف، در ابتدا برای شرکت Rambler در نظر گرفته شده بود. برای سیستم عامل های متعلق به گروه یونیکس طراحی شده است. مونتاژ با موفقیت بر روی OpenBSD، FreeBSD، Linux، Mac OS X، Solaris آزمایش شده است. در پلتفرم ویندوز مایکروسافت، Nginx با ظهور نسخه 0.7.52 اسمبلی باینری شروع به کار کرد.

آمار مارس 2011 نشان می دهد که تعداد سایت هایی که توسط Nginx ارائه می شود از مرز 22 میلیون عبور کرده است. امروزه Nginx توسط پروژه های معروفی مانند Rambler، Begun، Yandex، SourceForge.net، WordPress.com، vkontakte.ru و دیگران استفاده می شود. همراه با lighttpd، Nginx برای ارائه محتوای استاتیک تولید شده توسط یک برنامه وب "ناراحت کننده" که "تحت اختیار" یک وب سرور دیگر اجرا می شود استفاده می شود.
اما قبل از پرداختن به ویژگی‌های کاربردی Nginx، به یاد داشته باشید که وب سرور به طور کلی و سرور پروکسی به طور خاص چیست.

وب سرور و سرور پروکسی

وب سرورسروری است که درخواست های HTTP را از مرورگرهای وب و سایر کلاینت ها دریافت می کند و پاسخ های HTTP را برای آنها صادر می کند. دومی معمولاً با یک صفحه HTML، جریان رسانه، تصویر، فایل یا داده های دیگر نشان داده می شود. وب سرور هم به عنوان نرم افزاری که عملکرد وب سرور را انجام می دهد و هم سخت افزار درک می شود. تبادل داده ها و اطلاعات درخواستی از طریق پروتکل HTTP انجام می شود.

لیست عملکردهای اضافی سرورهای وب شامل: مجوز و تأیید اعتبار کاربران، ثبت دسترسی آنها به منابع، پشتیبانی HTTPS برای امنیت سوئیچینگ با مشتریان و موارد دیگر است. متداول ترین وب سرور مورد استفاده در سیستم عامل های مشابه یونیکس آپاچی است. خط سوم در لیست ترجیحات مشتری در حال حاضر توسط Nginx اشغال شده است.

سرور پروکسیبه مشتریان اجازه می دهد تا درخواست های جستجو برای خدمات شبکه را به صورت غیر مستقیم ارائه دهند. یعنی سروری است که در هدایت درخواست های مشتری به سرورهای دیگر تخصص دارد. با اتصال به یک سرور پراکسی و درخواست منبعی که در سرور دیگری قرار دارد، مشتری این توانایی را دارد که ناشناس بماند و از رایانه در برابر حملات شبکه محافظت کند. سرور پروکسی داده های درخواستی را یا از حافظه پنهان خود (در صورت وجود) یا با دریافت آنها از سرور مشخص شده برای مشتری صادر می کند. در برخی موارد (برای دستیابی به اهداف فوق)، پاسخ سرور و همچنین درخواست مشتری توسط پروکسی سرور قابل تغییر است.

ساده ترین سرور پروکسی Network Address Translator یا NAT است. در سال 2000، پروکسی NAT در توزیع ویندوز ساخته شد. سرورهای پروکسی مانند هر پدیده ای دو روی سکه دارند، یعنی هم می توان از آنها برای خیر و هم برای بد استفاده کرد. به عنوان مثال، با کمک آنها، کسانی که از تحریم به دلیل اقدامات ناشایست خود در شبکه می ترسند، آدرس IP خود را پنهان می کنند ...

محدوده عملکردی Nginx:

• نگهداری سرور فایل های فهرست، پرس و جوهای استاتیک، تولید توصیفگرهای کش فایل باز، لیست فایل ها.
• پروکسی تسریع شده، توزیع بار اولیه، تحمل خطا.
• پشتیبانی از کش در طول پروکسی سریع و FastCGI.
• پشتیبانی از FastCGI (شتاب داده شده) و سرورهای memcached.
• مدولار بودن، فیلترها، از جمله "رزومه" (محدوده بایت) و فشرده سازی (gzip).
• احراز هویت HTTP، پاسخ های تکه تکه شده، فیلتر SSI.
• اجرای موازی چندین درخواست فرعی در صفحه، پردازش شده از طریق FastCGI یا یک پروکسی در فیلتر SSI.
• پشتیبانی StartTLS و SSL.
• توانایی پشتیبانی از پرل تعبیه شده؛
• احراز هویت ساده (USER/PASS، LOGIN)؛
• هدایت مجدد سرور (پراکسی IMAP/POP3) کاربر به باطن IMAP/POP3 با استفاده از یک سرور احراز هویت خارجی (HTTP).

برای کسانی که با این اصطلاح "روی شما" نیستند، ممکن است شرح عملکرد Nginx بسیار مبهم به نظر برسد. اما وقتی نوبت به راه هایی برای استفاده خاص از این وب سرور می رسد، به تدریج شروع به از بین رفتن خواهد کرد.

معماری و پیکربندی

Worker در Nginx بسیاری از اتصالات را به طور همزمان پردازش می کند و برای آنها تماس هایی را با سیستم عامل (سیستم عامل) epoll (Linux)، انتخاب و kqueue (FreeBSD) فراهم می کند. داده های دریافتی از مشتری توسط ماشین حالت تجزیه می شود. درخواست تجزیه شده توسط زنجیره ای از ماژول های مشخص شده توسط پیکربندی پردازش می شود. شکل‌گیری پاسخ به کلاینت در بافرها اتفاق می‌افتد که می‌توانند به بخش فایل اشاره کنند یا داده‌ها را در حافظه ذخیره کنند. توالی انتقال داده به مشتری توسط زنجیره هایی که بافرها در آنها گروه بندی می شوند تعیین می شود.

از نظر ساختاری، سرور HTTP Nginx به سرورهای مجازی تقسیم می شود که به نوبه خود به مکان ها تقسیم می شوند. به سرور مجازی یا دایرکتیو می توان پورت ها و آدرس هایی برای پذیرش اتصالات داده شود. شما می توانید یک URI دقیق، بخشی از یک URI یا یک عبارت منظم برای مکان مشخص کنید. Pool ها که دنباله ای از بلوک های از پیش انتخاب شده حافظه هستند، برای مدیریت حافظه آنلاین استفاده می شوند. یک بلوک، که در ابتدا برای استخر اختصاص داده شده بود، دارای طول 1 تا 16 کیلوبایت است. به مناطق - اشغالی و غیر اشغالی تقسیم می شود. همانطور که دومی پر می شود، انتخاب یک شی جدید با تشکیل یک بلوک جدید تضمین می شود.

مشتریان از نظر جغرافیایی بر اساس آدرس IP خود در Nginx با استفاده از یک ماژول خاص طبقه بندی می شوند. سیستم درختی Radix به شما امکان می دهد تا به سرعت با آدرس های IP کار کنید و حداقل حافظه را اشغال کنید.

مزایای Nginx

Nginx به عنوان یک سرور HTTP بسیار سریع در نظر گرفته می شود. به جای آپاچی یا همراه با آن، از Nginx برای سرعت بخشیدن به پردازش درخواست ها و کاهش بار روی سرور استفاده می شود. واقعیت این است که امکانات عظیمی که توسط معماری ماژولار آپاچی در نظر گرفته شده توسط اکثر کاربران مورد نیاز نیست. پرداخت هزینه برای این عملکرد بی ادعا اتلاف قابل توجهی از منابع سیستم است. سایت های معمولی به جای اسکریپت ها بیشتر تحت سلطه فایل های ثابت (تصاویر، شیوه نامه ها، جاوا اسکریپت) هستند. هیچ عملکرد خاصی برای انتقال این فایل ها به بازدید کننده منبع مورد نیاز نیست، زیرا کار بسیار ساده است. و بنابراین، وب سرور برای پردازش چنین درخواست هایی باید مانند Nginx ساده و سبک باشد.

راه های استفاده از Nginx

در یک پورت/IP مجزا.اگر منبع با تصاویر یا فایل هایی برای دانلود اشباع شده باشد، Nginx را می توان روی یک پورت یا IP جداگانه پیکربندی کرد و محتوای ثابت را از طریق آن توزیع کرد. برای انجام این کار، با این حال، شما باید کمی با تغییر لینک ها در سایت مشکل داشته باشید. با تعداد زیادی درخواست برای فایل های ثابت، ایجاد یک سرور جداگانه و نصب Nginx بر روی آن منطقی است.

پروکسی تسریع شده. با استفاده از این گزینه، تمام درخواست های بازدیدکنندگان ابتدا به Nginx می آیند. درخواست های فایل های ثابت (مانند یک تصویر، HTML ساده، جاوا اسکریپت یا فایل CSS) توسط خود Nginx انجام می شود. اگر کاربر به یک اسکریپت خاص دسترسی پیدا کند، درخواست را به بخش آپاچی هدایت می کند. نیازی به هیچ تغییری با کد سایت نیست.

اگر کانال از سرور به بازدید کننده و بالعکس کند باشد، این استفاده از Nginx می تواند جلوه بیشتری بدهد. درخواست دریافت شده از بازدید کننده برای پردازش توسط آپاچی به Nginx منتقل می شود. پس از پردازش درخواست، آپاچی صفحه را به Nginx هدایت می کند و با احساس موفقیت، اتصال را قطع می کند. اکنون Nginx می تواند تا زمانی که کاربر دوست داشته باشد، یک صفحه را عملاً بدون صرف منابع سیستم برای کاربر ارسال کند. آپاچی در جای خود با یک بار حافظه غیرمنطقی بالا در هنگام اجرای تقریباً بیکار همراه خواهد بود. به هر حال، این مورد استفاده Nginx نام دیگری دارد: "فرانت اند به آپاچی".

Nginx به علاوه FastCGI.اگر مفسر زبانی که اسکریپت های سایت با آن نوشته شده اند، از فناوری FastCGI پشتیبانی کند، ممکن است اصلاً به آپاچی نیاز نباشد. از جمله این زبان ها می توان به PHP، Perl و تعدادی دیگر اشاره کرد. درست است، در این مورد، ممکن است مجبور شوید کدهای اسکریپت را تغییر دهید.

مطالب دقیق زیادی در مورد نحوه نصب و پیکربندی Nginx در شبکه وجود دارد. می توانید اطلاعات بیشتری در مورد Nginx در وب سایت توسعه دهنده آن Igor Sysoev کسب کنید.

در حال حاضر دو وب سرور بیشترین محبوبیت را به دست آورده اند. اینها Apache و Ngnix هستند. هر کدام از آنها جوانب مثبت و منفی خود را دارند. آپاچی در سال 1995 توسعه یافت و تمام نیازهای کاربر ممکن در طول توسعه آن در نظر گرفته نشد، حافظه و منابع سیستم زیادی مصرف می کند، اما پیکربندی آن آسان است. Nginx کمی دیرتر در سال 2002 توسعه یافت و در حال حاضر خطاهای آپاچی را در نظر گرفت و بر حداکثر عملکرد تمرکز کرد.

ما به تفصیل به مزایا و معایب این دو وب سرور نمی پردازیم. هر کدام از آنها حوزه کاربرد خاص خود را دارند. این آموزش نصب Nginx Ubuntu 16.04 را پوشش می دهد. اگرچه من در مورد اوبونتو 16.04 صحبت خواهم کرد، اما این مراحل برای سایر توزیع ها نیز کارساز خواهد بود. تنظیمات Nginx در همه جا یکسان است، فقط دستور نصب متفاوت است.

اولین قدم این است که خود وب سرور را در سیستم نصب کنید. این برنامه در مخازن رسمی است، اما نسخه آن در حال حاضر کمی قدیمی است، بنابراین اگر آخرین نسخه را می خواهید، باید PPA را اضافه کنید:

sudo apt-add-repository ppa:nginx/stable

اکنون نسخه 1.10.0 در مخازن رسمی موجود است و 1.10.1 در حال حاضر در PPA پایدار موجود است. اگر به نسخه ای نیاز ندارید، می توانید بدون PPA این کار را انجام دهید. در مرحله بعد، لیست های بسته را از مخازن به روز کنید:

و ngix را نصب کنید:

sudo apt nginx را نصب کنید

پس از اتمام نصب سرور Nginx، برنامه را به راه اندازی اضافه کنید تا به طور خودکار شروع شود:

sudo systemctl nginx را فعال می کند

اگر همین الان یک مرورگر را باز کنید، شاهد اجرای nginx خواهید بود، اما هنوز باید آن را پیکربندی کنیم.

راه اندازی Nginx Ubuntu

راه اندازی Nginx Ubuntu بسیار پیچیده تر از Apache است. در اینجا ما تمام گزینه ها و ویژگی های برنامه را در نظر نخواهیم گرفت، بلکه فقط در مورد موارد اصلی صحبت خواهیم کرد. تنظیمات مختلفی وجود دارد که در آن از Nginx به عنوان یک سرور پروکسی استفاده می شود و Apache سرور اصلی است، اما ما به این موضوع علاقه ای نخواهیم داشت. ما باید Nginx را به عنوان یک وب سرور مستقل نصب کنیم.

تنظیمات Nginx بسیار متفاوت است در اینجا فقط یک فایل پیکربندی اصلی و فایل برای هاست مجازی وجود دارد. پیکربندی از هر دایرکتوری، مانند آپاچی، پشتیبانی نمی شود.

• /etc/nginx/nginx.conf- فایل پیکربندی اصلی
• /etc/nginx/sites-available/*- فایل های پیکربندی برای هاست های مجازی، به عبارت دیگر، برای هر سایت.
• /etc/nginx/sites-enabled/*- فایل های پیکربندی سایت های فعال شده

در واقع، فایل‌های پیکربندی برای میزبان‌های مجازی فقط از فهرستی که سایت‌ها فعال هستند خوانده می‌شوند، اما حاوی پیوندهایی به سایت‌های موجود است. چنین سیستمی اختراع شد تا امکان غیرفعال کردن موقت سایت های خاص را بدون پاک کردن پیکربندی آنها فراهم کند. همه فایل‌های دیگر فقط شامل اعلان‌های متغیر و تنظیمات پیش‌فرض هستند که نیازی به تغییر ندارند. در مورد nginx.conf، تمام فایل‌های سایت‌ها-enables در آن گنجانده شده‌اند، و بنابراین می‌توانند همه دستورالعمل‌های مشابهی را داشته باشند. حالا بیایید به فایل پیکربندی اصلی نگاه کنیم:

sudo vi /etc/nginx/nginx.conf

همانطور که می بینید فایل به بخش هایی تقسیم شده است. ساختار کلی این است:

گزینه های جهانی
مناسبت ها()
http(
سرور(
محل()
}
سرور ()
}
نامه ()

• گزینه های جهانیمسئول عملیات کل برنامه است.
• مناسبت ها- این بخش شامل تنظیمات کار با شبکه است.
• http- شامل تنظیمات وب سرور است. باید شامل یک بخش سرور برای تنظیم دقیق هر سایت باشد.
• سرور- این بخش شامل تنظیمات هر سایتی است که روی سرور وب میزبانی می شود.
• محل- بخش مکان فقط می تواند در داخل بخش سرور قرار داده شود و فقط برای یک درخواست خاص تنظیماتی را شامل می شود.
• پست الکترونیکی- حاوی تنظیمات پروکسی ایمیل است.

قبل از اینکه به سراغ گزینه ها برویم، باید چند کلمه دیگر در مورد نحو خط در فایل پیکربندی بگوییم. به نظر می رسد این است:

مقدار پارامتر ارزش_اضافی...;

خط لزوماً باید با ";" خاتمه یابد، و تمام براکت های باز ( باید بسته شوند.

اکنون که ساختار جهانی را کمی بررسی کردید، زمان آن رسیده است که به خود پارامترها نگاه کنید. گزینه های جهانی زیادی وجود ندارد:

• کاربر- کاربری که برنامه از طرف آن اجرا می شود.
• کارگر_فرایندها- تعداد فرآیندهایی را که برای موازی کردن برنامه باید اجرا کنید را تنظیم می کند، شما نیازی به اجرای هیچ پروسه ای بیش از هسته های خود ندارید. می توانید پارامتر را تنظیم کنید خودکارو سپس برنامه خودش این عدد را تعیین می کند.
• pid= فایل pid برنامه.
• worker_rlimit_nofile- نشان دهنده حداکثر تعداد فایل هایی است که برنامه می تواند باز کند. محاسبه شده به عنوان worker_processes * worker_connections* 2.

ما با گزینه های جهانی تمام شده ایم، تعداد آنها زیاد نبود و چندان جالب نیستند. از نظر بهینه سازی گزینه از بخش رویدادها بسیار جالب تر است:

• worker_connections- تعداد اتصالاتی که برنامه می تواند به طور همزمان در یک فرآیند پردازش کند. اگر worker_process را در این پارامتر ضرب کنیم، حداکثر تعداد کاربرانی که می توانند همزمان به سرور متصل شوند را بدست می آوریم. توصیه می شود مقدار را از 1024 به 4048 تنظیم کنید.
• multi_accept- اجازه می دهد چندین اتصال را به طور همزمان دریافت کنید، پارامتر را روی روشن یا خاموش تنظیم کنید.
• استفاده کنید- راهی برای کار با پشته شبکه. پیش فرض نظرسنجی است، اما در لینوکس استفاده از epoll کارآمدتر است.

• ارسال فایل- از روش ارسال داده های sendfile استفاده کنید. در ارزش
• tcp_nodelay، tcp_nopush- ارسال سرصفحه و ابتدای فایل در یک بسته. در ارزش
• keepalive_timeout- زمان انتظار قبل از قطع شدن اتصال keepalive، پیش فرض 65 است، اما می توان آن را به 10 ثانیه کاهش داد.
• keepalive_requests- حداکثر تعداد اتصالات نگهدارنده از یک مشتری، 100 توصیه می شود.
• reset_timedout_connection- اتصالات را پس از اتمام زمان قطع کنید. در ارزش
• open_file_cache- اطلاعات کش در مورد فایل های باز. خط پیکربندی به این صورت است: open_file_cache max=200000 inactive=20s; max - حداکثر تعداد فایل ها در کش، زمان ذخیره سازی.
• open_file_cache_valid- نشان می دهد که پس از چه زمانی لازم است اطلاعات از حافظه پنهان حذف شود. به عنوان مثال: open_file_cache_valid 30s;
• open_file_cache_min_uses- اطلاعات کش در مورد فایل هایی که حداقل به تعداد مشخص شده باز شده اند.
• open_file_cache_errors- اطلاعات کش در مورد فایل های از دست رفته، ارزش در.

پارامترهای اصلی در نظر گرفته شده است. این تنظیمات به شما کمک می کند تا عملکرد بیشتری از nginx داشته باشید. ما بخش سرور و مکان را در پیکربندی میزبان مجازی در نظر خواهیم گرفت.

پیکربندی فشرده سازی Gzip

فشرده سازی محتوا برای کاهش حجم داده های دانلود شده توسط مرورگر ضروری است. این باعث افزایش سرعت بارگذاری سایت می شود، اما بار اضافی را بر روی پردازنده سرور اضافه می کند. برای فعال کردن فشرده سازی در بخش http، باید پارامتر را اضافه کنید:

این دایرکتیو در قسمت سرور نیز قابل استفاده است که در این صورت فقط برای دامنه مجازی مشخص شده کار می کند. در مرحله بعد، تنظیمات فشرده سازی را با استفاده از گزینه های زیر پیکربندی کنید:

• gzip_min_length- حداقل طول صفحه بر حسب بایت که در آن فشرده سازی باید استفاده شود، به عنوان مثال، 1000 (1 کیلوبایت)
• gzip_proxied- اینکه آیا فشرده سازی درخواست های پروکسی ضروری است، هر کدام می گوید که همه چیز باید فشرده شود.
• gzip_types- انواع فایل هایی که باید فشرده شوند، به عنوان مثال: text/plain application/xml application/x-javascript text/javascript text/css text/json.
• gzip_disable "msie6"- در IE 6، فشرده سازی پشتیبانی نمی شود، بنابراین آن را غیرفعال کنید.
• gzip_comp_level- سطح فشرده سازی، گزینه های 1 تا 10 موجود است. 1 - حداقل، 10 - حداکثر فشرده سازی.

راه اندازی هاست مجازی

همانطور که می دانید یک سرور می تواند چندین سایت را میزبانی کند. همه درخواست‌ها به آی‌پی سرور می‌آیند و nginx از قبل تعیین می‌کند که بر اساس دامنه چه محتوایی باید برگردانده شود. برای اینکه nginx بداند متعلق به کدام دامنه است، باید هاست مجازی را پیکربندی کنید. هر هاست معمولا در یک فایل جداگانه قرار می گیرد. پیکربندی میزبان در بخش سرور است، اما از آنجایی که تمام فایل‌های سایت‌های فعال شده به بخش http وارد می‌شوند، منطق ساختار فایل پیکربندی نقض نمی‌شود.

یک نمونه راه اندازی را در نظر بگیرید:

vi /etc/nginx/sites-enabled/site.conf

• گوش کن 80- مشخص می کند که برای اتصال در پورت 80 منتظر بمانید، همچنین ممکن است حاوی این گزینه باشد سرور پیش فرض، به این معنی که اگر دامنه در درخواست مشخص نشده باشد، این دامنه باز می شود.
• root /var/www/html- دایرکتوری که فایل های سایت در آن قرار دارند.
• index index.html- صفحه ای که به طور پیش فرض باز می شود.
• نام ارائهکننده- نام دامنه سایت
• access_log- فایلی برای نوشتن گزارش درخواست ها به سرور، هم به صورت سراسری در قسمت http و هم برای یک نوع فایل خاص در مکان قابل استفاده است.
• error_log- گزارش خطای وب سرور، می تواند یک پارامتر اضافی که جزئیات گزارش را نشان می دهد، بگیرد. هشدار - حداکثر، بحران - فقط خطاهای بحرانی.

اینها همه تنظیمات اولیه برای میزبان مجازی هستند که پس از آن از قبل کار می کند. اما یک بخش مکان نیز وجود دارد که به شما امکان می دهد رفتار سرور را برای دایرکتوری ها و فایل های خاصی پیکربندی کنید. نحو برای مکان این است:

آدرس مکان ()

آدرس می تواند یک پرس و جو مستقیم نسبت به ریشه سرور یا عبارات منظم باشد. برای استفاده از عبارات منظم، قبل از آن علامت "~" قرار می گیرد. بیایید به مثال های زیر نگاه کنیم، اما در حال حاضر اجازه دهید دستورالعمل های ممکن را بررسی کنیم:

• اجازه- اجازه دسترسی به مکان را برای کاربران، همه - همه، شما همچنین می توانید IP یا Subnet را مشخص کنید.
• انکار- دسترسی به مکان را ممنوع کنید، همه - برای همه.
• فایل ها را امتحان کنید- سعی می کند فایل ها را به ترتیب خاصی باز کند، اولین فایل یافت شده را باز می کند. به عنوان مثال، این ساختار: $uri $uri/index.html $uri.html =404; ابتدا سعی می کند $uri را باز کند، سپس index.html را، اگر $uri.html پیدا نشد، و سپس، اگر هیچ یک از فایل های پیش فرض وجود نداشته باشد، خطای 404 می دهد.
• منقضی می شود- زمان را تنظیم می کند تا مرورگر عنصر داده شده را ذخیره کند، به عنوان مثال، 1d - یک روز، 2h - دو ساعت، 30s - 30 ثانیه.

علاوه بر این دستورالعمل های اصلی، می توان از موارد دیگر نیز در اینجا استفاده کرد. برای جزئیات بیشتر به اسناد رسمی مراجعه کنید. بیایید به چند مثال نگاه کنیم:

فاویکون را وارد نکنید:

مکان = /favicon.ico (
log_not_found off;
access_logoff;
}

عدم دسترسی به فایل هایی که با نقطه شروع می شوند:

مکان ~ /\. (
انکار همه
}

فایل های معمولی را به مدت 90 روز کش کنید:

مکان ~* ^.+\.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|rss|atom|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2 |doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$ (
access_logoff; log_not_found off; 90 روز منقضی می شود.

Nginx یک وب سرور محبوب و قدرتمند و پروکسی معکوس است.

Nginx مزایای زیادی دارد، اما تنظیمات آن بسیار پیچیده است و همیشه برای مبتدیان واضح نیست. این راهنما به شما کمک می کند تا پارامترهای اساسی، نحو و فایل های پیکربندی Nginx را درک کنید.

توجه داشته باشید: آموزش انجام شده در اوبونتو 12.04.

سلسله مراتب دایرکتوری Nginx

Nginx فایل های پیکربندی را در پوشه /etc/nginx ذخیره می کند.

این فهرست شامل چندین فهرست دیگر و فایل های پیکربندی ماژول است.

سی دی /etc/nginx
ls -F

conf.d/ koi-win naxsi.rules scgi_params uwsgi_params
fastcgi_params mime.types nginx.conf sites-available/win-utf
koi-utf naxsi_core.rules proxy_params sites-enabled/

کاربران آپاچی از قبل با دایرکتوری های سایت های در دسترس و سایت های فعال آشنا هستند. این دایرکتوری ها تنظیمات سایت را تعریف می کنند. فایل ها معمولاً در سایت های موجود ایجاد و ذخیره می شوند. سایت‌های فعال فقط پیکربندی‌های سایت‌های فعال را ذخیره می‌کند. برای انجام این کار، یک پیوند نمادین از سایت‌های موجود به سایت‌های فعال ایجاد کنید.

دایرکتوری conf.d همچنین می تواند برای ذخیره تنظیمات استفاده شود. هر فایل با پسوند conf. هنگام راه اندازی Nginx خوانده می شود. سینتکس چنین فایل هایی نباید حاوی خطا باشد.

تقریباً تمام فایل‌های باقی‌مانده در /etc/nginx ذخیره می‌شوند که حاوی اطلاعات پیکربندی برای فرآیندهای خاص یا اجزای اضافی است.

فایل پیکربندی اصلی برای Nginx nginx.conf است.

فایل nginx.conf

فایل nginx.conf فایل‌های پیکربندی مربوطه را می‌خواند و هنگام راه‌اندازی سرور، آنها را در یک فایل پیکربندی ادغام می‌کند.

باز کردن فایل:

sudo nano /etc/nginx/nginx.conf

کاربر www-data;
worker_processes 4;
pid /var/run/nginx.pid;
مناسبت ها (
worker_connections 768;
# چند_پذیرش در;
}
http(
. . .

خطوط اول اطلاعات کلی در مورد Nginx می دهد. کاربر رشته www-data کاربری که سرور را اجرا می کند را مشخص می کند.

دستورالعمل pid مشخص می کند که PID های فرآیند برای استفاده داخلی کجا ذخیره می شوند. خط worker_processes تعداد فرآیندهایی را که Nginx می تواند همزمان پشتیبانی کند را مشخص می کند.

همچنین می‌توانید گزارش‌ها را در این قسمت از فایل مشخص کنید (به عنوان مثال، گزارش خطا با استفاده از دستورالعمل error_log تعریف می‌شود).

بخش رویدادها اطلاعات کلی در مورد سرور را دنبال می کند. نحوه مدیریت اتصالات Nginx را کنترل می کند. به دنبال آن بلوک http می آید. قبل از اینکه به تنظیمات وب سرور ادامه دهیم، باید بدانیم که فایل پیکربندی Nginx چگونه قالب بندی می شود.

ساختار فایل پیکربندی Nginx

فایل پیکربندی Nginx به بلوک ها تقسیم می شود.

بلوک اول رویدادها است و به دنبال آن http و سلسله مراتب پیکربندی اصلی شروع می شود.

جزئیات پیکربندی یک بلوک http با استفاده از بلوک‌های خصوصی که ویژگی‌های بلوکی را که در آن قرار دارند به ارث می‌برند، مرتب می‌شوند. بلوک http بیشتر پیکربندی عمومی Nginx را ذخیره می‌کند، که به بلوک‌های سرور تقسیم می‌شود، که به نوبه خود به بلوک‌های مکان تقسیم می‌شوند.

هنگام تنظیم Nginx، مهم است که قانون زیر را به خاطر بسپارید: هر چه سطح پیکربندی بالاتر باشد، بلاک های بیشتری این پیکربندی را به ارث خواهند برد. هرچه سطح پیکربندی پایین تر باشد، "فردی" تر است. یعنی اگر پارامتر X باید در هر بلوک سرور استفاده شود، چنین پارامتری باید در بلوک http قرار گیرد.

اگر به فایل دقت کنید، متوجه خواهید شد که حاوی گزینه های زیادی است که رفتار برنامه را به طور کلی تعیین می کند.

به عنوان مثال، برای پیکربندی فشرده سازی فایل، باید پارامترهای زیر را تنظیم کنید:

gzip روشن
gzip_disable "msie6";

این کار پشتیبانی gzip را برای فشرده سازی داده های ارسال شده به مشتری فعال می کند و gzip را برای Internet Explorer 6 غیرفعال می کند (زیرا آن مرورگر از فشرده سازی داده ها پشتیبانی نمی کند).

اگر یک تنظیم نیاز به مقدار متفاوتی در چندین بلوک سرور داشته باشد، می توان آن تنظیم را در سطح بالا تنظیم کرد و سپس در خود بلوک های سرور لغو کرد. در نتیجه، Nginx گزینه پایین ترین سطح را اجرا خواهد کرد.

این طبقه بندی تنظیمات از نیاز به مدیریت چندین فایل یکسان جلوگیری می کند. همچنین، اگر فراموش کردید که گزینه‌ها را در پایین‌ترین سطح تعریف کنید، Nginx به سادگی گزینه‌ها را پیش‌فرض می‌کند.

بلوک http در فایل nginx.conf به این شکل به پایان می رسد:

شامل /etc/nginx/conf.d/*.conf.
شامل /etc/nginx/sites-enabled/* باشد.

این به شما می‌گوید که بلوک‌های سرور و مکان، که تنظیمات سایت‌ها و URL‌های خاص را تعیین می‌کنند، خارج از این فایل ذخیره می‌شوند.

این به شما امکان می دهد یک معماری پیکربندی مدولار را حفظ کنید که در آن می توانید فایل های جدیدی را برای ارائه سایت های جدید ایجاد کنید. همچنین به شما امکان می دهد فایل های مشابه را گروه بندی کنید.

فایل nginx.conf را ببندید. اکنون باید تنظیمات هر سایت را مطالعه کنید.

بلوک های مجازی Nginx

بلوک‌های سرور در Nginx مشابه میزبان‌های مجازی آپاچی هستند (اما برای راحتی، به آنها میزبان مجازی نیز می‌گویند). اساساً، بلوک های سرور مشخصات فنی برای وب سایت های جداگانه ای هستند که روی همان سرور میزبانی می شوند.

در دایرکتوری sites-available، می‌توانید فایل بلوک سرور پیش‌فرض همراه با سرور را پیدا کنید. این فایل شامل تمامی داده های لازم برای نگهداری سایت می باشد.

سایت های سی دی در دسترس است
sudo nano پیش فرض

root /usr/share/nginx/www;
index index.html index.htm;
server_namelocalhost;
محل / (

}
مکان /doc/ (

نام مستعار /usr/share/doc/;
فهرست خودکار روشن
اجازه 127.0.0.1;
انکار همه

فایل پیش فرض بسیار خوب کامنت گذاری شده است، اما در مثال بالا نظرات برای سادگی و راحتی حذف شده است.

بلوک سرور شامل تمام تنظیمات بین بریس های فرفری است:

سرور(
. . .
}

این بلوک در فایل nginx.conf در انتهای بلوک http با استفاده از دستورالعمل include قرار می گیرد.

دستورالعمل root فهرستی را که محتوای سایت در آن ذخیره می شود را مشخص می کند. در این دایرکتوری، Nginx به دنبال فایل های درخواستی کاربر می گردد. دایرکتوری پیش فرض /usr/share/nginx/www است.

توجه داشته باشید که تمام خطوط با نقطه ویرگول به پایان می رسد. اینگونه است که Nginx یک دستورالعمل را از دیگری جدا می کند. اگر نقطه ویرگول وجود نداشته باشد، Nginx دو دستورالعمل (یا چند دستورالعمل) را به عنوان یک دستورالعمل با آرگومان های اضافی می خواند.

دستورالعمل ایندکس فایل هایی را که قرار است به عنوان شاخص استفاده شوند تعریف می کند. وب سرور فایل ها را به ترتیب فهرست شده بررسی می کند. اگر هیچ صفحه ای درخواست نشده باشد، بلوک سرور فایل index.html را پیدا کرده و برمی گرداند. اگر نتواند این فایل را پیدا کند، سعی می کند index.htm را پردازش کند.

دستورالعمل server_name

دستور server_name شامل لیستی از نام های دامنه است که توسط این بلوک سرور ارائه می شود. تعداد دامنه ها نامحدود است. دامنه های موجود در لیست باید با فاصله از هم جدا شوند.

یک کاراکتر ستاره (*) در ابتدا یا انتهای یک دامنه، نامی را با ماسک مشخص می کند، جایی که ستاره با بخشی (یا چند قسمت) از نام مطابقت دارد. برای مثال، *.example.com با forum.example.com و www.animals.example.com مطابقت دارد.

اگر url درخواستی با چندین دستورالعمل server_name مطابقت داشته باشد، ابتدا به آدرسی که کاملاً مطابقت دارد پاسخ می دهد.

اگر آدرس مطابقت پیدا نکند، به دنبال طولانی ترین نام پوشانده شده که با ستاره ختم می شود می گردد. اگر چنین نامی را پیدا نکرد، اولین عبارت معمولی مطابقت را برمی گرداند.

نام سرورهایی که از عبارات منظم استفاده می کنند با یک tilde (~) شروع می شوند. متاسفانه این موضوع از حوصله این مقاله خارج است.

بلوک های مکان یابی

مکان / خط مشخص می کند که دستورالعمل های پرانتز شده برای همه منابع درخواستی که با هیچ بلوک مکان دیگری مطابقت ندارند اعمال می شود.

چنین بلوک هایی ممکن است حاوی یک مسیر uri (به عنوان مثال /doc/) باشند. برای ایجاد تطابق کامل بین مکان و uri، از نماد = استفاده می شود. کاراکتر ~ با عبارات منظم مطابقت دارد.

tilde حالت حساس به حروف بزرگ و کوچک را روشن می‌کند، در حالی که علامت ستاره روی حالت حساس به حروف بزرگ و کوچک روشن می‌شود.

اگر درخواست به طور کامل با بلوک مکان مطابقت داشته باشد، سرور جستجو را متوقف می کند و از آن بلوک استفاده می کند. اگر سرور یک بلوک مکان کاملاً منطبق را پیدا نکند، URI را با پارامترهای دستورالعمل های مکان مقایسه می کند. Nginx بلوکی را انتخاب می کند که از ترکیب کاراکتر ^~ استفاده می کند و با URI مطابقت دارد.

اگر از گزینه ^~ استفاده نمی شود، Nginx نزدیکترین مورد را انتخاب می کند و یک عبارت منظم را جستجو می کند تا یکی از الگوهای موجود را امتحان کند. اگر چنین تعبیری بیابد از آن استفاده می کند. اگر چنین عبارتی وجود نداشته باشد، سرور از تطابق URI قبلی استفاده می کند.

به عنوان نتیجه، Nginx تطابق دقیق را ترجیح می دهد. اگر چنین تطابقی وجود نداشته باشد، به دنبال عبارت منظم می گردد و سپس URI را جستجو می کند. برای تغییر اولویت جستجوی URI، از ترکیب کاراکتر ^~ استفاده کنید.

دستورالعمل try_files

دستورالعمل try_files ابزار بسیار مفیدی است که وجود فایل ها را به ترتیب مشخص بررسی می کند و از اولین فایل یافت شده برای پردازش درخواست استفاده می کند.

این به شما امکان می دهد تا مشخص کنید که Nginx چگونه درخواست ها را با گزینه های اضافی ارائه می دهد.

فایل تنظیمات پیش فرض شامل این خط است:

try_files $uri $uri/ /index.html;

این به این معنی است که وقتی درخواستی توسط بلوک مکان ارائه می شود، Nginx ابتدا سعی می کند uri را به عنوان یک فایل ارائه کند (این رفتار توسط متغیر $uri تنظیم می شود).

اگر سرور موردی برای متغیر $uri پیدا نکرد، سعی می کند از uri به عنوان دایرکتوری استفاده کند.

با یک اسلش در انتها، سرور وجود دایرکتوری مانند $uri/ را بررسی می کند.

اگر هیچ فایل یا دایرکتوری یافت نشد، Nginx فایل پیش فرض را اجرا می کند (در این مورد، index.html در دایرکتوری ریشه بلوک سرور). هر دستورالعمل try_files از آخرین پارامتر به عنوان یک بازگشت استفاده می کند، بنابراین این فایل باید در سیستم وجود داشته باشد.

اگر وب سرور مطابق با پارامترهای قبلی پیدا نکرد، ممکن است صفحه خطا را برگرداند. برای این کار از علامت مساوی و کد خطا استفاده کنید.

به عنوان مثال، اگر مکان / بلوک نتواند منبع درخواستی را پیدا کند، به جای فایل index.html، ممکن است یک خطای 404 را برگرداند:

try_files $uri $uri/ =404;

برای این کار علامت مساوی قرار داده و کد خطا را به عنوان آخرین پارامتر (=404) قرار دهید.

گزینه های اضافی

دستورالعمل مستعار به Nginx اجازه می دهد تا صفحات را در بلوک مکان خارج از فهرست مشخص شده (به عنوان مثال، خارج از ریشه) ارائه دهد.

به عنوان مثال، فایل های درخواست شده در /doc/ از /usr/share/doc/ ارائه می شوند.

فهرست خودکار در دستورالعمل فهرست دایرکتوری Nginx را برای دستورالعمل مکان داده شده فعال می کند.

خطوط مجاز و رد دسترسی به دایرکتوری ها را کنترل می کنند.

نتیجه

وب سرور Nginx دارای ویژگی های غنی و بسیار توانمند است، اما اصطلاحات و گزینه های آن می تواند گیج کننده باشد.

هنگامی که پیکربندی های Nginx را درک کرده و با آن کار کنید، تمام مزایای این ابزار قدرتمند و سبک را دریافت خواهید کرد.

برچسب ها: ,