آموزش راه‌اندازی سایت بدون سرور با Cloudflare Workers

راه‌اندازی یک وب‌سایت در گذشته معمولاً یعنی اجاره سرور، نصب سیستم‌عامل و وب‌سرور، تنظیم فایروال، نگهداری از نرم‌افزارها و پرداخت هزینه یک ماشین همیشه‌روشن. مدل «بدون سرور» یا Serverless این مسئولیت‌ها را از دوش صاحب سایت برمی‌دارد: شما کد و فایل‌های سایت را آماده می‌کنید و یک پلتفرم ابری آن‌ها را بر اساس درخواست کاربران اجرا و تحویل می‌دهد.

Cloudflare یکی از گزینه‌های شناخته‌شده برای این کار است. سرویس Workers کدهای سمت سرور را در شبکهٔ Cloudflare اجرا می‌کند؛ Static Assets فایل‌هایی مانند HTML، CSS، جاوااسکریپت و تصویر را ارائه می‌دهد؛ و سرویس‌هایی مثل D1، KV، R2 و Durable Objects قابلیت ذخیره‌سازی و داده را به پروژه اضافه می‌کنند. در نتیجه، می‌توان از یک صفحهٔ معرفی ساده تا یک برنامهٔ وب پویا را بدون مدیریت یک سرور سنتی راه‌اندازی کرد.

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

نکته: نام گزینه‌ها و سقف مصرف سرویس‌های ابری ممکن است تغییر کند. دستورها و توضیحات محصول در این مقاله با مستندات رسمی Cloudflare بررسی شده‌اند. پیش از طراحی نهایی پروژه، قیمت‌ها و محدودیت‌های جاری را در مستندات همان سرویس مرور کنید.

«بدون سرور» دقیقاً یعنی چه؟

بدون سرور به این معنا نیست که هیچ سروری در کار نیست. برنامهٔ شما همچنان روی سخت‌افزارهای مراکز داده اجرا می‌شود، اما لازم نیست خودتان آن سرورها را تهیه، پیکربندی و نگهداری کنید. Cloudflare بخش زیادی از زیرساخت اجرا و تحویل محتوا را مدیریت می‌کند و شما بیشتر روی کد، داده‌ها و تجربهٔ کاربر تمرکز می‌کنید.

این مدل چند مزیت دارد:

• نیازی به مدیریت سیستم‌عامل، وصله‌های امنیتی سرور و وب‌سرور ندارید.

• فایل‌ها و کد برنامه از شبکهٔ توزیع‌شدهٔ Cloudflare در دسترس کاربران قرار می‌گیرند.

• ظرفیت اجرا با تعداد درخواست‌ها تغییر می‌کند و لازم نیست از ابتدا یک ماشین بزرگ بخرید.

• برای پروژه‌های کوچک، امکان شروع با هزینهٔ کم یا سهمیه‌های رایگان وجود دارد.

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

اجزای Cloudflare برای ساخت سایت

Workers؛ کد سمت سرور

Worker یک برنامهٔ کوچک است که در پاسخ به درخواست HTTP اجرا می‌شود. برای مثال، می‌تواند یک API بسازد، فرم تماس را پردازش کند، اطلاعات را از پایگاه داده بخواند یا درخواست را به سرویس دیگری بفرستد.

در کد Worker معمولاً یک تابع fetch درخواست را دریافت می‌کند و یک پاسخ برمی‌گرداند. برخلاف سرور سنتی، برنامه را روی یک ماشین مشخص نصب و همیشه روشن نمی‌گذارید؛ Cloudflare اجرای درخواست‌ها را مدیریت می‌کند.

Static Assets؛ فایل‌های سایت

صفحه‌های HTML، فایل‌های CSS، کد جاوااسکریپت مرورگر، فونت‌ها و تصاویر را می‌توان به‌عنوان دارایی‌های ایستا منتشر کرد. Cloudflare این فایل‌ها را تحویل مرورگر می‌دهد و می‌توان Worker را هم در همان پروژه برای منطق پویا به کار گرفت. در مستندات فعلی، انتشار فایل‌های ایستا و کد Worker در یک استقرار واحد پشتیبانی می‌شود.مستندات رسمی Static Assets

D1؛ پایگاه دادهٔ SQL

D1 پایگاه دادهٔ رابطه‌ای Cloudflare بر پایهٔ SQLite است. اگر سایت شما کاربران، نوشته‌ها، سفارش‌ها یا داده‌های ساختاریافته دارد، D1 ممکن است گزینهٔ مناسبی باشد. Worker از طریق یک binding به D1 متصل می‌شود؛ یعنی نامی در تنظیمات پروژه تعریف می‌کنید و از طریق آن در کد به پایگاه داده دسترسی می‌یابید.راهنمای شروع D1

