Samouczek: Wdróż aplikację ASP.NET Core i bazę danych Azure SQL do usługi Azure App Service

W tym samouczku dowiesz się, jak wdrożyć aplikację ASP.NET Core opartą na danych w usłudze Azure App Service i połączyć się z bazą danych Azure SQL. Następnie wdrożysz Azure Cache dla Redis, aby umożliwić kodowanie buforowania w swojej aplikacji. Azure App Service to wysoce skalowalna, samopatchująca usługa hostingu webowego, która może łatwo wdrażać aplikacje na Windows lub Linux. Mimo że ten samouczek używa aplikacji ASP.NET Core 8.0, proces jest taki sam dla innych wersji ASP.NET Core.

W tym poradniku nauczysz się, jak:

• Utwórz domyślnie bezpieczną architekturę usługi aplikacji, bazy danych SQL i pamięci podręcznej Redis.
• Zabezpiecz tajemnice połączeń za pomocą zarządzanej tożsamości i odniesień do Key Vault.
• Wdróż przykładową aplikację ASP.NET Core do usługi aplikacji z repozytorium GitHub.
• Uzyskaj dostęp do ciągów połączeń i ustawień aplikacji usługi aplikacji w kodzie aplikacji.
• Wprowadź aktualizacje i ponownie wdroż kod aplikacji.
• Generowanie schematu bazy danych przez przekazanie pakietu migracji.
• Strumieniuj dzienniki diagnostyczne z Azure.
• Zarządzaj aplikacją w portalu Azure.
• Aprowizuj tę samą architekturę i wdróż przy użyciu interfejsu wiersza polecenia dla deweloperów platformy Azure.
• Zoptymalizuj przepływ pracy programowania za pomocą usług GitHub Codespaces i GitHub Copilot.

Wymagania wstępne

• Konto Azure z aktywną subskrypcją. Jeśli nie masz konta Azure, możesz utworzyć je za darmo.
• Konto usługi GitHub. Możesz również bezpłatnie uzyskać jeden.
• Znajomość developowania w ASP.NET Core.
• (Opcjonalne) Aby wypróbować GitHub Copilot, konto GitHub Copilot. Dostępny jest 30-dniowy bezpłatny okres próbny.

• Konto Azure z aktywną subskrypcją. Jeśli nie masz konta Azure, możesz utworzyć je za darmo.
• Azure Developer CLI zainstalowany. Możesz wykonywać kroki używając Azure Cloud Shell, ponieważ ma już zainstalowane Azure Developer CLI.
• Znajomość developowania w ASP.NET Core.
• (Opcjonalne) Aby wypróbować GitHub Copilot, konto GitHub Copilot. Dostępny jest 30-dniowy bezpłatny okres próbny.

Przeskocz na koniec

Jeśli chcesz zobaczyć przykładową aplikację w tym samouczku uruchomionym na platformie Azure, uruchom następujące polecenia w usłudze Azure Cloud Shell i postępuj zgodnie z monitem:

dotnet tool install --global dotnet-ef
mkdir msdocs-app-service-sqldb-dotnetcore
cd msdocs-app-service-sqldb-dotnetcore
azd init --template msdocs-app-service-sqldb-dotnetcore
azd up

1. Uruchamianie przykładu

Najpierw skonfiguruj przykładową aplikację opartą na danych jako punkt wyjścia. Dla Twojej wygody, repozytorium przykładowe zawiera konfigurację kontenera deweloperskiego. Kontener deweloperski ma wszystko, czego potrzebujesz, aby opracować aplikację, w tym bazę danych, pamięć podręczną i wszystkie zmienne środowiskowe wymagane przez przykładową aplikację. Kontener deweloperski może działać w usłudze GitHub codespace, co oznacza, że można uruchomić przykład na dowolnym komputerze z przeglądarką internetową.

Krok 1: W nowym oknie przeglądarki:

1. Zaloguj się na swoje konto GitHub.
2. Przejdź do https://github.com/Azure-Samples/msdocs-app-service-sqldb-dotnetcore/fork.
3. Odznacz Tylko skopiuj główną gałąź. Chcesz wszystkie gałęzie.
4. Wybierz opcję Utwórz fork.

Krok 2: W forku GitHub:

1. Wybierz main>starter-no-infra dla gałęzi startowej. Ta gałąź zawiera tylko przykładowy projekt i nie zawiera plików ani konfiguracji związanych z Azure.
2. Wybierz Code>Codespaces>Utwórz przestrzeń kodu na starter-no-infra. Utworzenie przestrzeni kodowej zajmuje kilka minut.

Krok 3: W terminalu w przestrzeni kodowej:

1. Przeprowadź migracje bazy danych za pomocą dotnet ef database update.
2. Uruchom aplikację za pomocą dotnet run.
3. Gdy zobaczysz powiadomienie Your application running on port 5093 is available., wybierz Otwórz w przeglądarce. Powinnaś/Powinieneś zobaczyć przykładową aplikację w nowej karcie przeglądarki. Aby zatrzymać aplikację, wpisz Ctrl+C.

Wskazówka

Możesz zapytać GitHub Copilot o to repozytorium. Przykład:

• @workspace Co robi ten projekt?
• @workspace Do czego służy folder .devcontainer?

Masz problemy? Sprawdź sekcję rozwiązywania problemów.

2. Utwórz App Service, bazę danych i pamięć podręczną

W tym kroku tworzysz zasoby Azure. Kroki użyte w tym poradniku tworzą zestaw domyślnie zabezpieczonych zasobów, które obejmują App Service, Azure SQL Database i Azure Cache. W procesie tworzenia określisz następujące elementy:

• Nazwa aplikacji internetowej. Jest ona używana jako część nazwy DNS dla aplikacji.
• Region, w którym aplikacja będzie uruchamiana fizycznie na świecie. Jest także używane jako część nazwy DNS dla Twojej aplikacji.
• Stos Runtime dla aplikacji. To tutaj wybierasz wersję .NET do użycia w swojej aplikacji.
• Plan hostingowy dla aplikacji. Jest to poziom cenowy, który obejmuje zestaw funkcji i możliwości skalowania dla Twojej aplikacji.
• Grupa zasobów dla aplikacji. Grupa zasobów pozwala pogrupować (w logicznym kontenerze) wszystkie zasoby Azure potrzebne do aplikacji.

