Ciągła integracja i ciągłe dostarczanie dla obszaru roboczego usługi Azure Synapse Analytics

Ciągła integracja to proces automatyzacji kompilacji i testowania kodu za każdym razem, gdy członek zespołu zatwierdzi zmianę w systemie kontroli wersji. Ciągłe dostarczanie (CD) to proces kompilowania, testowania, konfigurowania i wdrażania z wielu środowisk testowych lub przejściowych do środowiska produkcyjnego.

W obszarze roboczym usługi Azure Synapse Analytics ciągła integracja/ciągłe wdrażanie przenosi wszystkie jednostki z jednego środowiska (programowanie, testowanie, produkcja) do innego środowiska. Podwyższanie poziomu obszaru roboczego do innego obszaru roboczego jest procesem dwuczęściowym. Najpierw użyj szablonu usługi Azure Resource Manager (szablonu usługi ARM), aby utworzyć lub zaktualizować zasoby obszaru roboczego (pule i obszar roboczy). Następnie przeprowadź migrację artefaktów, takich jak skrypty SQL i notesy, definicje zadań platformy Spark, potoki, zestawy danych i inne artefakty przy użyciu narzędzi wdrażania obszaru roboczego usługi Synapse w usłudze Azure DevOps lub w usłudze GitHub.

W tym artykule opisano sposób użycia potoku wydania usługi Azure DevOps i funkcji GitHub Actions w celu zautomatyzowania wdrażania obszaru roboczego usługi Azure Synapse w wielu środowiskach.

Wymagania wstępne

Aby zautomatyzować wdrażanie obszaru roboczego usługi Azure Synapse w wielu środowiskach, należy spełnić następujące wymagania wstępne i konfiguracje. Możesz użyć usługi Azure DevOps lub GitHub zgodnie z preferencjami lub istniejącą konfiguracją.

Azure DevOps

Jeśli używasz usługi Azure DevOps:

• Przygotuj projekt usługi Azure DevOps do uruchomienia potoku wydania.
• Udziel wszystkim użytkownikom, którzy zaewidencjonują dostęp podstawowy kodu na poziomie organizacji, aby mogli zobaczyć repozytorium.
• Udziel właścicielowi uprawnienia do repozytorium usługi Azure Synapse.
• Upewnij się, że utworzono własnego agenta maszyny wirtualnej usługi Azure DevOps lub użyj hostowanego agenta usługi Azure DevOps.
• Udziel uprawnień do tworzenia połączenia usługi Azure Resource Manager dla grupy zasobów.
• Administrator firmy Microsoft Entra musi zainstalować rozszerzenie agenta wdrażania obszaru roboczego usługi Azure DevOps w organizacji usługi Azure DevOps.
• Utwórz lub nominuj istniejące konto usługi dla potoku do uruchomienia jako. Możesz użyć osobistego tokenu dostępu zamiast konta usługi, ale potoki nie będą działać po usunięciu konta użytkownika.

GitHub

Jeśli używasz usługi GitHub:

• Utwórz repozytorium GitHub zawierające artefakty obszaru roboczego usługi Azure Synapse i szablon obszaru roboczego.
• Upewnij się, że utworzono własny moduł uruchamiający lub użyj modułu uruchamiającego hostowanego w usłudze GitHub.

Microsoft Entra ID

• Jeśli używasz jednostki usługi, w obszarze Microsoft Entra ID utwórz jednostkę usługi do użycia na potrzeby wdrożenia.
• Jeśli używasz tożsamości zarządzanej, włącz tożsamość zarządzaną przypisaną przez system na maszynie wirtualnej na platformie Azure jako agenta lub moduł uruchamiającego, a następnie dodaj ją do programu Azure Synapse Studio jako administrator usługi Synapse.
• Aby wykonać te akcje, użyj roli administratora Entra firmy Microsoft.

Azure Synapse Analytics

Uwaga

Te wymagania wstępne można zautomatyzować i wdrożyć przy użyciu tego samego potoku, szablonu usługi ARM lub interfejsu wiersza polecenia platformy Azure, ale te procesy nie zostały opisane w tym artykule.