KV؛ ذخیره‌سازی کلید و مقدار

Workers KV برای داده‌هایی مناسب است که با یک کلید مشخص بازیابی می‌شوند؛ مثلاً تنظیمات عمومی، پاسخ‌های کش‌شده یا برخی داده‌های ساده. KV جایگزین کامل پایگاه دادهٔ SQL نیست. اگر نیاز دارید چند جدول را با هم جست‌وجو کنید یا محدودیت‌های رابطه‌ای داشته باشید، D1 معمولاً انتخاب مناسب‌تری است.

R2؛ ذخیره‌سازی فایل

R2 برای ذخیرهٔ فایل‌هایی مانند عکس، ویدئو، سند و خروجی کاربران به کار می‌رود. محتوای وب‌سایت و فایل‌های آپلودی الزاماً یک نوع ذخیره‌سازی نیستند: دارایی‌های ثابت پروژه را می‌توان در مسیر انتشار سایت نگه داشت، در حالی‌که فایل‌هایی که کاربر بعداً اضافه می‌کند ممکن است به ذخیره‌سازی آبجکتی مانند R2 نیاز داشته باشند.

Durable Objects؛ وضعیت و هماهنگی

Durable Objects برای مواردی طراحی شده که به وضعیت پایدار یا هماهنگی نیاز دارند؛ برای نمونه، یک اتاق گفت‌وگو، شمارندهٔ مشترک یا نشست زنده. این سرویس برای هر سایت ساده لازم نیست، اما در برنامه‌های تعاملی خاص می‌تواند به مدیریت وضعیت کمک کند.

انتخاب معماری مناسب

پیش از ساخت سایت، مشخص کنید با کدام نوع پروژه سروکار دارید:

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

پیش‌نیازها

برای مسیر مبتنی بر خط فرمان، این موارد را آماده کنید:

1. حساب Cloudflare.

2. Node.js نصب‌شده روی سیستم.

3. یک ویرایشگر کد.

4. ترمینال در پوشه‌ای که می‌خواهید پروژه در آن ساخته شود.

5. دامنه، اگر می‌خواهید سایت را با نشانی اختصاصی منتشر کنید.

Cloudflare ابزار خط فرمانی به نام Wrangler دارد. این ابزار پروژه را اجرا و منتشر می‌کند و منابعی مانند D1 را مدیریت می‌کند. برای شروع، معمولاً بهتر است از دستورهای npx استفاده کنید تا Wrangler مرتبط با پروژه اجرا شود.

ساخت و اجرای اولین سایت

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

npm create cloudflare@latest -- my-static-site

در مراحل پرسش‌وپاسخ ابزار ساخت پروژه، قالب Static site را انتخاب کنید. راهنمای رسمی Cloudflare همین مسیر را برای ساخت یک سایت ایستا بدون چارچوب خاص پیشنهاد می‌کند.شروع به کار با Static Assets

سپس وارد پوشهٔ پروژه شوید:

cd my-static-site

برای اجرای محلی:

npx wrangler dev

Wrangler یک نشانی محلی می‌دهد که می‌توانید سایت را در مرورگر ببینید. تا وقتی این مرحله درست کار نمی‌کند، انتشار اینترنتی را به تعویق بیندازید: ابتدا صفحه‌ها، مسیر فایل‌ها، فونت‌ها و تصویرها را بررسی کنید.

پس از آماده‌شدن پروژه، آن را منتشر کنید:

npx wrangler deploy

پس از استقرار، Wrangler نشانی پیش‌فرضی روی دامنهٔ workers.dev نمایش می‌دهد. این نشانی برای مشاهده و بررسی اولیه مفید است. برای سایت عمومی، معمولاً بهتر است دامنه یا زیردامنهٔ اختصاصی به Worker متصل کنید.

اگر سایت شما به منطق سمت سرور هم نیاز دارد، می‌توانید از قالب برنامهٔ تمام‌پشته استفاده کنید. مستندات رسمی، ساخت پروژه با SSR / full-stack app را نیز در دسترس می‌داند و روش اجرای محلی و انتشار آن مشابه است.راهنمای ساخت سایت کامل روی Workers

یک Worker ساده چگونه کار می‌کند؟

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

export default {
  async fetch(request) {
    const url = new URL(request.url);

    if (url.pathname === "/api/hello") {
      return Response.json({
        message: "سلام از Cloudflare Workers!",
      });
    }

    return new Response("این پاسخ از Worker آمده است.", {
      headers: { "content-type": "text/plain; charset=utf-8" },
    });
  },
};

