طراحی سایت و برنامه نویسی

آموزش طراحی سایت و برنامه نویسی

طراحی سایت و برنامه نویسی

آموزش طراحی سایت و برنامه نویسی

چگونه از گیت (Git) به طرز موثرتری استفاده کنیم؟ — به زبان ساده

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

در این نوشته فرض شده که شما گیت را روی سیستم خود نصب کرده‌اید و تنظیمات پیکربندی عمومی (مانند نام کاربری و ایمیل) را نیز به طرز صحیحی تنظیم کرده‌اید. اگر چنین نیست، می‌توانید از مقاله «نصب گیت (Git) روی اوبونتو» کمک بگیرید.

پیش از استفاده از گیت برای توسعه کد، بهتر است گردش کار خود را طرح‌ریزی کنید. تصمیم‌گیری در مورد گردش کار معمولاً مبتنی بر اندازه و مقیاس پروژه صورت می‌گیرد. برای این که درکی اولیه از گیت داشته باشید، طراحی یک گردش کاری ساده و تک انشعابی (single branch) کافی خواهد بود. به طور پیش‌فرض نخستین شاخه از هر پروژه گیت به نام «مستر» (master) نامیده می‌شود. در این راهنما با روش ساخت شاخه‌های دیگر نیز آشنا می‌شویم.

در ادامه نخستین پروژه خود را به نام «testing» می‌سازیم. اگر از قبل پروژه‌ای دارید که می‌خواهید به گیت ایمپورت کنید، می‌توانید به بخش «تبدیل پروژه به محیط فضای کار» مراجعه کنید.

ایجاد فضای کار (workspace)

همان طور که هر کس دوست دارد محیط کاری تمیز و مناسبی داشته باشد، این مسئله در مورد محل کدنویسی نیز به خصوص در حالتی که همزمان روی چند پروژه کار شود، صدق می‌کند. پیشنهاد خوب در این زمینه آن است که پوشه‌ای به نام git روی دایرکتوری home سیستم خود داشته باشید که زیرپوشه‌های آن هر یک به یک پروژه مستقل اختصاص داشته باشند.

نخستین کاری که باید برای ایجاد محیط کاری خود انجام دهید، به صورت زیر است:

user@host ~ $ mkdir -p ~/git/testing; cd ~/git/testing

دستور فوق دو کار انجام می‌دهد:

  1. یک دایرکتوری به نام git در دایرکتوری home ایجاد می‌کند و سپس یک زیردایرکتوری به نام testing داخل آن ایجاد می‌کند. در واقع پروژه ما درون این زیردایرکتوری ذخیره خواهد شد.
  2. ما را به این زیردایرکتوری می‌برد.

زمانی که وارد این دایرکتوری شدیم، باید چند فایل ایجاد کنیم که پروژه ما را تشکیل خواهند داد. در این مرحله هم می‌توانید چند فایل ساختگی به منظور تست ایجاد کنید و یا این که فایل‌ها/دایرکتوری‌هایی که می‌خواهید واقعاً بخشی از پروژه شما باشند را ایجاد کنید.

ما با استفاده از دستور زیر یک فایل تست ایجاد می‌کنیم که در ریپازیتوری که ایجاد می‌کنیم، استفاده خواهد شد:

user@host ~/git/testing $ touch file

زمانی که فایل‌های پروژه در فضای کاری آماده شدند، باید شروع به ردگیری فایل‌ها با گیت بکنیم. در مرحله بعدی این فرایند توصیف خواهد شد.

تبدیل یک پروژه موجود به محیط فضای کاری

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

user@host ~/git/testing $ git init
Initialized empty Git repository in /home/user/git/testing/.git/

زمانی که ریپازیتوری خالی اولیه خود را راه‌اندازی کردیم، می‌توانیم فایل‌ها را به آن اضافه کنیم. در ادامه همه فایل‌ها و دایرکتوری‌ها را به ریپازیتوری جدیداً ایجاد شده اضافه می‌کنیم:

user@host ~/git/testing $ git add.

در این حالت بنا به مصداق ضرب‌المثل «بی‌خبری، خوش‌خبری است»، اگر هیچ خروجی دیده نشود، یعنی همه چیز به درستی پیش رفته است. متأسفانه گیت در همه موارد در صورت بروز اشکال، اطلاع‌رسانی نمی‌کند.

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

ایجاد یک پیام کامیت