Zaloguj się do portalu Azure i wykonaj następujące kroki, aby utworzyć zasoby usługi Azure App Service.

Krok 1. W witrynie Azure Portal:

1. Wprowadź "web app database" w pasek wyszukiwania na górze portalu Azure.
2. Wybierz element oznaczony jako Web App + Database pod nagłówkiem Marketplace. Możesz również przejść bezpośrednio do kreatora.

Krok 2. Na stronie Tworzenie aplikacji internetowej i bazy danych wypełnij formularz w następujący sposób.

1. Resource Group: Wybierz Create new i użyj nazwy msdocs-core-sql-tutorial.
2. Region: Dowolny region Azure w pobliżu.
3. Nazwa: msdocs-core-sql-XYZ, gdzie XYZ składa się z dowolnych trzech losowych znaków. Nazwa ta musi być unikalna w całym Azure.
4. Stos środowiska uruchomieniowego: .NET 8 (LTS).
5. Silnik: SQLAzure. Azure SQL Database to w pełni zarządzana platforma jako usługa (PaaS) z silnikiem bazodanowym, która zawsze działa na najnowszej stabilnej wersji SQL Server.
6. Chcesz dodać Azure Cache dla Redis?: Tak.
7. Plan hostingu: Podstawowy. Gdy wszystko będzie gotowe, możesz skalować w górę do warstwy cenowej produkcyjnej.
8. Wybierz opcję Recenzja i utwórz.
9. Po zakończeniu walidacji wybierz Utwórz.

Krok 3: Wdrożenie zajmuje kilka minut, aby się zakończyć. Gdy wdrożenie zostanie zakończone, wybierz przycisk Przejdź do zasobu. Jesteś bezpośrednio przeniesiony do aplikacji App Service, ale tworzone są także następujące zasoby:

• Grupa zasobów: Kontener dla wszystkich utworzonych zasobów.
• App Service plan: Określa zasoby obliczeniowe dla App Service. Plan Linux w warstwie Podstawowej został utworzony.
• App Service: Reprezentuje twoją aplikację i działa w planie App Service.
• Virtual network: Zintegrowana z aplikacją usługi App Service i izoluje ruch sieciowy zaplecza.
• Private endpoints: Punkty dostępu do skarbca kluczy, serwera baz danych i pamięci podręcznej Redis w sieci wirtualnej.
• Interfejsy sieciowe: Reprezentują prywatne adresy IP, po jednym dla każdego z prywatnych punktów końcowych.
• Serwer usługi Azure SQL Database: dostępny tylko zza jego prywatnego punktu końcowego.
• Azure SQL Database: Baza danych i użytkownik są tworzone dla Ciebie na serwerze.
• Azure Cache for Redis: Dostępny tylko zza jego prywatnego punktu końcowego.
• Key vault: Dostępne tylko z prywatnego punktu końcowego. Używany do zarządzania tajemnicami dla aplikacji App Service.
• Strefy prywatne DNS: Umożliwiają rozwiązywanie DNS skarbca kluczy, serwera baz danych i pamięci podręcznej Redis w sieci wirtualnej.

3. Zabezpiecz tajemnice połączenia

Kreator utworzył już dla Ciebie zmienną łączności jako łańcuchy połączeń .NET i ustawienia aplikacji. Najlepszą praktyką dotyczącą bezpieczeństwa jest całkowite unikanie przechowywania poufnych informacji w usłudze App Service. Proponuję przenieść swoje sekrety do klucza skarbca i zmienić ustawienia aplikacji na odwołania do Key Vault z pomocą złączy serwisowych.

Wskazówka

Aby korzystać z uwierzytelniania bez hasła, zobacz Jak zmienić połączenie z bazą danych SQL, aby używać tożsamości zarządzanej?

Krok 1. Pobieranie istniejącej parametry połączenia

1. W lewym menu strony App Service wybierz Ustawienia > Zmienne środowiskowe > Ciągi połączeń.
2. Wybierz AZURE_SQL_CONNECTIONSTRING.
3. W Dodaj/Edytuj ciąg połączenia, w polu Wartość, znajdź część Hasło= na końcu ciągu.
4. Skopiuj ciąg hasła po Password= do późniejszego użycia. Ten łańcuch połączenia umożliwia połączenie z bazą danych SQL zabezpieczoną za prywatnym punktem końcowym. Wpisy tajne są jednak zapisywane bezpośrednio w aplikacji usługi App Service, co nie jest najlepsze. Podobnie, w zakładce Ustawienia aplikacji łańcuch połączeń pamięci podręcznej Redis zawiera tajemnicę. Zmienisz to.

Krok 2: Utwórz magazyn kluczy w celu bezpiecznego zarządzania tajemnicami

1. Na górnym pasku wyszukiwania wpisz "key vault", następnie wybierz Marketplace>Key Vault.
2. W obszarze Grupa zasobów wybierz pozycję msdocs-core-sql-tutorial.
3. W Nazwa magazynu kluczy wpisz nazwę składającą się wyłącznie z liter i cyfr.
4. W Regionie ustaw tę samą lokalizację co grupa zasobów.

Krok 3. Zabezpiecz magazyn kluczy przy użyciu prywatnego punktu końcowego

1. Wybierz kartę Sieć.
2. Usuń zaznaczenie pozycji Włącz dostęp publiczny.
3. Wybierz Utwórz prywatny punkt końcowy.
4. W obszarze Grupa zasobów wybierz pozycję msdocs-core-sql-tutorial.
5. W oknie dialogowym, w Location, wybierz tę samą lokalizację, co twoja aplikacja App Service.
6. W Nazwa wpisz msdocs-core-sql-XYZVvaultEndpoint.
7. W obszarze Lokalizacja wybierz tę samą lokalizację co aplikacja usługi App Service.
8. W obszarze Sieć wirtualna wybierz pozycję msdocs-core-sql-XYZVnet.
9. W podsieci:msdocs-core-sql-XYZSubnet.
10. Kliknij przycisk OK.
11. Wybierz Przegląd + utwórz, a następnie wybierz Utwórz. Poczekaj na zakończenie wdrożenia usługi Key Vault. Powinien zostać wyświetlony komunikat "Wdrożenie zostało ukończone".

