اجرای ASP.NET Core MVC روی لینوکس: ادغام با NGINX، Systemd، Load Balancing و HTTPS

زبان های برنامه نویسی ASP.NET CORE MVC

اجرای ASP.NET Core MVC روی لینوکس: ادغام با NGINX، Systemd، Load Balancing و HTTPS

9 بازدید 0 نظر ۱۴۰۴/۰۴/۱۸

این مقاله به صورت جامع به فرایند ادغام ASP.NET Core MVC با NGINX برای استقرار در محیط لینوکس می‌پردازد. ما مراحل عملی را با استفاده از Systemd برای مدیریت سرویس‌ها، پیاده‌سازی Load Balancing برای افزایش مقیاس‌پذیری و دسترس‌پذیری، و پیکربندی HTTPS با Let's Encrypt برای تضمین امنیت ارتباطات، بررسی خواهیم کرد. هدف این راهنما، ارائه یک نقشه راه عملی برای توسعه‌دهندگان و مدیران سیستم است تا بتوانند پروژه‌های ASP.NET Core خود را به شیوه‌ای کارآمد و امن مستقر کنند.

چرا ASP.NET Core MVC و NGINX روی لینوکس؟

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

کراس‌پلتفرم بودن ASP.NET Core: ASP.NET Core برخلاف نسخه‌های قبلی ASP.NET، قابلیت اجرا روی سیستم‌عامل‌های مختلف از جمله لینوکس را دارد که انعطاف‌پذیری زیادی را فراهم می‌کند.
کارایی بالا: NGINX به دلیل معماری رویدادمحور و غیرمسدودکننده خود، قادر به مدیریت تعداد زیادی اتصال همزمان با حداقل منابع است. این ویژگی آن را به انتخابی ایده‌آل برای پراکسی کردن ترافیک به سمت ASP.NET Core تبدیل می‌کند.
امنیت و مقیاس‌پذیری: NGINX با قابلیت‌های پیشرفته‌ای نظیر SSL/TLS termination، لودبالانسینگ و فایروال وب اپلیکیشن (با استفاده از ماژول‌های Third-party)، امنیت و مقیاس‌پذیری اپلیکیشن را به طرز چشمگیری افزایش می‌دهد.
مدیریت آسان: ابزارهایی مانند Systemd در لینوکس، مدیریت سرویس‌های ASP.NET Core را ساده می‌کنند و اطمینان می‌دهند که اپلیکیشن شما همیشه در حال اجراست.
کاهش هزینه‌ها: استفاده از لینوکس و NGINX، به دلیل ماهیت متن‌باز و رایگان بودنشان، می‌تواند هزینه‌های زیرساختی را در مقایسه با سیستم‌عامل‌ها و وب‌سرورهای تجاری به طور قابل توجهی کاهش دهد.

پیش‌نیازها

قبل از شروع، مطمئن شوید که پیش‌نیازهای زیر را روی سرور لینوکس خود (به عنوان مثال Ubuntu یا CentOS) نصب کرده‌اید:

SDK یا Runtime دات‌نت Core: اطمینان حاصل کنید که نسخه مورد نیاز دات‌نت برای اپلیکیشن ASP.NET Core شما نصب شده است.
NGINX: وب‌سرور NGINX باید روی سیستم شما نصب باشد.
دسترسی SSH: برای اتصال به سرور و اجرای دستورات.
نام دامنه (Domain Name): برای پیکربندی HTTPS و دسترسی عمومی به اپلیکیشن.
پروژه ASP.NET Core MVC: یک پروژه ASP.NET Core MVC آماده برای استقرار.

مرحله ۱: انتشار (Publish) پروژه ASP.NET Core MVC

اولین گام، انتشار پروژه ASP.NET Core شما برای استقرار است. این کار باعث ایجاد فایل‌های اجرایی و وابستگی‌های لازم در یک پوشه جداگانه می‌شود.

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

dotnet publish -c Release -o /var/www/mywebapp

-c Release: پروژه را در حالت Release (بهینه‌سازی‌شده برای تولید) منتشر می‌کند.
-o /var/www/mywebapp: مسیر خروجی فایل‌های منتشر شده را مشخص می‌کند. شما می‌توانید این مسیر را به دلخواه خود تغییر دهید.

نکته: پس از انتشار، اطمینان حاصل کنید که پوشه mywebapp در مسیر /var/www/ ایجاد شده و فایل‌های منتشر شده (شامل DLLهای اپلیکیشن و فایل اجرایی اصلی) در آن قرار دارند.

مرحله ۲: ایجاد Systemd Service برای ASP.NET Core

