پروژه روی لپتاپ شما باز میشود، صفحه ورود کار میکند و درخواستهای API جواب میگیرند. بعد از انتشار، صفحه اصلی بالا میآید، ولی با تازهسازی صفحه پروفایل چیزی نمایش داده نمیشود؛ یا درخواستها هنوز به محیط توسعه میروند. مسئله دیپلوی React همین فاصله میان «روی سیستم من کار میکند» و «کاربر میتواند از آن استفاده کند» است. باید خروجی بسازید، تنظیمات محیط مقصد را وارد کنید و مسیریابی و ارتباط با بکاند را بیازمایید. انتخاب ابر ایران نیز نیاز به بررسی دسترسی وابستگیهای خارجی را از بین نمیبرد.
پاسخ سریع: برای دیپلوی React چه چیزی را منتشر کنیم؟
اگر پروژه شما یک SPA است، یعنی رابط کاربری در مرورگر اجرا میشود، خروجی production آن را با سرویسدهنده فایل استاتیک منتشر کنید. در پروژه معمول React همراه Vite، خروجی پیشفرض dist است. سرور توسعه و vite preview جایگزین وبسرور production نیستند. راهنمای استقرار Vite
در پاستا میتوانید Repository گیت یا پوشه پروژه را وارد کنید و نتیجه تشخیص را پیش از Build ببینید. ابتدا Build محلی را آزمایش و آدرس API را مشخص کنید. اگر پروژه به اجرای سمت سرور وابسته است، استقرار استاتیک کافی نیست.
هاست ری اکت را بر اساس نوع خروجی انتخاب کنید
React بهتنهایی نوع میزبانی را تعیین نمیکند. پروژه استاتیک و پروژه دارای رندر سمت سرور، نیاز اجرایی یکسانی ندارند. مستندات ساخت اپ React
|
وضعیت پروژه |
نیاز میزبانی |
معیار تصمیم |
|
SPA با API جداگانه |
سرویسدهی فایلهای خروجی و fallback مسیرها |
مدیریت انتشار، HTTPS و کش |
|
React با سرور اختصاصی |
اجرای سرور و تنظیمات محیط آن |
پشتیبانی از روش اجرا و نیازهای برنامه |
|
فرانتاند همراه بکاند |
استقرار و تنظیم ارتباط هر دو بخش |
هزینه و عملیات کل سامانه |
اگر پروژه Next.js شما از قابلیتهای سمت سرور استفاده میکند، «راهنمای دیپلوی Next.js روی زیرساخت ابری ایران» مسیر مرتبطتری است.
برای فایلهای استاتیک، هاست استاتیک هم میتواند کافی باشد. پاستا امکان مدیریت Build، وضعیت استقرار، لاگ و دامنه را از یک جریان فارسی فراهم میکند. کنترل کامل روی وبسرور اختصاصی، مسئولیت نگهداری بیشتری هم دارد.
Build قابل تکرار را پیش از انتشار آماده کنید
این نمونه برای پروژه موجود React با Vite و npm است. بخش scripts در package.json باید دستورهای زیر را داشته باشد. تنظیمات دیگر فایل را حذف نکنید:
{
"scripts": {
"build": "vite build",
"preview": "vite preview"
}
}
نسخه Node مورد نیاز پروژه را با محیط Build مقصد تطبیق دهید و package-lock.json را همراه سورس نگه دارید.
دستور npm ci پوشه موجود node_modules را حذف و وابستگیها را مطابق lockfile نصب میکند؛ تغییرات دستی داخل این پوشه از بین میروند. این دستور package.json یا lockfile را بازنویسی نمیکند. آن را برای پروژه و وابستگیهای مورد اعتماد اجرا کنید:
npm ci
npm run build
npm run preview
اجرای دوباره npm ci نصب تمیز را تکرار میکند. اگر lockfile با package.json ناسازگار باشد، نصب متوقف میشود؛ ناسازگاری را در محیط توسعه اصلاح کنید. مستندات npm ci
Build خروجی انتشار را دوباره تولید میکند؛ در تنظیمات پیشفرض، dist/index.html و فایلهای وابسته را میسازد. preview همان خروجی را برای آزمون محلی سرو میکند. اگر فایلها جای دیگری ساخته شدند، build.outDir را بررسی کنید. مستندات Vite
صفحه ورود، یک مسیر داخلی و درخواست API را روی پیشنمایش امتحان کنید. موفقبودن محیط توسعه بهتنهایی آزمون انتشار نیست.
اگر پروژه Angular هم دارید، دستورها و تنظیمات این نمونه را عیناً منتقل نکنید؛ برای آن پروژه، راهنمای «دیپلوی اپلیکیشن Angular — build، محیط و دامنه» را دنبال کنید.
آدرس API را در زمان درست وارد کنید
Vite متغیرهای دارای پیشوند VITE_ را داخل کد قابلدریافت مرورگر قرار میدهد. برای مثال، آدرس عمومی API میتواند در .env.production باشد:
VITE_API_BASE_URL=https://api.example.com
و در کد خوانده شود:
const apiBaseUrl = import.meta.env.VITE_API_BASE_URL;
دامنه نمونه را با آدرس HTTPS بکاند خود جایگزین کنید. مقدار هنگام Build وارد خروجی میشود؛ تغییر بعدی آن به Build و استقرار مجدد نیاز دارد.
رمز دیتابیس یا کلید خصوصی سرویس را در این متغیرها نگذارید. ذخیره ورودی بهشکل Secret هم مانع افشای آن در bundle مرورگر نمیشود. Secret های بکاند باید در محیط سرور بمانند. مستندات متغیرهای محیطی Vite
پاستا از متغیر محیطی و Secret پشتیبانی میکند؛ روش رساندن متغیر به مرحله Build را برای مسیر انتخابی پروژه بررسی کنید.
پروژه را در پاستا وارد و نتیجه را کنترل کنید
وارد حساب خود شوید و سورس را از GitHub، GitLab، پوشه یا ZIP ارائه کنید. در ZIP، وجود فایلهای پروژه و lockfile را بررسی کنید و فایلهای حاوی اطلاعات محرمانه را کنار بگذارید.
این موارد را کنترل کنید:
-
تشخیص پروژه: نتیجه تشخیص فریمورک، Dockerfile یا Compose را با ساختار پروژه تطبیق دهید. علت مغایرت را پیش از Build مشخص کنید.
-
تنظیمات ساخت: دستور Build، محل خروجی و دسترسی متغیرهای لازم هنگام ساخت را بررسی کنید.
-
هزینه: مبلغ و منابع انتخابی را در کنسول ببینید. هزینهها به توماناند؛ سرویس ماهانه پیش از ساخت شارژ میشود و ایجاد منبع PAYG به حداقل موجودی تنظیمشده نیاز دارد.
-
استقرار: جریان Build و وضعیت استقرار را دنبال کنید. اگر متوقف شد، لاگ مرحله شکست را مبنای تشخیص قرار دهید.
پس از آمادهشدن، اپلیکیشن میتواند آدرس HTTPS روی دامنه پاستا دریافت کند. اپهای مشتری روی paasta.app و زیردامنههای منطقهای آن منتشر میشوند.