Kontinuální integrace a průběžné doručování pro pracovní prostor Azure Synapse Analytics

Kontinuální integrace (CI) je proces automatizace sestavování a testování kódu pokaždé, když člen týmu potvrdí změnu správy verzí. Průběžné doručování (CD) je proces sestavování, testování, konfigurace a nasazování z více testovacích nebo přípravných prostředí do provozního prostředí.

V pracovním prostoru Azure Synapse Analytics přesouvá CI/CD všechny entity z jednoho prostředí (vývojového, testovacího, provozního) do jiného prostředí. Přenesení pracovního prostoru do jiného pracovního prostoru je proces skládající se ze dvou částí. Nejprve pomocí šablony Azure Resource Manager (ARM šablona) vytvořte nebo aktualizujte prostředky pracovního prostoru (pooly a pracovní prostor). Pak migrujte artefakty, jako jsou skripty SQL a poznámkové bloky, definice úloh Sparku, kanály, datové sady a další artefakty pomocí nástrojů pro nasazení pracovního prostoru Synapse v Azure DevOps nebo na GitHubu.

Tento článek popisuje, jak pomocí kanálu verze Azure DevOps a GitHub Actions automatizovat nasazení pracovního prostoru Azure Synapse do několika prostředí.

Požadavky

Pokud chcete automatizovat nasazení pracovního prostoru Azure Synapse do více prostředí, musí být splněné následující požadavky a konfigurace. Podle vašich preferencí nebo stávajícího nastavení můžete použít Azure DevOps nebo GitHub.

Azure DevOps

Pokud používáte Azure DevOps:

• Připravte projekt Azure DevOps k spuštění vydávacího kanálu.
• Udělte všem uživatelům, kteří budou provádět přihlášení kódu, základní úroveň přístupu na úrovni organizace, aby viděli repozitář.
• Udělte vlastníkovi oprávnění k úložišti Azure Synapse.
• Ujistěte se, že jste vytvořili místního agenta virtuálního počítače Azure DevOps nebo používáte agenta hostovaného v Azure DevOps.
• Udělte oprávnění k vytvoření připojení služby Azure Resource Manager pro skupinu prostředků.
• Správce Microsoft Entra musí nainstalovat rozšíření agenta nasazení pracovního prostoru Azure DevOps Synapse v organizaci Azure DevOps.
• Vytvořte nebo vyberte existující účet služby, který má potrubí používat pro spuštění. Místo účtu služby můžete použít osobní přístupový token, ale vaše kanály po odstranění uživatelského účtu nebudou fungovat.

GitHub

Pokud používáte GitHub:

• Vytvořte úložiště GitHubu, které obsahuje artefakty pracovního prostoru Azure Synapse a šablonu pracovního prostoru.
• Ujistěte se, že jste vytvořili místního spouštěče nebo používáte spouštěč hostovaný na GitHubu.

Microsoft Entra ID

• Pokud využíváte objekt služby, vytvořte v Microsoft Entra ID objekt služby pro nasazení.
• Pokud používáte spravovanou identitu, povolte systémem přiřazenou spravovanou identitu na svém virtuálním počítači v Azure jako agenta nebo runnera a poté ji přidejte do Azure Synapse Studia jako správce Synapse.
• K dokončení těchto akcí použijte roli správce Microsoft Entra.

Azure Synapse Analytics

Poznámka:

Tyto požadavky můžete automatizovat a nasazovat pomocí stejného kanálu, šablony ARM nebo Azure CLI, ale tyto procesy nejsou popsané v tomto článku.

• Zdrojový pracovní prostor, který se používá pro vývoj, musí být nakonfigurovaný s úložištěm Git v nástroji Azure Synapse Studio. Další informace najdete v tématu Správa zdrojového kódu v nástroji Azure Synapse Studio.

