Continue integratie en levering voor een Azure Synapse Analytics-werkruimte

Continue integratie (CI) is het proces van het automatiseren van het bouwen en testen van code telkens wanneer een teamlid een wijziging doorvoert in versiebeheer. Continue levering (CD) is het proces van het bouwen, testen, configureren en implementeren van meerdere test- of faseringsomgevingen naar een productieomgeving.

In een Azure Synapse Analytics-werkruimte verplaatst CI/CD alle entiteiten van de ene omgeving (ontwikkeling, test, productie) naar een andere omgeving. Het promoveren van uw werkruimte naar een andere werkruimte is een tweedelig proces. Gebruik eerst een AZURE Resource Manager-sjabloon (ARM-sjabloon) om werkruimteresources (pools en werkruimten) te maken of bij te werken. Migreer vervolgens artefacten zoals SQL-scripts en notebooks, Spark-taakdefinities, pijplijnen, gegevenssets en andere artefacten met behulp van Synapse Workspace Deployment Tools in Azure DevOps of op GitHub.

In dit artikel wordt beschreven hoe u een Azure DevOps-releasepijplijn en GitHub Actions gebruikt om de implementatie van een Azure Synapse-werkruimte in meerdere omgevingen te automatiseren.

Vereisten

Als u de implementatie van een Azure Synapse-werkruimte in meerdere omgevingen wilt automatiseren, moeten de volgende vereisten en configuraties aanwezig zijn. Houd er rekening mee dat u ervoor kunt kiezen om Azure DevOps of GitHub te gebruiken, afhankelijk van uw voorkeur of bestaande installatie.

Azure DevOps

Als u Azure DevOps gebruikt:

• Bereid een Azure DevOps-project voor voor het uitvoeren van de release-pijplijn.
• Verleent gebruikers die de code Basic-toegang op organisatieniveau inchecken, zodat ze de opslagplaats kunnen zien.
• Eigenaarsmachtigingen verlenen aan de Azure Synapse-opslagplaats.
• Zorg ervoor dat u een zelf-hostende Azure DevOps VM-agent hebt gemaakt of dat u een door Azure DevOps gehoste agent gebruikt.
• Verken machtigingen voor het maken van een Azure Resource Manager-serviceverbinding voor de resourcegroep.
• Een Microsoft Entra-beheerder moet de Azure DevOps Synapse Workspace Deployment Agent-extensie installeren in de Azure DevOps-organisatie.
• Maak of nomineer een bestaand serviceaccount om de pijplijn uit te voeren als. U kunt een persoonlijk toegangstoken gebruiken in plaats van een serviceaccount, maar uw pijplijnen werken niet nadat het gebruikersaccount is verwijderd.

GitHub

Als u GitHub gebruikt:

• Maak een GitHub-opslagplaats die de artefacten van de Azure Synapse-werkruimte en de werkruimtesjabloon bevat.
• Zorg ervoor dat u een zelf-hostende runner hebt gemaakt of dat u een door GitHub gehoste runner gebruikt.

Microsoft Entra ID

• Als u een service-principal gebruikt, maakt u in Microsoft Entra ID een service-principal die moet worden gebruikt voor implementatie.
• Als u een beheerde identiteit gebruikt, schakelt u de door het systeem toegewezen beheerde identiteit in op uw VIRTUELE machine in Azure als agent of runner en voegt u deze vervolgens toe aan Azure Synapse Studio als Synapse-beheerder.
• Gebruik de Microsoft Entra-beheerdersrol om deze acties te voltooien.

Azure Synapse Analytics

Notitie

U kunt deze vereisten automatiseren en implementeren met behulp van dezelfde pijplijn, een ARM-sjabloon of de Azure CLI, maar deze processen worden niet beschreven in dit artikel.

• De 'bronwerkruimte' die wordt gebruikt voor ontwikkeling, moet worden geconfigureerd met een Git-opslagplaats in Azure Synapse Studio. Zie Broncodebeheer in Azure Synapse Studio voor meer informatie.

