Najlepsze praktyki dotyczące wdrażania

Uwaga

Od 1 czerwca 2024 r. nowo utworzone aplikacje usługi App Service mogą wygenerować unikatową domyślną nazwę hosta, która używa konwencji <app-name>-<random-hash>.<region>.azurewebsites.netnazewnictwa . Istniejące nazwy aplikacji pozostają niezmienione. Na przykład:

myapp-ds27dh7271aah175.westus-01.azurewebsites.net

Aby uzyskać więcej informacji, zobacz Unikatowa domyślna nazwa 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 aplikacja systemu Azure: ź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

W tej sekcji opisano trzy główne składniki wdrażania w usłudze App Service.

Ź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 uruchamia szereg kroków w celu uzyskania aplikacji w stanie możliwych do uruchomienia.

Kroki mogą obejmować kompilowanie kodu, minimalizowanie kodu HTML i języka JavaScript, uruchamianie testów i tworzenie pakietów składników. Określone polecenia uruchamiane przez potok kompilacji zależą od stosu języka. Te operacje można uruchamiać na serwerze kompilacji, takim jak usługa Azure Pipelines lub 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. Działa 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, podczas wdrażania nowej kompilacji produkcyjnej użyj miejsc wdrożenia. W warstwie Plan usługi App Service w warstwie Standardowa lub lepszej możesz wdrożyć aplikację w środowisku przejściowym, zweryfikować zmiany i przeprowadzić testy weryfikacyjne kompilacji. Gdy wszystko będzie gotowe, zamień miejsca przejściowe i produkcyjne. Operacja zamiany rozgrzewa wystąpienia procesów roboczych niezbędne do dopasowania do skali produkcyjnej, co eliminuje przestoje.

Ciągłe wdrażanie kodu

Jeśli projekt ma gałęzie wyznaczone do testowania, kontroli jakości i przemieszczania, każda z tych gałęzi powinna być stale wdrażana w miejscu przejściowym. Takie podejście jest nazywane projektem gitflow. Ten projekt umożliwia uczestnikom projektu łatwe ocenianie i testowanie wdrożonej gałęzi.

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. Musisz 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 wykonywać te zadania 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 najnowszego . W przeciwnym razie trudno jest prześledzić, jaki kod jest obecnie wdrożony, co sprawia, że debugowanie jest trudniejsze.
2. Wypchnij otagowany obraz. Po skompilowania i oznakowaniu obrazu potok wypycha obraz do rejestru kontenerów. W następnym kroku miejsce wdrożenia ściąga 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.

Ten artykuł zawiera 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. W obszarze Wdrożenie wybierz pozycję Centrum wdrażania. Postępuj zgodnie z instrukcjami, aby wybrać repozytorium i gałąź. To podejście umożliwia 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. Plik przepływu pracy kompiluje i taguje kontener za pomocą identyfikatora zatwierdzenia, wypycha go do rejestru kontenerów i aktualizuje 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 az login --service-principalpolecenia , podając informacje o podmiotach 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. Aby uzyskać więcej informacji, zobacz Jak zalogować się do interfejsu wiersza polecenia platformy Azure w środowisku Circle CI.

Zagadnienia specyficzne dla języka

Należy pamiętać o następujących zagadnieniach dotyczących implementacji języków Java, Node i .NET.

Java

Użyj interfejsu API zipdeploy Kudu do wdrażania aplikacji JAR. Użyj 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 Deploy to aplikacja systemu Azure Service with Jenkins (Wdrażanie w usłudze aplikacja systemu Azure service za pomocą narzędzia Jenkins).

Węzeł

Domyślnie Kudu uruchamia 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 uruchamia kroki kompilacji dla 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

Inne zagadnienia obejmują lokalną pamięć podręczną i wysokie użycie procesora CPU lub pamięci.

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. Aby uzyskać więcej informacji, zobacz omówienie lokalnej pamięci podręcznej usługi aplikacja systemu Azure Service.

Uwaga

Lokalna pamięć podręczna nie jest zalecana w przypadku witryn zarządzania zawartością, takich jak WordPress.

Aby zapobiec przestojom, zawsze używaj lokalnej pamięci podręcznej z miejscami wdrożenia. Aby uzyskać informacje na temat używania tych funkcji razem, zobacz Najlepsze rozwiązania.

Wysokie użycie procesora CPU lub pamięci

Jeśli plan usługi App Service korzysta z ponad 90% dostępnego procesora CPU lub pamięci, podstawowa maszyna wirtualna może mieć problemy z przetwarzaniem wdrożenia. W takiej sytuacji 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, odwiedź stronę Diagnostyka usługi App Service, aby dowiedzieć się, które najlepsze rozwiązania z możliwością działania są specyficzne dla zasobu.

1. Przejdź do aplikacji internetowej w witrynie Azure Portal.

2. Wybierz pozycję Diagnozuj i rozwiąż problemy w obszarze nawigacji po lewej stronie, co spowoduje otwarcie diagnostyki usługi App Service.

3. Wybierz pozycję Dostępność i wydajność lub zapoznaj się z innymi opcjami, takimi jak Analiza wysokiego użycia procesora CPU.

   Wyświetl 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.

Powiązana zawartość

• Dokumentacja zmiennych środowiskowych i ustawień aplikacji