چرا یک runtime مدیریتشده PHP بر یک VPS خام برتری دارد
روی یک VPS خام، شما مالک کل استک هستید: بهروزرسانیهای سیستمعامل، pool مربوط به PHP-FPM، پیکربندی وبسرور، تمدید TLS، قواعد فایروال و daemon دیتابیس. انحراف هرکدام از اینها سایت را خراب میکند، و بیشتر این کار هیچ ربطی به اپلیکیشن شما ندارد. پلتفرم مدیریتشده PHP به شما یک runtime پشتیبانیشده PHP 8 با افزونههای معمول از پیش موجود میدهد، بنابراین مسئولیت شما به کد، وابستگیها و پیکربندی آن — بخشهایی که واقعاً مال شماست — کوچک میشود.
سازگار با فریمورکهای Laravel و Symfony
فریمورکهای مدرن یک چیدمان مشخص انتظار دارند: یک document root از نوع public/، یک دایرکتوری قابلنوشتن storage یا var، وابستگیهای مدیریتشده با Composer، و جایی برای اجرای migration های دیتابیس در زمان deploy. پلتفرم مستقیماً به آن نگاشت میشود — document root را روی public/ تنظیم میکنید، بقیه درخت را خصوصی نگه میدارید و دستورهای composer install و migration مربوط به artisan/console را به گامهای deploy وصل میکنید. Redis برای cache، صفها و نشستها در دسترس است، که دقیقاً همان چیزی است که یک queue worker از نوع Laravel یا یک cache pool از نوع Symfony میخواهد.
MySQL و Redis مدیریتشده بدون آنکه DBA باشید
برپا کردن MySQL و Redis بهدست خودتان یعنی تنظیم، پشتیبانگیری، مدیریت کاربران و وصله نگه داشتن آنها. اینجا هر دو افزونههای مدیریتشدهاند: آنها را تأمین میکنید، و host، port، user و password آنها بهجای چسبانده شدن در یک فایل پیکربندی، به محیط اپلیکیشن تزریق میشوند. این کار secret ها را بیرون از تاریخچه Git شما نگه میدارد، به شما امکان میدهد یک password دیتابیس را بدون deploy مجدد کد بچرخانید، و یعنی datastore جدا از runtime اپلیکیشن شما نگهداری میشود.
به همان روشی که تیم شما کار میکند deploy کنید
هر پروژه PHP هنوز روی Git نیست، و این اشکالی ندارد. یک سایت کوچک یا یک اپلیکیشن قدیمی را میتوان از طریق file manager آپلود کرد و ظرف چند دقیقه زنده کرد. یک تیم با یک مخزن، Git یا GitHub را متصل میکند و push-to-deploy با گامهای build تعریفشده — composer install، یک build فرانتاند، migration ها — بهدست میآورد، بنابراین انتشارها تکرارپذیرند نه یک کشیدنورها کردن SFTP که کسی فایلی را در آن جا میگذارد. وضعیت deploy و زمان آخرین deploy در پنل قابلمشاهدهاند.
edge cache و WAF در جلوی PHP پویا
اپلیکیشنهای PHP برای رندر صفحات CPU واقعی مصرف میکنند، بنابراین ارائه پاسخهای قابلcache از edge مستقیماً runtime شما را از بار محافظت میکند. تصمیم میگیرید کدام مسیرها امناند که cache شوند — یک کاتالوگ عمومی یا یک مقاله — و کدام همیشه اجرا میشوند، مانند یک داشبورد کاربر واردشده یا یک endpoint از نوع POST. WAF در edge در جلوی اپلیکیشن قرار میگیرد و ترافیک injection و اسکنر را پیش از رسیدن به PHP فیلتر میکند، و Auto SSL بدون یک cron تمدید، HTTPS را معتبر نگه میدارد.
یک مسیر کنترلشده برای مدرنسازی PHP قدیمی
اپلیکیشنهای قدیمی نوشتهشده برای PHP 5 یا یک CMS نگهدارینشده، دست زدن به آنها خطرناک است، اما نمیتوانند برای همیشه روی یک runtime پایانعمر بمانند. پلتفرم به شما جایی میدهد تا کد را بیاورید، دیتابیس آن را با مجموعهکاراکتر درست به MySQL مدیریتشده منتقل کنید و آن را روی PHP 8 اجرا کنید، جایی که میتوانید deprecation ها را بیابید و اصلاح کنید. روی یک URL موقت راستیآزمایی میکنید و WAF را جلوی یک codebase که دیگر وصله امنیتی دریافت نمیکند قرار میدهید، بنابراین سطح حمله عمومی حتی پیش از پاکسازی کامل کد کاهش مییابد.
راهنمای گامبهگام deploy
اپلیکیشن PHP را بسازید و runtime را انتخاب کنید
در پنل بخش Platform را باز کنید، PHP را انتخاب کنید و نسخه PHP 8 و پلن را برگزینید. runtime با افزونههای رایجی که اپلیکیشنهای PHP انتظار دارند — PDO، mbstring، GD، OpenSSL و افزونه Redis — عرضه میشود، بنابراین برای فعال شدن یک افزونه تیکت باز نمیکنید.
کد خود را روی پلتفرم بیاورید
از file manager توکار برای یک آپلود سریع استفاده کنید، یا یک مخزن Git/GitHub متصل کنید تا یک push اپلیکیشن را deploy کند. برای اپلیکیشنهای فریمورکی، document root را روی دایرکتوری public/ تنظیم و گامهای build و migration را یکبار تعریف میکنید.
یک دیتابیس مدیریتشده و Redis متصل کنید
یک دیتابیس مدیریتشده MySQL و در صورت نیاز اپلیکیشن به caching، صفها یا نشستها، یک نمونه مدیریتشده Redis تأمین کنید. مقادیر اتصال بهعنوان متغیرهای محیطی به runtime تزریق میشوند، بنابراین اعتبارنامهها بیرون از .env commitشده شما میمانند و میتوان آنها را از پنل چرخاند.
دامنه را اشاره دهید و Auto SSL صادر کنید
دامنه خود یا یک زیردامنه name.cdn.com.tr را متصل کنید، و Auto SSL گواهی را برای apex و www صادر و تمدید میکند. اکنون ترافیک ابتدا به edge شبکه cdn.com.tr میرسد، جایی که خاتمه SSL پیش از proxy شدن درخواستها به runtime از نوع PHP شما انجام میشود.
cache، WAF و گامهای deploy را تنظیم کنید
تعریف کنید کدام مسیرها در edge قابلcache هستند و کدام همیشه به PHP میرسند، یک پروفایل WAF اعمال کنید، و خط deploy را قفل کنید — برای مثال composer install، یک build دارایی و migration های دیتابیس — تا هر انتشار همان گامها را اجرا کند و با یک purge خودکار پایان یابد.
نمونه سناریوها
یک اپلیکیشن Laravel از GitHub با composer install و migration ها deploy میشود، از MySQL مدیریتشده و یک صف Redis استفاده میکند و پشت Auto SSL و WAF ارائه میشود.
یک پرتال قدیمی با CMS سفارشی به PHP 8 با یک دیتابیس مدیریتشده منتقل، پشت WAF قرار داده و مسیربهمسیر بدون قطعی مدرن میشود.
یک API از نوع PHP دستنویس روی runtime مدیریتشده با Redis برای وضعیت rate-limit و نشست اجرا میشود و روی یک دامنه با خاتمه SSL در edge در معرض دید قرار میگیرد.
پرسشهای پرتکرار
کدام افزونههای PHP روی runtime در دسترساند؟
runtime از نوع PHP 8 با افزونههایی که اپلیکیشنهای معمول به آنها وابستهاند عرضه میشود — درایورهای PDO و MySQL، mbstring، GD برای کار با تصویر، OpenSSL، cURL و افزونه Redis که برای cache، نشستها و صفها استفاده میشود. چون مجموعه افزونهها استاندارد است، Laravel، Symfony و بیشتر بستههای Composer بدون یک build سفارشی نصب میشوند.
آیا میتوانم یک queue worker از نوع Laravel یا کارهای زمانبندیشده اجرا کنم؟
بله. Redis بهعنوان یک backend صف در دسترس است، و پلتفرم اپلیکیشن شما را روی یک runtime پایدار اجرا میکند نه یک sandbox بهازای هر درخواست، بنابراین پردازش پسزمینه و کارهای زمانبندیشده با این مدل جور درمیآیند. دستورها را بهعنوان بخشی از پیکربندی اپلیکیشن تعریف میکنید نه ویرایش یک crontab سیستمی روی سروری که در غیر این صورت باید مدیریتش میکردید.
اعتبارنامههای دیتابیس چگونه بدون commit کردن secret ها به .env من میرسند؟
جزئیات اتصال دیتابیس مدیریتشده و Redis به محیط runtime تزریق میشوند. فریمورک شما آنها را از محیط میخواند همانطور که پیشتر مقادیر .env را میخواند، بنابراین هرگز host، user یا password را به Git commit نمیکنید، و چرخاندن یک password در پنل نیازی به تغییر کد ندارد.
اپلیکیشن من PHP 7 را هدف گرفته — آیا روی PHP 8 اجرا میشود؟
بیشتر کد نگهداریشده با تنظیمات جزئی روی PHP 8 اجرا میشود، اما PHP 8 برخی رفتارهای منسوخ را حذف کرده است. رویکرد درست این است که کد را روی پلتفرم بیاورید، آن را روی یک URL موقت اجرا کنید و deprecation هایی را که مییابید پیش از تغییر دامنه اصلاح کنید — runtime مدیریتشده جای امنی برای انجام دقیق همین کار به شما میدهد.
آیا document root را روی public/ تنظیم کنم؟
بله. برای Laravel، Symfony و فریمورکهای مشابه، web root را روی دایرکتوری public/ اشاره میدهید تا بقیه درخت اپلیکیشن — شامل .env، vendor و storage — بیرون از مسیر ارائهشده وب بماند. اپلیکیشنهای قدیمی که از دایرکتوری سطحبالای خود ارائه میدهند نیز پشتیبانی میشوند؛ root را متناسب با آن تنظیم میکنید.
چگونه آپلود فایلهایی را که باید از یک deploy مجدد جان بهدر ببرند رسیدگی کنم؟
اپلیکیشن یک volume پایدار برای داده کاربر دارد، و برای اپلیکیشنهای پُررسانه میتوانید آپلودها را به object storage منتقل و آنها را بهجای runtime از طریق CDN ارائه کنید. این deploy ها را سریع و بدونوضعیت نگه میدارد، و یعنی یک deploy مجدد یا رویداد scale هرگز فایلهای آپلودشده را به خطر نمیاندازد.