Konfigurera lagring och databaser
En del av distributionsprocessen kräver ofta att du ansluter till databaser eller lagringstjänster. Den här anslutningen kan vara nödvändig för att tillämpa ett databasschema, lägga till vissa referensdata i en databastabell eller för att ladda upp vissa blobar. I den här lektionen får du lära dig mer om hur du kan utöka din pipeline till att fungera med data- och lagringstjänster.
Konfigurera dina databaser från en pipeline
Många databaser har scheman som representerar strukturen för de data som finns i databasen. Det är ofta en bra idé att tillämpa ett schema på databasen från distributionspipelinen. Den här metoden hjälper till att säkerställa att allt din lösning behöver distribueras tillsammans. Det säkerställer också att pipelinen visar ett fel om det uppstår ett problem när schemat tillämpas. Med felet kan du åtgärda problemet och distribuera om.
När du arbetar med Azure SQL måste du använda databasscheman genom att ansluta till databasservern och köra kommandon med hjälp av SQL-skript. Dessa kommandon är dataplansåtgärder. Din pipeline måste autentisera till databasservern och sedan köra skripten. Azure Pipelines tillhandahåller den SqlAzureDacpacDeployment uppgift som kan ansluta till en Azure SQL-databasserver och köra kommandon.
Vissa andra data- och lagringstjänster behöver inte konfigureras med hjälp av ett API för dataplan. När du till exempel arbetar med Azure Cosmos DB lagrar du dina data i en container. Du kan konfigurera dina containrar med hjälp av kontrollplanet direkt från din Bicep-fil. På samma sätt kan du distribuera och hantera de flesta aspekter av Azure Storage-blobcontainrar i Bicep. I nästa övning visas ett exempel på hur du skapar en blobcontainer från Bicep.
Lägg till data
Många lösningar kräver att referensdata läggs till i deras databaser eller lagringskonton innan de fungerar. Pipelines kan vara en bra plats för att lägga till dessa data. När pipelinen har körts är din miljö helt konfigurerad och redo att användas.
Det är också bra att ha exempeldata i dina databaser, särskilt för icke-produktionsmiljöer. Exempeldata hjälper testare och andra personer som använder dessa miljöer att kunna testa din lösning omedelbart. Dessa data kan innehålla exempelprodukter eller saker som falska användarkonton. I allmänhet vill du inte lägga till dessa data i produktionsmiljön.
Vilken metod du använder för att lägga till data beror på vilken tjänst du använder. Till exempel:
- Om du vill lägga till data i en Azure SQL-databas måste du köra ett skript, ungefär som att konfigurera ett schema.
- Om du vill infoga data i en Azure Cosmos DB måste du komma åt dess API för dataplan, vilket kan kräva att du skriver anpassad skriptkod.
- Om du vill ladda upp blobar till en Azure Storage-blobcontainer kan du använda olika verktyg från pipelineskript, inklusive kommandoradsprogrammet AzCopy, Azure PowerShell eller Azure CLI. Vart och ett av dessa verktyg förstår hur du autentiserar till Azure Storage åt dig och hur du ansluter till dataplans-API:et för att ladda upp blobar.
Idempotens
En av egenskaperna hos distributionspipelines och infrastruktur som kod är att du bör kunna distribuera om upprepade gånger utan några negativa biverkningar. När du till exempel distribuerar om en tidigare distribuerad Bicep-fil jämför Azure Resource Manager filen du skickade med det befintliga tillståndet för dina Azure-resurser. Om det inte finns några ändringar gör Resource Manager ingenting. Möjligheten att köra en åtgärd igen upprepade gånger kallas idempotens. Det är en bra idé att se till att dina skript och andra pipelinesteg är idempotenter.
Idempotens är särskilt viktigt när du interagerar med datatjänster, eftersom de underhåller tillstånd. Anta att du infogar en exempelanvändare i en databastabell från pipelinen. Om du inte är försiktig skapas en ny exempelanvändare varje gång du kör pipelinen. Det här resultatet är förmodligen inte det du vill ha.
När du tillämpar scheman på en Azure SQL-databas kan du använda ett datapaket, även kallat en DACPAC-fil, för att distribuera schemat. Din pipeline skapar en DACPAC-fil från källkoden och skapar en pipelineartefakt, precis som med ett program. Distributionssteget i pipelinen publicerar sedan DACPAC-filen till databasen:
När en DACPAC-fil distribueras fungerar den på ett idempotent sätt. Den jämför måltillståndet för databasen med det tillstånd som definierats i paketet. I många situationer innebär det att du inte behöver skriva skript som följer principen om idempotens eftersom verktygen hanterar det åt dig. En del av verktygen för Azure Cosmos DB och Azure Storage fungerar också korrekt.
Men när du skapar exempeldata i en Azure SQL-databas eller en annan lagringstjänst som inte fungerar automatiskt på ett idempotent sätt. Det är en bra idé att skriva skriptet så att det bara skapar data om de inte redan finns.
Det är också viktigt att överväga om du kan behöva återställa distributioner, till exempel genom att köra en äldre version av en distributionspipeline igen. Återställning av ändringar i dina data kan bli komplicerad, så tänk noga på hur din lösning fungerar om du behöver återställa.
Nätverkssäkerhet
Ibland kan du använda nätverksbegränsningar för vissa av dina Azure-resurser. Dessa begränsningar kan framtvinga regler om begäranden som görs till dataplanet för en resurs, till exempel:
- Den här databasservern är endast tillgänglig från en angiven lista med IP-adresser.
- Det här lagringskontot är endast tillgängligt från resurser som distribueras i ett specifikt virtuellt nätverk.
Nätverksbegränsningar är vanliga med databaser, eftersom det kan verka som om det inte finns något behov av att något på Internet ansluter till en databasserver.
Nätverksbegränsningar kan dock också göra det svårt för dina distributionspipelines att arbeta med dina resursdataplan. När du använder en Microsoft-värdbaserad pipelineagent kan ip-adressen inte vara lätt att känna till i förväg och den kan tilldelas från en stor pool med IP-adresser. Dessutom kan Microsoft-värdbaserade pipelineagenter inte anslutas till dina egna virtuella nätverk.
Några av de Azure Pipelines-uppgifter som hjälper dig att utföra dataplansåtgärder kan lösa dessa problem. Till exempel uppgiften SqlAzureDacpacDeployment :
När du använder SqlAzureDacpacDeployment uppgiften för att arbeta med en logisk Azure SQL-server eller databas använder den pipelinens tjänsthuvudnamn
för att ansluta till kontrollplanet för den logiska Azure SQL-servern. Den uppdaterar brandväggen så att pipelineagenten kan komma åt servern från dess IP-adress
. Sedan kan den skicka DACPAC-filen eller skriptet för körning
. Uppgiften tar sedan automatiskt bort brandväggsregeln när den är klar.
I andra situationer går det inte att skapa dessa typer av undantag. Under dessa omständigheter bör du överväga att använda en lokalt installerad pipelineagent som körs på en virtuell dator eller någon annan beräkningsresurs som du styr. Du kan sedan konfigurera den här agenten hur du än behöver. Den kan använda en känd IP-adress eller anslutas till ditt eget virtuella nätverk. Vi diskuterar inte lokalt installerade agenter i den här modulen, men vi tillhandahåller länkar till mer information på sidan Sammanfattning i slutet av modulen.
Din distributionspipeline
I nästa övning uppdaterar du distributionspipelinen för att lägga till nya jobb för att skapa webbplatsens databaskomponenter, distribuera databasen och lägga till startdata:
