فهرست راهنما
سرور تازه، دامنه و مسیر بازیابی
به یک VPS تازه، IPv4 عمومی، پورت SSH شماره 22، حساب اولیه دارای sudo و دامنه تحت کنترل خود نیاز دارید. این راهنما روی سیستم میزبان سایت فعال اجرا نمی‌شود. مسیرها، نام کاربر و قواعد موجود آن سیستم ابتدا باید بررسی شوند.
در همه فرمان‌ها 203.0.113.10 را با آدرس سرور و app.example.com را با نام دامنه خود عوض کنید. این‌ها مثال‌اند. فرمان‌های محلی روی رایانه شما و فرمان‌های سرور پس از SSH اجرا می‌شوند. کنسول بازیابی ارائه‌دهنده را پیش از تغییر دسترسی باز کنید.
کلید بسازید و اتصال نخست را تأیید کنید
روی رایانه خود کلید تازه بسازید و عبارت عبور انتخاب کنید. اگر نام فایل وجود دارد، نام دیگری را در همه مراحل به کار ببرید.
mkdir -p ~/.ssh
ssh-keygen -t ed25519 -f ~/.ssh/ubuntu_vps
cat ~/.ssh/ubuntu_vps.pubهنگام ساخت VPS، فایل عمومی .pub را در بخش کلید SSH ارائه‌دهنده قرار دهید. این مسیر فرض می‌کند سرور تازه با همان کلید ساخته می‌شود؛ برای سرور موجود از دسترسی معتبر و فرایند افزودن کلید ارائه‌دهنده استفاده کنید. فایل خصوصی را بارگذاری نکنید.
در کنسول مورد اعتماد سرور، اثر انگشت کلید میزبان را بخوانید. برای نوع Ed25519:
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pubسپس روی رایانه خود وصل شوید و اثر انگشت پیام را با نتیجه کنسول مقایسه کنید. نام ubuntu را در صورت تفاوت حساب اولیه عوض کنید.
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مدیر جداگانه ایجاد و ورود آن را آزمایش کنید
روی سرور ابتدا getent passwd deploy را اجرا کنید. اگر این حساب وجود دارد، نام بلااستفاده دیگری انتخاب و در همه مسیرها و گروه‌ها جایگزین کنید. برای فرمان‌های sudo مدیر جدید رمز قوی بگذارید.
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در همین نشست جدید سرور، sudo را آزمایش کنید؛ نتیجه باید root باشد. نشست اولیه را نگه دارید.
sudo whoamiNginx و فایروال متناسب با ایمیج
روی سرور نصب و فعال‌سازی را انجام دهید.
sudo apt install nginx
sudo systemctl enable --now nginxدر شبکه ارائه‌دهنده، SSH را از محل مدیریت و HTTP/HTTPS را برای بازدیدکنندگان مجاز کنید. اگر پورت SSH متفاوت است، همان پورت را حفظ کنید. قواعد شبکه جای فایروال سیستم‌عامل را نمی‌گیرند.
ایمیج اوبونتو در Oracle: بخش UFW زیر را کامل رد کنید. قواعد موجود iptables و قواعد ضروری iSCSI را نگه دارید و قواعد شبکه OCI و مهمان را طبق مستندات همان ایمیج تنظیم کنید. فعال کردن UFW روی آن می‌تواند راه‌اندازی ماشین را مختل کند.
فقط برای ایمیج تازه دیگری که ارائه‌دهنده 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پس از هر مسیر، یک ورود SSH تازه را بررسی کنید. باز ماندن نشست قبلی، موفقیت اتصال جدید را ثابت نمی‌کند.
صفحه را در سایت مستقل Nginx منتشر کنید
روی سرور پوشه و تنظیمات زیر را برای این آزمایش بسازید. اگر این مسیرها از قبل استفاده می‌شوند ادامه ندهید. نام دامنه را جایگزین و علامت نقل‌قول اطراف 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فقط پس از موفقیت nginx -t تنظیمات را بازخوانی کنید.
sudo systemctl reload nginxروی رایانه، پیش از تغییر DNS، نام دامنه را مستقیماً با آدرس سرور درخواست کنید. باید صفحه آزمایشی خودتان را ببینید، نه صفحه پیش‌فرض Nginx.
curl --resolve app.example.com:80:203.0.113.10 http://app.example.com/DNS و گواهی HTTPS
رکورد A دامنه را به IPv4 سرور بدهید. فقط اگر IPv6 واقعاً کار می‌کند رکورد AAAA منتشر کنید. این مسیر DNS مستقیم و بدون پراکسی را فرض می‌کند. از رایانه، HTTP دامنه را بدون --resolve بررسی کنید و پس از دریافت صفحه درست ادامه دهید.
روی سرور Certbot و افزونه Nginx را از مخزن اوبونتو نصب کنید. بسته‌ها به مخزن Universe نیاز دارند؛ اگر بسته پیدا نشد، همان خطا را پیش از ادامه برطرف کنید.
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 وارد کنید. تغییر مسیر HTTPS و زمان‌بندی تمدید را بررسی کنید. اگر certbot.timer غیرفعال است، آن را با sudo systemctl enable --now certbot.timer فعال کنید. پورت 80 برای اعتبارسنجی و تمدید این روش در دسترس بماند.
از بیرون و پس از راه‌اندازی مجدد بررسی کنید
روی رایانه خود HTTP، HTTPS و محتوای پاسخ را بررسی کنید. گزینه -k اضافه نکنید؛ خطای اعتبار گواهی را پنهان می‌کند.
curl -I http://app.example.com/
curl -I https://app.example.com/
curl -fsS https://app.example.com/وقتی هنوز سایت آزمایشی است، روی سرور sudo reboot را اجرا کنید. قطع SSH در این مرحله عمدی است. پس از برگشت، با deploy وارد شوید، systemctl is-active nginx را بررسی کنید و درخواست HTTPS بیرونی را تکرار کنید. اگر ماشین برنگشت از کنسول کمک بگیرید.
خطا و بازیابی را بخشی از انتشار بدانید
برای دیدن همه ستون‌ها، جدول را به‌صورت افقی جابه‌جا کنید.
| نشانه | بررسی اولیه |
|---|---|
| خطای SSH | آدرس، کاربر، کلید و قواعد دو لایه فایروال |
| صفحه پیش‌فرض Nginx | مقصد DNS، server_name و سایت فعال |
| خطای گواهی | رکوردهای عمومی A/AAAA و دسترسی پورت 80 |
| خطای تنظیمات Nginx | nginx -t و گزارش سرویس |
راهنمای خطاهای SSH و تمرین بکاپ فایل‌ها مراحل بعدی‌اند. فایل‌های سایت، تنظیمات، اطلاعات DNS و دستور ساخت مجدد را مستقل نگه دارید. این راهنما پایگاه داده، WordPress یا محیط Node.js نصب نمی‌کند؛ آن‌ها تنظیمات و بکاپ سازگار خود را لازم دارند.
این مثال برای Ubuntu 24.04 تازه، DNS مستقیم و پورت SSH شماره 22 نوشته شده است. روش کامل روی تمام ایمیج‌های ارائه‌دهندگان آزمایش نشده؛ شاخه فایروال را مطابق محیط واقعی انتخاب کنید.
پرسش‌های رایج
آیا این فرمان‌ها برای سایت فعال من مناسب‌اند؟
ابتدا روی VPS آزمایشی جدا اجرا کنید. این روش فایل می‌سازد، تنظیمات شبکه را تغییر می‌دهد و به Certbot اجازه تغییر Nginx می‌دهد.
آیا نصب این صفحه یعنی برنامه من هم آماده است؟
خیر. خروجی این مسیر یک سایت ایستای HTTPS است. برای برنامه پویا باید سرویس اجرا، شروع خودکار، بررسی سلامت و بازیابی داده را جدا آزمایش کنید.
چرا UFW در Oracle فرق دارد؟
ایمیج Oracle قواعد ضروری مخصوص زیرساخت خود دارد. آن قواعد را حفظ کنید و مسیر مستند فایروال همان ایمیج را دنبال کنید.