Dela via

Vanliga frågor och svar om Service Fabric Mesh

  • Artikel

Viktigt

Förhandsversionen av Azure Service Fabric Mesh har dragits tillbaka. Nya distributioner kommer inte längre att tillåtas via Service Fabric Mesh-API:et. Stödet för befintliga distributioner fortsätter till och med den 28 april 2021.

Mer information finns i Förhandsversionen av Azure Service Fabric Mesh.

Azure Service Fabric Mesh är en fullständigt hanterad tjänst som gör att utvecklare kan distribuera mikrotjänstprogram utan att hantera virtuella datorer, lagring eller nätverk. Den här artikeln innehåller svar på vanliga frågor.

Hur gör jag för att rapportera ett problem eller ställa en fråga?

Ställ frågor, få svar från Microsoft-tekniker och rapportera problem på lagringsplatsen service-fabric-mesh-preview GitHub.

Kvot och kostnad

Vad kostar det att delta i förhandsversionen?

Det tillkommer för närvarande inga avgifter för att distribuera program eller containrar till Mesh förhandsversion. Håll utkik efter uppdateringar i maj för aktivering av fakturering. Vi rekommenderar dock att du tar bort de resurser som du distribuerar och inte låter dem köras om du inte aktivt testar dem.

Finns det en kvotgräns för antalet kärnor och RAM-minne?

Ja. Kvoterna för varje prenumeration är:

  • Antal program: 5
  • Kärnor per program: 12
  • Totalt RAM-minne per program: 48 GB
  • Slutpunkter för nätverk och ingång: 5
  • Azure-volymer som du kan koppla: 10
  • Antal tjänstrepliker: 3
  • Den största containern som du kan distribuera är begränsad till 4 kärnor och 16 GB RAM-minne.
  • Du kan allokera partiella kärnor till dina containrar i steg om 0,5 kärnor, upp till högst 6 kärnor.

Hur länge kan jag lämna mitt program distribuerat?

Vi har för närvarande begränsat livslängden för ett program till två dagar. Detta är för att maximera användningen av de kostnadsfria kärnor som allokerats till förhandsversionen. Därför kan du bara köra en viss distribution kontinuerligt i 48 timmar, varefter den stängs av.

Om du ser detta kan du verifiera att systemet stänger av det genom att köra az mesh app show kommandot i Azure CLI. Kontrollera om den returnerar "status": "Failed", "statusDetails": "Stopped resource due to max lifetime policies for an application during preview. Delete the resource to continue."

Ett exempel:

az mesh app show --resource-group myResourceGroup --name helloWorldApp

{
  "debugParams": null,
  "description": "Service Fabric Mesh HelloWorld Application!",
  "diagnostics": null,
  "healthState": "Ok",
  "id": "/subscriptions/1134234-b756-4979-84re-09d671c0c345/resourcegroups/myResourceGroup/providers/Microsoft.ServiceFabricMesh/applications/helloWorldApp",
  "location": "eastus",
  "name": "helloWorldApp",
  "provisioningState": "Succeeded",
  "resourceGroup": "myResourceGroup",
  "serviceNames": [
    "helloWorldService"
  ],
  "services": null,
  "status": "Failed",
  "statusDetails": "Stopped resource due to max lifetime policies for an application during preview. Delete the resource to continue.",
  "tags": {},
  "type": "Microsoft.ServiceFabricMesh/applications",
  "unhealthyEvaluation": null
}

Om du vill ta bort resursgruppen använder du az group delete <nameOfResourceGroup> kommandot .

Distributioner

Vilka containeravbildningar stöds?

Om du utvecklar på en Windows Fall Creators Update-dator (version 1709) kan du bara använda Windows version 1709 docker-avbildningar.

Om du utvecklar på en Windows 10 uppdateringsdator från april 2018 (version 1803) kan du använda antingen Windows version 1709 eller Windows version 1803 docker-avbildningar.

Följande os-containeravbildningar kan användas för att distribuera tjänster:

  • Windows – windowsservercore och nanoserver
    • Windows Server 1709
    • Windows Server 1803
    • Windows Server 1809
    • Windows Server 2019 LTSC
  • Linux
    • Inga kända begränsningar

