مدیریت دستگاهها با Config as Code تو Iru
خلاصهٔ کاملتر
به گفتهٔ Mike Boylan تو بلاگ Iru، خیلی از فرآیندهای مدیریت دستگاه هنوز به «دانش سینهبهسینه» وابستهان: یه ادمین تغییری میده، یهجا (شایدم هیچجا) مستندش میکنه و امیدواره نفر بعدی بفهمه چرا. تو مقیاس بزرگ این یه ریسکه.
ایدهٔ Config as Code اینه که تنظیمات بهجای UI، تو فایلهای تحت کنترلنسخه تعریف بشن؛ همون کاری که Terraform و Ansible و Kubernetes سالهاست میکنن، اینبار روی لایهٔ دستگاه. کل کانفیگ ناوگان میره تو یه ریپوی Git و هر تغییر یه کامیت با diff و نویسندهست.
نویسنده میگه این مدل چند مشکل آشنا رو حل میکنه: مشخصبودن اینکه کی چی رو کِی و چرا عوض کرده، هماهنگی بین چند ادمین، آمادگی همیشگی برای ممیزی، و ورود سادهٔ نیروی جدید که فقط ریپو رو clone میکنه بهجای گشتن دنبال اسکرینشات و داکیومنت.
تو Iru این کار با ابزار خطفرمان iructl و GitHub Actions انجام میشه. ساختار ریپو خودش تعریفه: هر آیتم پوشهٔ خودشو داره و یه فایل مانیفست (JSON/YAML/PLIST) میگه آیتم چیه، فعاله یا نه، تو کدوم Blueprint و کدوم دستگاهها اعمال بشه. یه نمونهٔ سادهٔ مانیفست:
{
"name": "Disable Improve Apple Search",
"active": true,
"runs_on_mac": true,
"ensure_blueprints": [
{ "blueprint": "Iru Level I" }
]
}سینک هوشمنده: قبل از push مانیفست و پروفایل اعتبارسنجی میشن و فقط چیزی که واقعاً عوض شده patch میشه. مهمتر از همه بحث بازیابیه؛ اگه یکی تو کنسول چیزی رو پاک کنه، بهجای بازسازی از رو حافظه، فقط کافیه workflow دوباره اجرا بشه تا همهچی به همون حالتِ اعلامشده تو ریپو برگرده.
نویسنده تأکید میکنه فعلاً بخشهایی مثل Blueprintها و منطق شرطی هنوز تو کنسول مدیریت میشن، ولی نقشهٔ راه API-first قراره امسال پوشش رو بیشتر کنه. پیام اصلی اینه که ناوگان دستگاهها هم باید مثل بقیهٔ استک کار کنه: یه منبع حقیقتِ واحد و بازیابیای که «اجرای دوبارهست، نه بازسازی».
نکات کلیدی:
- تنظیمات دستگاه به شکل فایلهای Git با diff، نویسنده و Pull Request
- پوشش فعلی: پروفایلها، اسکریپتها و اپهای سفارشی مک با iructl و GitHub Actions
- مانیفست هر آیتم میگه کجا و روی چه دستگاهی اعمال بشه
- سینک هشمحور فقط تغییرات واقعی رو اعمال میکنه
- بازیابی بعد از حذف اشتباهی یعنی اجرای دوبارهٔ workflow، نه بازسازی دستی




