Řešení problémů se zřizováním virtuálních počítačů pomocí cloud-init

Upozornění

Tento článek odkazuje na CentOS, linuxovou distribuci, která se blíží stavu Konec životnosti (EOL). Zvažte své použití a odpovídajícím způsobem naplánujte. Další informace najdete v doprovodných materiálech CentOS End Of Life.

Platí pro: ✔️ Flexibilní škálovací sady virtuálních počítačů s Linuxem ✔️

Pokud jste vytvářeli generalizované vlastní image pomocí cloud-init ke zřizování, ale zjistili jste, že se virtuální počítač nevytvořil správně, budete muset vyřešit potíže s vlastními imagemi.

Příklady problémů se zřizováním:

• Virtuální počítač se po dobu 40 minut zasekne a vytvoření virtuálního počítače se označí jako neúspěšné.
• CustomData nezpracová se.
• Dočasný disk se nepodaří připojit.
• Uživatelé se nevytvořili nebo dochází k problémům s uživatelským přístupem.
• Sítě nejsou správně nastaveny.
• Selhání prohození souboru nebo oddílu

Tento článek vás provede postupem řešení potíží s cloud-init. Podrobnější podrobnosti najdete v podrobných informacích o cloud-init.

Krok 1: Testování nasazení bez customData

Cloud-init může přijmout customData, který se předá do něj při vytvoření virtuálního počítače. Nejprve se ujistěte, že to nezpůsobuje žádné problémy s nasazeními. Zkuste zřídit virtuální počítač bez předání jakékoli konfigurace. Pokud zjistíte, že se virtuální počítač nepodaří zřídit, pokračujte následujícím postupem, pokud zjistíte, že se neprochází konfigurace, kterou předáváte , pokračujte krokem 4.

Krok 2: Kontrola požadavků na image

Hlavní příčinou selhání zřizování virtuálních počítačů je, že image operačního systému nesplňuje požadavky na provoz v Azure. Před pokusem o jejich zřízení v Azure se ujistěte, že jsou vaše image správně připravené.

Následující články ukazují postup přípravy různých distribucí Linuxu podporovaných v Azure:

• Distribuce založené na CentOS
• Debian Linux
• Flatcar Container Linux
• Oracle Linux
• Red Hat Enterprise Linux
• SLES a openSUSE
• Ubuntu
• Ostatní: Neschválené distribuce

U podporovaných imagí Cloud-init Azure už distribuce Linuxu mají všechny požadované balíčky a konfigurace pro správné zřízení image v Azure. Pokud zjistíte, že se vám nedaří vytvořit virtuální počítač z vlastní kurátorované image, vyzkoušejte podporovanou image Azure Marketplace, která je už nakonfigurovaná pro cloud-init, a to s volitelnou možností customData. Pokud funguje customData správně s imagí Azure Marketplace, pravděpodobně dojde k problému s vaším kurátorovaným obrázkem.

Krok 3: Shromažďování a kontrola protokolů virtuálních počítačů

Když se virtuální počítač nepodaří zřídit, Azure zobrazí stav Vytváření, 20 minut a pak virtuální počítač restartuje a počkejte dalších 20 minut, než nakonec označí nasazení virtuálního počítače jako neúspěšné, a teprve potom ho označíte chybou OSProvisioningTimedOut .

Zatímco je virtuální počítač spuštěný, budete potřebovat protokoly z virtuálního počítače, abyste pochopili, proč zřizování selhalo. Pokud chcete zjistit, proč se zřizování virtuálního počítače nezdařilo, nezastavte virtuální počítač. Nechte virtuální počítač spuštěný. Abyste mohli shromažďovat protokoly, budete muset ponechat virtuální počítač, který selhal, ve spuštěném stavu. Pokud chcete shromáždit protokoly, použijte jednu z následujících metod:

• Před vytvořením virtuálního počítače povolte diagnostiku spouštění a pak je během spouštění zobrazte .

• Sériová konzola

• Spuštěním opravy virtuálního počítače AZ připojte a připojte disk s operačním systémem pomocí chroot, který vám umožní shromáždit tyto protokoly:

sudo cat /rescue/var/log/cloud-init*
sudo cat /rescue/var/log/waagent*
sudo cat /rescue/var/log/syslog*
sudo cat /rescue/var/log/rsyslog*
sudo cat /rescue/var/log/messages*
sudo cat /rescue/var/log/kern*
sudo cat /rescue/var/log/dmesg*
sudo cat /rescue/var/log/boot*

Poznámka:

Případně můžete ručně vytvořit záchranný virtuální počítač pomocí webu Azure Portal. Další informace najdete v tématu Řešení potíží s virtuálním počítačem s Linuxem připojením disku s operačním systémem k virtuálnímu počítači pro obnovení pomocí webu Azure Portal.

Pokud chcete začít s počátečním řešením potíží, začněte s protokoly cloud-init a zjistěte, kde k chybě došlo, a pak pomocí dalších protokolů podrobně probít a poskytnout další přehledy.

• /var/log/cloud-init.log
• /var/log/cloud-init-output.log
• Protokoly sériového/spouštěcího prostředí