• Stel een lege werkruimte in om te implementeren op:

  1. Maak een nieuwe Azure Synapse-werkruimte.
  2. Verdeel de service-principal de volgende machtigingen voor de nieuwe Synapse-werkruimte:
     • Microsoft.Synapse/workspaces/integrationruntimes/write
     • Microsoft.Synapse/workspaces/operationResults/read
     • Microsoft.Synapse/workspaces/read
  3. Configureer de verbinding met de Git-opslagplaats niet in de werkruimte.
  4. Ga in de Azure Synapse-werkruimte naar Studio>Toegangsbeheer beheren.> 4. Ga in de Azure Synapse-werkruimte naar Studio > Toegangsbeheer beheren > . Wijs Synapse Artifact Publisher toe aan de service-principal. Als de implementatiepijplijn beheerde privé-eindpunten moet implementeren, wijst u in plaats daarvan de Synapse-beheerder toe.
  5. Wanneer u gekoppelde services gebruikt waarvan de verbindingsgegevens zijn opgeslagen in Azure Key Vault, wordt u aangeraden afzonderlijke sleutelkluizen voor verschillende omgevingen te bewaren. U kunt ook afzonderlijke machtigingsniveaus configureren voor elke sleutelkluis. U wilt bijvoorbeeld niet dat uw teamleden machtigingen hebben voor productiegeheimen. Als u deze aanpak volgt, raden we u aan om dezelfde geheime namen in alle fasen te bewaren. Als u dezelfde geheime namen bewaart, hoeft u niet elke verbindingsreeks te parameteriseren in CI/CD-omgevingen, omdat het enige dat verandert de naam van de sleutelkluis is. Dit is een afzonderlijke parameter.

Andere vereisten

• Spark-pools en zelf-hostende integratieruntimes worden niet gemaakt in een werkruimte-implementatietaak. Als u een gekoppelde service hebt die gebruikmaakt van een zelf-hostende Integration Runtime, maakt u de runtime handmatig in de nieuwe werkruimte.
• Als de items in de ontwikkelwerkruimte zijn gekoppeld aan de specifieke pools, moet u ervoor zorgen dat u dezelfde namen maakt of parameteriseert voor de pools in de doelwerkruimte in het parameterbestand.
• Als uw ingerichte SQL-pools worden onderbroken wanneer u probeert te implementeren, kan de implementatie mislukken.

Zie CI/CD in Azure Synapse Analytics Deel 4 voor meer informatie: de release-pijplijn.

Een release-pijplijn instellen in Azure DevOps

In deze sectie leert u hoe u een Azure Synapse-werkruimte implementeert in Azure DevOps.

1. Open in Azure DevOps het project dat u hebt gemaakt voor de release.

2. Selecteer Pijplijnreleases> in het linkermenu.

   

3. Selecteer Nieuwe pijplijn. Als u bestaande pijplijnen hebt, selecteert u Nieuwe>nieuwe release-pijplijn.

4. Selecteer de sjabloon Lege taak .

   

5. Voer in de fasenaam de naam van uw omgeving in.

6. Selecteer Artefact toevoegen en selecteer vervolgens de Git-opslagplaats die is geconfigureerd met Azure Synapse Studio in uw ontwikkelomgeving. Selecteer de Git-opslagplaats waarin u uw pools en werkruimte-ARM-sjabloon beheert. Als u GitHub als bron gebruikt, maakt u een serviceverbinding voor uw GitHub-account en pull-opslagplaatsen. Zie serviceverbindingen voor meer informatie.

   

7. Selecteer de ARM-sjabloonbranch van de resource. Voor de standaardversie selecteert u Nieuwste in de standaardbranch.

   

8. Selecteer voor de standaardvertakking voor artefacten de publicatievertakking van de opslagplaats of andere niet-publicerende vertakkingen die Synapse-artefacten bevatten. De publicatiebranch is workspace_publishstandaard . Voor de standaardversie selecteert u Nieuwste in de standaardbranch.

   

Een fasetaak instellen voor een ARM-sjabloon om een resource te maken en bij te werken

Als u een ARM-sjabloon hebt waarmee een resource wordt geïmplementeerd, zoals een Azure Synapse-werkruimte, een Spark- en SQL-pool of een sleutelkluis, voegt u een Azure Resource Manager-implementatietaak toe om deze resources te maken of bij te werken:

1. Selecteer fasetaken weergeven in de faseweergave.

   

2. Maak een nieuwe taak. Zoek naar ARM-sjabloonimplementatie en selecteer vervolgens Toevoegen.

3. Selecteer op het tabblad Implementatietaken het abonnement, de resourcegroep en de locatie voor de werkruimte. Geef indien nodig referenties op.

4. Selecteer voor Actie de optie Resourcegroep maken of bijwerken.