• Obszar roboczy "źródłowy", który jest używany do programowania, musi być skonfigurowany przy użyciu repozytorium Git w usłudze Azure Synapse Studio. Aby uzyskać więcej informacji, zobacz Kontrola źródła w usłudze Azure Synapse Studio.

• Skonfiguruj pusty obszar roboczy do wdrożenia w:

  1. Utwórz nowy obszar roboczy usługi Azure Synapse.
  2. Udziel jednostce usługi następujące uprawnienia do nowego obszaru roboczego usługi Synapse:
     • Microsoft.Synapse/workspaces/integrationruntimes/write
     • Microsoft.Synapse/workspaces/operationResults/read
     • Microsoft.Synapse/workspaces/read
  3. W obszarze roboczym nie konfiguruj połączenia repozytorium Git.
  4. W obszarze roboczym usługi Azure Synapse przejdź do obszaru Zarządzanie kontrolą dostępu w programie Studio>>. Przypisz element "Synapse Artifact Publisher" do jednostki usługi. Jeśli potok wdrażania będzie musiał wdrożyć zarządzane prywatne punkty końcowe, przypisz zamiast tego "Administrator usługi Synapse".
  5. W przypadku korzystania z połączonych usług, których informacje o połączeniu są przechowywane w usłudze Azure Key Vault, zaleca się przechowywanie oddzielnych magazynów kluczy w różnych środowiskach. Można również skonfigurować oddzielne poziomy uprawnień dla każdego magazynu kluczy. Na przykład możesz nie chcieć, aby członkowie zespołu mieli uprawnienia do wpisów tajnych produkcyjnych. Jeśli zastosujesz tę metodę, zalecamy zachowanie tych samych nazw wpisów tajnych we wszystkich etapach. Jeśli zachowasz te same nazwy wpisów tajnych, nie musisz parametrować poszczególnych parametry połączenia w środowiskach ciągłej integracji/ciągłego wdrażania, ponieważ jedyną rzeczą, która zmienia się, jest nazwa magazynu kluczy, który jest oddzielnym parametrem.

Inne wymagania wstępne

• Pule platformy Spark i własne środowiska Integration Runtime nie są tworzone w zadaniu wdrażania obszaru roboczego. Jeśli masz połączoną usługę korzystającą z własnego środowiska Integration Runtime, ręcznie utwórz środowisko uruchomieniowe w nowym obszarze roboczym.
• Jeśli elementy w obszarze roboczym programowania są dołączone do określonych pul, upewnij się, że utworzono lub sparametryzujesz te same nazwy pul w docelowym obszarze roboczym w pliku parametrów.
• Jeśli aprowizowane pule SQL zostaną wstrzymane podczas próby wdrożenia, wdrożenie może zakończyć się niepowodzeniem.

Aby uzyskać więcej informacji, zobacz Ciągła integracja/ciągłe wdrażanie w usłudze Azure Synapse Analytics — część 4 — potok wydania.

Konfigurowanie potoku wydania w usłudze Azure DevOps

W tej sekcji dowiesz się, jak wdrożyć obszar roboczy usługi Azure Synapse w usłudze Azure DevOps.

1. W usłudze Azure DevOps otwórz projekt utworzony dla wydania.

2. W menu po lewej stronie wybierz pozycję Wydania potoków>.

   

3. Wybierz pozycję Nowy potok. Jeśli masz istniejące potoki, wybierz pozycję Nowy>potok wydania.

4. Wybierz szablon Puste zadanie.

   

5. W polu Nazwa etapu wprowadź nazwę środowiska.

6. Wybierz pozycję Dodaj artefakt, a następnie wybierz repozytorium Git skonfigurowane przy użyciu usługi Azure Synapse Studio w środowisku deweloperów. Wybierz repozytorium Git, w którym zarządzasz pulami i szablonem arm obszaru roboczego. Jeśli używasz usługi GitHub jako źródła, utwórz połączenie usługi dla konta usługi GitHub i repozytoria ściągania. Aby uzyskać więcej informacji, zobacz Połączenia usług.

   

