لینوکس ۳۰۵؛ شب ۵۵: cloud-init؛ رشد دیسک، خطا و آماده‌سازی template

دیسک ۱۲ گیگابایتی ممکن است هنوز فایل‌سیستم کوچک قبلی را داشته باشد. امشب رشد دیسک root، تشخیص مرحلهٔ شکست و آماده‌سازی یک کپی برای بوت بعدی را جدا بررسی می‌کنیم.

این جلسه بخشی از دورهٔ لینوکس ۳۰۵ در ۶۰ شب است.

جایگاه در دوره: هدف‌های 353.3 آزمون 305-300.

محیط: مهمان مستقل ci305؛ برای بخش template از یک Clone دورریختنی استفاده کن. گزینه‌های CLI را با cloud-init --version و help نسخهٔ نصب‌شده تطبیق بده.

سه اندازهٔ متفاوت#

پیش از نخستین بوت یک overlay تازه، اندازهٔ virtual disk را مثل شب ۵۴ افزایش بده. در user-data همان شب این کلیدها را اضافه کن:

growpart:
  mode: auto
  devices: ['/']
  ignore_growroot_disabled: false
resize_rootfs: true

این تنظیم برای رشد partition حاوی root و فایل‌سیستم پشتیبانی‌شده است؛ LVM، layout پیچیده یا filesystem ناسازگار نیاز به روش خودش دارد. داخل مهمان بعد پایان cloud-init:

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
findmnt /
df -hT /
sudo cloud-init status --long

اندازهٔ image، partition و filesystem را تطبیق بده؛ چند مگابایت اختلاف و partitionهای boot طبیعی است. qemu-img resize را هنگام اجرای QEMU روی disk زنده اجرا نکن.

دیسک دادهٔ تازه#

این شاخه دیسک جدید و خالی را partition و format می‌کند؛ اطلاعات قبلی آن قابل حفظ نیست. در پوشهٔ همین تمرین، یک تصویر دوگیگابایتی تازه بساز؛ نام موجود را انتخاب نکن:

qemu-img create -f qcow2 ci305-data.qcow2 2G

به فرمان QEMU نمونهٔ تازه، این آرگومان‌ها را اضافه کن؛ فرمان مستقل shell نیستند:

-drive file=ci305-data.qcow2,format=qcow2,if=none,id=data305 \
-device virtio-blk-pci,drive=data305,serial=lab305-data

پیش از automation، یک boot اکتشافی با user-data بدون کلیدهای storage انجام بده. داخل guest، lsblk و readlink -f /dev/disk/by-id/virtio-lab305-data باید همین دیسک خالی دوگیگابایتی را نشان دهند. سپس خاموش کن و نمونهٔ تازه با root overlay و seed تازه بساز؛ اگر این شناسه وجود ندارد یا دیسک درست نیست، config زیر را اجرا نکن.

به user-data اضافه کن:

device_aliases:
  labdata: /dev/disk/by-id/virtio-lab305-data
disk_setup:
  labdata:
    table_type: gpt
    layout: true
    overwrite: false
fs_setup:
  - label: lab305-data
    filesystem: ext4
    device: labdata.1
    overwrite: false
mounts:
  - ['LABEL=lab305-data', /srv/data, ext4, 'defaults,nofail', '0', '2']

disk_setup، fs_setup و mounts به‌ترتیب layout، فایل‌سیستم و اتصال را تعریف می‌کنند. overwrite: false انتخاب اشتباه device را ایمن نمی‌کند. label این مثال باید یکتا باشد؛ در محیط عملیاتی UUID واقعی هم روش مناسبی برای mount پایدار است. بعد پایان cloud-init، findmnt /srv/data و lsblk -f را بررسی کن، marker بنویس و بقای آن را پس از reboot بسنج. برای بازگشت، فقط disk داده و root overlay همین شاخه را پس از shutdown کنار بگذار؛ نسخهٔ اصلی ci305 وارد این آزمایش نمی‌شود.

خطا در کدام مرحله است؟#

sudo cloud-init status --long
sudo cloud-init analyze show
sudo journalctl -u cloud-init-local -u cloud-init -u cloud-config -u cloud-final -b --no-pager
sudo less /var/log/cloud-init.log
sudo less /var/log/cloud-init-output.log

مرحلهٔ local منبع اولیه و شبکهٔ لازم را آماده می‌کند؛ مراحل بعدی تنظیم و کار نهایی را انجام می‌دهند. YAML نامعتبر، datasource پیدا‌نشده و خطای APT شواهد یکسان ندارند. جزئیات log را پیش از پاک‌سازی state ثبت کن؛ /var/lib/cloud/ cache و وضعیت اجرای نمونه را نگه می‌دارد.

آماده‌سازی تصویر مستقل#

در Clone مخصوص template، داده و credential برنامه را جدا بازبینی کن. سپس:

sudo cloud-init clean --help
sudo cloud-init clean --logs --machine-id
sudo poweroff

پس از clean دیگر همین نمونه را برای کار عادی reboot نکن؛ خاموش و از disk آن کپی سرد بساز. clean پاک‌کنندهٔ تمام رازها یا کلیدهای host SSH نیست؛ پاک‌سازی آفلاین هویت شب ۲۹ و حذف دسترسی bootstrap اضافی هنوز لازم‌اند. VM تازه با UUID، MAC، seed و instance-id تازه بساز؛ template اصلی writable مشترک نمی‌شود.

آزمون و بازگشت: guest جدید باید hostname و کلید host تازه، فایل شاهد درست و ظرفیت root مورد انتظار داشته باشد. برای خطای عمدی، YAML خراب را روی نمونهٔ تازه بسنج و سپس از baseline تکرار کن؛ clean روی مهمان کاری برای «رفع همهٔ خطاها» مناسب نیست.

منبع: ماژول‌های storage ، مراحل بوت ، CLI و clean ، عیب‌یابی .