بهترین روشهای آپلود پروژههای ASP.NET Core روی Deployment - VPS
«بهترین» روش استقرار چیست؟ پاسخ این است: «بستگی دارد.» بهترین روش به سیستمعامل VPS شما (لینوکس یا ویندوز)، سطح مهارت فنی شما، و نیازمندیهای پروژه (مانند مقیاسپذیری و انزوا) بستگی دارد.
در این مقاله، ما سه روش اصلی و مدرن برای استقرار پروژههای ASP.NET Core روی VPS را به همراه مزایا، معایب و ملاحظات هر یک بررسی خواهیم کرد.
مفاهیم کلیدی: Kestrel و Reverse Proxy
قبل از ورود به روشها، درک دو مفهوم اساسی ضروری است:
۱. Kestrel (کِسترِل):
ASP.NET Core با یک وب سرور داخلی، سبک و بسیار پرسرعت به نام Kestrel ارائه میشود. Kestrel مسئول اجرای کد برنامه شما و پاسخدهی به درخواستهای HTTP است. با این حال، Kestrel برای قرار گرفتن مستقیم در لبه اینترنت (Edge-Facing) طراحی نشده است. اگرچه در نسخههای اخیر بسیار امنتر شده، اما فاقد بسیاری از ویژگیهای یک وب سرور کامل مانند مدیریت پیشرفته SSL، فشردهسازی، Caching، محدودسازی درخواستها (Rate Limiting) و میزبانی چندین سایت روی یک پورت است.
۲. Reverse Proxy (پراکسی معکوس):
اینجاست که یک وب سرور قدرتمند مانند Nginx، Apache (در لینوکس) یا IIS (در ویندوز) وارد میشود. این سرورها به عنوان یک پراکسی معکوس عمل میکنند:
-
درخواستهای ورودی از اینترنت (پورتهای 80 و 443) را دریافت میکنند.
-
وظایف سنگین مانند خاتمه دادن به SSL (SSL Termination)، فشردهسازی، و کش کردن فایلهای استاتیک را انجام میدهند.
-
درخواستهای پویا را به سرور Kestrel (که معمولاً روی یک پورت داخلی مانند 5000 یا 5001 در حال اجراست) هدایت (Forward) میکنند.
-
پاسخ را از Kestrel دریافت کرده و به کاربر بازمیگردانند.
استفاده از این معماری (Reverse Proxy + Kestrel) استاندارد طلایی برای استقرار ASP.NET Core در محیط پروداکشن است.
روش اول: استقرار روی لینوکس (Nginx + Kestrel as a Service)
این روش، محبوبترین، مقرونبهصرفهترین و از نظر عملکرد، بهینهترین راه برای میزبانی ASP.NET Core است. ما از Nginx به عنوان پراکسی معکوس و systemd (مدیر سرویس استاندارد در اکثر توزیعهای لینوکس) برای مدیریت فرآیند برنامه استفاده میکنیم.
مراحل کلیدی:
۱. آمادهسازی سرور:
-
یک VPS با توزیع لینوکس (مانند Ubuntu 22.04) تهیه کنید.
-
فایروال (مانند ufw) را فعال کرده و پورتهای SSH (22)، HTTP (80) و HTTPS (443) را باز کنید.
-
ASP.NET Core Runtime را نصب کنید (نه لزوماً SDK کامل).
# مثال برای اوبونتو sudo apt-get update sudo apt-get install -y aspnetcore-runtime-8.0
۲. انتشار (Publish) پروژه:
در دستگاه لوکال خود، پروژه را برای استقرار پابلیش کنید:
dotnet publish --configuration Release
این دستور یک پوشه در bin/Release/net8.0/publish ایجاد میکند که شامل تمام DLLها و فایلهای مورد نیاز برای اجرا است.
۳. انتقال فایلها به VPS:
فایلهای موجود در پوشه publish را با استفاده از scp یا rsync به سرور خود منتقل کنید (مثلاً به مسیر /var/www/my-app).
۴. ایجاد سرویس systemd:
برای اینکه برنامه شما به صورت دائمی در پسزمینه اجرا شود و در صورت شکست (Crash) یا راهاندازی مجدد سرور، به طور خودکار ریاستارت شود، یک فایل سرویس systemd میسازیم:
-
فایلی در مسیر /etc/systemd/system/my-app.service ایجاد کنید.
[Unit] Description=My ASP.NET Core Application [Service] # مسیر پوشهای که فایلها را در آن کپی کردید WorkingDirectory=/var/www/my-app # دستور اجرا (مطمئن شوید مسیر dotnet runtime صحیح است) ExecStart=/usr/bin/dotnet /var/www/my-app/MyApp.dll Restart=always # در صورت کرش، پس از 5 ثانیه ریاستارت کن RestartSec=5 KillSignal=SIGINT SyslogIdentifier=my-app # برنامه را تحت این کاربر اجرا کن (برای امنیت بهتر) User=www-data Environment=ASPNETCORE_ENVIRONMENT=Production Environment=DOTNET_PRINT_TELEMETRY_MESSAGE=false [Install] WantedBy=multi-user.target -
سرویس را فعال و اجرا کنید:
sudo systemctl enable my-app.service # فعالسازی برای بوت sudo systemctl start my-app.service # اجرای سرویس sudo systemctl status my-app.service # بررسی وضعیت
۵. پیکربندی Nginx:
-
ابتدا Nginx را نصب کنید: sudo apt-get install nginx.
-
یک فایل پیکربندی برای سایت خود در /etc/nginx/sites-available/my-app بسازید:
server { listen 80; listen [::]:80; server_name your-domain.com www.your-domain.com; # دامنه خود را جایگزین کنید location / { # آدرس Kestrel (مطابق با appsettings.json یا پیشفرض) proxy_pass http://localhost:5000; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection keep-alive; proxy_set_header Host $host; proxy_cache_bypass $http_upgrade; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } } -
این پیکربندی را فعال کنید:
sudo ln -s /etc/nginx/sites-available/my-app /etc/nginx/sites-enabled/
-
پیکربندی Nginx را تست و ریاستارت کنید:
sudo nginx -t
sudo systemctl restart nginx
۶. راهاندازی SSL (بسیار مهم):
از Certbot برای دریافت گواهینامه SSL رایگان از Let's Encrypt استفاده کنید:
sudo apt-get install certbot python3-certbot-nginx
sudo certbot --nginx -d your-domain.com
Certbot به طور خودکار فایل پیکربندی Nginx شما را برای استفاده از HTTPS (پورت 443) و ریدایرکت HTTP به HTTPS بهروزرسانی میکند.
-
مزایا: عملکرد بسیار بالا، هزینه پایین (لینوکس رایگان است)، کنترل کامل، اکوسیستم غنی لینوکس.
-
معایب: نیاز به آشنایی با خط فرمان لینوکس، پیکربندی دستی (اگرچه یکبار انجام میشود).
روش دوم: استقرار روی ویندوز (IIS)
این روش برای تیمهایی که تجربه زیادی در اکوسیستم ویندوز سرور دارند و با محیط گرافیکی IIS راحتتر هستند، ایدهآل است.
مراحل کلیدی:
۱. آمادهسازی سرور:
-
یک VPS با Windows Server (مانند 2019 یا 2022) تهیه کنید.
-
نقش (Role) Web Server (IIS) را از طریق Server Manager نصب کنید.
-
مهمترین مرحله: .NET Core Hosting Bundle را دانلود و نصب کنید. این بسته شامل Runtime مورد نیاز و ASP.NET Core Module (ANCM) است. ANCM ماژولی است که به IIS اجازه میدهد درخواستها را به Kestrel پراکسی کند. (پس از نصب، سرور را ریاستارت کنید).
۲. انتشار (Publish) پروژه:
مانند روش قبل، پروژه را با dotnet publish پابلیش کنید. همچنین میتوانید از قابلیت Web Deploy در ویژوال استودیو برای پابلیش مستقیم به IIS استفاده کنید.
۳. پیکربندی IIS:
-
IIS Manager را باز کنید.
-
در قسمت Application Pools، یک Application Pool جدید بسازید. مهمترین تنظیم این است که .NET CLR Version را روی No Managed Code قرار دهید. (چرا؟ چون IIS فقط یک پراکسی است و کد داتنت را مستقیماً اجرا نمیکند، Kestrel این کار را انجام میدهد).
-
در قسمت Sites، یک New Website ایجاد کنید.
-
Physical Path را روی پوشه publish پروژه خود تنظیم کنید.
-
Application Pool ساخته شده در مرحله قبل را به این سایت تخصیص دهید.
-
Bindingهای لازم برای دامنه خود (پورت 80) را تنظیم کنید.
۴. فایل web.config:
وقتی پروژه را پابلیش میکنید، معمولاً یک فایل web.config به طور خودکار ایجاد میشود. این فایل به IIS میگوید که چگونه برنامه را با استفاده از ANCM اجرا کند:
-
Hosting Mode1l:
-
InProcess: (پیشفرض در ASP.NET Core 3.1 و جدیدتر) عملکرد بهتری دارد زیرا Kestrel مستقیماً درون فرآیند IIS (w3wp.exe) اجرا میشود.
-
OutOfProcess: IIS درخواستها را به یک فرآیند dotnet.exe جداگانه (Kestrel) پراکسی میکند. این مدل شبیهتر به Nginx در لینوکس است.
-
۵. راهاندازی SSL:
در IIS Manager، میتوانید از بخش Server Certificates برای Import کردن یک گواهینامه SSL خریداری شده یا استفاده از ابزارهایی مانند win-acme (معادل Certbot برای ویندوز) برای دریافت SSL رایگان از Let's Encrypt استفاده کنید.
-
مزایا: محیط گرافیکی و آشنا برای مدیران ویندوز، یکپارچگی کامل با اکوسیستم مایکروسافت، مدیریت آسانتر چندین سایت با GUI.
-
معایب: هزینه لایسنس ویندوز سرور، مصرف منابع بیشتر (RAM و CPU) نسبت به لینوکس.
روش سوم: کانتینرسازی با Docker
این روش مدرنترین، قابلحملترین و ایزولهترین روش استقرار است. شما برنامه و تمام وابستگیهای آن را در یک «کانتینر» پکیج میکنید و آن کانتینر را در هر جایی (لینوکس یا ویندوز) که Docker نصب باشد، اجرا میکنید.

مراحل کلیدی:
۱. نوشتن Dockerfile:
یک فایل به نام Dockerfile (بدون پسوند) در ریشه پروژه خود ایجاد کنید. استفاده از Multi-Stage Build بهترین روش است:
# --- مرحله اول: ساخت (Build Stage) ---
# از ایمیج رسمی SDK برای ساخت پروژه استفاده میکنیم
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
# کپی کردن فایلهای پروژه و Restore کردن پکیجها
COPY *.csproj .
RUN dotnet restore
# کپی کردن بقیه سورسکد و ساخت پروژه
COPY . .
RUN dotnet publish "MyApp.csproj" -c Release -o /app/publish
# --- مرحله دوم: نهایی (Final Stage) ---
# از ایمیج سبک Runtime برای اجرای برنامه استفاده میکنیم
FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS final
WORKDIR /app
COPY --from=build /app/publish .
# پورت 8080 را در داخل کانتینر Expose میکنیم
# (Kestrel به این پورت گوش میدهد)
ENV ASPNETCORE_URLS=http://+:8080
EXPOSE 8080
# دستور اجرای برنامه هنگام استارت کانتینر
ENTRYPOINT ["dotnet", "MyApp.dll"]
-
چرا Multi-Stage؟ ایمیج نهایی فقط شامل Runtime و فایلهای پابلیش شده است و SDK سنگین در آن وجود ندارد. این باعث میشود ایمیج نهایی بسیار کوچکتر و امنتر باشد.
۲. آمادهسازی VPS:
-
یک VPS لینوکسی (ترجیحاً) تهیه کنید.
-
Docker Engine را روی آن نصب کنید.
۳. ساخت (Build) و پوش (Push) ایمیج:
-
در دستگاه لوکال خود، ایمیج را بسازید:
docker build -t my-app-image:latest .
-
(اختیاری اما پیشنهادی) ایمیج را به یک رجیستری (مانند Docker Hub یا GitLab Registry) پوش کنید:
docker push your-registry/my-app-image:latest
۴. اجرای کانتینر روی VPS:
-
اگر ایمیج را پوش کردهاید، ابتدا آن را روی VPS دریافت (Pull) کنید.
-
کانتینر را اجرا کنید:
docker run -d \ --name my-app-container \ -p 80:8080 \ --restart always \ your-registry/my-app-image:latest-
-d: اجرا در پسزمینه (Detached mode).
-
--name: یک نام برای کانتینر.
-
-p 80:8080: مهم: پورت 80 سرور VPS (ورودی) را به پورت 8080 داخل کانتینر (جایی که Kestrel گوش میدهد) مپ میکند.
-
--restart always: معادل systemd؛ اگر کانتینر متوقف شد، داکر آن را ریاستارت میکند.
-
۵. استفاده از Docker Compose (توصیه شده):
برای مدیریت آسانتر، میتوانید از docker-compose.yml استفاده کنید. این فایل به شما اجازه میدهد برنامه خود، دیتابیس (مانند Postgres) و حتی یک پراکسی معکوس (Nginx) را به صورت هماهنگ تعریف و اجرا کنید.
-
مزایا: انزوا (Isolation) کامل وابستگیها، قابلیت حمل (Portability) (روی هر سیستمی که داکر دارد اجرا میشود)، راهاندازی سریع و یکسان، مدیریت آسانتر میکروسرویسها.
-
معایب: نیاز به یادگیری مفاهیم داکر، پیچیدگی اولیه بیشتر، لایه اضافه (Overhead) اندک.
اتوماسیون با CI/CD (روش مکمل)
هیچکدام از روشهای بالا «بهترین» نیستند اگر شما فایلها را به صورت دستی (مثلاً با scp یا FTP) به سرور منتقل کنید. این کار مستعد خطای انسانی است.
بهترین روش، ترکیب یکی از سه روش بالا (خصوصاً لینوکس یا داکر) با یک پایپلاین CI/CD (Continuous Integration / Continuous Deployment) است.
-
ابزارها: GitHub Actions (بسیار محبوب و ساده)، GitLab CI/CD، Jenkins.
-
فرآیند:
-
شما کد خود را به ریپازیتوری (مثلاً main branch) پوش میکنید.
-
CI (ادغام): ابزار CI/CD (مثلاً GitHub Actions) به طور خودکار کد را دریافت میکند، dotnet build و dotnet test را اجرا میکند تا از سلامت کد مطمئن شود.
-
CD (استقرار):
-
اگر از روش لینوکس (روش اول) استفاده میکنید: اکشن، پروژه را dotnet publish کرده، فایلها را با rsync به VPS منتقل میکند و سپس با ssh دستور sudo systemctl restart my-app.service را اجرا میکند.
-
اگر از داکر (روش سوم) استفاده میکنید (بهترین حالت): اکشن، Dockerfile را بیلد میکند، ایمیج جدید را به رجیستری پوش میکند. سپس با ssh به VPS وصل شده و دستور میدهد که ایمیج جدید را docker pull کرده و کانتینر را با ایمیج جدید ریاستارت کند (ابزارهایی مانند watchtower میتوانند این کار را خودکار کنند).
-
-
استفاده از CI/CD فرآیند استقرار شما را قابل تکرار، سریع و ایمن میکند.
نتیجهگیری: کدام روش برای شما بهترین است؟
| سناریو | بهترین روش پیشنهادی |
| تازهکار در VPS، آشنا با ویندوز: | روش ۲ (ویندوز + IIS). به شما اجازه میدهد با محیط آشنای GUI کار کنید. |
| به دنبال بهترین عملکرد و کمترین هزینه: | روش ۱ (لینوکس + Nginx + systemd). استاندارد صنعتی برای اکثر پروژههای جدید. |
| نیاز به انزوا، مقیاسپذیری و میکروسرویس: | روش ۳ (داکر). مدرنترین و انعطافپذیرترین روش برای آینده. |
| تیم حرفهای با هر سطح مهارت: | روش ۳ (داکر) + اتوماسیون CI/CD. این ترکیب، قابل اطمینانترین و مدیریتپذیرترین زیرساخت را فراهم میکند. |
در نهایت، ASP.NET Core به شما آزادی انتخاب میدهد. سرمایهگذاری برای یادگیری استقرار روی لینوکس (چه به صورت مستقیم و چه با داکر) در بلندمدت بیشترین بازده را برای شما خواهد داشت، زیرا اکوسیستم ابری مدرن به شدت به لینوکس و کانتینرها متکی است.
0 نظر
هنوز نظری برای این مقاله ثبت نشده است.