در این مثال، Worker مسیر درخواست را می‌خواند. اگر مسیر /api/hello باشد، پاسخ JSON می‌سازد؛ در غیر این صورت یک پاسخ متنی می‌دهد. در یک برنامهٔ واقعی، کد می‌تواند فایل HTML را تحویل دهد، داده را از D1 بخواند، ورودی فرم را اعتبارسنجی کند یا درخواست را به سرویس بیرونی ارسال کند.

نکتهٔ مهم این است که Worker را با APIهای محیط اجرا سازگار بنویسید. بسیاری از کتابخانه‌های جاوااسکریپت برای Node.js طراحی شده‌اند و ممکن است بدون تنظیمات یا جایگزین مناسب روی Workers اجرا نشوند. اگر کتابخانه‌ای به فایل‌سیستم محلی، پردازش طولانی یا قابلیت خاص سیستم‌عامل وابسته باشد، پیش از انتخاب آن سازگاری‌اش را بررسی کنید.

افزودن پایگاه داده با D1

اگر سایت به دادهٔ ساختاریافته نیاز دارد، ابتدا یک پروژهٔ Worker داشته باشید و سپس پایگاه داده بسازید:

npx wrangler d1 create my-site-db

ابزار شناسه و تنظیمات لازم برای اتصال را نمایش می‌دهد. این اطلاعات باید به پیکربندی پروژه اضافه شوند. نمونهٔ مفهومی پیکربندی JSON:

{
  "d1_databases": [
    {
      "binding": "DB",
      "database_name": "my-site-db",
      "database_id": "شناسه‌ای که Wrangler نمایش داده است"
    }
  ]
}

مقدار binding نامی است که کد Worker برای دسترسی به پایگاه داده استفاده می‌کند. برای نمونه، اگر نام آن DB باشد، در تابع درخواست از env.DB استفاده می‌کنید. مقدار database_id را از خروجی ابزار بگیرید و نمونهٔ بالا را عیناً با شناسهٔ ساختگی به کار نبرید.

می‌توانید یک فایل SQL بسازید و جدول‌ها را تعریف کنید:

CREATE TABLE posts (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  title TEXT NOT NULL,
  body TEXT NOT NULL,
  created_at TEXT NOT NULL DEFAULT CURRENT_TIMESTAMP
);

برای افزودن داده به پایگاه دادهٔ محلی توسعه، ابزار D1 را با فایل SQL اجرا کنید. پیش از اجرای هر دستور، گزینه‌های محلی و راهنمای نسخهٔ فعلی Wrangler را بررسی کنید تا مطمئن شوید به پایگاه دادهٔ موردنظر وصل هستید. برای پایگاه دادهٔ تولیدی، استفاده از migrationهای نسخه‌دار راه منظم‌تری است: هر تغییر ساختار در یک فایل SQL ذخیره می‌شود و قابل پیگیری خواهد بود.راهنمای D1 migrations

نمونهٔ کد Worker برای خواندن نوشته‌ها:

export default {
  async fetch(request, env) {
    const result = await env.DB
      .prepare("SELECT id, title, body FROM posts ORDER BY id DESC")
      .all();

    return Response.json(result.results);
  },
};

در برنامهٔ واقعی، دادهٔ ورودی را مستقیم داخل رشتهٔ SQL قرار ندهید. از پارامترهای bind‌شده استفاده کنید تا خطر تزریق SQL کاهش پیدا کند:

const row = await env.DB
  .prepare("SELECT id, title FROM posts WHERE id = ?")
  .bind(postId)
  .first();

راهنمای رسمی D1 binding را مسیر دسترسی Worker به پایگاه داده معرفی می‌کند.D1 Database API

افزودن دامنهٔ اختصاصی

برای شروع می‌توانید از دامنهٔ workers.dev استفاده کنید. برای سایت عمومی، یک دامنه مثل example.com یا زیردامنه‌ای مثل www.example.com را به Worker متصل کنید.

Cloudflare دو مفهوم را باید از هم جدا کرد:

• Custom Domain: دامنه یا زیردامنه مستقیماً به Worker وصل می‌شود و Worker نقش مبدأ سایت را دارد.

• Route: Worker روی بخشی از ترافیک دامنه‌ای که ممکن است سرور مبدأ جداگانه‌ای داشته باشد، اجرا می‌شود.