• Nastavení prázdného pracovního prostoru pro nasazení do:

  1. Vytvořte nový pracovní prostor Azure Synapse.
  2. Udělte služebnímu uživateli následující oprávnění k novému pracovnímu prostoru Synapse:
     • Microsoft.Synapse/workspaces/integrationruntimes/zapsat
     • Microsoft.Synapse/pracovní_prostory/výsledky_operací/čtení
     • Microsoft.Synapse/workspaces/read
  3. V pracovním prostoru nekonfigurujte připojení úložiště Git.
  4. V pracovním prostoru Azure Synapse přejděte do Studio>Správa>Řízení přístupu. Přiřaďte služebnímu principálu roli Synapse Artifact Publisher. Pokud je potřeba nasadit spravované privátní koncové body, zadejte místo toho "Synapse Administrator".
  5. Pokud používáte propojené služby, jejichž informace o připojení jsou uložené ve službě Azure Key Vault, doporučujeme zachovat samostatné trezory klíčů pro různá prostředí. Můžete také nakonfigurovat samostatné úrovně oprávnění pro každý trezor klíčů. Například možná nechcete, aby členové vašeho týmu měli oprávnění k produkčním tajemstvím. Pokud postupujete podle tohoto přístupu, doporučujeme zachovat stejné názvy tajných kódů ve všech fázích. Pokud zachováte stejné názvy tajných kódů, nemusíte parametrizovat jednotlivé připojovací řetězec napříč prostředími CI/CD, protože jedinou věcí, kterou změníte, je název trezoru klíčů, což je samostatný parametr.

Další předpoklady

• Fondy Sparku a místní prostředí Integration Runtime se nevytvoří v úloze nasazení pracovního prostoru. Pokud máte propojenou službu, která používá místní prostředí Integration Runtime, ručně vytvořte modul runtime v novém pracovním prostoru.
• Pokud jsou položky v pracovním prostoru pro vývoj připojené ke konkrétním fondům, ujistěte se, že vytvoříte nebo parametrizujete stejné názvy fondů v cílovém pracovním prostoru v souboru parametrů.
• Pokud jsou zřízené fondy SQL pozastavené při pokusu o nasazení, nasazení může selhat.

Další informace najdete v CI/CD ve službě Azure Synapse Analytics – část 4 – Publikační kanál.

Nastavení distribučního kanálu v Azure DevOps

V této části se dozvíte, jak nasadit pracovní prostor Azure Synapse v Azure DevOps.

1. V Azure DevOps otevřete projekt, který jste vytvořili pro vydání.

2. V nabídce vlevo vyberte Pipelines>Releases.

   

3. Vyberte New pipeline (Nový kanál). Pokud máte existující kanály, vyberte Nový>Nový kanál vydání.

4. Vyberte prázdnou šablonu úlohy .

   

5. Do pole Název fáze zadejte název vašeho prostředí.

6. Vyberte Přidat artefakt a pak vyberte úložiště Git, které je nakonfigurované pomocí nástroje Azure Synapse Studio ve vašem vývojovém prostředí. Vyberte úložiště Git, ve kterém spravujete clustery a šablonu ARM pracovního prostoru. Pokud jako zdroj používáte GitHub, vytvořte připojení služby pro váš GitHub účet a stahování úložišť. Další informace najdete v tématu Připojení služeb.

   

7. Vyberte větev šablony prostředku ARM. Jako výchozí verzi vyberte Nejnovější z výchozí větve.

   

8. Pro artefakty Výchozí větev vyberte ve úložišti publikační větev nebo jiné nepublikační větve, které obsahují artefakty Synapse. Ve výchozím nastavení je workspace_publishvětev publikování. Jako výchozí verzi vyberte Nejnovější z výchozí větve.

   

Nastavení úlohy fáze pro šablonu ARM pro vytvoření a aktualizaci prostředku

Pokud máte šablonu ARM, která nasadí prostředek, například pracovní prostor Azure Synapse, Spark a fond SQL nebo trezor klíčů, přidejte úlohu nasazení Azure Resource Manageru pro vytvoření nebo aktualizaci těchto prostředků:

1. V zobrazení fáze vyberte Zobrazit úkoly fáze.

   

2. Vytvořte nový úkol. Vyhledejte Nasazení šablony ARM, a poté vyberte Přidat.

3. Na kartě Úlohy nasazení vyberte předplatné, skupinu prostředků a umístění pracovního prostoru. V případě potřeby zadejte přihlašovací údaje.

4. V části Akce vyberte Vytvořit nebo aktualizovat skupinu prostředků.

