Automatizzare l'integrazione continua usando le versioni di Azure Pipelines

SI APPLICA A: Azure Data Factory Azure Synapse Analytics

Suggerimento

Provare Data Factory in Microsoft Fabric, una soluzione di analisi all-in-one per le aziende. Microsoft Fabric copre tutto, dallo spostamento dati al data science, all'analisi in tempo reale, alla business intelligence e alla creazione di report. Vedere le informazioni su come iniziare una nuova prova gratuita!

Di seguito è riportata una guida per la configurazione di una versione di Azure Pipelines che automatizza la distribuzione di una data factory in più ambienti.

Requisiti

• Una sottoscrizione di Azure collegata ad Azure DevOps Server, in precedenza Visual Studio Team Foundation Server, o Azure Repos che usa l’endpoint servizio di Azure Resource Manager.

• Una data factory configurata con l'integrazione Git per Azure Repos.

• Un insieme di credenziali delle chiavi di Azure che contiene i segreti per ogni ambiente.

Configurare una versione di Azure Pipelines

1. In Azure DevOps aprire il progetto configurato con la data factory.

2. Sul lato sinistro della pagina selezionare Pipeline, quindi selezionare Versioni.

   

3. Selezionare Nuova pipeline oppure, se sono presenti pipeline esistenti, selezionare Nuova, quindi Nuova pipeline di versione.

4. Selezionare il modello Fase vuota.

   

5. Nella casella Nome fase immettere il nome dell'ambiente.

6. Selezionare Aggiungi artefatto, quindi selezionare il repository Git configurato con la data factory di sviluppo. Selezionare la pubblicazione del ramo del repository per il ramo predefinito. Per impostazione predefinita, questa pubblicazione del ramo è adf_publish. Per la versione predefinita, selezionare Più recente dal ramo predefinito.

   

7. Aggiungere un'attività di distribuzione di Azure Resource Manager:

   1. Nella visualizzazione dei passaggi selezionare Visualizza le attività della fase.

      

   2. Creare una nuova attività. Cercare Distribuzione del modello di Azure Resource Manager e quindi selezionare Aggiungi.

   3. Nell'attività Distribuzione scegliere la sottoscrizione, il gruppo di risorse e la posizione per la data factory di destinazione. Fornire le credenziali, se necessario.

   4. Nell'elenco Azione selezionare Creare o aggiornare un gruppo di risorse.

   5. Selezionare il pulsante con i puntini di sospensione (...) accanto alla casella Modello. Cercare il modello di Azure Resource Manager generato nel ramo di pubblicazione del repository Git configurato. Cercare il file ARMTemplateForFactory.json nella cartella <FactoryName> del ramo adf_publish. Per altri dettagli sull’uso di modelli di Resource Manager collegati, vedere Distribuzione di modelli di Azure Resource Manager collegati con VSTS e Uso di modelli collegati.

   6. Selezionare … accanto alla casella Parametri modello per scegliere il file dei parametri. Cercare il file ARMTemplateParametersForFactory.json nella cartella >FactoryName< del ramo adf_publish.

   7. Selezionare … accanto alla casella Esegui override dei parametri del modello e immettere i valori dei parametri desiderati per la data factory di destinazione. Per le credenziali provenienti da Azure Key Vault, immettere il nome del segreto tra virgolette doppie. Se, ad esempio, il nome del segreto è cred1, immettere "$(cred1)" per questo valore.

   8. Selezionare Incrementale per la Modalità di distribuzione.

      Avviso

      In modalità di distribuzione completa le risorse presenti nel gruppo di risorse ma che non sono specificate nel nuovo modello di Resource Manager verranno eliminate. Per altre informazioni, vedere Modalità di distribuzione di Azure Resource Manager

      

8. Salvare la pipeline di versione.

9. Per attivare una versione, selezionare Crea versione. Per automatizzare la creazione di versioni, vedere Trigger versione di Azure DevOps

   

Importante

Negli scenari CI/CD, il tipo di runtime di integrazione (IR) in ambienti diversi deve essere lo stesso. Ad esempio, se si dispone di un runtime di integrazione self-hosted nell'ambiente di sviluppo, anche lo stesso runtime di integrazione deve essere di tipo self-hosted in altri ambienti, come quelli di test e produzione. Analogamente, se si condividono runtime di integrazione tra più fasi, è necessario configurarli come self-hosted collegati in tutti gli ambienti, ad esempio quelli di sviluppo, test e produzione.

Ottenere segreti da Azure Key Vault