5. Selecteer voor Sjabloon de knop met het beletselteken (...). Ga naar de ARM-sjabloon van de werkruimte.

6. Voor sjabloonparameters selecteert u ... om het parameterbestand te kiezen.

   

7. Voor sjabloonparameters overschrijven selecteert u ...en voert u vervolgens de parameterwaarden in die u voor de werkruimte wilt gebruiken.

8. Selecteer incrementeel voor de implementatiemodus.

9. (Optioneel) Voeg Azure PowerShell toe voor de toekenning en werk de roltoewijzing van de werkruimte bij. Als u een release-pijplijn gebruikt om een Azure Synapse-werkruimte te maken, wordt de service-principal van de pijplijn toegevoegd als de standaardwerkruimtebeheerder. U kunt PowerShell uitvoeren om andere accounts toegang te verlenen tot de werkruimte.

   

Waarschuwing

In de volledige implementatiemodus worden resources in de resourcegroep die niet zijn opgegeven in de nieuwe ARM-sjabloon verwijderd. Zie Implementatiemodi van Azure Resource Manager voor meer informatie.

Een fasetaak instellen voor de implementatie van Azure Synapse-artefacten

Gebruik de implementatie-extensie van de Synapse-werkruimte om andere items in uw Azure Synapse-werkruimte te implementeren. Items die u kunt implementeren, zijn onder andere gegevenssets, SQL-scripts en notebooks, spark-taakdefinities, integratieruntime, gegevensstroom, referenties en andere artefacten in de werkruimte.

Implementatie-extensie installeren en toevoegen

1. Zoek en haal de extensie op uit Visual Studio Marketplace.

   

2. Selecteer de Azure DevOps-organisatie waarin u de extensie wilt installeren.

   

3. Zorg ervoor dat de service-principal van de Azure DevOps-pijplijn de machtiging Abonnement heeft gekregen en is toegewezen als de Synapse-werkruimtebeheerder voor de werkruimte.

4. Als u een nieuwe taak wilt maken, zoekt u naar de implementatie van de Synapse-werkruimte en selecteert u Vervolgens Toevoegen.

   

De implementatietaak configureren

De implementatietaak ondersteunt drie typen bewerkingen, alleen valideren, implementeren en implementeren.

Notitie

Deze werkruimte-implementatie-extensie is niet compatibel met eerdere versies. Zorg ervoor dat de nieuwste versie is geïnstalleerd en gebruikt. U kunt de releaseopmerking lezen in een overzichtvan Azure DevOps en de nieuwste versie in GitHub-actie.

Valideer het valideren van de Synapse-artefacten in een vertakking die niet is gepubliceerd met de taak en het genereren van de werkruimtesjabloon en het parametersjabloonbestand. De validatiebewerking werkt alleen in de YAML-pijplijn. Het YAML-voorbeeldbestand ziet er als volgt uit:

   pool:
     vmImage: ubuntu-latest

   resources:
     repositories:
     - repository: <repository name>
       type: git
       name: <name>
       ref: <user/collaboration branch>

   steps:
     - checkout: <name>
     - task: Synapse workspace deployment@2
       continueOnError: true    
       inputs:
         operation: 'validate'
         ArtifactsFolder: '$(System.DefaultWorkingDirectory)/ArtifactFolder'
         TargetWorkspaceName: '<target workspace name>'    

Valideren en implementeren kan worden gebruikt om de werkruimte rechtstreeks te implementeren vanuit een niet-publicerende vertakking met de hoofdmap van het artefact.

Notitie

De implementatietaak moet afhankelijkheidS-JS-bestanden van dit eindpunt downloaden web.azuresynapse.net wanneer het bewerkingstype is geselecteerd als Valideren of Valideren en implementeren. Zorg ervoor dat het eindpunt web.azuresynapse.net is toegestaan als netwerkbeleid is ingeschakeld op de VIRTUELE machine.

De validatie- en implementatiebewerking werkt in zowel de klassieke als de YAML-pijplijn. Het YAML-voorbeeldbestand ziet er als volgt uit:

   pool:
     vmImage: ubuntu-latest

   resources:
     repositories:
     - repository: <repository name>
       type: git
       name: <name>
       ref: <user/collaboration branch>

   steps:
     - checkout: <name>
     - task: Synapse workspace deployment@2
       continueOnError: true    
       inputs:
         operation: 'validateDeploy'
         ArtifactsFolder: '$(System.DefaultWorkingDirectory)/ArtifactFolder'
         TargetWorkspaceName: 'target workspace name'
         azureSubscription: 'target Azure resource manager connection name'
         ResourceGroupName: 'target workspace resource group'
         DeleteArtifactsNotInTemplate: true
         OverrideArmParameters: >
           -key1 value1
           -key2 value2

