Tworzenie pierwszej aplikacji kontenera usługi Service Fabric w systemie Linux
Uruchomienie istniejącej aplikacji w kontenerze systemu Linux w klastrze usługi Service Fabric nie wymaga dokonywania żadnych zmian w aplikacji. W tym artykule przedstawiono proces tworzenia obrazu Docker zawierającego aplikację internetową w języku Python na platformie Flask oraz wdrażania go w klastrze usługi Service Fabric. Będziesz również udostępniać aplikację skonteneryzowaną za pomocą usługi Azure Container Registry. W tym artykule przyjęto założenie, że masz podstawową wiedzą dotyczącą platformy Docker. Aby uzyskać informacje dotyczące platformy Docker, przeczytaj artykuł Docker Overview (Przegląd platformy Docker).
Uwaga
Ten artykuł dotyczy środowiska deweloperskiego systemu Linux. Środowisko uruchomieniowe klastra usługi Service Fabric i środowisko uruchomieniowe platformy Docker muszą być uruchomione w tym samym systemie operacyjnym. Nie można uruchamiać kontenerów systemu Linux w klastrze systemu Windows.
Wymagania wstępne
Komputer dewelopera z następującym oprogramowaniem:
Klaster systemu Linux z co najmniej trzema węzłami.
Rejestr w usłudze Azure Container Registry — utwórz rejestr kontenera w subskrypcji platformy Azure.
Definiowanie kontenera platformy Docker
Zbuduj obraz na podstawie obrazu Python znajdującego się w usłudze Docker Hub.
Określ kontener platformy Docker w pliku Dockerfile. Plik Dockerfile zawiera instrukcje dotyczące konfigurowania środowiska wewnątrz kontenera, ładowania aplikacji do uruchomienia i mapowania portów. Plik Dockerfile stanowi dane wejściowe dla polecenia docker build, za pomocą którego jest tworzony obraz.
Utwórz pusty katalog, a następnie utwórz plik Dockerfile (bez rozszerzenia). Dodaj następujący kod do pliku Dockerfile i zapisz zmiany:
# Use an official Python runtime as a base image
FROM python:2.7-slim
# Set the working directory to /app
WORKDIR /app
# Copy the current directory contents into the container at /app
ADD . /app
# Install any needed packages specified in requirements.txt
RUN pip install -r requirements.txt
# Make port 80 available outside this container
EXPOSE 80
# Define environment variable
ENV NAME World
# Run app.py when the container launches
CMD ["python", "app.py"]
Przeczytaj artykuł Dockerfile reference (Informacje o pliku Dockerfile), aby uzyskać więcej informacji.
Tworzenie podstawowej aplikacji internetowej
Utwórz aplikację internetową platformy Flask, która nasłuchuje na porcie 80 i zwraca wartość „Hello World!”. W tym samym katalogu utwórz plik requirements.txt. Dodaj następujący kod i zapisz zmiany:
Flask
Utwórz również plik app.py i dodaj następujący fragment:
from flask import Flask
app = Flask(__name__)
@app.route("/")
def hello():
return 'Hello World!'
if __name__ == "__main__":
app.run(host='0.0.0.0', port=80)
Zaloguj się do platformy Docker i skompiluj obraz
Następnie utworzymy obraz, który uruchamia aplikację internetową. Podczas ściągania obrazów publicznych z platformy Docker (na przykład python:2.7-slim w naszym pliku Dockerfile) najlepszym rozwiązaniem jest uwierzytelnianie przy użyciu konta usługi Docker Hub zamiast tworzenia anonimowego żądania ściągnięcia.
Uwaga
Podczas wykonywania częstych anonimowych żądań ściągnięcia mogą wystąpić błędy platformy Docker podobne do ERROR: toomanyrequests: Too Many Requests. lub You have reached your pull rate limit. Uwierzytelnianie w usłudze Docker Hub, aby zapobiec tym błędom. Aby uzyskać więcej informacji, zobacz Zarządzanie zawartością publiczną za pomocą usługi Azure Container Registry .
Otwórz okno programu PowerShell i przejdź do katalogu zawierającego plik Dockerfile. Następnie uruchom następujące polecenia:
docker login
docker build -t helloworldapp .
To polecenie powoduje utworzenie nowego obrazu zgodnie z instrukcjami z pliku Dockerfile i nadanie obrazowi nazwy helloworldapp (dzięki zastosowaniu parametru tagowania -t). W celu utworzenia obrazu kontenera obraz podstawowy jest najpierw pobierany z usługi Docker Hub, do której jest dodawana aplikacja.
Po zakończeniu działania polecenia budowania uruchom polecenie docker images, aby wyświetlić informacje o nowym obrazie:
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
helloworldapp latest 86838648aab6 2 minutes ago 194 MB
Lokalne uruchamianie aplikacji
Przed wypchnięciem aplikacji skonteneryzowanej do rejestru kontenerów sprawdź, czy działa ona lokalnie.
Uruchom aplikację, mapując port komputera 4000 na widoczny port kontenera 80:
docker run -d -p 4000:80 --name my-web-site helloworldapp
Parametr name umożliwia nadanie nazwy działającemu kontenerowi (zamiast identyfikatora kontenera).
Nawiąż połączenie z działającym kontenerem. Otwórz przeglądarkę internetową wskazującą adres IP zwrócony na porcie 4000, na przykład "http://localhost:4000". W przeglądarce powinien zostać wyświetlony nagłówek "Hello World!".
Aby zatrzymać kontener, uruchom polecenie:
docker stop my-web-site
Usuń kontener z komputera dewelopera:
docker rm my-web-site
Wypychanie obrazu do rejestru kontenerów
Po sprawdzeniu, że aplikacja działa na platformie Docker, wypchnij obraz do rejestru w usłudze Azure Container Registry.
Uruchom polecenie docker login , aby zalogować się do rejestru kontenerów przy użyciu poświadczeń rejestru.
Poniższy przykład przekazuje identyfikator i hasło jednostki usługi Microsoft Entra. Na przykład nazwę główną usługi można było przypisać do rejestru dla scenariusza automatyzacji. Możesz też zalogować się przy użyciu nazwy użytkownika i hasła rejestru.
docker login myregistry.azurecr.io -u xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx -p myPassword
Następujące polecenie tworzy tag lub alias obrazu z w pełni kwalifikowaną ścieżką do Twojego rejestru. W tym przykładzie obraz jest umieszczany w przestrzeni nazw samples, aby uniknąć zaśmiecania katalogu głównego rejestru.
docker tag helloworldapp myregistry.azurecr.io/samples/helloworldapp
Wypchnij obraz do rejestru kontenerów:
docker push myregistry.azurecr.io/samples/helloworldapp
Umieszczanie w pakiecie obrazu platformy Docker za pomocą narzędzia Yeoman
Zestaw SDK usługi Service Fabric dla systemu Linux zawiera generator Yeoman, który ułatwia tworzenie własnej aplikacji i dodawanie obrazu kontenera. Wykorzystamy narzędzie Yeoman w celu utworzenia aplikacji z pojedynczym kontenerem platformy Docker o nazwie SimpleContainerApp.
Aby utworzyć aplikację kontenera usługi Service Fabric, otwórz okno terminalu i uruchom polecenie yo azuresfcontainer.
Nazwij aplikację (np. „mycontainer”) i usługę aplikacji (np. „myservice”).
W przypadku nazwy obrazu podaj adres URL obrazu kontenera w rejestrze kontenerów (np. „myregistry.azurecr.io/samples/helloworldapp”).
Ponieważ ten obraz ma zdefiniowany punkt wejścia obciążenia, nie musisz jawnie określić poleceń wejściowych (są to polecenia uruchamiane wewnątrz kontenera, które zapewnią działanie kontenera po uruchomieniu).
Określ liczbę wystąpień jako „1”.
Określ mapowanie portów w odpowiednim formacie. W tym artykule należy podać 80:4000 jako mapowanie portów. W ten sposób skonfigurowano, że wszystkie żądania przychodzące przychodzące do portu 4000 na maszynie hosta są przekierowywane do portu 80 w kontenerze.
Konfigurowanie uwierzytelniania repozytorium kontenerów
Zobacz Uwierzytelnianierepozytorium kontenerów, aby dowiedzieć się, jak skonfigurować różne typy uwierzytelniania na potrzeby pobierania obrazu kontenera.
Konfigurowanie trybu izolacji
W wersji środowiska uruchomieniowego 6.3 izolacja maszyny wirtualnej jest obsługiwana w przypadku kontenerów systemu Linux, a tym samym obsługuje dwa tryby izolacji dla kontenerów: proces i funkcję Hyper-V. W trybie izolacji funkcji Hyper-V jądra są izolowane między każdym kontenerem a hostem kontenera. Izolacja funkcji Hyper-V jest implementowana przy użyciu funkcji Clear Containers. Tryb izolacji jest określony dla klastrów systemu Linux w elemecie ServicePackageContainerPolicy w pliku manifestu aplikacji. Tryby izolacji, które można określić, to process, hyperv i default. Wartość domyślna to tryb izolacji procesu. Poniższy fragment kodu przedstawia sposób określania trybu izolacji w pliku manifestu aplikacji.
<ServiceManifestImport>
<ServiceManifestRef ServiceManifestName="MyServicePkg" ServiceManifestVersion="1.0.0"/>
<Policies>
<ServicePackageContainerPolicy Hostname="votefront" Isolation="hyperv">
<PortBinding ContainerPort="80" EndpointRef="myServiceTypeEndpoint"/>
</ServicePackageContainerPolicy>
</Policies>
</ServiceManifestImport>
Konfigurowanie zarządzania zasobami
Zarządzanie zasobami ogranicza zasoby, z których kontener może korzystać na hoście. Element ResourceGovernancePolicy określany w manifeście aplikacji służy do deklarowania limitów zasobów pakietu kodu usługi. Limity można ustawić dla następujących zasobów: Memory, MemorySwap, CpuShares (CPU — względna waga), MemoryReservationInMB, BlkioWeight (BlockIO — względna waga). W tym przykładzie pakiet usług Guest1Pkg otrzymuje dostęp do jednego rdzenia w węzłach klastra, w których jest umieszczony. Limity pamięci są bezwzględne, więc pakiet kodu jest ograniczony do 1024 MB pamięci (i ma rezerwację tej samej ilości ze wstępną gwarancją). Pakiety kodu (kontenery lub procesy) nie mogą przydzielać pamięci ponad ten limit. Podjęcie próby takiego przydzielenia spowoduje wyjątek braku pamięci. Aby wymuszanie limitu zasobów działało, wszystkie pakiety kodu w ramach pakietu usług powinny mieć określone limity pamięci.
<ServiceManifestImport>
<ServiceManifestRef ServiceManifestName="MyServicePKg" ServiceManifestVersion="1.0.0" />
<Policies>
<ServicePackageResourceGovernancePolicy CpuCores="1"/>
<ResourceGovernancePolicy CodePackageRef="Code" MemoryInMB="1024" />
</Policies>
</ServiceManifestImport>
Konfigurowanie funkcji HEALTHCHECK platformy Docker
Począwszy od wersji 6.1, usługa Service Fabric automatycznie integruje zdarzenia funkcji HEALTHCHECK platformy Docker z raportem o kondycji systemu. Oznacza to, że jeśli w kontenerze włączono funkcję HEALTHCHECK, usługa Service Fabric będzie raportować kondycję przy każdej zmianie stanu kondycji kontenera zgłoszonej przez platformę Docker. Raport kondycji OK pojawi się w narzędziu Service Fabric Explorer, gdy wartość health_status będzie równa healthy, a raport OSTRZEŻENIE pojawi się, gdy wartość health_status będzie równa unhealthy.
Począwszy od najnowszej wersji odświeżania wersji 6.4, możesz określić, że oceny docker HEALTHCHECK powinny być zgłaszane jako błąd. Jeśli ta opcja jest włączona, zostanie wyświetlony raport kondycji OK, gdy health_status jest w dobrej kondycji, a błąd pojawi się, gdy health_status jest w złej kondycji.
Instrukcja HEALTHCHECK wskazująca rzeczywisty test wykonywany w celu monitorowania kondycji kontenera musi występować w pliku Dockerfile używanym podczas generowania obrazu kontenera.
Możesz skonfigurować zachowanie funkcji HEALTHCHECK dla każdego kontenera, określając opcje HealthConfig jako część sekcji ContainerHostPolicies w pliku ApplicationManifest.
<ServiceManifestImport>
<ServiceManifestRef ServiceManifestName="ContainerServicePkg" ServiceManifestVersion="2.0.0" />
<Policies>
<ContainerHostPolicies CodePackageRef="Code">
<HealthConfig IncludeDockerHealthStatusInSystemHealthReport="true"
RestartContainerOnUnhealthyDockerHealthStatus="false"
TreatContainerUnhealthyStatusAsError="false" />
</ContainerHostPolicies>
</Policies>
</ServiceManifestImport>
Domyślnie właściwość IncludeDockerHealthStatusInSystemHealthReport jest ustawiona na wartość true, właściwość RestartContainerOnUnhealthyDockerHealthStatus ma wartość false, a właściwość TreatContainerUnhealthyStatusAsError ma wartość false.
Jeśli wartość RestartContainerOnUnhealthyDockerHealthStatus jest ustawiona na true, kontener wielokrotnie raportujący złą kondycję jest uruchamiany ponownie (potencjalnie w innych węzłach).
Jeśli właściwość TreatContainerUnhealthyStatusAsError ma wartość true, raporty o kondycji BŁĘDÓW będą wyświetlane, gdy health_status kontenera jest w złej kondycji.
Aby wyłączyć integrację funkcji HEALTHCHECK dla całego klastra usługi Service Fabric, należy ustawić wartość EnableDockerHealthCheckIntegration na false.
Wdrażanie aplikacji
Po skompilowaniu aplikację można wdrożyć w klastrze lokalnym za pomocą interfejsu wiersza polecenia usługi Service Fabric.
Połącz się z lokalnym klastrem usługi Service Fabric.
sfctl cluster select --endpoint http://localhost:19080
Użyj skryptu instalacji podanego w szablonach w https://github.com/Azure-Samples/service-fabric-containers/ witrynie , aby skopiować pakiet aplikacji do magazynu obrazów klastra, zarejestrować typ aplikacji i utworzyć wystąpienie aplikacji.
./install.sh
Otwórz przeglądarkę i przejdź do narzędzia Service Fabric Explorer dostępnego pod adresem http://localhost:19080/Explorer (zastąp ciąg localhost prywatnym adresem IP maszyny wirtualnej w przypadku używania narzędzia Vagrant w systemie Mac OS X). Rozwiń węzeł Aplikacje i zwróć uwagę, że istnieje teraz wpis dla danego typu aplikacji i inny wpis dla pierwszego wystąpienia tego typu.
Nawiąż połączenie z działającym kontenerem. Otwórz przeglądarkę internetową wskazującą adres IP zwrócony na porcie 4000, na przykład "http://localhost:4000". W przeglądarce powinien zostać wyświetlony nagłówek "Hello World!".
Czyszczenie
Użyj skryptu dezinstalacji udostępnionego w szablonie, aby usunąć wystąpienie aplikacji z lokalnego klastra projektowego i wyrejestrować typ aplikacji.
./uninstall.sh
Po wypchnięciu obrazu do rejestru kontenerów można usunąć lokalny obraz z komputera dewelopera:
docker rmi helloworldapp
docker rmi myregistry.azurecr.io/samples/helloworldapp
Kompletny przykład aplikacji i manifestów usługi Service Fabric
W tym miejscu przedstawiono kompletne manifesty usługi i aplikacji używane w tym artykule.
ServiceManifest.xml
<?xml version="1.0" encoding="utf-8"?>
<ServiceManifest Name="myservicePkg"
Version="1.0.0"
xmlns="http://schemas.microsoft.com/2011/01/fabric"
xmlns:xsd="https://www.w3.org/2001/XMLSchema"
xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance">
<ServiceTypes>
<!-- This is the name of your ServiceType.
The UseImplicitHost attribute indicates this is a guest service. -->
<StatelessServiceType ServiceTypeName="myserviceType" UseImplicitHost="true" />
</ServiceTypes>
<!-- Code package is your service executable. -->
<CodePackage Name="Code" Version="1.0.0">
<EntryPoint>
<!-- Follow this link for more information about deploying containers
to Service Fabric: https://aka.ms/sfguestcontainers -->
<ContainerHost>
<ImageName>myregistry.azurecr.io/samples/helloworldapp</ImageName>
<!-- Pass comma delimited commands to your container: dotnet, myproc.dll, 5" -->
<!--Commands> dotnet, myproc.dll, 5 </Commands-->
<Commands></Commands>
</ContainerHost>
</EntryPoint>
<!-- Pass environment variables to your container: -->
<EnvironmentVariables>
<!--
<EnvironmentVariable Name="VariableName" Value="VariableValue"/>
-->
</EnvironmentVariables>
</CodePackage>
<Resources>
<Endpoints>
<!-- This endpoint is used by the communication listener to obtain the port on which to
listen. Please note that if your service is partitioned, this port is shared with
replicas of different partitions that are placed in your code. -->
<Endpoint Name="myServiceTypeEndpoint" UriScheme="http" Port="4000" Protocol="http"/>
</Endpoints>
</Resources>
</ServiceManifest>
ApplicationManifest.xml
<?xml version="1.0" encoding="utf-8"?>
<ApplicationManifest ApplicationTypeName="mycontainerType"
ApplicationTypeVersion="1.0.0"
xmlns="http://schemas.microsoft.com/2011/01/fabric"
xmlns:xsd="https://www.w3.org/2001/XMLSchema"
xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance">
<!-- Import the ServiceManifest from the ServicePackage. The ServiceManifestName and ServiceManifestVersion
should match the Name and Version attributes of the ServiceManifest element defined in the
ServiceManifest.xml file. -->
<ServiceManifestImport>
<ServiceManifestRef ServiceManifestName="myservicePkg" ServiceManifestVersion="1.0.0" />
<ConfigOverrides />
<Policies>
<ContainerHostPolicies CodePackageRef="Code">
<RepositoryCredentials AccountName="myregistry" Password="=P==/==/=8=/=+u4lyOB=+=nWzEeRfF=" PasswordEncrypted="false"/>
<PortBinding ContainerPort="80" EndpointRef="myServiceTypeEndpoint"/>
</ContainerHostPolicies>
</Policies>
</ServiceManifestImport>
<DefaultServices>
<!-- The section below creates instances of service types, when an instance of this
application type is created. You can also create one or more instances of service type using the
ServiceFabric PowerShell module.
The attribute ServiceTypeName below must match the name defined in the imported ServiceManifest.xml file. -->
<Service Name="myservice">
<!-- On a local development cluster, set InstanceCount to 1. On a multi-node production
cluster, set InstanceCount to -1 for the container service to run on every node in
the cluster.
-->
<StatelessService ServiceTypeName="myserviceType" InstanceCount="1">
<SingletonPartition />
</StatelessService>
</Service>
</DefaultServices>
</ApplicationManifest>
Dodawanie kolejnych usług do istniejącej aplikacji
Aby dodać kolejną usługę kontenera do aplikacji utworzonej już przy użyciu narzędzia Yeoman, wykonaj następujące czynności:
- Zmień katalog na katalog główny istniejącej aplikacji. Na przykład wpisz polecenie
cd ~/YeomanSamples/MyApplication, jeśli aplikacjaMyApplicationto aplikacja utworzona przez narzędzie Yeoman. - Uruchom polecenie
yo azuresfcontainer:AddService
Konfigurowanie interwału czasu wymuszania przerwania działania kontenera
Możesz skonfigurować interwał czasu środowiska uruchomieniowego, po upływie którego kontener ma zostać usunięty po rozpoczęciu usuwania usługi (lub przenoszenia do innego węzła). Skonfigurowanie interwału czasu powoduje wysłanie polecenia docker stop <time in seconds> do kontenera. Aby uzyskać więcej informacji, zobacz docker stop. Interwał czasu oczekiwania jest określony w sekcji Hosting. W poniższym fragmencie manifestu klastra pokazano, jak ustawić interwał oczekiwania:
{
"name": "Hosting",
"parameters": [
{
"name": "ContainerDeactivationTimeout",
"value" : "10"
},
...
]
}
Domyślny interwał to 10 sekund. Ta konfiguracja jest dynamiczna, dlatego uaktualnienie samej konfiguracji w klastrze powoduje zaktualizowanie limitu czasu.
Konfigurowanie środowiska uruchomieniowego w celu usunięcia nieużywanych obrazów kontenerów
Możesz skonfigurować klaster usługi Service Fabric w celu usuwania nieużywanych obrazów kontenerów z węzła. Ta konfiguracja pozwala na ponowne przechwycenie miejsca na dysku w przypadku zbyt wielu obrazów kontenerów w węźle. Aby włączyć tę funkcję, zaktualizuj sekcję Hosting w manifeście klastra, jak pokazano w poniższym fragmencie kodu:
{
"name": "Hosting",
"parameters": [
{
"name": "PruneContainerImages",
"value": "True"
},
{
"name": "ContainerImagesToSkip",
"value": "mcr.microsoft.com/windows/servercore|mcr.microsoft.com/windows/nanoserver|mcr.microsoft.com/dotnet/framework/aspnet|..."
}
...
}
]
}
Jeśli nie chcesz usuwać pewnych obrazów, określ je przy użyciu parametru ContainerImagesToSkip.
Konfigurowanie czasu pobierania obrazów kontenerów
Środowisko uruchomieniowe usługi Service Fabric przydziela 20 minut na pobieranie i wyodrębnianie obrazów kontenerów, co sprawdza się w przypadku większości obrazów kontenerów. W przypadku dużych obrazów lub wolnego połączenia sieciowego może być konieczne wydłużenie czasu oczekiwania przed przerwaniem pobierania i wyodrębniania obrazu. Ten limit czasu można ustawić przy użyciu atrybutu ContainerImageDownloadTimeout w sekcji Hosting manifestu klastra, jak pokazano w poniższym fragmencie kodu:
{
"name": "Hosting",
"parameters": [
{
"name": "ContainerImageDownloadTimeout",
"value": "1200"
}
]
}
Ustawianie zasad przechowywania kontenerów
Aby ułatwić diagnozowanie błędów uruchamiania kontenerów, usługa Service Fabric (w wersji 6.1 lub nowszej) obsługuje przechowywanie kontenerów, w przypadku których działanie zostało przerwane lub uruchamianie nie powiodło się. Te zasady można ustawić w pliku ApplicationManifest.xml, jak pokazano w poniższym fragmencie kodu:
<ContainerHostPolicies CodePackageRef="NodeService.Code" Isolation="process" ContainersRetentionCount="2" RunInteractive="true">
Ustawienie ContainersRetentionCount określa liczbę kontenerów do przechowywania w przypadku wystąpienia w nich błędu. Jeśli zostanie określona wartość ujemna, będą przechowywane wszystkie kontenery z błędami. Jeśli atrybut ContainersRetentionCount nie zostanie określony, nie będą przechowywane żadne kontenery. Atrybut ContainersRetentionCount obsługuje też parametry aplikacji, dzięki czemu użytkownicy mogą określać różne wartości dla klastrów testowych i produkcyjnych. W przypadku używania tej funkcji można zastosować ograniczenia rozmieszczania, tak aby obiektem docelowym usługi kontenera był określony węzeł, co zapobiega przenoszeniu usługi kontenera do innych węzłów. Wszelkie kontenery przechowywane przy użyciu tej funkcji należy usunąć ręcznie.
Uruchamianie demona platformy Docker z niestandardowymi argumentami
W środowisku uruchomieniowym usługi Service Fabric w wersji 6.2 lub nowszej można uruchomić demona platformy Docker z niestandardowymi argumentami. Jeśli określono niestandardowe argumenty, usługa Service Fabric nie przekaże żadnego innego argumentu do aparatu platformy Docker z wyjątkiem argumentu --pidfile. Dlatego nie należy przekazywać elementu --pidfile jako argumentu. Ponadto argument powinien nadal mieć włączone nasłuchiwanie przez demona platformy Docker w domyślnym potoku nazw w systemie Windows (lub w gnieździe domeny systemu Unix w systemie Linux), aby umożliwić komunikację usługi Service Fabric z demonem. Niestandardowe argumenty są określone w manifeście klastra w sekcji Hosting w obszarze ContainerServiceArguments. Przykład przedstawiono w następującym fragmencie kodu:
{
"name": "Hosting",
"parameters": [
{
"name": "ContainerServiceArguments",
"value": "-H localhost:1234 -H unix:///var/run/docker.sock"
}
]
}
Następne kroki
- Dowiedz się więcej o uruchamianiu kontenerów w usłudze Service Fabric.
- Zapoznaj się z samouczkiem Deploy a .NET application in a container (Wdrażanie aplikacji .NET w kontenerze).
- Uzyskaj informacje o cyklu życia aplikacji usługi Service Fabric.
- Sprawdź przykłady kodu kontenera usługi Service Fabric w witrynie GitHub.