Samouczek: wdrażanie aplikacji ASP.NET Core i Azure SQL Database do Azure App Service

W tym poradniku nauczysz się, jak wdrożyć aplikację ASP.NET Core wykorzystującą dane do Azure App Service i nawiązać połączenie z bazą danych Azure SQL. Wdrożysz również usługę pamięci podręcznej Redis, aby umożliwić działanie kodu buforującego w aplikacji. Azure App Service to wysoce skalowalna, samoobsługowa usługa hostingu sieci Web, która może łatwo wdrażać aplikacje w Windows lub Linux. Mimo że w tym samouczku jest używana aplikacja ASP.NET Core 8.0, proces jest taki sam w przypadku innych wersji ASP.NET Core.

Ważna

Azure Cache for Redis ogłosiła harmonogram wycofania wszystkich SKU. Zalecamy przeniesienie istniejących instancji usługi Azure Cache for Redis do usługi Azure Managed Redis, jak najszybciej.

Wskazówki dotyczące migracji:

• Migruj warstwy Podstawowa, Standardowa i Premium do usługi Azure Managed Redis
• Migrowanie warstwy Enterprise do usługi Azure Managed Redis

Aby uzyskać więcej informacji na temat przejścia na emeryturę:

• Wycofanie usługi Azure Cache for Redis: co należy wiedzieć i jak przygotować
• FAQ dotyczące zakończenia usługi Azure Cache for Redis

W tym poradniku nauczysz się, jak:

• Utwórz domyślnie bezpieczną architekturę usługi aplikacji, bazy danych SQL i pamięci podręcznej Redis.
• Zabezpieczanie tajnych danych połączenia za pomocą tożsamości zarządzanej i odwołań do Key Vault.
• Wdróż przykładową aplikację ASP.NET Core w usłudze App Service 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.
• Transmituj dzienniki diagnostyczne z platformy Azure.
• Zarządzanie aplikacją w portalu Azure.
• Aprowizuj tę samą architekturę i wdróż przy użyciu interfejsu wiersza polecenia dewelopera Azure.
• Zoptymalizuj przepływ pracy programowania przy użyciu GitHub Codespaces i GitHub Copilot.

Wymagania wstępne

• Konto Azure z aktywną subskrypcją. Jeśli nie masz konta Azure, możesz utworzyć je bezpłatnie.
• Konto GitHub. Możesz również bezpłatnie uzyskać jeden.
• Znajomość programowania ASP.NET Core.
• (opcjonalnie) Aby spró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 bezpłatnie.
• Azure Developer CLI zainstalowany. Możesz wykonać kroki opisane w Azure Cloud Shell ponieważ ma już zainstalowany interfejs wiersza polecenia dewelopera Azure.
• Znajomość programowania ASP.NET Core.
• (opcjonalnie) Aby spró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 w Azure, uruchom następujące polecenia w 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. Repozytorium sample dla Twojej wygody zawiera konfigurację kontenera dev. 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 GitHub codespace co oznacza, że przykład można uruchomić na dowolnym komputerze za pomocą przeglądarki internetowej.

Krok 1: W nowym oknie przeglądarki:

1. Zaloguj się do konta 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 żadnych 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 poprosić 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 utworzysz zasoby Azure. Kroki używane w tym samouczku umożliwiają utworzenie zestawu bezpiecznych domyślnie zasobów obejmujących usługę App Service, Azure SQL Database i pamięć podręczną 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. W tym miejscu należy wybrać wersję .NET do użycia dla 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 umożliwia grupowanie (w kontenerze logicznym) wszystkich zasobów Azure potrzebnych dla aplikacji.

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

Krok 1: W portalu Azure:

1. Na górnym pasku wyszukiwania wpisz app service.
2. Wybierz element oznaczony etykietą App Service pod nagłówkiem Usługi .
3. Wybierz pozycję Utwórz>aplikację internetową. Możesz również przejść bezpośrednio do kreatora tworzenia.

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

1. Nazwa: msdocs-core-sql-XYZ. Zostanie wygenerowana grupa zasobów o nazwie msdocs-core-sql-XYZ_group .
2. Stos wykonawczy: .NET 8 (LTS).
3. System operacyjny: Linux.
4. Region: preferowany region.
5. Plan systemu Linux: utwórz nowy i użyj nazwy msdocs-core-sql-XYZ.
6. Plan cenowy: Podstawowa B1. Gdy wszystko będzie gotowe, możesz skalować w górę do innej warstwy cenowej.