5. U šablony zvolte tlačítko se třemi tečkami (...). Přejděte do šablony ARM pracovního prostoru.

6. V části Parametry šablony vyberte ... a zvolte soubor parametrů.

   

7. V části Přepsat parametry šablony vyberte ...a zadejte hodnoty parametrů, které chcete použít pro pracovní prostor.

8. V režimu nasazení vyberte Přírůstkové.

9. (Volitelné) Přidejte Azure PowerShell k udělení oprávnění a aktualizujte přiřazení role ve workspace. Pokud k vytvoření pracovního prostoru Azure Synapse použijete kanál verze, instanční objekt kanálu se přidá jako výchozí správce pracovního prostoru. Spuštěním PowerShellu můžete udělit ostatním účtům přístup k pracovnímu prostoru.

   

Upozornění

V úplném režimu nasazení jsou prostředky ve skupině prostředků, které nejsou zadané v nové šabloně ARM, odstraněny. Další informace najdete v tématu Režimy nasazení Azure Resource Manageru.

Nastavení fázové úlohy pro nasazení artefaktů Azure Synapse

Rozšíření pro nasazení pracovního prostoru Synapse použijte k nasazení dalších položek ve vašem pracovním prostoru Azure Synapse. Mezi položky, které můžete nasadit, patří datové sady, skripty SQL a poznámkové bloky, definice úloh Sparku, prostředí Integration Runtime, tok dat, přihlašovací údaje a další artefakty v pracovním prostoru.

Instalace a přidání rozšíření pro nasazení

1. Vyhledejte a získejte rozšíření z Webu Visual Studio Marketplace.

   

2. Vyberte organizaci Azure DevOps, do které chcete rozšíření nainstalovat.

   

3. Ujistěte se, že instančnímu objektu kanálu Azure DevOps bylo uděleno oprávnění Předplatné a že je přiřazený jako správce pracovního prostoru Synapse pro daný pracovní prostor.

4. Pokud chcete vytvořit novou úlohu, vyhledejte nasazení pracovního prostoru Synapse a pak vyberte Přidat.

   

Konfigurace úlohy nasazení

Úloha nasazení podporuje tři typy operací: pouze ověření, nasadit, a nasadit a ověřit.

Poznámka:

Toto rozšíření pro nasazení pracovního prostoru není zpětně kompatibilní. Ujistěte se, že je nainstalovaná a použitá nejnovější verze. Poznámku k verzi můžete přečíst v přehledu v Azure DevOps a nejnovější verzi v GitHub Actions.

Ověřením je ověření artefaktů Synapse v nepublikované větvi pomocí úlohy a vygenerování šablony pracovního prostoru a souboru šablony parametrů. Operace ověření funguje pouze v kanálu YAML. Tady je ukázkový soubor YAML:

   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>'    

Ověření a nasazení lze použít k přímému nasazení pracovního prostoru z nepublikované větve s kořenovou složkou artefaktu.

Poznámka:

Úloha nasazení musí stáhnout soubory JS závislostí z tohoto koncového bodu web.azuresynapse.net , pokud je typ operace vybrán jako Ověřit nebo Ověřit a nasadit. Ujistěte se, že je koncový bod web.azuresynapse.net povolen, pokud jsou povolené síťové zásady na virtuálním počítači.

Operace ověření a nasazení funguje v klasickém kanálu i v kanálu YAML. Tady je ukázkový soubor YAML:

   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

Nasazení obsahuje vstupy operace nasazení, včetně šablony pracovního prostoru Synapse a šablony parametrů, které je možné vytvořit buď po publikování v publikační větvi pracovního prostoru, nebo po ověření. Je to stejné jako verze 1.x.

Typy operací můžete zvolit na základě případu použití. Následující část je příkladem nasazení.

1. V úloze vyberte typ operace jako Nasadit.

   

2. V úkolu vedle šablony vyberte ... a zvolte soubor šablony.

3. Vedle parametrů šablony vyberte ... pro zvolení souboru parametrů.

4. Vyberte připojení, skupinu prostředků a název pracovního prostoru.

