Loading...
مورد کاربرد

مورد کاربرد: یک اپلیکیشن PHP قدیمی را ایمن مهاجرت دهید

اپلیکیشن‌های قدیمی PHP معمولاً روی نسخه‌های پایان‌عمر PHP، یک دیتابیس که کسی نمی‌خواهد به آن دست بزند، و یک سرور که یک خرابی دیسک تا یک قطعی فاصله دارد اجرا می‌شوند. این سناریو یک اپلیکیشن قدیمی را به یک runtime مدرن PHP 8 با یک دیتابیس مدیریت‌شده و امنیت edge می‌برد، با استفاده از staging و rollback تا مهاجرت هرگز با ترافیک زنده قمار نکند.

مورد کاربرد: یک اپلیکیشن PHP قدیمی را ایمن مهاجرت دهید

مشکل: PHP قدیمی یک قطعی آهسته است

یک اپلیکیشن قدیمی PHP معمولاً سه خطر را هم‌زمان حمل می‌کند: روی نسخه‌ای از PHP اجرا می‌شود که دیگر اصلاحات امنیتی نمی‌گیرد، از طریق افزونه‌هایی با دیتابیس صحبت می‌کند که PHP مدرن حذف کرده، و روی یک سرور فرسوده واحد زندگی می‌کند که کسی جرئت restart آن را ندارد. هر ماهی که می‌گذرد آن را بیشتر در معرض خطر و جابه‌جایی‌اش را سخت‌تر می‌کند، چون حافظه سازمانی از نحوه کارش محو می‌شود در حالی که سطح حمله رشد می‌کند. غریزهٔ رها کردن آن قابل‌درک و دقیقاً همان چیزی است که آن را خطرناک می‌کند — هرچه بیشتر بماند، مهاجرت اجباری نهایی بزرگ‌تر می‌شود. این سناریو وجود دارد تا جابه‌جایی را عمدی و بازگشت‌پذیر کند به‌جای یک اضطرار.

cdn.com.tr چگونه آن را حل می‌کند: runtime مدرن، داده مدیریت‌شده، سپر edge

PHP Platform به اپلیکیشن یک runtime پشتیبانی‌شده PHP 8 با یک file manager مناسب و انتخاب نسخه می‌دهد، بنابراین دیگر به هر آنچه روی جعبه قدیمی نصب بود میخکوب نیستید. دیتابیس مدیریت‌شده داده را از آن سرور شکننده برمی‌دارد و روی یک سرویس نگهداری‌شده MySQL با اعتبارنامه‌های تزریق‌شده به runtime به‌جای چسبانده در فایل‌های پیکربندی قرار می‌دهد. جلوی هر دو، لایه edge با Auto SSL، TLS را خاتمه و با WAF ترافیک را فیلتر می‌کند، بنابراین حتی کدی که پیش از شیوه‌های امنیتی مدرن است مستقیماً در معرض اینترنت نیست. runtime و لایه داده را مدرن می‌کنید در حالی که کل مجموعه را در محافظتی می‌پیچید که اپلیکیشن اصلی هرگز نداشت.

سازگاری PHP 8: کاری که واقعاً دروازه جابه‌جایی است

مهاجرت با سازگاری کد برپا می‌ماند یا فرومی‌ریزد، بنابراین اینجا جایی است که تلاش واقعی صرف می‌شود. اپلیکیشن‌های قدیمی معمولاً از توابع حذف‌شده mysql_* استفاده می‌کنند، به توابعی که در PHP 7 و 8 حذف یا تغییر یافته‌اند تکیه دارند، juggling نوعِ سست را فرض می‌کنند که PHP 8 سخت‌تر کرده، یا به افزونه‌هایی وابسته‌اند که دیگر همراه عرضه نمی‌شوند. اجرای اپلیکیشن روی یک کپی staging از runtime جدید این مسائل را به‌جای غافلگیری‌ در تولید، به‌عنوان خطاهای ملموس نمایان می‌کند. آن‌ها را روشمند اصلاح می‌کنید — mysql_* را با mysqli یا PDO عوض کنید، توابع حذف‌شده را جایگزین کنید، هشدارها را رسیدگی کنید — و دوباره آزمایش می‌کنید تا مسیرهای بحرانی تمیز شوند. تنها آنگاه زنده شدن به یک گام روتین تبدیل می‌شود نه یک جهش ایمانی.

مهاجرت دیتابیس بدون خراب کردن داده شما

جابه‌جایی داده جایی است که اگر عجله کنید آسیب بی‌صدا رخ می‌دهد. رایج‌ترین دام، encoding کاراکتر است: بسیاری از دیتابیس‌های قدیمی latin1 یا یک ترکیب‌اند، و import آن‌ها به یک هدف utf8mb4 بدون دقت، کاراکترهای ترکی و دیگر متن‌های غیر ASCII را به mojibake تبدیل می‌کند که بازگرداندنش بعداً دردناک است. مسیر ایمن این است که به MySQL مدیریت‌شده import کنید، به‌صراحت مجموعه‌کاراکتر و collation منبع را مطابقت دهید، و نمونه‌ای از رکوردهای واقعی — به‌ویژه هر چیزی با متن مصوت‌دار یا غیرلاتین — را پیش از اعتماد به نتیجه راستی‌آزمایی کنید. چرخه کامل خواندن/نوشتن را روی staging راستی‌آزمایی می‌کنید تا هنگام جابه‌جایی، دیتابیس یک کپی سالمِ شناخته‌شده باشد، نه یک کپی امیدوارانه.

