Hantera vätskecontainrar
En container är atomisk lagringsenhet i Azure Fluid Relay-tjänsten och representerar data som lagras från en fluidsession, inklusive åtgärder och ögonblicksbilder. Fluid-körningen använder containern för att extrahera tillståndet för en Fluid-session när en användare ansluter för första gången eller återansluts efter att ha lämnat.
När du skapar ett program med Fluid Framework finns det flera saker du behöver ta hänsyn till när det gäller skapande och hantering av containrar, som sammanfattas i det här diagrammet.
Viktiga begrepp
Containerbehörigheter
I de flesta fall vill utvecklare hantera en inventering av containrar och containerbehörigheter. Detta skulle omfatta information om vem som har åtkomst till containrarna samt metadata som containerns eget namn.
Åtkomst till containrar
Containrar refereras till av container-ID. Innan en användare kan skapa eller öppna en container måste de begära en JWT som Fluid Runtime använder när de kommunicerar med Azure Fluid Relay-tjänsten. Alla processer med en giltig JWT kan komma åt en container. Det är utvecklarens ansvar att generera JWT:er för containeråtkomst, vilket ger dem kontroll över affärslogik för att kontrollera åtkomsten efter behov för deras scenario. Azure Fluid Relay-tjänsten har ingen kunskap om vilka användare som ska ha åtkomst till en container. Mer information om det här avsnittet finns i Azure Fluid Relay-tokenkontrakt
Kommentar
JWT-fältet documentID motsvarar container-ID:t för Fluid.
Namngivning av containrar
Containrar namnges av Azure Fluid Relay-tjänsten när containern skapas. Åtgärden Skapa returnerar ett containernamn i form av ett GUID som måste användas senare för att öppna containern. I de flesta fall vill utvecklare lagra detta container-ID GUID, tillsammans med ett eget namn, i sitt eget datalager för att underlätta containeridentifieringsflöden.
Containeridentifiering
Utvecklare ansvarar för alla erfarenheter och affärslogik som rör användaridentifiering av befintliga containrar. Detta kan ske i form av en dåsbar lista över containrar baserat på användarens deltagande i fluidsessionen, direkt delning av containrar mellan användare eller programmatisk tilldelning av containrar till befintliga artefakter eller processer.
Exempel på flöde för skapande av container
I det här exemplet läses appen/sidan in med en allmän JWT (inte bunden till en specifik container) som klientappen ska använda när det är dags att skapa en ny container.
Appen på klientsidan använder Fluid Framework API för att skapa en ny container i Azure Fluid Relay-tjänsten, vilket resulterar i ett containerobjekt med ett nyligen tilldelat container-ID. Ytterligare interaktioner med containern kräver en ny JWT som innehåller container-ID:t.
När klienten har skapat den nya containern sparar den container-ID:t i ett system som mappar containrar och användare för att hantera behörigheter. Det här systemet kommer att driva alla containeridentifierings-/webbläsarupplevelser som utvecklaren vill skapa för sina användare.
Innan du interagerar med containern begär klienten en containerspecifik JWT som ska användas för efterföljande anrop från Fluid Framework-körningen till Azure Fluid Relay-tjänsten.
Exportera containerinnehåll
Om ett program lagrar data som kan behöva exporteras av slutanvändarna ansvarar programutvecklaren för att skapa den exportfunktionen i sitt program, med hjälp av det aktuella tillståndet för containern Fluid som representeras av de distribuerade datastrukturer som definieras i containern. Mer information om hur du ansluter till och öppnar Fluid-containrar finns i: Containrar (fluidframework.com). Mer information om hur du listar och tar bort containrar med kontrollplanets API finns i: Ta bort vätskecontainrar i Microsoft Azure Fluid Relay Server.