Problemen met het inrichten van VM's oplossen met cloud-init

Let op

In dit artikel wordt verwezen naar CentOS, een Linux-distributie die de status End Of Life (EOL) nadert. Houd rekening met uw gebruik en plan dienovereenkomstig. Zie de Richtlijnen voor het einde van de levensduur van CentOS voor meer informatie.

Van toepassing op: ✔️ Flexibele schaalsets voor Linux-VM's ✔️

Als u gegeneraliseerde aangepaste installatiekopieën hebt gemaakt met behulp van cloud-init om inrichting uit te voeren, maar hebt vastgesteld dat de VIRTUELE machine niet correct is gemaakt, moet u problemen met uw aangepaste installatiekopieën oplossen.

Enkele voorbeelden van problemen met het inrichten:

• De VM blijft 40 minuten hangen bij 'maken' en het maken van de VIRTUELE machine is gemarkeerd als mislukt.
• CustomData wordt niet verwerkt.
• De tijdelijke schijf kan niet worden gekoppeld.
• Gebruikers worden niet gemaakt of er zijn problemen met gebruikerstoegang.
• Netwerken zijn niet juist ingesteld.
• Bestands- of partitiefouten wisselen.

In dit artikel wordt uitgelegd hoe u problemen met cloud-init oplost. Zie cloud-init voor meer gedetailleerde informatie.

Stap 1: De implementatie testen zonder customData

Cloud-init kan accepteren customData, dat wordt doorgegeven aan het bestand, wanneer de virtuele machine wordt gemaakt. Eerst moet u ervoor zorgen dat dit geen problemen met implementaties veroorzaakt. Probeer de VIRTUELE machine in te richten zonder configuratie door te geven. Als u merkt dat de VM niet kan worden ingericht, gaat u verder met de onderstaande stappen als u vindt dat de configuratie die u doorgeeft, niet wordt toegepast op stap 4.

Stap 2: Vereisten voor installatiekopieën controleren

De primaire oorzaak van een VM-inrichtingsfout is dat de installatiekopie van het besturingssysteem niet voldoet aan de vereisten voor uitvoering in Azure. Zorg ervoor dat uw installatiekopieën goed zijn voorbereid voordat u ze in Azure inricht.

In de volgende artikelen ziet u de stappen voor het voorbereiden van verschillende Linux-distributies die worden ondersteund in Azure:

• CentOS-distributies
• Debian Linux
• Flatcar Container Linux
• Oracle Linux
• Red Hat Enterprise Linux
• SLES en OpenSUSE
• Ubuntu
• Overig: niet-goedgekeurde distributies

Voor de ondersteunde Azure-cloud-init-installatiekopieën beschikken de Linux-distributies al over alle vereiste pakketten en configuraties om de installatiekopieën correct in te richten in Azure. Als u merkt dat uw virtuele machine niet kan worden gemaakt op basis van uw eigen gecureerde installatiekopieën, probeert u een ondersteunde Azure Marketplace-installatiekopieën die al zijn geconfigureerd voor cloud-init, met uw optionele customDatainstallatiekopieën. Als de customData installatiekopieën correct werken met een Azure Marketplace-installatiekopieën, is er waarschijnlijk een probleem met uw gecureerde installatiekopieën.

Stap 3: VM-logboeken verzamelen en controleren

Wanneer de VM niet kan worden ingericht, wordt in Azure de status 'maken' weergegeven, gedurende 20 minuten en wordt de VIRTUELE machine opnieuw opgestart. Wacht nog eens 20 minuten voordat de IMPLEMENTATIE van de VIRTUELE machine is gemarkeerd als mislukt, voordat deze uiteindelijk wordt gemarkeerd met een OSProvisioningTimedOut fout.

Terwijl de VM wordt uitgevoerd, hebt u de logboeken van de VM nodig om te begrijpen waarom het inrichten is mislukt. Als u wilt weten waarom het inrichten van vm's is mislukt, stopt u de VM niet. Houd de VM actief. U moet de mislukte VM in een actieve status houden om logboeken te kunnen verzamelen. Gebruik een van de volgende methoden om de logboeken te verzamelen:

• Schakel Diagnostische gegevens over opstarten in voordat u de virtuele machine maakt en bekijk deze vervolgens tijdens het opstarten.

• Seriële console

• Voer AZ VM Repair uit om de besturingssysteemschijf te koppelen en te koppelen met behulp van chroot, zodat u deze logboeken kunt verzamelen:

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*

Notitie

U kunt ook handmatig een reddings-VM maken met behulp van Azure Portal. Zie Problemen met een Virtuele Linux-machine oplossen door de besturingssysteemschijf te koppelen aan een herstel-VM met behulp van Azure Portal.

Als u de eerste probleemoplossing wilt starten, begint u met de cloud-init-logboeken en begrijpt u waar de fout is opgetreden, gebruikt u vervolgens de andere logboeken om dieper in te gaan op de details en krijgt u aanvullende inzichten.