Se sono presenti segreti da passare in un modello di Azure Resource Manager, è consigliabile usare Azure Key Vault con la versione di Azure Pipelines.

Esistono due modi per gestire i segreti:

• Aggiungere i segreti al file dei parametri. Per altre informazioni, vedere Usare Azure Key Vault per passare valori di parametro protetti durante la distribuzione.

  Creare una copia del file dei parametri caricato nel ramo di pubblicazione. Impostare i valori dei parametri che si desidera ottenere da Key Vault usando il formato seguente:

  {
      "parameters": {
          "azureSqlReportingDbPassword": {
              "reference": {
                  "keyVault": {
                      "id": "/subscriptions/<subId>/resourceGroups/<resourcegroupId> /providers/Microsoft.KeyVault/vaults/<vault-name> "
                  },
                  "secretName": " < secret - name > "
              }
          }
      }
  }
  

  Quando si usa questo metodo, viene eseguito il pull automatico del segreto dall'insieme di credenziali delle chiavi.

  Il file dei parametri deve essere anche nel ramo di pubblicazione.

• Aggiungere un'attività di Azure Key Vault prima dell'attività di distribuzione di Azure Resource Manager descritta nella sezione precedente:

  1. Nella scheda Attività creare una nuova attività. Cercare Azure Key Vault e aggiungerlo.

  2. Nell'attività di Key Vault selezionare la sottoscrizione in cui è stato creato l'insieme di credenziali delle chiavi. Fornire le credenziali, se necessario, quindi selezionare l'insieme di credenziali delle chiavi.

  

Concedere le autorizzazioni all'agente di Azure Pipelines

L'attività di Azure Key Vault potrebbe non riuscire con un errore di accesso negato se non sono impostate le autorizzazioni corrette. Scaricare i log per la versione e individuare il file con estensione ps1 contenente il comando per concedere le autorizzazioni all'agente di Azure Pipelines. È possibile eseguire il comando direttamente. In alternativa, è possibile copiare l'ID dell'entità di sicurezza dal file e aggiungere manualmente il criterio di accesso nel portale di Azure. Get e List sono le autorizzazioni minime necessarie.

Aggiornamento di trigger attivi

Installare i moduli di Azure PowerShell più recenti seguendo le istruzioni descritte in Come installare e configurare Azure PowerShell.

Avviso

Se non si usano le versioni più recenti del modulo PowerShell e Data Factory, è possibile che si verifichino errori di deserializzazione durante l’esecuzione dei comandi.

La distribuzione può non riuscire se si prova ad aggiornare i trigger attivi. Per aggiornare trigger attivi, è necessario arrestarli manualmente e riavviarli dopo la distribuzione. Questa operazione può essere eseguita usando un'attività di Azure PowerShell:

1. Nella scheda Attività della versione aggiungere un'attività di Azure PowerShell. Scegliere la versione più recente di Azure PowerShell per la versione dell’attività.

2. Selezionare la sottoscrizione in cui risiede la factory.

3. Selezionare Percorso file script come tipo di script. A questo scopo, è necessario salvare lo script di PowerShell nel repository. Lo script di PowerShell seguente può essere usato per interrompere trigger:

   $triggersADF = Get-AzDataFactoryV2Trigger -DataFactoryName $DataFactoryName -ResourceGroupName $ResourceGroupName
   
   $triggersADF | ForEach-Object { Stop-AzDataFactoryV2Trigger -ResourceGroupName $ResourceGroupName -DataFactoryName $DataFactoryName -Name $_.name -Force }
   

È possibile completare passaggi simili (con la funzione Start-AzDataFactoryV2Trigger) per riavviare i trigger dopo la distribuzione.

Il team di Data Factory ha fornito un esempio di script di pre-distribuzione e post-distribuzione.

Nota

Usare PrePostDeploymentScript.Ver2.ps1 se si vuole disattivare/attivare solo i trigger modificati anziché disattivare/attivare tutti i trigger durante l’integrazione continua e recapito continuo (CI/CD).

Avviso

Assicurarsi di usare PowerShell Core nell’attività ADO per eseguire lo script

Contenuto correlato

• Panoramica dell’integrazione e del recapito continuo
• Alzare di livello manualmente un modello di Resource Manager per ogni ambiente
• Usare parametri personalizzati con un modello di Resource Manager
• Modelli di Resource Manager collegati
• Uso di un ambiente di produzione hotfix
• Esempio di script di pre-distribuzione e post-distribuzione