تنظیم سرورهای محیط توزیع نهایی (Production) برای وب اپلیکیشن — راهنمای مقدماتی

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

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

هدف از آموزش

در انتهای این راهنما ما یک سرور توزیع نهایی خواهیم داشت که برای یک اپلیکیشن PHP یعنی وردپرس به عنوان یک مثال آموزشی، بهینه‌سازی شده است و از طریق دامنه https://www.example.com قبل دسترسی خواهد بود. همچنین سرورهای پشتیبانی کننده از سرورهای اصلی اپلیکیشن توزیع یافته را طراحی می‌کنیم. در مرحله نهایی به چیزی مانند تصویر زیر خواهیم رسید (توجه کنید که DNS و پشتیبان‌گیری ریموت در تصویر ارائه نشده است):

در این تنظیمات، سرورهایی که در کادر Application قرار دارند، برای عملکرد صحیح اپلیکیشن ضروری محسوب می‌شوند. علاوه بر برنامه بازیابی و سرور ریموت برای پشتیبان، بقیه اجزا شامل پشتیبان‌گیری، نظارت و تهیه گزارش برای پشتیبانی از اپلیکیشن در مرحله توزیع نهایی ارائه شده‌اند. هر یک از این اجزا بر روی یک سرور اوبونتو 14.04 مجزا نصب شده‌اند و شبکه‌بندی خصوصی بین آن‌ها اجرا شده است.

مجموعه سرورهایی که اپلیکیشن را ارائه می‌کنند با نام‌های میزبانی (hostname) زیر شناخته می‌شوند:

• lb1: متعادل‌کننده بار HAProxy که در آدرس قابل دسترسی است: https://example.com
• app1: سرور اپلیکیشن PHP و آپاچی
• app2: سرور اپلیکیشن PHP و آپاچی
• db1: سرور پایگاه داده مای‌اس‌کیوال

لازم به ذکر است که این نوع از تنظیمات برای نمایش چگونگی ساخت یک اپلیکیشن روی چند سرور ارائه شده است. شما می‌توانید بر اساس نیازهای خودتان از انواع مختلفی از تنظیمات دیگر استفاده کنید. این نوع خاص از تنظیمات سرور دچار مشکل نقطه منفرد شکست (single points of failure) هستند. با افزودن یک متعادل‌کننده بار (load balancer) دیگر (استفاده از DNS به صورت round-robin) و اپلیکیشن سرور پایگاه داده و یا افزودن IP استاتیک که به یک متعادل‌کننده بار فعال یا منفعل اشاره می‌کند، می‌توان از این نقاط منفرد شکست جلوگیری کرد. این موارد همگی در ادامه توضیح داده شده‌اند.

اجزای پشتیبانی

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

