Azure Container Registry tjänstnivåer
Azure Container Registry är tillgängligt på flera tjänstnivåer (kallas även SKU:er). De här nivåerna ger förutsägbar prissättning och flera alternativ för att anpassa sig till kapacitets- och användningsmönstren för ditt privata Docker-register i Azure.
Nivå | Description |
---|---|
Basic | En kostnadsoptimerad startpunkt för utvecklare som lär sig Azure Container Registry. Grundläggande register har samma programmatiska funktioner som Standard och Premium (till exempel Azure Active Directory autentiseringsintegrering, borttagning av avbildningar och webhooks). Det inkluderade dataflödet för lagring och avbildning är dock lämpligast för scenarier med lägre användning. |
Standard | Standardregister har samma funktioner som Basic, med ökat lagringsutrymme och dataflöde för avbildningar. Standard-register bör uppfylla behoven för de flesta produktionsscenarier. |
Premium | Premium register ger den högsta mängden inkluderade lagrings- och samtidiga åtgärder, vilket möjliggör scenarier med stora volymer. Förutom högre dataflöde för avbildningar lägger Premium till funktioner som geo-replikering för att hantera ett enskilt register i flera regioner, innehållsförtroende för signering av avbildningstaggen, privat länk med privata slutpunkter för att begränsa åtkomsten till registret. |
Nivåerna Basic, Standard och Premium har samma programmatiska funktioner. De drar också nytta av avbildningslagring som hanteras helt av Azure. Om du väljer en nivå på högre nivå får du mer prestanda och skala. Med flera tjänstnivåer kan du komma igång med Basic och sedan konvertera till Standard och Premium när registeranvändningen ökar.
Funktioner och gränser på tjänstnivå
I följande tabell beskrivs funktionerna och registergränserna för tjänstnivåerna Basic, Standard och Premium.
Resurs | Basic | Standard | Premium |
---|---|---|---|
Inkluderat lagringsutrymme1 (GiB) | 10 | 100 | 500 |
Storage gräns (TiB) | 20 | 20 | 20 |
Maximal bildlagerstorlek (GiB) | 200 | 200 | 200 |
Maximal manifeststorlek (MiB) | 4 | 4 | 4 |
ReadOps per minut2, 3 | 1 000 | 3 000 | 10 000 |
WriteOps per minut2, 4 | 100 | 500 | 2 000 |
Ladda ned bandbredd2 (Mbit/s) | 30 | 60 | 100 |
Upload bandbredd 2 (Mbit/s) | 10 | 20 | 50 |
Webhooks | 2 | 10 | 500 |
Geo-replikering | Saknas | Saknas | Stöds |
Tillgänglighetszoner | Saknas | Saknas | Förhandsgranskning |
Förtroende för innehåll | Saknas | Saknas | Stöds |
Privat länk med privata slutpunkter | Saknas | Saknas | Stöds |
• Privata slutpunkter | Saknas | Saknas | 200 |
Regler för offentligt IP-nätverk | Saknas | Saknas | 100 |
Åtkomst till VNet för tjänstslutpunkt | Saknas | Saknas | Förhandsgranskning |
• Regler för virtuellt nätverk | Saknas | Saknas | 100 |
Kundhanterade nycklar | Saknas | Saknas | Stöds |
Behörigheter med lagringsplatsomfattning | Saknas | Saknas | Förhandsgranskning |
• Token | Saknas | Saknas | 20 000 |
• Omfångskartor | Saknas | Saknas | 20 000 |
• Lagringsplatser per omfångskarta | Saknas | Saknas | 500 |
1 Storage ingår i det dagliga priset för varje nivå. Ytterligare lagringsutrymme kan användas, upp till registrets lagringsgräns, till en extra daglig kostnad per GiB. Information om priser finns i Azure Container Registry prissättning. Om du behöver lagringsutrymme utanför registerlagringsgränsen kontaktar du Azure-supporten.
2ReadOps, WriteOps och Bandbredd är minimiuppskattningar. Azure Container Registry strävar efter att förbättra prestanda som användning kräver.
3 En Docker-hämtning översätts till flera läsåtgärder baserat på antalet lager i avbildningen, plus manifesthämtningen.
4 En docker-push översätts till flera skrivåtgärder, baserat på antalet lager som måste push-överföras. En docker push
innehåller ReadOps för att hämta ett manifest för en befintlig avbildning.
5 Enskilda åtgärder i content/delete
, content/read
, content/write
, metadata/read
, metadata/write
motsvarar gränsen för lagringsplatser per omfångskarta.
Registerdataflöde och begränsning
Dataflöde
När du genererar en hög frekvens av registeråtgärder använder du tjänstnivåns gränser för läs- och skrivåtgärder och bandbredd som vägledning för förväntat maximalt dataflöde. Dessa begränsningar påverkar dataplansåtgärder som att lista, ta bort, push-överföra och hämta bilder och andra artefakter.
Om du vill beräkna dataflödet för avbildningshämtningar och push-överföringar specifikt bör du överväga registergränserna och dessa faktorer:
- Antal och storlek på bildskikt
- Återanvändning av lager eller basbilder över bilder
- ytterligare API-anrop som kan krävas för varje pull- eller push-överföring
Mer information finns i dokumentationen för Docker HTTP API V2.
När du utvärderar eller felsöker registerdataflöde bör du även överväga konfigurationen av klientmiljön:
- din Docker-daemonkonfiguration för samtidiga åtgärder
- nätverksanslutningen till registrets dataslutpunkt (eller slutpunkter, om registret är geo-replikerat).
Om du får problem med dataflödet till registret kan du läsa Felsöka registerprestanda.
Exempel
Push-överföring av en enskild 133 MB-avbildning nginx:latest
till ett Azure-containerregister kräver flera läs- och skrivåtgärder för avbildningens fem lager:
- Läsåtgärder för att läsa avbildningsmanifestet, om det finns i registret
- Skrivåtgärder för att skriva avbildningens konfigurationsblob
- Skrivåtgärder för att skriva bildmanifestet
Begränsning
Du kan uppleva begränsning av pull- eller push-åtgärder när registret fastställer att antalet begäranden överskrider de gränser som tillåts för registrets tjänstnivå. Du kan se ett HTTP 429-fel som liknar Too many requests
.
Begränsning kan inträffa tillfälligt när du genererar en burst av avbildningshämtnings- eller push-åtgärder under en mycket kort period, även om den genomsnittliga frekvensen för läs- och skrivåtgärder ligger inom registergränserna. Du kan behöva implementera omprövningslogik med viss backoff i koden eller minska den maximala hastigheten för begäranden till registret.
Visa registeranvändning
Använd kommandot az acr show-usage , eller REST API :et List Usages , för att få en ögonblicksbild av registrets aktuella förbrukning av lagring och andra resurser, jämfört med gränserna för registrets tjänstnivå. Storage användning visas också på registrets översiktssida i portalen.
Användningsinformation hjälper dig att fatta beslut om att ändra tjänstnivån när registret närmar sig en gräns. Den här informationen hjälper dig också att hantera förbrukning.
Anteckning
Registrets lagringsanvändning bör endast användas som en guide och återspeglar kanske inte de senaste registeråtgärderna. Övervaka registrets mått StorageUsed för aktuella data.
Beroende på registrets tjänstnivå innehåller användningsinformationen några eller alla av följande, tillsammans med gränsen på den nivån:
- Storage förbrukas i bytes1
- Antal webhooks
- Antal geo-replikeringar (inklusive startrepliken)
- Antal privata slutpunkter
- Antal IP-åtkomstregler
- Antal regler för virtuellt nätverk
1 I ett geo-replikerat register visas lagringsanvändning för hemregionen. Multiplicera med antalet replikering för totalt förbrukat lagringsutrymme.
Ändra nivåer
Du kan ändra tjänstnivån för ett register med Azure CLI eller i Azure Portal. Du kan flytta fritt mellan nivåer så länge den nivå som du växlar till har den maximala lagringskapacitet som krävs.
Det finns ingen stilleståndstid för registret eller påverkan på registeråtgärder när du flyttar mellan tjänstnivåer.
Azure CLI
Om du vill flytta mellan tjänstnivåer i Azure CLI använder du kommandot az acr update . Om du till exempel vill växla till Premium:
az acr update --name myregistry --sku Premium
Azure Portal
I containerregistret Översikt i Azure Portal väljer du Uppdatera och sedan en ny SKU i listrutan SKU.
Prissättning
Prisinformation om var och en av de Azure Container Registry tjänstnivåerna finns i Prissättning för Container Registry.
Mer information om priser för dataöverföringar finns i Prisinformation om bandbredd.
Nästa steg
Azure Container Registry översikt
Besök ACR-översikten om GitHub för att hitta information om kommande funktioner i tjänsten.
Azure Container Registry UserVoice
Skicka in och rösta på nya funktionsförslag i ACR UserVoice.