اگر Worker خودش سایت شما را ارائه می‌کند و سرور مبدأ جداگانه‌ای ندارید، Custom Domain معمولاً مسیر طبیعی‌تری است. در تنظیمات پروژه یا داشبورد Cloudflare دامنه را اضافه می‌کنید؛ برای Custom Domain، Cloudflare می‌تواند رکوردهای DNS لازم و گواهی را برایتان ایجاد کند. دامنه باید در یک zone فعال Cloudflare باشد و روی همان hostname نباید تنظیم DNS ناسازگار وجود داشته باشد.راهنمای Custom Domains

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

• دامنهٔ اصلی و زیردامنهٔ www هر دو به مقصد موردنظر می‌روند.

• HTTPS فعال است.

• مسیرهای سایت، مثلاً /about و /contact، رفتار درست دارند.

• تنظیمات canonical و redirect باعث ساخت دو نسخهٔ تکراری از یک صفحه نمی‌شود.

• اگر فرم یا API دارید، از دامنهٔ درست استفاده می‌کنند.

اتصال مخزن Git و انتشار خودکار

برای هر تغییر لازم نیست دستور انتشار را دستی اجرا کنید. می‌توان مخزن Git پروژه را به فرایند ساخت و انتشار وصل کرد تا پس از به‌روزرسانی شاخهٔ مشخص، build و deploy انجام شود. Cloudflare Workers Builds امکان ساخت پروژه از مخزن را فراهم می‌کند و محدودیت‌های ساخت مانند دقیقه‌های build و تعداد هم‌زمانی به پلن وابسته است.محدودیت‌های Workers Builds

پیش از فعال‌سازی انتشار خودکار، این موارد را در نظر بگیرید:

• شاخهٔ تولیدی را از شاخهٔ آزمایش جدا کنید.

• کلیدهای API و رمزها را به‌صورت secret تنظیم کنید.

• متغیرهای لازم محیط staging و production را جداگانه تعریف کنید.

• پس از انتشار، صفحهٔ اصلی و مسیرهای حساس را بررسی کنید.

• برای بازگشت به نسخهٔ قبلی، روش rollback و نسخه‌بندی کد را بشناسید.

متغیرها و اطلاعات محرمانه

برنامه‌ها معمولاً به تنظیماتی مثل نشانی API یا کلید سرویس پرداخت نیاز دارند. مقادیر معمولی را می‌توان به‌عنوان متغیر محیطی تنظیم کرد. اما کلید خصوصی، رمز و توکن را نباید داخل کد یا فایل پیکربندی عمومی نگه دارید.

Cloudflare برای اطلاعات حساس از Secrets پشتیبانی می‌کند. در کد Worker، secret نیز مانند مقدار محیطی از شیء env در دسترس است؛ تفاوت اصلی این است که مقدار secret به شکل امن‌تری نگهداری می‌شود و پس از تعریف، در داشبورد قابل مشاهده نیست. Wrangler برای ثبت یک secret از دستوری مانند این استفاده می‌کند:

npx wrangler secret put API_KEY

برای توسعهٔ محلی می‌توان از فایل .dev.vars استفاده کرد، ولی باید این فایل را از Git خارج نگه داشت. مستندات Cloudflare صریحاً هشدار می‌دهد که مقدار حساس را در vars ساده قرار ندهید و فایل‌های محلی حاوی secret را commit نکنید.مستندات Secrets

امنیت فرم‌ها و API

قرار گرفتن کد روی شبکهٔ Cloudflare به این معنا نیست که برنامه خودبه‌خود امن است. این اصول را رعایت کنید:

1. ورودی‌ها را اعتبارسنجی کنید. نوع، طول و قالب داده را پیش از استفاده بررسی کنید.

2. دسترسی را کنترل کنید. هر مسیر مدیریتی باید احراز هویت و مجوز مناسب داشته باشد.

3. محدودسازی درخواست را در نظر بگیرید. فرم ورود یا مسیرهایی که هزینه‌ساز هستند باید در برابر درخواست‌های انبوه محافظت شوند.

4. از HTTPS استفاده کنید. برای دامنهٔ عمومی، گواهی معتبر و تنظیمات درست TLS اهمیت دارند.

5. خطاها را مدیریت کنید. جزئیات داخلی، کلیدها و پیام‌های خام پایگاه داده را به کاربر نمایش ندهید.

6. CORS را محدود کنید. اگر API برای مرورگرهاست، فقط مبدأهای موردنیاز را مجاز کنید.

7. از داده نسخهٔ پشتیبان داشته باشید. انتشار نسخهٔ جدید کد لزوماً تغییرات پایگاه داده یا حذف تصادفی داده‌ها را برنمی‌گرداند.