Ve všech protokolech začněte hledat "Failed", "WARNING", "WARN", "err", "error", "ERROR". Doporučujeme nastavit konfiguraci pro ignorování hledání s rozlišováním velkých a malých písmen.

Tip

Pokud řešíte potíže s vlastní imagí, měli byste zvážit přidání uživatele během image. Pokud se zřizování nepodaří nastavit uživatele správce, můžete se stále přihlásit k operačnímu systému.

Analýza protokolů

Tady jsou další podrobnosti o tom, co hledat v jednotlivých protokolech cloud-init.

/var/log/cloud-init.log

Ve výchozím nastavení jsou všechny události cloud-init s prioritou ladění nebo vyšší, zapsány do /var/log/cloud-init.log. Poskytuje podrobné protokoly každé události, ke které došlo během inicializace cloud-init.

Příklad:

2019-10-10 04:51:25,321 - util.py[DEBUG]: Failed mount of '/dev/sr0' as 'auto': Unexpected error while running command.
Command: ['mount', '-o', 'ro,sync', '-t', 'auto', u'/dev/sr0', '/run/cloud-init/tmp/tmpLIrklc']
Exit code: 32
Reason: -
Stdout:
Stderr: mount: unknown filesystem type 'udf'
2020-01-31 00:21:53,352 - DataSourceAzure.py[WARNING]: /dev/sr0 was not mountable

Jakmile najdete chybu nebo upozornění, přečtěte si v protokolu cloud-init zpět, abyste pochopili, co se cloud-init pokusil předtím, než došlo k chybě nebo upozornění. V mnoha případech cloud-init bude mít před chybou spuštěné příkazy operačního systému nebo provádět operace zřizování, které můžou poskytovat přehledy o tom, proč se v protokolech zobrazovaly chyby. Následující příklad ukazuje, že se cloud-init pokusil připojit zařízení přímo před chybou.

2019-10-10 04:51:24,010 - util.py[DEBUG]: Running command ['mount', '-o', 'ro,sync', '-t', 'auto', u'/dev/sr0', '/run/cloud-init/tmp/tmpXXXXX'] with allowed return codes [0] (shell=False, capture=True)

Pokud máte přístup k sériové konzole, můžete zkusit znovu spustit příkaz, který se cloud-init pokusil spustit.

Protokolování /var/log/cloud-init.log lze také překonfigurovat v rámci /etc/cloud/cloud.cfg.d/05_logging.cfg. Další podrobnosti o protokolování cloud-init najdete v dokumentaci ke cloud-init.

/var/log/cloud-init-output.log

Informace můžete získat z stdout fází cloud-init a stderr během těchto fází. To obvykle zahrnuje informace o směrovací tabulce, síťové informace, ověřovací informace stdout o klíči hostitele SSH a stderr pro každou fázi cloud-init spolu s časovým razítkem pro každou fázi. V případě potřeby stderr je stdout možné protokolování překonfigurovat z /etc/cloud/cloud.cfg.d/05_logging.cfg.

Protokoly sériového/spouštěcího prostředí

Cloud-init má několik závislostí, jsou popsané v požadovaných požadavcích pro image v Azure, jako jsou sítě, úložiště, schopnost připojit ISO a připojit a naformátovat dočasný disk. Některá z těchto možností může vyvolat chyby a způsobit selhání cloud-init. Pokud například virtuální počítač nemůže získat zapůjčení DHCP, cloud-init selže.

Pokud stále nemůžete izolovat, proč se cloud-init nepodařilo zřídit, musíte pochopit, jaké fáze cloud-init a kdy se moduly spouštějí. Další podrobnosti najdete v tématu Potápění hlouběji do cloud-init .

Krok 4: Prozkoumejte, proč se konfigurace nepoužívá

Ne každé selhání v cloud-init vede k závažnému selhání zřizování. Pokud například používáte runcmd modul v konfiguraci cloud-init, nenulový ukončovací kód z příkazu, který je spuštěný, způsobí selhání zřizování virtuálního počítače. Důvodem je to, že běží po základních funkcích zřizování, ke kterým dochází v prvních 3 fázích cloud-init. Pokud chcete vyřešit potíže s tím, proč se konfigurace nepoužila, projděte si protokoly v kroku 3 a moduly cloud-init ručně. Příklad:

• runcmd - Spouští se skripty bez chyb? Spusťte konfiguraci ručně z terminálu, abyste zajistili, že budou fungovat podle očekávání.
• Instalace balíčků – má virtuální počítač přístup k úložištím balíčků?
• Měli byste také zkontrolovat customData konfiguraci dat poskytovanou virtuálnímu počítači, která se nachází v /var/lib/cloud/instances/<unique-instance-identifier>/user-data.txtumístění .

Další kroky

Pokud stále nemůžete izolovat, proč cloud-init nespustí konfiguraci, musíte se podrobněji podívat, co se stane v jednotlivých fázích cloud-init a kdy se moduly spustí. Další informace najdete v tématu Podrobnější informace o konfiguraci cloud-init.