5. Vedle možnosti Přepsat parametry šablony vyberte ... . Zadejte hodnoty parametrů, které chcete použít pro pracovní prostor, včetně připojovací řetězec a klíčů účtu, které se používají ve vašich propojených službách. Další informace najdete v tématu CI/CD ve službě Azure Synapse Analytics.

   

6. Nasazení spravovaného privátního koncového bodu je podporováno pouze ve verzi 2.x. Ujistěte se, že jste vybrali správnou verzi a zkontrolovali v šabloně nasazení spravovaných privátních koncových bodů.

   

7. Ke správě spouští můžete použít přepínač spouště k jejich zastavení před nasazením. Můžete také přidat úlohu, která restartuje spouštěče po úloze nasazení.

   

Důležité

Ve scénářích CI/CD musí být typ prostředí Integration Runtime v různých prostředích stejný. Pokud máte například místní prostředí Integration Runtime ve vývojovém prostředí, musí být stejné prostředí Integration Runtime hostované v jiných prostředích, například v testovacím a produkčním prostředí. Podobně pokud sdílíte prostředí Integration Runtime napříč několika fázemi, musí být prostředí Integration Runtime propojená a hostovaná ve všech prostředích, jako je vývoj, testování a produkční prostředí.

Připojení služby DevOps s federací identit úloh (WIF) není v současné době podporováno v rozšíření pro nasazení v Synapse Workspace. Přepněte do režimu tajných kódů, aby bylo připojení úspěšné.

Pro zabezpečení bez potřeby tajných kódů, které plně podporuje federaci identit úloh (WIF), použijte úlohy AzureCLI@2 nebo PowerShell s připojením ke federované službě, jak je popsáno v tématu Připojení k Azure pomocí federace identit úloh.

Tyto úlohy podporují ověřování bez tajných kódů a můžou spouštět příkazy nasazení Synapse (az synapse pipeline create, az synapse artifact publish) při zachování stejného toku nasazení.

Vytvoření verze pro nasazení

Po uložení všech změn můžete výběrem možnosti Vytvořit vydání vytvořit ručně. Informace o automatizaci vytváření verzí najdete v tématu Triggery vydání Azure DevOps.

Nastavení vydání v GitHub Actions

V této části se dozvíte, jak vytvářet pracovní postupy GitHubu pomocí GitHub Actions pro nasazení pracovního prostoru Azure Synapse.

Pomocí šablony GitHub Actions pro Azure Resource Manager můžete automatizovat nasazení šablony ARM do Azure pro pracovní prostor a fondy výpočetních prostředků.

Soubor pracovního postupu

Definujte pracovní postup GitHub Actions v souboru YAML (.yml) v cestě /.github/workflows/ ve vašem úložišti. Definice obsahuje různé kroky a parametry, které tvoří pracovní postup.

Soubor .yml má dvě části:

Sekce	Úlohy
Autentizace	1. Definujte entitu služby. 2. Vytvořte tajný kód GitHubu.
Nasazení	Nasaďte artefakty pracovního prostoru.

Konfigurace tajných kódů GitHub Actions

Tajemství GitHub Actions jsou proměnné prostředí, které jsou šifrované. Každý, kdo má k tomuto úložišti oprávnění spolupracovníka, může tyto tajné kódy použít k interakci s akcemi v úložišti.

1. V úložišti GitHub vyberte kartu Nastavení a pak vyberte Tajemství>Nové tajemství úložiště.

   

2. Přidejte nový tajný klíč pro ID klienta a přidejte nový tajný klíč klienta, pokud pro nasazení používáte instanční objekt. Můžete se také rozhodnout uložit ID předplatného a ID tenanta jako tajné kódy.

Přidejte svůj pracovní postup

V úložišti GitHub přejděte na Akce.

1. Vyberte Nastavit pracovní postup sami.

2. V souboru pracovního postupu odstraňte všechno za oddílem on: . Váš zbývající pracovní postup může například vypadat jako v tomto příkladu:

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

3. Přejmenujte pracovní postup. Na kartě Marketplace vyhledejte možnost nasazení pracovního prostoru Synapse a potom tuto možnost přidejte.

   

