ما تحتاج إليه
تحتاج إلى ثلاثة أشياء: تطبيق Next.js (تطبيق موجود مناسب تمامًا)، ومستودع Git له (يعمل GitHub مباشرةً)، وحساب على cdn.com.tr. لن تحتاج إلى تجهيز خادم، أو تثبيت Node على خادم افتراضي، أو إعداد وكيل عكسي (reverse proxy) — فالمنصّة تتولّى بيئة التشغيل وTLS والتوصيل. والتغيير الوحيد من جهة التطبيق هو أن تطلب من Next.js إنتاج بناء مكتفٍ ذاتيًا ليعمل بنظافة داخل حاوية.
هيّئ التطبيق للحاوية
أولًا، فعّل مخرجات Next.js المكتفية ذاتيًا (standalone). فهذا يحزم الملفات التي يحتاجها الخادم فقط، ممّا يُبقي الصورة صغيرة والحاوية بسيطة.
next.config.js
// next.config.js
module.exports = {
output: 'standalone',
};
أضِف Dockerfile
يبني Dockerfile صغير متعدّد المراحل التطبيقَ في مرحلة ويشحن مخرجات التشغيل فقط في المرحلة التالية. أضِف هذا الملف إلى جذر مستودعك.
Dockerfile
# Build stage
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
# Runtime stage
FROM node:20-alpine AS runner
WORKDIR /app
ENV NODE_ENV=production
COPY --from=builder /app/.next/standalone ./
COPY --from=builder /app/.next/static ./.next/static
COPY --from=builder /app/public ./public
EXPOSE 3000
CMD ["node", "server.js"]
انشر من Git (موصى به)
من لوحة cdn.com.tr، أنشئ تطبيق حاوية واربط مستودع Git الخاص بك. تقرأ المنصّة ملف Dockerfile، وتبني الصورة، وتشغّل الحاوية — دون خادم بناء تصونه. ومن ثمّ يصبح النشر مجرّد دفعٍ إلى فرعك: فكل دفعة تُطلق بناءً جديدًا وطرحًا دون أيّ توقّف.
أصدِر تغييرًا
git add .
git commit -m "Update homepage"
git push origin main
# cdn.com.tr builds the new image and rolls it out automatically
أو انشر عبر واجهة cdnctl
تفضّل سطر الأوامر أو خطّ CI؟ تدير واجهة cdnctl للمشغّلين تطبيقات حاوياتك كشيفرة. سجّل الدخول مرّةً واختر حسابك، ثم أنشئ التطبيق من صورة دفعتها إلى سجلّ (registry) — واستخدم الأداة نفسها لبثّ السجلّات أو التوسيع أو التراجع. هذا ما يجعل النشر على cdn.com.tr سريعًا: أمرٌ واحد بدلًا من سلسلة نقرات في وحدة التحكّم.
cdnctl login
cdnctl accounts use <account_uuid>
# create the app from your pushed image, on your domain
cdnctl container apps create \
--name my-nextjs \
--image registry.example.com/acme/my-nextjs --tag 1.0.0 \
--port 3000 --domain app.example.com \
--healthcheck /api/health --healthcheck-type http
# then, anytime:
cdnctl container apps logs --app <app_uuid> --tail 100
cdnctl container apps scale --app <app_uuid> --replicas 2
cdnctl container apps deploy --app <app_uuid>
النطاق المخصّص وHTTPS والحافة
وجّه نطاقك إلى التطبيق، ويُصدِر cdn.com.tr شهادة SSL ويجدّدها تلقائيًا — دون certbot يدوي. يعمل تطبيق Next.js الآن خلف حافة CDN، فتُخزَّن الأصول الثابتة مؤقتًا وتُوصَّل قريبًا من كل زائر، ويرشّح WAF الزيارات الضارة، وتُمتَص موجات الذروة عند الحافة بدلًا من إرهاق حاوية واحدة. تحصل على نشر Next.js إنتاجي سريع وآمن دون تشغيل أيّ من البنية التحتية تحته.
أين يناسب أكثر
صفحات Next.js المخدومة من الحافة تُحمَّل بسرعة حول العالم وتظلّ متاحة أثناء إطلاق أو لحظة انتشار.
شغّل مسارات Next.js API والعرض من الخادم (SSR) كحاوية مُدارة مع HTTPS تلقائي وWAF أمامها.
النشر عبر دفع Git مع طرح دون توقّف يناسب CI والإصدارات المتكرّرة دون مجالسة الخوادم.
الأسئلة الشائعة حول نشر Next.js
هل يعمل العرض من الخادم (SSR) ومسارات API، أم التصدير الثابت فقط؟
كلاهما يعمل. ولأن التطبيق يعمل كحاوية Node حقيقية (لا كتصدير ثابت)، فإن العرض من الخادم، ومسارات API، والوسائط (middleware) تعمل جميعها بشكل طبيعي. تخزّن شبكة CDN ما هو قابل للتخزين مؤقتًا وتمرّر الطلبات الديناميكية إلى الحاوية.
كيف تعمل التحديثات والتراجعات؟
كل دفعة إلى فرعك المتّصل تبني صورة جديدة وتطرحها دون أيّ توقّف. وإذا فشل البناء، تظلّ النسخة السابقة تخدم الزوّار، فلا يُسقِط إيداعٌ سيّئ موقعك.
هل عليّ إدارة الخادم أو إصدار Node أو SSL؟
لا. تُدار لك بيئة تشغيل الحاوية، والتوسيع، وشهادات TLS، والحافة. أنت تتحكّم في التطبيق وملف Dockerfile الخاص به؛ أما البنية التحتية تحته فمُتكفَّل بها.