7. Wybierz gałąź szablonu usługi ARM zasobu. W polu Wersja domyślna wybierz pozycję Najnowsza z gałęzi domyślnej.

   

8. Dla gałęzi Artefakty domyślne wybierz gałąź publikowania repozytorium lub inne gałęzie niepublikacyjne, które obejmują artefakty usługi Synapse. Domyślnie gałąź publikowania to workspace_publish. W polu Wersja domyślna wybierz pozycję Najnowsza z gałęzi domyślnej.

   

Konfigurowanie zadania etapowego dla szablonu usługi ARM w celu utworzenia i zaktualizowania zasobu

Jeśli masz szablon usługi ARM, który wdraża zasób, taki jak obszar roboczy usługi Azure Synapse, pula Spark i SQL lub magazyn kluczy, dodaj zadanie wdrażania usługi Azure Resource Manager, aby utworzyć lub zaktualizować te zasoby:

1. W widoku etapu wybierz pozycję Wyświetl zadania etapu.

   

2. Utwórz nowe zadanie. Wyszukaj pozycję Wdrażanie szablonu usługi ARM, a następnie wybierz pozycję Dodaj.

3. Na karcie Zadania wdrażania wybierz subskrypcję, grupę zasobów i lokalizację dla obszaru roboczego. W razie potrzeby podaj poświadczenia.

4. W obszarze Akcja wybierz pozycję Utwórz lub zaktualizuj grupę zasobów.

5. W polu Szablon wybierz przycisk wielokropka (...). Przejdź do szablonu usługi ARM obszaru roboczego.

6. W obszarze Parametry szablonu wybierz pozycję ... , aby wybrać plik parametrów.

   

7. W polu Przesłoń parametry szablonu wybierz pozycję ..., a następnie wprowadź wartości parametrów, których chcesz użyć dla obszaru roboczego.

8. W obszarze Tryb wdrażania wybierz pozycję Przyrostowe.

9. (Opcjonalnie) Dodaj program Azure PowerShell dla udzielenia i zaktualizuj przypisanie roli obszaru roboczego. Jeśli używasz potoku wydania do utworzenia obszaru roboczego usługi Azure Synapse, jednostka usługi potoku zostanie dodana jako domyślny administrator obszaru roboczego. Możesz uruchomić program PowerShell, aby udzielić innym kontom dostępu do obszaru roboczego.

   

Ostrzeżenie

W trybie pełnego wdrażania zasoby w grupie zasobów, które nie są określone w nowym szablonie usługi ARM, są usuwane. Aby uzyskać więcej informacji, zobacz Tryby wdrażania usługi Azure Resource Manager.

Konfigurowanie zadania etapowego dla wdrożenia artefaktów usługi Azure Synapse

Użyj rozszerzenia wdrażania obszaru roboczego usługi Synapse, aby wdrożyć inne elementy w obszarze roboczym usługi Azure Synapse. Elementy, które można wdrożyć, obejmują zestawy danych, skrypty SQL i notesy, definicje zadań platformy Spark, środowisko Integration Runtime, przepływ danych, poświadczenia i inne artefakty w obszarze roboczym.

Instalowanie i dodawanie rozszerzenia wdrożenia

1. Wyszukaj i pobierz rozszerzenie z witryny Visual Studio Marketplace.

   

2. Wybierz organizację usługi Azure DevOps, w której chcesz zainstalować rozszerzenie.

   

3. Upewnij się, że jednostka usługi potoku usługi Azure DevOps ma uprawnienie Subskrypcja i jest przypisana jako administrator obszaru roboczego usługi Synapse dla obszaru roboczego.

4. Aby utworzyć nowe zadanie, wyszukaj pozycję Wdrożenie obszaru roboczego usługi Synapse, a następnie wybierz pozycję Dodaj.

   

Konfigurowanie zadania wdrażania

Zadanie wdrażania obsługuje trzy typy operacji, weryfikować tylko, wdrażać i weryfikować i wdrażać.

Uwaga

