Konfigurowanie magazynu i baz danych
Często część procesu wdrażania wymaga połączenia z bazami danych lub usługami magazynu. To połączenie może być konieczne do zastosowania schematu bazy danych, dodania niektórych danych referencyjnych do tabeli bazy danych lub przekazania niektórych obiektów blob. W tej lekcji dowiesz się, jak rozszerzyć potok w celu pracy z usługami danych i magazynowania.
Konfigurowanie baz danych z potoku
Wiele baz danych ma schematy, które reprezentują strukturę danych zawartych w bazie danych. Często dobrym rozwiązaniem jest zastosowanie schematu do bazy danych z potoku wdrażania. Ta praktyka pomaga zapewnić, że wszystkie potrzeby rozwiązania są wdrażane razem. Gwarantuje również, że w przypadku wystąpienia problemu podczas stosowania schematu potok wyświetla błąd. Błąd umożliwia rozwiązanie problemu i ponowne wdrożenie.
Podczas pracy z usługą Azure SQL należy zastosować schematy bazy danych, łącząc się z serwerem bazy danych i wykonując polecenia przy użyciu skryptów SQL. Te polecenia to operacje płaszczyzny danych. Potok musi uwierzytelniać się na serwerze bazy danych, a następnie wykonywać skrypty. Usługa Azure Pipelines udostępnia SqlAzureDacpacDeployment zadanie, które może łączyć się z serwerem bazy danych Azure SQL Database i wykonywać polecenia.
Niektóre inne usługi danych i magazynowania nie muszą być konfigurowane przy użyciu interfejsu API płaszczyzny danych. Na przykład podczas pracy z usługą Azure Cosmos DB dane są przechowywane w kontenerze. Kontenery można skonfigurować przy użyciu płaszczyzny sterowania bezpośrednio z poziomu pliku Bicep. Podobnie można wdrażać większość aspektów kontenerów obiektów blob usługi Azure Storage i zarządzać nimi w ramach Bicep. W następnym ćwiczeniu zobaczysz przykład tworzenia kontenera obiektów blob na podstawie Bicep.
Dodaj dane
Wiele rozwiązań wymaga dodania danych referencyjnych do baz danych lub kont magazynu przed ich pracą. Potoki mogą być dobrym miejscem do dodawania tych danych. Po uruchomieniu potoku środowisko jest w pełni skonfigurowane i gotowe do użycia.
Warto również mieć przykładowe dane w bazach danych, szczególnie w środowiskach nieprodukcyjnych. Przykładowe dane pomagają testerom i innym osobom korzystającym z tych środowisk natychmiast przetestować rozwiązanie. Te dane mogą obejmować przykładowe produkty lub takie rzeczy jak fałszywe konta użytkowników. Ogólnie rzecz biorąc, nie chcesz dodawać tych danych do środowiska produkcyjnego.
Podejście używane do dodawania danych zależy od używanej usługi. Na przykład:
- Aby dodać dane do bazy danych Azure SQL Database, musisz wykonać skrypt, podobnie jak konfigurowanie schematu.
- Aby wstawić dane w usłudze Azure Cosmos DB, musisz uzyskać dostęp do interfejsu API płaszczyzny danych, co może wymagać napisania kodu niestandardowego skryptu.
- Aby przekazać obiekty blob do kontenera obiektów blob usługi Azure Storage, możesz użyć różnych narzędzi ze skryptów potoku, w tym aplikacji wiersza polecenia narzędzia AzCopy, programu Azure PowerShell lub interfejsu wiersza polecenia platformy Azure. Każde z tych narzędzi rozumie, jak uwierzytelniać się w usłudze Azure Storage w Twoim imieniu oraz jak nawiązać połączenie z interfejsem API płaszczyzny danych w celu przekazania obiektów blob.
Idempotencja
Jedną z cech potoków wdrażania i infrastruktury jako kodu jest możliwość ponownego wdrożenia bez żadnych negatywnych skutków ubocznych. Na przykład po ponownym wdrożeniu wcześniej wdrożonego pliku Bicep usługa Azure Resource Manager porównuje przesłany plik z istniejącym stanem zasobów platformy Azure. Jeśli nie ma żadnych zmian, usługa Resource Manager nic nie robi. Możliwość ponownego wykonania operacji wielokrotnie jest nazywana idempotencją. Dobrym rozwiązaniem jest upewnienie się, że skrypty i inne kroki potoku są idempotentne.
Idempotencja jest szczególnie ważna w przypadku interakcji z usługami danych, ponieważ zachowują one stan. Wyobraź sobie, że wstawiasz przykładowego użytkownika do tabeli bazy danych z potoku. Jeśli nie jesteś ostrożny, za każdym razem, gdy uruchamiasz potok, zostanie utworzony nowy przykładowy użytkownik. Ten wynik prawdopodobnie nie jest odpowiedni.
W przypadku stosowania schematów do bazy danych Azure SQL Database można użyć pakietu danych nazywanego również plikiem DACPAC w celu wdrożenia schematu. Potok tworzy plik DACPAC z kodu źródłowego i tworzy artefakt potoku, podobnie jak w przypadku aplikacji. Następnie etap wdrażania w potoku publikuje plik DACPAC w bazie danych:
Po wdrożeniu pliku DACPAC zachowuje się w sposób idempotentny. Porównuje ona stan docelowy bazy danych z stanem zdefiniowanym w pakiecie. W wielu sytuacjach oznacza to, że nie trzeba pisać skryptów, które są zgodne z zasadą idempotencji, ponieważ narzędzie obsługuje je za Ciebie. Niektóre narzędzia dla usług Azure Cosmos DB i Azure Storage również działają prawidłowo.
Jednak podczas tworzenia przykładowych danych w bazie danych Azure SQL Database lub innej usługi magazynu, która nie działa automatycznie w sposób idempotentny. Dobrym rozwiązaniem jest napisanie skryptu, aby utworzyć dane tylko wtedy, gdy jeszcze nie istnieje.
Ważne jest również, aby rozważyć, czy może być konieczne wycofanie wdrożeń, takich jak ponowne uruchomienie starszej wersji potoku wdrażania. Wycofywanie zmian danych może stać się skomplikowane, dlatego należy dokładnie rozważyć, jak działa rozwiązanie, jeśli trzeba wycofać.
Bezpieczeństwo sieci
Czasami można zastosować ograniczenia sieci do niektórych zasobów platformy Azure. Te ograniczenia mogą wymuszać reguły dotyczące żądań wysyłanych do płaszczyzny danych zasobu, takich jak:
- Ten serwer bazy danych jest dostępny tylko z określonej listy adresów IP.
- To konto magazynu jest dostępne tylko z zasobów wdrożonych w określonej sieci wirtualnej.
Ograniczenia sieci są powszechne w przypadku baz danych, ponieważ może się wydawać, że w Internecie nie ma potrzeby nawiązywania połączenia z serwerem bazy danych.
Jednak ograniczenia sieci mogą również utrudnić potokom wdrażania pracę z płaszczyznami danych zasobów. Jeśli używasz agenta potoku hostowanego przez firmę Microsoft, jego adres IP nie może być łatwo znany z wyprzedzeniem i może zostać przypisany z dużej puli adresów IP. Ponadto agenci potoku hostowanego przez firmę Microsoft nie mogą być połączeni z własnymi sieciami wirtualnymi.
Niektóre zadania usługi Azure Pipelines, które ułatwiają wykonywanie operacji płaszczyzny danych, mogą obejść te problemy. Na przykład SqlAzureDacpacDeployment zadanie:
Gdy używasz SqlAzureDacpacDeployment zadania do pracy z serwerem logicznym lub bazą danych azure SQL, używa jednostki
usługi potoku do nawiązywania połączenia z płaszczyzną sterowania dla serwera logicznego usługi Azure SQL. Aktualizuje zaporę, aby umożliwić agentowi potoku dostęp do serwera z jego adresu
IP. Następnie można pomyślnie przesłać plik DACPAC lub skrypt do wykonania
. Następnie zadanie automatycznie usuwa regułę zapory po zakończeniu.
W innych sytuacjach nie można utworzyć tego typu wyjątków. W takich okolicznościach rozważ użycie własnego agenta potoku, który działa na maszynie wirtualnej lub innym zasobie obliczeniowym, który kontrolujesz. Następnie można skonfigurować tego agenta, jednak jest to konieczne. Może on używać znanego adresu IP lub może być połączony z własną siecią wirtualną. W tym module nie omawiamy własnych agentów, ale udostępniamy linki do dodatkowych informacji na stronie Podsumowanie na końcu modułu.
Potok wdrażania
W następnym ćwiczeniu zaktualizujesz potok wdrażania, aby dodać nowe zadania w celu skompilowania składników bazy danych witryny internetowej, wdrożenia bazy danych i dodania danych inicjacji:
