بیشتر مهاجرتها حین کپیکردن شکست نمیخورند. آنها در همان بیست دقیقهٔ بعد از تغییر DNS شکست میخورند، وقتی نیمی از اینترنت هنوز با سرور قدیمی حرف میزند و نیمهٔ دیگر رفته سراغ سرور جدید — و هر دو ماشین دارند نوشتن را میپذیرند. فایلها سالم رسیدهاند، سایت بالا میآید، و بااینحال سفارشها دارند در دو پایگاهداده مینشینند که هرگز با هم تطبیق داده نمیشوند. پرهیز از این اتفاق تقریباً هیچ ربطی به سرعت انتقال ندارد و تقریباً همهچیزش به ترتیب برمیگردد: چهچیزی را اول تغییر میدهید، چهچیزی را متوقف میکنید، و چهچیزی را تا وقتی مطمئن شوید همچنان در حال اجرا نگه میدارید.
"بدون قطعی" واقعاً یعنی چه
ارزشش را دارد که دقیق باشیم، چون این عبارت دو وعدهٔ کاملاً متفاوت را پوشش میدهد که هزینهٔ تلاش بسیار متفاوتی هم دارند. تصمیمگرفتن دربارهٔ اینکه کدامیک را میخرید، اولین تصمیم واقعی مهاجرت است.
اگر مجبورید از یکی بگذرید، از دردسترسبودن بگذرید. یک صفحهٔ نگهداری برای چهار دقیقه چیزی است که میتوانید توضیحش دهید. دادههای واگرا چیزی است که نمیتوانید درستش کنید، چون دیگر هیچ مرجعی نمانده که بگوید کدام کپی درست بوده.
پیش از شروع، طولانیترین توقف نوشتنی که میتوانید تحمل کنید را بنویسید. چهار دقیقه، سی ثانیه، صفر. همین یک عدد همهچیز را در ادامهٔ کار تعیین میکند — اینکه یک دامپ و بازیابی کافی است، اینکه به ریپلیکیشن نیاز دارید، یا اینکه به یک پراکسی جلوی کل ماجرا نیاز دارید. انتخاب ابزار پیش از انتخاب این عدد، دقیقاً همانجایی است که مهاجرتها غافلگیریهایشان را کسب میکنند.
پیش از گرفتن کپی، فهرستبرداری کنید
یک سرور چیزهایی را جمع میکند که هیچکس مستندشان نکرده: یک کار cron که وسط یک حادثه اضافه شده، یک قاعدهٔ فایروال برای آدرس یک پارتنر، یک کلید API که داخل یک فایل سرویس پیست شده. کپی اینها را با خودش نمیبرد، و شما یکییکی طی دو هفتهٔ بعد پیدایشان میکنید. نیمساعت فهرستبرداری همین حالا، تقریباً همهٔ اینها را از سر راه برمیدارد.
چه چیزی گوش میدهد
ss -tulpn را اجرا کنید و حساب هر سوکت در حال گوشدادن را داشته باشید. هرکدام یک سرویس است که باید روی دستگاهٔ جدید هم وجود داشته باشد، و هر پورت بیتوضیح، پیش از آنکه بازتولیدش کنید، ارزش فهمیدن دارد — مهاجرت لحظهٔ خوبی است برای متوجهشدن اینکه چه چیزی از سال 2023 در حال اجراست.
چه چیزی روی تایمر اجرا میشود
crontab -l برای هر کاربر ازجمله root، systemctl list-timers، و هر زمانبند دیگری که داخل خود اپلیکیشن است. تایمرها رایجترین چیزیاند که از یک مهاجرت بهصورت تکراری جان سالم به در میبرند، و تکراریبودن بدتر از نبودن است.
چه چیزی روی دیسک نیست
رکوردهای DNS، رکورد DNS معکوس روی آدرستان، قواعد فایروال، کلیدهای API که در دست اشخاص ثالث است، مقصدهای webhook، و هر فهرست مجازی در جای دیگر که IP فعلیتان را نام برده. هیچکدام از اینها در همان فایلسیستمی زندگی نمیکنند که قرار است کپی کنید.
اپلیکیشن چه چیزی را مسلم فرض میکند
مسیرهای مطلق hard-code شده، یک hostname داخل یک فایل کانفیگ، محل یک سوکت پایگاهداده، یک آدرس داخل یک دستور bind. اینها چیزهاییاند که بیسروصدا میشکنند — سرویس استارت میشود، و بعد کار نمیکند.
آن را در فایلی بنویسید که در version control نگه میدارید، نه در اسکرولبک ترمینال. در طول سوییچ سه بار میخوانیدش، یکبارش هم در لحظهای که ذهنتان درست کار نمیکند.
مقصد را بر اساس چیزهایی انتخاب کنید که بعداً نمیتوانید تغییرشان دهید
مشخصات فنی قابلتنظیماند؛ چند ویژگی اینطور نیستند، و همانها ارزش تصمیمگیری آگاهانه دارند، وقتی هنوز انتخاب آزاد دارید. از آنجا که دارید بههرحال جابهجا میشوید، این ارزانترین لحظهای است که تا بهحال برای رفع محدودیتی که دورش کار میکردید گیر میآورید.
- موقعیت مکانی، چون هم تأخیر تا کاربرهایتان و هم قانون قابلاجرا، هر دو با آن ثابت میشوند. /locations مناطق و ویژگیهای round-trip آنها را فهرست کرده؛ منطقهای انتخاب کنید که مستقل از هر جایی که دارید ترکش میکنید از کار بیفتد.
- پایگاه حقوقی، اگر دلیل جابهجایی این است که ارائهدهندهٔ فعلیتان شکایتها را سریعتر از پکتها فوروارد میکند. /offshore-hosting مشخص میکند حوزهٔ قضایی واقعاً چه چیزی را کنترل میکند و چه چیزی را نه.
- هویت صورتحساب، چون میزبانی که پیش از پذیرفتن پرداخت مدرک میخواهد، ذاتاً یک پرونده از شما دارد. /no-kyc-vps و /pay-with جایگزین را توصیف میکنند — موجودیای که با رمزارز شارژ شده، بدون کارت، بدون هیچ نامی که به ماشین وصل باشد.
- فضای رشد، چون دوبار مهاجرتکردن نتیجهای است که هیچکس برایش برنامه نمیریزد. /vps سطوح مختلف را فهرست کرده، و /guides روش اندازهگیری را دارد، اگر دستگاهٔ فعلی هیچوقت واقعاً اندازهگیری نشده.
- IPv6 و یک IPv4 تمیز، چون یک آدرس بازیافتی میتواند با اعتبار (reputation) شخص دیگری وارد شود — پیش از آنکه به یک مشکل ایمیلی تبدیل شود، بررسیاش کنید.
اول TTL را پایین بیاورید، روزها قبل
این تنها گام آمادهسازیای است که نمیشود آخر کار با عجله انجامش داد، چون اثرش را ساعتی کنترل میکند که دست شما نیست. TTL روی رکوردهایتان به resolverها میگوید یک پاسخ را چهمدت کش کنند. اگر روی یک روز تنظیم شده باشد، یک resolver که یک ساعت پیش پرسیده، تا بیستوسه ساعت بعد کاربرها را به سرور قدیمی میفرستد، مهم نیست چه چیزی را منتشر کنید.
- 1
TTL فعلی را بخوانید
dig +noall +answer yourdomain.com زمان باقیمانده از کش را نشان میدهد؛ کوئریگرفتن مستقیم از nameserver مرجعتان با dig @ns1.example.net yourdomain.com مقدار پیکربندیشده را نشان میدهد. آن را یادداشت کنید — همین عدد طول دورهٔ انتظارتان را تعیین میکند.
- 2
آن را به 300 ثانیه برسانید
TTL را روی هر رکوردی که قرار است تغییر کند پایین بیاورید: A، AAAA، و هر MX یا CNAME که به میزبان اشاره میکند. پنج دقیقه بهاندازهٔ کافی کوتاه است که سوییچ را راحت کند و بهاندازهٔ کافی بلند است که nameserverهایتان را زیر فشار نگذارد.
- 3
صبر کنید تا TTL قدیمی تمام شود، بعد دوباره صبر کنید
TTL کوتاه جدید فقط بعد از تمامشدن TTL بلند قدیمی به resolver میرسد. پیش از آنکه TTL پایین را واقعی در نظر بگیرید، دستکم بهاندازهٔ یک دورهٔ کامل از TTL قدیمی صبر کنید — یک روز، اگر یک روز بوده. زود شروعکردن این کار هیچ هزینهای ندارد و برای کل سوییچ حاشیهٔ امن میخرد.
بعضی resolverها به TTL شما بیتوجهی میکنند و بههرحال با حداقل زمان خودشان کش میکنند، و بخشی از کلاینتها هم برای کل طول عمر پردازه کش میکنند. برای یک دنبالهٔ بلند از ترافیک که ساعتها بعد از یک سوییچ کاملاً کتابی هم به آدرس قدیمی میخورد، برنامهریزی کنید. این دلیلی برای ردکردن کار TTL نیست — دقیقاً همین دلیلی است که سرور قدیمی باید بعدش هم زنده بماند.
سرور جدید را بسازید، سرور قدیمی را کلون نکنید
غریزهٔ اول این است که از دیسک فعلی ایمیج بگیرید و جای دیگری بازیابیاش کنید. این حرکت اشتباهی است، دقیقاً به همان دلیلی که در یک بازیابی هم اشتباه است: یک کلون در سطح بلوک، انحراف کانفیگ، پکیجهای یتیم، سرویس نیمهپیکربندیشدهای که یک نفر رهایش کرده، و هر چیزی که یک نفوذگر قبلی برای ماندن در سیستم جا گذاشته را وفادارانه بازتولید میکند. این کار همچنین شما را به نسخهٔ قدیمی distribution میخکوب میکند.
ماشین جدید را از یک ایمیج پایهٔ بهروز بسازید، سرویسها را از یک اسکریپت نصب کنید، و فقط داده را کپی کنید. اسکریپت همان خروجی واقعی کار است — همین است که مهاجرت بعدی را از دو هفته به یک بعدازظهر تبدیل میکند، و همین است که به شما اجازه میدهد بعد از یک حادثه، بدون باستانشناسی، از نو بسازید.
- پیش از آنکه هر چیز دیگری به آن دست بزند، راهاندازی، بهروزرسانی و سختسازی کنید: SSH فقط با کلید، فایروال default-deny، و بهروزرسانیهای امنیتی خودکار. /guides نسخهٔ یکساعتهٔ آن چکلیست را دارد.
- همان نسخههای اصلی runtime و پایگاهدادهای که در پروداکشن است را نصب کنید. مهاجرت زمان بدی است برای اینکه همزمان PostgreSQL 14 را هم به 17 ارتقا دهید — هر بار فقط یک تغییر بدهید تا هر شکستی دقیقاً یک توضیح داشته باشد.
- پیش از کپیکردن فایلها، کاربرها و گروهها را با همان شناسههای عددی دوباره بسازید، یا بعداً ownership را دستی درست کنید. انتقال با --numeric-ids همان اعداد را دستنخورده نگه میدارد؛ نگاشتشان به نامهای درست، کار شماست.
- آدرس جدید را در هر فهرست مجازی که الان آدرس قدیمی را نام برده وارد کنید — APIهای پارتنر، فایروالهای پایگاهدادهٔ مدیریتشده، درگاههای پرداخت، مانیتورینگ خودتان — درحالیکه هر دو هنوز معتبرند.
سرویسها را نصب کنید، بعد متوقف و غیرفعالشان کنید. یک وبسرور که موقع بوت استارت میشود و روی آدرس جدید پاسخ میدهد، توسط اسکنرها پیدا میشود، زیر hostname اشتباه ایندکس میشود، و — بدتر از آن — با کمال میل یک کپی نیمهپر از سایتتان را به هر کسی که زود resolve کند تحویل میدهد. هیچچیز روی دستگاهٔ جدید نباید بهصورت عمومی پاسخ بدهد، تا وقتی خودتان تصمیم بگیرید که بدهد.
فایلها را در دو دور کپی کنید
یک انتقال تکی از یک فایلسیستم زنده، فقط یک اسنپشات از یک هدف متحرک است. دو دور این را تمیز حل میکند: دور اول طولانی است و روی یک سیستم زنده اجرا میشود، دور دوم کوتاه است و در طول توقف نوشتن اجرا میشود، و فقط همان دور دوم لازم است سریع باشد.
دور اول را هر وقت خواستید اجرا کنید — چند روز زودتر هم اشکالی ندارد. این دور بار اصلی را میبرد: دایرکتوری آپلودها، mail spool، ولومهای کانتینر، سالها مدیای انباشتهشده. تا زمانی که سوییچ کنید، این کپی کهنه شده، و دقیقاً به همین دلیل دور دوم وجود دارد.
- از rsync -aAXH --numeric-ids --info=progress2 روی SSH استفاده کنید: -a برای ویژگیهای معمول، -A برای ACLها، -X برای ویژگیهای extended، -H برای hard linkها، که اگر چیزی روی دستگاه دادههای تکراری را حذف میکند اهمیت دارند.
- چیزی که نباید جابهجا شود را exclude کنید: /proc، /sys، /dev، /run، دایرکتوریهای موقت، کش پکیج و لاگهایی که نیازشان ندارید. کپیکردن واسطهای کرنل، در بهترین حالت وقت تلف میکند و در بدترین حالت کل انتقال را هنگ میکند.
- --delete را فقط روی دور دوم اضافه کنید. روی دور اول بیضرر است؛ روی دور دوم فایلهایی را حذف میکند که از آن زمان روی مبدأ حذف شدهاند، که دقیقاً همان انحرافی است که میخواهید از بین ببرید.
- کانفیگ سیستم را گزینشی کپی کنید، نه یکجا و کامل. چیزی که میخواهید vhostهای وبسرورتان، service unitهایتان و کانفیگ اپلیکیشنتان است — نه جدول فایلسیستم ماشین قدیمی، کانفیگ شبکهاش یا machine IDاش.
- یک کلید SSH یکبارمصرف برای انتقال بسازید، روی مقصد مجازش کنید، و وقتی مهاجرت تمام شد حذفش کنید. کلید مهاجرتی که دو سال باقی میماند، اعتبارنامهای است که هیچکس یادش نمیآید صادرش کرده.
میان دو دور، بهجای فرضکردن، تأیید کنید. اجرای دور دوم با --dry-run دقیقاً چاپ میکند چه چیزی را تغییر میدهد: فهرستی از چند صد فایل اخیر سالم است، و فهرستی از چهل هزار فایل یعنی یک exclude اشتباه است یا چیزی بیدلیل دارد timestampها را بازمینویسد.
پایگاهداده را بدون ازدستدادن نوشتنها جابهجا کنید
اینجا همانجایی است که بودجهٔ توقف نوشتن خرج میشود، و تکنیک درست کاملاً با همان عددی تعیین میشود که اول کار نوشتید. هر سه گزینهٔ زیر درستاند — برای عددهای متفاوت.
هرچه انتخاب کنید، پایگاهدادهٔ قدیمی باید پیش از آنکه جدیدی شروع کند، از پذیرفتن نوشتن دست بکشد. نه کمی بعدش — پیش از آن. همپوشانیای که هر دو در آن قابلنوشتناند، همان دورهٔ اسپلیتبرین است، و تنها شکستی است در کل این راهنما که هیچ بازیابی تمیزی ندارد: دو تاریخچهٔ واگرا و هیچ راهی برای ادغامشان که مستلزم خواندن ردیفها با دست نباشد.
وقتی دیتاست بزرگ است، schema و داده را جدا از هم دامپ بگیرید. بازیابی اول schema به شما اجازه میدهد ساختار، ایندکسها و دسترسیها را زود روی میزبان جدید تأیید کنید، که بارگذاری داده را به یک عملیات طولانی تکی تبدیل میکند که میتوانید در طول توقف نوشتن شروعش کنید، درحالیکه از قبل مطمئنید جا میافتد.
گواهی TLS را پیش از سوییچ صادر کنید، نه بعدش
گواهی روی سرور جدید باید همان لحظهای که اولین کاربر میرسد معتبر باشد. اگر جز این باشد، یعنی هر بازدیدکننده با یک صفحهٔ میانی مرورگر روبهرو میشود، و اگر هدرهای HSTS بفرستید — که باید بفرستید — نمیتوانند از آن رد شوند. دو راه هست برای در دست داشتن یک گواهی کارآمد، پیش از آنکه DNS به جای جدیدی اشاره کند.
- همان گواهی موجود را کپی کنید. کل دایرکتوری وضعیت ACME، یا فقط گواهی و کلید از هرجایی که کلاینتتان نگهشان میدارد. بلافاصله معتبر است، چون اعتبار هیچ ربطی به اینکه کدام سرور فایل را نگه داشته ندارد، و تمدید هم بهمحض جابهجاشدن DNS به روال عادی برمیگردد.
- یک گواهی تازه با یک چالش DNS-01 صادر کنید، که کنترل دامنه را با یک رکورد TXT ثابت میکند، نه با یک درخواست HTTP به آدرس فعلی. این روش پیش از مهاجرت، پیش از سوییچ، و برای wildcardها هم کار میکند، کاری که HTTP-01 اصلاً از پسش برنمیآید.
- پیش از سوییچ، سراغ اعتبارسنجی HTTP-01 روی سرور جدید نروید. چالش از روی پورت 80 روی نام دامنه گرفته میشود، دامنه هنوز به ماشین قدیمی resolve میشود، و اعتبارسنجی هر بار شکست میخورد.
بدون دستزدن به DNS، با resolve کردن hostname به آدرس جدید فقط برای یک دستور، آن را تأیید کنید: curl -sI --resolve yourdomain.com:443:198.51.100.10 https://yourdomain.com/ — با جایگزینکردن آدرس واقعی. همین یک خط، باارزشترین بررسی در کل این مهاجرت است. vhost واقعی، گواهی واقعی و کل استک اپلیکیشن واقعی را روی دستگاهٔ جدید بهکار میاندازد، و همینطور است که یک پیکربندی غلط را پیدا میکنید، درحالیکه پیداکردنش هنوز هیچ هزینهای ندارد.
اگر سرور ایمیل میفرستد، زودتر شروع کنید
ایمیل همان بخشی از یک مهاجرت است که روزها بعد، بیسروصدا شکست میخورد و تقصیرش گردن چیز دیگری میافتد. یک آدرس جدید هیچ اعتبار ارسالی ندارد و ممکن است اعتبار شخص دیگری را به ارث برده باشد، و هر رکورد احرازهویتی که منتشر میکنید به همان آدرسی گره خورده که دارید ترکش میکنید.
- پیش از آنکه رویش قطعی کنید، آدرس جدید را در برابر فهرستهای سیاه اصلی بررسی کنید. یک IP بازیافتی با پیشینه، وقتی هنوز عوضکردنش رایگان است، ارزش عوضشدن دارد.
- رکورد DNS معکوس روی آدرس جدید را روی hostname ایمیلتان تنظیم کنید. سرورهای گیرنده بررسی میکنند که resolve مستقیم و معکوس با هم جور دربیایند، و نبودِ یک PTR بهتنهایی کافی است که پیام spam دستهبندی شود.
- آدرس جدید را پیش از سوییچ به SPF اضافه کنید و آدرس قدیمی را بعدش حذف کنید — در طول همپوشانی هر دو فهرست شدهاند، تا ایمیل از هر سروری که واقعاً فرستاده، احرازهویت شود.
- بهجای ساختن کلیدهای خصوصی DKIM جدید، همانهای موجود را کپی کنید، تا selectorی که از قبل در DNS منتشر شده همچنان معتبر بماند. ساختن دوباره یعنی انتشار دوباره، و انتشار دوباره تأخیر انتشار خودش را دارد.
- اگر با حجم قابلتوجهی ایمیل میفرستید، آدرس جدید را بهتدریج گرم کنید. سروری که در کل عمرش هیچچیز نفرستاده و بعد یکمرتبه ده هزار پیام میفرستد، برای گیرنده، از یک میزبان بهخطرافتاده قابلتشخیص نیست.
سوییچ نهایی
همهٔ آنچه بالا آمد آمادهسازی بود تا همین بخش کوتاه، منظم و برگشتپذیر باشد. آن را در کمینهٔ واقعی ترافیکتان انجام دهید، نه ساعت سه بامداد از روی خرافات — آنالیتیکس خودتان را چک کنید. پیش از شروع، بازگشت را نوشته باشید، چون همان لحظهای که بهش نیاز دارید، دقیقاً همان لحظهای است که کمترین میل را به نوشتنش دارید.
- 1
نوشتنها را روی سرور قدیمی متوقف کنید
حالت نگهداری، یک کاربر پایگاهدادهٔ فقطخواندنی، یا یک خطا روی مسیرهای نوشتن در پراکسی معکوس. خواندنها در تمام این مدت همچنان از ماشین قدیمی سرویس داده میشوند — همین است که سایت را روشن نگه میدارد، درحالیکه داده دارد جابهجا میشود.
- 2
هر تایمری را روی سرور قدیمی غیرفعال کنید
crontabها را کامنت کنید، تایمرها را متوقف کنید، queue workerها را متوقف کنید. از همین لحظه، ماشین قدیمی نباید هیچچیزی را پردازش کند، وگرنه jobها دوبار اجرا میشوند: دو فاکتور، دو ایمیل، دو تحویل webhook.
- 3
دلتای نهایی را اجرا کنید
دور دوم فایلها با --delete، بعد دامپ نهایی پایگاهداده یا بهروزرساندن نهایی ریپلیکا. این همان دور کوتاه است، حداکثر چند دقیقه، چون دور اول از قبل حجم اصلی را جابهجا کرده.
- 4
سرور جدید را در برابر hostname واقعیاش تأیید کنید
با همان ترفند --resolve که بالا آمد، یک صفحهای که از پایگاهداده میخواند، یک لاگین، و یک مسیر نوشتن را امتحان کنید. مطمئن شوید تعداد ردیفها با مبدأ جور دربیاید. همهٔ اینها را پیش از تغییر DNS انجام دهید، درحالیکه برگشتن هنوز اصلاً هیچ هزینهای ندارد.
- 5
DNS را سوییچ کنید و سرویسها را استارت کنید
A و AAAA را به آدرس جدید بهروزرسانی کنید، بعد اپلیکیشن و تایمرهایش را روی سرور جدید فعال و استارت کنید. ترافیک ظرف یک TTL شروع به رسیدن میکند و طی یک ساعت بعدی همچنان در حال جابهجایی است.
- 6
بگذارید سرور قدیمی همچنان خواندنها را سرویس دهد
دستکم برای بیستوچهار ساعت، روشن و فقطخواندنی نگهش دارید. کلاینتهایی که کش کهنه دارند همچنان رویش فرود میآیند، و یک سرور قدیمی فقطخواندنی، بهجای یک اتصال ردشده، صفحاتی کمی کهنه برمیگرداند — تفاوت میان یک مهاجرت نامرئی و یک مهاجرت مرئی.
همین همپوشانی جایی است که تمیزترین ترفند هم زندگی میکند. بهجای یک سوییچ سخت DNS، سرور قدیمی را در پایان گام پنجم بهعنوان یک پراکسی معکوس بهسمت سرور جدید پیکربندی مجدد کنید. هر بازماندهای که هنوز به آدرس قدیمی resolve میشود، شفاف فوروارد میشود، سوییچ کاملاً از وابستگی به انتشار DNS بیرون میآید، و هروقت ترافیک بهسمت آن پراکسی به صفر رسید، جمعش میکنید. X-Forwarded-For را پاس بدهید تا لاگها و rate limitتان همچنان آدرسهای واقعی کلاینت را ببینند.
48 ساعت اول
مهاجرت وقتی سایت بالا میآید تمام نمیشود. وقتی تمام میشود که دیگر هیچچیز به ماشین قدیمی وابسته نباشد، و پیداکردن آن وابستگیها یک تمرین فعال است، نه یک بازی صبرکردن.
- لاگ دسترسی سرور قدیمی را زیر نظر بگیرید. هر درخواستی که هنوز آنجا میرسد یک وابستگی مهاجرتنشده است — یک آدرس hard-code شده در یکپارچهسازی یک پارتنر، یک کلاینت موبایل با کش کهنه، یک پراب مانیتورینگ که هیچکس مالکش نیست. این لاگ همان فهرست کارهاست.
- مطمئن شوید تایمرها واقعاً روی میزبان جدید اجرا شدهاند. نه اینکه فعالاند — اینکه اجرا شدهاند، در زمان موردانتظار، با خروجی موردانتظار. یک کار cron که بیسروصدا هیچ کاری نمیکند، دقیقاً شبیه یک کار cron است که درست کار میکند.
- تمدید گواهی را واقعاً با یک dry run تست کنید، بهجای آنکه شصت روز بعد کشف کنید کلاینت ACMEتان داشته در برابر سروری تمدید میکرده که دیگر چالش را دریافت نمیکند.
- جریان ایمیل را سر تا سر و در هر دو جهت بررسی کنید، ازجمله هرچیزی که اپلیکیشن خودکار میفرستد. بازنشانی رمز عبور همان قربانی کلاسیک است، چون تا وقتی یک کاربر واقعاً به آن نیاز پیدا نکند، هیچکس تستش نمیکند.
- از سرور جدید یک بکاپ بگیرید و جایی بازیابیاش کنید. یک ماشین تازه بدون بکاپ تأییدشده، وضعیتی بدتر از همان جایی است که ترک کردهاید؛ /guides نسخهٔ کامل این استدلال را دارد.
- بهمحض آنکه مطمئن شدید، TTL را به مقدار عادیاش برگردانید. برای همیشه رویش روی 300 ثانیه گذاشتن، یک هزینهٔ دائمی کوچک در کوئری و تأخیر است، بدون هیچ فایدهٔ باقیماندهای.
از رده خارجکردن سرور قدیمی
آخرین گام همان گامی است که جا میافتد، و تنها گامی است که پیامد حریمخصوصی دارد. دیسک قدیمی کلیدهایتان، پایگاهدادهتان، دادههای مشتریهایتان و لاگهایتان را نگه داشته، و لغو سرویس هیچکدام از آنها را پاک نمیکند — فقط ولوم را به یک استخر برمیگرداند، جایی که مستأجر بعدی هرچه را که سیاست wipe ارائهدهنده باقی گذاشته تحویل میگیرد.
- پیش از آنکه دست به هرچیزی بزنید، صبر کنید تا لاگ دسترسی قدیمی ساکت شود. لغوکردن درحالیکه یک ارائهدهندهٔ پرداخت هنوز دارد webhookهایش را به آدرس قدیمی میفرستد، دقیقاً همینطور است که یک مهاجرت یک هفته بعد به یک حادثه تبدیل میشود.
- بهجای صرفاً حذفکردن، rotate کنید: هر اعتبارنامهای که سرور قدیمی نگه داشته — کلیدهای API، رمزهای عبور پایگاهداده، کلیدهای deploy، کلید موقت مهاجرت. فرض کنید هرچیزی که روی ماشینی زندگی کرده که دیگر کنترلش را ندارید بهخطرافتاده، چون دیر یا زود واقعاً همینطور میشود.
- پیش از رهاکردن ولوم، داده را overwrite کنید. دایرکتوریهای حساس را shred کنید، یا فضای آزاد را با یک فایل تصادفی بزرگ پر کنید و بعد حذفش کنید. روی یک دیسک مجازیسازیشده ناقص است، اما بهمراتب بهتر از هیچچیز است.
- از هرچیزی که ممکن است بعداً برای رجوع لازمتان شود یک آرشیو نهایی بگیرید — لاگها، کانفیگ، تاریخچهٔ شلی که مستند میکند واقعاً چه کاری انجام شده — و آن را رمزنگاریشده جایی نگه دارید که هیچکدام از دو سرور نباشد.
- سرویس را فقط بعد از آنکه سرور جدید یک چرخهٔ کامل صورتحساب و یک تست کامل بکاپوبازیابی را پشت سر گذاشت، لغو کنید. همان یک ماه همپوشانی، ارزانترین بیمهٔ کل این فرآیند است.
یک جدول زمانی که میتوانید کپی کنید
هیچکدام از اینها بهتنهایی سخت نیست. دلیل اینکه مهاجرتها بد پیش میروند این است که گامها در یک عصر واحد فشرده میشوند، جایی که TTL هنوز تمام نشده، گواهی هنوز تست نشده و بازگشت هنوز نوشته نشده. وقتی روی یک هفته پخش شود، هر روز فقط بیست دقیقه کار است.
مهاجرتها واقعاً کجا خراب میشوند
نه از راه کپیکردن. از راه چیزهایی که هرگز روی دیسک نبودند، و چیزهایی که دوبار اجرا شدند.
- هر دو سرور همزمان در حال نوشتن — دورهٔ اسپلیتبرین، همان تنها شکستی که اینجا هیچ رفع تمیزی ندارد. جلویش با ترتیب گرفته میشود، نه با ابزار: اول قدیمی را متوقف کنید، بعد جدیدی را استارت کنید.
- تایمرهایی که روی هر دو ماشین در حال اجرا هستند، که دقیقاً همینطور است که مشتریها از هرچیزی دوتا دریافت میکنند. قدیمیها را پیش از همگامسازی نهایی غیرفعال کنید، نه بعدش.
- یک TTL که هرگز پایین آورده نشده، که یک سوییچ پنجدقیقهای را به یک دنبالهٔ یکروزه تبدیل میکند که هیچکس برایش نیرو در نظر نگرفته بود.
- ownership فایلها غلط مینشیند چون شناسههای عددی میان دو ماشین فرق دارند، پس اپلیکیشن استارت میشود و بعد نمیتواند در دایرکتوری آپلود خودش بنویسد.
- یک گواهی که قرار بوده بعد از سوییچ حلوفصل شود، به یک هدر HSTS برمیخورد که هیچ راهی برای ادامهدادن جلوی بازدیدکنندهها نمیگذارد.
- یک آدرس hard-code شده جایی که کنترلش دست شما نیست — یک یکپارچهسازی پارتنر، یک قاعدهٔ فایروال، یک رکورد DNS برای زیردامنهای که یادتان رفته بود اصلاً وجود دارد.
- لغوکردن سرور قدیمی درست در روز جابهجایی، که دقیقاً همان لحظهای مسیر بازگشت را حذف میکند که آمار میگوید بیشترین احتمال را دارید که بهش نیاز پیدا کنید.
مهاجرت یک VPS چقدر طول میکشد؟
این کار معمولاً چند ساعت است که روی یک هفته پخش شده، و بخشی که کاربر میبیند فقط چند دقیقه است. انتقال حجم اصلی و کاهش TTL روزها زودتر اتفاق میافتند درحالیکه همهچیز زنده میماند؛ خود سوییچ فقط یک همگامسازی دلتای نهایی، یک تغییر DNS و یک پاس تأیید است. سایتی با چند گیگابایت داده و یک پایگاهدادهٔ متوسط، بهراحتی یک سوییچ سیدقیقهای است، با توقف نوشتنی که در حد چند دقیقهٔ تکرقمی اندازهگیری میشود.
آیا میتوانم اصلاً بدون هیچ قطعیای مهاجرت کنم؟
برای خواندنها بله — سرور قدیمی تا وقتی DNS جابهجا شود همچنان پاسخ میدهد، و تبدیلکردنش به یک پراکسی معکوس بعد از آن، حتی دنبالهٔ انتشار را هم حذف میکند. نوشتنها مورد سختتریاند: یک توقف کوتاه، تا امروز، سادهترین راه برای تضمین این است که چیزی از دست نرود، و ریپلیکیشن آن توقف را به چند ثانیه کوتاه میکند. یک توقف نوشتنِ واقعاً صفر روی نوشتنها، نیاز دارد که اپلیکیشن در طول همپوشانی روی هر دو پایگاهداده بنویسد، که دستیافتنی است اما یک حالت شکست اضافه میکند که بیشتر سایتها نیازش ندارند.
باید دیسک را کلون کنم یا سرور را از نو بسازم؟
از نو بسازید. یک کلون، انحراف کانفیگ، پکیجهای یتیم و هر چیزی که یک نفوذ قبلی برای ماندن جا گذاشته را با خودش میبرد، و شما را به نسخهٔ قدیمی distribution میخکوب میکند. نصب از روی یک اسکریپت و کپیکردن فقط داده، یک ماشین تمیز بهعلاوهٔ یک دستورالعمل تکرارپذیر به شما میدهد — که دقیقاً همان چیزی است که بازسازی بعدی را هم سریع میکند.
برای آدرس IP و رتبهٔ من در نتایج جستوجو چه اتفاقی میافتد؟
آدرس تغییر میکند؛ دامنه تغییر نمیکند، و لینکها، رتبهها و تاریخچه دنبال دامنه میروند. URLها را یکسان نگه دارید، سرور قدیمی را در طول همپوشانی همچنان پاسخگو نگه دارید تا هیچکدام از crawlerها هرگز یک خطای اتصال نبینند، و آنوقت این تغییر عملاً برای موتورهای جستوجو نامرئی است. جابهجایی میان کشورها میتواند معیارهای حساس به تأخیر را کمی تکان دهد، پس منطقهای نزدیک به مخاطب واقعیتان را در /locations انتخاب کنید.
چطور یک پایگاهداده را بدون ازدستدادن داده مهاجرت دهم؟
پیش از شروع نوشتن روی مقصد، نوشتن روی مبدأ را متوقف کنید — کل تضمین همین ترتیب است. برای دیتاستهای کوچک، توقف کنید، با pg_dump یا mysqldump --single-transaction دامپ بگیرید، بازیابی کنید و سوییچ کنید. برای دیتاستهای بزرگتر، از قبل ریپلیکیت کنید و هنگام سوییچ ریپلیکا را ارتقا دهید تا رسیدن به آخرین وضعیت فقط چند ثانیه طول بکشد. پیش از فرستادن هر ترافیکی، با مقایسهٔ تعداد ردیفها روی جدولهایی که اهمیت دارند تأیید کنید.
آیا میتوانم بدون افشای هویتم به یک میزبان آفشور مهاجرت کنم؟
بله. میزبانی که از یک موجودی رمزارزی صورتحساب میکشد، نه کارتی دارد و نه آدرس صورتحسابی که به ماشین وصل شود، پس حسابی که پشت سرور است هیچچیزی دربارهٔ شما نگه نمیدارد. خودِ مهاجرت از نظر فنی کاملاً یکسان است — همان دورهای فایل، همان دامپ، همان سوییچ DNS. /offshore-vps توضیح میدهد این مدل چطور کار میکند و /pay-with سمت پرداخت را پوشش میدهد.
چه زمانی لغو سرور قدیمی امن است؟
بعد از آنکه لاگ دسترسیاش دستکم یک روز ساکت مانده، هر اعتبارنامهای که نگه داشته rotate شده، و از سرور جدید یک بکاپ گرفتهاید و جایی با موفقیت بازیابیاش کردهاید. یک ماه اضافه از یک VPS کوچک، ارزانترین بیمهٔ این فرآیند است — تفاوت میان یک بازگشت و یک حادثه.