4. Nastavte požadované hodnoty a šablonu pracovního prostoru:

   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. Jste připraveni potvrdit změny. Vyberte Zahájit potvrzení, zadejte název a pak přidejte popis (volitelné). Pak vyberte Potvrdit nový soubor.

   

   Soubor se zobrazí ve složce .github/workflows ve vašem úložišti.

   Poznámka:

   Spravovaná identita se podporuje jenom u virtuálních počítačů v Azure v místním prostředí. Ujistěte se, že nastavíte runner na vlastní hostování. Povolte spravovanou identitu přiřazenou systémem pro váš virtuální počítač a přidejte ji do azure Synapse Studia jako správce Synapse.

Proveďte kontrolu nasazení

1. V úložišti GitHub přejděte na Akce.

2. Pokud chcete zobrazit podrobné protokoly spuštění pracovního postupu, otevřete první výsledek:

   

Vytvoření vlastních parametrů v šabloně pracovního prostoru

Pokud používáte automatizovanou CI/CD a chcete během nasazování změnit některé vlastnosti, ale vlastnosti nejsou ve výchozím nastavení parametrizované, můžete přepsat výchozí šablonu parametrů.

Pokud chcete přepsat výchozí šablonu parametrů, vytvořte vlastní šablonu parametrů s názvem template-parameters-definition.json v kořenové složce vaší větve Git. Musíte použít tento přesný název souboru. Když pracovní prostor Azure Synapse publikuje z kolaborativní větve nebo nasazovací úlohy ověří artefakty v jiných větvích, tento soubor přečte a využije jeho konfiguraci k generování parametrů. Pokud pracovní prostor Azure Synapse tento soubor nenajde, použije výchozí šablonu parametrů.

Syntaxe vlastních parametrů

K vytvoření vlastního souboru parametrů můžete použít následující pokyny:

• Zadejte cestu vlastnosti pod příslušným typem entity.
• Nastavením názvu * vlastnosti označíte, že chcete parametrizovat všechny vlastnosti v rámci vlastnosti (pouze na první úroveň, ne rekurzivně). Pro tuto konfiguraci můžete nastavit výjimky.
• Nastavení hodnoty vlastnosti jako řetězce označuje, že chcete parametrizovat vlastnost. Použijte formát <action>:<name>:<stype>.
  • <action> může mít jeden z těchto znaků:
    • = znamená zachovat aktuální hodnotu jako výchozí hodnotu parametru.
    • - znamená, že neuchovávejte výchozí hodnotu parametru.
    • |je zvláštní případ tajných kódů ze služby Azure Key Vault pro připojovací řetězec nebo klíče.
  • <name> je název parametru. Pokud je pole prázdné, převezme název vlastnosti. Pokud hodnota začíná znakem - , název se zkracuje. Například AzureStorage1_properties_typeProperties_connectionString by bylo zkráceno na AzureStorage1_connectionString.
  • <stype> je typ parametru. Pokud <stype> je prázdný, výchozí typ je string. Podporované hodnoty: string, , securestringint, bool, objectsecureobject , a array.
• Zadání pole v souboru označuje, že odpovídající vlastnost v šabloně je pole. Azure Synapse iteruje všechny objekty v poli pomocí zadané definice. Druhý objekt, řetězec, se stane názvem vlastnosti, která se používá jako název parametru pro každou iteraci.
• Definice nemůže být specifická pro instanci prostředku. Každá definice se vztahuje na všechny prostředky tohoto typu.
• Ve výchozím nastavení jsou parametrizovány všechny zabezpečené řetězce (například tajné kódy služby Key Vault) a zabezpečené řetězce (například připojovací řetězec, klíče a tokeny).

Příklad definice šablony parametrů

Tady je příklad, jak vypadá definice šablony parametrů:

{
    "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": "="
            }
        }
    }
}

Tady je vysvětlení toho, jak je předchozí šablona vytvořena podle typu prostředku.

notebooks

• Jakákoli vlastnost v cestě properties/bigDataPool/referenceName je parametrizována s výchozí hodnotou. Připojený fond Sparku můžete parametrizovat pro každý soubor poznámkového bloku.

sqlscripts

• V cestě properties/content/currentConnection jsou vlastnosti poolName a databaseName parametrizovány jako řetězce bez výchozích hodnot v šabloně.

pipelines