برای اطمینان از اینکه اپلیکیشن ASP.NET Core شما به صورت مداوم اجرا می‌شود و پس از راه‌اندازی مجدد سرور به طور خودکار شروع به کار می‌کند، از Systemd استفاده می‌کنیم.

یک فایل سرویس جدید در مسیر /etc/systemd/system/ ایجاد کنید:

sudo nano /etc/systemd/system/mywebapp.service

محتوای زیر را در فایل mywebapp.service قرار دهید. حتماً مقادیر User, WorkingDirectory و ExecStart را بر اساس تنظیمات خود تغییر دهید:

[Unit]
Description=ASP.NET Core Web Application
After=network.target

[Service]
WorkingDirectory=/var/www/mywebapp
ExecStart=/usr/bin/dotnet /var/www/mywebapp/YourAppName.dll
Restart=always
# Restart service after 10 seconds if dotnet process crashes
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=mywebapp
User=www-data # یا کاربر دیگری با دسترسی مناسب به پوشه اپلیکیشن
Environment=ASPNETCORE_ENVIRONMENT=Production
Environment=DOTNET_PRINT_TELEMETRY_MESSAGE=false

[Install]
WantedBy=multi-user.target

توضیحات:

Description: توضیحات کوتاهی برای سرویس.
After=network.target: اطمینان می‌دهد که سرویس پس از فعال شدن شبکه شروع به کار کند.
WorkingDirectory: مسیر اصلی اپلیکیشن.
ExecStart: دستور اجرای اپلیکیشن. /usr/bin/dotnet مسیر اجرایی دات‌نت و YourAppName.dll نام فایل DLL اصلی اپلیکیشن شماست (که معمولاً نام پروژه شماست).
Restart=always: سرویس در صورت توقف یا خرابی، همیشه مجدداً راه‌اندازی می‌شود.
User: کاربری که سرویس با آن اجرا می‌شود. بهتر است از یک کاربر غیر ریشه (non-root) با حداقل دسترسی استفاده کنید (مثلاً www-data یا یک کاربر اختصاصی).
Environment: متغیرهای محیطی برای اپلیکیشن ASP.NET Core. ASPNETCORE_ENVIRONMENT=Production محیط را به Production تنظیم می‌کند و DOTNET_PRINT_TELEMETRY_MESSAGE=false پیام‌های تله‌متری دات‌نت را غیرفعال می‌کند.

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

sudo systemctl daemon-reload
sudo systemctl enable mywebapp.service
sudo systemctl start mywebapp.service

برای بررسی وضعیت سرویس:

sudo systemctl status mywebapp.service

اطمینان حاصل کنید که سرویس در وضعیت active (running) قرار دارد.

مرحله ۳: پیکربندی NGINX به عنوان Reverse Proxy

حالا NGINX را پیکربندی می‌کنیم تا درخواست‌های ورودی را به اپلیکیشن ASP.NET Core در حال اجرا در پورت داخلی (معمولاً 5000 یا 5001) هدایت کند.

یک فایل پیکربندی جدید برای NGINX در مسیر /etc/nginx/sites-available/ ایجاد کنید:

sudo nano /etc/nginx/sites-available/mywebapp

محتوای زیر را در فایل mywebapp قرار دهید:

server {
    listen 80;
    server_name yourdomain.com www.yourdomain.com; # نام دامنه خود را اینجا وارد کنید

    location / {
        proxy_pass http://localhost:5000; # پورت داخلی اپلیکیشن ASP.NET Core
        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;
    }
}

توضیحات:

listen 80: NGINX به درخواست‌های HTTP در پورت 80 گوش می‌دهد.
server_name: نام‌های دامنه شما که NGINX برای این پیکربندی به آن‌ها پاسخ می‌دهد.
location /: هر درخواستی را که به ریشه دامنه ارسال می‌شود، مدیریت می‌کند.
proxy_pass http://localhost:5000: درخواست‌ها را به اپلیکیشن ASP.NET Core که روی localhost و پورت 5000 در حال گوش دادن است، ارسال می‌کند. (مطمئن شوید که اپلیکیشن شما واقعاً روی این پورت گوش می‌دهد، در غیر این صورت آن را تغییر دهید.)
proxy_set_header: هدرهای لازم را برای انتقال اطلاعات مربوط به درخواست اصلی به اپلیکیشن ASP.NET Core تنظیم می‌کند. این هدرها برای مواردی مانند دریافت آدرس IP واقعی کاربر و پروتکل مورد استفاده (HTTP/HTTPS) ضروری هستند.

پس از ذخیره و بستن فایل، یک سیم‌لینک (symlink) از این فایل به پوشه sites-enabled ایجاد کنید تا NGINX آن را بارگذاری کند:

sudo ln -s /etc/nginx/sites-available/mywebapp /etc/nginx/sites-enabled/

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

sudo nginx -t
sudo systemctl restart nginx

حالا باید بتوانید با مرورگر خود به آدرس دامنه (مثلاً http://yourdomain.com) دسترسی پیدا کنید و اپلیکیشن ASP.NET Core شما را مشاهده کنید.

مرحله ۴: پیکربندی HTTPS با Let's Encrypt (Certbot)

امنیت ارتباطات وب از اهمیت بالایی برخوردار است. HTTPS با رمزنگاری داده‌ها، از حملات Man-in-the-Middle جلوگیری می‌کند. Let's Encrypt یک مرجع صدور گواهی رایگان و خودکار است که به شما امکان می‌دهد گواهی‌های SSL/TLS را به راحتی تهیه و مدیریت کنید.

نصب Certbot:

Certbot ابزاری است که فرایند دریافت و تمدید گواهی‌های Let's Encrypt را خودکار می‌کند. برای Ubuntu:

sudo snap install core
sudo snap refresh core
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

برای CentOS:

sudo yum install epel-release
sudo yum install certbot python-certbot-nginx

دریافت گواهی SSL:

از Certbot برای دریافت گواهی و پیکربندی NGINX استفاده کنید:

sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com

Certbot به صورت خودکار پیکربندی NGINX شما را برای استفاده از HTTPS به‌روزرسانی می‌کند. این دستور تغییرات لازم را در فایل mywebapp در /etc/nginx/sites-available/ اعمال می‌کند. Certbot همچنین یک cron job یا systemd timer برای تمدید خودکار گواهی‌ها قبل از انقضا ایجاد می‌کند.

پس از اتمام کار Certbot، مجدداً پیکربندی NGINX را تست و راه‌اندازی کنید:

sudo nginx -t
sudo systemctl restart nginx

حالا باید بتوانید با استفاده از HTTPS (مثلاً https://yourdomain.com) به اپلیکیشن خود دسترسی پیدا کنید و اتصال شما امن باشد.

مرحله ۵: پیاده‌سازی Load Balancing (اختیاری اما توصیه شده)

اگر قصد دارید مقیاس‌پذیری اپلیکیشن خود را افزایش دهید و ترافیک بالایی را مدیریت کنید، پیاده‌سازی Load Balancing بسیار مهم است. این کار شامل اجرای چندین نمونه (instance) از اپلیکیشن ASP.NET Core شما در پورت‌های مختلف یا حتی روی سرورهای مختلف است، و سپس NGINX ترافیک را بین این نمونه‌ها توزیع می‌کند.

فرض کنید دو نمونه از اپلیکیشن ASP.NET Core دارید که روی پورت‌های 5000 و 5001 در حال اجرا هستند.

ابتدا، فایل سرویس Systemd دیگری برای نمونه دوم اپلیکیشن خود ایجاد کنید (مثلاً mywebapp2.service که روی پورت 5001 اجرا شود). مطمئن شوید که هر سرویس از یک پورت متفاوت استفاده می‌کند. شما باید در کد ASP.NET Core خود نیز اطمینان حاصل کنید که اپلیکیشن قابلیت گوش دادن به پورت‌های مختلف را دارد یا پورت را از طریق متغیر محیطی (مثلاً ASPNETCORE_URLS) پیکربندی کنید.

به عنوان مثال، در appsettings.Production.json می‌توانید پورت را تعیین کنید یا در Systemd Service: Environment=ASPNETCORE_URLS=http://*:5001

سپس، پیکربندی NGINX خود را برای Load Balancing به‌روزرسانی کنید. فایل /etc/nginx/sites-available/mywebapp را باز کنید:

sudo nano /etc/nginx/sites-available/mywebapp

و بلوک upstream را اضافه کرده و بلوک location را تغییر دهید:

upstream mywebapp_backend {
    server 127.0.0.1:5000;
    server 127.0.0.1:5001; # فرض بر این است که نمونه دوم روی پورت 5001 اجرا می شود
    # server 192.168.1.10:5000; # می توانید سرورهای دیگر را نیز اضافه کنید
}

server {
    listen 80;
    listen [::]:80;
    server_name yourdomain.com www.yourdomain.com;
    return 301 https://$host$request_uri; # Redirect HTTP to HTTPS
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name yourdomain.com www.yourdomain.com;

    ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem; # مسیر گواهی شما
    ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem; # مسیر کلید خصوصی شما
    ssl_session_cache shared:SSL:10m;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH;
    ssl_prefer_server_ciphers on;

    location / {
        proxy_pass http://mywebapp_backend; # استفاده از بلوک upstream
        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;
    }
}

توضیحات:

upstream mywebapp_backend: این بلوک گروهی از سرورها (نمونه‌های اپلیکیشن) را تعریف می‌کند که NGINX درخواست‌ها را بین آن‌ها توزیع خواهد کرد.
server 127.0.0.1:5000; و server 127.0.0.1:5001;: آدرس‌ها و پورت‌های داخلی نمونه‌های اپلیکیشن ASP.NET Core شما.
proxy_pass http://mywebapp_backend;: به جای ارجاع مستقیم به یک پورت خاص، NGINX اکنون ترافیک را به گروه mywebapp_backend هدایت می‌کند و به طور پیش‌فرض از الگوریتم Round Robin برای توزیع درخواست‌ها استفاده می‌کند.
پیکربندی HTTPS (443): این پیکربندی شامل تنظیمات SSL/TLS است که توسط Certbot اضافه شده است. خط return 301 https://$host$request_uri; اطمینان می‌دهد که تمام درخواست‌های HTTP به HTTPS ریدایرکت شوند.

پس از اعمال تغییرات، مجدداً پیکربندی NGINX را تست کرده و آن را راه‌اندازی مجدد کنید:

sudo nginx -t
sudo systemctl restart nginx

با این پیکربندی، NGINX به عنوان یک لودبالانسر عمل می‌کند و ترافیک را بین نمونه‌های مختلف اپلیکیشن ASP.NET Core شما توزیع می‌کند که این امر باعث افزایش دسترس‌پذیری و ظرفیت پذیری اپلیکیشن شما می‌شود.

نکات و ملاحظات پیشرفته

Logging: برای دیباگ کردن و مانیتورینگ، بررسی لاگ‌های NGINX (/var/log/nginx/access.log و /var/log/nginx/error.log) و لاگ‌های Systemd برای سرویس ASP.NET Core (sudo journalctl -u mywebapp.service) بسیار مفید است.
فایروال: برای افزایش امنیت سرور، حتماً یک فایروال (مانند UFW در اوبونتو یا FirewallD در CentOS) را پیکربندی کنید تا فقط پورت‌های لازم (80 و 443) برای دسترسی عمومی باز باشند.
پیکربندی Kestrel: اپلیکیشن ASP.NET Core شما توسط Kestrel میزبانی می‌شود. به طور پیش‌فرض، Kestrel تنها به localhost گوش می‌دهد. در محیط تولید، از NGINX به عنوان پراکسی معکوس استفاده می‌کنیم و Kestrel مستقیماً در معرض اینترنت قرار نمی‌گیرد.
Content Security Policy (CSP): برای افزایش امنیت در سمت کلاینت، پیاده‌سازی CSP در اپلیکیشن ASP.NET Core شما می‌تواند از حملات XSS (Cross-Site Scripting) جلوگیری کند.
Health Checks: در سناریوهای لودبالانسینگ، می‌توانید از قابلیت‌های Health Check در NGINX (به همراه ماژول ngx_http_upstream_hc_module یا با استفاده از لایه‌های پراکسی پیشرفته‌تر) برای حذف خودکار نمونه‌های ناسالم از گروه لودبالانسینگ استفاده کنید.
استفاده از Docker: برای استقرار و مدیریت آسان‌تر، می‌توانید اپلیکیشن ASP.NET Core و حتی NGINX را در کانتینرهای Docker قرار دهید و از Docker Compose یا Kubernetes برای ارکستراسیون استفاده کنید. این روش می‌تواند پیچیدگی استقرار را کاهش دهد و قابلیت حمل را افزایش دهد.

نتیجه‌گیری

ادغام ASP.NET Core MVC با NGINX در محیط لینوکس، همراه با استفاده از Systemd برای مدیریت سرویس‌ها، Load Balancing برای مقیاس‌پذیری و HTTPS برای امنیت، یک استراتژی قدرتمند و بهینه برای استقرار حرفه‌ای وب‌اپلیکیشن‌ها فراهم می‌کند. این رویکرد نه تنها کارایی و پایداری را به ارمغان می‌آورد، بلکه با کاهش هزینه‌های عملیاتی و فراهم آوردن یک محیط امن، به شما کمک می‌کند تا اپلیکیشن‌های خود را با اطمینان در مقیاس بزرگ مستقر کنید. با دنبال کردن دقیق مراحل این راهنما، توسعه‌دهندگان و مدیران سیستم می‌توانند از تمام پتانسیل این فناوری‌ها بهره‌مند شوند و تجربه کاربری بهتری را برای کاربران خود فراهم آورند.

لینک استاندارد شده: MNESuUrJ