یک کاربر با استفاده از رزبری‌پای زیرو ۲ دبلیو (Raspberry Pi Zero 2 W) یک سرور کوچک شبکه راه‌اندازی کرده که پاسخ به پرس‌وجوهای DNS ورودی را با ترکیب Unbound و Pi-Hole انجام می‌دهد. چند کانتینر Docker نیز برای پایش و داشبورد در نظر گرفته شده و Tailscale بیرون از این کانتینرها برای دسترسی از راه دور و در صورت نیاز Tailscale Serve مستقر شده است.
این مجموعه به‌خوبی کار می‌کند، اما هر از گاهی یک سرویس دچار اختلال می‌شود و نخستین راه‌حل، اتصال SSH به رزبری‌پای برای بررسی مشکل است. همین تجربه‌ها کاربر را به فکر اسکریپتی انداخته که در پس‌زمینه اجرا شود، سرویس‌های غیرفعال را شناسایی کند و مانند یک نگهبان (Watchdog) آن‌ها را بدون دخالت انسان ترمیم کند.
چرا دسترس‌پذیری DNS اهمیت دارد؟
وقتی صحبت از ابزارهای شبکه‌ای روی یک برد تک‌برد (SBC) مانند Raspberry Pi Zero 2 W باشد، مهم‌ترین دغدغه زمان کارکرد (Uptime) است. در حالت ایده‌آل سرور نباید هیچ‌گاه از دسترس خارج شود، اما این همیشه ممکن نیست. یک سرویس، فرایند یا نمونه Docker معیوب می‌تواند سرور را غیرقابل استفاده کند.
اگر کاربر پشت رایانه شخصی باشد یا داشبورد را در مرورگر باز کرده باشد، می‌تواند ببیند کدام کانتینرها از کار افتاده‌اند. اما وقتی هر پرس‌وجوی جست‌وجو از رایانه به سرور Raspberry Pi Zero 2 W می‌رسد، این روش چندان کارآمد نیست. برخی سرویس‌ها مانند Tailscale نیز چون بیرون از Docker مستقر شده‌اند، در داشبورد نمایش داده نمی‌شوند و در صورت خرابی، دسترسی به سیستم از خارج خانه از دست می‌رود.
ساخت اسکریپت خودترمیم
بسیاری از کاربران سامانه‌ای برای رهگیری و هشدار هنگام از کار افتادن Docker یا سرور می‌سازند؛ چنین سامانه‌ای مشکل را اطلاع می‌دهد اما کاری برای بازگرداندن وضعیت کاری انجام نمی‌دهد. از سوی دیگر، منابع سخت‌افزاری برد تک‌برد انتخابی محدود است. Raspberry Pi Zero 2 W می‌تواند کل این مجموعه را اجرا کند، اما توان اجرای ابزارهایی مانند Uptime Kuma و Grafana را ندارد.
به همین دلیل یک اسکریپت گزینه هوشمندانه‌ای است؛ زیرا هنگام راه‌اندازی بارگذاری می‌شود و در بازه‌های زمانی کوتاه در پس‌زمینه اجرا می‌شود. کاربر برای رسیدن به این هدف با Gemini و ChatGPT آزمایش کرده و در نهایت از اسکریپت دومی استفاده کرده است. این اسکریپت بین بررسی‌ها فاصله می‌گذارد و سرور را با نخستین خطا ری‌استارت نمی‌کند.
اسکریپت ابتدا بررسی می‌کند که Docker فعال است یا نه، سپس وضعیت کانتینرها را بازرسی می‌کند و هر چیزی را که در حال اجرا نیست، دوباره راه‌اندازی می‌کند. پس از آن با یک پرس‌وجوی DNS بررسی می‌کند که Pi-Hole فعال است یا نه و سپس در صورت نیاز آن را ری‌استارت می‌کند. Unbound نیز بررسی مشابهی می‌شود و در ادامه سرویس Tailscale تحلیل می‌شود.
حتی اگر همه‌چیز کار کند، ممکن است اینترنت قطع باشد؛ برای این حالت هم بررسی وجود دارد. اسکریپت تنها زمانی راه‌اندازی مجدد سیستم را آغاز می‌کند که چند بررسی پشت‌سرهم شکست بخورند و نتیجه را در یک فایل لاگ ذخیره می‌کند. یک تایمر نیز اسکریپت را وادار می‌کند پس از مدت کوتاهی دوباره اجرا شود؛ دلیل اصلی این کار، جلوگیری از اجرای مداوم آن در حافظه است، زیرا چنین چیزی برای یک برد تک‌برد تجملی محسوب می‌شود.
فراتر از سیاست‌های ری‌استارت Docker
Docker از سیاست‌های ری‌استارت (Restart Policies) پشتیبانی می‌کند و می‌توان آن‌ها را در فایل پیکربندی بررسی کرد. اما فقط ری‌استارت کردن کانتینر، سایر مشکلات موجود روی سرور را بررسی نمی‌کند. کاربر برای همه کانتینرها از سیاست ری‌استارت استفاده می‌کند، اما اسکریپت به‌عنوان یک لایه حفاظتی اضافی عمل می‌کند و کل سیستم Docker را همراه با Tailscale و بررسی اتصال شبکه خارجی مدیریت می‌کند.
اسکریپت بررسی می‌کند که Pi-Hole واقعاً کار می‌کند و حل‌کننده DNS یعنی Unbound را آزمایش می‌کند. اگر چیزی غیرعادی باشد، در لاگ ثبت می‌شود و سپس اسکریپت تلاش می‌کند آن را برطرف کند. به‌طور مشابه، وجود یک فرایند Tailscale به معنای فعال بودن واقعی سرویس نیست؛ اسکریپت سرویس را ری‌استارت می‌کند تا دوباره کار کند. Docker هیچ بررسی‌ای بیرون از کانتینرها پیاده‌سازی نمی‌کند.
بخشی از کد حتی بررسی می‌کند که برد تک‌برد می‌تواند به شبکه خارجی متصل شود. اسکریپت تلاش می‌کند یک شبکه خارجی را پینگ کند و نتیجه را ثبت می‌کند. این اسکریپت مانند یک تازه‌کار عمل نمی‌کند و با عجله فرمان راه‌اندازی مجدد سیستم را صادر نمی‌کند. ری‌استارت تنها زمانی رخ می‌دهد که چند بررسی شکست بخورند و راه دیگری جز شروع دوباره باقی نماند.
البته این اسکریپت بسیار مفصل، سرور Raspberry Pi را کاملاً ضدخطا نمی‌کند. بهترین توصیف این است که نیاز به عیب‌یابی‌های پایه را از بین می‌برد. کارهای خسته‌کننده را انجام می‌دهد و همه نتایج را در یک فایل لاگ برای بررسی بیشتر ارائه می‌کند. بنابراین یک خط پایه برای مرجع و آزمایش‌های بعدی در اختیار دارید یا می‌توانید اقدام‌های پیشرفته‌تری مانند بازسازی کانتینرها انجام دهید.
SSH را برای کارهای مهم نگه دارید
SSH نخستین چیزی است که هنگام کار با یک برد تک‌برد یاد می‌گیرید. صفحه‌ای برای تماشا وجود ندارد و باید به دسترسی ترمینال و دانش خود تکیه کنید. اما اتصال SSH به برد برای کارهای جزئی مانند ری‌استارت یک سرویس یا بررسی‌های پایه شبکه و وضعیت، اتلاف وقت است. یک اسکریپت Bash می‌تواند همه این کارها را ترکیب کند، در زمان‌بندی مشخص اجرا کند و مشکلات کوچک را خودش برطرف کند. ممکن است مجموعه متفاوتی از کانتینرهای Docker و ابزارهای نصب‌شده مستقیم داشته باشید، بنابراین باید اسکریپت را متناسب با نیاز خود تغییر دهید.
در پایان، Raspberry Pi Zero 2 W یک برد تک‌برد کوچک با قابلیت Wi-Fi و بلوتوث است.