8. دسترسی توکن Cloudflare را محدود کنید. برای CI یا ابزارهای انتشار، از توکنی با حداقل دسترسی لازم استفاده کنید.

هزینه و سهمیه‌ها

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

برای نمونه، مستندات D1 سهمیه‌هایی برای خواندن ردیف، نوشتن و ذخیره‌سازی در پلن‌های Workers Free و Paid اعلام می‌کند؛ D1 از مقیاس‌پذیری تا صفر استفاده می‌کند و هزینهٔ ظرفیت دائمی ندارد. KV نیز سقف عملیات روزانه و ذخیره‌سازی دارد. مقادیر دقیق قابل تغییرند، پس پیش از عرضهٔ عمومی، صفحهٔ قیمت همان سرویس را بخوانید.قیمت D1 و قیمت KV

در برآورد هزینه، این سؤال‌ها را پاسخ دهید:

• چند درخواست ماهانه انتظار دارید؟

• هر درخواست چند بار پایگاه داده را می‌خواند یا می‌نویسد؟

• چه مقدار داده ذخیره می‌کنید؟

• چه میزان فایل به R2 اضافه خواهد شد؟

• آیا ساخت‌های مکرر پروژه از سهمیهٔ build استفاده می‌کنند؟

• آیا مصرف شما در ساعت‌های پرترافیک جهش دارد؟

محدودیت منابع و هزینهٔ سرویس‌ها را پیش از رشد پروژه زیر نظر بگیرید و برای داده‌های مهم، برنامهٔ پشتیبان‌گیری و بازیابی داشته باشید.

مزایا و محدودیت‌ها

مزایا

• مدیریت مستقیم سرور و سیستم‌عامل لازم نیست.

• برای سایت‌های ایستا، انتشار فایل‌ها ساده است.

• می‌توان کد پویا، API و منابع داده را در یک مجموعهٔ ابری کنار هم به کار گرفت.

• امکان شروع با پلن‌های کم‌هزینه‌تر وجود دارد.

• شبکهٔ توزیع‌شده می‌تواند محتوا را به کاربران مناطق مختلف نزدیک‌تر ارائه کند.

محدودیت‌ها

• محیط اجرای Workers با سرور Node.js معمولی یکسان نیست؛ سازگاری کتابخانه‌ها باید بررسی شود.

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

• وابستگی به APIها و bindingهای پلتفرم می‌تواند مهاجرت به ارائه‌دهندهٔ دیگر را دشوار کند.

• سرویس‌های داده سهمیه‌ها و الگوهای مصرف خاص خود را دارند.

• «سرورلس» به معنی حذف نیاز به پایش، تست، امنیت و نگهداری کد نیست.

اگر برنامه به پردازش دائمی، کنترل سیستم‌عامل یا نرم‌افزارهای خاصی نیاز دارد، یک سرور مجازی یا معماری ترکیبی را هم مقایسه کنید. می‌توانید فایل‌های ایستا را از Cloudflare ارائه دهید و بخش خاصی از پردازش را در سرویس دیگری نگه دارید.

چک‌لیست انتشار

پیش از اینکه سایت را به کاربران معرفی کنید، این موارد را انجام دهید:

• پروژه را در حالت محلی اجرا و صفحه‌های اصلی را بررسی کنید.

• مسیرهای ناموجود، خطاهای API و پاسخ‌های غیرمنتظره را امتحان کنید.

• تنظیمات تولید را از حالت توسعه جدا کنید.

• secretها را از کد و مخزن Git خارج کنید.

• دامنه و HTTPS را بررسی کنید.

• رفتار فایل‌های ایستا، تصاویر و فونت‌ها را آزمایش کنید.

• اگر D1 دارید، migrationها را ثبت و در محیط درست اجرا کنید.

• لاگ‌ها و روش پیگیری خطا را بشناسید.

• قیمت و سقف مصرف سرویس‌هایی را که استفاده می‌کنید مرور کنید.

• نسخهٔ کد و روش بازگشت به انتشار قبلی را مشخص کنید.

جمع‌بندی

Cloudflare Workers راهی برای اجرای منطق سمت سرور و انتشار سایت بدون مدیریت مستقیم سرور فراهم می‌کند. برای سایت ساده، می‌توان از فایل‌های ایستا استفاده کرد؛ برای API یا منطق پویا، Worker را به پروژه افزود؛ و برای داده و فایل، بر اساس نیاز سراغ D1، KV یا R2 رفت. مراحل معمول شروع عبارت‌اند از ساخت پروژه با npm create cloudflare@latest، توسعهٔ محلی با npx wrangler dev و انتشار با npx wrangler deploy.

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