Ciągła integracja/ciągłe wdrażanie dla frontonu aplikacji bezserwerowej na platformie Azure

Azure Pipelines

Przetwarzanie bezserwerowe zapewnia abstrakcję serwerów, infrastruktury i systemów operacyjnych, dzięki czemu deweloperzy mogą skupić się na tworzeniu aplikacji. Niezawodna ciągła integracja//ciągłedostarczanie takich aplikacji umożliwia firmom dostarczanie w pełni przetestowanych i zintegrowanych wersji oprogramowania w ciągu kilku minut od czasu opracowywania. Zapewnia szkielet nowoczesnego środowiska DevOps.

Co tak naprawdę oznacza ciągła integracja/ciągłe wdrażanie?

Ciągła integracja umożliwia zespołom deweloperów integrowanie zmian kodu w udostępnionym repozytorium niemal natychmiast. Ta możliwość, w połączeniu z zautomatyzowaną kompilacją i testowaniem przed zintegrowaniem zmian, zapewnia, że do wdrożenia jest dostępny tylko w pełni funkcjonalny kod aplikacji.
Ciągłe dostarczanie umożliwia dostarczanie zmian w kodzie źródłowym, konfiguracji, zawartości i innych artefaktach do produkcji oraz gotowość do wdrożenia dla użytkowników końcowych tak szybko i bezpiecznie, jak to możliwe. Proces utrzymuje kod w stanie możliwy do wdrożenia przez cały czas. Szczególnym przypadkiem jest ciągłe wdrażanie, które obejmuje rzeczywiste wdrożenie dla użytkowników końcowych.

W tym artykule omówiono potok ciągłej integracji/ciągłego wdrażania dla frontonu internetowego implementacji referencyjnej bezserwerowej. Ten potok jest opracowywany przy użyciu usług platformy Azure. Fronton internetowy demonstruje nowoczesną aplikację internetową z kodem JavaScript po stronie klienta, interfejsami API po stronie serwera wielokrotnego użytku i wstępnie utworzonymi znacznikami, alternatywnie nazywanymi narzędziami Jamstack. Kod można znaleźć w tym repozytorium GitHub. Plik readme opisuje kroki pobierania, kompilowania i wdrażania aplikacji.

Na poniższym diagramie opisano potok ciągłej integracji/ciągłego wdrażania używany w tym przykładowym frontonie:

Potok ciągłej integracji/ciągłego wdrażania w aplikacji bezserwerowej przy użyciu usług platformy Azure

W tym artykule nie omówiono wdrażania zaplecza.

Wymagania wstępne

Aby pracować z tą przykładową aplikacją, upewnij się, że masz następujące elementy:

Konto usługi GitHub.
Konto platformy Azure. Jeśli go nie masz, możesz wypróbować bezpłatne konto platformy Azure.
Organizacja usługi Azure DevOps. Jeśli go nie masz, możesz wypróbować podstawowy plan, który obejmuje usługi DevOps, takie jak Azure Pipelines.

Korzystanie z systemu kontroli wersji online

Systemy kontroli wersji śledzą i kontrolują zmiany w kodzie źródłowym. Utrzymywanie kodu źródłowego w systemie kontroli wersji online umożliwia wielu zespołom deweloperów współpracę. Łatwiej jest również zachować tradycyjną kontrolę wersji lokalnie. Te systemy online można łatwo zintegrować z wiodącymi usługami ciągłej integracji/ciągłego wdrażania. Możesz tworzyć i obsługiwać kod źródłowy w wielu katalogach wraz z plikami kompilacji i konfiguracji w repozytorium.

Pliki projektu dla tej przykładowej aplikacji są przechowywane w usłudze GitHub. Jeśli nie masz konta usługi GitHub, przeczytaj tę dokumentację, aby rozpocząć pracę z repozytoriami GitHub.

Automatyzowanie kompilacji i wdrażania

Użycie usługi ciągłej integracji/ciągłego wdrażania, takiej jak Azure Pipelines , może pomóc zautomatyzować procesy kompilacji i wdrażania. W potoku można utworzyć wiele etapów, z których każdy jest uruchamiany na podstawie wyniku poprzedniego. Etapy mogą być uruchamiane w kontenerze systemu Windows lub Linux. Skrypt musi upewnić się, że narzędzia i środowiska są prawidłowo ustawione w kontenerze. Usługa Azure Pipelines może uruchamiać różne narzędzia kompilacji i może pracować z wieloma systemami kontroli wersji online.