To rozszerzenie wdrożenia obszaru roboczego w programie nie jest zgodne z poprzednimi wersjami. Upewnij się, że zainstalowano i użyto najnowszej wersji. Informacje o wersji można przeczytać w temacie Omówieniew usłudze Azure DevOps i najnowszej wersji akcji usługi GitHub.

Zweryfikuj , czy artefakty usługi Synapse w gałęzi innej niżpublish mają być weryfikowane za pomocą zadania, a następnie wygeneruj szablon obszaru roboczego i plik szablonu parametrów. Operacja walidacji działa tylko w potoku YAML. Oto przykładowy plik 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>'    

Walidacja i wdrażanie można użyć do bezpośredniego wdrożenia obszaru roboczego z gałęzi innej niżpublish z folderem głównym artefaktu.

Uwaga

Zadanie wdrożenia musi pobrać pliki JS zależności z tego punktu końcowego web.azuresynapse.net, gdy typ operacji jest wybrany jako Weryfikuj lub Zweryfikuj i wdróż. Upewnij się, że punkt końcowy web.azuresynapse.net jest dozwolony, jeśli zasady sieciowe są włączone na maszynie wirtualnej.

Operacja sprawdzania poprawności i wdrażania działa zarówno w potoku klasycznym, jak i YAML. Oto przykładowy plik 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

Wdróż dane wejściowe operacji wdrażania obejmują szablon obszaru roboczego usługi Synapse i szablon parametru, który można utworzyć po opublikowaniu w gałęzi publikowania obszaru roboczego lub po weryfikacji. Jest taka sama jak wersja 1.x.

Typy operacji można wybrać na podstawie przypadku użycia. Poniżej przedstawiono przykład wdrożenia.

1. W zadaniu wybierz typ operacji jako Wdróż.

   

2. W zadaniu obok pozycji Szablon wybierz pozycję ... , aby wybrać plik szablonu.

3. Obok pozycji Parametry szablonu wybierz pozycję ... aby wybrać plik parametrów.

4. Wybierz połączenie, grupę zasobów i nazwę obszaru roboczego.

5. Obok pozycji Zastąpij parametry szablonu wybierz pozycję ... . Wprowadź wartości parametrów, których chcesz użyć dla obszaru roboczego, w tym parametry połączenia i kluczy kont używanych w połączonych usługach. Aby uzyskać więcej informacji, zobacz Ciągła integracja/ciągłe wdrażanie w usłudze Azure Synapse Analytics.

   

6. Wdrożenie zarządzanego prywatnego punktu końcowego jest obsługiwane tylko w wersji 2.x. Upewnij się, że wybrano odpowiednią wersję i sprawdź w szablonie Wdrażanie zarządzanych prywatnych punktów końcowych.

   

7. Aby zarządzać wyzwalaczami, możesz użyć przełącznika wyzwalacza, aby zatrzymać wyzwalacze przed wdrożeniem. Możesz również dodać zadanie w celu ponownego uruchomienia wyzwalaczy po zadaniu wdrożenia.

   

Ważne

W scenariuszach ciągłej integracji/ciągłego wdrażania typ środowiska Integration Runtime w różnych środowiskach musi być taki sam. Jeśli na przykład masz własne środowisko Integration Runtime w środowisku deweloperskim, to samo środowisko Integration Runtime musi być hostowane samodzielnie w innych środowiskach, takich jak w środowisku testowym i produkcyjnym. Podobnie, jeśli udostępniasz środowiska Integration Runtime na wielu etapach, środowiska Integration Runtime muszą być połączone i hostowane samodzielnie we wszystkich środowiskach, takich jak programowanie, testowanie i produkcja.

Tworzenie wydania na potrzeby wdrożenia

Po zapisaniu wszystkich zmian możesz wybrać pozycję Utwórz wydanie , aby ręcznie utworzyć wydanie. Aby dowiedzieć się, jak zautomatyzować tworzenie wersji, zobacz Wyzwalacze wydania usługi Azure DevOps.

Konfigurowanie wydania w funkcji GitHub Actions

