Tworzenie pakietu aplikacji

W tym artykule opisano sposób tworzenia pakietu aplikacji usługi Service Fabric i przygotowania jej do wdrożenia.

Układ pakietu

Manifest aplikacji, co najmniej jeden manifest usługi i inne niezbędne pliki pakietu muszą być zorganizowane w określonym układzie do wdrożenia w klastrze usługi Service Fabric. Przykładowe manifesty w tym artykule muszą być zorganizowane w następującej strukturze katalogów:

tree /f .\MyApplicationType

D:\TEMP\MYAPPLICATIONTYPE
│   ApplicationManifest.xml
│
└───MyServiceManifest
    │   ServiceManifest.xml
    │
    ├───MyCode
    │       MyServiceHost.exe
    │
    ├───MyConfig
    │       Settings.xml
    │
    └───MyData
            init.dat

Foldery są nazwane tak, aby odpowiadały atrybutom nazwy każdego odpowiedniego elementu. Jeśli na przykład manifest usługi zawierał dwa pakiety kodu o nazwach MyCodeA i MyCodeB, dwa foldery o tych samych nazwach będą zawierać niezbędne pliki binarne dla każdego pakietu kodu.

Korzystanie z setupEntryPoint

Typowe scenariusze korzystania z programu SetupEntryPoint są sytuacje, w których należy uruchomić plik wykonywalny przed uruchomieniem usługi lub wykonać operację z podwyższonym poziomem uprawnień. Na przykład:

• Konfigurowanie i inicjowanie zmiennych środowiskowych, których potrzebuje plik wykonywalny usługi. Nie ogranicza się tylko do plików wykonywalnych napisanych za pośrednictwem modeli programowania usługi Service Fabric. Na przykład npm.exe wymaga pewnych zmiennych środowiskowych skonfigurowanych do wdrażania aplikacji Node.js.
• Konfigurowanie kontroli dostępu przez zainstalowanie certyfikatów zabezpieczeń.

Aby uzyskać więcej informacji na temat konfigurowania programu SetupEntryPoint, zobacz Konfigurowanie zasad dla punktu wejścia konfiguracji usługi

Konfiguruj

Tworzenie pakietu przy użyciu programu Visual Studio

Jeśli do utworzenia aplikacji użyto programu Visual Studio, możesz użyć polecenia Pakiet , aby automatycznie utworzyć pakiet zgodny z układem opisanym powyżej.

Aby utworzyć pakiet, kliknij prawym przyciskiem myszy projekt aplikacji w Eksplorator rozwiązań i wybierz polecenie Pakiet:

Po zakończeniu tworzenia pakietów można znaleźć lokalizację pakietu w oknie Dane wyjściowe . Krok pakowania odbywa się automatycznie podczas wdrażania lub debugowania aplikacji w programie Visual Studio.

Tworzenie pakietu według wiersza polecenia

Istnieje również możliwość programowego spakowania aplikacji przy użyciu polecenia msbuild.exe. Pod maską program Visual Studio jest uruchomiony, więc dane wyjściowe są takie same.

D:\Temp> msbuild HelloWorld.sfproj /t:Package

Testowanie pakietu

Strukturę pakietów można sprawdzić lokalnie za pomocą programu PowerShell, używając polecenia Test-ServiceFabricApplicationPackage . To polecenie sprawdza problemy z analizowaniem manifestu i weryfikuje wszystkie odwołania. To polecenie weryfikuje tylko poprawność strukturalną katalogów i plików w pakiecie. Nie weryfikuje żadnej zawartości kodu ani pakietu danych poza sprawdzeniem, czy istnieją wszystkie niezbędne pliki.

Test-ServiceFabricApplicationPackage .\MyApplicationType

False
Test-ServiceFabricApplicationPackage : The EntryPoint MySetup.bat is not found.
FileName: C:\Users\servicefabric\AppData\Local\Temp\TestApplicationPackage_7195781181\nrri205a.e2h\MyApplicationType\MyServiceManifest\ServiceManifest.xml

Ten błąd pokazuje, że w pakiecie kodu brakuje pliku MySetup.bat , do którego odwołuje się plik w manifeście usługi SetupEntryPoint . Po dodaniu brakującego pliku weryfikacja aplikacji przejdzie pomyślnie:

tree /f .\MyApplicationType

D:\TEMP\MYAPPLICATIONTYPE
│   ApplicationManifest.xml
│
└───MyServiceManifest
    │   ServiceManifest.xml
    │
    ├───MyCode
    │       MyServiceHost.exe
    │       MySetup.bat
    │
    ├───MyConfig
    │       Settings.xml
    │
    └───MyData
            init.dat

