Udostępnij za pośrednictwem

Wdrożenie serwera DevOps dla usługi Azure Logic Apps z jedną dzierżawą

  • Artykuł

Dotyczy: Azure Logic Apps (wersja Standardowa)

Wraz z trendem w kierunku rozproszonych i natywnych aplikacji 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 pewniej przy użyciu 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 usługi Azure Logic Apps z jedną dzierżawą.

Jedna 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 (ARM), które łączą i obsługują aprowizowanie zasobów dla aplikacji logiki 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 aplikacjami i infrastrukturą.

Podczas tworzenia aplikacji logiki przy użyciu typu zasobu Aplikacja logiki (Standardowa) przepływy pracy są obsługiwane przez przeprojektowane jednodostępne środowisko uruchomieniowe usługi Azure Logic Apps. To środowisko uruchomieniowe używa rozszerzalności modelu rozszerzalności Azure Functions i jest hostowane jako rozszerzenie w środowisku uruchomieniowym Azure Functions. Ten projekt zapewnia przenośność, elastyczność i większą wydajność aplikacji logiki oraz inne możliwości i korzyści dziedziczone z platformy Azure Functions i ekosystemu Azure App Service.

Na przykład można spakować przeprojektowane środowisko uruchomieniowe konteneryzowane i przepływy pracy razem w ramach aplikacji logiki. Możesz użyć ogólnych kroków lub zadań, które kompilują, składają i pakują zasoby aplikacji logiki do gotowych do wdrożenia artefaktów. Aby wdrożyć aplikacje, 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ć 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 używać 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 funkcji i korzysta z platformy Azure Functions i ekosystemu Azure App Service. Te aktualizacje obejmują zupełnie nowy model wdrażania i więcej sposobów używania metodyki DevOps na potrzeby przepływów pracy aplikacji logiki.

Lokalne programowanie i testowanie

Jeśli używasz Visual Studio Code z rozszerzeniem usługi Azure Logic Apps (standard), możesz lokalnie opracowywać, kompilować i uruchamiać przepływy pracy aplikacji logiki opartej na jednej dzierżawie w środowisku deweloperów bez konieczności wdrażania na platformie Azure. Jeśli twój 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 główną poprawą i zapewnia znaczną korzyść w porównaniu z modelem wielodostępnym, który wymaga opracowania w odniesieniu do istniejącego i uruchomionego zasobu na platformie Azure.

Oddzielne problemy

Model z jedną dzierżawą umożliwia oddzielenie problemów między aplikacją a podstawową infrastrukturą. Możesz na przykład tworzyć, 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.

Diagram koncepcyjny przedstawiający oddzielne potoki wdrażania dla aplikacji i infrastruktury.

Struktura zasobów aplikacji logiki

W modelu usługi Azure Logic Apps z wieloma dzierżawami 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 rozważane i przywoływane 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 nawzajem. Ta struktura zasobów wygląda i działa podobnie do 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 Azure Functions, które można zwykle zastosować do usługi Azure Logic Apps z jedną dzierżawą.

Struktura projektu aplikacji logiki

W 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
  • Oparty na pakietach NuGet (.NET), który można przekonwertować na podstawie typu domyślnego

Na podstawie tych typów projekt zawiera nieco inne foldery i pliki. Projekt oparty na programie NuGet zawiera folder .bin, który zawiera 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 korzystanie z narzędzia NuGet, zobacz Włączanie tworzenia wbudowanych łączników.

W przypadku domyślnego projektu opartego na pakietach 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:

Nazwa Folder lub plik Opis
.vscode Folder Zawiera pliki ustawień związanych z Visual Studio Code, takie jak extensions.json, launch.json, settings.json i tasks.json.
Artifacts Folder Zawiera artefakty konta integracji, które są definiowane i używane w przepływach pracy, które obsługują scenariusze 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, który zawiera podstawową definicję JSON tego przepływu pracy.
czas projektowania przepływu pracy Folder Zawiera pliki ustawień związanych ze środowiskiem projektowym.
.funcignore Plik Zawiera informacje dotyczące zainstalowanych narzędzi 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 platformy Azure Logic Apps z jedną dzierżawą, aplikacje logiki, przepływy pracy, wyzwalacze i akcje. 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 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, zostanie wyświetlony następujący błąd:

Microsoft.Azure.WebJobs.Script.WebHost: Repository has more than 10 non-decryptable secrets backups (host))

Aby rozwiązać ten problem, 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, gdzie można uruchamiać kontenery. Po konteneryzacji aplikacji wdrożenie działa głównie tak samo jak w przypadku każdego innego kontenera, którym wdrażasz i zarządzasz.

Aby zapoznać się z przykładami obejmującymi usługę Azure DevOps, zapoznaj się z artykułem 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ń i parametrów aplikacji, aby nie trzeba było ich ponownie wdrażać tak często.

Łączniki zarządzane i wbudowane operacje

Ekosystem usługi Azure Logic Apps udostępnia setki łączników zarządzanych przez firmę Microsoft i 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 te łączniki i wbudowane operacje, pozostają w większości takie same w usłudze Azure Logic Apps z jedną dzierżawą.

Najważniejszym ulepszeniem jest to, że usługa z jedną dzierżawą udostępnia bardziej popularne łączniki zarządzane również jako wbudowane operacje. Można na przykład używać wbudowanych operacji dla Azure Service Bus, Azure Event Hubs, SQL i innych. W międzyczasie wersje łącznika zarządzanego są nadal dostępne i nadal działają.

Połączenia tworzone przy użyciu wbudowanych operacji są nazywane połączeniami wbudowanymi lub połączeniami 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 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 bliskość 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 do tego samego artefaktu kompilacji.

W Visual Studio Code, gdy używasz projektanta do opracowywania lub wprowadzania zmian w przepływach pracy, aparat usługi Logic Apps 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

W przypadku korzystania z 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 działające w tym samym procesie co przepływ pracy. Ta infrastruktura połączenia jest hostowana i zarządzana jako część zasobu aplikacji logiki, a ustawienia aplikacji przechowują parametry połączenia dla każdej wbudowanej operacji dostawcy usług używanej przez przepływy pracy.

W projekcie aplikacji logiki każdy przepływ pracy zawiera plik workflow.json zawierający podstawową definicję JSON przepływu pracy. Ta definicja przepływu pracy odwołuje się następnie do niezbędnych parametrów połączenia w pliku connections.json projektu.

W poniższym przykładzie pokazano, jak połączenie dostawcy usług dla wbudowanej operacji usługi Service Bus jest wyświetlane 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 Visual Studio Code podczas tworzenia i opracowywania przepływu pracy przy użyciu projektanta aparat usługi Logic Apps 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.

W poniższym przykładzie pokazano, jak połączenie interfejsu API dla zarządzanego łącznika usługi Service Bus jest wyświetlane 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 Azure Functions

Aby wywołać funkcje utworzone i hostowane w Azure Functions, należy użyć wbudowanej operacji Azure Functions. Metadane połączenia dla wywołań Azure Functions różnią się od innych wbudowanych połączeń. Te metadane są przechowywane w pliku connections.json projektu aplikacji logiki, ale wygląda 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}"
   },
   <...>
}

Authentication

W usłudze Azure Logic Apps z jedną dzierżawą model hostingu przepływów pracy aplikacji logiki jest jedną dzierżawą, 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 Visual Studio Code. Mimo to ten projekt wymaga sposobu uwierzytelniania tożsamości przez aplikacje logiki, aby mogły uzyskiwać dostęp do ekosystemu łączników zarządzanych 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 parametrów połączenia używanych do tworzenia połączenia. W czasie wykonywania aplikacja logiki używa tej tożsamości do uwierzytelniania połączeń za pośrednictwem zasad dostępu platformy Azure. Jeśli ta tożsamość zostanie wyłączona, 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 hostowanej i uruchamianej 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 zarządzany połączenie ma authentication obiekt określający ManagedServiceIdentity typ uwierzytelniania:

"authentication": {
   "type": "ManagedServiceIdentity"
}

Nieprzetworzone

W przypadku aplikacji logiki uruchamianych w lokalnym środowisku projektowym przy użyciu Visual Studio Code klucze uwierzytelniania pierwotnego 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 zarządzany połączenie ma authentication obiekt określający następujące informacje dotyczące uwierzytelniania:

"authentication": {
   "type": "Raw", 
   "scheme": "Key", 
   "parameter": "@appsetting('connectionKey')"
 }

Następne kroki