Veelvoorkomende problemen in Azure Container Instances oplossen
In dit artikel wordt beschreven hoe u veelvoorkomende problemen kunt oplossen voor het beheren of implementeren van containers in Azure Container Instances. Zie ook veelgestelde vragen.
Als u meer ondersteuning nodig hebt, raadpleegt u de beschikbare Help en ondersteuningsopties in Azure Portal.
Problemen tijdens de implementatie van een containergroep
Naamconventies
Wanneer u de containerspecificatie definieert, moeten bepaalde parameters voldoen aan naamgevingsbeperkingen. In de volgende tabel ziet u de specifieke vereisten voor eigenschappen van de containergroep. Zie Naamconventies in het Azure Architecture Center en naamgevingsregels en -beperkingen voor Azure-resources voor meer informatie.
Bereik | Lengte | Hoofdlettergebruik | Geldige tekens | Voorgesteld patroon | Opmerking |
---|---|---|---|---|---|
Containernaam1 | 1-63 | Kleine letters | Alfanumeriek en afbreekstreepje ergens behalve het eerste of laatste teken | <name>-<role>-container<number> |
web-batch-container1 |
Containerpoorten | Tussen 1 en 65535 | Geheel getal | Geheel getal tussen 1 en 65535 | <port-number> |
443 |
DNS-naamlabel | 5-63 | Niet hoofdlettergevoelig | Alfanumeriek en afbreekstreepje ergens behalve het eerste of laatste teken | <name> |
frontend-site1 |
Omgevingsvariabele | 1-63 | Niet hoofdlettergevoelig | Alfanumeriek en onderstrepingsteken (_) overal behalve het eerste of laatste teken | <name> |
MY_VARIABLE |
Volumenaam | 5-63 | Kleine letters | Alfanumeriek en afbreekstreepjes overal behalve het eerste of laatste teken. Kan geen twee opeenvolgende afbreekstreepjes bevatten. | <name> |
batch-output-volume |
1Beperking ook voor namen van containergroepen wanneer deze niet onafhankelijk van containerinstanties zijn opgegeven, bijvoorbeeld met az container create
opdrachtimplementaties.
Besturingssysteemversie van installatiekopieën wordt niet ondersteund
Als u een installatiekopieën opgeeft die niet door Azure Container Instances worden ondersteund, wordt er een OsVersionNotSupported
fout geretourneerd. De fout is vergelijkbaar met de volgende, waarbij de naam is van de installatiekopieën {0}
die u hebt geprobeerd te implementeren:
{
"error": {
"code": "OsVersionNotSupported",
"message": "The OS version of image '{0}' is not supported."
}
}
Deze fout treedt het vaakst op bij het implementeren van Windows-installatiekopieën die zijn gebaseerd op Semi-Annual Channel release 1709 of 1803, die niet worden ondersteund. Zie Veelgestelde vragen voor ondersteunde Windows-installatiekopieën in Azure Container Instances.
Kan afbeelding niet ophalen
Als Azure Container Instances uw installatiekopie in eerste instantie niet kan ophalen, wordt de installatiekopie opnieuw geprobeerd. Als de pull-bewerking van de installatiekopie blijft mislukken, mislukt ACI uiteindelijk de implementatie en ziet u mogelijk een Failed to pull image
fout.
U kunt dit probleem oplossen door de containerinstantie te verwijderen en de implementatie opnieuw uit te voeren. Zorg ervoor dat de installatiekopie bestaat in het register en u de naam van de installatiekopie juist hebt getypt.
Als de installatiekopie niet kan worden opgehaald, worden gebeurtenissen zoals de volgende weergegeven in de uitvoer van az container show:
"events": [
{
"count": 3,
"firstTimestamp": "2017-12-21T22:56:19+00:00",
"lastTimestamp": "2017-12-21T22:57:00+00:00",
"message": "pulling image \"mcr.microsoft.com/azuredocs/aci-hellowrld\"",
"name": "Pulling",
"type": "Normal"
},
{
"count": 3,
"firstTimestamp": "2017-12-21T22:56:19+00:00",
"lastTimestamp": "2017-12-21T22:57:00+00:00",
"message": "Failed to pull image \"mcr.microsoft.com/azuredocs/aci-hellowrld\": rpc error: code 2 desc Error: image t/aci-hellowrld:latest not found",
"name": "Failed",
"type": "Warning"
},
{
"count": 3,
"firstTimestamp": "2017-12-21T22:56:20+00:00",
"lastTimestamp": "2017-12-21T22:57:16+00:00",
"message": "Back-off pulling image \"mcr.microsoft.com/azuredocs/aci-hellowrld\"",
"name": "BackOff",
"type": "Normal"
}
],
Fout 'Resource niet beschikbaar'
Vanwege verschillende regionale resourcebelasting in Azure krijgt u mogelijk de volgende fout bij het implementeren van een containerinstantie:
The requested resource with 'x' CPU and 'y.z' GB memory is not available in the location 'example region' at this moment. Please retry with a different resource request or in another location.
Deze fout geeft aan dat vanwege zware belasting in de regio waarin u probeert te implementeren, de resources die zijn opgegeven voor uw container op dat moment niet kunnen worden toegewezen. Gebruik een of meer van de volgende oplossingen om uw probleem op te lossen.
- Controleer of uw containerimplementatie-instellingen vallen binnen de parameters die zijn gedefinieerd in de beschikbaarheid van regio's voor Azure Container Instances
- Lagere CPU- en geheugeninstellingen voor de container opgeven
- Implementeren in een andere Azure-regio
- Op een later tijdstip implementeren
Problemen tijdens runtime van containergroep
Container heeft een geïsoleerde herstart uitgevoerd zonder expliciete gebruikersinvoer
Er zijn twee algemene categorieën waarom een containergroep opnieuw kan worden opgestart zonder expliciete gebruikersinvoer. Ten eerste kunnen containers opnieuw worden opgestart die worden veroorzaakt door een crash van het toepassingsproces. De ACI-service raadt aan om waarneembaarheidsoplossingen zoals Application Insights SDK, metrische gegevens van containergroepen en containergroeplogboeken toe te passen om te bepalen waarom de toepassing problemen heeft ondervonden. Ten tweede kunnen klanten opnieuw opstarten ervaren die door de ACI-infrastructuur zijn geïnitieerd vanwege onderhoudsevenementen. Als u de beschikbaarheid van uw toepassing wilt vergroten, voert u meerdere containergroepen uit achter een inkomend onderdeel, zoals een Application Gateway of Traffic Manager.
Container wordt voortdurend afgesloten en opnieuw gestart (geen langlopend proces)
Containergroepen worden standaard ingesteld op een beleid voor opnieuw opstarten van Always, zodat containers in de containergroep altijd opnieuw worden opgestart nadat ze zijn voltooid. Mogelijk moet u dit wijzigen in OnFailure of Nooit als u van plan bent om op taken gebaseerde containers uit te voeren. Als u OnFailure opgeeft en nog steeds continu opnieuw opstarten ziet, kan er een probleem zijn met de toepassing of het script dat in uw container wordt uitgevoerd.
Wanneer u containergroepen uitvoert zonder langdurige processen, ziet u mogelijk herhaalde uitgangen en opnieuw opstarten met installatiekopieën zoals Ubuntu of Alpine. Verbinding maken via EXEC werkt niet omdat de container geen proces heeft dat het actief houdt. U kunt dit probleem oplossen door een startopdracht op te nemen zoals in het volgende voorbeeld met de implementatie van uw containergroep om de container actief te houden.
## Deploying a Linux container
az container create -g MyResourceGroup --name myapp --image ubuntu --command-line "tail -f /dev/null"
## Deploying a Windows container
az container create -g myResourceGroup --name mywindowsapp --os-type Windows --image mcr.microsoft.com/windows/servercore:ltsc2019
--command-line "ping -t localhost"
De Container Instances-API en Azure Portal bevatten een restartCount
eigenschap. Als u het aantal opnieuw opstarten voor een container wilt controleren, kunt u de opdracht az container show in de Azure CLI gebruiken. In de volgende voorbeelduitvoer, die we voor kortheid hebben afgekapt, ziet u de restartCount
eigenschap aan het einde van de uitvoer.
...
"events": [
{
"count": 1,
"firstTimestamp": "2017-11-13T21:20:06+00:00",
"lastTimestamp": "2017-11-13T21:20:06+00:00",
"message": "Pulling: pulling image \"myregistry.azurecr.io/aci-tutorial-app:v1\"",
"type": "Normal"
},
{
"count": 1,
"firstTimestamp": "2017-11-13T21:20:14+00:00",
"lastTimestamp": "2017-11-13T21:20:14+00:00",
"message": "Pulled: Successfully pulled image \"myregistry.azurecr.io/aci-tutorial-app:v1\"",
"type": "Normal"
},
{
"count": 1,
"firstTimestamp": "2017-11-13T21:20:14+00:00",
"lastTimestamp": "2017-11-13T21:20:14+00:00",
"message": "Created: Created container with id bf25a6ac73a925687cafcec792c9e3723b0776f683d8d1402b20cc9fb5f66a10",
"type": "Normal"
},
{
"count": 1,
"firstTimestamp": "2017-11-13T21:20:14+00:00",
"lastTimestamp": "2017-11-13T21:20:14+00:00",
"message": "Started: Started container with id bf25a6ac73a925687cafcec792c9e3723b0776f683d8d1402b20cc9fb5f66a10",
"type": "Normal"
}
],
"previousState": null,
"restartCount": 0
...
}
Notitie
De meeste containerinstallatiekopieën voor Linux-distributies stellen een shell in, zoals bash, als de standaardopdracht. Omdat een shell zelf geen langlopende service is, sluiten deze containers onmiddellijk af en vallen ze in een herstartlus wanneer deze zijn geconfigureerd met het standaardbeleid voor altijd opnieuw opstarten.
Het starten van de container duurt lang
De drie belangrijkste factoren die bijdragen aan de opstarttijd van containers in Azure Container Instances zijn:
Windows-installatiekopieën hebben verdere overwegingen.
Afbeeldingsgrootte
Als het lang duurt voordat uw container wordt gestart, maar uiteindelijk slaagt, kijkt u eerst naar de grootte van de containerinstallatiekopieën. Omdat Azure Container Instances uw containerinstallatiekopie op aanvraag ophaalt, is de opstarttijd die u ziet direct gerelateerd aan de grootte.
U kunt de grootte van uw containerinstallatiekopieën weergeven met behulp van de docker images
opdracht in de Docker CLI:
docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
mcr.microsoft.com/azuredocs/aci-helloworld latest 7367f3256b41 15 months ago 67.6MB
De sleutel voor het klein houden van de grootte van de installatiekopieën is ervoor te zorgen dat uw uiteindelijke installatiekopieën niets bevatten dat tijdens runtime niet is vereist. Een manier om dit te doen, is met builds met meerdere fasen. Builds met meerdere fasen maken het eenvoudig om ervoor te zorgen dat de uiteindelijke installatiekopieën alleen de artefacten bevatten die u nodig hebt voor uw toepassing, en niet een van de extra inhoud die tijdens de build is vereist.
Locatie van afbeelding
Een andere manier om de impact van de pull-installatiekopie op de opstarttijd van uw container te verminderen, is door de containerinstallatiekopie in Azure Container Registry te hosten in dezelfde regio waar u containerinstanties wilt implementeren. Hierdoor wordt het netwerkpad verkort dat de containerinstallatiekopieën nodig hebben, waardoor de downloadtijd aanzienlijk wordt verkort.
Afbeeldingen in cache
Azure Container Instances maakt gebruik van een cachingmechanisme om de opstarttijd van containers te versnellen voor installatiekopieën die zijn gebouwd op algemene Windows-basisinstallatiekopieën, waaronder nanoserver:1809
, servercore:ltsc2019
en servercore:1809
. Veelgebruikte Linux-installatiekopieën, zoals ubuntu:1604
en alpine:3.6
worden ook in de cache opgeslagen. Vermijd het gebruik van de latest
tag voor zowel Windows- als Linux-installatiekopieën. Raadpleeg de best practices voor de installatiekopieëntag van Container Registry voor richtlijnen. Voor een actuele lijst met afbeeldingen en tags in de cache gebruikt u de API list cached images .
Notitie
Het gebruik van installatiekopieën op basis van Windows Server 2019 in Azure Container Instances bevindt zich nog in de preview-fase.
Windows-containers vertragen de netwerkgereedheid
Bij het maken van windows-containers is er mogelijk gedurende maximaal 30 seconden geen binnenkomende of uitgaande connectiviteit (of langer, in zeldzame gevallen). Als uw containertoepassing een internetverbinding nodig heeft, voegt u vertragings- en nieuwe pogingslogica toe om 30 seconden internetverbinding tot stand te brengen. Na de eerste installatie moeten containernetwerken op de juiste manier worden hervat.
Kan geen verbinding maken met de onderliggende Docker-API of bevoegde containers uitvoeren
Azure Container Instances biedt geen directe toegang tot de onderliggende infrastructuur die als host fungeert voor containergroepen. Dit omvat toegang tot de containerruntime, indelingstechnologie en het uitvoeren van bevoegde containerbewerkingen. Raadpleeg de REST-referentiedocumentatie om te zien welke bewerkingen ACI ondersteunt. Als er iets ontbreekt, dient u een aanvraag in op de ACI-feedbackforums.
Het IP-adres van de containergroep is mogelijk niet toegankelijk vanwege niet-overeenkomende poorten
Azure Container Instances biedt nog geen ondersteuning voor poorttoewijzing, zoals bij normale Docker-configuratie. Als u merkt dat het IP-adres van een containergroep niet toegankelijk is wanneer u denkt dat het moet zijn, moet u ervoor zorgen dat u de containerinstallatiekopie hebt geconfigureerd om te luisteren naar dezelfde poorten die u beschikbaar maakt in uw containergroep met de ports
eigenschap.
Als u wilt bevestigen dat Azure Container Instances kan luisteren naar de poort die u hebt geconfigureerd in uw containerinstallatiekopieën, test u een implementatie van de aci-helloworld
installatiekopieën die de poort beschikbaar maakt. Voer ook de aci-helloworld
app uit zodat deze luistert op de poort. aci-helloworld
accepteert een optionele omgevingsvariabele PORT
om de standaardpoort 80 te overschrijven waarop deze luistert. Als u bijvoorbeeld poort 9000 wilt testen, stelt u de omgevingsvariabele in wanneer u de containergroep maakt:
Stel de containergroep in om poort 9000 beschikbaar te maken en geef het poortnummer door als de waarde van de omgevingsvariabele. Het voorbeeld is opgemaakt voor de Bash-shell. Als u de voorkeur geeft aan een andere shell, zoals PowerShell of opdrachtprompt, moet u de variabeletoewijzing dienovereenkomstig aanpassen.
az container create --resource-group myResourceGroup \ --name mycontainer --image mcr.microsoft.com/azuredocs/aci-helloworld \ --ip-address Public --ports 9000 \ --environment-variables 'PORT'='9000'
Zoek het IP-adres van de containergroep in de opdrachtuitvoer van
az container create
. Zoek de waarde van ip.Nadat de container is ingericht, bladert u naar het IP-adres en de poort van de containertoepassing in uw browser, bijvoorbeeld:
192.0.2.0:9000
.U ziet nu het bericht Welkom bij Azure Container Instances! dat wordt weergegeven door de web-app.
Wanneer u klaar bent met de container, verwijdert u deze met behulp van de
az container delete
opdracht:az container delete --resource-group myResourceGroup --name mycontainer
Problemen tijdens implementaties van vertrouwelijke containergroepen
Beleidsfouten tijdens het gebruik van aangepast CCE-beleid
Aangepast CCE-beleid moet worden gegenereerd met de Azure CLI confcom-extensie. Voordat u het beleid genereert, moet u ervoor zorgen dat alle eigenschappen die zijn opgegeven in uw ARM-sjabloon geldig zijn en overeenkomen met wat u verwacht te worden weergegeven in een beleid voor vertrouwelijke computing. Sommige eigenschappen die moeten worden gevalideerd, zijn de containerinstallatiekopieën, omgevingsvariabelen, volumekoppelingen en containeropdrachten.
Hash ontbreekt in beleid
De Azure CLI confcom-extensie maakt gebruik van in de cache opgeslagen installatiekopieën op uw lokale computer die mogelijk niet overeenkomen met de installatiekopieën die extern beschikbaar zijn. Dit kan ertoe leiden dat de laag niet overeenkomt wanneer het beleid wordt gevalideerd. Zorg ervoor dat u oude installatiekopieën verwijdert en de meest recente containerinstallatiekopieën naar uw lokale omgeving haalt. Zodra u zeker weet dat u de nieuwste SHA hebt, moet u het CCE-beleid opnieuw genereren.
Proces/container beëindigd met afsluitcode: 139
Deze afsluitcode treedt op vanwege beperkingen met de basisinstallatiekopie van Ubuntu versie 22.04. Het wordt aanbevolen om een andere basisinstallatiekopieën te gebruiken om dit probleem op te lossen.
Volgende stappen
Meer informatie over het ophalen van containerlogboeken en -gebeurtenissen om fouten in uw containers op te sporen.