Test-ServiceFabricApplicationPackage .\MyApplicationType

True

Jeśli aplikacja ma zdefiniowane parametry aplikacji, możesz przekazać je w pliku Test-ServiceFabricApplicationPackage w celu prawidłowego sprawdzenia poprawności.

Jeśli znasz klaster, w którym zostanie wdrożona aplikacja, zaleca się przekazanie parametru ImageStoreConnectionString . W takim przypadku pakiet jest również weryfikowany względem poprzednich wersji aplikacji, które są już uruchomione w klastrze. Na przykład walidacja może wykryć, czy pakiet z tą samą wersją, ale inna zawartość została już wdrożona.

Po poprawnym spakowaniu aplikacji i zakończeniu walidacji rozważ skompresowanie pakietu w celu przyspieszenia operacji wdrażania.

Kompresowanie pakietu

Gdy pakiet jest duży lub zawiera wiele plików, możesz go skompresować w celu szybszego wdrożenia. Kompresja zmniejsza liczbę plików i rozmiar pakietu. W przypadku skompresowanego pakietu aplikacji przekazywanie pakietu aplikacji może trwać dłużej w porównaniu z przekazywaniem nieskompresowanego pakietu, zwłaszcza jeśli kompresja jest wykonywana w ramach kopiowania. Dzięki kompresji rejestrowanie i wyrejestrowywanie typu aplikacji jest szybsze.

Mechanizm wdrażania jest taki sam w przypadku skompresowanych i nieskompresowanych pakietów. Jeśli pakiet jest skompresowany, jest przechowywany jako taki w magazynie obrazów klastra i jest on nieskompresowany w węźle przed uruchomieniem aplikacji. Kompresja zastępuje prawidłowy pakiet usługi Service Fabric skompresowaną wersją. Folder musi zezwalać na uprawnienia do zapisu. Uruchamianie kompresji na już skompresowanym pakiecie nie daje żadnych zmian.

Pakiet można skompresować, uruchamiając polecenie programu PowerShell Copy-ServiceFabricApplicationPackage z przełącznikiem CompressPackage . Pakiet można usunąć z tego samego polecenia przy użyciu UncompressPackage przełącznika.

Następujące polecenie kompresuje pakiet bez kopiowania go do magazynu obrazów. W razie potrzeby można skopiować skompresowany pakiet do co najmniej jednego klastra usługi Service Fabric przy użyciu polecenia Copy-ServiceFabricApplicationPackage bez flagi SkipCopy . Pakiet zawiera teraz spakowane pliki dla codepakietów , configi data . Manifest aplikacji i manifesty usługi nie są spakowane, ponieważ są one wymagane w przypadku wielu operacji wewnętrznych. Na przykład udostępnianie pakietów, nazwa typu aplikacji i wyodrębnianie wersji dla niektórych weryfikacji muszą mieć dostęp do manifestów. Spakowanie manifestów spowoduje, że te operacje będą nieefektywne.

tree /f .\MyApplicationType

D:\TEMP\MYAPPLICATIONTYPE
│   ApplicationManifest.xml
│
└───MyServiceManifest
    │   ServiceManifest.xml
    │
    ├───MyCode
    │       MyServiceHost.exe
    │       MySetup.bat
    │
    ├───MyConfig
    │       Settings.xml
    │
    └───MyData
            init.dat

Copy-ServiceFabricApplicationPackage -ApplicationPackagePath .\MyApplicationType -CompressPackage -SkipCopy
tree /f .\MyApplicationType

D:\TEMP\MYAPPLICATIONTYPE
│   ApplicationManifest.xml
│
└───MyServiceManifest
       ServiceManifest.xml
       MyCode.zip
       MyConfig.zip
       MyData.zip

Alternatywnie możesz skompresować i skopiować pakiet za pomocą polecenia Copy-ServiceFabricApplicationPackage w jednym kroku. Jeśli pakiet jest duży, podaj wystarczająco duży limit czasu, aby umożliwić czas zarówno kompresji pakietu, jak i przekazywania do klastra.

Copy-ServiceFabricApplicationPackage -ApplicationPackagePath .\MyApplicationType -ApplicationPackagePathInImageStore MyApplicationType -ImageStoreConnectionString fabric:ImageStore -CompressPackage -TimeoutSec 5400