W tej sekcji dowiesz się, jak tworzyć przepływy pracy usługi GitHub przy użyciu funkcji GitHub Actions dla wdrożenia obszaru roboczego usługi Azure Synapse.

Za pomocą szablonu funkcji GitHub Actions dla usługi Azure Resource Manager można zautomatyzować wdrażanie szablonu usługi ARM na platformie Azure dla obszarów roboczych i pul obliczeniowych.

Plik przepływu pracy

Zdefiniuj przepływ pracy funkcji GitHub Actions w pliku YAML (.yml) w ścieżce /.github/workflows/ w repozytorium. Definicja zawiera różne kroki i parametry, które tworzą przepływ pracy.

Plik .yml zawiera dwie sekcje:

Sekcja	Zadania
Authentication	1. Zdefiniuj jednostkę usługi. 2. Utwórz wpis tajny usługi GitHub.
Wdrażanie	Wdróż artefakty obszaru roboczego.

Konfigurowanie wpisów tajnych funkcji GitHub Actions

Wpisy tajne funkcji GitHub Actions to zmienne środowiskowe, które są szyfrowane. Każdy, kto ma uprawnienie Współpracownik do tego repozytorium, może używać tych wpisów tajnych do interakcji z akcjami w repozytorium.

1. W repozytorium GitHub wybierz kartę Ustawienia, a następnie wybierz pozycję Wpisy tajne> Nowego repozytorium.

   

2. Dodaj nowy wpis tajny dla identyfikatora klienta i dodaj nowy klucz tajny klienta, jeśli używasz jednostki usługi do wdrożenia. Możesz również zapisać identyfikator subskrypcji i identyfikator dzierżawy jako wpisy tajne.

Dodawanie przepływu pracy

W repozytorium GitHub przejdź do pozycji Akcje.

1. Wybierz pozycję Skonfiguruj przepływ pracy samodzielnie.

2. W pliku przepływu pracy usuń wszystko po on: sekcji. Na przykład pozostały przepływ pracy może wyglądać następująco:

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

3. Zmień nazwę przepływu pracy. Na karcie Marketplace wyszukaj akcję wdrażania obszaru roboczego usługi Synapse, a następnie dodaj akcję.

   

4. Ustaw wymagane wartości i szablon obszaru roboczego:

   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. Możesz przystąpić do zatwierdzania zmian. Wybierz pozycję Rozpocznij zatwierdzenie, wprowadź tytuł, a następnie dodaj opis (opcjonalnie). Następnie wybierz pozycję Zatwierdź nowy plik.

   

   Plik zostanie wyświetlony w folderze .github/workflows w repozytorium.

   Uwaga

   Tożsamość zarządzana jest obsługiwana tylko w przypadku własnych maszyn wirtualnych na platformie Azure. Pamiętaj, aby ustawić moduł uruchamiający na własny host. Włącz tożsamość zarządzaną przypisaną przez system dla maszyny wirtualnej i dodaj ją do programu Azure Synapse Studio jako administrator usługi Synapse.

Przeglądanie wdrożenia

1. W repozytorium GitHub przejdź do pozycji Akcje.

2. Aby wyświetlić szczegółowe dzienniki przebiegu przepływu pracy, otwórz pierwszy wynik:

   

Tworzenie parametrów niestandardowych w szablonie obszaru roboczego

Jeśli używasz automatycznej ciągłej integracji/ciągłego wdrażania i chcesz zmienić niektóre właściwości podczas wdrażania, ale właściwości nie są domyślnie sparametryzowane, możesz zastąpić domyślny szablon parametrów.

Aby zastąpić domyślny szablon parametrów, utwórz niestandardowy szablon parametrów o nazwie template-parameters-definition.json w folderze głównym gałęzi Git. Musisz użyć tej dokładnej nazwy pliku. Gdy obszar roboczy usługi Azure Synapse publikuje z gałęzi współpracy lub zadanie wdrażania weryfikuje artefakty w innych gałęziach, odczytuje ten plik i używa jego konfiguracji do wygenerowania parametrów. Jeśli obszar roboczy usługi Azure Synapse nie znajdzie tego pliku, jest używany domyślny szablon parametru.