Krok 4:

1. W górnym pasku wyszukiwania wpisz msdocs-core-sql, a następnie zasób usługi App Service o nazwie msdocs-core-sql-XYZ.
2. Na stronie App Service, w menu po lewej stronie, wybierz Ustawienia > Łącznik Usługi. Istnieją już dwa łączniki, które kreator tworzenia aplikacji wygenerował dla Ciebie.
3. Wybierz pole wyboru obok łącznika bazy danych SQL, a następnie wybierz Edytuj.
4. Wybierz kartę Uwierzytelnianie .
5. W polu Hasło wklej hasło, które skopiowałeś wcześniej.
6. Wybierz Przechowuj tajemnicę w Key Vault.
7. W sekcji Połączenie z Key Vault wybierz Utwórz nowe. Nad oknem dialogowym edycji otwarte zostaje okno dialogowe Utwórz połączenie.

Krok 5. Ustanawianie połączenia usługi Key Vault

1. W oknie dialogowym Tworzenie połączenia dla połączenia Key Vault, w Key Vault wybierz utworzony wcześniej magazyn kluczy.
2. Wybierz Przejrzyj i utwórz.
3. Gdy walidacja zostanie zakończona, wybierz Utwórz.

Krok 6: Finalizuj ustawienia łącznika bazy danych SQL

1. Jesteś ponownie w oknie dialogowym edycji dla defaultConnector. Na karcie Authentication poczekaj, aż zostanie utworzony łącznik key vault. Gdy jest gotowe, rozwijane menu Key Vault Connection automatycznie je wybiera.
2. Wybierz Next: Networking.
3. Wybierz Zapisz. Poczekaj, aż pojawi się powiadomienie Aktualizacja zakończona pomyślnie.

Krok 7: Skonfiguruj łącznik Redis, aby używać tajemnic Key Vault

1. Na stronie Łącznik usługi zaznacz pole wyboru obok łącznika pamięci podręcznej Redis, a następnie wybierz pozycję Edytuj.
2. Wybierz kartę Uwierzytelnianie .
3. Wybierz Przechowuj tajemnicę w Key Vault.
4. W sekcji Połączenie z Key Vault wybierz Key Vault, który utworzyłeś.
5. Wybierz Next: Networking.
6. Wybierz Skonfiguruj reguły zapory, aby umożliwić dostęp do docelowej usługi. Kreator tworzenia aplikacji już zabezpieczył bazę danych SQL za pomocą prywatnego punktu końcowego.
7. Wybierz Zapisz. Poczekaj, aż pojawi się powiadomienie Aktualizacja zakończona pomyślnie.

Krok 8. Weryfikowanie integracji z usługą Key Vault

1. Z menu po lewej stronie wybierz Ustawienia > Zmienne środowiskowe > Łącza połączeń ponownie.
2. Obok AZURE_SQL_CONNECTIONSTRING wybierz Pokaż wartość. Wartość powinna być @Microsoft.KeyVault(...), co oznacza, że jest to odwołanie do skarbca kluczy, ponieważ tajemnica jest teraz zarządzana w skarbcu kluczy.
3. Aby zweryfikować ciąg połączenia Redis, wybierz kartę Ustawienia aplikacji. Obok AZURE_REDIS_CONNECTIONSTRING wybierz Pokaż wartość. Wartość powinna być @Microsoft.KeyVault(...) również.

Podsumowując, proces zabezpieczania tajemnic połączenia obejmował:

• Pobieranie tajnych danych połączenia ze zmiennych środowiskowych aplikacji App Service.
• Tworzenie repozytorium kluczy.
• Tworzenie połączenia usługi Key Vault z tożsamością zarządzaną przypisaną przez system.
• Aktualizowanie łączników usługi w celu przechowywania tajnych danych w skarbcu kluczy.

4. Wdrażanie przykładowego kodu

W tym kroku konfigurujesz wdrożenie GitHub przy użyciu GitHub Actions. Istnieje wiele sposobów na wdrożenie do App Service, a ten jest również doskonałym sposobem na zapewnienie ciągłej integracji w procesie wdrażania. Domyślnie każde git push w twoim repozytorium GitHub uruchamia procesy budowania i wdrażania.

Krok 1: W menu po lewej stronie wybierz Wdrożenia>Centrum wdrożeń.

Krok 2. Na stronie Centrum wdrażania:

1. W obszarze Źródło wybierz pozycję GitHub. Domyślnie GitHub Actions jest wybrane jako dostawca budowania.
2. Zaloguj się do konta usługi GitHub i postępuj zgodnie z monitem, aby autoryzować platformę Azure.
3. W Organization wybierz swoje konto.
4. W Repozytorium wybierz msdocs-app-service-sqldb-dotnetcore.
5. W Branch wybierz starter-no-infra. Jest to ta sama gałąź, w której pracowaliśmy z przykładową aplikacją bez żadnych plików ani konfiguracji związanych z platformą Azure.
6. W polu Typ uwierzytelniania wybierz pozycję Tożsamość przypisana przez użytkownika.
7. W górnym menu wybierz Save. Usługa aplikacji dodaje plik przepływu pracy do wybranego repozytorium GitHub, w katalogu .github/workflows. Domyślnie centrum wdrożeniowe tworzy tożsamość przypisaną do użytkownika, aby przepływ pracy mógł uwierzytelniać się za pomocą Microsoft Entra (uwierzytelnianie OIDC). Aby zapoznać się z alternatywnymi opcjami uwierzytelniania, zobacz Wdrożenie do usługi App Service za pomocą GitHub Actions.

Krok 3: Wróć do przestrzeni kodu GitHub swojej próbki forka i uruchom git pull origin starter-no-infra. Ta akcja pobiera nowo zatwierdzony plik przepływu pracy do twojej przestrzeni kodu.

Krok 4 (opcja 1: w usłudze GitHub Copilot):