پیام کامیت، پیام کوتاهی است که تغییراتی که صورت گرفته است را توضیح می‌دهد. این پیام برای ارسال تغییرات کد به ریپازیتوری که پوش (push) نامیده می‌شود ضروری است و روش مناسبی برای ارتباط با همکاران توسعه‌دهنده محسوب می‌شود که می‌خواهند تغییرات را مشاهده کنند. در این بخش روش ایجاد کامیت را توضیح می‌دهیم.

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

اگر مثال خود را پیگیری کنیم می‌توانیم پیام نخستین کامیت خود را به صورت زیر تنظیم کنیم:

user@host ~/git/testing $ git commit -m "Initial Commit" -a
[master (root-commit) 1b830f8] initial commit
0 files changed
create mode 100644 file

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

user@host ~/git/testing $ git commit -m "Initial Commit" file

برای افزودن فایل‌ها یا دایرکتوری‌های دیگر باید یک فهرست جداشده با کاراکتر اسپیس به انتهای دستور فوق اضافه کنید.

پوش کردن تغییرات به سرور ریموت

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

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

user@host ~/git/testing $ git remote add origin ssh://git@git.domain.tld/repository.git

user@host ~/git/testing $ git remote -v

origin ssh://git@git.domain.tld/repository.git (fetch)

origin ssh://git@git.domain.tld/repository.git (push)

دستور نخست یک سرور ریموت به نام «origin» اضافه می‌کند و URL را به صورت ssh://git@git.domain.tld/repository.git تنظیم می‌کند.

شما می‌توانید نام ریموت را هر چیزی که دوست دارید بگذارید؛ اما URL باید به یک ریپازیتوری ریموت واقعی اشاره کند. برای نمونه اگر بخواهید کد خود را به گیت‌هاب پوش کنید، باید از ریپازیتوری دارای URL ارائه شده از سوی گیت‌هاب استفاده کنید. زمانی که ریموت پیکربندی شد می‌توانید کد خود را پوش کنید.

با دستور زیر می‌توان کد را به سرور ریموت پوش کرد:

user@host ~/git/testing $ git push origin master
Counting objects: 4, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 266 bytes, done.
Total 3 (delta 1), reused 1 (delta 0)
To ssh://git@git.domain.tld/repository.git
0e78fdf..e6a8ddc master -> master

دستور git push به گیت می‌گوید که می‌خواهید تغییرات را پوش کنید. در دستور فوق «origin» نام سرور ریموت اخیراً پیکربندی‌شده ما است و «master» نیز نام نخستین شاخه یا branch ما محسوب می‌شود. در آینده هر کامیتی را که بخواهید به سرور پوش کنید، می‌توانید به سادگی از دستور git push استفاده کنید.

امیدواریم این مقاله درکی مقدماتی از طرز کار گیت به شما ارائه کرده باشد و بتوانید از آن به طرز مؤثری برای کار با همکارانتان استفاده کنید. در بخش بعدی این سری از مقالات، تحلیل عمیق‌تری از برنچ‌های گیت و دلیل کارآمدی آن‌ها خواهیم داشت.


منبع: فرادرس

اطلاعات پایگاه داده در MySQL — راهنمای جامع

سه نوع اطلاعات پایگاه داده MySQL وجود دارند که می‌توان به دست آورد:

  • اطلاعاتی در مورد نتیجه کوئری‌ها – این اطلاعات شامل چند رکورد هستند که تحت تأثیر عبارت‌های SELECT، UPDATE یا DELETE قرار گرفته‌اند.
  • اطلاعاتی در مورد جدول‌ها و پایگاه‌های داده – این اطلاعات شامل مواردی در مورد ساختار پایگاه داده و جدول‌ها می‌شود.
  • اطلاعاتی در مورد سرور MySQL – این مورد نیز شامل وضعیت سرورهای پایگاه داده، شماره نسخه و مواردی از این دست است.

دریافت همه این اطلاعات در خط اعلان MySQL کار آسانی است؛ اما هنگام استفاده از PERL یا PHP باید API های مختلفی را به طور صریح فراخوانی کنیم تا همه این اطلاعات را به دست آوریم.

به دست آوردن تعداد ردیف‌هایی که از یک کوئری تأثیر پذیرفته‌اند

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

مثال PERL

در اسکریپت‌های DBI، تعداد ردیف‌های تأثیر پذیرفته به وسیله ()do یا از طریق دستور ()execute بازگشت می‌یابد و این مسئله به چگونگی اجرای کوئری وابسته است.

