Najlepsze rozwiązania dotyczące wdrażania

Uwaga

Od 1 czerwca 2024 r. wszystkie nowo utworzone aplikacje usługi App Service będą miały możliwość wygenerowania unikatowej domyślnej nazwy hosta przy użyciu konwencji <app-name>-<random-hash>.<region>.azurewebsites.netnazewnictwa . Istniejące nazwy aplikacji pozostaną niezmienione.

Przykład: myapp-ds27dh7271aah175.westus-01.azurewebsites.net

Aby uzyskać więcej informacji, zapoznaj się z unikatową domyślną nazwą hosta zasobu usługi App Service.

Każdy zespół programistyczny ma unikatowe wymagania, które mogą utrudnić implementację wydajnego potoku wdrażania w dowolnej usłudze w chmurze. W tym artykule przedstawiono trzy główne składniki wdrażania w usłudze App Service: źródła wdrożenia, potoki kompilacji i mechanizmy wdrażania. W tym artykule opisano również niektóre najlepsze rozwiązania i porady dotyczące określonych stosów językowych.

Składniki wdrażania

Źródło wdrożenia

Źródłem wdrożenia jest lokalizacja kodu aplikacji. W przypadku aplikacji produkcyjnych źródło wdrożenia jest zwykle repozytorium hostowane przez oprogramowanie do kontroli wersji, takie jak GitHub, BitBucket lub Azure Repos. W przypadku scenariuszy tworzenia i testowania źródło wdrożenia może być projektem na komputerze lokalnym.

Potok kompilacji

Po podjęciu decyzji o źródle wdrożenia następnym krokiem jest wybranie potoku kompilacji. Potok kompilacji odczytuje kod źródłowy ze źródła wdrożenia i wykonuje serię kroków (takich jak kompilowanie kodu, minimalizowanie kodu HTML i JavaScript, uruchamianie testów i składników pakowania), aby pobrać aplikację w stanie z możliwością uruchomienia. Określone polecenia wykonywane przez potok kompilacji zależą od stosu języka. Te operacje można wykonywać na serwerze kompilacji, takim jak Usługa Azure Pipelines, lub wykonywane lokalnie.

Mechanizm wdrażania

Mechanizm wdrażania to akcja używana do umieszczania wbudowanej aplikacji w katalogu /home/site/wwwroot aplikacji internetowej. Katalog /wwwroot jest instalowaną lokalizacją magazynu udostępnioną przez wszystkie wystąpienia aplikacji internetowej. Gdy mechanizm wdrażania umieszcza aplikację w tym katalogu, wystąpienia otrzymują powiadomienie o zsynchronizowaniu nowych plików. Usługa App Service obsługuje następujące mechanizmy wdrażania:

• Punkty końcowe Kudu: Kudu to narzędzie zwiększające produktywność deweloperów typu open source, które działa jako oddzielny proces w usłudze Windows App Service i jako drugi kontener w usłudze App Service systemu Linux. Usługa Kudu obsługuje ciągłe wdrożenia i udostępnia punkty końcowe HTTP do wdrożenia, takie jak zipdeploy/.
• FTP i WebDeploy: przy użyciu poświadczeń witryny lub użytkownika można przekazywać pliki za pośrednictwem protokołu FTP lub narzędzia WebDeploy. Te mechanizmy nie przechodzą przez Kudu.

Narzędzia wdrażania, takie jak Azure Pipelines, Jenkins i wtyczki edytora, używają jednego z tych mechanizmów wdrażania.

Korzystanie z miejsc wdrożenia

Jeśli to możliwe, użyj miejsc wdrożenia podczas wdrażania nowej kompilacji produkcyjnej. W przypadku korzystania z warstwy Planu usługi App Service w warstwie Standardowa możesz wdrożyć aplikację w środowisku przejściowym, zweryfikować zmiany i przeprowadzić testy weryfikacyjne kompilacji. Gdy wszystko będzie gotowe, możesz zamienić miejsca przejściowe i produkcyjne. Operacja zamiany rozgrzewa wystąpienia procesów roboczych niezbędne do dopasowania do skali produkcyjnej, eliminując w ten sposób przestoje.

Ciągłe wdrażanie kodu

Jeśli projekt ma wyznaczone gałęzie do testowania, kontroli jakości i przemieszczania, każde z tych gałęzi powinno być stale wdrażane w miejscu przejściowym. (Jest to znane jako Projekt usługi Gitflow). Dzięki temu uczestnicy projektu mogą łatwo ocenić i przetestować wdrożona gałąź.