Implementeer de invoer van de bewerking die wordt geïmplementeerd, inclusief synapse-werkruimtesjabloon en parametersjabloon, die kan worden gemaakt na publicatie in de werkruimtepublicatiebranch of na de validatie. Het is hetzelfde als versie 1.x.

U kunt de bewerkingstypen kiezen op basis van de use-case. Hieronder volgt een voorbeeld van de implementatie.

1. Selecteer in de taak het bewerkingstype implementeren.

   

2. Selecteer in de taak naast Sjabloon de optie ... om het sjabloonbestand te kiezen.

3. Selecteer naast sjabloonparameters de optie ... om het parameterbestand te kiezen.

4. Selecteer een verbinding, resourcegroep en naam voor de werkruimte.

5. Selecteer naast Sjabloonparameters overschrijven ... . Voer de parameterwaarden in die u wilt gebruiken voor de werkruimte, inclusief verbindingsreeks s en accountsleutels die worden gebruikt in uw gekoppelde services. Zie CI/CD in Azure Synapse Analytics voor meer informatie.

   

6. De implementatie van een beheerd privé-eindpunt wordt alleen ondersteund in versie 2.x. Zorg ervoor dat u de juiste versie selecteert en controleer de beheerde privé-eindpunten implementeren in de sjabloon.

   

7. Als u triggers wilt beheren, kunt u de triggerknop gebruiken om de triggers vóór de implementatie te stoppen. En u kunt ook een taak toevoegen om de triggers opnieuw op te starten na de implementatietaak.

   

Belangrijk

In CI/CD-scenario's moet het type Integration Runtime in verschillende omgevingen hetzelfde zijn. Als u bijvoorbeeld een zelf-hostende Integration Runtime in de ontwikkelomgeving hebt, moet dezelfde Integration Runtime zelf worden gehost in andere omgevingen, zoals in test en productie. Als u integratieruntimes deelt in meerdere fasen, moeten de integratieruntimes worden gekoppeld en zelf worden gehost in alle omgevingen, zoals in ontwikkeling, testen en productie.

Een release maken voor implementatie

Nadat u alle wijzigingen hebt opgeslagen, kunt u Release maken selecteren om handmatig een release te maken. Zie Azure DevOps-releasetriggers voor meer informatie over het automatiseren van het maken van een release.

Een release instellen in GitHub Actions

In deze sectie leert u hoe u GitHub-werkstromen maakt met behulp van GitHub Actions voor de implementatie van Azure Synapse-werkruimten.

U kunt de GitHub Actions voor Azure Resource Manager-sjabloon gebruiken om het implementeren van een ARM-sjabloon in Azure te automatiseren voor de werkruimte- en rekengroepen.

Werkstroombestand

Definieer een GitHub Actions-werkstroom in een YAML-bestand (.yml) in het pad /.github/workflows/ in uw opslagplaats. De definitie bevat de verschillende stappen en parameters waaruit de werkstroom bestaat.

Het bestand .yml bestaat uit twee secties:

Sectie	Opdrachten
Verificatie	1. Definieer een service-principal. 2. Maak een GitHub-geheim.
Implementatie	Implementeer de werkruimteartefacten.

GitHub Actions-geheimen configureren

GitHub Actions-geheimen zijn omgevingsvariabelen die zijn versleuteld. Iedereen met de machtiging Samenwerker voor deze opslagplaats kan deze geheimen gebruiken om te communiceren met acties in de opslagplaats.

1. Selecteer in de GitHub-opslagplaats het tabblad Instellingen en selecteer vervolgens Geheimen>nieuw opslagplaatsgeheim.

   

2. Voeg een nieuw geheim toe voor de client-id en voeg een nieuw clientgeheim toe als u de service-principal voor implementatie gebruikt. U kunt er ook voor kiezen om de abonnements-id en tenant-id op te slaan als geheimen.

Voeg uw werkstroom toe

Ga in uw GitHub-opslagplaats naar Acties.