1. Rozpocznij nową sesję czatu, wybierając widok Chat, a następnie wybierając +.
2. Zapytaj: "@workspace Jak aplikacja łączy się z bazą danych i pamięcią podręczną?". Copilot może podać kilka wyjaśnień dotyczących MyDatabaseContext klasy i sposobu jej konfiguracji w Program.cs.
3. Zapytaj: "W trybie produkcyjnym chcę, aby aplikacja korzystała z parametru połączenia o nazwie AZURE_SQL_CONNECTIONSTRING dla bazy danych i parametru ustawień aplikacji o nazwie AZURE_REDIS_CONNECTIONSTRING*". Copilot może dać sugestię kodu podobną do tej w poniższych krokach w opcji 2: bez narzędzia GitHub Copilot i nawet poinformować Cię o zmianie w pliku Program.cs.
4. Otwórz Program.cs w eksploratorze i dodaj proponowany kod. GitHub Copilot nie daje za każdym razem tej samej odpowiedzi i nie zawsze jest poprawny. Być może będziesz musiał zadać więcej pytań, aby dopracować odpowiedź. Aby uzyskać wskazówki, zobacz Co mogę zrobić z GitHub Copilot w mojej przestrzeni kodowej?.

Krok 4 (opcja 2: bez narzędzia GitHub Copilot):

1. Otwórz Program.cs w eksploratorze.
2. Znajdź zakomentowany kod (linie 12-21) i odkomentuj go. Ten kod łączy się z bazą danych przy użyciu AZURE_SQL_CONNECTIONSTRING oraz łączy się z pamięcią podręczną Redis przy użyciu ustawienia aplikacji AZURE_REDIS_CONNECTIONSTRING.

Krok 5 (Opcja 1: z GitHub Copilot):

1. Otwórz .github/workflows/starter-no-infra_msdocs-core-sql-XYZ w eksploratorze. Ten plik został utworzony przez kreator tworzenia usługi App Service.
2. Podświetl dotnet publish krok i wybierz .
3. Zapytaj Copilot, "Zainstaluj dotnet ef, a następnie utwórz pakiet migracji w tym samym folderze wyjściowym."
4. Jeśli sugestia jest akceptowalna, wybierz Akceptuj. GitHub Copilot nie daje za każdym razem tej samej odpowiedzi i nie zawsze jest poprawny. Być może będziesz musiał zadać więcej pytań, aby dopracować odpowiedź. Aby uzyskać wskazówki, zobacz Co mogę zrobić z GitHub Copilot w mojej przestrzeni kodowej?.

Krok 5 (opcja 2: bez narzędzia GitHub Copilot):

1. Otwórz .github/workflows/starter-no-infra_msdocs-core-sql-XYZ w eksploratorze. Ten plik został utworzony przez kreator tworzenia usługi App Service.
2. Pod krokiem dotnet publish dodaj krok instalacji narzędzia Entity Framework Core za pomocą polecenia dotnet tool install -g dotnet-ef --version 8.*.
3. Pod nowym krokiem dodaj kolejny krok, aby wygenerować pakiet migracji bazy danych w pakiecie wdrożeniowym: . Pakiet migracyjny to samodzielny plik wykonywalny, który możesz uruchomić w środowisku produkcyjnym bez potrzeby posiadania .NET SDK. Kontener Linux w usłudze App Service ma tylko środowisko uruchomieniowe .NET, a nie posiada zestawu SDK .NET.

Krok 6.

1. Wybierz rozszerzenie Source Control.
2. W polu tekstowym wpisz wiadomość zatwierdzenia, taką jak Configure Azure database and cache connections. Albo wybierz i pozwól GitHub Copilot wygenerować dla Ciebie wiadomość zatwierdzenia.
3. Wybierz Zatwierdź, a następnie potwierdź wybór, klikając Tak.
4. Wybierz Sync changes 1, a następnie potwierdź, klikając OK.

Krok 7: Wróć na stronę Centrum wdrażania w portalu Azure:

1. Wybierz kartę Logi, a następnie wybierz Odśwież, aby zobaczyć nowe uruchomienie wdrożenia.
2. W elemencie dziennika z przebiegu wdrożenia, wybierz wpis Dzienniki budowania/wdrażania z najnowszą datą i godziną.

Krok 8: Zostaniecie przeniesieni do swojego repozytorium GitHub i zobaczycie, że akcja GitHub działa. Plik przepływu pracy definiuje dwa oddzielne etapy: budowanie i wdrażanie. Poczekaj, aż uruchomienie na GitHubie pokaże stan Success. Trwa to około 5 minut.

Masz problemy? Sprawdź sekcję rozwiązywania problemów.

5. Generowanie schematu bazy danych

Proponuję ulepszenia: Z uwagi na fakt, że baza danych SQL jest chroniona przez wirtualną sieć, najprostszym sposobem na uruchomienie dotnet migration bazy danych jest użycie sesji SSH z kontenerem Linux w usłudze App Service.

Krok 1. Powrót na stronę usługi App Service w menu po lewej stronie

1. Wybierz Narzędzia deweloperskie>SSH.
2. Wybierz Idź. (Uruchomienie trwa kilka minut).

Krok 2: W sesji SSH:

1. Uruchom program cd /home/site/wwwroot. Oto wszystkie Twoje wdrożone pliki.
2. Uruchom pakiet migracyjny wygenerowany przez proces GitHub, używając polecenia ./migrationsbundle -- --environment Production. Jeśli się uda, usługa App Service nawiązuje pomyślnie połączenie z bazą danych SQL. Pamiętaj, że --environment Production odpowiada zmianom kodu wprowadzonych w Program.cs.

W sesji SSH tylko zmiany w plikach w /home mogą być zachowane po ponownym uruchomieniu aplikacji. Zmiany poza /home nie są zapisywane.

Masz problemy? Sprawdź sekcję rozwiązywania problemów.

6. Przejdź do aplikacji

Step 1: Na stronie usługi App Service:

1. Z menu po lewej stronie wybierz Przegląd.
2. Wybierz URL swojej aplikacji.

Step 2: Dodaj kilka zadań do listy. Gratulacje, uruchamiasz aplikację webową w usłudze Azure App Service, z bezpiecznym połączeniem z Azure SQL Database.

Wskazówka