• Jakákoli vlastnost v cestě activities/typeProperties/waitTimeInSeconds je parametrizována. Jakákoli aktivita v kanálu, který má vlastnost na úrovni kódu s názvem waitTimeInSeconds (například Wait aktivita), je parametrizována jako číslo s výchozím názvem. Vlastnost nebude mít v šabloně Resource Manageru výchozí hodnotu. Místo toho bude vlastnost vyžadovat vstup během nasazení Resource Manageru.
• Vlastnost headers (například v aktivitě Web ) je parametrizována typem object (Object). Vlastnost headers má výchozí hodnotu, která je stejná jako zdrojová továrna.

integrationRuntimes

• Všechny vlastnosti v cestě typeProperties jsou parametrizovány s příslušnými výchozími hodnotami. Například dvě vlastnosti jsou pod IntegrationRuntimes vlastnostmi typu: computeProperties a ssisProperties. Oba typy vlastností se vytvářejí s příslušnými výchozími hodnotami a typy (Object).

triggers

• V části typePropertiesJsou parametrizovány dvě vlastnosti:

  • Vlastnost maxConcurrency má výchozí hodnotu a je typ string . Výchozí název parametru maxConcurrency vlastnosti je <entityName>_properties_typeProperties_maxConcurrency.
  • Vlastnost recurrence je také parametrizována. Všechny vlastnosti pod recurrence vlastností jsou nastaveny tak, aby byly parametrizovány jako řetězce s výchozími hodnotami a názvy parametrů. Výjimkou je interval vlastnost, která je parametrizována int jako typ. Název parametru je příponou <entityName>_properties_typeProperties_recurrence_triggerSuffix. freq Podobně je vlastnost typu řetězec a je jako taková parametrizována. freq Vlastnost je však parametrizována bez výchozí hodnoty. Název je zkrácený a příponovaný, například <entityName>_freq.

  Poznámka:

  V současné době se podporuje maximálně 50 triggerů.

linkedServices

• Propojené služby jsou jedinečné. Vzhledem k tomu, že propojené služby a datové sady mají širokou škálu typů, můžete poskytnout přizpůsobení specifické pro konkrétní typ. V předchozím příkladu se pro všechny propojené služby AzureDataLakeStore typu použije konkrétní šablona. Pro všechny ostatní (identifikované pomocí znaku * ) se použije jiná šablona.
• Vlastnost connectionString je parametrizována jako hodnota securestring. Nemá výchozí hodnotu. Název parametru je zkrácen a zakončen příponou connectionString.
• Vlastnost secretAccessKey je parametrizována jako AzureKeyVaultSecret hodnota (například ve službě propojené s Amazon S3). Vlastnost se automaticky parametrizuje jako tajný klíč služby Azure Key Vault a načte se z nakonfigurovaného trezoru klíčů. Můžete také parametrizovat samotný trezor klíčů.

datasets

• I když můžete přizpůsobit typy v datových sadách, explicitní konfigurace na úrovni *není nutná. V předchozím příkladu jsou všechny vlastnosti datové sady pod typeProperties parametrizovány.

Osvědčené postupy pro CI/CD

Pokud používáte integraci Gitu s pracovním prostorem Azure Synapse a máte kanál CI/CD, který přesouvá vaše změny z vývoje na testování a pak do produkčního prostředí, doporučujeme tyto osvědčené postupy:

• Integrujte pouze pracovní prostor pro vývoj s Gitem. Pokud používáte integraci Gitu, integrujte do Gitu jenom svůj vývojový pracovní prostor Azure Synapse. Změny testovacích a produkčních pracovních prostorů se nasazují prostřednictvím CI/CD a nepotřebují integraci Gitu.
• Připravte fondy před migrací artefaktů. Pokud máte skript SQL nebo poznámkový blok připojený k fondům v pracovním prostoru pro vývoj, použijte stejný název pro fondy v různých prostředích.
• Synchronizace verzování v infrastruktuře jako kódu ve scénářích Ke správě infrastruktury (sítí, virtuálních počítačů, nástrojů pro vyrovnávání zatížení a topologie připojení) v popisném modelu použijte stejnou správu verzí, kterou tým DevOps používá pro zdrojový kód.
• Projděte si osvědčené postupy služby Azure Data Factory. Pokud používáte službu Data Factory, podívejte se na osvědčené postupy pro artefakty služby Data Factory.