1. Selecteer Uw werkstroom zelf instellen.

2. Verwijder alles na de on: sectie in het werkstroombestand. De resterende werkstroom kan er bijvoorbeeld uitzien als in dit voorbeeld:

   name: CI
   
   on:
   push:
       branches: [ master ]
   pull_request:
       branches: [ master ]
   

3. Wijzig de naam van uw werkstroom. Zoek op het tabblad Marketplace naar de implementatieactie synapse-werkruimte en voeg vervolgens de actie toe.

   

4. Stel de vereiste waarden en de werkruimtesjabloon in:

   name: workspace deployment
   
   on:
       push:
           branches: [ publish_branch ]
   jobs:
       release:
           # You also can use the self-hosted runners.
           runs-on: windows-latest
           steps:
           # Checks out your repository under $GITHUB_WORKSPACE, so your job can access it.
           - uses: actions/checkout@v2
           - uses: azure/synapse-workspace-deployment@release-1.0
           with:
             TargetWorkspaceName: 'target workspace name'
             TemplateFile: './path of the TemplateForWorkspace.json'
             ParametersFile: './path of the TemplateParametersForWorkspace.json'
             OverrideArmParameters: './path of the parameters.yaml'
             environment: 'Azure Public'
             resourceGroup: 'target workspace resource group'
             clientId: ${{secrets.CLIENTID}}
             clientSecret:  ${{secrets.CLIENTSECRET}}
             subscriptionId: 'subscriptionId of the target workspace'
             tenantId: 'tenantId'
             DeleteArtifactsNotInTemplate: 'true'
             managedIdentity: 'False'
   

5. U kunt uw wijzigingen doorvoeren. Selecteer Doorvoeren starten, voer de titel in en voeg vervolgens een beschrijving toe (optioneel). Selecteer vervolgens Nieuw bestand doorvoeren.

   

   Het bestand wordt weergegeven in de map .github/workflows in uw opslagplaats.

   Notitie

   Beheerde identiteit wordt alleen ondersteund met zelf-hostende VM's in Azure. Zorg ervoor dat u de runner instelt op zelf-hostend. Schakel de door het systeem toegewezen beheerde identiteit voor uw VM in en voeg deze toe aan Azure Synapse Studio als Synapse-beheerder.

Beoordeel uw implementatie

1. Ga in uw GitHub-opslagplaats naar Acties.

2. Als u gedetailleerde logboeken van de uitvoering van uw werkstroom wilt bekijken, opent u het eerste resultaat:

   

Aangepaste parameters maken in de werkruimtesjabloon

Als u geautomatiseerde CI/CD gebruikt en bepaalde eigenschappen tijdens de implementatie wilt wijzigen, maar de eigenschappen niet standaard worden geparameteriseerd, kunt u de standaardparametersjabloon overschrijven.

Als u de standaardparametersjabloon wilt overschrijven, maakt u een aangepaste parametersjabloon met de naam template-parameters-definition.json in de hoofdmap van uw Git-vertakking. U moet deze exacte bestandsnaam gebruiken. Wanneer de Azure Synapse-werkruimte wordt gepubliceerd vanuit de samenwerkingsbranch of de implementatietaak de artefacten in andere vertakkingen valideert, wordt dit bestand gelezen en wordt de configuratie gebruikt om de parameters te genereren. Als azure Synapse-werkruimte dat bestand niet vindt, wordt de standaardparametersjabloon gebruikt.

Aangepaste parametersyntaxis

U kunt de volgende richtlijnen gebruiken om een aangepast parameterbestand te maken:

• Voer het eigenschapspad in onder het relevante entiteitstype.
• Als u een eigenschapsnaam instelt om aan te * geven dat u alle eigenschappen onder de eigenschap wilt parameteriseren (alleen op het eerste niveau, niet recursief). U kunt uitzonderingen instellen op deze configuratie.
• Als u de waarde van een eigenschap instelt als een tekenreeks, geeft u aan dat u de eigenschap wilt parameteriseren. Gebruik de indeling <action>:<name>:<stype>.
  • <action> kan een van deze tekens zijn:
    • = betekent dat de huidige waarde behouden blijft als de standaardwaarde voor de parameter.
    • - betekent dat de standaardwaarde voor de parameter niet behouden blijft.
    • |is een speciaal geval voor geheimen uit Azure Key Vault voor verbindingsreeks s of sleutels.
  • <name> is de naam van de parameter. Als deze leeg is, wordt de naam van de eigenschap gebruikt. Als de waarde begint met een - teken, wordt de naam ingekort. Zou bijvoorbeeld AzureStorage1_properties_typeProperties_connectionString worden ingekort tot AzureStorage1_connectionString.
  • <stype> is het type parameter. Als <stype> dit leeg is, is stringhet standaardtype . Ondersteunde waarden: string, securestring, int, , bool, en arrayobjectsecureobject .