Integrowanie narzędzi kompilacji

Nowoczesne narzędzia kompilacji mogą uprościć proces kompilacji i zapewnić funkcje, takie jak konfiguracja wstępna, minification plików JavaScript i generowanie statycznej witryny. Generatory witryn statycznych mogą tworzyć pliki znaczników przed ich wdrożeniem na serwerach hostingu, co skutkuje szybkim środowiskiem użytkownika. Możesz wybrać spośród różnych narzędzi na podstawie typu języka programowania i platformy aplikacji, a także dodatkowych wymaganych funkcji. Ten artykuł zawiera listę popularnych narzędzi kompilacji dla nowoczesnej aplikacji.

Przykład jest aplikacją React utworzoną przy użyciu Gatsby.js, która jest generatorem statycznych witryn i strukturą programowania frontonu. Te narzędzia można uruchamiać lokalnie podczas faz programowania i testowania, a następnie integrować je z usługą Azure Pipelines na potrzeby końcowego wdrożenia.

W przykładzie użyto gatsby-ssr.js pliku Gatsby do renderowania i gatsby-config.js konfiguracji lokacji. Narzędzie Gatsby konwertuje wszystkie pliki JavaScript w pages podkatalogu src folderu na pliki HTML. Dodatkowe składniki są w podkatalogu components . W przykładzie użyto również wtyczki gatsby-plugin-typescript , która umożliwia korzystanie z języka TypeScript w celu zapewnienia bezpieczeństwa typów zamiast języka JavaScript.

Aby uzyskać więcej informacji na temat konfigurowania projektu Gatsby, zobacz oficjalną dokumentację narzędzia Gatsby.

Automatyzowanie kompilacji

Automatyzacja procesu kompilacji zmniejsza liczbę błędów ludzkich, które można wprowadzić w procesach ręcznych. Plik azure-pipelines.yml zawiera skrypt automatyzacji dwuetapowej. Plik Readme dla tego projektu opisuje kroki wymagane do skonfigurowania potoku automatyzacji przy użyciu usługi Azure Pipelines. W poniższych podsekcjach przedstawiono sposób konfigurowania etapów potoku.

Etap kompilacji

Ponieważ usługa Azure Pipelines jest zintegrowana z repozytorium GitHub, wszelkie zmiany w śledzonym katalogu głównej gałęzi wyzwalają pierwszy etap potoku, etap kompilacji:

trigger:
  batch: true
  branches:
    include:
    - main
  paths:
    include:
    - src/ClientApp

Poniższy fragment kodu ilustruje początek etapu kompilacji, który uruchamia kontener Ubuntu w celu uruchomienia tego etapu.

    stages:
    - stage: Build
      jobs:
      - job: WebsiteBuild
        displayName: Build Fabrikam Drone Status app
        pool:
          vmImage: 'Ubuntu-16.04'
        continueOnError: false
    steps:

Następnie są wykonywane zadania i skrypty wymagane do pomyślnego skompilowania projektu. Należą do nich:

Instalowanie Node.js i konfigurowanie zmiennych środowiskowych,

Instalowanie i uruchamianie Gatsby.js, które kompiluje statyczną witrynę internetową:

    - script: |
        cd src/ClientApp
        npm install
        npx gatsby build
      displayName: 'gatsby build'

zainstalowanie i uruchomienie narzędzia kompresji o nazwie brotli w celu skompresowania skompresowanych plików przed wdrożeniem:

    - script: |
        cd src/ClientApp/public
        sudo apt-get install brotli --install-suggests --no-install-recommends -q --assume-yes
        for f in $(find . -type f \( -iname '*.html' -o -iname '*.map' -o -iname '*.js' -o -iname '*.json' \)); do brotli $f -Z -j -f -v && mv ${f}.br $f; done
      displayName: 'enable compression at origin level'

Obliczanie wersji bieżącej kompilacji na potrzeby zarządzania pamięcią podręczną,