Krok 3:

1. Wybierz kartę Baza danych .
2. Wybierz pozycję Utwórz bazę danych.
3. W Silniku wybierz SQLAzure.
4. Utwórz pamięć podręczną Redis.
5. W polu Nazwa (w obszarze Pamięć podręczna) wprowadź nazwę pamięci podręcznej.
6. W SKU wybierz Podstawowa.

Krok 4:

1. Wybierz kartę Wdrożenie .
2. Włącz ciągłe wdrażanie.
3. W Organization wybierz alias GitHub.
4. W Repozytorium wybierz msdocs-app-service-sqldb-dotnetcore.
5. W Branch wybierz starter-no-infra.
6. Upewnij się, że uwierzytelnianie podstawowe jest wyłączone.
7. Wybierz opcję Recenzja i utwórz.
8. Po zakończeniu walidacji wybierz Utwórz.

Krok 5: Ukończenie wdrożenia trwa kilka minut. 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.
• Azure SQL Database server: Dostępny tylko zza jego prywatnego punktu końcowego.
• Azure SQL Database: baza danych i użytkownik są tworzone dla Ciebie na serwerze.
• Redis: dostępny wyłącznie z prywatnego punktu końcowego.
• Key vault: Dostępne tylko z prywatnego punktu końcowego. Używany do zarządzania tajemnicami dla aplikacji App Service.
• Prywatne strefy DNS: Włącz rozwiązywanie nazw DNS dla magazynu kluczy, serwera bazy danych i pamięci podręcznej Redis w wirtualnej sieci.

3. Zabezpiecz tajemnice połączenia

Kreator tworzenia wygenerował zmienną łączności już jako parametry połączenia .NET i ustawienia aplikacji. Najlepszą praktyką dotyczącą bezpieczeństwa jest całkowite unikanie przechowywania poufnych informacji w usłudze App Service. Przeniesiesz swoje tajne informacje do magazynu kluczy i zmienisz ustawienie aplikacji na referencje Key Vault za pomocą łączników usług.

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: Pobierz istniejący łańcuch 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 Value, znajdź część Password= na końcu ciągu.
4. Skopiuj ciąg hasła po Password= do późniejszego użycia. Ten łańcuch połączenia pozwala połączyć się z bazą danych SQL, zabezpieczoną prywatnym punktem końcowym. Wpisy tajne są jednak zapisywane bezpośrednio w aplikacji usługi App Service, co nie jest najlepsze. Podobnie, łańcuch połączeniowy pamięci podręcznej Redis w zakładce Ustawienia aplikacji zawiera wpis tajny. Zmienisz to.

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

1. Na górnym pasku wyszukiwania wpisz "key vault", a następnie wybierz pozycję Marketplace>Key Vault.
2. W obszarze Grupa zasobów wybierz pozycję msdocs-core-sql-XYZ_group.
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-XYZ_group.
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 Sieć wirtualna wybierz sieć wirtualną w grupie msdocs-core-sql-XYZ_group .
8. W obszarze Podsieć wybierz dostępną zgodną podsieć. Kreator aplikacji internetowej utworzył go dla Twojej wygody.
9. Kliknij przycisk OK.
10. 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 pozycję Przechowaj tajemnicę w Key Vault.
7. W obszarze Key Vault Connection wybierz pozycję Utwórz nowy. Nad oknem dialogowym edycji otwarte zostaje okno dialogowe Utwórz połączenie.

Krok 5: Ustanawianie połączenia Key Vault

1. W oknie dialogowym Utwórz połączenie dla połączenia z magazynem kluczy w Magazyn kluczy, 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. Po zakończeniu lista rozwijana Key Vault Connection automatycznie ją wybiera.
2. Wybierz Next: Networking.
3. 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.
4. Wybierz Zapisz. Poczekaj, aż pojawi się powiadomienie Aktualizacja zakończona pomyślnie.

Krok 7: Konfigurowanie łącznika usługi Redis do używania 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 pozycję Przechowaj tajemnicę w Key Vault.
4. W sekcji Key Vault Connection wybierz utworzony magazyn kluczy.
5. Wybierz Next: Networking.
6. Wybierz Skonfiguruj reguły zapory, aby umożliwić dostęp do docelowej usługi.
7. Wybierz Zapisz. Poczekaj, aż pojawi się powiadomienie Aktualizacja zakończona pomyślnie.

Krok 8: Weryfikowanie integracji 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 odniesienie do magazynu kluczy, ponieważ tajny wpis jest teraz zarządzany w magazynie kluczy.
3. Aby sprawdzić connection string dla usługi Redis, wybierz kartę Ustawienia aplikacji. Obok pozycji AZURE_REDIS_CONNECTIONSTRING wybierz pozycję Pokaż wartość. Wartość powinna być również @Microsoft.KeyVault(...).

zrzut ekranu

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 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 skonfigurujesz 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 do repozytorium GitHub uruchamia akcję budowania i wdrażania.

Krok 1: Wróć do obszaru kodu GitHub rozwidlenia przykładowego, uruchom git pull origin starter-no-infra. Ta akcja pobiera nowo zatwierdzony plik przepływu pracy do twojej przestrzeni kodu.

zrzut ekranu przedstawiający git pull wewnątrz przestrzeni roboczej GitHub.

Krok 2 (opcja 1: z 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ć wyjaśnienie dotyczące klasy MyDatabaseContext i sposobu jej konfiguracji w Program.cs.
3. Zapytaj: "W trybie produkcyjnym chcę, aby aplikacja korzystała z ciągu połączenia o nazwie AZURE_SQL_CONNECTIONSTRING dla bazy danych oraz z ustawienia aplikacji o nazwie AZURE_REDIS_CONNECTIONSTRING." Copilot może dać sugestię kodu podobną do tej w Opcji 2: bez GitHub Copilot w krokach, które następują, a nawet poinformować o zmianie w pliku Program.cs.
4. Otwórz Program.cs w eksploratorze i dodaj proponowany kod. GitHub Copilot nie daje tej samej odpowiedzi za każdym razem i nie zawsze jest poprawna. Być może będziesz musiał zadać więcej pytań, aby dopracować odpowiedź. Aby uzyskać porady, zobacz W co mogę zrobić z GitHub Copilot w mojej przestrzeni kodu?.

zrzut ekranu pokazujący, jak zadać pytanie w nowej sesji czatu GitHub Copilot.

Krok 2 (opcja 2: bez 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 3 (opcja 1: z GitHub Copilot):

1. Otwórz .github/workflows/starter-no-infra_msdocs-core-sql-XYZ w eksploratorze. Asystent tworzenia usługi App Service utworzył ten plik.
2. Podświetl dotnet publish krok i wybierz .
3. Zapytaj Copilota "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 tej samej odpowiedzi za każdym razem i nie zawsze jest poprawna. Być może będziesz musiał zadać więcej pytań, aby dopracować odpowiedź. Aby uzyskać porady, zobacz W co mogę zrobić z GitHub Copilot w mojej przestrzeni kodu?.

Zrzut ekranu przedstawiający użycie GitHub Copilot w pliku przepływu pracy GitHub.

Krok 3 (opcja 2: bez GitHub Copilot):

1. Otwórz .github/workflows/starter-no-infra_msdocs-core-sql-XYZ w eksploratorze. Kreator tworzenia usługi App Service utworzył ten plik
2. W kroku 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 migracji jest samodzielnym plikiem wykonywalnym, który można uruchomić w środowisku produkcyjnym bez konieczności używania zestawu .NET SDK. Kontener systemu Linux usługi App Service ma tylko środowisko uruchomieniowe .NET, a nie zestaw SDK .NET.

Krok 4:

1. Wybierz rozszerzenie Source Control.
2. W polu tekstowym wpisz komunikat zatwierdzenia, taki jak Configure Azure database and cache connections. Możesz też wybrać i pozwolić GitHub Copilot wygenerować komunikat 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 5: Wróć do strony 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 6: Przejdź do repozytorium GitHub i sprawdź, czy akcja GitHub jest uruchomiona. Plik przepływu pracy definiuje dwa oddzielne etapy: budowanie i wdrażanie. Poczekaj, aż uruchomienie na GitHub 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).

Zrzut ekranu

Krok 2: W sesji SSH:

1. Uruchom program cd /home/site/wwwroot. Oto wszystkie Twoje wdrożone pliki.
2. Uruchom pakiet migracji wygenerowany przez przepływ pracy GitHub z poleceniem ./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.

zrzut ekranu

Step 2: Dodaj kilka zadań do listy. Gratulacje, uruchamiasz aplikację internetową w Azure App Service z bezpieczną łącznością z Azure SQL Database.

Wskazówka

Przykładowa aplikacja implementuje wzorzec cache-aside. Gdy odwiedzisz widok danych po raz drugi lub ponownie załadujesz tę samą stronę po wprowadzeniu zmian danych, czas przetwarzania na stronie internetowej pokazuje krótszy czas, ponieważ ładuje dane z pamięci podręcznej zamiast bazy danych.

7. Przesyłanie dzienników diagnostycznych

Azure App Service 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 z subskrypcji Azure, usuwając grupę zasobów.

Krok 1: Na pasku wyszukiwania w górnej części 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. Tworzenie zasobów Azure i wdrażanie przykładowej aplikacji

W tym kroku utworzysz zasoby Azure i wdrożysz przykładową aplikację w App Service on Linux. Kroki używane w tym samouczku umożliwiają utworzenie zestawu bezpiecznych domyślnie zasobów obejmujących usługę App Service, usługę Azure SQL Database i pamięć podręczną Redis Cache.

Dev kontener ma już 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 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 wierszem polecenia:

   azd auth login
   

4. Utwórz niezbędne zasoby Azure i wdróż kod aplikacji za pomocą polecenia azd up. Postępuj zgodnie z monitem, aby wybrać żądaną subskrypcję i lokalizację 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. Gdy jest uruchomiona, polecenie udostępnia komunikaty dotyczące procesu aprowizacji 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ą architekturę o domyślnym zabezpieczeniu 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.
   • Azure SQL Database server: Dostępny tylko zza jego prywatnego punktu końcowego.
   • Azure SQL Database: baza danych i użytkownik są tworzone dla Ciebie na serwerze.
   • Redis: dostępny tylko przez prywatny punkt końcowy.
   • Key vault: Dostępne tylko z prywatnego punktu końcowego. Używany do zarządzania tajemnicami dla aplikacji App Service.
   • Prywatne strefy DNS: Włącz rozwiązywanie nazw DNS dla magazynu kluczy, serwera bazy danych i pamięci podręcznej Redis w wirtualnej sieci.

   Po zakończeniu tworzenia zasobów i wdrażaniu kodu aplikacji po raz pierwszy wdrożona przykładowa aplikacja nie działa jeszcze, ponieważ musisz wprowadzić niewielkie zmiany, aby połączyć się 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 do bazy 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 ciąg połączenia do bazy danych SQL na platformie Azure, a AZURE_REDIS_CONNECTIONSTRING zawiera ciąg połączenia do pamięci podręcznej Redis na platformie Azure. 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 GitHub codespace rozpocznij nową sesję czatu, wybierając Chat widok, a następnie wybierając pozycję +.

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

3. Zapytaj: "W trybie produkcyjnym chcę, aby aplikacja korzystała z łańcucha połączenia o nazwie AZURE_SQL_CONNECTIONSTRING dla bazy danych i ustawienia aplikacji o nazwie AZURE_REDIS_CONNECTIONSTRING*." Copilot może dać sugestię dotyczącą kodu podobną do tej w Opcja 2: bez GitHub Copilot z krokiem, którym należy podążać, oraz może nawet poinformować o naniesieniu zmian w pliku Program.cs.

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

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

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";
       });
   } 
   

   Gdy aplikacja nie jest w trybie programowania (na przykład w Azure App Service), ten kod łączy się z bazą danych przy użyciu AZURE_SQL_CONNECTIONSTRING i łączy się z pamięcią podręczną Redis przy użyciu 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 Linux w usłudze App Service nie zawierają zestawu SDK .NET, więc najprostszym sposobem na uruchamianie migracji bazy danych jest przesłanie samodzielnego pakietu migracji.

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 (zobacz 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ę internetową w Azure App Service z bezpieczną łącznością z Azure SQL Database.

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

7. Przesyłanie dzienników diagnostycznych

Azure App Service może przechwytywać dzienniki konsoli, aby ułatwić diagnozowanie problemów z aplikacją. Dla wygody szablon AZD już włączył logowanie w lokalnym systemie plików i przesyła dzienniki do obszaru roboczego 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 logowaniu w aplikacjach .NET w serii Enable Azure Monitor OpenTelemetry for .NET, Node.js, Python i Java applications.

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

8. Posprzątaj zasoby

Aby usunąć wszystkie zasoby Azure w bieżącym środowisku wdrażania, uruchom polecenie azd down i postępuj zgodnie z monitami.

azd down

Rozwiązywanie problemów

• W widoku wdrażania portalu dla Azure SQL Database jest wyświetlany stan konfliktów
• W portalu Azure interfejs użytkownika strumienia logów dla aplikacji internetowej pokazuje błędy w sieci
• 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 Azure SQL Database pokazuje stan konfliktów

W zależności od wybranej subskrypcji i regionu może zostać wyświetlony stan wdrożenia dla Azure SQL Database Conflict z następującym komunikatem w obszarze Szczegóły 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 strumienia dzienników dla aplikacji internetowej wyświetla błędy sieci.

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 połączyć się z serwerem Azure SQL Database zabezpieczonym za siecią wirtualną za pomocą innych narzędzi?
• Jak lokalne programowanie aplikacji współpracuje z GitHub Actions?
• Jak debugować błędy podczas wdrażania 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
• W co mogę zrobić z GitHub Copilot w mojej 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.
• Azure SQL Database jest utworzona w warstwie ogólnego przeznaczenia, bezserwerowej, na sprzęcie z 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 for Redis jest tworzony w warstwie Basic o minimalnym rozmiarze 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 Azure Cache for Redis. Aby uzyskać więcej informacji, zobacz Cennik usługi Azure Managed Redis.
• Wirtualna sieć nie generuje opłat, chyba że skonfigurujesz dodatkową funkcjonalność, taką jak peering. Zobacz cennik Azure Virtual Network.
• Prywatna strefa DNS wiąże się z niewielkimi opłatami. Zobacz cennik Azure DNS.

Jak połączyć się z serwerem Azure SQL Database zabezpieczonym za siecią wirtualną przy użyciu 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 nawiązać połączenie z klienta SQL Server Management Studio lub z Visual Studio, maszyna musi znajdować się w sieci wirtualnej. Na przykład może to być maszyna wirtualna Azure połączona z jedną z podsieci lub maszyna w sieci lokalnej, która ma połączenie VPN typu "lokalizacja-lokalizacja" z wirtualną siecią Azure.

W jaki sposób programowanie aplikacji lokalnych działa 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 lokalnego klonu repozytorium GitHub należy dokonać wymaganych aktualizacji, a następnie wypchnąć je do GitHub. Przykład:

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

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

Jeśli krok zakończy się niepowodzeniem w automatycznie wygenerowanym pliku przepływu pracy GitHub, spróbuj zmodyfikować nieudane polecenie, aby uzyskać bardziej szczegółowe dane wyjściowe. 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 Skonfiguruj wdrożenie GitHub Actions z Centrum wdrożeń.

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

Łącznik usługi zarządza domyślnym ciągiem połączenia do bazy danych SQL o nazwie defaultConnector i używa uwierzytelniania 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 użytkownika jako administratora 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 connection string bez hasła o nazwie AZURE_SQL_CONNECTIONGSTRING, której aplikacja używa już na końcu samouczka.

Twoja aplikacja powinna teraz mieć połączenie z bazą danych SQL. Aby uzyskać więcej informacji, zobacz Samouczek: Nawiązywanie połączenia z bazami danych Azure z usługi App Service bez danych poufnych przy użyciu tożsamości zarządzanej.

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ą siecią wirtualną, jeśli masz przypisanie roli Owner w ramach swojej subskrypcji.

Aby udzielić tożsamości wymaganego dostępu do bazy danych zabezpieczonej przez sieć wirtualną, az webapp connection create sql potrzebuje bezpośredniej łączności z serwerem bazy danych za pomocą uwierzytelniania Entra ID. Domyślnie usługa Azure Cloud Shell nie ma tego dostępu do bazy danych zabezpieczonej przez sieć.

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

Być może zauważyłeś, że widok czatu GitHub Copilot był już dostępny podczas tworzenia codespace. Dla Wygody dołączamy rozszerzenie czatu GitHub Copilot w definicji kontenera (zobacz .devcontainer/devcontainer.json). Potrzebujesz jednak konta GitHub Copilot (dostępna jest 30-dniowa bezpłatna wersja próbna).

Kilka wskazówek dotyczących rozmowy 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 repozytorium. Aby zadawać pytania dotyczące pliku, najpierw otwórz plik w edytorze.
• Aby umożliwić GitHub Copilot mieć 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.
• W sesji czatu GitHub Copilot może proponować zmiany oraz, za pomocą @workspace, wskazywać, gdzie je wprowadzić, ale nie ma możliwości wprowadzania zmian 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 był uruchamiany 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