Przykładowa aplikacja implementuje wzorzec cache-aside. Kiedy odwiedzasz widok danych po raz drugi lub ponownie ładujesz tę samą stronę po dokonaniu zmian w danych, Czas przetwarzania na stronie internetowej pokazuje znacznie szybszy czas, ponieważ dane są ładowane z pamięci podręcznej zamiast z bazy danych.

7. Przesyłanie dzienników diagnostycznych

Usługa aplikacyjna Azure przechwytuje wszystkie dzienniki konsoli, aby ułatwić diagnozowanie problemów z aplikacją. Przykładowa aplikacja zawiera kod logowania w każdym ze swoich punktów końcowych, aby zademonstrować tę funkcję.

Step 1: Na stronie usługi App Service:

1. Z lewego menu wybierz Monitoring>Dzienniki usługi App Service.
2. W obszarze Logowanie aplikacji wybierz pozycję System plików.
3. W górnym menu wybierz Save.

Krok 2: Z menu po lewej stronie wybierz Log stream. Widzisz dzienniki dla swojej aplikacji, w tym dzienniki platformy i dzienniki z wnętrza kontenera.

8. Posprzątaj zasoby

Po zakończeniu możesz usunąć wszystkie zasoby ze swojej subskrypcji Azure, usuwając grupę zasobów.

Krok 1: W pasku wyszukiwania na górze portalu Azure:

1. Wprowadź nazwę grupy zasobów.
2. Wybierz grupę zasobów.

Krok 2: Na stronie grupy zasobów wybierz Usuń grupę zasobów.

Krok 3:

1. Wprowadź nazwę grupy zasobów, aby potwierdzić jej usunięcie.
2. Wybierz Usuń.

2. Utwórz zasoby Azure i wdroż przykładową aplikację

pl-PL: W tym kroku tworzysz zasoby Azure i wdrażasz przykładową aplikację do App Service na systemie Linux. Kroki używane w tym samouczku tworzą zestaw zasobów bezpiecznych domyślnie, które obejmują App Service, Azure SQL Database oraz Azure Cache for Redis.

Kontener deweloperski już zawiera narzędzie Azure Developer CLI (AZD).

1. Z katalogu głównego repozytorium uruchom azd init.

   azd init --template dotnet-app-service-sqldb-infra
   

2. Po wyświetleniu prośby, podaj następujące odpowiedzi:

   Pytanie	Odpowiedź
   Bieżący katalog nie jest pusty. Czy chciałbyś zainicjować projekt tutaj w '<your-directory>'?	Y
   Co chciałbyś zrobić z tymi plikami?	Pozostaw moje istniejące pliki bez zmian
   Wprowadź nową nazwę środowiska	Wpisz unikalną nazwę. Szablon AZD używa tej nazwy jako części nazwy DNS twojej aplikacji internetowej w Azure (<app-name>-<hash>.azurewebsites.net). Dozwolone są znaki alfanumeryczne i łączniki.

3. Zaloguj się do Azure, uruchamiając polecenie azd auth login i postępując zgodnie z wyświetlanymi instrukcjami.

   azd auth login
   

4. Utwórz niezbędne zasoby Azure i wdroż kod aplikacji za pomocą polecenia azd up. Postępuj zgodnie z instrukcjami, aby wybrać żądaną subskrypcję i lokalizację dla zasobów Azure.

   azd up
   

   Polecenie azd up zajmuje około 15 minut do wykonania (najwięcej czasu zajmuje pamięć podręczna Redis). Kompiluje i wdraża również kod aplikacji, ale później zmodyfikujesz swój kod, aby działał z usługą App Service. Podczas działania, polecenie dostarcza komunikaty dotyczące procesu przygotowywania i wdrażania, w tym link do wdrożenia w Azure. Po zakończeniu polecenie wyświetla również link do wdrożonej aplikacji.

   Ten szablon AZD zawiera pliki (azure.yaml i katalog infra), które generują domyślnie bezpieczną architekturę z następującymi zasobami Azure:

   • Grupa zasobów: Kontener dla wszystkich utworzonych zasobów.
   • App Service plan: Określa zasoby obliczeniowe dla App Service. Plan Linux w warstwie Podstawowej został utworzony.
   • App Service: Reprezentuje twoją aplikację i działa w planie App Service.
   • Virtual network: Zintegrowana z aplikacją usługi App Service i izoluje ruch sieciowy zaplecza.
   • Private endpoints: Punkty dostępu do skarbca kluczy, serwera baz danych i pamięci podręcznej Redis w sieci wirtualnej.
   • Interfejsy sieciowe: Reprezentują prywatne adresy IP, po jednym dla każdego z prywatnych punktów końcowych.
   • Serwer usługi Azure SQL Database: dostępny tylko zza jego prywatnego punktu końcowego.
   • Azure SQL Database: Baza danych i użytkownik są tworzone dla Ciebie na serwerze.
   • Azure Cache for Redis: Dostępny tylko zza jego prywatnego punktu końcowego.
   • Key vault: Dostępne tylko z prywatnego punktu końcowego. Używany do zarządzania tajemnicami dla aplikacji App Service.
   • Strefy prywatne DNS: Umożliwiają rozwiązywanie DNS skarbca kluczy, serwera baz danych i pamięci podręcznej Redis w sieci wirtualnej.

   Gdy polecenie zakończy tworzenie zasobów i wdrażanie kodu aplikacji po raz pierwszy, wdrożona przykładowa aplikacja jeszcze nie działa, ponieważ musisz wprowadzić drobne zmiany, aby połączyć ją z bazą danych w Azure.

Masz problemy? Sprawdź sekcję rozwiązywania problemów.

3. Zweryfikuj ciągi połączeń

Wskazówka

Domyślny ciąg połączenia z bazą danych SQL używa uwierzytelniania SQL. Aby uzyskać bardziej bezpieczne uwierzytelnianie bez hasła, zobacz Jak zmienić połączenie usługi SQL Database, aby zamiast tego używać tożsamości zarządzanej?

Szablon AZD, którego używasz, już wygenerował dla Ciebie zmienne połączenia jako ustawienia aplikacji i wyświetla je w terminalu dla Twojej wygody. Ustawienia aplikacji są jednym ze sposobów na nieprzechowywanie tajnych danych połączeń w repozytorium kodu.