staging و rollback: هرگز با ترافیک زنده قمار نکنید

انضباطی که یک مهاجرت قدیمی را ایمن می‌کند این است که تولید تا وقتی محیط جدید خود را اثبات کند دست‌نخورده در حال اجرا می‌ماند. همه چیز را روی staging می‌سازید و آزمایش می‌کنید، و میزبان قدیمی را زنده و در حال ارائه نگه می‌دارید تا پس از جابه‌جایی. پایین آوردن TTL از نوع DNS از پیش یعنی جابه‌جایی به edge — و جابه‌جایی به عقب، در صورت نیاز — دقیقه‌ها طول می‌کشد نه ساعت‌ها. اگر چیزی زیر ترافیک واقعی خراب شد که staging آشکار نکرده بود، DNS را به میزبان قدیمی برمی‌گردانید، مشکل را روی staging اصلاح می‌کنید و دوباره تلاش می‌کنید. چون هیچ چیز درباره محیط قدیمی در حین جابه‌جایی نابود نشد، rollback یک گزینه واقعی است نه یک بلوف.

اختیاری: deploy های آینده را با GitHub استاندارد کنید

پس از اینکه اپلیکیشن روی پلتفرم بود، می‌توانید مخزن آن را از طریق GitHub Deploy متصل کنید تا تغییرات آینده از یک خط تولید تکرارپذیر بیرون بروند — گام‌های Composer install، build و migration که یک‌بار تعریف و هر بار به همان روش اجرا می‌شوند. این مهاجرت یک‌باره را به یک جریان deploy پیوسته و کنترل‌شده تبدیل می‌کند، که اغلب لحظه‌ای است که یک اپلیکیشن مدت‌ها رهاشده سرانجام یک فرآیند انتشار قابل‌نگهداری می‌گیرد. اختیاری است، اما جایی است که یک مهاجرت نجات به مدرن‌سازی واقعی تبدیل می‌شود نه صرفاً یک تغییر نشانی.

راه‌اندازی گام‌به‌گام

1

اپلیکیشن را فهرست‌برداری و یک runtime هدف انتخاب کنید

نسخه PHP، افزونه‌ها، cron job ها و مسیرهای فایلی را که اپلیکیشن به آن‌ها وابسته است کاتالوگ کنید، سپس یک اپلیکیشن PHP Platform با هدف یک runtime پشتیبانی‌شده PHP 8 بسازید. هر چیزی را که از توابع حذف‌شده یا افزونه‌های قدیمی MySQL استفاده می‌کند یادداشت کنید تا پیش از دست زدن به تولید بدانید چه تغییرات کدی در راه است.

2

یک نسخه staging برپا کنید

کد را به‌عنوان یک محیط staging روی پلتفرم deploy و یک کپی از دیتابیس را import کنید، تا بتوانید اپلیکیشن را روی runtime جدید بدون هیچ ترافیک زنده تمرین دهید. کد را یا از طریق GitHub Deploy یا file manager push کنید، و این محیط را تا اثبات مهاجرت نگه دارید.

3

دیتابیس را به MySQL مدیریت‌شده مهاجرت دهید

یک دیتابیس مدیریت‌شده بسازید، dump خود را import کنید، و تأیید کنید که مجموعه‌کاراکتر و collation با نسخه اصلی مطابقت دارند (اپلیکیشن‌های قدیمی اغلب latin1 یا یک encoding مخلوط‌اند). اپلیکیشن را با اعتبارنامه‌های ارائه‌شده توسط پلتفرم به DB مدیریت‌شده اشاره دهید نه اینکه آن‌ها را hardcode کنید، و خواندن و نوشتن را روی staging راستی‌آزمایی کنید.

4

سازگاری را اصلاح و دوباره روی staging آزمایش کنید

مسائل PHP 8 نمایان‌شده در staging را حل کنید — توابع منسوخ، تبدیل mysql_* به mysqli/PDO، رسیدگی سخت‌گیرانه‌تر type — تا اپلیکیشن تمیز اجرا شود. مسیرهای بحرانی (ورود، فرم‌ها، admin، پرداخت‌ها) را به‌صورت سرتاسری روی URL از نوع staging آزمایش کنید پیش از آنکه کسی درباره زنده شدن صحبت کند.

5

دامنه، Auto SSL و WAF را متصل کنید