Składnia parametrów niestandardowych

Aby utworzyć plik parametrów niestandardowych, możesz użyć następujących wskazówek:

• Wprowadź ścieżkę właściwości pod odpowiednim typem jednostki.
• Ustawienie nazwy * właściwości oznacza, że chcesz sparametryzować wszystkie właściwości w ramach właściwości (tylko w dół do pierwszego poziomu, a nie rekursywnie). Można ustawić wyjątki dla tej konfiguracji.
• Ustawienie wartości właściwości jako ciągu wskazuje, że chcesz sparametryzować właściwość. Użyj formatu <action>:<name>:<stype>.
  • <action> może być jednym z następujących znaków:
    • = oznacza zachowanie bieżącej wartości jako wartości domyślnej parametru.
    • - oznacza, że wartość domyślna parametru nie jest zachowywana.
    • |jest specjalnym przypadkiem dla wpisów tajnych z usługi Azure Key Vault dla parametry połączenia lub kluczy.
  • <name> to nazwa parametru. Jeśli jest ona pusta, przyjmuje nazwę właściwości. Jeśli wartość zaczyna się od - znaku, nazwa zostanie skrócona. Na przykład AzureStorage1_properties_typeProperties_connectionString zostanie skrócony do AzureStorage1_connectionString.
  • <stype> jest typem parametru. Jeśli <stype> wartość jest pusta, domyślnym typem jest string. Obsługiwane wartości: string, , securestring, boolint, objectsecureobject , i array.
• Określenie tablicy w pliku wskazuje, że pasująca właściwość w szablonie jest tablicą. Usługa Azure Synapse iteruje wszystkie obiekty w tablicy przy użyciu określonej definicji. Drugi obiekt, ciąg, staje się nazwą właściwości, która jest używana jako nazwa parametru dla każdej iteracji.
• Definicja nie może być specyficzna dla wystąpienia zasobu. Każda definicja ma zastosowanie do wszystkich zasobów tego typu.
• Domyślnie wszystkie bezpieczne ciągi (takie jak wpisy tajne usługi Key Vault) i bezpieczne ciągi (takie jak parametry połączenia, klucze i tokeny) są sparametryzowane.

Przykład definicji szablonu parametru

Oto przykładowa definicja szablonu parametru:

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

Poniżej przedstawiono wyjaśnienie sposobu konstruowania poprzedniego szablonu według typu zasobu.

notebooks

• Każda właściwość w ścieżce properties/bigDataPool/referenceName jest sparametryzowana z jego wartością domyślną. Możesz sparametryzować dołączoną pulę spark dla każdego pliku notesu.

sqlscripts

• W ścieżce properties/content/currentConnection właściwości poolName i databaseName są sparametryzowane jako ciągi bez wartości domyślnych w szablonie.

pipelines

• Każda właściwość w ścieżce activities/typeProperties/waitTimeInSeconds jest sparametryzowana. Każde działanie w potoku, które ma właściwość na poziomie kodu o nazwie waitTimeInSeconds (na przykład Wait działanie) jest sparametryzowane jako liczba, z nazwą domyślną. Właściwość nie będzie miała wartości domyślnej w szablonie usługi Resource Manager. Zamiast tego właściwość będzie wymagana podczas wdrażania usługi Resource Manager.
• Właściwość headers (na przykład w działaniu) jest sparametryzowana z object typem Web (Object). Właściwość headers ma wartość domyślną, która jest taka sama jak fabryka źródłowa.

integrationRuntimes

• Wszystkie właściwości w ścieżce typeProperties są sparametryzowane przy użyciu odpowiednich wartości domyślnych. Na przykład dwie właściwości znajdują się w obszarze IntegrationRuntimes właściwości typu: computeProperties i ssisProperties. Oba typy właściwości są tworzone z odpowiednimi wartościami domyślnymi i typami (Object).

triggers