• Het opgeven van een matrix in het bestand geeft aan dat de overeenkomende eigenschap in de sjabloon een matrix is. Azure Synapse doorloopt alle objecten in de matrix met behulp van de opgegeven definitie. Het tweede object, een tekenreeks, wordt de naam van de eigenschap, die wordt gebruikt als de naam voor de parameter voor elke iteratie.
• Een definitie kan niet specifiek zijn voor een resource-exemplaar. Elke definitie is van toepassing op alle resources van dat type.
• Standaard worden alle beveiligde tekenreeksen (zoals Key Vault-geheimen) en beveiligde tekenreeksen (zoals verbindingsreeks s, sleutels en tokens) geparameteriseerd.

Voorbeeld van parametersjabloondefinitie

Hier volgt een voorbeeld van hoe een parametersjabloondefinitie eruitziet:

{
    "Microsoft.Synapse/workspaces/notebooks": {
        "properties": {
            "bigDataPool": {
                "referenceName": "="
            }
        }
    },
    "Microsoft.Synapse/workspaces/sqlscripts": {
        "properties": {
            "content": {
                "currentConnection": {
                    "*": "-"
                }
            }
        }
    },
    "Microsoft.Synapse/workspaces/pipelines": {
        "properties": {
            "activities": [{
                "typeProperties": {
                    "waitTimeInSeconds": "-::int",
                    "headers": "=::object",
                    "activities": [
                        {
                            "typeProperties": {
                                "url": "-:-webUrl:string"
                            }
                        }
                    ]
                }
            }]
        }
    },
    "Microsoft.Synapse/workspaces/integrationRuntimes": {
        "properties": {
            "typeProperties": {
                "*": "="
            }
        }
    },
    "Microsoft.Synapse/workspaces/triggers": {
        "properties": {
            "typeProperties": {
                "recurrence": {
                    "*": "=",
                    "interval": "=:triggerSuffix:int",
                    "frequency": "=:-freq"
                },
                "maxConcurrency": "="
            }
        }
    },
    "Microsoft.Synapse/workspaces/linkedServices": {
        "*": {
            "properties": {
                "typeProperties": {
                    "accountName": "=",
                    "username": "=",
                    "connectionString": "|:-connectionString:secureString",
                    "secretAccessKey": "|"
                }
            }
        },
        "AzureDataLakeStore": {
            "properties": {
                "typeProperties": {
                    "dataLakeStoreUri": "="
                }
            }
        },
        "AzureKeyVault": {
            "properties": {
                "typeProperties": {
                    "baseUrl": "|:baseUrl:secureString"
                },
                "parameters": {
                    "KeyVaultURL": {
                        "type": "=",
                        "defaultValue": "|:defaultValue:secureString"
                    }
                }
            }
        }
    },
    "Microsoft.Synapse/workspaces/datasets": {
        "*": {
            "properties": {
                "typeProperties": {
                    "folderPath": "=",
                    "fileName": "="
                }
            }
        }
    },
    "Microsoft.Synapse/workspaces/credentials" : {
        "properties": {
            "typeProperties": {
                "resourceId": "="
            }
        }
    }
}

Hier volgt een uitleg van hoe de voorgaande sjabloon wordt samengesteld op resourcetype.

notebooks

• Elke eigenschap in het properties/bigDataPool/referenceName pad wordt geparameteriseerd met de standaardwaarde. U kunt een gekoppelde Spark-pool parameteriseren voor elk notebookbestand.

sqlscripts

• In het properties/content/currentConnection pad worden zowel de poolName eigenschappen als de databaseName eigenschappen geparameteriseerd als tekenreeksen zonder de standaardwaarden in de sjabloon.

pipelines