Anteckning

Visual Studio verktyg för Mesh stöder ännu inte distribution till Windows Server 2019- och 1809-containrar.

Vilka typer av program kan jag distribuera?

Du kan distribuera allt som körs i containrar som passar in i begränsningarna för en programresurs (se ovan för mer information om kvoter). Om vi upptäcker att du använder Mesh för att köra olagliga arbetsbelastningar eller missbruka systemet (dvs. utvinning) förbehåller vi oss rätten att avsluta dina distributioner och blockera prenumerationen från att köras på tjänsten. Kontakta oss om du har frågor om att köra en viss arbetsbelastning.

Problem med utvecklarupplevelsen

DNS-matchning från en container fungerar inte

Utgående DNS-frågor från en container till Service Fabric DNS-tjänsten kan misslyckas under vissa omständigheter. Detta undersöks. Så här kan du undvika problemet:

  • Använd Windows Fall Creators-uppdatering (version 1709) eller senare som bascontaineravbildning.
  • Om enbart tjänstnamnet inte fungerar kan du prova det fullständigt kvalificerade namnet: ServiceName.ApplicationName.
  • I Docker-filen för din tjänst lägger du till EXPOSE <port> där porten är den port som du exponerar tjänsten på. Ett exempel:
EXPOSE 80

DNS fungerar inte på samma sätt som för Service Fabric utvecklingskluster och i Mesh

Du kan behöva referera till tjänster på olika sätt i ditt lokala utvecklingskluster än i Azure Mesh.

I ditt lokala utvecklingskluster använder du {serviceName}.{applicationName}. I Azure Service Fabric Mesh använder du {servicename}.

Azure Mesh stöder för närvarande inte DNS-matchning mellan olika program.

Andra kända DNS-problem med att köra ett Service Fabric utvecklingskluster på Windows 10 finns i Felsöka Windows-containrar och kända DNS-problem.

Nätverk

Nat för ServiceFabric-nätverket kan försvinna när du kör appen på den lokala datorn. Om du vill diagnostisera om detta har inträffat kör du följande från en kommandotolk:

docker network ls och notera om servicefabric_nat visas. Om inte kör du följande kommando: docker network create -d=nat --subnet 10.128.0.0/24 --gateway 10.128.0.1 servicefabric_nat

Detta åtgärdar problemet även om appen redan har distribuerats lokalt och är i ett feltillstånd.

Problem med att köra flera appar

Du kan stöta på cpu-tillgänglighet och begränsningar som åtgärdas i alla program. Så här kan du undvika problemet:

  • Skapa ett kluster med fem noder.
  • Minska CPU-användningen i tjänster i den app som distribueras. I tjänstens service.yaml-fil kan du till exempel ändra cpu: 1.0 till cpu: 0.5

Flera program kan inte distribueras till ett kluster med en nod. Så här kan du undvika problemet:

  • Använd ett kluster med fem noder när du distribuerar flera appar till ett lokalt kluster.
  • Ta bort appar som du inte testar för närvarande.

VS Tooling har begränsat stöd för Windows containrar

Verktyget Visual Studio stöder endast distribution av Windows-containrar med en basversion av Windows Server 1709 och 1803 i dag.

Funktionsluckor och andra kända problem

När jag har distribuerat mitt program har nätverksresursen som är associerad med den ingen IP-adress

Det finns ett känt problem där IP-adressen inte blir tillgänglig omedelbart. Kontrollera nätverksresursens status på några minuter för att se den associerade IP-adressen.

Mitt program kan inte komma åt rätt nätverks-/volymresurs

I din programmodell använder du det fullständiga resurs-ID:t för nätverk och volymer för att få åtkomst till den associerade resursen. Här är ett exempel från snabbstartsexemplet:

"networkRefs": [
    {
    "name":  "[resourceId('Microsoft.ServiceFabric/networks', 'SbzVotingNetwork')]" 
    }
]

När jag skalar ut påverkas alla mina containrar, inklusive att köra dem

Det här är en bugg och en korrigering implementeras.

Nästa steg

Mer information om Service Fabric Mesh finns i översikten.