• Backups: سرور پشتیبانی گیری Bacula
• Monitoring: سرور نظارت Nagios
• Logging: استک (Elasticsearch, Logstash, Kibana (ELK برای گزارش‌گیری متمرکز

به علاوه سه جزء پشتیبانی کننده زیر در تصویر فوق نمایش نیافته‌اند:

• ns1: سرور نام Bind اصلی برای DNS خصوصی
• ns2: سرور نام Bind دوم برای DNS خصوصی
• remotebackups: سرور ریموت که در منطقه دیگری قرار دارد و برای ذخیره‌سازی کپی‌هایی از پشتیبان‌های Bacula در صورت بروز فاجعه‌های فیزیکی در دیتاسنتر توزیع نهایی تدارک دیده شده است.

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

زمانی که به انتهای این راهنما برسیم و تنظیمات خود را اعمال کنیم، 10 سرور خواهیم داشت. ما همه آن‌ها را همزمان ایجاد می‌کنیم، چون این کار باعث ساده‌تر شدن اموری مانند راه‌اندازی DNS می‌شود. اما شما می‌توانید هر کدام را در مواقع مختلف بنا به ضرورت ایجاد کنید.

دسترسی‌پذیری بالا (اختیاری)

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

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

شبکه مجازی خصوصی (اختیاری)

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

اگر به دنبال یک راه‌حل متن-باز برای VPN باشید می‌توانید Tinc یا OpenVPN را بررسی کنید. در این مورد خاص Tinc که از مسیریابی توری (mesh) استفاده می‌کند راه‌حل بهتری محسوب می‌شود.

پیش‌نیازها

هر سرور اوبونتو 14.04 باید یک superuser به صورت غیر root داشته باشد که بتواند در مراحل مختلف این راهنما، موارد مورد نیاز را نصب کند، چون در این راهنما همه دستورها در همه سرورها از طریق چنین کاربری اجرا می‌شوند.

فیلم آموزش نصب توزیع اوبونتو ۱۶.۰۴ (رایگان) در فرادرس

کلیک کنید

ما فرض می‌کنیم که شما دانش پایه‌ای از مفاهیم مقدماتی امنیت لینوکس دارید و از این رو وارد جزئیات نمی‌شویم. اگر فکر می‌کنید اطلاعات شما در این زمینه کم است می‌توانید از «آموزش مقدماتی مدیریت سرور لینوکس» استفاده کنید.

نام دامنه

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

زمانی که نام دامنه خود را انتخاب کردید، می‌توانید از راهنمای «آموزش مدیریت‌هاست با دایرکت ادمین» برای تنظیم سرورهای نام آن کمک بگیرید.

نام دامنه علاوه بر این که باعث می‌شود کاربرانتان راحت‌تر بتوانند به سرویس‌های شما دسترسی داشته باشند (در قیاس با آدرس IP)؛ بلکه برای بهره‌مند شدن از مزیت‌های اعتبارسنجی هویت دامنه با استفاده از گواهی‌های SSL نیز مفید هستند. این گواهی‌ها باعث ایجاد رمزنگاری ارتباط‌ها بین اپلیکیشن و کاربران می‌شوند.

گواهی SSL

پروتکل TLS/SSL موجب ارائه رمزنگاری و اعتبارسنجی دامنه بین اپلیکیشن و کاربران آن می‌شود و از این رو ما در تنظیمات خود از گواهی SSL استفاده می‌کنیم. در مثال دامنه ما از آن جا که می‌خواهیم کاربران وب‌سایت در آدرس www.example.com به سرویس‌های ما دسترسی داشته باشند، این مسئله را در نام مشترک (Common Name) یا CA گواهی خود قید می‌کنیم. این گواهی بر روی سرور HAProxy در سرور lb1 نصب خواهد شد و از این رو بهتر است کلیدهای گواهی و CSR را روی همین سرور ایجاد کنید.

اگر به یک گواهی نیاز دارید که صرفاً اعتبار هویت را ارائه کند، می‌توانید از خدمات رایگان Let’s Encrypt استفاده کنید. همچنین می‌توانید از گواهی‌های مراجع پولی نیز استفاده کنید. برای کسب اطلاع بیشتر مورد گواهی‌های Let’s Encrypt می‌توانید از راهنمای «تنظیم و راه‌اندازی SSL روی یک وب‌سایت» استفاده کنید. همچنین می‌توانید از یک گواهی SSL خود-امضا (self-signed) نیز استفاده کنید که با استفاده از دستور زیر قابل تولید است:

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ~/www.example.com.key -out ~/www.example.com.crt

مراحل راه‌اندازی محیط توزیع نهایی اپلیکیشن

اینک که موارد مقدماتی برای آماده‌سازی محیط توزیع را انجام دادیم، می‌توانیم یک طرح کلی برای رسیدن به این تنظیمات تنظیم کنیم.

فیلم آموزش تغییر سریع DNS در ویندوز با نرم افزار دی ان اس جامپر در فرادرس

کلیک کنید

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

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

1. سرور پایگاه داده
2. سرورهای اپلیکیشن
3. متعادل‌کننده بار

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

پس از این که طرح‌های مختلف بازیابی خود را آماده کردیم، می‌توانیم با راه‌اندازی سرور backups کار خود را ادامه دهیم. پس از آن می‌توانیم سرور monitoring را راه‌اندازی کنیم تا مطمئن شویم که سرورها و سرویس‌های ما در وضعیت مطلوب هستند. در نهایت سرور centralized logging را راه‌اندازی می‌کنیم که به ما امکان مشاهده لاگ ها، عیب‌یابی مشکلات و شناسایی روندها را می‌دهد.

نتیجه‌گیری

اینک که طرح کلی ما آماده شده است، آماده هستیم تا تنظیمات محیط توزیع نهایی اپلیکیشن خود را پیاده‌سازی کنیم. به خاطر داشته باشید که گرچه این تنظیمات کاملاً عملیاتی هستند؛ اما این تنها یک نمونه برای ارائه اطلاعات کاملاً روشن به شما است و باید از آن نکاتی برای بهبود تنظیمات محیط توزیع نهایی خود بیاموزید. در بخش بعدی این آموزش مراحل عملی راه‌اندازی محیط توزیع نهایی اپلیکیشن را آغاز خواهیم کرد.

اگر این نوشته مورد توجه‌تان قرار گرفته است، آموزش‌های زیر نیز به شما پیشنهاد می‌شوند:

• مجموعه آموزش های طراحی و برنامه نویسی وب
• Node.js و وب‌ هوک های گیت‌ هاب — راهنمای به‌ روز رسانی پروژه‌ ها از راه دور
• مجموعه آموزش های پروژه محور برنامه نویسی
• آموزش مقدماتی مدیریت سرور لینوکس (Linux CentOS)
• چگونه می‌توانیم یک محیط توسعه و سرور مجازی برای برنامه نویسی وب بسازیم؟
• آموزش آشنایی با سرورهای متصل (Linked Server) و پیاده سازی آن در SQL Server
• آموزش مقدمات ارتباط با سرور در دیتابیس سمت سرور در اندروید

==