• W obszarze typePropertiesparametry są sparametryzowane dwie właściwości:

  • Właściwość maxConcurrency ma wartość domyślną i jest typem string . Domyślna nazwa parametru maxConcurrency właściwości to <entityName>_properties_typeProperties_maxConcurrency.
  • Właściwość recurrence jest również sparametryzowana. Wszystkie właściwości w recurrence ramach właściwości mają być sparametryzowane jako ciągi z wartościami domyślnymi i nazwami parametrów. Wyjątkiem jest interval właściwość, która jest sparametryzowana jako int typ. Nazwa parametru ma sufiks .<entityName>_properties_typeProperties_recurrence_triggerSuffix freq Podobnie właściwość jest ciągiem i jest sparametryzowana jako ciąg. freq Jednak właściwość jest sparametryzowana bez wartości domyślnej. Nazwa jest skrócona i sufiksowana, na przykład <entityName>_freq.

  Uwaga

  Obecnie obsługiwanych jest maksymalnie 50 wyzwalaczy.

linkedServices

• Połączone usługi są unikatowe. Ponieważ połączone usługi i zestawy danych mają szeroką gamę typów, można zapewnić dostosowanie specyficzne dla typu. W poprzednim przykładzie dla wszystkich połączonych AzureDataLakeStore usług typu jest stosowany określony szablon. W przypadku wszystkich innych (zidentyfikowanych przy użyciu * znaku) stosowany jest inny szablon.
• Właściwość connectionString jest sparametryzowana jako securestring wartość. Nie ma wartości domyślnej. Nazwa parametru jest skrócona i sufiksowana ciągiem connectionString.
• Właściwość secretAccessKey jest sparametryzowana jako AzureKeyVaultSecret wartość (na przykład w połączonej usłudze Amazon S3). Właściwość jest automatycznie sparametryzowana jako wpis tajny usługi Azure Key Vault i pobierana ze skonfigurowanego magazynu kluczy. Można również sparametryzować sam magazyn kluczy.

datasets

• Chociaż można dostosowywać typy w zestawach danych, jawna konfiguracja *-level nie jest wymagana. W poprzednim przykładzie wszystkie właściwości zestawu danych w obszarze typeProperties są sparametryzowane.

Najlepsze rozwiązania dotyczące ciągłej integracji/ciągłego wdrażania

Jeśli korzystasz z integracji usługi Git z obszarem roboczym usługi Azure Synapse i masz potok ciągłej integracji/ciągłego wdrażania, który przenosi zmiany z programowania do testowania, a następnie do środowiska produkcyjnego, zalecamy następujące najlepsze rozwiązania:

• Integrowanie tylko obszaru roboczego programowania z usługą Git. Jeśli używasz integracji z usługą Git, zintegruj tylko obszar roboczy usługi Azure Synapse z usługą Git. Zmiany w obszarach roboczych testowych i produkcyjnych są wdrażane za pośrednictwem ciągłej integracji/ciągłego wdrażania i nie wymagają integracji z usługą Git.
• Przygotuj pule przed migracją artefaktów. Jeśli masz skrypt SQL lub notes dołączony do pul w obszarze roboczym programowania, użyj tej samej nazwy dla pul w różnych środowiskach.
• Synchronizowanie wersji w infrastrukturze jako scenariuszy kodu. Aby zarządzać infrastrukturą (sieciami, maszynami wirtualnymi, modułami równoważenia obciążenia i topologią połączeń) w modelu opisowym, użyj tej samej wersji, która jest używana przez zespół DevOps na potrzeby kodu źródłowego.
• Zapoznaj się z najlepszymi rozwiązaniami dotyczącymi usługi Azure Data Factory. Jeśli używasz usługi Data Factory, zapoznaj się z najlepszymi rozwiązaniami dotyczącymi artefaktów usługi Data Factory.

Rozwiązywanie problemów z wdrażaniem artefaktów

Wdrażanie artefaktów usługi Synapse za pomocą zadania wdrażania obszaru roboczego usługi Synapse