Publikowanie skompilowanych plików do użycia przez etap wdrażania:

    - task: PublishPipelineArtifact@1
      inputs:
        targetPath: 'src/ClientApp/public'
        artifactName: 'drop'

Pomyślne zakończenie etapu kompilacji usuwa środowisko Ubuntu i wyzwala etap wdrażania w potoku.

Etap wdrażania

Etap wdrażania jest uruchamiany w nowym kontenerze systemu Ubuntu:

    - stage: Deploy
      jobs:
      - deployment: WebsiteDeploy
        displayName: Deploy Fabrikam Drone Status app
        pool:
          vmImage: 'Ubuntu-16.04'
        environment: 'fabrikamdronestatus-prod'
        strategy:
          runOnce:
            deploy:
              steps:

Ten etap obejmuje różne zadania wdrażania i skrypty do:

Pobierz artefakty kompilacji do kontenera (co dzieje się automatycznie w wyniku użycia PublishPipelineArtifact na etapie kompilacji)
Zarejestruj wersję wydania kompilacji i zaktualizuj je w repozytorium GitHub.
Przekaż pliki witryny internetowej do usługi Blob Storage w nowym folderze odpowiadającym nowej wersji i
Zmień sieć CDN tak, aby wskazywała ten nowy folder.

Ostatnie dwa kroki razem replikują przeczyszczanie pamięci podręcznej, ponieważ starsze foldery nie są już dostępne dla serwerów brzegowych usługi CDN. Poniższy fragment kodu pokazuje, jak to jest osiągane:

       - script: |
              az login --service-principal -u $(azureArmClientId) -p $(azureArmClientSecret) --tenant $(azureArmTenantId)
              # upload content to container versioned folder
              az storage blob upload-batch -s "$(Pipeline.Workspace)/drop" --destination "\$web\$(releaseSemVer)" --account-name $(azureStorageAccountName) --content-encoding br --pattern "*.html" --content-type "text/html"
              az storage blob upload-batch -s "$(Pipeline.Workspace)/drop" --destination "\$web\$(releaseSemVer)" --account-name $(azureStorageAccountName) --content-encoding br --pattern "*.js" --content-type "application/javascript"
              az storage blob upload-batch -s "$(Pipeline.Workspace)/drop" --destination "\$web\$(releaseSemVer)" --account-name $(azureStorageAccountName) --content-encoding br --pattern "*.js.map" --content-type "application/octet-stream"
              az storage blob upload-batch -s "$(Pipeline.Workspace)/drop" --destination "\$web\$(releaseSemVer)" --account-name $(azureStorageAccountName) --content-encoding br --pattern "*.json" --content-type "application/json"
              az storage blob upload-batch -s "$(Pipeline.Workspace)/drop" --destination "\$web\$(releaseSemVer)" --account-name $(azureStorageAccountName) --pattern "*.txt" --content-type "text/plain"
              # target new version
              az cdn endpoint update --resource-group $(azureResourceGroup) --profile-name $(azureCdnName) --name $(azureCdnName) --origin-path '/$(releaseSemVer)'
              AZURE_CDN_ENDPOINT_HOSTNAME=$(az cdn endpoint show --resource-group $(azureResourceGroup) --name $(azureCdnName) --profile-name $(azureCdnName) --query hostName -o tsv)
              echo "Azure CDN endpoint host ${AZURE_CDN_ENDPOINT_HOSTNAME}"
              echo '##vso[task.setvariable variable=azureCndEndpointHost]'$AZURE_CDN_ENDPOINT_HOSTNAME
            displayName: 'upload to Azure Storage static website hosting and purge Azure CDN endpoint'

Niepodzielne wdrożenia

Wdrożenie niepodzielne gwarantuje, że użytkownicy witryny internetowej lub aplikacji zawsze uzyskują zawartość odpowiadającą tej samej wersji.

W przykładowym potoku ciągłej integracji/ciągłego wdrażania zawartość witryny internetowej jest wdrażana w usłudze Blob Storage, która działa jako serwer źródłowy usługi Azure CDN. Jeśli pliki zostaną zaktualizowane w tym samym folderze głównym obiektu blob, witryna internetowa będzie stale obsługiwana. Przekazywanie do nowego folderu w wersji, jak pokazano w poprzedniej sekcji, rozwiązuje ten problem. Użytkownicy otrzymują wszystkie lub nic z nowej pomyślnej kompilacji, ponieważ usługa CDN wskazuje nowy folder jako źródło, dopiero po pomyślnym zaktualizowaniu wszystkich plików.

