Opslag en databases configureren
Vaak vereist een deel van uw implementatieproces dat u verbinding maakt met databases of opslagservices. Deze verbinding kan nodig zijn om een databaseschema toe te passen, om enkele referentiegegevens toe te voegen aan een databasetabel of om sommige blobs te uploaden. In deze les leert u hoe u uw pijplijn kunt uitbreiden om te werken met gegevens- en opslagservices.
Uw databases configureren vanuit een pijplijn
Veel databases hebben schema's, die de structuur van de gegevens in de database vertegenwoordigen. Het is vaak een goed idee om een schema toe te passen op uw database vanuit uw implementatiepijplijn. Deze procedure helpt ervoor te zorgen dat alles wat uw oplossing nodig heeft, samen wordt geïmplementeerd. Het zorgt er ook voor dat als er een probleem is wanneer het schema wordt toegepast, uw pijplijn een fout weergeeft. Door de fout kunt u het probleem oplossen en herimplementeren.
Wanneer u met Azure SQL werkt, moet u databaseschema's toepassen door verbinding te maken met de databaseserver en opdrachten uit te voeren met behulp van SQL-scripts. Deze opdrachten zijn bewerkingen in het gegevensvlak. Uw pijplijn moet zich authenticeren bij de databaseserver en vervolgens de scripts uitvoeren. Azure Pipelines biedt de SqlAzureDacpacDeployment taak die verbinding kan maken met een Azure SQL-databaseserver en opdrachten kan uitvoeren.
Sommige andere gegevens- en opslagservices hoeven niet te worden geconfigureerd met behulp van een gegevensvlak-API. Wanneer u bijvoorbeeld met Azure Cosmos DB werkt, slaat u uw gegevens op in een container. U kunt uw containers configureren met behulp van het besturingsvlak, rechtstreeks vanuit uw Bicep-bestand. Op dezelfde manier kunt u de meeste aspecten van Azure Storage-blobcontainers in Bicep implementeren en beheren. In de volgende oefening ziet u een voorbeeld van het maken van een blobcontainer van Bicep.
Gegevens toevoegen
Voor veel oplossingen moeten referentiegegevens worden toegevoegd aan hun databases of opslagaccounts voordat ze werken. Pijplijnen kunnen een goede plek zijn om deze gegevens toe te voegen. Nadat de pijplijn is uitgevoerd, is uw omgeving volledig geconfigureerd en klaar voor gebruik.
Het is ook handig om voorbeeldgegevens in uw databases te hebben, met name voor niet-productieomgevingen. Voorbeeldgegevens helpen testers en andere personen die deze omgevingen gebruiken om uw oplossing onmiddellijk te testen. Deze gegevens kunnen voorbeeldproducten of zaken zijn zoals nepgebruikersaccounts. Over het algemeen wilt u deze gegevens niet toevoegen aan uw productieomgeving.
De methode die u gebruikt om gegevens toe te voegen, is afhankelijk van de service die u gebruikt. Bijvoorbeeld:
- Als u gegevens wilt toevoegen aan een Azure SQL-database, moet u een script uitvoeren, net zoals het configureren van een schema.
- Als u gegevens wilt invoegen in een Azure Cosmos DB, moet u toegang krijgen tot de GEGEVENSvlak-API. Hiervoor moet u mogelijk aangepaste scriptcode schrijven.
- Als u blobs wilt uploaden naar een Azure Storage-blobcontainer, kunt u verschillende hulpprogramma's van pijplijnscripts gebruiken, waaronder de AzCopy-opdrachtregeltoepassing, Azure PowerShell of Azure CLI. Elk van deze tools begrijpt hoe ze namens u kunnen verifiëren bij Azure Storage en hoe ze verbinding kunnen maken met de gegevensvlak-API om blobs te uploaden.
Idempotentie
Een van de kenmerken van implementatiepijplijnen en infrastructuur als code is dat u herhaaldelijk opnieuw moet kunnen implementeren zonder nadelige bijwerkingen. Wanneer u bijvoorbeeld een eerder geïmplementeerd Bicep-bestand opnieuw implementeert, vergelijkt Azure Resource Manager het bestand dat u hebt ingediend met de bestaande status van uw Azure-resources. Als er geen wijzigingen zijn, doet Resource Manager niets. De mogelijkheid om een bewerking herhaaldelijk opnieuw uit te voeren, wordt idempotentiegenoemd. Het is een goede gewoonte om ervoor te zorgen dat uw scripts en andere pijplijnstappen idempotent zijn.
Idempotentie is vooral belangrijk wanneer u communiceert met gegevensservices, omdat ze de status behouden. Stel dat u een voorbeeldgebruiker invoegt in een databasetabel vanuit uw pijplijn. Als u niet voorzichtig bent, wordt er telkens wanneer u de pijplijn uitvoert een nieuwe voorbeeldgebruiker gemaakt. Dit resultaat is waarschijnlijk niet wat u wilt.
Wanneer u schema's toepast op een Azure SQL-database, kunt u een gegevenspakket, ook wel een DACPAC-bestand genoemd, gebruiken om uw schema te implementeren. Uw pijplijn bouwt een DACPAC-bestand op basis van broncode en maakt een pijplijnartefact, net als bij een toepassing. Vervolgens publiceert de implementatiefase in uw pijplijn het DACPAC-bestand naar de database:
Wanneer een DACPAC-bestand wordt geïmplementeerd, gedraagt het zich op een idempotente manier. Hiermee wordt de doelstatus van uw database vergeleken met de status die in het pakket is gedefinieerd. In veel situaties betekent dit dat u geen scripts hoeft te schrijven die voldoen aan het principe van idempotentie, omdat de tooling dit voor u afhandelt. Sommige hulpprogramma's voor Azure Cosmos DB en Azure Storage werken ook correct.
Maar wanneer u voorbeeldgegevens maakt in een Azure SQL-database, of in een andere opslagservice die niet automatisch op een idempotente manier werkt. Het is een goede gewoonte om uw script zo te schrijven dat het de gegevens alleen aanmaakt als ze nog niet bestaan.
Het is ook belangrijk om na te gaan of u mogelijk implementaties moet terugdraaien, bijvoorbeeld door een oudere versie van een implementatiepijplijn opnieuw uit te voeren. Het terugdraaien van wijzigingen in uw gegevens kan ingewikkeld worden, dus overweeg zorgvuldig hoe uw oplossing werkt als u wilt terugdraaien.
Netwerkbeveiliging
Soms kunt u netwerkbeperkingen toepassen op sommige van uw Azure-resources. Deze beperkingen kunnen regels afdwingen voor aanvragen die zijn gedaan op het gegevensvlak van een resource, zoals:
- Deze databaseserver is alleen toegankelijk vanuit een opgegeven lijst met IP-adressen.
- Dit opslagaccount is alleen toegankelijk vanuit resources die zijn geïmplementeerd in een specifiek virtueel netwerk.
Netwerkbeperkingen zijn gebruikelijk voor databases, omdat het lijkt alsof er niets nodig is op internet om verbinding te maken met een databaseserver.
Netwerkbeperkingen kunnen het echter ook lastig maken voor uw implementatiepijplijnen om te werken met uw resources-gegevensvlakken. Wanneer u een door Microsoft gehoste pijplijnagent gebruikt, kan het IP-adres niet eenvoudig van tevoren bekend zijn en kan het worden toegewezen vanuit een grote groep IP-adressen. Bovendien kunnen door Microsoft gehoste pijplijnagents niet worden verbonden met uw eigen virtuele netwerken.
Sommige Azure Pipelines-taken waarmee u gegevensvlakbewerkingen kunt uitvoeren, kunnen deze problemen omzeilen. Bijvoorbeeld, de SqlAzureDacpacDeployment opdracht:
Wanneer u de SqlAzureDacpacDeployment taak gebruikt om te werken met een logische Azure SQL-server of -database, maakt de service-principal
van uw pijplijn verbinding met het controlevlak voor de logische Azure SQL-server. Hiermee wordt de firewall bijgewerkt zodat de pijplijnagent toegang heeft tot de server vanaf het IP-adres
. Vervolgens kan het DACPAC-bestand of -script met succes worden verzonden voor uitvoering
. De taak verwijdert vervolgens automatisch de firewallregel wanneer deze is voltooid.
In andere situaties is het niet mogelijk om deze soorten uitzonderingen te maken. In deze omstandigheden kunt u overwegen om een zelf-hostende pijplijnagent te gebruiken, die wordt uitgevoerd op een virtuele machine of een andere rekenresource die u beheert. U kunt deze agent vervolgens zo configureren dat u deze nodig hebt. Het kan een bekend IP-adres gebruiken of het kan worden verbonden met uw eigen virtuele netwerk. We bespreken geen zelf-gehoste agents in deze module, maar we bieden koppelingen naar meer informatie aan op de samenvattingspagina aan het einde van de module.
Uw implementatiepijplijn
In de volgende oefening werkt u uw implementatiepijplijn bij om nieuwe taken toe te voegen om de databaseonderdelen van uw website te bouwen, de database te implementeren en seed-gegevens toe te voegen:
