سایت استاتیک، مستقیم از باکت ذخیره‌سازی

برای انتشار یک سایت چهار چیز تعیین می‌کنید. باکت مبدأ باید متعلق به حساب خودتان باشد؛ سرویس اجازه نمی‌دهد باکت مشتری دیگری منتشر شود. زیردامنه آدرس عمومی سایت را می‌سازد و بین همهٔ مشتریان یکتاست. دو فایل دیگر هم مشخص می‌کنند بازدیدکننده در صفحهٔ اصلی و هنگام خطا چه ببیند.

جدول زیر تنظیمات قابل انتخاب و مقدار پیش‌فرض هر کدام را نشان می‌دهد:

معیار ساده است: اگر پوشهٔ خروجی build را باز کنید و با دو بار کلیک روی index.html سایت درست کار کند، احتمالاً گزینهٔ مناسبی برای میزبانی استاتیک است. نمونه‌های رایج:

هر فریم‌ورک خروجی را در پوشهٔ متفاوتی می‌سازد و باید محتوای همان پوشه، نه خود پوشه، در ریشهٔ باکت قرار بگیرد. چون سند اصلی و سند خطا فقط نام فایل می‌پذیرند و مسیر ندارند، index.html و 404.html باید مستقیماً در ریشهٔ باکت باشند.

سایت روی ریشهٔ یک زیردامنه منتشر می‌شود، پس مسیر پایه (base path) را روی اسلش تنها بگذارید و زیرپوشه تعریف نکنید. اگر اپ تک‌صفحه‌ای شما مسیریابی سمت مرورگر دارد، دقت کنید که آدرس‌های داخلی در ریشه فایل متناظری ندارند و به سند خطا می‌رسند؛ برای این حالت سند خطا را همان index.html بگذارید تا اپ مسیر را خودش باز کند (پاسخ این صفحه‌ها کد ۴۰۴ دارد). آدرسی که به اسلش ختم شود، index.html همان پوشه را باز می‌کند.

چون باکت‌ها کاملاً با API استاندارد S3 کار می‌کنند، برای بارگذاری فایل‌ها لازم نیست ابزار جدیدی یاد بگیرید. نشانی سرویس s3.iranclaud.ir است و آدرس‌دهی به‌صورت مسیری (path-style) انجام می‌شود. در پنل یک کلید دسترسی خواندن‌ونوشتن بسازید که فقط به باکت سایت محدود باشد؛ کلید مخفی فقط یک بار نمایش داده می‌شود.

با AWS CLI کافی است دستور aws s3 sync ./dist s3://نام-باکت --delete --endpoint-url https://s3.iranclaud.ir را اجرا کنید. گزینهٔ delete فایل‌هایی را که در build جدید نیستند از باکت پاک می‌کند تا نسخه‌های قدیمی جا نمانند. اگر rclone را ترجیح می‌دهید، دستور rclone sync همین کار را انجام می‌دهد. AWS CLI نوع محتوای فایل‌ها را از پسوند تشخیص می‌دهد؛ این موضوع برای نمایش درست CSS و جاوااسکریپت در مرورگر مهم است.

همین دستورها را می‌توانید در انتهای pipeline خود قرار دهید تا با هر ادغام در شاخهٔ اصلی، فایل‌های جدید در باکت قرار بگیرند. اگر CI خودتان را می‌خواهید، راهنمای نصب Woodpecker CI یا Gitea روی سرور ابری را ببینید.

همان‌طور که در پنل هم نوشته شده، سایت استاتیک هزینهٔ جداگانه ندارد و فقط هزینهٔ باکتی که سایت از آن سرو می‌شود محاسبه می‌شود. باکت‌ها طبق تعرفهٔ ذخیره‌سازی شیء حساب می‌شوند: ۱۰ گیگابایت اول مجموع فضای همهٔ باکت‌های هر مشتری رایگان است و بیش از آن ۲٬۰۰۰ تومان به‌ازای هر گیگابایت در ماه، به‌صورت ساعتی از کیف پول کسر می‌شود.

ترافیک دانلود از باکت‌های ذخیره‌سازی شیء ۱٬۰۰۰ تومان به‌ازای هر گیگابایت است. نحوهٔ محاسبهٔ ترافیک بازدید سایت و تعرفهٔ نهایی هنگام راه‌اندازی اعلام می‌شود. برای مقایسه با سرویس‌های دیگر، ماشین‌حساب هزینه و صفحهٔ قیمت‌گذاری را ببینید.

امروز دو راه فعال برای انتشار فایل‌های ثابت دارید و سرویس سایت استاتیک راه سوم خواهد بود. باکت عمومی ساده‌ترین است، اما صفحهٔ اصلی را خودکار باز نمی‌کند و آدرس شامل نام باکت است. سرور ابری انعطاف کامل و دامنهٔ اختصاصی می‌دهد، اما نگه‌داری سرور با شماست.

جدول زیر تفاوت‌ها را کنار هم می‌گذارد تا بر اساس نیاز امروز انتخاب کنید:

اگر سایت شما همین هفته باید بالا بیاید، یک سرور ابری کوچک با nginx مطمئن‌ترین مسیر است. nginx را با راهنمای نصب nginx راه‌اندازی کنید، پوشهٔ build را در مسیر ریشهٔ وب قرار دهید و دامنه را با DNS ایران‌کلاد به IP سرور وصل کنید. برای گواهی SSL هم صفحهٔ گواهی SSL را ببینید.

اگر فقط می‌خواهید چند فایل ثابت مثل تصویر، فونت یا فایل PDF را در دسترس عموم بگذارید، باکت را در پنل عمومی کنید. در این حالت هر فایل با آدرس کامل خود باز می‌شود، اما ریشهٔ باکت صفحهٔ اصلی نشان نمی‌دهد. در هر دو حالت، اگر فایل‌ها را از همین حالا در یک باکت جداگانه نگه دارید، انتقال به سرویس سایت استاتیک پس از راه‌اندازی تقریباً بدون کار اضافه خواهد بود.

وقتی یک باکت به سایت تبدیل شود، هر فایلی که در آن است با آدرس مستقیم قابل دریافت است. پس هرگز فایل‌هایی مثل .env، کلید API، بکاپ دیتابیس یا خروجی‌های داخلی را در باکت سایت نگذارید. بهترین روش، داشتن یک باکت جدا فقط برای سایت است که چیزی جز خروجی build در آن نیست.

در کد فرانت‌اند هم هیچ رمز یا کلید محرمانه‌ای قرار ندهید؛ هر چیزی که به مرورگر برسد، برای همه قابل خواندن است. اگر نمی‌خواهید کد منبع خوانا باشد، فایل‌های source map را از خروجی نهایی حذف کنید. کلید S3 مخصوص بارگذاری را فقط به همان باکت سایت محدود کنید تا اگر در سرور CI لو رفت، به باکت‌های دیگر دسترسی ندهد.

با انتشار، باکت انتخاب‌شده عمومی می‌شود و فایل‌هایش از آدرس s3.iranclaud.ir هم بدون کلید قابل دریافت است؛ حذف سایت این تنظیم را برنمی‌گرداند و اگر بخواهید باید باکت را دوباره در پنل خصوصی کنید. سرویس فقط اجازه می‌دهد باکت‌های متعلق به حساب خودتان منتشر شوند و زیردامنه بین مشتریان یکتاست؛ بنابراین کسی نمی‌تواند باکت شما را با زیردامنهٔ خودش منتشر کند. برای بررسی سرآیندهای پاسخ سایت پس از انتشار، ابزار بررسی هدرها کمک می‌کند.

در طرح فعلی، آدرس هر سایت زیردامنه‌ای از sites.iranclaud.ir است و اتصال دامنهٔ اختصاصی جزو سرویس نیست. برای مستندات داخلی، صفحه‌های آزمایشی و پیش‌نمایش پروژه برای مشتری، این آدرس کاملاً کافی است. اما اگر برند شما به دامنهٔ خودش نیاز دارد، فعلاً سرور ابری راه درست است و می‌توانید دامنه را از ثبت دامنه تهیه کنید.

زیردامنه پس از ثبت یکتا می‌ماند. اگر خواستید نام دیگری بگیرید، سایت فعلی را حذف کنید و دوباره با زیردامنهٔ جدید منتشر کنید؛ فایل‌ها در باکت دست‌نخورده باقی می‌مانند، چون حذف سایت فقط اتصال باکت به زیردامنه را برمی‌دارد. در انتخاب نام هم از کلمات کوتاه و مرتبط با پروژه استفاده کنید تا در ذهن کاربران بماند.

سرویس هنوز فعال نیست و تاریخ قطعی راه‌اندازی اعلام نشده است؛ خبرها در صفحهٔ تغییرات منتشر می‌شود. در طرح فعلی، دامنهٔ اختصاصی، اتصال مستقیم به مخزن Git و build خودکار سمت سرور وجود ندارد و سرویس فقط فایل‌های آماده را از باکت تحویل می‌دهد.

هر حساب تا ۱۰ سایت و تا ۱۰ باکت دارد، سند اصلی و سند خطا باید در ریشهٔ باکت باشند و کد سمت سرور اجرا نمی‌شود. فقط درخواست‌های GET و HEAD پاسخ می‌گیرند و ریدایرکت یا سرآیند سفارشی تعریف نمی‌شود. تعرفهٔ ترافیک سایت هم هنگام راه‌اندازی قطعی می‌شود. اگر پروژهٔ شما به یکی از این موارد وابسته است، با پشتیبانی هماهنگ کنید یا مسیر سرور ابری را انتخاب کنید.