مینیپیسی قدیمی اما وفادار Intel NUC من هنوز کاملاً کارآمد است، اما دیگر منطقی نبود یک رایانهٔ کامل را فقط برای اجرای دو کانتینر Docker کنار بگذارم. میخواستم دوباره آن را به سرور فایل تبدیل کنم، اما یک مشکل آزاردهنده سر راهم بود.
روی اوبونتوی این دستگاه، سامانهٔ پایش فعال n8n، سرویس ntfy، سابقهای مفصل از کارها و انبوهی از تنظیمات وجود داشت که نمیخواستم با تکیه بر حافظهام از نو بسازم.
بهجای آنکه برنامههای سرور را یکییکی از نو بسازم، با Clonezilla تصویری کامل از دیسک فیزیکی آن گرفتم و تصویر را در VMware Workstation بازیابی کردم. حجم SSD صدوبیستگیگابایتی به اندازهٔ بسیار جمعوجورتر ۹.۱۲ گیگابایت کاهش یافت، اوبونتو تقریباً بینقص راه افتاد و خودکارسازیهای n8n نیز پس از مهاجرت همچنان کار میکردند.
ارزش این خودکارسازیها از سختافزار بیشتر بود
مینیپیسی جایگزینشدنی بود، اما وضعیت کاری آن نه
دستگاهی که میخواستم آزاد کنم، Intel NUC6CAYB قدیمیام بود؛ سامانهای کاملاً معمولی با این مشخصات:
- پردازندهٔ اینتل سلرون (Intel Celeron J3455)
- حافظهٔ رم ۴ گیگابایتی (RAM)
- درایو حالت جامد ۱۲۰ گیگابایتی سندیسک (SanDisk SSD)
- اوبونتو سرور ۲۶.۰۴.۱ با پشتیبانی بلندمدت (Ubuntu Server ۲۶.۰۴.۱ LTS)
مینیپیسی Intel NUC من هیچ ایرادی نداشت و اوبونتو همراه با خودکارسازیها تنها ۱۹ گیگابایت از SSD را اشغال کرده بود. وقتی نیاز اصلی من فضای ذخیرهسازی محلی بیشتری بود، اختصاص دادن یک مینیپیسی کامل به تنها دو کانتینر Docker، اتلافی باورنکردنی به شمار میرفت.
البته آن کانتینرها هنوز کارهای سودمندی انجام میدادند. n8n یک گردشکار را برای نظارت بر سرور Home Ops من اجرا میکرد و گردشکاری دیگر نیز نمونهٔ راهدور Glances را بررسی میکرد و هر روز گزارشی میفرستاد. اعلانهای هر دو از طریق یک ربات Telegram ارسال میشدند.
کپیکردن همهٔ فایلهای Compose بهتنهایی هیچیک از اطلاعات مهم را حفظ نمیکرد. به دادههای متصلشده با bind mount، اطلاعات ورود، وضعیت گردشکارها، تاریخچهٔ اجراها و تمام تصمیمهای ریزی هم نیاز داشتم که در طول مسیر هیچجا ثبتشان نکرده بودم.
بنابراین، پیش از آنکه اجازه دهم Clonezilla به سرور دست بزند، بارهای کاری آن را وارسی کردم:
sudo docker compose ls sudo docker inspect n8n --format '{{range .Mounts}}{{.Source}} -> {{.Destination}}{{println}}{{end}}' این بررسی تأیید کرد که هر دو پروژهٔ Compose در حال اجرا هستند و سیاست راهاندازی دوبارهٔ n8n روی «unless stopped» تنظیم شده است. سپس برای آزمودن خودکارسازیها، Homarr را عمداً متوقف کردم. اعلانهای قطعی و بازیابی هر دو مطابق انتظار رسیدند و سرور برای مهاجرت به یک ماشین مجازی آماده شد.
تصویر دیسک نباید تنها نسخهٔ موجود از اطلاعات مهم باشد. به همین دلیل، بایگانی جداگانهای هم ساختم که پوشههای n8n و ntfy، تنظیمات Caddy و گواهیها را در بر میگرفت. همچنین هشهای SHA-۲۵۶ را تولید کردم تا پس از استقرار تصویر دیسک روی ماشین مجازی، از انتقال سالم و کامل این پوشهها مطمئن شوم.
کلونزیلا تمام سرور را در ۹.۱۲ گیگابایت جا داد
یک SSD تقریباً خالی ۱۲۰ گیگابایتی به درایو پشتیبان بزرگتری نیاز نداشت
در نگاه نخست، به نظر میرسید فضای ذخیرهسازی نخستین مانع بزرگ باشد. SSD دستگاه NUC با وجود ظرفیت اسمی ۱۲۰ گیگابایت، تنها ۱۱۱.۸ گیگابایت فضای قابلاستفاده داشت؛ درحالیکه ظرفیت فلش USB من فقط ۱۱۵ گیگابایت بود. بله، از نظر فنی بزرگتر بود، اما تنها اندکی.
یک تصویر خام از دیسک تقریباً تمام فضای فلش USB را میگرفت، با آنکه بخش عمدهٔ SSD مبدأ چیزی جز بلوکهای خالی نبود.
اما سامانهٔ فایل اوبونتو تصویر بسیار امیدوارکنندهتری نشان میداد:
Filesystem Size Used Avail Use%
/dev/sda2 109G 19G 85G 19%از آنجا که Clonezilla سامانهٔ فایل ext4 را میشناسد، میتوانست بهجای نگهداشتن تکتک بایتهای خالی در فایلی فشردهنشده و ۱۲۰ گیگابایتی، فقط بلوکهای پُر سامانهٔ فایل را کپی کند. بااینحال، جانب احتیاط را نگه داشتم: برای راهاندازی Clonezilla Live از یک فلش USB یدکی ۱۶ گیگابایتی و Balena Etcher استفاده کردم و فلش USB صدگیگابایتی را نیز به محل نگهداری تصویر اختصاص دادم.
سپس فشردهسازی چندریسمانی Zstandard با تنظیم z9p، که Clonezilla از آن پشتیبانی میکند، اندازهٔ تصویر نهایی را به ۹.۱۲ گیگابایت کاهش داد.
روشی که به کار بردم ساده و کاملاً روشن بود و در شش گام خلاصه میشد:
- بهجای کپی مستقیم میان دیسکها، گزینهٔ ساخت تصویر از دستگاه (
device-image) را برگزینید. - درایو USB با ظرفیت ۱۱۵ گیگابایت را بهعنوان مخزن ایمیج سوار کنید.
- گزینهٔ
savediskرا انتخاب کنید و نامی بهیادماندنی برای آن بگذارید. - حافظهٔ SSD داخلی SanDisk را بهعنوان مبدأ انتخاب کنید.
- از فشردهسازی چندریسمانی Zstandard با گزینهٔ
z9pاستفاده کنید. - درستی ایمیج نهایی را بررسی کنید.
Clonezilla هم پارتیشن ۱ گیگابایتی EFI و هم پارتیشن ۱۱۰.۷ گیگابایتی ext4 را ایمیجبرداری کرد. در نتیجه، ۱۹ گیگابایت فضای اشغالشده به ایمیجی فشرده با حجم ۹.۱۲ گیگابایت تبدیل شد.
پس از پایان ایمیجبرداری، یک ماشین مجازی Ubuntu با تنظیمات زیر ساختم تا سختافزار NUC اصلی را تا جای ممکن بازآفرینی کنم:
- میانافزار UEFI
- یک پردازندهٔ مجازی (vCPU) با دو هسته
- ۴ گیگابایت حافظهٔ RAM
- دیسک سخت SATA خالی با ظرفیت ۱۲۸ گیگابایت
- کارت شبکه در حالت پلشده
فایل ISO مربوط به Clonezilla را به درایو مجازی CD/DVD اختصاص دادم و درایو USB با ظرفیت ۱۰۰ گیگابایت را نیز بهعنوان یک دستگاه USB مستقیماً به ماشین مجازی متصل کردم. Clonezilla پارتیشن NTFS آن را سوار کرد و ایمیج ذخیرهشده را در ریشهٔ مخزن یافت. برای بازگردانی ایمیج روی ماشین مجازی، گزینهٔ restoreddisk را به کار بردم، دیسک SATA مجازی ۱۲۸ گیگابایتی VMware را بهعنوان مقصد برگزیدم و هر دو پارتیشن Ubuntu را روی درایو مجازی خالی بازگرداندم.
هنگام بازگردانی و نخستین راهاندازی، کارت شبکهٔ پلشدهٔ VMware را قطع نگه داشتم؛ زیرا سرور فیزیکی و نسخهٔ شبیهسازیشدهٔ آن در آغاز نام میزبان، نشانی سرویسها و نشانی IP مورد انتظار یکسانی داشتند. حضور همزمان هر دو در شبکه میتوانست به پیدایش دو دستگاه با هویت یکسان بینجامد.
نخستین راهاندازی موفق بود، اما شبکه نه
نسخهٔ شبیهسازیشده هنوز کارت فیزیکی حذفشده را به یاد داشت
در نخستین راهاندازی مجازی، Ubuntu بیمشکل به نظر میرسید و همان اعلان ورود آشنای mini-pc را نمایش میداد. سامانهٔ فایل، حسابهای کاربری، نام میزبان، نصبهای Docker و سرویسهای سامانه همگی از مهاجرت جان سالم به در برده بودند.
برای حدود ۳۰ ثانیهٔ رؤیایی، به نظر میرسید مهاجرت با موفقیت کامل انجام شده است.
اما شبکه خیلی زود ما را به واقعیت بازگرداند و فرمانهای زیر مشکل را آشکار کردند:
sudo grep -R . /etc/netplan ip -br address پیکربندی Netplan همچنان با نشانی MAC کارت Ethernet فیزیکی NUC، یعنی f4:4d:30:6a:c5:87، تطبیق داده میشد. در مقابل، VMware یک کارت مجازی با نام ens33 و نشانی MAC برابر با 00:0c:29:41:3e:b4 در اختیار سرور گذاشته بود. از آنجا که سختافزار مورد انتظار Ubuntu دیگر وجود نداشت، هیچ رابط شبکهٔ محلی پیکربندی نشده بود.
پیش از تلاش برای رفع مشکل، از فایل Netplan نسخهٔ پشتیبان گرفتم، نشانی MAC قدیمی را جایگزین کردم و enp3s0 را بهعنوان نام رابطی که سرور اکنون انتظار داشت نگه داشتم:
match:
macaddress: 00:0c:29:4a:e3:b4
set-name: enp3s0 DHCP بلافاصله به کار افتاد، اما بهجای نشانی اصلی .249، نشانی IP برابر با 192.168.1.234 را اختصاص داد. این تغییر همان لحظه گواهیهای Caddy، نشانکها، یکپارچهسازیهای n8n و نشانی سرویسهای محلی را از کار انداخت، زیرا همهٔ آنها از پیش به 192.168.1.249 اشاره میکردند.
رفع این مشکل بهسادگی حذف رزرو .249 در OpenWRT و ساخت رزروی تازه با نشانی MAC کارت شبکهٔ مجازی VMware بود. راهاندازی دوبارهٔ نهایی نشان داد که نشانی IP قدیمی بازگشته است و همچنین خطای قدیمی مسیریابی ntfy را که از نشانی IP اولیه ناشی شده بود، برطرف کرد.
در پایان، open-vm-tools را نصب کردم و سامانهٔ بازیابیشده روی سختافزار مجازی VMware عملکردی نسبتاً روان پیدا کرد.
راهاندازی موفق بهتنهایی مهاجرت را ثابت نمیکرد
سرور باید همان وظیفهٔ واقعی پیشین را انجام میداد
نمایش اعلان ورود و برقراری موفق اتصال SSH فقط ثابت میکرد که Linux میتواند دیسک بازیابیشده را بخواند. این برای اطمینان از عملکرد درست دادههای برنامه، پایشها و خودکارسازیها مانند گذشته کافی نبود.
n8n را از همان نشانی HTTPS پیشین باز کردم و خوشبختانه دیدم که هر دو گردشکار نهتنها همچنان سر جای خود هستند، بلکه فعالاند و اجرا میشوند. تاریخچهٔ پیشین آنها نیز حفظ شده بود و Docker هر دو سرویس n8n و ntfy را بهطور خودکار راهاندازی کرده بود.
سپس Homarr را عمداً روی سرور Home Ops متوقف کردم تا همان آزمایشی را که پیش از مهاجرت به ماشین مجازی انجام داده بودم، تکرار کنم:
sudo docker stop homarrاجرای زمانبندیشدهٔ بعدی گردشکار n8n انجام شد، تغییر را تشخیص داد و از طریق ntfy و تلگرام اعلان فرستاد.
سپس کانتینر را بازیابی کردم:
sudo docker start homarrاجرای زمانبندیشدهٔ بعدی، تغییر وضعیت معکوس را تشخیص داد و پیام رفع مشکل را به ntfy و تلگرام فرستاد. گردشکار واقعاً وضعیت پیشین خود را حفظ کرده بود، تنها تا نوبت بعدی زمانبندی منتظر مانده بود و در هر دو جهت، شاخههای درست n8n را دنبال کرده بود.
پس از آنکه از کارکرد درست آن مطمئن شدم، یک اسنپشات گرفتم و کار را به پایان رساندم. در مجموع، مهاجرت حدود ۳ ساعت زمان برد که بخش عمدهاش صرف تماشای نوار پیشرفتی شد که بهکندی روی صفحه جلو میرفت. هرچند انتقال از دستگاه فیزیکی به ماشین مجازی موفقیتآمیز بود، مهاجرت در این مسیر همچنان محدودیتهایی دارد:
- پیکربندیهای منسوخ و همه خردهریزهای انباشتهشده را نیز همراه با دادهها و برنامههای سودمند حفظ میکند.
- اگر سختافزارهای اختصاصی فراوانی در کار باشند، تنظیمات شبکه، درایورها و مجوزهای وابسته به سختافزار از کار خواهند افتاد.
- اتصال دوبارهٔ دستگاه اصلی میتواند برای نام میزبان، نشانی MAC و نشانی IP تداخل ایجاد کند.
- ایمیج کامل دیسک، جای نسخهٔ پشتیبان جداگانه از برنامهها را نمیگیرد.
NUC و سرور خودکارسازی گزینههای بسیار مناسبی بودند، زیرا اوبونتو از پشتیبانی عمومی سختافزار بهره میبرد و بارهای کاری آن در کانتینرها اجرا میشوند. کلونزیلا مرا از بازسازی پشتهٔ خودکارسازی بینیاز کرد. VMware نیز همهٔ مزیتهای استفاده از ماشین مجازی را بهخوبی نشان داد؛ از جمله امکان گرفتن و بازگرداندن اسنپشاتها و مقیاسپذیری آسانتر.
مهمتر از همه، NUC فیزیکی اکنون آزاد شده است تا کنار میز نقش سرور فایل را بر عهده بگیرد و من نیز بتوانم از سختافزار و SSD آن بسیار بهتر بهره ببرم.
منبع: این مطلب ترجمه و بومیسازی مقالهای از MakeUseOf به قلم Gregory Gibson است. مشاهده مقاله اصلی