Wdrożenie w wersji

Zalety tego podejścia są następujące:

Ponieważ nowa zawartość nie jest dostępna dla użytkowników, dopóki usługa CDN nie wskazuje nowego folderu źródła, powoduje niepodzielne wdrożenie.
W razie potrzeby możesz łatwo przywrócić starszą wersję witryny internetowej.
Ponieważ źródło może hostować wiele wersji witryny internetowej obok siebie, można dostosować wdrożenie przy użyciu technik, takich jak umożliwienie podglądu niektórym użytkownikom przed szerszą dostępnością.

Hostowanie i rozpowszechnianie przy użyciu chmury

Sieć dostarczania zawartości (CDN) to zestaw serwerów rozproszonych, które przyspieszają dostarczanie zawartości użytkownikom w rozległym obszarze geograficznym. Każdy użytkownik pobiera zawartość z serwera najbliżej niego. Usługa CDN uzyskuje dostęp do tej zawartości z serwera pochodzenia i buforuje ją na serwerach brzegowych w strategicznych lokalizacjach. Przykładowa ciągła integracja/ciągłe wdrażanie w tym artykule używa usługi Azure CDN, wskazując na zawartość witryny internetowej hostowaną na Azure Blob Storage jako serwer pochodzenia. Magazyn obiektów blob jest skonfigurowany do hostowania statycznej witryny internetowej. Aby uzyskać szybki przewodnik dotyczący korzystania z usługi Azure CDN z Azure Blob Storage, przeczytaj Integrowanie konta usługi Azure Storage z usługą Azure CDN.

Poniżej przedstawiono niektóre strategie, które mogą poprawić wydajność usługi CDN.

Kompresuj zawartość

Kompresowanie plików przed obsługą zwiększa szybkość transferu plików i zwiększa wydajność ładowania stron dla użytkowników końcowych.

Istnieją dwa sposoby wykonania tej czynności:

Na bieżąco na serwerach brzegowych USŁUGI CDN. Poprawia to zużycie przepustowości przez znaczny procent, co znacznie przyspiesza witrynę internetową niż bez kompresji. Stosunkowo łatwo jest włączyć tego typu kompresję w usłudze Azure CDN. Ponieważ jest on kontrolowany przez sieć CDN, nie można wybrać ani skonfigurować narzędzia kompresji. Użyj tej kompresji, jeśli wydajność witryny internetowej nie jest krytycznym problemem.
Wstępne kompresowanie przed dotarciem do sieci CDN na serwerze źródłowym lub przed dotarciem do źródła. Kompresowanie wstępne dodatkowo poprawia wydajność czasu wykonywania witryny internetowej, ponieważ jest ona wykonywana przed pobraniem przez sieć CDN. Przykładowy potok ciągłej integracji/ciągłego wdrażania kompresuje wbudowane pliki na etapie wdrażania przy użyciu narzędzia brotli, jak pokazano w powyższej sekcji kompilacji. Zalety korzystania z kompresji wstępnej są następujące:
1. Możesz użyć dowolnego narzędzia kompresji, które jest wygodne i dodatkowo dostosować kompresję. Sieci CDN mogą mieć ograniczenia dotyczące używanych narzędzi.
2. Niektóre sieci CDN ograniczają rozmiary plików, które można skompresować na bieżąco, powodując trafienie wydajności dla większych plików. Kompresja wstępna nie ustawia limitów rozmiaru pliku.
3. Kompresowanie wstępne w potoku wdrażania powoduje zmniejszenie ilości miejsca wymaganego do magazynowania w miejscu pochodzenia.
4. Jest to szybsze i bardziej wydajne niż kompresja CDN.

Aby uzyskać więcej informacji, zobacz Poprawianie wydajności przez kompresowanie plików w usłudze Azure CDN.

Przyspieszanie witryn dynamicznych

Użycie usługi CDN jest optymalne dla zawartości statycznej, która może być bezpiecznie buforowana na serwerach brzegowych. Jednak dynamiczne witryny sieci Web wymagają, aby serwer wygenerował zawartość na podstawie odpowiedzi użytkownika. Tego typu zawartości nie można buforować na brzegu, co wymaga bardziej kompleksowego rozwiązania, które może przyspieszyć dostarczanie zawartości. Dynamiczne przyspieszanie witryn przez usługę Azure CDN to jedno z takich rozwiązań, które w sposób zrozumiały zwiększa wydajność dynamicznych stron internetowych.

Ten przykład umożliwia dynamiczne przyspieszanie lokacji, jak pokazano w tej sekcji readme.

Zarządzanie pamięcią podręczną witryny internetowej

Sieci CDN używają buforowania w celu zwiększenia wydajności. Konfigurowanie tej pamięci podręcznej i zarządzanie nią staje się integralną częścią potoku wdrażania. W dokumentacji usługi Azure CDN przedstawiono kilka sposobów, aby to zrobić. Możesz ustawić reguły buforowania w sieci CDN, a także skonfigurować czas wygaśnięcia zawartości na serwerze źródłowym. Statyczna zawartość internetowa może być buforowana przez długi czas, ponieważ może nie zmieniać się zbyt wiele w czasie. Zmniejsza to obciążenie związane z uzyskiwaniem dostępu do pojedynczego serwera pochodzenia dla każdego żądania użytkownika. Aby uzyskać więcej informacji, zobacz Jak działa buforowanie.

Przeczyszczanie pamięci podręcznej

Sieć CDN buforuje pliki witryny sieci Web na serwerach brzegowych do momentu wygaśnięcia. Są one aktualizowane dla nowego żądania klienta, dopiero po wygaśnięciu czasu wygaśnięcia. Przeczyszczanie pamięci podręcznej USŁUGI CDN jest wymagane w celu zagwarantowania, że każdy użytkownik otrzymuje najnowsze pliki witryny internetowej na żywo, zwłaszcza jeśli wdrożenie odbywa się w tym samym folderze źródłowym usługi CDN. Usługa Azure CDN umożliwia przeczyszczenie pamięci podręcznej z Azure Portal.

Lepszym rozwiązaniem jest unieważnienie tej pamięci podręcznej przy użyciu przechowywania wersji podczas wdrażania. Jawne przeczyszczenie lub wygaśnięcie pamięci podręcznej zwykle powoduje, że sieć CDN pobiera nowsze wersje zawartości internetowej. Jednak ponieważ sieć CDN zawsze wskazuje najnowszą wersję wdrożenia, poprawia buforowanie w następujący sposób:

Sieć CDN weryfikuje index.html względem źródła dla każdego nowego wystąpienia witryny internetowej.
Z wyjątkiem index.html i 404.html wszystkie inne pliki witryny internetowej są odciski palców i buforowane przez rok. Jest to oparte na założeniu, że zasoby, takie jak obrazy i filmy wideo, nie wymagają częstych zmian. Jeśli te pliki zostaną zaktualizowane i ponownie skompilowane, ich nazwy zostaną zaktualizowane przez nowy identyfikator GUID odcisku palca. Spowoduje to aktualizację index.html ze zaktualizowanym odwołaniem do zmienionego pliku zasobu. Następnie usługa CDN pobiera zaktualizowaną index.html i ponieważ nie znajduje pliku zasobu referencyjnego w pamięci podręcznej, pobiera również zmienione pliki zasobów.

Dzięki temu usługa CDN zawsze pobiera nowe zaktualizowane pliki i usuwa konieczność przeczyszczenia pamięci podręcznej dla nowej kompilacji.

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Główny autor:

Dhanashri Kshirsagar | Starszy pm zawartości

Aby wyświetlić niepubliowe profile usługi LinkedIn, zaloguj się do serwisu LinkedIn.

Następne kroki

Teraz, gdy znasz podstawy, postępuj zgodnie z tym readme , aby skonfigurować i wykonać potok ciągłej integracji/ciągłego wdrażania.
Poznaj najlepsze rozwiązania dotyczące korzystania z sieci dostarczania zawartości (CDN)

Udostępnij za pośrednictwem