Wewnętrznie usługa Service Fabric oblicza sumy kontrolne pakietów aplikacji na potrzeby walidacji. W przypadku korzystania z kompresji sumy kontrolne są obliczane na spakowanych wersjach każdego pakietu. Generowanie nowego pliku zip z tego samego pakietu aplikacji powoduje utworzenie różnych sum kontrolnych. Aby zapobiec błędom walidacji, użyj aprowizacji różnic. W przypadku tej opcji nie dołączaj niezmienionych pakietów do nowej wersji. Zamiast tego należy odwoływać się do nich bezpośrednio z nowego manifestu usługi.

Jeśli aprowizacja różnic nie jest opcją i należy uwzględnić pakiety, wygeneruj nowe wersje dla codepakietów , configi data , aby uniknąć niezgodności sumy kontrolnej. Generowanie nowych wersji dla niezmienionych pakietów jest konieczne, gdy jest używany skompresowany pakiet, niezależnie od tego, czy poprzednia wersja używa kompresji, czy nie.

Pakiet jest teraz poprawnie spakowany, zweryfikowany i skompresowany (w razie potrzeby), więc jest gotowy do wdrożenia w co najmniej jednym klastrze usługi Service Fabric.

Kompresuj pakiety podczas wdrażania przy użyciu programu Visual Studio

Możesz poinstruować program Visual Studio, aby kompresował pakiety podczas wdrażania, dodając CopyPackageParameters element do profilu publikowania i ustawiając CompressPackage atrybut na true.

    <PublishProfile xmlns="http://schemas.microsoft.com/2015/05/fabrictools">
        <ClusterConnectionParameters ConnectionEndpoint="mycluster.westus.cloudapp.azure.com" />
        <ApplicationParameterFile Path="..\ApplicationParameters\Cloud.xml" />
        <CopyPackageParameters CompressPackage="true"/>
    </PublishProfile>

Tworzenie sfpkg

Począwszy od wersji 6.1, usługa Service Fabric umożliwia aprowizację z magazynu zewnętrznego. W przypadku tej opcji pakiet aplikacji nie musi być kopiowany do magazynu obrazów. Zamiast tego możesz utworzyć sfpkg plik i przekazać go do magazynu zewnętrznego, a następnie podać identyfikator URI pobierania do usługi Service Fabric podczas aprowizacji. Ten sam pakiet można aprowizować w wielu klastrach. Aprowizowanie z magazynu zewnętrznego pozwala zaoszczędzić czas potrzebny na skopiowanie pakietu do każdego klastra.

Plik sfpkg jest plikiem zip zawierającym początkowy pakiet aplikacji i ma rozszerzenie .sfpkg. Wewnątrz pliku zip pakiet aplikacji może być skompresowany lub nieskompresowany. Kompresja pakietu aplikacji wewnątrz pliku zip jest wykonywana na poziomach kodu, konfiguracji i pakietu danych, jak wspomniano wcześniej.

Aby utworzyć sfpkg plik, zacznij od folderu zawierającego oryginalny pakiet aplikacji, skompresowany lub nie. Następnie użyj dowolnego narzędzia, aby spakować folder z rozszerzeniem ".sfpkg". Na przykład użyj pliku ZipFile.CreateFromDirectory.

ZipFile.CreateFromDirectory(appPackageDirectoryPath, sfpkgFilePath);

Element sfpkg musi zostać przekazany do zewnętrznego magazynu poza usługą Service Fabric. Magazyn zewnętrzny może być dowolnym magazynem, który uwidacznia punkt końcowy REST http lub https. Podczas aprowizacji usługa Service Fabric wykonuje operację GET w celu pobrania sfpkg pakietu aplikacji, więc sklep musi zezwolić na dostęp do odczytu dla pakietu.

Aby aprowizować pakiet, użyj aprowizacji zewnętrznej, która wymaga identyfikatora URI pobierania i informacji o typie aplikacji.

Uwaga

Aprowizowanie na podstawie ścieżki względnej magazynu obrazów nie obsługuje sfpkg obecnie plików. W związku z tym nie należy kopiować elementu sfpkg do magazynu obrazów.

Następne kroki

Wdrażanie i usuwanie aplikacji opisuje sposób używania programu PowerShell do zarządzania wystąpieniami aplikacji

Zarządzanie parametrami aplikacji dla wielu środowisk opisuje sposób konfigurowania parametrów i zmiennych środowiskowych dla różnych wystąpień aplikacji.

Konfigurowanie zasad zabezpieczeń dla aplikacji opisuje sposób uruchamiania usług w ramach zasad zabezpieczeń w celu ograniczenia dostępu.