1. W wyjściu AZD znajdź ustawienia AZURE_SQL_CONNECTIONSTRING i AZURE_REDIS_CONNECTIONSTRING. Wyświetlane są tylko nazwy ustawień. Wyglądają tak w wynikach AZD.

    App Service app has the following connection strings:
        - AZURE_SQL_CONNECTIONSTRING
        - AZURE_REDIS_CONNECTIONSTRING
        - AZURE_KEYVAULT_RESOURCEENDPOINT
        - AZURE_KEYVAULT_SCOPE
    

   AZURE_SQL_CONNECTIONSTRING zawiera łańcuch połączenia do bazy danych SQL w Azure, a AZURE_REDIS_CONNECTIONSTRING zawiera łańcuch połączenia do pamięci podręcznej Azure Redis. Należy ich użyć w swoim kodzie później.

2. Dla Twojej wygody szablon AZD pokazuje bezpośredni link do strony ustawień aplikacji. Znajdź link i otwórz go w nowej karcie przeglądarki.

Masz problemy? Sprawdź sekcję rozwiązywania problemów.

4. Zmodyfikuj przykładowy kod i wdroż ponownie

Za pomocą narzędzia GitHub Copilot

1. W przestrzeni kodowej GitHub, rozpocznij nową sesję czatu, wybierając widok Chat, a następnie wybierając +.

2. Zapytaj: "@workspace Jak aplikacja łączy się z bazą danych i pamięcią podręczną?". Copilot może podać kilka wyjaśnień dotyczących MyDatabaseContext klasy i sposobu jej konfiguracji w Program.cs.

3. Zapytaj: "W trybie produkcyjnym chcę, aby aplikacja korzystała z parametru połączenia o nazwie AZURE_SQL_CONNECTIONSTRING dla bazy danych i parametru ustawień aplikacji o nazwie AZURE_REDIS_CONNECTIONSTRING*". Copilot może dać sugestię kodu podobną do tej w poniższych krokach w opcji 2: bez narzędzia GitHub Copilot i nawet poinformować Cię o zmianie w pliku Program.cs.

4. Otwórz Program.cs w eksploratorze i dodaj proponowany kod.

   GitHub Copilot nie daje za każdym razem tej samej odpowiedzi i nie zawsze jest poprawny. Być może będziesz musiał zadać więcej pytań, aby dopracować odpowiedź. Aby uzyskać wskazówki, zobacz Co mogę zrobić z GitHub Copilot w mojej przestrzeni kodowej?.

Bez narzędzia GitHub Copilot

1. W eksploratorze otwórz Program.cs.

2. W metodzie contextIntialized() znajdź zakomentowany kod (linie 12-21) i odkomentuj go.

   else
   {
       builder.Services.AddDbContext<MyDatabaseContext>(options =>
           options.UseSqlServer(builder.Configuration.GetConnectionString("AZURE_SQL_CONNECTIONSTRING")));
       builder.Services.AddStackExchangeRedisCache(options =>
       {
       options.Configuration = builder.Configuration["AZURE_REDIS_CONNECTIONSTRING"];
       options.InstanceName = "SampleInstance";
       });
   } 
   

   Kiedy aplikacja nie jest w trybie deweloperskim (tak jak w Azure App Service), ten kod łączy się z bazą danych za pomocą AZURE_SQL_CONNECTIONSTRING i łączy się z pamięcią podręczną Redis za pomocą ustawienia aplikacji AZURE_REDIS_CONNECTIONSTRING.

Przed wdrożeniem tych zmian nadal trzeba wygenerować pakiet migracji.

Masz problemy? Sprawdź sekcję rozwiązywania problemów.

5. Generowanie schematu bazy danych

W przypadku usługi SQL Database chronionej przez sieć wirtualną najprostszym sposobem uruchamiania migracji bazy danych jest sesja SSH z kontenerem usługi App Service. Jednak kontenery App Service Linux nie zawierają .NET SDK, więc najprostszym sposobem na przeprowadzenie migracji bazy danych jest przesłanie samodzielnego pakietu migracyjnego.

1. Wygeneruj pakiet migracji dla swojego projektu za pomocą następującego polecenia:

   dotnet ef migrations bundle --runtime linux-x64 -o migrationsbundle
   

   Wskazówka

   Przykładowa aplikacja (patrz DotNetCoreSqlDb.csproj) jest skonfigurowana do uwzględnienia tego pliku migrationsbundle. Podczas etapu azd package, migrationsbundle zostanie dodany do pakietu wdrożeniowego.

2. Zastosuj wszystkie zmiany z azd up.

   azd up
   

3. W danych wyjściowych usługi AZD znajdź adres URL sesji SSH i przejdź do niego w przeglądarce. Wygląda na to w danych wyjściowych:

    Open SSH session to App Service container at: <URL>
    

4. W sesji SSH uruchom następujące polecenia:

   cd /home/site/wwwroot
   ./migrationsbundle -- --environment Production
   

   Jeśli się uda, usługa App Service łączy się z bazą danych pomyślnie. Pamiętaj, że --environment Production odpowiada zmianom kodu wprowadzonych w Program.cs.

   Uwaga

   Tylko zmiany w plikach w /home mogą być zachowane po ponownym uruchomieniu aplikacji. Zmiany poza /home nie są zapisywane.

Masz problemy? Sprawdź sekcję rozwiązywania problemów.

6. Przejdź do aplikacji

1. W wynikach AZD znajdź URL swojej aplikacji i otwórz go w przeglądarce. URL wygląda tak w wyniku AZD:

    Deploying services (azd deploy)
   
      (✓) Done: Deploying service web
      - Endpoint: <URL>
    

2. Dodaj kilka zadań do listy.

   

   Gratulacje, uruchamiasz aplikację webową w usłudze Azure App Service, z bezpiecznym połączeniem z Azure SQL Database.

Masz problemy? Sprawdź sekcję rozwiązywania problemów.

7. Przesyłanie dzienników diagnostycznych

Usługa Azure App Service może przechwytywać dzienniki konsoli, aby pomóc w diagnozowaniu problemów z Twoją aplikacją. Dla wygody szablon AZD już umożliwił logowanie do lokalnego systemu plików i wysyła logi do przestrzeni roboczej Log Analytics.

