مقالات و آموزشهای بسیاری در حوزه توسعه اپلیکیشن دات نتی تالیف شده اند، از بایدها و نبایدهای معماری، تا چگونگی کد نویسی و شناخت فریمورک ها و امثالهم. اما در این بین کمتر به موضوع publish کردن اپلیکیشن و همچنین باید و نبایدهای deploy اپلیکیشن پرداخته شده است.
اگر تاکنون دراین خصوص مطالعه مستقلی نداشته اید، و یا صرفا به روال های معمول اکتفا کرده اید و کارتان هم راه افتاده است، یا خیلی خوش شانس هستید و در جایی مشغول به کار هستید که افراد دیگری جور ندانستن شما را در تیم کشیده اند، و یا کار جدی انجام نداده اید!
سلام، من محمد عباسی هستم. در این مقاله با ذره بین به تمام وجه های publish و deploy اپلیکیشن های دات نتی میپردازم و در این راه از مقالات، کتب و تجربیاتم استفاده میکنم.
دامنه این مقاله در حوزه برنامه نویسی میماند، و به هیچ عنوان وارد مباحثی که مختص به دوستان عملیاتی و مدیرسیستمی هستند، نمیشود.
فهرست مطالب
بعد از اینکه یک وب اپلیکیشنی را توسعه دادیم و آن را آماده استفاده کردیم، چه کاری باید انجام دهیم؟ جواب هاست کردن است. ما باید اپلیکیشنی را که توسعه دادیم را روی یک سرور هاست کنیم تا در دسترس دیگران قرار بگیرد. اساسا به فرایند نصب و دیپلوی اپلیکیشن روی یک سرور را هاست کردن (hosting) میگویند.
هر زمان که یک وب اپلیکیشن ایجاد میکنید، بطور پیشفرض یک وب سرور بواسطه دات نت درون خودش قرار میگیره بنام کسترل (Kestrel) که تمام آنچه که برای سرویس دهی وب نیاز هست رو پوشش میدهد.
کسترل این امکان رو برای اپلیکیشن های دات نتی ایجاد میکنه که بصورت cross platform روی سیستم عامل های مختلف نظیر ویندوز، مک و لینوکس اجرا بشند.
کسترل با استفاده از کتابخانه libuv ساخته شده، همون کتابخانه ای که node هم ازش استفاده میکنه.
توی کلاس Program.cs و در متد ConfigureWebHostDefaults یک اکستنشن متد بنام UseKestrel صدا زده میشه که امکان استفاده از کسترل رو برای ما مهیا میکنه.
با این تعاریف اشتباه نیست که وب سرور کسترل رو بخشی از اپلیکیشن دات نت بدونیم، نه یک تیکه جدا از آن. البته این یکپارچگی به معنای در هم تنیدگی نیست. معماری فریمورک ASP.NET بسیار ماژولار است و امکان تغییر هر جز آن وجود دارد که در ادامه هم به آن اشاره میکنم.
برای ختم کلام در رابطه با خود کسترل، فقط این نکته را اضافه کنم که این وب سرور، همانی است که آبجکت HttpContext را برای ما ایجاد میکند و تحویل Middlewareهای پایینی میدهد، و Respone را از آنها تحویل میگیرد و به کاربر برمیگرداند.
همانطور که عرض شد، کسترل درخواست را دریافت میکند و به بدنه اپلیکیشن برای تولید پاسخ میفرستد. (که در تصویر زیر شاهد آن هستید).
این مدل از هاست کردن، فرایندهای وب سرور و پراکسی را از خود اپلیکیشن جدا میکند، این جدا سازی هم این امکان را میدهد که اپلیکیشن بدون آنکه خودش تغییری داشته باشد، بتواند در محیط های مختلف هاست شود.
از آنجاییکه که در عکس تصویر یک Reverse Proxy (قدم های 1 و 7) مشاهده شد، و در تعریف بالا یک جدا سازی بین وب سرور و پراکسی لحاظ کردیم، لازمه که در این خصوص صحبت کنیم.
ما میتوانیم از کسترل برای ارتباط مستقیم با کلاینت استفاده کنیم، و همچنین میتوانیم بین کسترل و کلاینت یک سرور واسط قرار دهیم که این ارتباط را برقرار کند. به این سرور واسط Reverse Proxy میگویند. اما چرا باید این کار رو انجام داد؟ یا سوال دقیق تر اینکه چه میشود که چنین نیازمندی ای بوجود میاید؟ چرا که بایدی در کار نیست، همانطور که عرض شد کسترل میتواند بصورت مستقیم با کلاینت ارتباط برقرار کند.
پرسش گر: ببخشید مهندس، یکم یواش تر! من اصلا نفهمیدم که این Reverse Proxy چی بود!
پاسخ: ببینید در اصل Reverse Proxy برنامه ای است که ریکوئست را از اینترنت میگیرد، و بعد خودش به وب سرور اپلیکیشن مدنظر ما ریکوئست میزنه. اینکار در مقابل با عملی است که اپلیکیشن ما مستقیما از اینترنت ریکوئست رو دریافت کنه.
پرسش گر: فقط اینترنت؟
پاسخ: نه دیگه، منظور بیرون از شبکه داخلی هست. ریورس پراکسی اساسا در لبه یک شبکه (یا حتا یک سرور) قرار میگیرد، و تنها پل ارتباطی اون شبکه (یا سرور) با بیرون میشه. هر ریکوئستی که از بیرون (حالا چه اینترنت، و چه شبکه داخلی بزرگتر) بخواهد به این شبکه ما (یا سرور ما) برسد، به دست ریورس پراکسی میرسد، و اون تصمیم میگیرد که با این ریکوئست چکار بکند. که در حالت معمول اون روکوئست رو میفرسته (forward) به وب سرور اپلیکیشن مدنظر، و پاسخ تولید شده توسط اپلیکیشن رو هم میگیره و پس میده به کلاینت.
پرسش گر: خب چرا به چنین چیزی نیاز هست؟
پاسخ: یکم زبان به کام بگیرید، داشتم همین را توضیح میدادم که سوال مطرح کردید!
همانطور که توضیح داده شد، ما میتوانیم در یک سرور (یا یک شبکه ای از سرورها) چند اپلیکیشن داشته باشیم، و در لبه یا پل ارتباطی آن سرور (یا شبکه) یک Reverse Proxy ایجاد کنیم که از بیرون (حال چه اینترنت چه شبکه ای دیگر) از طریق آن ریورس پراکسی با اپلیکیشن های ما در ارتباط باشند. از آنجاییکه اپلیکیشن های ما هم در پلتفرم وب هستند، پس قضیه وب سرور منتقی نیست! صرفا یک لایه (ریورس پراکسی) اضافه شده است (تصویر زیر). و به عبارت دقیق تر ریورس پراکسی رابط وب سرور و کلاینت است.
این مدل از هاست کردن اپلیکیشن (که یک ریورس پراکسی مابین قرار بگیرد) مزایایی دارد:
با همه این مزایا، استفاده از ریورس پراکسی همیشه گل و بلبل نیست! گاهی تنظیمات خود ریورس پراکسی میتواند پیچیده باشد و هم اینکه اضافه شدن یک لایه اضافه میتونه سرعت رو تحت تاثیر قرار دهد.
پرسش گر: تا اینجا که من فهمیدم، ریورس پراکسی یکسری مزایا دارد، اما به هر جهت یک لایه ریکوئیست را دریافت میکند، میفرستد سمت وب سرور درون اپلیکیشن، و آن ریسپانس را آماده میکند. در صورتیکه خود وب سرور اپلیکیشن میتوانست مستقیما همین کار را بکند تا سرعت عملکرد آن بخاطر حذف این لایه بهتر باشد.
پاسخ: بله، همینطور است. مزایایی که از آن صحبت شد، در گرو وجود این لایه اضافه است، و خب مشخصا اگر این لایه اضافه نباشد، شاید ما کمی بهبود سرعت داشته باشیم، اما از آن مزایا خبری نیست. ولی باز هم برای نتیجه گیری زود است، در مقاله بعدی من این بحث را مجدد باز میکنم، و در آنجا سعی میکنم به موراد بیشتری اشاره کنم تا قدرتمان برای تصمیم گیری افزایش یابد.
برای هاست کردن اپلیکیشن های ASP.NET Core ما به هر دو روش که در بالا به آن اشاره شد، میتوانیم عمل کنیم.
در قسمت بعدی به این موضوع میپردازم و مفاهیم InProcess و OutOfProcess را شرح میدهم.