دامنه را روی حساب CDN بیاورید، بگذارید Auto SSL گواهی را آماده کند، و WAF را فعال کنید تا کد قدیمی همان لحظه‌ای که با اینترنت عمومی روبه‌رو می‌شود سپر شود. origin را تنها از طریق edge در دسترس نگه دارید تا سرور اپلیکیشن هرگز مستقیماً در معرض دید نباشد.

6

DNS را با یک rollback آماده جابه‌جا کنید

DNS را در یک بازه آرام با یک TTL پایین که از پیش تنظیم شده به edge جابه‌جا کنید، تا اگر مشکلی ظاهر شد بتوانید سریع برگردید. میزبان قدیمی را در حال اجرا و دست‌نخورده نگه دارید تا محیط جدید خود را زیر ترافیک واقعی اثبات کند، سپس آن را از کار بیندازید.

نمونه سناریوها

انجمن یا پرتال جامعه قدیمی

یک انجمن دیرپا روی PHP پایان‌عمر به PHP 8 و MySQL مدیریت‌شده منتقل می‌شود، با بخش‌های بایگانی پُرخوانش که در edge کش می‌شوند و WAF که سوءاستفاده بات را کند می‌کند.

CMS سفارشی که کسی نمی‌خواهد بازنویسی کند

یک CMS اختصاصی PHP پس از اصلاحات سازگاری همان‌طور که هست روی runtime مدرن بالا برده می‌شود، و سال‌ها عملیات ایمن را بدون یک بازنویسی کامل می‌خرد.

اپلیکیشن کاری داخلی روی یک سرور در حال مرگ

یک ابزار PHP کسب‌وکاری که روی یک جعبه فرسوده واحد اجرا می‌شود به runtime و دیتابیس مدیریت‌شده مهاجرت می‌کند و نقطه شکست واحدی را که همه را نگران نگه می‌داشت حذف می‌کند.

پرسش‌های پرتکرار

اپلیکیشن من از توابع قدیمی mysql_* استفاده می‌کند. آیا روی PHP 8 اجرا می‌شود؟

نه همان‌طور که هست — آن توابع سال‌ها پیش حذف شدند. مهاجرت شامل جایگزینی آن‌ها با mysqli یا PDO است، که دقیقاً همان نوع مسئله‌ای است که staging به‌عنوان خطاهای روشن نمایان می‌کند تا بتوانید پیش از زنده شدن اصلاحش کنید نه اینکه در تولید کشفش کنید.

چگونه از درهم‌ریختن کاراکترهای ترکی در حین جابه‌جایی DB پرهیز کنم؟

هنگام import به MySQL مدیریت‌شده، مجموعه‌کاراکتر و collation منبع را به‌صراحت مطابقت دهید، و رکوردهای نمونه حاوی متن مصوت‌دار یا غیرلاتین را روی staging راستی‌آزمایی کنید. ناسازگاری‌های encoding رایج‌ترین شکست بی‌صدا در مهاجرت‌های قدیمی است، بنابراین آن را پیش از جابه‌جایی راستی‌آزمایی می‌کنید نه پس از آن.

آیا می‌توانم همه چیز را پیش از دست زدن به سایت زنده آزمایش کنم؟

بله، این هسته این رویکرد است. یک نسخه کامل staging را روی runtime جدید با یک کپی از دیتابیس اجرا می‌کنید، مسیرهای بحرانی را اثبات می‌کنید، و تنها آنگاه DNS را جابه‌جا می‌کنید. تولید تمام مدت روی میزبان قدیمی در حال اجرا می‌ماند.

اگر چیزی درست پس از جابه‌جایی خراب شود چه؟

DNS را به میزبان قدیمی که هنوز در حال اجرا و دست‌نخورده است برمی‌گردانید، سپس مشکل را روی staging اصلاح و دوباره تلاش می‌کنید. تنظیم یک TTL پایین از نوع DNS پیش از جابه‌جایی، آن rollback را در حد دقیقه‌ها نگه می‌دارد.

آیا باید همه کدم را یک‌باره ارتقا دهم؟

به‌اندازه کافی کار سازگاری نیاز دارید که اپلیکیشن روی runtime هدف PHP 8 تمیز اجرا شود، اما لازم نیست اپلیکیشن را بازنویسی کنید. بسیاری از اپلیکیشن‌های قدیمی با یک مجموعه متمرکز از اصلاحات جابه‌جا می‌شوند؛ یک refactor بزرگ‌تر می‌تواند بعداً پس از آنکه اپلیکیشن ایمن روی پلتفرم بود انجام شود.

آیا کد قدیمی من پس از قرار گرفتن دوباره در معرض اینترنت ایمن است؟

WAF در edge و Auto SSL جلوی اپلیکیشن قرار می‌گیرند و پیش از رسیدن درخواست‌ها به origin، ترافیک رایج حمله را فیلتر و HTTPS را اجرا می‌کنند. در ترکیب با در دسترس نگه داشتن سرور اپلیکیشن تنها از طریق edge، این به کد قدیمی محافظتی می‌دهد که هرگز روی میزبان قدیمی خود نداشت.