محتويات الدليل
حضّر الوصول قبل إنشاء الجهاز
أنشئ المفتاح التالي على حاسوب Linux أو macOS أو WSL قبل إنشاء الخادم. اختر اسمًا مختلفًا إذا كان الملف موجودًا، واستخدم عبارة مرور. ارفع الملف العام فقط إلى لوحة المزود؛ لا ترفع المفتاح الخاص.
mkdir -p ~/.ssh
ssh-keygen -t ed25519 -f ~/.ssh/ubuntu_vps
cat ~/.ssh/ubuntu_vps.pubاختر صورة أوبونتو الرسمية وافحص اسم مستخدمها ومنفذ SSH الفعلي. يعتمد المثال على المنفذ 22. بعد الإنشاء، افتح وحدة تحكم موثوقة للجهاز نفسه واقرأ بصمة المضيف:
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pubمن حاسوبك، استبدل العنوان التوثيقي بعنوان جهازك واسم المستخدم بالاسم الصحيح للصورة. قارن نوع المفتاح وبصمة SHA256 قبل قبول هوية المضيف.
ssh -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10انسخ المفتاح العام فقط إلى الحساب الأولي تمهيدًا لإنشاء مدير منفصل:
scp -i ~/.ssh/ubuntu_vps ~/.ssh/ubuntu_vps.pub ubuntu@203.0.113.10:ubuntu-vps-admin.pubأنشئ مديرًا منفصلاً واختبره
احتفظ بالجلسة الأصلية مفتوحة. تأكد من أن deploy اسم جديد ومقصود؛ إن كان الحساب موجودًا فتوقف وراجع إعداداته بدلاً من استبدالها. الأوامر التالية تنشئه وتثبت المفتاح العام مع الملكية والصلاحيات اللازمة:
cat /etc/os-release
free -h
df -h /
sudo apt update
sudo apt upgrade
sudo adduser deploy
sudo usermod -aG sudo deploy
sudo install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
sudo install -m 600 -o deploy -g deploy ~/ubuntu-vps-admin.pub /home/deploy/.ssh/authorized_keysافتح طرفية جديدة على حاسوبك واختبر دخول المدير:
ssh -i ~/.ssh/ubuntu_vps deploy@203.0.113.10داخل جلسة deploy اختبر sudo:
sudo whoamiلا تغلق الوصول الأول ولا تعطل طريقة دخول قبل نجاح الجلسة الثانية وصلاحياتها. احتفظ بوصول وحدة التحكم إن تغيرت الشبكة أو إعدادات SSH.
ثبّت Nginx وافتح مسار الشبكة المناسب
نفّذ داخل الخادم بعد اكتمال تهيئة الصورة. راجع الترقيات والتغييرات المطلوبة قبل الموافقة:
sudo apt install nginx
sudo systemctl enable --now nginxاسمح بـ TCP على 80 و443 في جدار المزود، مع الحفاظ على منفذ الإدارة الفعلي. الصورة والجدار داخل الضيف يحددان الخطوة التالية.
على Ubuntu في Oracle OCI: لا تثبّت UFW ولا تفعّله. استخدم قواعد OCI وقواعد الضيف المتوافقة مع وثائق الصورة، واحفظ قواعد iSCSI. انتقل بعد ذلك إلى نشر الملفات.
على صورة أخرى يدعم فيها المزود UFW، وكان SSH يستخدم 22 كما في هذا المثال، يمكنك تطبيق الأوامر التالية. إذا تغير المنفذ فاسمح بالمنفذ الفعلي أولاً. أبقِ الجلسة الحالية مفتوحة واختبر جلسة جديدة بعد التفعيل.
sudo apt install ufw
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verboseانشر صفحة اختبار دون المساس بموقع قائم
هذا المسار ينشئ جذرًا جديدًا باسم first-site وإعداد Nginx مخصصًا. افحص أن الملفات والأسماء غير مستخدمة. استبدل app.example.com باسم المضيف الذي تتحكم به قبل التنفيذ. محدد EOF المقتبس يحافظ على متغير Nginx مثل $uri داخل النص.
sudo install -d -m 755 /var/www/first-site
printf '%s\n' '<!doctype html><html lang="en"><title>First deployment</title><h1>Ubuntu VPS is serving this page</h1></html>' | sudo tee /var/www/first-site/index.html
sudo tee /etc/nginx/sites-available/first-site >/dev/null <<'EOF'
server {
listen 80;
listen [::]:80;
server_name app.example.com;
root /var/www/first-site;
index index.html;
location / {
try_files $uri $uri/ =404;
}
}
EOF
sudo ln -s /etc/nginx/sites-available/first-site /etc/nginx/sites-enabled/first-site
sudo nginx -tافحص الإعداد قبل إعادة التحميل؛ عند فشل الفحص أصلح الرسالة أولاً. لا تستخدم إعادة التشغيل لإخفاء خطأ الإعداد.
sudo systemctl reload nginxمن حاسوبك اختبر توجيه اسم النطاق إلى الخادم قبل تغيير DNS. استبدل الاسم والعنوان في الأمر كليهما:
curl --resolve app.example.com:80:203.0.113.10 http://app.example.com/تحقق من محتوى الصفحة المتوقع، لا من رمز 200 فقط؛ فقد يجيب مضيف افتراضي آخر.
وجّه DNS ثم أصدر شهادة HTTPS
يفترض هذا المسار أن DNS يشير مباشرة إلى الخادم دون وسيط proxy. أضف سجل A للاسم app.example.com بعد استبداله باسمك نحو عنوان IPv4 الصحيح. لا تضف AAAA إلا إذا كان مسار IPv6 يعمل إلى الموقع نفسه. اختبر http://app.example.com/ باسمك من خارج الخادم ودون --resolve بعد انتشار السجل؛ الشهادة لا تصلح خطأ DNS أو جدارًا مغلقًا.
الأوامر التالية تستخدم حزم Ubuntu، بما فيها مستودع Universe عند الحاجة. اقرأ خيارات Certbot واستخدم النطاق الذي اختبرته وبريدًا تتابعه لتنبيهات الشهادة.
sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d app.example.com --redirect
sudo nginx -t
sudo certbot renew --dry-run
systemctl list-timers --all certbot.timerافحص نجاح إصدار الشهادة ومؤقت التجديد وتجربة التجديد الجافة. إذا كان certbot.timer غير مفعّل، راجع تثبيت الحزم وفعّله عند انطباقه باستخدام sudo systemctl enable --now certbot.timer. لا تعد التجديد جاهزًا لمجرد نجاح الإصدار الأول.
اختبر من خارج الخادم ثم بعد إعادة التشغيل
من حاسوبك اختبر التحويل وHTTPS بالمجال الصحيح. لا تضف -k لتجاوز التحقق من الشهادة:
curl -I http://app.example.com/
curl -I https://app.example.com/
curl -fsS https://app.example.com/تأكد من تحويل HTTP إلى HTTPS ومن صلاحية الشهادة والمحتوى المقصود. أبقِ منفذ 80 متاحًا إذا كانت طريقة تجديدك تحتاجه، واختبر IPv4 وIPv6 إذا نشرت كليهما.
أعد تشغيل الجهاز وهو ما يزال اختبارًا، ثم تحقق من SSH وNginx والموقع. سجّل الإصدار ومسارات الإعداد واسم النطاق وتاريخ الاختبار. إن تعذر الدخول، راجع مسار تشخيص SSH مع الحفاظ على وحدة التحكم.
أكمل متطلبات التطبيق قبل استقبال الزوار
هذه صفحة ثابتة؛ لا تثبت سعة تطبيق ديناميكي أو سلامة قاعدة بيانات. قبل نقل موقع، جهّز نسخة مستقلة واختبر الاستعادة، ثم خطط للمزامنة النهائية والمهام والبريد والملفات المرفوعة. احتفظ بالخدمة السابقة حتى تأكيد النتيجة.
انتقل إلى تجربة النسخ والاستعادة وإلى فحص توافق الحزم عند إضافة بيئة تشغيل. لا تنشر مفاتيح أو ملفات إعداد سرية داخل جذر الويب.
الأوامر من الدليل الإنجليزي نفسه، ومسار الشرح هنا يقتصر على جهاز جديد وصورة Ubuntu 24.04 LTS. راجع متطلبات صورة المزود قبل تعديل الجدار.
أسئلة شائعة
هل أحتاج إلى النطاق قبل تثبيت Nginx؟
يمكن تثبيت الخدمة واختبارها بالعنوان وترويسة المضيف أولاً. تحتاج نطاقًا تتحكم به وDNS صحيحًا عند إصدار شهادة HTTPS لهذا المسار.
هل تصلح الأوامر لخادم يستضيف موقعًا بالفعل؟
المسار مخصص لجهاز جديد. الموقع القائم يحتاج مراجعة أسماء المستخدمين والمسارات والمضيفات الافتراضية وخطة استعادة قبل أي تغيير.
هل نجاح HTTPS يعني أن الخادم جاهز للإنتاج؟
يثبت نجاح المسار المختبر والشهادة فقط. تحتاج أيضًا إلى صيانة ومراقبة ونسخ مستقل واختبار التطبيق وسعته.