نشر تطبيق ويب على Linux خطوة بخطوة

وصلت الآن إلى المرحلة التي ينتظرها كل مطور: تحويل المشروع من كود على جهازك إلى تطبيق حي يعمل على الإنترنت. هذه لحظة مهمة، لكنها أيضا حساسة إذا لم تتبع خطوات واضحة.

في هذا الدرس سننفذ نشر تطبيق ويب على Linux بطريقة عملية: إعداد الخادم، ربط الدومين، تشغيل Nginx، تفعيل HTTPS، وضبط الخدمة عبر systemd.

قبل النشر: ماذا يجب أن يكون جاهزا؟

  • خادم Linux محدث ومؤمن (كما في الدرس السابق)
  • دومين يشير إلى IP الخادم
  • نسخة مستقرة من التطبيق على Git
  • معرفة البورت الداخلي الذي يعمل عليه التطبيق (مثلا 3000)
قاعدة تشغيل: لا تنشر مباشرة من فرع غير مستقر. اعتمد نسخة واضحة يمكن الرجوع إليها بسرعة عند الحاجة.

الخطوة 1: تجهيز التطبيق على الخادم

cd /var/www
sudo mkdir -p myapp
sudo chown -R $USER:$USER myapp
cd myapp
git clone https://github.com/your-org/your-app.git .
npm ci
npm run build

إذا كان مشروعك Python أو PHP، استبدل أوامر التثبيت والبناء بما يناسب Stack الخاص بك.

الخطوة 2: تشغيل التطبيق كخدمة systemd

أنشئ ملف خدمة حتى يعمل التطبيق تلقائيا بعد إعادة تشغيل الخادم.

sudo nano /etc/systemd/system/myapp.service
[Unit]
Description=MyApp Service
After=network.target

[Service]
Type=simple
User=www-data
WorkingDirectory=/var/www/myapp
Environment=NODE_ENV=production
EnvironmentFile=/var/www/myapp/.env
ExecStart=/usr/bin/node /var/www/myapp/server.js
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

فعّل الخدمة وشغلها:

sudo systemctl daemon-reload
sudo systemctl enable --now myapp
sudo systemctl status myapp

الخطوة 3: إعداد Nginx كـ Reverse Proxy

sudo apt install -y nginx
sudo nano /etc/nginx/sites-available/myapp
server {
    listen 80;
    server_name example.com www.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}
sudo ln -s /etc/nginx/sites-available/myapp /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

ما دور كل مكون في النشر؟

المكون الدور
systemd تشغيل التطبيق تلقائيا وإعادة تشغيله عند الفشل
Nginx استقبال الطلبات من الإنترنت وتمريرها للتطبيق
DNS ربط الدومين بعنوان IP الخاص بالخادم

الخطوة 4: تفعيل HTTPS عبر Let's Encrypt

sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com

بعد نجاح Certbot، سيتم تحديث إعداد Nginx تلقائيا لتفعيل SSL وإعادة توجيه HTTP إلى HTTPS.

الخطوة 5: التحقق بعد النشر (Post-Deploy Checks)

  1. تحقق أن الخدمة تعمل: sudo systemctl status myapp
  2. تحقق أن Nginx سليم: sudo nginx -t
  3. اختبر الموقع عبر المتصفح على HTTPS
  4. راجع السجلات عند أي خطأ: journalctl -u myapp -n 100
  5. تأكد أن الجدار الناري يسمح بـ 80 و443 فقط عند الحاجة

Best Practices للنشر الآمن والمستقر

  • استخدم ملف .env بدون نشره في Git
  • نفّذ الاختبارات قبل إعادة تشغيل الخدمة
  • احتفظ بخطة rollback للنسخة السابقة
  • فعّل المراقبة والتنبيهات للخدمة
  • وثّق خطوات النشر في README خاص بالعمليات
نتيجة الدرس: صار لديك مسار نشر واضح: تطبيق شغال عبر systemd + Nginx + HTTPS على بيئة Linux إنتاجية.

تمرين سريع (20 دقيقة)

نفّذ Mini Deploy على خادم تجريبي:

sudo systemctl status myapp
sudo nginx -t
curl -I http://example.com
curl -I https://example.com
journalctl -u myapp -n 50 --no-pager

إذا كانت الاستجابات سليمة والخدمة مستقرة، فأنت نفذت نشر ويب حقيقي بشكل صحيح.

الأسئلة الشائعة (FAQ)

هل يمكن النشر بدون Nginx؟

ممكن تقنيا، لكن Nginx يعطيك مرونة أعلى في HTTPS، البروكسي، والأداء.

هل systemd أفضل من تشغيل node مباشرة؟

نعم في الإنتاج، لأنه يدير التشغيل التلقائي وإعادة التشغيل بعد الفشل.

ماذا أفعل إذا فشل certbot؟

تحقق أولا من DNS، ثم تأكد أن المنفذ 80 مفتوح وأن Nginx يمر باختبار nginx -t.

ممتاز، وصلت لآخر مشروع عملي

في الفصل القادم سنضع خطة مراجعة نهائية لاجتياز الاختبار الختامي بثقة.

التالي: خطة الاختبار النهائي
المحرر الذكي

اكتب الكود وشاهد النتيجة فوراً

جرب الآن مجاناً
قناة ديف عربي

تابع أحدث الدروس والتحديثات مباشرة على واتساب

انضم الآن