• /var/log/cloud-init.log
• /var/log/cloud-init-output.log
• Seriële/opstartlogboeken

Zoek in alle logboeken naar 'Mislukt', 'WAARSCHUWING', 'WAARSCHUWEN', 'fout', 'fout'. Het wordt aanbevolen om configuratie zo in te stellen dat hoofdlettergevoelige zoekopdrachten worden genegeerd.

Tip

Als u problemen met een aangepaste installatiekopieën wilt oplossen, kunt u overwegen om een gebruiker toe te voegen tijdens de installatiekopieën. Als de inrichting de gebruiker met beheerdersrechten niet kan instellen, kunt u zich nog steeds aanmelden bij het besturingssysteem.

De logboeken analyseren

Hier vindt u meer informatie over wat u moet zoeken in elk cloud-init-logboek.

/var/log/cloud-init.log

Standaard worden alle cloud-init-gebeurtenissen met een prioriteit voor foutopsporing of hoger geschreven naar /var/log/cloud-init.log. Dit biedt uitgebreide logboeken van elke gebeurtenis die is opgetreden tijdens de initialisatie van cloud-init.

Voorbeeld:

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

Zodra u een fout of waarschuwing hebt gevonden, leest u achteruit in het cloud-init-logboek om te begrijpen wat cloud-init heeft geprobeerd voordat deze de fout of waarschuwing heeft bereikt. In veel gevallen hebben cloud-init os-opdrachten uitgevoerd of inrichtingsbewerkingen uitgevoerd vóór de fout, wat inzicht kan geven in waarom fouten in de logboeken worden weergegeven. In het volgende voorbeeld ziet u dat cloud-init heeft geprobeerd een apparaat te koppelen voordat er een fout optreedt.

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)

Als u toegang hebt tot de seriële console, kunt u proberen de opdracht die cloud-init probeerde uit te voeren opnieuw uit te voeren.

De logboekregistratie voor /var/log/cloud-init.log kan ook opnieuw worden geconfigureerd binnen /etc/cloud/cloud.cfg.d/05_logging.cfg. Raadpleeg de cloud-init-documentatie voor meer informatie over cloud-init-logboekregistratie.

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

U kunt informatie ophalen uit de stdout en stderr tijdens de fasen van cloud-init. Dit omvat normaal gesproken routeringstabelgegevens, netwerkinformatie, SSH-hostsleutelverificatiegegevens stdout en stderr voor elke fase van cloud-init, samen met de tijdstempel voor elke fase. Indien gewenst stderr , en stdout logboekregistratie kan opnieuw worden geconfigureerd vanuit /etc/cloud/cloud.cfg.d/05_logging.cfg.

Seriële/opstartlogboeken

Cloud-init heeft meerdere afhankelijkheden. Deze worden gedocumenteerd in de vereiste vereisten voor installatiekopieën in Azure, zoals netwerken, opslag, de mogelijkheid om een ISO te koppelen en de tijdelijke schijf te koppelen en op te maken. Elk van deze fouten kan fouten veroorzaken en ervoor zorgen dat cloud-init mislukt. Als de VM bijvoorbeeld geen DHCP-lease kan krijgen, mislukt cloud-init.

Als u nog steeds niet kunt isoleren waarom cloud-init niet kon worden ingericht, moet u begrijpen welke cloud-init-fasen en wanneer modules worden uitgevoerd. Zie Dieper ingaan op cloud-init voor meer informatie.

Stap 4: Onderzoeken waarom de configuratie niet wordt toegepast

Niet elke fout in cloud-init resulteert in een fatale inrichtingsfout. Als u bijvoorbeeld de runcmd module in een cloud-init-configuratie gebruikt, mislukt een afsluitcode zonder nul van de opdracht die wordt uitgevoerd. Dit komt doordat deze wordt uitgevoerd na de belangrijkste inrichtingsfunctionaliteit die plaatsvindt in de eerste drie fasen van cloud-init. Als u wilt oplossen waarom de configuratie niet is toegepast, raadpleegt u de logboeken in stap 3 en cloud-init-modules handmatig. Voorbeeld:

• runcmd - worden de scripts zonder fouten uitgevoerd? Voer de configuratie handmatig uit vanuit de terminal om ervoor te zorgen dat ze worden uitgevoerd zoals verwacht.
• Pakketten installeren: heeft de VM toegang tot pakketopslagplaatsen?
• Controleer ook de customData gegevensconfiguratie die is opgegeven voor de virtuele machine. Dit bevindt zich in /var/lib/cloud/instances/<unique-instance-identifier>/user-data.txt.

Volgende stappen

Als u nog steeds niet kunt isoleren waarom cloud-init de configuratie niet heeft uitgevoerd, moet u beter kijken wat er gebeurt in elke cloud-init-fase en wanneer modules worden uitgevoerd. Zie Dieper ingaan op cloud-init-configuratie voor meer informatie.