Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Azure Container Apps sandbox-miljöer ger snabba, säkra, tillfälliga beräkningsmiljöer med inbyggda funktioner för paus och återupptagning. Sandbox-miljön är en förstklassig resurstyp (Microsoft.App/SandboxGroups) i Container Apps, tillsammans med appar, jobb och dynamiska sessioner.
Important
För att hantera och skapa sandbox-miljö behöver du Azure rollen Container Apps SandboxGroup Data Owner. Tilldela den här rollen till alla användare som skapar och hanterar sandbox-miljö.
Skapa och hantera sandbox-miljöer
Du kan skapa och hantera sandbox-miljöer i portalen Sandboxes eller programmatiskt med hjälp av Azure Container Apps CLI eller SDK.
Viktiga egenskaper hos Container Apps-sandlådor
Uppstart på under en sekund: Sandlådor etableras från förvärmda pooler för nästan omedelbar tillgänglighet.
Stark isolering: Varje sandbox-miljö körs i sin egen säkra gräns, säker för obetrodd kodkörning.
Skala till noll: Du betalar inga CPU- eller minnesavgifter när sandlådorna stoppas.
Horisontell skalning: Tjänsten kan skalas upp till tusentals samtidiga sandlådor vid behov.
OCI-stöd för containerbilder: Använd den medföljande publika bilden eller ta med egna containerbilder som sandbox-rotfilsystem.
Pausa och återuppta: Skapa en ögonblicksbild av hela tillståndet, inklusive minne och disk, och återuppta senare med återställning på under en sekund.
Livscykelkontroll: Du kan hantera hela sandlådelivscykeln, inklusive tillståndsögonblick, persistent lagring och nätverkspolicyer (både utgång och ingång).
När du ska använda sandbox-miljöer
Använd sandlådor när du behöver isolerade beräkningsmiljöer med explicit livscykelkontroll, persistent tillstånd eller programmerbar åtkomst via SDK:er.
| Scenario | Använda sandlådor? | Varför |
|---|---|---|
| AI-kodkörning med tillståndsbevarande | Ja | Pausa mellan aktiviteter, återuppta med fullständig kontext intakt |
| Utvecklingsmiljöer | Ja | Miljöer som kan pausas på begäran och som bevarar tillstånd mellan sessioner |
| Agentarbetsflöden | Ja | Ge AI-agenter beständiga, isolerade arbetsytor över aktivitetsgränser |
| Interaktiva användarsessioner | Ja | Varje användare får en egen isolerad beräkningsmiljö |
| Säker flerklientberäkning | Ja | Stark isolering vid körning av icke betrodda arbetsbelastningar från flera hyresgäster |
| Burst-arbetsbelastningar | Ja | Skala upp från noll till tusentals sandboxar vid behov |
| CI/CD-pipelines | Ja | Tillfälliga bygg- och testmiljöer som skalas till noll när de är inaktiva |
Välj rätt beräkningsalternativ för Container Apps
Använd följande tabell för att välja den Container Apps-beräkningstyp som passar din arbetsbelastning.
| Typ av beräkning | Bäst för | Lifecycle | Tillstånd |
|---|---|---|---|
| Apps | Långvariga tjänster, API:er, webbappar | Kontinuerlig | Tillståndslös (externa tillståndslager) |
| jobb | Uppgifter som körs till slutförande, batchbearbetning | Starta → köra → slutfört | Tillståndslös |
| Dynamiska sessioner | Körning av hanterad kod, LLM-genererade skript | Hanteras av sessionspool | Tillfällig |
| Sandlådor | Programmerbar isolerad beräkning med livscykelkontroll | Du hanterar: skapa, pausa, återuppta, ta bort | Tillståndsbevarande (ögonblicksbilder, volymer) |
Viktiga begrepp
Förutsättningar
För att skapa eller hantera sandbox-miljö behöver du Azure rolltilldelning Container Apps SandboxGroup Data Owner. Utan den här rollen kan du inte utföra åtgärder i sandboxen. Tilldela den här rollen i önskat omfång (Azure prenumeration eller Azure resursgrupp) i Azure-portalen eller med hjälp av Azure CLI.
Innan du kör följande kommando ersätter du platshållarna som omges av <> med dina egna värden.
az role assignment create \
--assignee "<USER_EMAIL_OR_OBJECT_ID>" \
--role "Container Apps SandboxGroup Data Owner" \
--scope "/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP_NAME>"
Sandbox-grupper
En sandlådegrupp är den översta hanteringsgränsen för sandlådor. Det är en Azure Resource Manager resurs (ARM) som du skapar i en resursgrupp och region. Alla sandbox-miljöer, diskbilder, ögonblicksbilder, volymer och hemligheter är begränsade till en sandbox-grupp.
Använd sandbox-grupper för att organisera sandbox-miljöer efter program, team eller miljö.
Sandbox-miljöer
En sandbox-miljö är en enskild isolerad beräkningsinstans i en sandbox-grupp. Varje sandbox-miljö körs från en diskbild eller ögonblicksbild och har en egen gräns för PROCESSOR, minne, disk och nätverk.
Du interagerar med sandbox-miljöer genom att köra kommandon, hantera filer, exponera portar och kontrollera livscykeltillståndet.
Diskbilder
Diskavbildningar är OCI-containeravbildningar som konverteras för användning som sandbox-rotfilsystem. Du kan använda offentliga avbildningar eller skapa privata avbildningar från dina egna containerregister.
Du kan skapa diskbilder från:
- Offentliga avbildningar: Fördefinierade avbildningar som är tillgängliga för alla sandbox-grupper.
- Avbildningar i containerregister: Hämta från offentliga eller privata containerregister med valfri autentisering.
Snapshots
Ögonblicksbilder fångar hela tillståndet för en sandbox i drift, inklusive minne och diskinnehåll. Använd ögonblicksbilder för att:
- Pausa och återuppta: Pausa en sandbox-miljö och återställ den senare med alla processer och data intakta.
- Klona miljöer: Skapa nya sandbox-miljöer från ett känt och bra tillstånd.
- Dela baslinjer: Distribuera förkonfigurerade miljöer i ditt team.
Volymer
Microsoft hanterar volymer och tillhandahåller beständig lagring som du kan montera i sandbox-miljöer. Det finns två typer av volymer:
| Volymtyp | Description |
|---|---|
| Azure blob | Dela data över flera sandlådor (uppladdningar och nedladdningar, persistenta artefakter). Kan monteras i flera sandlådor samtidigt. |
| Datadisk | Lagringsvolym med hög prestanda för databaser, build-cache och stora arbetsmängder. Kan endast monteras på en sandbox i taget. |
Livscykeltillstånd
Sandlådor har följande tillstånd:
| Tillstånd | Description |
|---|---|
| Springa | Aktivt exekverande, med CPU och minne |
| Stoppade | Stoppas av användare, API eller livscykelpolicy |
När sandlådan stoppas tar operationen och bevarar en ögonblicksbild baserad på Suspend Mode (se följande avsnitt).
Du kan konfigurera livscykelpolicyer för varje sandlåda:
- Auto-suspend: Pausa en inaktiv sandlåda efter en konfigurerbar tidsgräns. En sandbox blir inaktiv när den inte har någon inkommande trafik, ingen kodexekvering (via execute API), inga interaktiva shell-sessioner och inga filoperationer.
- Suspend Mode: Välj mellan minnesläge (full snapshot – disk + minne) eller diskläge (endast bevara disk).
- Auto-delete: Radera automatiskt sandlådor efter ett angivet antal dagar efter att sandlådan har stoppats.
Architecture
Sandbox-miljön använder en arkitektur med två plan:
| Flygplan | Endpoint | Operations |
|---|---|---|
| ARM-kontrollplan | management.azure.com |
Skapa, uppdatera, ta bort och lista sandbox-grupper. Hantera VNet-anslutningar. |
| ADC-dataplan | management.azuredevcompute.io |
Hantera sandbox-miljöer, diskbilder, ögonblicksbilder, filer, volymer, hemligheter, portar och utgående principer. |
Du skapar och hanterar sandbox-grupper via ARM-kontrollplanet. Alla åtgärder på enskilda sandlådor och deras resurser sker via ADC:s dataplan, avgränsat till en specifik sandbox-grupp.
Resursnivåer
Varje sandbox-miljö tilldelas en resursnivå som kontrollerar dess processor, minne och diskallokering.
| Tier | CPU | Memory | Disk |
|---|---|---|---|
| XS | 0,25 kärnor | 0,5 GB | 20 GB |
| S | 0,5 kärnor | 1 GB | 20 GB |
| M (standard) | 1 kärna | 2 GB | 20 GB |
| L | 2 kärnor | 4 GB | 40 GB |
| XL | 4 kärnor | 8 GB | 80 GB |
Considerations
Tänk på följande när du arbetar med sandbox-miljö:
- Entra ID krävs: Endast Microsoft Entra ID konton har åtkomst till sandbox-miljön. Personliga Microsoft-konton stöds inte.
- Nätverkskontroller: Du kan konfigurera utgående policyer för att kontrollera utgående trafik från sandlådor, inklusive domänbaserade tillåt eller nek-regler, CIDR-baserade nätverksregler och VNet-integration.
Sandlådor jämfört med dynamiska sessioner
Sandbox-miljöer och dynamiska sessioner tillhandahåller både isolerade beräkningsmiljöer i Container Apps, men de uppfyller olika behov.
| Dynamiska sessioner | Sandbox-miljöer | |
|---|---|---|
| Åtkomstmönster | HTTP-begärandedirigering via en slutpunkt för hantering av sessionspooler | Direkt kontroll via SDK och CLI av enskilda sandboxmiljöer |
| State | Tillfällig, förstörd efter nedkylning | Tillståndskänslig med pausa, återuppta och ögonblicksbilder |
| Utvecklarkontroll | Pool hanterar allokering och livscykel | Du hanterar sandbox-livscykel, filer, portar och principer |
| Bildmodell | Kodtolkare (inbyggd) eller anpassad container | Diskbilder (OCI), ögonblicksbilder, innehållspaket |
| Beständig lagring | Inte tillgänglig | Volymer (Azure Blob, Datadisk) |
| Nätverk | Grundläggande isolering | Principer för utgående trafik, VNet-integrering, porthantering |
| SDK | REST API via poolslutpunkt | Python SDK (azure-containerapps-sandbox) och REST API |
Välj dynamiska sessioner när du behöver en hanterad exekveringsmiljö som döljer den underliggande infrastrukturen. Välj Sandbox-miljö när du behöver programmerbar kontroll över isolerad beräkning med tillståndsbeständighet.