유체 컨테이너 관리
컨테이너는 Azure Fluid Relay 서비스의 스토리지 원자 단위이며 작업 및 스냅샷을 포함하여 Fluid 세션에서 저장된 데이터를 나타냅니다. Fluid 런타임은 컨테이너를 사용하여 사용자가 처음으로 조인하거나 종료 후 다시 조인할 때 Fluid 세션의 상태를 리하이드레이션합니다.
Fluid Framework를 사용하여 애플리케이션을 빌드할 때 이 다이어그램에 요약된 대로 컨테이너 만들기 및 관리와 관련하여 고려해야 할 몇 가지 사항이 있습니다.
주요 개념
컨테이너 권한
대부분의 경우 개발자는 컨테이너 및 컨테이너 사용 권한의 인벤토리를 관리하려고 합니다. 여기에는 컨테이너에 대한 액세스 권한이 있는 사용자에 대한 정보와 컨테이너의 식별 이름과 같은 메타데이터가 포함됩니다.
컨테이너 액세스
컨테이너는 컨테이너 ID로 참조됩니다. 사용자가 컨테이너를 만들거나 열기 전에 Azure Fluid Relay 서비스와 통신할 때 Fluid Runtime이 사용할 JWT를 요청해야 합니다. 유효한 JWT를 사용하는 모든 프로세스는 컨테이너에 액세스할 수 있습니다. 컨테이너 액세스에 대한 JWT를 생성하는 것은 개발자의 책임이며, 이를 통해 비즈니스 논리를 제어하여 시나리오에 맞게 액세스를 제어할 수 있습니다. Azure Fluid Relay 서비스는 컨테이너에 액세스할 수 있어야 하는 사용자를 알지 못합니다. 이 항목에 대한 자세한 내용은 Azure Fluid Relay 토큰 계약을 참조하세요.
참고 항목
JWT 필드 documentID는 Fluid 컨테이너 ID에 해당합니다.
컨테이너 이름 지정
컨테이너 이름은 컨테이너를 만들 때 Azure Fluid Relay 서비스에 의해 지정됩니다. 만들기 작업은 나중에 컨테이너를 여는 데 사용해야 하는 GUID 형식의 컨테이너 이름을 반환합니다. 대부분의 경우 개발자는 컨테이너 검색 흐름을 용이하게 하기 위해 친숙한 이름과 함께 이 컨테이너 ID GUID를 자체 데이터 저장소에 저장하려고 합니다.
컨테이너 검색
개발자는 기존 컨테이너의 사용자 검색과 관련된 모든 환경 및 비즈니스 논리를 담당합니다. 이는 Fluid 세션의 사용자 참여, 사용자 간의 컨테이너 직접 공유 또는 기존 아티팩트나 프로세스에 대한 프로그래밍 방식의 컨테이너 할당에 따라 탐색 가능한 컨테이너 목록의 형태를 취할 수 있습니다.
컨테이너 만들기 흐름 예제
이 예제에서 앱/페이지는 클라이언트 앱에서 새 컨테이너를 만들 때 사용할 일반 JWT(특정 컨테이너에 바인딩되지 않음)와 함께 로드됩니다.
클라이언트 쪽 앱은 Fluid Framework API를 사용하여 Azure Fluid Relay 서비스에서 새 컨테이너를 만듭니다. 그러면 새로 할당된 컨테이너 ID가 있는 컨테이너 개체가 생성됩니다. 컨테이너와의 추가 상호 작용에는 컨테이너 ID를 포함하는 새 JWT가 필요합니다.
클라이언트가 새 컨테이너를 만든 후에는 컨테이너 및 사용자가 사용 권한을 관리하도록 매핑하는 일부 시스템에 컨테이너 ID를 저장합니다. 이 시스템은 개발자가 사용자를 위해 만들려는 모든 컨테이너 검색/검색 환경을 구동합니다.
컨테이너와 상호 작용하기 전에 클라이언트는 Fluid Framework 런타임에서 Azure Fluid Relay 서비스로의 후속 호출에 사용할 컨테이너별 JWT를 요청합니다.
컨테이너 콘텐츠 내보내기
애플리케이션에서 최종 사용자가 내보낼 수 있는 데이터를 저장하는 경우 애플리케이션 개발자는 컨테이너에 정의된 분산 데이터 구조로 표시되는 Fluid 컨테이너의 현재 상태를 사용하여 해당 내보내기 기능을 애플리케이션에 빌드하는 역할을 담당합니다. Fluid 컨테이너에 연결하고 여는 방법에 대한 자세한 내용은 컨테이너(fluidframework.com)를 참조하세요. 컨트롤 플레인 API를 사용하여 컨테이너를 나열하고 삭제하는 방법에 대한 자세한 내용은 Microsoft Azure Fluid Relay Server에서 Fluid 컨테이너 삭제를 참조하세요.