Omówienie kompleksowej obsługi wdrożeń
Przepływy pracy funkcji GitHub Actions to elastyczne narzędzia, które można skonfigurować na wiele różnych sposobów, aby odpowiadały Twoim potrzebom. W tej lekcji dowiesz się, jak używać przepływów pracy do wdrażania całego rozwiązania, w tym konfigurowania infrastruktury platformy Azure i wykonywania innych operacji wdrażania.
Ile przepływów pracy?
W niektórych organizacjach zespół zarządzający środowiskiem platformy Azure różni się od zespołu, który opracowuje kod uruchamiany w środowisku. W takich sytuacjach często kuszące jest utworzenie wielu przepływów pracy, z których każdy jest własnością zespołu odpowiedzialnego za dany obszar. Możesz na przykład utworzyć jeden przepływ pracy, aby wdrożyć kod Bicep, który wdraża zasoby platformy Azure witryny internetowej, oraz inny przepływ pracy, który wdraża aplikację witryny internetowej.
Mimo że takie podejście może zapewnić pewną elastyczność w sposobie zarządzania przepływami pracy, może to być trudne, aby zachować wszystko w synchronizacji. Załóżmy na przykład, że zespół witryny internetowej potrzebuje nowego ustawienia w swojej aplikacji usługi aplikacja systemu Azure Service, aby umożliwić tworzenie funkcji. Przepływ pracy wdrażania aplikacji nie może działać, dopóki przepływ pracy wdrażania infrastruktury nie zakończy się pomyślnie. Ponadto może to być skomplikowane w przypadku wysyłania danych, takich jak nazwy zasobów platformy Azure utworzonych przez przepływ pracy infrastruktury, między przepływami pracy.
Zamiast tego często lepiej jest utworzyć pojedynczy przepływ pracy, który wdraża wszystkie elementy wymagane dla rozwiązania, nawet jeśli różne zespoły lub różne osoby zarządzają składnikami. Aby koordynować swoją pracę, możesz użyć narzędzi, takich jak Git i GitHub. Po dodaniu nowej funkcji można użyć gałęzi, aby wprowadzić niezbędne zmiany w pliku Bicep. Gdy zmiana jest gotowa do zintegrowania i wydania, pojedynczy przepływ pracy wykonuje wszystkie kroki niezbędne do skompilowania i wdrożenia rozwiązania, co zmniejsza prawdopodobieństwo wylogowania się z synchronizacji.
Napiwek
Podczas kompilowania kodu dla rozwiązania prawdopodobnie trzeba będzie go często wdrażać, aby można było przetestować jego działanie. Może się okazać, że wdrażanie infrastruktury wraz z kodem aplikacji sprawia, że przepływ pracy działa wolno i hamuje postęp.
Jeśli jesteś na tym stanowisku, możesz rozważyć wyłączenie wdrożenia infrastruktury dla środowiska deweloperskiego. Aby to osiągnąć, możesz użyć filtrów ścieżek, przepływów pracy wielokrotnego użytku i warunków. Jednak należy pozostawić pełną sekwencję wdrażania bez zmian dla innych środowisk.
Płaszczyzna sterowania i płaszczyzna danych
Wiele zasobów platformy Azure zapewnia dwa różne płaszczyzny dostępu. Płaszczyzna sterowania wdraża i konfiguruje zasób. Płaszczyzna danych umożliwia dostęp do funkcji zasobu.
Podczas tworzenia i wdrażania plików Bicep można korzystać z płaszczyzny sterowania. Na platformie Azure płaszczyzna sterowania to Azure Resource Manager. Usługa Resource Manager służy do definiowania konfiguracji poszczególnych zasobów.
Jednak przepływ pracy często wymaga więcej niż tylko interakcji z płaszczyzną sterowania. Na przykład może być konieczne:
- Przekaż obiekt blob do konta magazynu.
- Modyfikowanie schematu bazy danych.
- Wywołanie interfejsu API do usługi innej firmy.
- Wyzwalanie aktualizacji modelu uczenia maszynowego.
- Wdróż witrynę internetową w aplikacji usługi aplikacja systemu Azure Service.
- Wdrażanie oprogramowania na maszynie wirtualnej.
- Zarejestruj wpis DNS u dostawcy innej firmy.
W przypadku uwzględnienia kompleksowego przepływu pracy zwykle trzeba wdrożyć zasoby platformy Azure, a następnie wykonać serię operacji na płaszczyznach danych tych zasobów. Czasami te operacje są nazywane ostatnią milą wdrożenia, ponieważ wykonujesz większość wdrożenia przy użyciu płaszczyzny sterowania i pozostaje tylko niewielka ilość konfiguracji.
Uwaga
Niektóre zasoby nie mają wyraźnego podziału między płaszczyzną sterowania a płaszczyzną danych. Należą do nich usługi Azure Data Factory i Azure API Management. Obie usługi obsługują w pełni zautomatyzowane wdrożenia przy użyciu rozwiązania Bicep, ale wymagają one szczególnych zagadnień. Linki do dodatkowych informacji znajdziesz na stronie Podsumowanie na końcu modułu.
Jak wykonywać operacje płaszczyzny danych
Podczas tworzenia przepływu pracy wdrażania, który współdziała z płaszczyzną danych zasobów, można użyć dowolnego z trzech typowych podejść:
- Skrypty wdrażania usługi Resource Manager
- Skrypty przepływu pracy
- Akcje przepływu pracy
Skrypty wdrażania usługi Resource Manager są definiowane w pliku Bicep. Uruchamiają skrypty powłoki Bash lub programu PowerShell i mogą wchodzić w interakcje z poleceniami interfejsu wiersza polecenia platformy Azure i poleceniami cmdlet programu Azure PowerShell. Utworzysz tożsamość zarządzaną dla skryptu wdrażania, który będzie używany do uwierzytelniania na platformie Azure, a platforma Azure automatycznie aprowizuje inne zasoby, których potrzebuje do uruchomienia skryptu wdrażania.
Skrypty wdrażania są dobre, gdy trzeba uruchomić podstawowy skrypt w procesie wdrażania, ale nie zapewniają one łatwego dostępu do innych elementów z przepływu pracy.
Możesz również uruchomić własną logikę z poziomu przepływu pracy wdrażania. Funkcja GitHub Actions udostępnia bogaty ekosystem akcji dla typowych rzeczy, które należy wykonać. Jeśli nie możesz znaleźć akcji spełniającej Twoje potrzeby, możesz użyć skryptu , aby uruchomić własny kod powłoki Bash lub programu PowerShell. Akcje i skrypty przepływu pracy są uruchamiane z poziomu modułu uruchamiającego przepływ pracy. Często musisz uwierzytelnić akcję lub skrypt na płaszczyźnie danych używanej usługi i w jaki sposób jest to zależne od usługi.
Akcje i skrypty przepływu pracy zapewniają elastyczność i kontrolę. Umożliwiają one również dostęp do artefaktów przepływu pracy, które wkrótce poznasz. W tym module koncentrujemy się na akcjach przepływu pracy. Link do dodatkowych informacji na temat skryptów wdrażania usługi Resource Manager na stronie Podsumowanie na końcu modułu.
Dane wyjściowe
Przepływ pracy zwykle tworzy i konfiguruje zasoby platformy Azure przez wdrożenie pliku Bicep. Kolejne części przepływu pracy wchodzą w interakcję z płaszczyzną danych tych zasobów. Aby móc korzystać z zasobów, akcje przepływu pracy i kroki wymagają informacji o utworzonym zasobie platformy Azure.
Załóżmy na przykład, że masz plik Bicep, który wdraża konto magazynu. Chcesz, aby przepływ pracy wdrażał konto magazynu, a następnie przekazywać niektóre obiekty blob do kontenera obiektów blob na koncie magazynu. Krok przepływu pracy, który przekazuje obiekty blob, musi znać nazwę konta magazynu, z którą ma nawiązać połączenie, oraz nazwę kontenera obiektów blob w celu przekazania pliku do.
Dobrym rozwiązaniem jest podjęcie decyzji o nazwach zasobów platformy Azure przez plik Bicep. Może używać parametrów, zmiennych lub wyrażeń, aby utworzyć nazwy konta magazynu i kontenera obiektów blob. Plik Bicep może następnie uwidocznić dane wyjściowe, które zawierają nazwę każdego zasobu. W kolejnych krokach przepływu pracy można odczytać wartość wyjściową. W ten sposób definicja przepływu pracy nie musi kodować żadnych nazw ani innych informacji, które mogą ulec zmianie między środowiskami lub być oparte na regułach zdefiniowanych w pliku Bicep.
Za pomocą funkcji GitHub Actions można propagować wartości danych wyjściowych przy użyciu zmiennych przepływu pracy. Akcja azure/arm-deploy automatycznie tworzy zmienne dla każdego z danych wyjściowych wdrożenia Bicep. Można również ręcznie utworzyć zmienne przepływu pracy w skryptach. Na końcu tego modułu znajdziesz linki do dodatkowych informacji na stronie Podsumowanie.
Gdy uzyskujesz dostęp do zmiennych utworzonych w innym zadaniu, musisz opublikować zmienną, aby była dostępna dla zadania, które go odczytuje. Załóżmy na przykład, że tworzysz zadanie, które wdraża plik Bicep i musisz propagować appServiceAppName dane wyjściowe do przepływu pracy. Słowo kluczowe służy outputs do określenia, że appServiceAppName zmienna przepływu pracy powinna być ustawiona na wartość appServiceAppName zmiennej wyjściowej utworzonej przez deploy krok:
job1:
runs-on: ubuntu-latest
outputs:
appServiceAppName: ${{ steps.deploy.outputs.appServiceAppName }}
steps:
- uses: actions/checkout@v3
- uses: azure/login@v1
name: Sign in to Azure
with:
client-id: ${{ secrets.AZURE_CLIENT_ID }}
tenant-id: ${{ secrets.AZURE_TENANT_ID }}
subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
- uses: azure/arm-deploy@v1
id: deploy
name: Deploy Bicep file
with:
failOnStdErr: false
deploymentName: ${{ github.run_number }}
resourceGroupName: Playground1
template: ./deploy/main.bicep
Następnie w późniejszym zadaniu utworzysz jawną zależność od zadania, które utworzyło zmienną przez dołączenie needs słowa kluczowego, i odwołujesz się do zmiennej przy użyciu nazwy opublikowanej zmiennej:
job2:
needs: job1
runs-on: ubuntu-latest
steps:
- run: |
echo "${{needs.job1.outputs.appServiceAppName}}"
Za pomocą danych wyjściowych Bicep i zmiennych przepływu pracy można utworzyć przepływ pracy, który wdraża kod Bicep, a następnie wykonuje różne akcje na zasobach w ramach wdrożenia.