W usłudze Azure Synapse, w przeciwieństwie do usługi Data Factory, artefakty nie są zasobami usługi Resource Manager. Nie można użyć zadania wdrażania szablonu usługi ARM do wdrożenia artefaktów usługi Azure Synapse. Zamiast tego użyj zadania wdrażania obszaru roboczego usługi Synapse, aby wdrożyć artefakty i użyć zadania wdrożenia usługi ARM dla zasobów usługi ARM (pul i obszaru roboczego). W międzyczasie to zadanie obsługuje tylko szablony usługi Synapse, w których zasoby mają typ Microsoft.Synapse. Dzięki temu zadaniu użytkownicy mogą automatycznie wdrażać zmiany z dowolnych gałęzi bez ręcznego kliknięcia publikowania w programie Synapse Studio. Poniżej przedstawiono niektóre często zgłaszane problemy.

1. Publikowanie nie powiodło się: plik arm obszaru roboczego jest większy niż 20 MB

W usłudze Azure DevOps występuje ograniczenie rozmiaru pliku, na przykład w usłudze Azure DevOps maksymalny rozmiar pliku to 20 Mb. Gdy rozmiar pliku szablonu obszaru roboczego przekroczy 20 Mb, ten błąd występuje podczas publikowania zmian w programie Synapse Studio, w którym plik szablonu obszaru roboczego jest generowany i synchronizowany z usługą Git. Aby rozwiązać ten problem, możesz użyć zadania wdrażania usługi Synapse z weryfikacją lub walidacją i wdrożeniem operacji, aby zapisać plik szablonu obszaru roboczego bezpośrednio w agencie potoku i bez ręcznego publikowania w programie synapse Studio.

2. Nieoczekiwany błąd tokenu w wydaniu

Jeśli plik parametrów zawiera wartości parametrów, które nie zostały usunięte, potok wydania nie może przeanalizować pliku i wygenerować unexpected token błąd. Zalecamy zastąpienie parametrów lub użycie usługi Key Vault do pobierania wartości parametrów. Możesz również użyć podwójnych znaków ucieczki, aby rozwiązać problem.

3. Wdrożenie środowiska Integration Runtime nie powiodło się

Jeśli masz szablon obszaru roboczego wygenerowany na podstawie obszaru roboczego z włączoną zarządzaną siecią wirtualną i spróbuj wdrożyć go w zwykłym obszarze roboczym lub odwrotnie, ten błąd występuje.

4. Napotkano nieoczekiwany znak podczas analizowania wartości

Nie można przeanalizować pliku szablonu. Spróbuj, uciekając przed ukośnikami z tyłu, na przykład \\Test01\Test

5. Nie można pobrać informacji o obszarze roboczym, Nie znaleziono

Informacje o docelowym obszarze roboczym nie są poprawnie skonfigurowane. Upewnij się, że połączenie usługi, które zostało utworzone, ma zakres do grupy zasobów, która ma obszar roboczy.

6. Usuwanie artefaktu nie powiodło się

Rozszerzenie porówna artefakty obecne w gałęzi publikowania z szablonem i na podstawie różnicy, która je usunie. Upewnij się, że nie próbujesz usunąć żadnego artefaktu, który znajduje się w gałęzi publikowania, a jakiś inny artefakt ma odwołanie lub zależność od niego.

7. Wdrożenie nie powiodło się z powodu błędu: pozycja json 0

Jeśli próbujesz ręcznie zaktualizować szablon, ten błąd wystąpi. Upewnij się, że szablon nie został ręcznie edytowany.

8. Tworzenie lub aktualizowanie dokumentu nie powiodło się z powodu nieprawidłowego odwołania

Artefakt w usłudze Synapse można odwoływać się do innego. Jeśli atrybut jest sparametryzowany, do którego odwołuje się artefakt, upewnij się, że podaj poprawną i niepustą wartość

9. Nie można pobrać stanu wdrożenia we wdrożeniu notesu

Notes, który próbujesz wdrożyć, jest dołączony do puli platformy Spark w pliku szablonu obszaru roboczego, podczas gdy we wdrożeniu pula nie istnieje w docelowym obszarze roboczym. Jeśli nie sparametryzujesz nazwy puli, upewnij się, że ma taką samą nazwę dla pul między środowiskami.