Rozwiązywanie problemów z aprowizowaniem maszyny wirtualnej za pomocą pakietu cloud-init

Uwaga

W tym artykule odwołuje się do systemu CentOS — dystrybucji systemu Linux, która zbliża się do stanu zakończenia życia (EOL). Rozważ odpowiednie użycie i zaplanuj. Aby uzyskać więcej informacji, zobacz wskazówki dotyczące zakończenia życia systemu CentOS.

Dotyczy: ✔️ Maszyny wirtualne z systemem Linux — elastyczne zestawy skalowania ✔️

Jeśli tworzysz uogólnione obrazy niestandardowe, użyj pakietu cloud-init do aprowizacji, ale okazało się, że maszyna wirtualna nie została utworzona poprawnie, musisz rozwiązać problemy z obrazami niestandardowymi.

Niektóre przykłady problemów z aprowizowaniem:

• Maszyna wirtualna zostaje zablokowana przez 40 minut, a tworzenie maszyny wirtualnej zostanie oznaczone jako nieudane.
• CustomData nie jest przetwarzany.
• Nie można zainstalować dysku efemerycznego.
• Użytkownicy nie są tworzeni lub występują problemy z dostępem użytkowników.
• Sieć nie jest poprawnie skonfigurowana.
• Błędy wymiany pliku lub partycji.

W tym artykule opisano sposób rozwiązywania problemów z rozwiązaniem cloud-init. Aby uzyskać bardziej szczegółowe informacje, zobacz szczegółowe omówienie cloud-init.

Krok 1. Testowanie wdrożenia bez customData

Plik Cloud-init może zaakceptować customDataelement , który jest przekazywany do niej po utworzeniu maszyny wirtualnej. Najpierw upewnij się, że nie powoduje to żadnych problemów z wdrożeniami. Spróbuj aprowizować maszynę wirtualną bez przekazywania żadnej konfiguracji. Jeśli okaże się, że aprowizacja maszyny wirtualnej nie powiedzie się, wykonaj poniższe kroki, jeśli okaże się, że przekazywana konfiguracja nie jest stosowana, przejdź do kroku 4.

Krok 2. Przegląd wymagań dotyczących obrazów

Główną przyczyną niepowodzenia aprowizacji maszyny wirtualnej jest obraz systemu operacyjnego nie spełnia wymagań wstępnych dotyczących uruchamiania na platformie Azure. Przed podjęciem próby aprowizacji obrazów na platformie Azure upewnij się, że obrazy są prawidłowo przygotowane.

W poniższych artykułach przedstawiono kroki przygotowywania różnych dystrybucji systemu Linux obsługiwanych na platformie Azure:

• dystrybucje oparte na systemie CentOS
• Debian Linux
• Flatcar Container Linux
• Oracle Linux
• Red Hat Enterprise Linux
• SLES i openSUSE
• Ubuntu
• Inne: nieobsługiwane dystrybucje

W przypadku obsługiwanych obrazów pakietu Cloud-init platformy Azure dystrybucje systemu Linux mają już wszystkie wymagane pakiety i konfiguracje, aby poprawnie aprowizować obraz na platformie Azure. Jeśli okaże się, że nie można utworzyć maszyny wirtualnej na podstawie własnego obrazu nadzorowanego, wypróbuj obsługiwany obraz witryny Azure Marketplace, który jest już skonfigurowany dla pakietu cloud-init, przy użyciu opcjonalnego elementu customData. Jeśli obraz customData witryny Azure Marketplace działa prawidłowo, prawdopodobnie występuje problem z wyselekcjonowanych obrazami.

Krok 3. Zbieranie i przeglądanie dzienników maszyn wirtualnych

Gdy nie można zainicjować obsługi administracyjnej maszyny wirtualnej, platforma Azure wyświetli stan "tworzenie", przez 20 minut, a następnie ponownie uruchomi maszynę wirtualną, a następnie zaczeka kolejne 20 minut, zanim w końcu oznaczy wdrożenie maszyny wirtualnej jako niepowodzenie, a następnie oznaczy ją OSProvisioningTimedOut z powodu błędu.

Podczas uruchamiania maszyny wirtualnej potrzebne będą dzienniki z maszyny wirtualnej, aby zrozumieć, dlaczego aprowizowanie nie powiodło się. Aby dowiedzieć się, dlaczego aprowizowanie maszyny wirtualnej nie powiodło się, nie należy zatrzymywać maszyny wirtualnej. Zachowaj działanie maszyny wirtualnej. Aby zebrać dzienniki, należy zachować maszynę wirtualną, która zakończyła się niepowodzeniem. Aby zebrać dzienniki, użyj jednej z następujących metod:

• Włącz diagnostykę rozruchu przed utworzeniem maszyny wirtualnej, a następnie wyświetl je podczas rozruchu.

• Konsola szeregowa

• Uruchom polecenie AZ VM Repair , aby dołączyć i zainstalować dysk systemu operacyjnego przy użyciu katalogu chroot, co pozwoli zebrać następujące dzienniki:

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*

Uwaga

Alternatywnie możesz ręcznie utworzyć ratunkową maszynę wirtualną przy użyciu witryny Azure Portal. Aby uzyskać więcej informacji, zobacz Rozwiązywanie problemów z maszyną wirtualną z systemem Linux przez dołączenie dysku systemu operacyjnego do maszyny wirtualnej odzyskiwania przy użyciu witryny Azure Portal.

