Wdrażanie metodyki DevOps dla aplikacji logiki w warstwie Standardowa w usłudze Azure Logic Apps z jedną dzierżawą
Dotyczy: Azure Logic Apps (Standardowa)
Dzięki trendowi w przypadku aplikacji rozproszonych i natywnych w chmurze organizacje mają do czynienia z bardziej rozproszonymi składnikami w wielu środowiskach. Aby zachować kontrolę i spójność, możesz zautomatyzować środowiska i wdrożyć więcej składników szybciej i bezpieczniej, korzystając z narzędzi i procesów DevOps.
Ten artykuł zawiera wprowadzenie i omówienie bieżącego środowiska ciągłej integracji i ciągłego wdrażania (CI/CD) dla standardowych przepływów pracy aplikacji logiki w usłudze Azure Logic Apps z jedną dzierżawą.
Pojedyncza dzierżawa a wiele dzierżaw
W wielodostępnej usłudze Azure Logic Apps wdrażanie zasobów jest oparte na szablonach usługi Azure Resource Manager (szablonach usługi ARM), które łączą i obsługują aprowizowanie zasobów zarówno dla zasobów aplikacji logiki Zużycie, jak i infrastruktury. W usłudze Azure Logic Apps z jedną dzierżawą wdrażanie staje się łatwiejsze, ponieważ można oddzielić aprowizację zasobów między zasobami standardowej aplikacji logiki i infrastrukturą.
Podczas tworzenia zasobu aplikacji logiki w warstwie Standardowa przepływy pracy są obsługiwane przez przeprojektowane środowisko uruchomieniowe usługi Azure Logic Apps z jedną dzierżawą. To środowisko uruchomieniowe używa modelu rozszerzalności usługi Azure Functions i jest hostowane jako rozszerzenie w środowisku uruchomieniowym usługi Azure Functions. Ten projekt zapewnia przenośność, elastyczność i większą wydajność aplikacji logiki w warstwie Standardowa oraz inne możliwości i korzyści dziedziczone z platformy Azure Functions i ekosystemu usługi aplikacja systemu Azure Service.
Można na przykład spakować przeprojektowane środowisko uruchomieniowe konteneryzowane i przepływy pracy w ramach standardowej aplikacji logiki. Możesz użyć ogólnych kroków lub zadań, które kompilują, składają i spakują zasoby aplikacji logiki do gotowych do wdrożenia artefaktów. Aby wdrożyć standardowe aplikacje logiki, skopiuj artefakty do środowiska hosta, a następnie uruchom aplikacje, aby uruchamiać przepływy pracy. Możesz też zintegrować artefakty z potokami wdrażania przy użyciu narzędzi i procesów, które już znasz i których używasz. Jeśli na przykład scenariusz wymaga kontenerów, możesz konteneryzować standardowe aplikacje logiki i zintegrować je z istniejącymi potokami.
Aby skonfigurować i wdrożyć zasoby infrastruktury, takie jak sieci wirtualne i łączność, możesz nadal korzystać z szablonów usługi ARM i oddzielnie aprowizować te zasoby wraz z innymi procesami i potokami używanymi do tych celów.
Korzystając ze standardowych opcji kompilacji i wdrażania, można skoncentrować się na tworzeniu aplikacji niezależnie od wdrożenia infrastruktury. W związku z tym uzyskasz bardziej ogólny model projektu, w którym można zastosować wiele podobnych lub tych samych opcji wdrażania, które są używane dla aplikacji ogólnej. Możesz również korzystać z bardziej spójnego środowiska tworzenia potoków wdrażania wokół projektów aplikacji oraz uruchamiania wymaganych testów i walidacji przed opublikowaniem w środowisku produkcyjnym. Niezależnie od używanego stosu technologii możesz wdrażać aplikacje logiki przy użyciu własnych wybranych narzędzi.
Możliwości wdrażania metodyki DevOps
Usługa Azure Logic Apps z jedną dzierżawą dziedziczy wiele możliwości i korzyści z platformy Azure Functions i ekosystemu usługi aplikacja systemu Azure Service. Te aktualizacje obejmują zupełnie nowy model wdrażania i więcej sposobów korzystania z metodyki DevOps dla przepływów pracy aplikacji logiki.
Lokalne programowanie i testowanie
Jeśli używasz programu Visual Studio Code z rozszerzeniem usługi Azure Logic Apps (Standard), możesz lokalnie opracowywać, kompilować i uruchamiać standardowe przepływy pracy aplikacji logiki w środowisku projektowym bez konieczności wdrażania na platformie Azure. Jeśli scenariusz wymaga kontenerów, możesz utworzyć i wdrożyć za pomocą usługi Logic Apps z obsługą usługi Azure Arc.
Ta funkcja jest ważną ulepszeniem i zapewnia znaczną korzyść w porównaniu z modelem wielodostępnym, który wymaga opracowania istniejącego i uruchomionego zasobu na platformie Azure.
Oddzielne obawy
Model z jedną dzierżawą umożliwia oddzielenie kwestii między aplikacją logiki a podstawową infrastrukturą. Możesz na przykład opracowywać, kompilować, zip i wdrażać aplikację oddzielnie jako niezmienny artefakt w różnych środowiskach. Przepływy pracy aplikacji logiki zwykle mają "kod aplikacji", który jest aktualizowany częściej niż podstawowa infrastruktura. Oddzielając te warstwy, możesz skupić się bardziej na tworzeniu przepływu pracy aplikacji logiki i poświęcać mniej wysiłku na wdrażanie wymaganych zasobów w wielu środowiskach.
Struktura zasobów aplikacji logiki
W modelu wielodostępnym usługi Azure Logic Apps struktura zasobów aplikacji logiki Zużycie może zawierać tylko jeden przepływ pracy. Ze względu na tę relację "jeden do jednego" zarówno aplikacja logiki, jak i przepływ pracy są często brane pod uwagę i odwołuje się do nich synonimy. Jednak w modelu usługi Azure Logic Apps z jedną dzierżawą struktura zasobów standardowej aplikacji logiki może zawierać wiele przepływów pracy. Ta relacja jeden do wielu oznacza, że w tej samej aplikacji logiki przepływy pracy mogą udostępniać i ponownie używać innych zasobów. Przepływy pracy w tej samej aplikacji logiki i dzierżawie oferują również lepszą wydajność ze względu na tę współdzieloną dzierżawę i bliskość siebie. Ta struktura zasobów wygląda i działa podobnie do usługi Azure Functions, w której aplikacja funkcji może hostować wiele funkcji.
Aby uzyskać więcej informacji i najlepszych rozwiązań dotyczących organizowania przepływów pracy, wydajności i skalowania w aplikacji logiki, zapoznaj się z podobnymi wskazówkami dotyczącymi usługi Azure Functions , które można ogólnie zastosować do usługi Azure Logic Apps z jedną dzierżawą.
Struktura projektu aplikacji logiki
W programie Visual Studio Code projekt aplikacji logiki ma jeden z następujących typów:
- Oparty na pakiecie rozszerzenia (Node.js), który jest typem domyślnym
- Pakiet NuGet (.NET), który można przekonwertować na podstawie typu domyślnego
Na podstawie tych typów projekt zawiera nieco różne foldery i pliki. Projekt oparty na nuGet zawiera folder .bin zawierający pakiety i inne pliki biblioteki. Projekt oparty na pakiecie nie zawiera folderu .bin i innych plików. Niektóre scenariusze wymagają uruchomienia projektu opartego na oprogramowaniu NuGet, na przykład w przypadku tworzenia i uruchamiania niestandardowych operacji wbudowanych. Aby uzyskać więcej informacji na temat konwertowania projektu na używanie narzędzia NuGet, zobacz Włączanie tworzenia wbudowanego łącznika.
W przypadku domyślnego projektu opartego na pakiecie projekt ma strukturę folderów i plików podobną do poniższego przykładu:
MyBundleBasedLogicAppProjectName
| .vscode
| Artifacts
|| Maps
||| MapName1
||| ...
|| Schemas
||| SchemaName1
||| ...
| WorkflowName1
|| workflow.json
|| ...
| WorkflowName2
|| workflow.json
|| ...
| workflow-designtime
| .funcignore
| connections.json
| host.json
| local.settings.json
Na poziomie głównym projektu można znaleźć następujące pliki i foldery z innymi elementami:
| Nazwisko | Folder lub plik | opis |
|---|---|---|
| .vscode | Folder | Zawiera pliki ustawień związanych z programem Visual Studio Code, takie jak pliki extensions.json, launch.json, settings.json i tasks.json. |
| Artefakty | Folder | Zawiera artefakty konta integracji zdefiniowane i używane w przepływach pracy, które obsługują scenariusze biznesowe (B2B). Na przykład przykładowa struktura zawiera mapy i schematy dla operacji przekształcania i walidacji XML. |
| <Nazwa przepływu pracy> | Folder | Dla każdego przepływu pracy <folder WorkflowName> zawiera plik workflow.json zawierający podstawową definicję JSON tego przepływu pracy. |
| czas projektowania przepływu pracy | Folder | Zawiera pliki ustawień środowiska deweloperskiego. |
| .funcignore | Plik | Zawiera informacje związane z zainstalowanymi narzędziami Azure Functions Core Tools. |
| connections.json | Plik | Zawiera metadane, punkty końcowe i klucze dla wszystkich zarządzanych połączeń i funkcji platformy Azure używanych przez przepływy pracy. Ważne: Aby używać różnych połączeń i funkcji dla każdego środowiska, upewnij się, że sparametryzujesz ten plik connections.json i zaktualizuj punkty końcowe. |
| host.json | Plik | Zawiera ustawienia i wartości konfiguracji specyficzne dla środowiska uruchomieniowego, na przykład domyślne limity dla pojedynczej dzierżawy platformy Azure Logic Apps, aplikacji logiki, przepływów pracy, wyzwalaczy i akcji. Na poziomie głównym projektu aplikacji logiki plik metadanych host.json zawiera ustawienia konfiguracji i wartości domyślne używane przez wszystkie przepływy pracy w tej samej aplikacji logiki podczas uruchamiania, zarówno lokalnie, jak i na platformie Azure. Uwaga: podczas tworzenia aplikacji logiki program Visual Studio Code tworzy plik host.snapshot.*.json w kontenerze magazynu. Jeśli usuniesz aplikację logiki, ten plik kopii zapasowej nie zostanie usunięty. Jeśli tworzysz inną aplikację logiki o tej samej nazwie, zostanie utworzony inny plik migawki. Dla tej samej aplikacji logiki można mieć maksymalnie 10 migawek. Jeśli przekroczysz ten limit, wystąpi następujący błąd: Microsoft.Azure.WebJobs.Script.WebHost: Repository has more than 10 non-decryptable secrets backups (host)) Aby rozwiązać ten błąd, usuń dodatkowe pliki migawek z kontenera magazynu. |
| local.settings.json | Plik | Zawiera ustawienia aplikacji, parametry połączenia i inne ustawienia używane przez przepływy pracy podczas uruchamiania lokalnego. Innymi słowy, te ustawienia i wartości mają zastosowanie tylko w przypadku uruchamiania projektów w lokalnym środowisku projektowym. Podczas wdrażania na platformie Azure plik i ustawienia są ignorowane i nie są uwzględniane we wdrożeniu. Ten plik przechowuje ustawienia i wartości jako lokalne zmienne środowiskowe, które są używane przez lokalne narzędzia programistyczne jako appSettings wartości. Te zmienne środowiskowe można wywoływać i odwoływać się do nich zarówno w czasie wykonywania, jak i w czasie wdrażania przy użyciu ustawień aplikacji i parametrów. Ważne: plik local.settings.json może zawierać wpisy tajne, dlatego upewnij się, że ten plik został również wyklucz z kontroli źródła projektu. |
Wdrażanie kontenera
Usługa Azure Logic Apps z jedną dzierżawą obsługuje wdrażanie w kontenerach, co oznacza, że można konteneryzować przepływy pracy aplikacji logiki i uruchamiać je, w których można uruchamiać kontenery. Po konteneryzacji aplikacji wdrożenie działa głównie tak samo jak w przypadku każdego innego kontenera wdrażanego i zarządzanego.
Przykłady obejmujące usługę Azure DevOps można znaleźć w artykule Ciągła integracja/ciągłe wdrażanie dla kontenerów.
Ustawienia i parametry aplikacji
W wielodostępnej usłudze Azure Logic Apps szablony usługi ARM stanowią wyzwanie, gdy trzeba zachować zmienne środowiskowe dla aplikacji logiki w różnych środowiskach deweloperskich, testowych i produkcyjnych. Wszystko w szablonie usługi ARM jest definiowane we wdrożeniu. Jeśli musisz zmienić tylko jedną zmienną, musisz ponownie wdrożyć wszystko.
W usłudze Azure Logic Apps z jedną dzierżawą można wywoływać zmienne środowiskowe i odwoływać się do niego w czasie wykonywania przy użyciu ustawień aplikacji i parametrów, aby nie trzeba było ich ponownie wdrażać tak często.
Zarządzane łączniki i wbudowane operacje
Ekosystem usługi Azure Logic Apps udostępnia ponad 1000 łączników zarządzanych przez firmę Microsoft i hostowanych na platformie Azure oraz wbudowanych operacji w ramach stale rosnącej kolekcji, której można używać w usłudze Azure Logic Apps z jedną dzierżawą. Sposób, w jaki firma Microsoft utrzymuje zarządzane łączniki, pozostaje w większości taki sam w usłudze Azure Logic Apps z jedną dzierżawą co w wielodostępnej usłudze Azure Logic Apps.
Najważniejszą poprawą jest to, że usługa z jedną dzierżawą udostępnia bardziej popularne łączniki zarządzane jako wbudowane operacje. Można na przykład użyć wbudowanych operacji dla usług Azure Service Bus, Azure Event Hubs, SQL i wielu innych. W międzyczasie wersje łącznika zarządzanego są nadal dostępne i nadal działają.
Połączenia tworzone przy użyciu wbudowanych operacji opartych na usłudze platformy Azure są nazywane połączeniami wbudowanymi lub połączeniami opartymi na dostawcy usług. Wbudowane operacje i ich połączenia są uruchamiane lokalnie w tym samym procesie, który uruchamia przepływy pracy. Oba są hostowane w przeprojektowanych środowiskach uruchomieniowych usługi Azure Logic Apps. Natomiast połączenia zarządzane lub połączenia interfejsu API są tworzone i uruchamiane oddzielnie jako zasoby platformy Azure, które są wdrażane przy użyciu szablonów usługi ARM. W rezultacie wbudowane operacje i ich połączenia zapewniają lepszą wydajność ze względu na ich bliskość do przepływów pracy. Ten projekt działa również dobrze w przypadku potoków wdrażania, ponieważ połączenia dostawcy usług są pakowane w ten sam artefakt kompilacji.
W programie Visual Studio Code, gdy używasz projektanta do opracowywania lub wprowadzania zmian w przepływach pracy, aparat usługi Azure Logic Apps z jedną dzierżawą automatycznie generuje wszelkie niezbędne metadane połączenia w pliku connections.json projektu. W poniższych sekcjach opisano trzy rodzaje połączeń, które można utworzyć w przepływach pracy. Każdy typ połączenia ma inną strukturę JSON, co jest ważne, ponieważ punkty końcowe zmieniają się podczas przechodzenia między środowiskami.
Połączenia dostawcy usług
Jeśli używasz wbudowanej operacji dla usługi, takiej jak Azure Service Bus lub Azure Event Hubs w usłudze Azure Logic Apps z jedną dzierżawą, należy utworzyć połączenie dostawcy usług, które działa w tym samym procesie co przepływ pracy. Ta infrastruktura połączeń jest hostowana i zarządzana w ramach zasobu aplikacji logiki, a ustawienia aplikacji przechowują parametry połączenia dla dowolnej wbudowanej operacji dostawcy usług używanej przez przepływy pracy.
Ważne
Jeśli masz poufne informacje, takie jak parametry połączenia zawierające nazwy użytkowników i hasła, upewnij się, że jest dostępny najbezpieczniejszy przepływ uwierzytelniania. Na przykład firma Microsoft zaleca uwierzytelnienie dostępu do zasobów platformy Azure przy użyciu tożsamości zarządzanej, gdy jest dostępna pomoc techniczna, i przypisanie roli, która ma najmniej wymagane uprawnienia.
Jeśli ta funkcja jest niedostępna, upewnij się, że zabezpieczasz parametry połączenia za pomocą innych miar, takich jak usługa Azure Key Vault, której można używać z ustawieniami aplikacji. Następnie można bezpośrednio odwoływać się do bezpiecznych ciągów, takich jak parametry połączenia i klucze. Podobnie jak w przypadku szablonów usługi ARM, gdzie można zdefiniować zmienne środowiskowe w czasie wdrażania, można zdefiniować ustawienia aplikacji w definicji przepływu pracy aplikacji logiki. Następnie można przechwytywać dynamicznie generowane wartości infrastruktury, takie jak punkty końcowe połączenia, parametry magazynu i inne. Aby uzyskać więcej informacji, zobacz Typy aplikacji dla Platforma tożsamości Microsoft.
W projekcie aplikacji logiki w warstwie Standardowa każdy przepływ pracy ma plik workflow.json zawierający podstawową definicję JSON przepływu pracy. Ta definicja przepływu pracy odwołuje się następnie do niezbędnych parametry połączenia w pliku connections.json projektu.
Poniższy przykład przedstawia sposób wyświetlania wbudowanej operacji dostawcy usług dla wbudowanej operacji usługi Azure Service Bus w pliku connections.json projektu:
"serviceProviderConnections": {
"{service-bus-connection-name}": {
"parameterValues": {
"connectionString": "@appsetting('servicebus_connectionString')"
},
"serviceProvider": {
"id": "/serviceProviders/serviceBus"
},
"displayName": "{service-bus-connection-name}"
},
<...>
}
Połączenia zarządzane
Gdy używasz łącznika zarządzanego po raz pierwszy w przepływie pracy, zostanie wyświetlony monit o utworzenie zarządzanego połączenia interfejsu API dla usługi docelowej lub systemu i uwierzytelnienie tożsamości. Te łączniki są zarządzane przez ekosystem łączników udostępnionych na platformie Azure. Połączenia interfejsu API istnieją i działają jako oddzielne zasoby na platformie Azure.
W programie Visual Studio Code podczas tworzenia i opracowywania przepływu pracy przy użyciu projektanta aparat usługi Azure Logic Apps z jedną dzierżawą automatycznie tworzy niezbędne zasoby na platformie Azure dla łączników zarządzanych w przepływie pracy. Aparat automatycznie dodaje te zasoby połączenia do grupy zasobów platformy Azure, która została zaprojektowana tak, aby zawierała aplikację logiki.
Poniższy przykład przedstawia sposób wyświetlania połączenia interfejsu API dla łącznika zarządzanego usługi Azure Service Bus w pliku connections.json projektu:
"managedApiConnections": {
"{service-bus-connection-name}": {
"api": {
"id": "/subscriptions/{subscription-ID}/providers/Microsoft.Web/locations/{region}/managedApis/servicebus"
},
"connection": {
"id": "/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Web/connections/servicebus"
},
"connectionRuntimeUrl": "{connection-runtime-URL}",
"authentication": {
"type": "Raw",
"scheme": "Key",
"parameter": "@appsetting('servicebus_1-connectionKey')"
},
},
<...>
}
Połączenia usługi Azure Functions
Aby wywołać funkcje utworzone i hostowane w usłudze Azure Functions, należy użyć wbudowanej operacji usługi Azure Functions. Metadane połączenia dla wywołań usługi Azure Functions różnią się od innych wbudowanych połączeń. Te metadane są przechowywane w pliku connections.json projektu aplikacji logiki, ale wyglądają inaczej:
"functionConnections": {
"{function-operation-name}": {
"function": {
"id": "/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Web/sites/{function-app-name}/functions/{function-name}"
},
"triggerUrl": "{function-url}",
"authentication": {
"type": "QueryString",
"name": "Code",
"value": "@appsetting('azureFunctionOperation_functionAppKey')"
},
"displayName": "{functions-connection-display-name}"
},
<...>
}
Uwierzytelnianie
W usłudze Azure Logic Apps z jedną dzierżawą model hostingu dla przepływów pracy aplikacji logiki jest jedną dzierżawą firmy Microsoft Entra, w której obciążenia korzystają z większej izolacji niż w modelu wielodostępnym. Ponadto środowisko uruchomieniowe usługi Azure Logic Apps z jedną dzierżawą jest przenośne, co oznacza, że możesz uruchamiać przepływy pracy w innych środowiskach, na przykład lokalnie w programie Visual Studio Code. Mimo to ten projekt wymaga sposobu uwierzytelniania tożsamości przez aplikacje logiki, aby mogły uzyskiwać dostęp do ekosystemu łącznika zarządzanego na platformie Azure. Aplikacje wymagają również odpowiednich uprawnień do uruchamiania operacji podczas korzystania z połączeń zarządzanych.
Domyślnie każda aplikacja logiki oparta na jednej dzierżawie ma automatycznie włączoną tożsamość zarządzaną przypisaną przez system. Ta tożsamość różni się od poświadczeń uwierzytelniania lub parametry połączenia używanych do tworzenia połączenia. W czasie wykonywania aplikacja logiki używa tej tożsamości do uwierzytelniania połączeń za pomocą zasad dostępu platformy Azure. Jeśli wyłączysz tę tożsamość, połączenia nie będą działać w czasie wykonywania.
Poniższe sekcje zawierają więcej informacji na temat typów uwierzytelniania, których można użyć do uwierzytelniania połączeń zarządzanych w zależności od tego, gdzie działa aplikacja logiki. Dla każdego połączenia zarządzanego plik connections.json projektu aplikacji logiki ma authentication obiekt określający typ uwierzytelniania, którego aplikacja logiki może użyć do uwierzytelniania tego połączenia zarządzanego.
Tożsamość zarządzana
W przypadku aplikacji logiki, która jest hostowana i uruchamiana na platformie Azure, tożsamość zarządzana jest domyślnym i zalecanym typem uwierzytelniania używanym do uwierzytelniania połączeń zarządzanych hostowanych i uruchamianych na platformie Azure. W pliku connections.json projektu aplikacji logiki połączenie zarządzane ma authentication obiekt określający ManagedServiceIdentity typ uwierzytelniania:
"authentication": {
"type": "ManagedServiceIdentity"
}
Nieprzetworzone
W przypadku aplikacji logiki uruchamianych w lokalnym środowisku programistycznym przy użyciu programu Visual Studio Code nieprzetworzone klucze uwierzytelniania są używane do uwierzytelniania połączeń zarządzanych hostowanych i uruchamianych na platformie Azure. Te klucze są przeznaczone tylko do użytku programistycznego, a nie produkcyjnego i mają 7-dniowe wygaśnięcie. W pliku connections.json projektu aplikacji logiki połączenie zarządzane ma authentication obiekt określający następujące informacje dotyczące uwierzytelniania:
"authentication": {
"type": "Raw",
"scheme": "Key",
"parameter": "@appsetting('connectionKey')"
}