cloud-init Hatası: status error ve degraded done Ne Demek?

cloud-init, bir bulut sunucusunu ilk açılışında kuran program: kullanıcını oluşturur, SSH anahtarını koyar, hostname'i ve ağı ayarlar, sağlayıcının panelindeki "user data" kutusuna ne yazdıysan onu çalıştırır. cloud-init status çıktısı error ya da degraded diyorsa bu kurulumun bir kısmı tarif edildiği gibi gitmemiş demektir. Bazen bu önemlidir (kullanıcın ya da paketlerin eksiktir). Aylardır çalışan bir sunucuda ise çoğu zaman önemli değildir.

İlk iş, hangisiyle karşı karşıya olduğunu anlamak.

Önce durumu oku

sudo cloud-init status --long

cloud-init belgelerine göre olası durumlar şunlar: "not started", "running", "done", "error - done", "error - running", "degraded done", "degraded running" ve "disabled". Belgeye göre cloud-init çalışırken sorun yaşadıysa genişletilmiş durumda "degraded" kelimesi görünür; yani iş bitmiş ama yol boyunca bir şeyler aksamıştır.

Çıkış kodu aynı şeyi betiklere söyler. cloud-init 23.4'ten beri: "0 - success", "1 - unrecoverable error", "2 - recoverable error" (return codes). Aynı sayfaya göre 23.4'ten itibaren cloud-init'i çökertmeyen hatalar 2 ile çıkıyor; 1 çöktüğünü, 0 da gerçekten başarılı olduğunu gösteriyor. Yani bir güncellemeden sonra izleme betiğin cloud-init'i birden hatalı göstermeye başladıysa, daha önce hiç görmediği bir uyarı için 2 görüyor olabilir.

Hata durumları sayfası ikisini ayırıyor: kritik hata, cloud-init'in güvenle başa çıkamadığı bir durum; kurtarılabilir hata ise cloud-init'in işini bitirebildiği ama bir şeylerin ters gittiği durum. Mesajlar errors ve recoverable_errors altında, aşamalara göre dizilir: init-local, init, modules-config, modules-final.

İki log ve her birinde ne var?

Hata ayıklama rehberi seni iki dosyaya yönlendiriyor:

• /var/log/cloud-init.log: cloud-init'in kendi ayrıntılı log'u. Hangi veri kaynağını bulduğu, hangi modüllerin çalıştığı, biri başarısız olduğunda Python traceback'i.
• /var/log/cloud-init-output.log: senin için çalıştırdığı komutların çıktısı. apt hataları, runcmd satırlarının çıktısı, bir betiğin ekrana yazdığı her şey.

Önce uyarılara ve hatalara bak, sonra ilkinin hemen önceki satırlarını oku:

sudo grep -nE 'WARNING|ERROR|Traceback' /var/log/cloud-init.log | head -40
sudo tail -n 60 /var/log/cloud-init-output.log

Belgeler servislere ve başarısız birimler listesine bakmayı da öneriyor:

systemctl --failed
systemctl list-units 'cloud*'

(Birim adları sürümden sürüme değişti; list-units 'cloud*' seninkinin kullandığı adları gösterir.)

Şikâyet hata değil de yavaş açılışsa, zamanın nereye gittiğini cloud-init analyze gösterir: blame en maliyetli işlemlere göre sıralı bir rapor, show her açılış aşamasındaki işlemlerin zaman sıralı raporunu verir (CLI başvurusu). İlk açılıştaki paket güncellemesi genelde listenin başındadır.

Yaygın sebepler

Hatalı user data

Belgeler en sık iki user-data sorununu sayıyor: bozuk biçimli YAML ve eksik #cloud-config başlığı (debug user data). Başlık tam olarak #cloud-config olmalı ve en ilk satırda durmalı. Girinti için bir tab, iki noktadan sonra unutulmuş bir boşluk ya da yanlış seviyede bir anahtar yeterli.

Sunucunun gerçekte aldığı veriyi doğrula:

sudo cloud-init schema --system --annotate

Bir dahakine sağlayıcının paneline yapıştırmadan önce dosyayı da doğrula:

cloud-init schema -c user-data.yaml --annotate

Her kayıt bir arıza değil. recoverable_errors seviyeye göre ayrılıyor: "WARNING", "DEPRECATED", "ERROR" ve "CRITICAL" (exported errors). Belgelerin kendi degraded done örneği de apt kaynaklarıyla ilgili tek bir uyarıdan ibaret. Bir uyarı ya da kullanımdan kalkma notu, her şey çalışırken durumu degraded yapmaya yetiyor.

Ağ ya da metadata hazır değildi

cloud-init ayarlarını sağlayıcının veri kaynağından (bir metadata adresi ya da takılı bir yapılandırma diski) okur. Kaynağı bulamazsa ya da ağ geç açıldıysa ayarları uygulayamaz. cloud-init.log içinde veri kaynaklarını denediğini ve zaman aşımına uğradığını görürsün. Tespit log'u /run/cloud-init/ds-identify.log; belgeler, cloud-init hiç çalışmamış gibi göründüğünde buna bakmayı öneriyor.

Taşınmış, başka bir platformda anlık görüntüden geri yüklenmiş ya da metadata servisi olmadan ISO'dan kurulmuş bir sunucuda bu her açılışta tekrarlanır. Bu durum genelde zararsızdır; aşağıya bak.

Paket mirror hataları

package_update, package_upgrade ve packages ilk açılışta apt çalıştırır. Mirror yavaşsa, erişilemiyorsa ya da tam o sırada eşitleniyorsa cloud-init-output.log içinde apt hatalarını, durum çıktısında da paket modülünden gelen bir hatayı görürsün. Çözüm, ağ artık düzgünken o adımı kendin çalıştırmak:

sudo apt update && sudo apt upgrade
sudo apt install <user data içindeki paketler>

Kendi runcmd satırın başarısız oldu

runcmd satırları ilk açılışın sonunda bir betik olarak çalışır. Biri sıfırdan farklı bir kodla çıkarsa cloud-init scripts_user modülünden bir hata bildirir. Komutun kendi çıktısı cloud-init-output.log içindedir. Komutu düzelt ve elle çalıştır; bunun için cloud-init'i yeniden çalıştırmana gerek yok.

Ne zaman zararsız?

Şunların hepsi doğruysa dokunma ya da sustur:

• Anahtarınla girebiliyorsun, kullanıcın var, hostname ve ağ doğru.
• İstediğin paketler ve dosyalar yerinde (ya da sonradan kurdun).
• Durum yalnızca WARNING ya da DEPRECATED kayıtları olan bir degraded done, ya da tek şikâyet veri kaynağı olmayan bir sunucuda "veri kaynağı yok".

cloud-init belgeleri, cloud-init'i kapatmanın bir yolu olarak touch /etc/cloud/cloud-init.disabled komutunu veriyor: açılış sırasında işletim sisteminin init sistemi bu dosyanın varlığına bakıyor, dosya varsa cloud-init başlatılmıyor. Ardından eski hatayı systemd listesinden temizle:

sudo touch /etc/cloud/cloud-init.disabled
sudo systemctl reset-failed

Bir istisna: sağlayıcın ağı cloud-init üzerinden kuruyorsa kontrol etmeden kapatma. Ubuntu'da /etc/netplan/ klasörüne bak; başlığında veri kaynağından üretildiği yazan bir dosya cloud-init'e aittir. cloud-init'i kapatmak mevcut ağ dosyasını yerinde bırakır ama güncellenmesini durdurur; sağlayıcı bir gün adreslemeni değiştirirse bu önemli olur. Böyle bir sunucuda kapatmak yerine hatayı düzelt.

cloud-init'i güvenle tekrar çalıştırmak

Akla gelen ilk çözüm cloud-init clean --reboot. CLI başvurusu clean komutunun ne yaptığını anlatıyor: cloud-init'in izlerini temiz bir makineyi taklit edecek şekilde siliyor ve yeniden başlatınca cloud-init bütün aşamaları ilk açılıştaki gibi tekrar çalıştırıyor. Yeniden çalıştırma rehberi de uyarıyor: "Making cloud-init run again may be destructive and must never be done on a production system. Artefacts such as ssh keys or passwords may be overwritten." Yani cloud-init'i yeniden çalıştırmak yıkıcı olabilir, üretim sisteminde asla yapılmamalı; SSH anahtarları ve şifreler üzerine yazılabilir. Pratikte bu yeni SSH host anahtarları (her istemci host anahtarı uyarısı görür), eski user data'dan yeniden uygulanan kullanıcılar ve şifreler, iki kez çalışan ilk açılış komutları demek.

Daha güvenli seçenekler, en hafiften en ağıra:

1. Başarısız adımı kendin çalıştır. Paketler ve runcmd için cevap neredeyse hep bu.
2. Tek bir modülü tekrar çalıştır. Belgelerdeki kalıp sudo cloud-init single --name cc_ssh --frequency always; modül adını başarısız olanla değiştir.
3. Yeniden başlat. Belgeye göre yeniden başlatmak, cloud-init'in her açılışta çalışan kısımlarını tekrar çalıştırır.
4. Tam temizlik ve yeniden başlatma, yalnızca bir test makinesinde ya da zaten yeniden kuracağın bir sunucuda.

Sık sunucu kuruyorsan

Her yeni sunucudan önce user data'yı cloud-init schema -c ile doğrula ve ilk açılış işini küçük tut: kullanıcıyı oluştur, anahtarı ekle, gerisini kendi kurulum betiğin yapsın. Böylece açılıştaki bir mirror aksaklığı yarım kalmış bir makine bırakmaz. Sunucu ayağa kalkınca sıradaki adım SSH ve UFW rehberi, ardından fail2ban kurulumu. Sunucu ileride ilk açılışla ilgisi olmayan bir sebeple tuhaflaşırsa, bizim ilk eleyeceğimiz şey dolu disk olurdu.

Başarısız servisleri adıyla gör

Approvalens sunucu ajanı başarısız systemd servislerini adıyla bildirir; sunucu sayfası cloud-init gibi yaygın olanları, ne zaman görmezden gelinebileceklerini de belirterek açıklar.

Sık sorulan sorular

"degraded done" bir hata mı?

cloud-init'in işini bitirdiğini ama en az bir sorun kaydettiğini söyler. cloud-init status --long çıktısında recoverable_errors kısmına bak. Yalnızca WARNING ya da DEPRECATED kayıtları varsa ve sunucu doğru kurulmuşsa bozuk bir şey yok.

cloud-init status neden 2 çıkış kodu vermeye başladı?

23.4 sürümünden beri 2, "kurtarılabilir hata" demek. Öncesinde aynı durum 0 dönüyordu. Sıfırdan farklı her kodu hata sayan betiklerin güncellenmesi gerekiyor; yalnızca çökmeleri önemsiyorsan belgeler 1 kontrolünü öneriyor.

cloud-init'i kaldırabilir miyim?

Kaldırabilirsin ama /etc/cloud/cloud-init.disabled ile kapatmak geri alması daha kolay olan ve belgelerin anlattığı yol. Önce sağlayıcının ağı onun üzerinden yönetmediğinden emin ol.

Sunucunun aldığı user data'yı nerede görürüm?

sudo cloud-init query userdata yazdırır. cloud-init'in hangi satırları kabul etmediğini görmek için sudo cloud-init schema --system --annotate çalıştır.