Ciągłe wdrażanie nigdy nie powinno być włączone dla miejsca produkcyjnego. Zamiast tego gałąź produkcyjna (często główna) powinna zostać wdrożona w miejscu nieprodukcyjnym. Gdy wszystko będzie gotowe do wydania gałęzi podstawowej, zamień ją na miejsce produkcyjne. Zamiana na środowisko produkcyjne — zamiast wdrażania w środowisku produkcyjnym — uniemożliwia przestój i umożliwia wycofanie zmian przez zamianę ponownie.

Ciągłe wdrażanie kontenerów

W przypadku kontenerów niestandardowych z platformy Docker lub innych rejestrów kontenerów wdróż obraz w miejscu przejściowym i zamień na środowisko produkcyjne, aby zapobiec przestojom. Automatyzacja jest bardziej złożona niż wdrażanie kodu, ponieważ należy wypchnąć obraz do rejestru kontenerów i zaktualizować tag obrazu w aplikacji internetowej.

Dla każdej gałęzi, którą chcesz wdrożyć w miejscu, skonfiguruj automatyzację, aby wykonać następujące czynności w każdym zatwierdzeniu w gałęzi.

1. Skompiluj i oznacz obraz tagiem. W ramach potoku kompilacji oznacz obraz identyfikatorem zatwierdzenia git, znacznikiem czasu lub innymi możliwymi do zidentyfikowania informacjami. Najlepiej nie używać domyślnego tagu "latest". W przeciwnym razie trudno jest prześledzić, jaki kod jest obecnie wdrożony, co znacznie utrudnia debugowanie.
2. Wypchnij otagowany obraz. Gdy obraz zostanie skompilowany i oznaczony tagiem, potok wypchnie obraz do rejestru kontenerów. W następnym kroku miejsce wdrożenia ściągnie otagowany obraz z rejestru kontenerów.
3. Zaktualizuj miejsce wdrożenia przy użyciu nowego tagu obrazu. Po zaktualizowaniu tej właściwości witryna zostanie automatycznie ponownie uruchomiona i ściągnie nowy obraz kontenera.

Poniżej przedstawiono przykłady typowych struktur automatyzacji.

Korzystanie z usługi Azure DevOps

Usługa App Service ma wbudowane ciągłe dostarczanie dla kontenerów za pośrednictwem Centrum wdrażania. Przejdź do aplikacji w witrynie Azure Portal i wybierz pozycję Centrum wdrażania w obszarze Wdrożenie. Postępuj zgodnie z instrukcjami, aby wybrać repozytorium i gałąź. Spowoduje to skonfigurowanie potoku kompilacji i wydania metodyki DevOps w celu automatycznego kompilowania, tagowania i wdrażania kontenera po wypchnięciu nowych zatwierdzeń do wybranej gałęzi.

Korzystanie z funkcji GitHub Actions

Wdrożenie kontenera można również zautomatyzować za pomocą funkcji GitHub Actions. Poniższy plik przepływu pracy skompiluje i oznaczy kontener identyfikatorem zatwierdzenia, wypchnie go do rejestru kontenerów i zaktualizuje określoną aplikację internetową przy użyciu nowego tagu obrazu.

on:
  push:
    branches:
    - <your-branch-name>

name: Linux_Container_Node_Workflow

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
    # checkout the repo
    - name: 'Checkout GitHub Action'
      uses: actions/checkout@main

    - uses: azure/docker-login@v1
      with:
        login-server: contoso.azurecr.io
        username: ${{ secrets.REGISTRY_USERNAME }}
        password: ${{ secrets.REGISTRY_PASSWORD }}

    - run: |
        docker build . -t contoso.azurecr.io/nodejssampleapp:${{ github.sha }}
        docker push contoso.azurecr.io/nodejssampleapp:${{ github.sha }} 

    - uses: azure/webapps-deploy@v2
      with:
        app-name: 'node-rnc'
        publish-profile: ${{ secrets.azureWebAppPublishProfile }}
        images: 'contoso.azurecr.io/nodejssampleapp:${{ github.sha }}'

Korzystanie z innych dostawców automatyzacji

Wymienione wcześniej kroki dotyczą innych narzędzi automatyzacji, takich jak CircleCI lub Travis CI. Należy jednak użyć interfejsu wiersza polecenia platformy Azure, aby zaktualizować miejsca wdrożenia przy użyciu nowych tagów obrazów w ostatnim kroku. Aby użyć interfejsu wiersza polecenia platformy Azure w skryscie automatyzacji, wygeneruj jednostkę usługi przy użyciu następującego polecenia.