مثال PHP

در زبان برنامه‌نویسی PHP، می‌توان تابع ()mysql_affected_rows را برای یافتن تعداد ردیف‌هایی که توسط یک کوئری تغییر یافته است، فراخوانی کرد.

لیست کردن جدول‌ها و پایگاه‌های داده

لیست کردن همه پایگاه‌های داده و جدول‌های موجود در یک سرور پایگاه داده کار آسانی است. اما در صورتی که دسترسی‌های کافی نداشته باشید، ممکن است با نتایج null مواجه شوید.

به جز روشی که در کد زیر برای این منظور استفاده شده است، می‌توان از کوئری‌های SHOW TABLES یا SHOW DATABASES برای دریافت لیستی از جدول‌ها یا پایگاه‌های داده در PHP یا PERL استفاده کرد.

مثال PERL

مثال PHP

دریافت فراداده سرور

چند دستور مهم در MySQL وجود دارند که می‌توان در اعلان MySQL یا با استفاده از اسکریپت‌هایی مانند PHP اجرا کرد و اطلاعات مختلفی در مورد سرور پایگاه داده به دست آورد.

دستورتوضیح
()SELECT VERSIONرشته معرف نسخه سرور
()SELECT DATABASEنام پایگاه داده جاری (در صورت نبودن، خالی است)
()SELECT USERنام کاربری جاری
SHOW STATUS نمایش وضعیت سرور
SHOW VARIABLES نمایش متغیرهای پیکربندی سرور

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

منبع: فرادرس


شل اسکریپت (Shell Script) روی VPS (بخش دوم) — از صفر تا صد

در بخش قبلی این راهنما در مورد آماده‌سازی فضای سیستم برای نوشتن اسکریپت شل صحبت کردیم. در این بخش از راهنما دستورهای مقدماتی Shell Script روی یک VPS را معرفی می‌کنیم. این دستورهای مقدماتی مسئول گردآوری اطلاعاتی از سوی کاربر و یا نمایش اطلاعاتی برای کاربر هستند. در این نوشته فرض کرده‌ایم که شما قبلاً پوشه شل اسکریپت را بر اساس آن چه در بخش اول این راهنما گفتیم پیکربندی کرده‌اید.

دستور echo

این دستور امکان نمایش اطلاعات به کاربر را فراهم می‌سازد. با استفاده از این دستور می‌توان رشته‌های متنی ساده، متغیرها یا ترکیبی از هر دو را نمایش داد. این دستور دو پارامتر به صورت n- و e- دارد. پارامتر n- باعث می‌شود که متن نمایش یافته در انتهای خود، کاراکتر «New line» (اینتر) را نداشته باشد و پارامتر e- باعث می‌شود که مجموعه کدهای زیر را درون رشته جای دهیم:

برای نمونه دستورهای زیر دقیقاً کار یکسانی را انجام می‌دهند:

برای نمایش متغیرها با echo، کافی است آن‌ها را به صورت زیر در رشته خود با کاراکتر ابتدایی $ بنویسید:

می‌توان متن، دستورها و متغیرها را در یک رشته منفرد ترکیب کرد. حتی می‌توان به راحتی با استفاده از دستور n\ چندین خط از متن را در یک خط از کد ترکیب کرده و در یک خط جدید در خروجی ارائه کرد.

متن قالب‌بندی شده با استفاده از echo

متن‌ها را با استفاده از دستور echo می‌توان به رنگ‌ها و سبک‌های مختلف نمایش داد. البته همه این تنظیمات در همه کلاینت‌های ترمینال کار نمی‌کنند و از این رو باید همواره در خاطر داشته باشید که ممکن است افراد نتایج متفاوتی نسبت به آن چه طراحی می‌کنید، شاهد باشند. اما با توجه به این که تفاوت‌ها صرفاً بصری هستند در اغلب موارد مشکل جدی ایجاد نمی‌کند. هر نوع سفارشی‌سازی (بولد کردن متن، طراحی زیرخط یا رنگ‌آمیزی) به وسیله دنباله‌هایی از escape تعریف می‌شود. منظور از escape کدی است که پس از کاراکتر e\ می‌آید. مانند زیر:

در جدول کوچک زیر اغلب کدهای رایج آن ارائه شده است:

می‌توان با ترکیب کردن آن‌ها برای نمونه متن‌های بولد، زیرخط دار ایجاد کرد. همچنین با استفاده از «e[0m\» می‌توان این تنظیمات را ریست کرد.

دستور فوق را امتحان کرده و خروجی را مشاهده کنید.

رنگ‌ها اساساً کارکرد مشابهی دارند. هر رنگ یک کد دارد و می‌توان این کد را همانند کدهای قالب‌بندی در نوشته درج کرد. در ادامه جدولی از رنگ‌هایی که اغلب کلاینت‌های ترمینال پشتیبانی می‌کنند، ارائه کرده‌ایم:

ضمناً می‌توان رنگ‌های متن را با رنگ‌های پس‌زمینه ترکیب کرد و همچنین کدهای قالب‌بندی معمول را به متون رنگی اضافه کرد.

دستور read

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

اما این یک اسکریپت است که هیچ اینترفیسی ندارد. کاربر از کجا باید بداند که باید چه چیزی و چگونه وارد نماید؟

اسکریپت نمونه

در اسکریپت نمونه زیر از همه چیزهایی که تا اینجا در این راهنما آموخته‌ایم بهره می‌گیریم. پیام‌های با قالب سفارشی برای کاربر نمایش می‌یابند و یک ورودی نیز دریافت می‌شود. در بخش نخست این راهنما مثالی داشتیم که در آن فایل‌ها را بر مبنای پارامترهای ارسالی هنگام فراخوانی اسکریپت، پشتیبان می‌گرفتیم. اینک آن مثال را بازنویسی می‌کنیم و از کاربر می‌پرسیم که می‌خواهد از چه چیزی پشتیبان‌گیری شود؟

ابتدا باید فایل را تنظیم و باز کنیم:

در ادامه اسکریپت را بازنویسی می‌کنیم تا یک رابط (اینترفیس) داشته باشد:

سخن پایانی

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

منبع: فرادرس


پیکربندی بلوک سرور Nginx روی سرور اوبونتو — از صفر تا صد

زمانی که از وب‌سرور Nginx استفاده می‌کنید، بلوک‌های سرور (server blocks) که معادل میزبان‌های مجازی (virtual hosts) در وب‌سرور آپاچی هستند، به منظور جمع‌بندی جزییات پیکربندی و میزبانی بیش از یک دامنه روی یک سرور منفرد به کار گرفته می‌شوند. در این مقاله به بررسی شیوه پیکربندی بلوک‌های سرور Nginx روی سرور اوبونتو 14.04 می‌پردازیم.

پیش‌نیازها

ما از یک کاربر غیر root با دسترسی‌های sudo در سراسر این راهنما استفاده خواهیم کرد. اگر چنین کاربری را روی سیستم خود پیکربندی نکرده‌اید، می‌توانید با پیگیری مراحل 1 تا 4 راهنمای «راه‌اندازی اولیه سرورهای اوبونتو ۱۸.۰۴» این کار را انجام دهید.

همچنین باید Nginx را روی سرور خود نصب کنید. اگر می‌خواهید کل مجموعه LEMP یعنی Linux, Nginx, MySQ و PHP را روی سرور نصب کنید، می‌توانید از مطلب «راهنمای نصب (Nginx،MySQL،PHP (LEMP روی اوبونتو» به این منظور کمک بگیرید.

اگر صرفاً می‌خواهید از Nginx استفاده کنید، می‌توانید آن را با دستورهای زیر نصب کنید:

sudo apt-get update
sudo apt-get install nginx

زمانی که این شرایط تأمین شدند، می‌توانید ادامه این راهنما را مطالعه کنید. ما صرفاً به منظور نمایش مقصود، دو دامنه را با سرور Nginx راه‌اندازی می‌کنیم. نام‌های دامنه‌های مورد استفاده در این راهنما به صورت example.com و test.com خواهند بود.

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

مرحله اول – راه‌اندازی دایرکتوری‌های جدید برای ریشه سند

به طور پیش‌فرض Nginx روی اوبونتو 14.04 یک بلوک سرور را در حالت default فعال می‌کند. این بلوک سرور برای عرضه اسنادی که در دایرکتوری زیر قرار دارند، پیکربندی‌شده است:

/usr/share/nginx/html

ما از این بلوک سرور پیش‌فرض استفاده نمی‌کنیم، زیرا کار با دایرکتوری var/www/ آسان‌تر است. بسته Nginx اوبونتو از دایرکتوری var/www/ به عنوان ریشه سند پیش‌فرض استفاده نمی‌کند و دلیل آن سیاست توزیع دبیان در خصوص بسته‌هایش است.

از آنجا که ما کاربر هستیم و نه مسئول نگهداری بسته، پس می‌توانیم به Nginx بگوییم که کجا می‌خواهیم ریشه سندمان را قرار دهیم. به طور خاص ما برای هر یک از سایت‌های خود درون دایرکتوری var/www/ یک دایرکتوری می‌سازیم و یک دایرکتوری نیز درون آن‌ها به نام html باید داشته باشیم که فایل‌ها را در آن‌ها نگه‌داری کنیم.

ابتدا باید دایرکتوری‌های مورد نیاز را بسازیم. این کار از طریق استفاده از دستورهای زیر ممکن است. فلگ p- به mkdir می‌گوید که دایرکتوری‌های والد ضروری را نیز در این مسیر باید ایجاد کند:

sudo mkdir -p /var/www/example.com/html
sudo mkdir -p /var/www/test.com/html

اینک که دایرکتوری‌ها ایجاد شدند، باید مالکیت را به کاربر معمولی انتقال دهیم. می‌توان از متغیر محیطی USER$ برای جایگزینی حساب کاربری که اکنون وارد آن شده‌ایم استفاده کنیم. بدین ترتیب امکان ایجاد فایل‌هایی در این دایرکتوری را می‌یابیم، به طوری که بازدیدکنندگانِ دیگر نتوانند محتوایی در آن ایجاد کنند.

sudo chown -R $USER:$USER /var/www/example.com/html
sudo chown -R $USER:$USER /var/www/test.com/html

مجوزهای ریشه‌های وب ما در صورتی که مقدار mask را تغییر نداده باشید، باید به طور صحیحی پیکربندی شده باشند؛ اما با وارد کردن دستور زیر می‌توانید در این مورد اطمینان حاصل کنید:

sudo chmod -R 755 /var/www

ساختار دایرکتوری اینک پیکربندی شده است و می‌توانیم به مراحل بعدی بپردازیم.

مرحله دوم – ایجاد صفحه‌های ساده برای هر سایت

اکنون که ساختار دایرکتوری ما آماده شده است، می‌توانیم صفحه‌های پیش فرضی برای هر یک از سایت‌ها ایجاد کنیم که در آن چیزی برای نمایش وجود داشته باشد. یک فایل index.html در دامنه اول خود ایجاد می‌کنیم:

nano /var/www/example.com/html/index.html

درون این فایل، یک محتوای بسیار ابتدایی ایجاد می‌کنیم که نشان‌دهنده این باشد که در حال حاضر به چه سایتی دسترسی یافته‌ایم. محتوای فایل به صورت زیر است:

<html>
    <head>
        <title>Welcome to Example.com!</title>
    </head>
    <body>
        <h1>Success! The example.com server block is working!</h1>
    </body>
</html>

زمانی که محتوا را وارد کردید، فایل را ذخیره کرده و خارج شوید.

از آنجا که فایل سایت دوم ما نیز به همین شکل خواهد بود، می‌توانید آن را در ریشه سند سایت دوم به صورت زیر کپی کنید:

cp /var/www/example.com/html/index.html /var/www/test.com/html/

اینک می‌توانیم این فایل جدید را باز کنیم:

nano /var/www/test.com/html/index.html

و آن را طوری ویرایش کنیم که نشان دهد روی دامنه دوم ما قرار دارد:

<html>
    <head>
        <title>Welcome to Test.com!</title>
    </head>
    <body>
        <h1>Success! The test.com server block is working!</h1>
    </body>
</html>

در پایان این فایل را نیز ذخیره کرده و خارج شوید. اینک روی هر دو دامنه خود صفحاتی داریم که به بازدیدکنندگان وب‌سایت نمایش دهیم.

مرحله سوم – ایجاد فایل‌های بلوک سرور برای هر دامنه

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

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

ایجاد فایل بلوک سرور برای دامنه اول

همان طور که قبلاً اشاره کردیم، بلوک سرور اول را با کپی کردن فایل default ایجاد می‌کنیم:

sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/example.com

اکنون فایل جدید را در ویرایشگر متنی خود با دسترسی root باز کنید:

sudo nano /etc/nginx/sites-available/example.com

با نادیده گرفتن خط‌های کامنت شده، فایل به صورت زیر باید باشد:

server {
    listen 80 default_server;
    listen [::]:80 default_server ipv6only=on;
    root /usr/share/nginx/html;
    index index.html index.htm;
    server_name localhost;
    location / {
        try_files $uri $uri/ =404;
    }
}

ابتدا باید دایرکتیوهای listen را بررسی کنیم. تنها یکی از بلوک‌های سرور می‌تواند دارای خصوصیات default_server باشد. این خصوصیت نشان می‌دهد که اگر server_name مورد تقاضا با هیچ یک از بلوک‌های سرور مطابقت نداشته باشد، این بلوک می‌تواند به درخواست مربوطه پاسخ دهد.

در نهایت باید پیکربندی بلوک سرور پیش‌فرض را غیر فعال کنیم تا بتوانیم گزینه default_server را در بلوک سرور این دامنه یا دامنه دیگر تعیین کنیم. در این راهنما گزینه default_server را روی این دامنه فعال نگه می‌داریم؛ اما شما می‌توانید بسته به نیازهای خود روی هر دامنه دیگری نیز آن را تنظیم کنید.

کار بعدی که باید انجام دهیم، تنظیم ریشه سند است که به وسیله دایرکتیو root مشخص می‌شود. در ریشه سند سایتی که ایجاد کردید به این مقدار اشاره کنید:

root /var/www/example.com/html;

دقت کنید که هر عبارت در Nginx باید با یک نقطه‌ویرگول (;) بسته شود، بدین ترتیب باید همه خطوط را بررسی کنید تا دچار مشکل نشوید.

سپس اقدام به ویرایش server_name می‌کنیم تا با درخواست‌هایی که برای دامنه ما می‌آید، مطابقت داشته باشد. همچنین می‌توانیم هر نام مستعار (alias) که دوست داریم برای آن تعیین کنیم. برای نمایش طرز کار alias ها یک مورد به صورت www.example.com ایجاد می‌کنیم.

server_name example.com www.example.com;

زمانی که کار ویرایش فایل به اتمام رسید، به صورت زیر درخواهد آمد:

server {
    listen 80 default_server;
    listen [::]:80 default_server ipv6only=on;
    root /var/www/example.com/html;
    index index.html index.htm;
    server_name example.com www.example.com;
    location / {
        try_files $uri $uri/ =404;
    }
}

این‌ها همه مواردی بودند که به عنوان پیکربندی مقدماتی لازم داریم. فایل را ذخیره کرده و خارج شوید.

ایجاد فایل بلوک برای سرور دوم

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

sudo cp /etc/nginx/sites-available/example.com /etc/nginx/sites-available/test.com

فایل جدید را با دسترسی root در ویرایشگر خود باز کنید:

sudo nano /etc/nginx/sites-available/test.com

در فایل جدید باید مجدداً دایرکتیو listen را بررسی کنیم. اگر گزینه default_server در فایل قبلی فعال بوده باشد، باید آن را در این فایل حذف کنیم. به علاوه باید گزینه ipv6only=on را نیز حذف کنید چون برای هر ترکیب آدرس/پورت تنها یک بار می‌تواند مورد استفاده قرار گیرد:

listen 80;
listen [::]:80;

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

root /var/www/test.com/html;

server_name را طوری تنظیم کنید که با alias ها مطابقت داشته باشد:

server_name test.com www.test.com;

اینک فایل شما با این تغییرات باید به صورت زیر درآمده باشد:

server {
    listen 80;
    listen [::]:80;
    root /var/www/test.com/html;
    index index.html index.htm;
    server_name test.com www.test.com;
    location / {
        try_files $uri $uri/ =404;
    }
}

زمانی که کار ویرایش فایل به اتمام رسید، آن را ذخیره کرده و ببندید.

مرحله چهارم – فعال‌سازی بلوک‌های سرور و ری‌استارت Nginx

اینک بلوک‌های سرور ایجاد شده‌اند و باید آن‌ها را فعال کنیم. این کار از طریق ایجاد پیوندهای نمادین (symbolic links) از این فایل‌ها به دایرکتوری sites-enabled ممکن می‌شود. Nginx در طی راه‌اندازی اولیه محتوای این دایرکتوری را می‌خواند. با وارد کردن دستور زیر می‌توان این پیوندها را ایجاد کرد:

sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/
sudo ln -s /etc/nginx/sites-available/test.com /etc/nginx/sites-enabled/

اکنون این فایل‌ها در دایرکتوری enabled قرار دارند. با این حال، فایل بلوک سرور پیش‌فرض که از آن به عنوان قالب استفاده کردیم هم در حال حاضر فعال است و با فایل ما که پارامتر default_server را برای آن تنظیم کرده‌ایم، تداخل می‌یابد.

می‌توان فایل بلوک سرور پیش‌فرض را با حذف پیوند نمادین آن غیر فعال کرد. البته این فایل همچنان در دایرکتوری sites-available به منظور ارجاع در موارد آتی باقی می‌ماند؛ اما Nginx هنگام راه‌اندازی اولیه آن را نمی‌خواند:

sudo rm /etc/nginx/sites-enabled/default

همچنین باید یک تنظیم واقعاً کوچک را نیز در فایل پیکربندی Nginx ایجاد کنیم. این فایل را با دستور زیر باز کنید:

sudo nano /etc/nginx/nginx.conf

در این فایل تنها باید یک خط را از حالت کامنت در بیاوریم. دستور زیر را یافته و کامنت آن حذف کنید:

server_names_hash_bucket_size 64;

اکنون آماده هستیم که Nginx را ری‌استارت کرده و تغییرات را فعال کنیم. این کار از طریق دستور زیر ممکن است:

sudo service nginx restart

Nginx اینک می‌تواند هر دو نام دامنه را عرضه کند.

مرحله پنجم – راه‌اندازی فایل میزبان‌های محلی (اختیاری)

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

البته بدین ترتیب بازدیدکنندگان دیگر امکان دیدن سایت شما را نخواهند داشت؛ اما این امکان را می‌یابید که به طور مستقل هر سایت را ببینید و پیکربندی خود را تست کنید. این وضعیت اساساً از طریق پذیرش درخواست‌هایی که معمولاً به DNS برای resolve می‌روند ممکن می‌شود. به جای این کار می‌توانید آدرس IP که می‌خواهید رایانه محلی در هنگام دریافت نام دامنه مراجعه کند را تنظیم کنید.

ابتدا اطمینان حاصل کنید که در طی این مراحل روی یک سرور VPS کار نمی‌کنید؛ بلکه همه مراحل را رایانه محلی اجرا کرده‌اید. همچنین باید دسترسی root داشته باشید، یا عضو گروه administrative سیستم باشید و یا این که قابلیت ویرایش فایل‌های سیستمی را داشته باشید. اگر روی یک رایانه مک یا لینوکس کار می‌کنید می‌توانید فایل مورد نیاز را با وارد کردن دستور زیر ویرایش کنید:

sudo nano /etc/hosts

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

C:\Windows\System32\drivers\etc\hosts

در این مرحله باید آدرس IP عمومی و دامنه‌ای که می‌خواهید سرور به آن مسیریابی کند را بدانید. با فرض این که آدرس IP عمومی شما به صورت 111.111.111.111 باشد، خطوط زیر را به فایل فوق اضافه کنید:

127.0.0.1 localhost
127.0.0.1 guest-desktop
111.111.111.111 example.com
111.111.111.111 test.com

بدین ترتیب همه درخواست‌ها به دامنه example.com و test.com به سرور شما ارسال می‌شود که در صورتی که عملاً این دو دامنه را نداشته باشید، وضعیت مطلوبی به شمار می‌رود.

هنگام اتمام کارِ ویرایش، فایل را ذخیره کرده و خارج شوید.

مرحله ششم – تست نتایج

اینک که همه چیز راه‌اندازی شده است، باید بلوک‌های سرور را تست کنید تا از عملکرد صحیح آن‌ها مطمئن شوید. این کار از طریق بازدید از دامنه‌ها روی مرورگر وب ممکن است:

http://example.com

در مرورگر خود باید صفحه‌ای ببینید که شبیه تصویر زیر است:

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

http://test.com

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

سخن پایانی

اکنون شما می‌توانید بلوک‌های سرور را برای هر دامنه‌ای که می‌خواهید روی سرور خود میزبانی کنید، تنظیم نمایید. عملاً محدودیتی در مورد تعداد بلوک‌های سروری که می‌توان ایجاد کرد وجود ندارد و می‌توانید تا جایی که سخت‌افزار شما اجازه می‌دهد، میزبان سایت‌های مختلف باشید.

منبع: فرادرس