Aby rozpocząć początkowe rozwiązywanie problemów, zacznij od dzienników cloud-init i dowiedz się, gdzie wystąpił błąd, a następnie użyj innych dzienników, aby uzyskać szczegółowe informacje i podaj dodatkowe informacje.

• /var/log/cloud-init.log
• /var/log/cloud-init-output.log
• Dzienniki szeregowe/rozruchowe

We wszystkich dziennikach rozpocznij wyszukiwanie "Niepowodzenie", "OSTRZEŻENIE", "WARN", "err", "error", "ERROR". Zalecane jest ustawienie konfiguracji ignorowania wyszukiwań z uwzględnieniem wielkości liter.

Napiwek

Jeśli rozwiązujesz problemy z obrazem niestandardowym, rozważ dodanie użytkownika podczas obrazu. Jeśli aprowizacja nie może ustawić użytkownika administratora, nadal możesz zalogować się do systemu operacyjnego.

Analizowanie dzienników

Poniżej przedstawiono więcej szczegółów na temat tego, czego należy szukać w każdym dzienniku cloud-init.

/var/log/cloud-init.log

Domyślnie wszystkie zdarzenia cloud-init z priorytetem debugowania lub wyższego są zapisywane w pliku /var/log/cloud-init.log. Zapewnia to pełne dzienniki każdego zdarzenia, które wystąpiło podczas inicjowania pakietu cloud-init.

Na przykład:

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

Po znalezieniu błędu lub ostrzeżenia przeczytaj wstecz w dzienniku cloud-init, aby dowiedzieć się, co usługa cloud-init próbowała, zanim napotka błąd lub ostrzeżenie. W wielu przypadkach pakiet cloud-init będzie uruchamiał polecenia systemu operacyjnego lub wykonywał operacje aprowizacji przed błędem, co może zapewnić szczegółowe informacje dotyczące przyczyn wystąpienia błędów w dziennikach. W poniższym przykładzie pokazano, że aplikacja cloud-init próbowała zainstalować urządzenie bezpośrednio przed wystąpieniem błędu.

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)

Jeśli masz dostęp do konsoli szeregowej, możesz spróbować ponownie uruchomić polecenie, które próbuje uruchomić cloud-init.

Rejestrowanie można /var/log/cloud-init.log również ponownie skonfigurować w folderze /etc/cloud/cloud.cfg.d/05_logging.cfg. Aby uzyskać więcej informacji na temat rejestrowania cloud-init, zapoznaj się z dokumentacją cloud-init.

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

Informacje można uzyskać z i stdoutstderr na etapach pakietu cloud-init. Zwykle obejmuje to informacje o tabeli routingu, informacje o sieci, informacje stdout o weryfikacji klucza hosta SSH i stderr dla każdego etapu pakietu cloud-init wraz ze znacznikiem czasu dla każdego etapu. W razie potrzeby stderrstdout można ponownie skonfigurować rejestrowanie z poziomu /etc/cloud/cloud.cfg.d/05_logging.cfgprogramu .

Dzienniki szeregowe/rozruchowe

Usługa Cloud-init ma wiele zależności. Są one udokumentowane w wymaganych wymaganiach wstępnych dotyczących obrazów na platformie Azure, takich jak sieć, magazyn, możliwość instalowania i instalowania i formatowania dysku tymczasowego. Dowolny z nich może zgłaszać błędy i powodować niepowodzenie pakietu cloud-init. Jeśli na przykład maszyna wirtualna nie może uzyskać dzierżawy DHCP, inicjowanie chmury zakończy się niepowodzeniem.

Jeśli nadal nie możesz wyizolować przyczyny niepowodzenia aprowizacji pakietu cloud-init, musisz zrozumieć, jakie etapy pakietu cloud-init i kiedy są uruchamiane moduły. Aby uzyskać więcej informacji, zobacz Szczegółowe informacje na temat pakietu cloud-init .

Krok 4. Badanie, dlaczego konfiguracja nie jest stosowana

Nie każdy błąd w pliku cloud-init powoduje błąd krytyczny aprowizacji. Jeśli na przykład używasz modułu runcmd w konfiguracji cloud-init, kod zakończenia inny niż zero z uruchomionego polecenia spowoduje niepowodzenie aprowizacji maszyny wirtualnej. Dzieje się tak, ponieważ działa po podstawowej funkcji aprowizacji, która występuje w pierwszych 3 etapach pakietu cloud-init. Aby rozwiązać problemy z tym, dlaczego konfiguracja nie została zastosowana, przejrzyj dzienniki w kroku 3 i moduły cloud-init ręcznie. Na przykład:

• runcmd - czy skrypty działają bez błędów? Uruchom konfigurację ręcznie z terminalu, aby upewnić się, że działają zgodnie z oczekiwaniami.
• Instalowanie pakietów — czy maszyna wirtualna ma dostęp do repozytoriów pakietów?
• Należy również sprawdzić konfigurację customData danych dostarczoną do maszyny wirtualnej, która znajduje się w /var/lib/cloud/instances/<unique-instance-identifier>/user-data.txtlokalizacji .

Następne kroki

Jeśli nadal nie możesz wyizolować przyczyn, dla których usługa cloud-init nie uruchamiała konfiguracji, należy dokładniej przyjrzeć się temu, co dzieje się na każdym etapie inicjowania chmury, a po uruchomieniu modułów. Aby uzyskać więcej informacji, zobacz Szczegółowe informacje na temat konfiguracji pakietu cloud-init.