az ad sp create-for-rbac --name "myServicePrincipal" --role contributor \
   --scopes /subscriptions/{subscription}/resourceGroups/{resource-group} \
   --sdk-auth

W skryscie zaloguj się przy użyciu polecenia az login --service-principal, podając informacje podmiotu zabezpieczeń. Następnie można użyć az webapp config container set polecenia , aby ustawić nazwę kontenera, tag, adres URL rejestru i hasło rejestru. Poniżej przedstawiono kilka przydatnych linków do konstruowania procesu ciągłej integracji kontenera.

• Jak zalogować się do interfejsu wiersza polecenia platformy Azure w okręgu ciągłej integracji

Zagadnienia specyficzne dla języka

Java

Użyj pliku zipdeploy/ interfejsu API Kudu do wdrażania aplikacji JAR i narzędzia wardeploy/ dla aplikacji WAR. Jeśli używasz narzędzia Jenkins, możesz użyć tych interfejsów API bezpośrednio w fazie wdrażania. Aby uzyskać więcej informacji, zobacz ten artykuł.

Węzeł

Domyślnie Kudu wykonuje kroki kompilacji aplikacji Node (npm install). Jeśli używasz usługi kompilacji, takiej jak Azure DevOps, kompilacja Kudu jest niepotrzebna. Aby wyłączyć kompilację Kudu, utwórz ustawienie aplikacji , SCM_DO_BUILD_DURING_DEPLOYMENTz wartością false.

.NET

Domyślnie Kudu wykonuje kroki kompilacji aplikacji .NET (dotnet build). Jeśli używasz usługi kompilacji, takiej jak Azure DevOps, kompilacja Kudu jest niepotrzebna. Aby wyłączyć kompilację Kudu, utwórz ustawienie aplikacji , SCM_DO_BUILD_DURING_DEPLOYMENTz wartością false.

Inne zagadnienia dotyczące wdrażania

Lokalna pamięć podręczna

aplikacja systemu Azure zawartość usługi jest przechowywana w usłudze Azure Storage i jest udostępniana w trwały sposób jako udział zawartości. Jednak niektóre aplikacje potrzebują tylko magazynu zawartości z wysoką wydajnością, który można uruchamiać z wysoką dostępnością. Te aplikacje mogą korzystać z lokalnej pamięci podręcznej. Lokalna pamięć podręczna nie jest zalecana w przypadku witryn zarządzania zawartością, takich jak WordPress.

Zawsze używaj lokalnej pamięci podręcznej w połączeniu z miejscami wdrożenia, aby zapobiec przestojom. Zobacz tę sekcję , aby uzyskać informacje na temat używania tych funkcji razem.

Wysokie użycie procesora CPU lub pamięci

Jeśli plan usługi App Service używa ponad 90% dostępnego procesora CPU lub pamięci, podstawowa maszyna wirtualna może mieć problemy z przetwarzaniem wdrożenia. W takim przypadku tymczasowo skaluj liczbę wystąpień w górę, aby wykonać wdrożenie. Po zakończeniu wdrażania można zwrócić liczbę wystąpień do poprzedniej wartości.

Aby uzyskać więcej informacji na temat najlepszych rozwiązań, odwiedź stronę Diagnostyka usługi App Service, aby dowiedzieć się więcej o najlepszych rozwiązaniach z możliwością działania specyficznych dla zasobu.

• Przejdź do aplikacji internetowej w witrynie Azure Portal.
• Wybierz pozycję Diagnozuj i rozwiąż problemy w obszarze nawigacji po lewej stronie, co spowoduje otwarcie diagnostyki usługi App Service.
• Wybierz kafelek strony głównej Najlepszych rozwiązań .
• Wybierz pozycję Najlepsze rozwiązania dotyczące dostępności i wydajności lub najlepszych rozwiązań dotyczących optymalnej konfiguracji , aby wyświetlić bieżący stan aplikacji w odniesieniu do tych najlepszych rozwiązań.

Możesz również użyć tego linku, aby bezpośrednio otworzyć diagnostykę usługi App Service dla zasobu: https://portal.azure.com/?websitesextension_ext=asd.featurePath%3Ddetectors%2FParentAvailabilityAndPerformance#@microsoft.onmicrosoft.com/resource/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{siteName}/troubleshoot.

Więcej zasobów

Dokumentacja zmiennych środowiskowych i ustawień aplikacji