بررسی روند deployment در اپلیکیشن های Asp.Net Core

در آخرین قسمت از این فصل قرار است در رابطه با روند deployment در اپلیکیشن های Asp.Net Core صحبت کنیم. در اپلیکیشن‌های Asp.Net Core روال Deploy کردن پیچیدگی ها و ویژگی های منحصر به فرد خود را دارد که می بایست با آنها آشنا بشویم.

بررسی Deployment در Asp.Net Core

به طور کلی در روند Deployment کردن یک اپلیکیشن با Asp.Net Core فارغ از اینکه در چه فضایی میزبانی و یا Host خواهند شد چندین مرحله وجود دارد. اولین مرحله Publish کردن اپلیکیشن مورد نظر است که با استفاده از دستور dotnet publish که یکی از دستورات CLI است می توانید آن را انجام بدهید. این موضوع باعث می‌شود که برنامه کامپایل شده و تمامی فایل های مورد نیاز برای اجرا شدن آن در فولدر مشخص شده توسط همین دستور dotnet publish قرار بگیرد. زمانی که اپلیکیشن را با استفاده از ویژوال استودیو Publish می کنید این مرحله به طور خودکار برای شما انجام خواهد شد. در فولدری که توسط روند Publish شدن برنامه مشخص می کنید فایلهای با پسوند exe و dll قرار می‌گیرند و البته دیگر dependency های برنامه نیز حضور پیدا خواهند کرد. یک اپلیکیشن خودشمول یا اصطلاحا self-contained نامیده می‌شود شامل نسخه‌ای از NET runtime. نیز خواهد بود. اپلیکیشن های Asp.Net Core شامل فایل‌های configuration و فایلهای static client asset ها و همچنین MVC view ها خواهند بود.

اپلیکیشن های Asp.Net Core در واقع console application هایی هستند که می بایست در زمان boot شدن سرور آغاز به کار کرده و در زمان crash کردن سرور دوباره اجرا و یا restart بشوند. یک process manager می تواند برای خودکار کردن این فرایند مورد استفاده قرار بگیرد. معمول‌ترین process manager ها برای Asp.Net Core بر روی لینوکس شامل Nginx و آپاچی و بر روی ویندوز شامل IIS و ویندوز سرور می باشند.

علاوه بر process manager ها اپلیکیشن‌های Asp.Net Core ممکن است از reverse proxy server نیز استفاده کنند. یک reverse proxy server در واقع HTTP request ها را از اینترنت دریافت کرده و آنها را پس از انجام کارهای ابتدایی تحویل Kestrel می‌دهد. reverse proxy server یک لایه امنیتی برای اپلیکیشن لحاظ می‌نماید. نکته دیگر اینکه Kestrel امکان میزبانی کردن چندین اپلیکیشن بر روی یک پورت یکسان را نخواهد داشت بنابراین تکنیک هایی از قبیل Host header نمی‌تواند در استفاده کردن از Kestrel مورد استفاده قرار بگیرد. تصویر زیر نیز این موضوع را به شما نشان خواهد داد.

یک سناریو دیگر که در آن می‌توان از reverse proxy server ها استفاده کرد ایجاد امنیت برای چندین اپلیکیشن با استفاده از SSL/HTTPS می باشد. در چنین مواردی فقط reverse proxy server نیاز به SSL خواهد داشت. ارتباط بین reverse proxy server و Kestrel می‌تواند همچنان با استفاده از HTTP اتفاق بیفتد. این موضوع نیز در تصویر زیر نشان داده شده است:

یکی از روش های محبوب دیگر برای میزبانی کردن یک اپلیکیشن Asp.Net Core استفاده کردن از Docker container می باشد که در بسته ی آموزش ویدئویی داکر (Docker) و Container در پروژه های ASP.NET Core و بسته ی آموزش ویدئویی توسعه وب اپلیکیشن ASP.NET Core و داکر (Docker) از آن بیشتر صحبت کرده ایم. با استفاده از Docker container شما می توانید هم اپلیکیشن را به صورت Local میزبانی کنید و هم آن را به Azure و برای میزبانی تحت Cloud انتقال بدهید. استفاده از Docker container باعث می شود که یک Container ‌، Application Code شما را شامل شده و برنامه را بر روی Kestrel اجرا کند. علاوه بر این موضوع استفاده کردن از reverse proxy server نیز در لحاظ نمودن یک Docker container اتفاق خواهد افتاد. اگر میخواهید که برنامه را بر روی Azure میزبانی کنید می‌توانید از Microsoft Azure Application Gateway به عنوان یک virtual appliance تخصصی برای فراهم کردن چندین سرور سرویس مختلف استفاده نمایید. Microsoft Azure Application Gateway علاوه بر ایفای نقش یک reverse proxy server برای اپلیکیشن ها، سرویس های دیگری را نیز در اختیار شما قرار می دهند که شامل موارد زیر هستند:

  • HTTP load balancing
  • (SSL offload (SSL only to Internet
  • End to End SSL
  • Multi-site routing
  • Web application firewall
  • پشتیبانی از Websocket
  • گزینه های پیشرفته رفع اشکال و یا diagnostics