• Een eigenschap in het activities/typeProperties/waitTimeInSeconds pad wordt geparameteriseerd. Elke activiteit in een pijplijn met een eigenschap op codeniveau met de naam waitTimeInSeconds (bijvoorbeeld de Wait activiteit) wordt geparameteriseerd als een getal, met een standaardnaam. De eigenschap heeft geen standaardwaarde in de Resource Manager-sjabloon. In plaats daarvan is de eigenschap vereist tijdens de implementatie van Resource Manager.
• De headers eigenschap (bijvoorbeeld in een Web activiteit) wordt geparameteriseerd met het object type (Object). De headers eigenschap heeft een standaardwaarde die dezelfde waarde is als de bronfactory.

integrationRuntimes

• Alle eigenschappen in het typeProperties pad worden geparameteriseerd met hun respectieve standaardwaarden. Twee eigenschappen bevinden zich bijvoorbeeld onder IntegrationRuntimes typeeigenschappen: computeProperties en ssisProperties. Beide eigenschapstypen worden gemaakt met hun respectieve standaardwaarden en typen (Object).

triggers

• Onder typePropertiesworden twee eigenschappen geparameteriseerd:

  • De maxConcurrency eigenschap heeft een standaardwaarde en is het string type. De standaardparameternaam van de maxConcurrency eigenschap is <entityName>_properties_typeProperties_maxConcurrency.
  • De recurrence eigenschap wordt ook geparameteriseerd. Alle eigenschappen onder de recurrence eigenschap worden ingesteld op parameters als tekenreeksen, met standaardwaarden en parameternamen. Een uitzondering is de interval eigenschap, die wordt geparameteriseerd als het int type. De parameternaam wordt achtervoegseld met <entityName>_properties_typeProperties_recurrence_triggerSuffix. Op dezelfde manier is de freq eigenschap een tekenreeks en wordt deze geparameteriseerd als een tekenreeks. De freq eigenschap wordt echter geparameteriseerd zonder een standaardwaarde. De naam wordt ingekort en achtervoegseld, zoals <entityName>_freq.

  Notitie

  Er worden momenteel maximaal 50 triggers ondersteund.

linkedServices

• Gekoppelde services zijn uniek. Omdat gekoppelde services en gegevenssets een breed scala aan typen hebben, kunt u typespecifieke aanpassingen bieden. In het voorgaande voorbeeld wordt voor alle gekoppelde services van het AzureDataLakeStore type een specifieke sjabloon toegepast. Voor alle andere (geïdentificeerd via het gebruik van het * teken), wordt een andere sjabloon toegepast.
• De connectionString eigenschap wordt geparameteriseerd als een securestring waarde. Deze heeft geen standaardwaarde. De parameternaam wordt ingekort en achtervoegsel met connectionString.
• De secretAccessKey eigenschap wordt geparameteriseerd als een AzureKeyVaultSecret waarde (bijvoorbeeld in een gekoppelde Amazon S3-service). De eigenschap wordt automatisch geparameteriseerd als een Azure Key Vault-geheim en opgehaald uit de geconfigureerde sleutelkluis. U kunt ook de sleutelkluis zelf parameteriseren.

datasets

• Hoewel u typen in gegevenssets kunt aanpassen, is een expliciete configuratie op *-niveau niet vereist. In het voorgaande voorbeeld worden alle eigenschappen van de gegevensset onder typeProperties geparameteriseerd.

Best practices voor CI/CD

Als u Git-integratie gebruikt met uw Azure Synapse-werkruimte en u een CI/CD-pijplijn hebt die uw wijzigingen van ontwikkeling naar test verplaatst en vervolgens naar productie, raden we u aan deze aanbevolen procedures te volgen:

• Integreer alleen de ontwikkelwerkruimte met Git. Als u Git-integratie gebruikt, integreert u alleen uw Azure Synapse-ontwikkelwerkruimte met Git. Wijzigingen in test- en productiewerkruimten worden geïmplementeerd via CI/CD en hebben geen Git-integratie nodig.
• Pools voorbereiden voordat u artefacten migreert. Als u een SQL-script of notebook hebt gekoppeld aan pools in de ontwikkelwerkruimte, gebruikt u dezelfde naam voor pools in verschillende omgevingen.
• Versiebeheer in infrastructuur synchroniseren als codescenario's. Als u infrastructuur (netwerken, virtuele machines, load balancers en verbindingstopologie) in een beschrijvend model wilt beheren, gebruikt u dezelfde versiebeheer die het DevOps-team gebruikt voor broncode.
• Best practices voor Azure Data Factory bekijken. Als u Data Factory gebruikt, raadpleegt u de aanbevolen procedures voor Data Factory-artefacten.