Przykładowa aplikacja zawiera standardowe instrukcje logowania, aby zademonstrować tę możliwość, jak pokazano w poniższym fragmencie.

public async Task<IActionResult> Index()
{
    var todoItems = await _cache.GetAsync(_TodoItemsCacheKey);
    if (todoItems != null)
    {
        _logger.LogInformation("Data from cache.");
        var todoList = JsonConvert.DeserializeObject<List<Todo>>(Encoding.UTF8.GetString(todoItems));
        return View(todoList);
    }
    else
    {
        _logger.LogInformation("Data from database.");
        var todoList = await _context.Todo.ToListAsync();
        var serializedTodoList = JsonConvert.SerializeObject(todoList);
        await _cache.SetAsync(_TodoItemsCacheKey, Encoding.UTF8.GetBytes(serializedTodoList));
        return View(todoList);
    }
}

W wyniku AZD znajdź link do strumieniowania dzienników App Service i otwórz go w przeglądarce. Link wygląda tak w wyniku AZD.

Stream App Service logs at: <URL>

Dowiedz się więcej o rejestrowaniu w aplikacjach .NET w serii dotyczącej Włącz monitorowanie Azure OpenTelemetry dla aplikacji .NET, Node.js, Python i Java.

Masz problemy? Sprawdź sekcję rozwiązywania problemów.

8. Posprzątaj zasoby

Aby usunąć wszystkie zasoby Azure w bieżącym środowisku wdrożeniowym, uruchom azd down i postępuj zgodnie z wyświetlanymi instrukcjami.

azd down

Rozwiązywanie problemów

• Widok wdrożenia portalu dla bazy danych Azure SQL pokazuje status Konflikt
• W portalu Azure interfejs użytkownika strumienia dziennika dla aplikacji internetowej pokazuje błędy sieciowe
• Sesja SSH w przeglądarce pokazuje SSH CONN CLOSED
• Strona strumienia logów portalu Connected! pokazuje, ale nie ma logów

Widok wdrażania portalu dla usługi Azure SQL Database przedstawia stan konfliktu

W zależności od twojej subskrypcji i regionu, który wybierzesz, możesz zobaczyć status wdrażania dla Azure SQL Database jako Conflict, z następującą wiadomością w szczegółach operacji:

Location '<region>' is not accepting creation of new Windows Azure SQL Database servers at this time.

Ten błąd najprawdopodobniej wynika z ograniczeń nałożonych na Twój abonament dla wybranego regionu. Spróbuj wybrać inny region wdrożenia.

W portalu Azure, interfejs użytkownika strumienia logów dla aplikacji webowej pokazuje błędy sieciowe.

Ten błąd może zostać wyświetlony:

Unable to open a connection to your app. This may be due to any network security groups or IP restriction rules that you have placed on your app. To use log streaming, please make sure you are able to access your app directly from your current network.

To jest zwykle przejściowy błąd, który pojawia się przy pierwszym uruchomieniu aplikacji. Poczekaj kilka minut i sprawdź ponownie.

Sesja SSH w przeglądarce pokazuje SSH CONN CLOSED

Uruchomienie kontenera systemu Linux trwa kilka minut. Poczekaj kilka minut i sprawdź ponownie.

Strona logów w portalu pokazuje Connected!, ale brak logów

Po skonfigurowaniu dzienników diagnostycznych aplikacja zostanie ponownie uruchomiona. Może być konieczne odświeżenie strony, aby zmiany zostały zastosowane w przeglądarce.

Najczęściej zadawane pytania

• Ile kosztuje ta konfiguracja?
• Jak nawiązać połączenie z serwerem usługi Azure SQL Database zabezpieczonym za siecią wirtualną przy użyciu innych narzędzi?
• Jak lokalne tworzenie aplikacji działa z GitHub Actions?
• Jak debugować błędy podczas wdrażania za pomocą GitHub Actions?
• Jak zmienić połączenie usługi SQL Database, aby zamiast tego używać tożsamości zarządzanej?
• Nie mam uprawnień do tworzenia tożsamości przypisanej przez użytkownika
• Co mogę zrobić za pomocą narzędzia GitHub Copilot w swojej przestrzeni kodu?

Ile kosztuje ta konfiguracja?

Cennik dla utworzonych zasobów wygląda następująco:

• Plan usługi App Service jest tworzony w warstwie Podstawowej i może być skalowany w górę lub w dół. Zobacz cennik usługi App Service.
• Baza danych Azure SQL jest tworzona w warstwie ogólnego przeznaczenia, bezserwerowej na sprzęcie serii Standard z minimalną liczbą rdzeni. Jest niewielki koszt i można to rozprowadzać do innych regionów. Możesz dodatkowo zminimalizować koszty, zmniejszając maksymalny rozmiar, lub zwiększyć skalę, dostosowując poziom obsługi, poziom obliczeniowy, konfigurację sprzętową, liczbę rdzeni, rozmiar bazy danych oraz redundancję strefy. Zobacz cennik Azure SQL Database.
• Azure Cache dla Redis został utworzony w warstwie Basic z najmniejszym rozmiarem pamięci podręcznej. Posiada niewielki koszt związany z tą opcją. Możesz zwiększyć skalę do wyższych poziomów wydajności, aby zapewnić wyższą dostępność, klasteryzację oraz inne funkcje. Zobacz cennik usługi Azure Cache for Redis.
• Wirtualna sieć nie generuje opłat, chyba że skonfigurujesz dodatkową funkcjonalność, taką jak peering. Zobacz Cennik usługi Azure Virtual Network.
• Prywatna strefa DNS wiąże się z niewielkimi opłatami. Zobacz Cennik usługi Azure DNS.

Jak nawiązać połączenie z serwerem Azure SQL Database, który jest zabezpieczony za wirtualną siecią, używając innych narzędzi?

