راه‌اندازی Ubuntu برای سایت فقط نصب Nginx یا Apache نیست. سرور production باید دسترسی قابل بازیابی، patch، firewall، TLS، runtime، دیتابیس، backup، log و مانیتورینگ داشته باشد. اگر DNS را پیش از آزمون این زنجیره تغییر دهید، اولین خطای ساده ممکن است به قطعی و بازگشت دشوار تبدیل شود.
پاسخ سریع: ابتدا inventory و مسیر دسترسی اضطراری بسازید، سیستم را به نسخه پشتیبانی‌شده patch کنید، کاربر مدیریتی با SSH key و firewall مرحله‌ای آماده کنید. سپس stack وب را با حداقل سرویس، TLS و backup نصب کنید؛ سایت را با hostname آزمایشی و smoke test بسنجید و تنها با TTL و rollback مشخص DNS را منتقل کنید.
پیش‌نیازهای قبل از ورود
- نسخه Ubuntu پشتیبانی‌شده و image معتبر
- IP، console ارائه‌دهنده و اطلاعات شبکه
- دامنه و دسترسی DNS
- نیاز runtime، دیتابیس و نسخه‌های پشتیبانی‌شده
- برآورد CPU، RAM، storage و ترافیک
- RPO/RTO و مقصد backup مستقل
- مالک patch و پاسخ incident
وضعیت اولیه را فقط بخوانید
lsb_release -a
uname -r
ip -br addr
ss -lntup
free -h
df -h
systemctl --failedاین فرمان‌ها وضعیت را نمایش می‌دهند و تنظیمات را تغییر نمی‌دهند. خروجی IP عمومی، نام کاربری و اطلاعات شبکه را پیش از ارسال عمومی ناشناس کنید. سرویس ناشناخته یا پورت باز باید پیش از ادامه بررسی شود.
Patch و برنامه Reboot
بسته‌ها را از repository معتبر دریافت کنید. update kernel یا کتابخانه حیاتی ممکن است reboot یا restart بخواهد؛ maintenance window و console اضطراری داشته باشید. ارتقای major نسخه Ubuntu پروژه جدا با backup و compatibility test است، نه بخشی از نصب روزمره.
کاربر مدیریتی و حداقل دسترسی
کار روزمره را با کاربر مشخص و sudo کنترل‌شده انجام دهید. SSH key را روی دستگاه امن بسازید و private key را روی سرور یا repository کپی نکنید. حساب هر فرد جدا باشد تا revoke و audit ممکن شود. root مشترک و shared password مسیر نگهداری مناسبی نیست.
SSH را بدون قفل‌شدن امن کنید
ابتدا login با کلید را در session دوم آزمایش و console را باز نگه دارید. سپس password/root login را مرحله‌ای محدود کنید. پیش از reload، syntax config را با ابزار همان نسخه بررسی کنید. تغییر هم‌زمان پورت، firewall و authentication تشخیص خطا را دشوار می‌کند.
Firewall با Allowlist حداقلی
تنها پورت‌های HTTP/HTTPS و مدیریت لازم را باز کنید. پیش از فعال‌سازی، rule SSH از شبکه مدیریت و مسیر console را تأیید کنید. دیتابیس و Redis نباید بی‌دلیل روی اینترنت باشند. Docker نیز می‌تواند rule شبکه اضافه کند؛ مسیر packet را واقعاً تست کنید.
زمان، Hostname و DNS
همگام‌سازی ساعت برای TLS، log، token و cron حیاتی است. timezone نمایشی را آگاهانه تنظیم کنید، اما logها را با مبنای قابل تطبیق نگه دارید. رکورد A/AAAA را فقط وقتی فعال کنید که هر دو مسیر پاسخ صحیح دهند؛ IPv6 نیمه‌پیکربندی‌شده برای بخشی از کاربران خطا می‌سازد.
Nginx یا Apache
هر دو می‌توانند production مناسب باشند. سازگاری برنامه، تجربه تیم، rewrite و معماری proxy مهم‌تر از برچسب «سریع‌ترین» است. هم‌زمانی دو سرویس روی یک پورت خطا ایجاد می‌کند. document root، مالک فایل و virtual host را صریح تعریف کنید.
Runtime برنامه
نسخه PHP، Python، Node یا runtime دیگر باید توسط برنامه و افزونه‌ها پشتیبانی شود. repository ناشناخته اضافه نکنید. process manager، worker، timeout و memory را با workload تنظیم کنید. اجرای برنامه با root یا مجوز 777 راه‌حل permission نیست.
دیتابیس را عمومی نکنید
دیتابیس را روی interface و firewall لازم محدود و user برنامه را حداقلی کنید. رمز را در config عمومی، history یا repository نگذارید. charset، timezone، backup و connection limit را با برنامه هماهنگ کنید. تغییر مستقیم داده production برای نصب توصیه نمی‌شود.
مالکیت فایل و Deployment
کد، upload و secret چرخه متفاوت دارند. releaseها را نسخه‌دار و قابل rollback نگه دارید و فایل کاربر را خارج از مسیر جایگزینی کد قرار دهید. permission را بر اساس فرایند خواندن/نوشتن تنظیم کنید، نه با باز کردن همگانی.
TLS و Redirect
گواهی باید دامنه واقعی و زنجیره کامل داشته باشد. تمدید خودکار را dry run و با alert انقضا کنترل کنید. redirect HTTP به HTTPS را پس از اطمینان از پاسخ دامنه فعال کنید. HSTS اثر بلندمدت دارد و پیش از آمادگی زیردامنه‌ها نباید عجولانه اعمال شود.
Headerهای Proxy و IP واقعی
اگر CDN یا reverse proxy دارید، scheme، host و IP واقعی را فقط از proxyهای مورد اعتماد بپذیرید. اعتماد سراسری به header ارسالی کاربر امکان جعل IP و دور زدن rate limit می‌دهد. redirect loop و secure cookie اغلب از تشخیص نادرست HTTPS پشت proxy می‌آیند.
Log و Rotation
access/error log وب‌سرور، برنامه، runtime، دیتابیس و journal را مشخص کنید. retention و rotation مانع پر شدن دیسک می‌شود. secret، cookie و payload پرداخت نباید log شوند. timestamp و request ID مشترک عیب‌یابی را ساده می‌کند.
Backup مستقل و Restore Test
از دیتابیس، فایل کاربر و config نسخه هماهنگ بگیرید و کپی خارج از همان سرور نگه دارید. encryption، retention و دسترسی restore را تعیین کنید. snapshot همان حساب برای همه سناریوها کافی نیست. restore را دوره‌ای روی محیط جدا آزمایش و زمان واقعی را ثبت کنید.
مانیتورینگ و Alert
- HTTP و اعتبار TLS
- CPU، load، available RAM و OOM
- فضای دیسک، inode و I/O latency
- وضعیت process و restart
- نرخ 4xx/5xx و p95
- دیتابیس، queue و تازگی backup
alert باید مسئول و runbook داشته باشد. هشدار CPU بدون مسیر تشخیص یا هشدار بعد از پر شدن کامل دیسک دیر است.
کنترل Brute Force
ابزار ban می‌تواند نویز و brute force را کم کند، اما جای key، firewall و patch را نمی‌گیرد. log source، threshold و allowlist مدیریت را درست تنظیم کنید تا مدیر یا proxy اشتباه block نشود. IP واقعی پشت proxy را فقط از مبدأ مورد اعتماد بخوانید.
آماده‌سازی سایت پیش از DNS
با hostname آزمایشی یا override کنترل‌شده، صفحه اصلی، asset، login، upload، cron، ایمیل و مسیر خرید را تست کنید. header Host و HTTPS باید مشابه production باشد؛ تست فقط با IP، virtual host و certificate واقعی را پوشش نمی‌دهد.
انتقال DNS با Rollback
- TTL را با فاصله مناسب کاهش دهید.
- backup نهایی و sync داده را انجام دهید.
- write هم‌زمان و سفارش را در برنامه لحاظ کنید.
- رکوردها را به مقصد آزموده‌شده تغییر دهید.
- هر دو سرور و metricها را پایش کنید.
- پس از پایداری TTL را برگردانید.
برای سایت فعال، راهنمای انتقال وردپرس از هاست اشتراکی به VPS معیارهای زیرساخت و برنامه cutover را تکمیل می‌کند.
سخت‌سازی سرویس‌ها
سرویس‌ها را با user جدا، دسترسی filesystem محدود و secret خارج از کد اجرا کنید. سرویس بلااستفاده را پس از inventory غیرفعال کنید. hardening template عمومی را کور اعمال نکنید؛ نیاز برنامه، update و مسیر rollback را بسنجید.
برنامه نگهداری پس از نصب
نصب پایان کار نیست. پنجره patch، بازبینی دسترسی، آزمون restore، تمدید TLS، ظرفیت دیسک و review alert را زمان‌بندی کنید. owner هر کار و شیوه ثبت تغییر باید روشن باشد. configuration drift میان مستندات و سرور incident را طولانی می‌کند.
کنترل نهایی خواندنی
ss -lntup
df -h
free -h
systemctl --failed
journalctl -p err -bفرمان آخر خطاهای boot جاری را نشان می‌دهد و ممکن است پیام قدیمی یا غیرمرتبط داشته باشد؛ هر مورد را با سرویس و timestamp بررسی کنید. پس از استقرار، از بیرون سرور نیز پورت و HTTPS را کنترل کنید.
معیار تحویل Production
- دسترسی مدیر و console بازیابی آزموده شده
- فقط پورت‌های موردنیاز باز هستند
- HTTPS و تمدید گواهی کنترل شده
- backup تازه restore شده است
- monitor و alert به فرد پاسخ‌گو می‌رسد
- rollback release و DNS مستند است
- smoke test برنامه و عملیات تجاری موفق است
اشتباه‌های رایج
- بستن SSH پیش از session دوم
- باز کردن DB/Redis روی اینترنت
- استفاده از
chmod 777 - نگهداری secret در repository
- DNS پیش از آزمون Host/TLS
- backup بدون restore test
- چند وب‌سرور/firewall بدون نقشه
چه زمانی کمک تخصصی لازم است؟
اگر سایت فروشگاهی، مهاجرت بدون قطعی یا شبکه محدود دارید، خطا در SSH، firewall، TLS یا DNS دسترسی را قطع می‌کند. نصب و کانفیگ سرور لینوکس می‌تواند stack را با backup، hardening، مانیتورینگ و rollback آماده کند.
پرسش‌های متداول
Ubuntu Server یا Desktop؟
Server معمولاً بدون محیط گرافیکی و با سطح سرویس کمتر مناسب است؛ نیاز برنامه و تیم را بررسی کنید.
تغییر پورت SSH کافی است؟
نویز اسکن را کم می‌کند اما جای key، محدودیت دسترسی، patch و مانیتورینگ را نمی‌گیرد.
اول DNS یا SSL؟
به validation بستگی دارد؛ مقصد را پیش از cutover با Host واقعی آزمایش و مسیر صدور/تمدید را طراحی کنید.
Snapshot همان Backup است؟
برای بعضی بازیابی‌ها مفید است، اما استقلال، سازگاری، retention و restore test همچنان لازم‌اند.