Problemen met de implementatie van artefacten oplossen

De implementatietaak van de Synapse-werkruimte gebruiken om Synapse-artefacten te implementeren

In Azure Synapse, in tegenstelling tot in Data Factory, zijn artefacten geen Resource Manager-resources. U kunt de arm-sjabloonimplementatietaak niet gebruiken om Azure Synapse-artefacten te implementeren. Gebruik in plaats daarvan de implementatietaak van de Synapse-werkruimte om de artefacten te implementeren en gebruik ARM-implementatietaak voor ARM-resources (pools en werkruimten). Ondertussen ondersteunt deze taak alleen Synapse-sjablonen waarbij resources het type Microsoft.Synapse hebben. En met deze taak kunnen gebruikers wijzigingen van elke vertakking automatisch implementeren zonder dat ze handmatig op de publicatie in Synapse Studio hoeven te klikken. Hier volgen enkele veelvoorkomende problemen.

1. Publiceren is mislukt: arm-werkruimtebestand is meer dan 20 MB

Er is een bestandsgroottebeperking in Git-provider, bijvoorbeeld in Azure DevOps is de maximale bestandsgrootte 20 MB. Zodra de bestandsgrootte van de werkruimtesjabloon groter is dan 20 Mb, treedt deze fout op wanneer u wijzigingen publiceert in Synapse Studio, waarin het werkruimtesjabloonbestand wordt gegenereerd en gesynchroniseerd met Git. Als u het probleem wilt oplossen, kunt u de Synapse-implementatietaak gebruiken met de bewerking valideren of valideren en implementeren om het werkruimtesjabloonbestand rechtstreeks op te slaan in de pijplijnagent en zonder handmatig te publiceren in Synapse Studio.

2. Onverwachte tokenfout in release

Als het parameterbestand parameterwaarden bevat die niet zijn ontsnapt, kan de release-pijplijn het bestand niet parseren en wordt er een unexpected token fout gegenereerd. We raden u aan parameters te overschrijven of Key Vault te gebruiken om parameterwaarden op te halen. U kunt ook dubbele escapetekens gebruiken om het probleem op te lossen.

3. Implementatie van Integration Runtime is mislukt

Als u de werkruimtesjabloon hebt gegenereerd op basis van een beheerde VNet-werkruimte en probeert te implementeren in een normale werkruimte of omgekeerd, treedt deze fout op.

4. Onverwacht teken aangetroffen tijdens het parseren van de waarde

De sjabloon kan niet worden geparseerd in het sjabloonbestand. Probeer het door de achterslashes te ontsnappen, bijvoorbeeld. \\Test01\Test

5. Kan werkruimtegegevens niet ophalen, niet gevonden

De gegevens van de doelwerkruimte zijn niet juist geconfigureerd. Zorg ervoor dat de serviceverbinding die u hebt gemaakt, is afgestemd op de resourcegroep met de werkruimte.

6. Verwijderen van artefact is mislukt

De extensie vergelijkt de artefacten die aanwezig zijn in de publicatievertakking met de sjabloon en op basis van het verschil dat deze worden verwijderd. Zorg ervoor dat u geen artefact probeert te verwijderen dat aanwezig is in de publicatievertakking en een ander artefact een verwijzing of afhankelijkheid heeft.

8. Implementatie is mislukt met fout: json position 0

Als u de sjabloon handmatig probeert bij te werken, treedt deze fout op. Zorg ervoor dat u de sjabloon niet handmatig hebt bewerkt.

9. Het maken of bijwerken van het document is mislukt vanwege een ongeldige verwijzing

Naar het artefact in synapse kan worden verwezen door een andere. Als u een kenmerk hebt geparameteriseerd waarnaar wordt verwezen in een artefact, moet u ervoor zorgen dat u de juiste en niet-null-waarde opgeeft

10. Kan de implementatiestatus niet ophalen in notebookimplementatie

Het notebook dat u probeert te implementeren, is gekoppeld aan een Spark-pool in het werkruimtesjabloonbestand, terwijl in de implementatie de pool niet bestaat in de doelwerkruimte. Als u de naam van de pool niet parameteriseert, moet u ervoor zorgen dat u dezelfde naam hebt voor de pools tussen omgevingen.