Řešení potíží s nasazováním artefaktů

Nasazení artefaktů Synapse pomocí úlohy nasazení pracovního prostoru Synapse

Na rozdíl od Azure Data Factory nejsou artefakty v Azure Synapse prostředky Resource Manageru. K nasazení artefaktů Azure Synapse nemůžete použít úlohu nasazení šablony ARM. Místo toho použijte úlohu nasazení pracovního prostoru Synapse k nasazení artefaktů a použijte úlohu nasazení ARM pro prostředky ARM (fondy a pracovní prostor). Mezitím tato úloha podporuje pouze šablony Synapse, ve kterých prostředky mají typ Microsoft.Synapse. S touto úlohou můžou uživatelé automaticky nasazovat změny z libovolné větve bez ručního kliknutí na publikování v nástroji Synapse Studio. Následují často zmiňované problémy.

1. Publikování se nezdařilo: Soubor ARM pracovního prostoru je větší než 20 MB.

U poskytovatele Gitu platí omezení velikosti souboru, například v Azure DevOps je maximální velikost souboru 20 Mb. Jakmile velikost souboru šablony pracovního prostoru překročí 20 Mb, dojde k této chybě při publikování změn v nástroji Synapse Studio, ve kterém se soubor šablony pracovního prostoru vygeneruje a synchronizuje s Gitem. K vyřešení problému můžete použít úlohu nasazení Synapse s operací ověření nebo ověření a nasazení k uložení souboru šablony pracovního prostoru přímo do agenta kanálu a bez nutnosti manuálního publikování v Synapse Studio.

2. Neočekávaná chyba tokenu ve vydané verzi

Pokud má soubor parametrů hodnoty, které nejsou záchytně zpracovány, nasazovací kanál se nepodaří správně analyzovat soubor a vygeneruje unexpected token chybu. Doporučujeme přepsat parametry nebo použít Key Vault k načtení hodnot parametrů. K vyřešení problému můžete také použít dvojité escape znaky.

3. Nasazení prostředí Integration Runtime selhalo.

Pokud máte šablonu pracovního prostoru vygenerovanou ze spravovaného pracovního prostoru s povolenou virtuální sítí a pokusíte se ji nasadit do běžného pracovního prostoru nebo naopak, dojde k této chybě.

4. Při analýze hodnoty byl zjištěn neočekávaný znak.

Šablonu nelze analyzovat jako soubor šablony. Zkuste to tak, že escapujete zpětná lomítka, například \\Test01\Test.

5. Načtení informací o pracovním prostoru se nezdařilo, nenalezena

Informace o cílovém pracovním prostoru nejsou správně nakonfigurované. Ujistěte se, že připojení služby, které jste vytvořili, je omezeno na skupinu prostředků, která obsahuje pracovní prostor.

6. Odstranění artefaktu se nezdařilo.

Rozšíření porovná artefakty ve publikační větvi se šablonou a na základě rozdílu je odstraní. Ujistěte se, že se nepokoušíte odstranit žádný artefakt, který se nachází ve větvi publikování, a některé jiné artefakty na něm mají odkaz nebo závislost.

7. Nasazení selhalo s chybou: pozice JSON 0

Pokud byste se pokusili šablonu aktualizovat ručně, dojde k této chybě. Ujistěte se, že jste šablonu neupravovali ručně.

8. Vytvoření nebo aktualizace dokumentu se nezdařilo kvůli neplatnému odkazu.

Na artefakt v synapse může odkazovat jiný artefakt. Pokud jste parametrizovali atribut, na který se odkazuje v artefaktu, ujistěte se, že jste zadali správnou a nenulovou hodnotu.

9. Nepodařilo se načíst stav nasazení v nasazení poznámkového bloku.

Poznámkový blok, který se pokoušíte nasadit, je připojený k fondu Spark v šablonovém souboru pracovního prostoru, zatímco při nasazení tento fond v cílovém pracovním prostoru neexistuje. Pokud název fondu neparametrizujete, ujistěte se, že fondy mají mezi prostředími stejný název.