• Aby uzyskać podstawowy dostęp z narzędzia wiersza poleceń, możesz uruchomić sqlcmd z terminalu SSH aplikacji. Kontener aplikacji nie zawiera sqlcmd, więc musisz zainstalować go ręcznie. Pamiętaj, że zainstalowany klient nie zachowuje się po ponownym uruchomieniu aplikacji.
• Aby połączyć się z klienta SQL Server Management Studio lub z Visual Studio, twoja maszyna musi znajdować się w wirtualnej sieci. Na przykład może to być maszyna wirtualna Azure (VM), która jest podłączona do jednej z podsieci, albo maszyna w sieci lokalnej, która ma połączenie VPN typu site-to-site z wirtualną siecią Azure.

Jak działa lokalne rozwijanie aplikacji z GitHub Actions?

Jako przykład weź plik workflow wygenerowany automatycznie z usługi App Service, każdy git push rozpoczyna nowe uruchomienie procesu budowy i wdrażania. Z lokalnej kopii repozytorium GitHub wprowadzisz żądane aktualizacje i prześlesz je do GitHub. Przykład:

git add .
git commit -m "<some-message>"
git push origin main

Jak debugować błędy podczas wdrażania za pomocą GitHub Actions?

Jeśli krok nie powiedzie się w automatycznie wygenerowanym pliku przepływu pracy GitHub, spróbuj zmodyfikować nieudaną komendę, aby wygenerować bardziej szczegółowy output. Na przykład, za pomocą opcji dotnet, możesz uzyskać więcej danych wyjściowych z dowolnego polecenia -v. Zatwierdź i wypchnij zmiany, aby uruchomić kolejne wdrożenie dla usługi App Service.

Nie mam uprawnień do utworzenia tożsamości przypisanej przez użytkownika.

Zobacz Konfiguracja wdrożenia GitHub Actions z Centrum wdrożeń.

Jak zmienić połączenie z bazą danych SQL, aby zamiast tego używać zarządzanej tożsamości?

Domyślny ciąg połączenia z bazą danych SQL jest zarządzany przez Service Connector, o nazwie defaultConnector, i wykorzystuje uwierzytelnianie SQL. Aby zastąpić go połączeniem używającym zarządzanej tożsamości, uruchom następujące polecenia w cloud shell po zastąpieniu symboli zastępczych.

az extension add --name serviceconnector-passwordless --upgrade
az sql server update --enable-public-network true
az webapp connection delete sql --connection defaultConnector --resource-group <group-name> --name <app-name>
az webapp connection create sql --connection defaultConnector --resource-group <group-name> --name <app-name> --target-resource-group <group-name> --server <database-server-name> --database <database-name> --client-type dotnet --system-identity --config-connstr true
az sql server update --enable-public-network false

Domyślnie, polecenie az webapp connection create sql --client-type dotnet --system-identity --config-connstr wykonuje następujące czynności:

• Ustawia Twojego użytkownika jako administratora tożsamości Microsoft Entra ID serwera bazy danych SQL.
• Utwórz zarządzaną tożsamość przypisaną przez system i nadaj jej dostęp do bazy danych.
• Generuje bezhasłowy ciąg połączenia o nazwie AZURE_SQL_CONNECTIONGSTRING, którego Twoja aplikacja już używa na końcu tego samouczka.

Twoja aplikacja powinna teraz mieć połączenie z bazą danych SQL. Aby uzyskać więcej informacji, zobacz Tutorial: Connect to Azure databases from App Service without secrets using a managed identity.

Wskazówka

Nie chcesz włączyć połączenia z siecią publiczną? Możesz pominąć az sql server update --enable-public-network true uruchamiając polecenia z Azure cloud shell zintegrowanego z Twoją wirtualną siecią, jeśli masz przypisaną rolę Owner w ramach swojej subskrypcji.

Aby przyznać tożsamości wymagany dostęp do bazy danych zabezpieczonej przez sieć wirtualną, az webapp connection create sql potrzebuje bezpośredniego połączenia z serwerem bazy danych z uwierzytelnianiem w Entra ID. Domyślnie, powłoka chmurowa Azure nie ma dostępu do zabezpieczonej sieciowo bazy danych.

Co mogę zrobić z GitHub Copilot w mojej przestrzeni kodowej?

Możliwe, że zauważyłeś, że widok czatu GitHub Copilot był już dostępny, gdy tworzyłeś przestrzeń kodową. Dla Twojej wygody dołączamy rozszerzenie czatu Copilot w usłudze GitHub w definicji kontenera (zobacz .devcontainer/devcontainer.json). Jednakże musisz mieć konto GitHub Copilot (dostępna 30-dniowa wersja próbna).

Kilka wskazówek dla Ciebie, gdy rozmawiasz z GitHub Copilot:

• W ramach jednej sesji czatu pytania i odpowiedzi wzajemnie się uzupełniają, a ty możesz dostosować swoje pytania, aby precyzyjnie dopasować odpowiedź, którą otrzymujesz.
• Domyślnie GitHub Copilot nie ma dostępu do żadnego pliku w twoim repozytorium. Aby zadawać pytania dotyczące pliku, najpierw otwórz plik w edytorze.
• Aby umożliwić GitHub Copilot dostęp do wszystkich plików w repozytorium podczas przygotowywania odpowiedzi, rozpocznij pytanie od @workspace. Aby uzyskać więcej informacji, zobacz Use the @workspace agent.
• Podczas sesji czatu, GitHub Copilot może sugerować zmiany i (za pomocą @workspace) nawet wskazać, gdzie te zmiany wprowadzić, ale nie może ich wprowadzać za ciebie. To od Ciebie zależy, czy dodasz sugerowane zmiany i je przetestujesz.

Oto kilka innych rzeczy, które możesz powiedzieć, aby doprecyzować otrzymaną odpowiedź:

• Chcę, aby ten kod działał tylko w trybie produkcyjnym.
• Chcę, aby ten kod działał tylko w Azure App Service, a nie lokalnie.
• Parametr --output-path wydaje się nie być obsługiwany.

Powiązana zawartość

Przejdź do następnego samouczka, aby dowiedzieć się, jak zabezpieczyć swoją aplikację za pomocą niestandardowej domeny i certyfikatu.

  Zabezpiecz za pomocą niestandardowej domeny i certyfikatu

Lub sprawdź inne zasoby:

Samouczek: Połączenie z bazą danych SQL z usługi App Service bez użycia tajnych danych za pomocą zarządzanej tożsamości

Konfigurowanie aplikacji ASP.NET Core