Automazione del cloud basata su eventi

L'automazione dei flussi di lavoro e delle attività ripetitive nel cloud, usando tecnologie serverless, può migliorare notevolmente la produttività del team DevOps di un'organizzazione. Un modello serverless è ideale per gli scenari di automazione che soddisfano un approccio basato su eventi.

Architettura

Scenari

Questo articolo illustra due scenari chiave di automazione cloud:

1. Assegnazione di tag al centro di costo: questa implementazione tiene traccia dei centri di costo di ogni risorsa di Azure. Il servizio Criteri di Azure contrassegna tutte le nuove risorse in un gruppo con un ID centro di costo predefinito. Il Griglia di eventi di Azure monitora gli eventi di creazione delle risorse e quindi chiama una funzione di Azure. La funzione interagisce con Microsoft Entra ID e convalida l'ID centro di costo per la nuova risorsa. Se diverso, aggiorna il tag e invia un messaggio di posta elettronica al proprietario della risorsa. Le query REST per Microsoft Entra ID vengono fittizie per semplicità. Microsoft Entra ID può anche essere integrato usando il modulo Microsoft Graph PowerShell o Microsoft Authentication Library (MSAL) per Python.

2. Risposta di limitazione: in questo esempio viene monitorato un database di Azure Cosmos DB per la limitazione delle richieste. Gli avvisi di Monitoraggio di Azure vengono attivati quando le richieste di accesso ai dati ad Azure Cosmos DB superano la capacità in unità richiesta (o UR). Un gruppo di azioni di Monitoraggio di Azure è configurato per chiamare la funzione di automazione in risposta a questi avvisi. La funzione ridimensiona le UR a un valore superiore, aumentando la capacità e arrestando a sua volta gli avvisi.

L'implementazione di riferimento per lo scenario 1 è disponibile in GitHub.

Le funzioni in questi scenari di automazione cloud serverless sono spesso scritte in PowerShell e Python, due dei linguaggi di scripting più comuni usati nell'automazione del sistema. Vengono distribuiti usando Funzioni di Azure Core Tools nell'interfaccia della riga di comando di Azure. In alternativa, usare il cmdlet Az.Functions di PowerShell per distribuire e gestire Funzioni di Azure.

Workflow

Gli scenari di automazione basati su eventi vengono implementati in modo ottimale usando Funzioni di Azure. Seguono questi modelli comuni:

• Rispondere agli eventi sulle risorse. Si tratta di risposte a eventi quali una risorsa di Azure o un gruppo di risorse che vengono creati, eliminati, modificati e così via. Questo modello usa Griglia di eventi per attivare la funzione per tali eventi. Lo scenario di assegnazione di tag al centro di costo è un esempio di questo modello. Altri scenari comuni includono:

  • concedere ai team DevOps l'accesso ai gruppi di risorse appena creati,
  • invio di notifiche a DevOps quando una risorsa viene eliminata e
  • risposta agli eventi di manutenzione per risorse come Azure Macchine virtuali (VM).

• Attività pianificate. Si tratta in genere di attività di manutenzione eseguite usando funzioni attivate dal timer. Ecco alcuni esempi di questo modello:

  • arrestare una risorsa di notte e iniziare la mattina,
  • lettura del contenuto Archiviazione BLOB a intervalli regolari e conversione in un documento di Azure Cosmos DB
  • analizzare periodicamente le risorse non più in uso e rimuoverle e
  • backup automatizzati.

• Elaborare gli avvisi di Azure. Questo modello usa la facilità di integrazione di avvisi e gruppi di azioni di Monitoraggio di Azure con Funzioni di Azure. La funzione esegue in genere azioni correttive in risposta a metriche, log analytics e avvisi provenienti dalle applicazioni e dall'infrastruttura. Lo scenario di risposta alla limitazione è un esempio di questo modello. Altri scenari comuni sono:

  • troncamento della tabella quando database SQL raggiunge le dimensioni massime,
  • riavvio di un servizio in una macchina virtuale quando viene arrestato erroneamente e
  • invio di notifiche se una funzione ha esito negativo.

• Orchestrare con sistemi esterni. Questo modello consente l'integrazione con sistemi esterni, usando App per la logica per orchestrare il flusso di lavoro. I connettori di App per la logica possono essere facilmente integrati con diversi servizi di terze parti e servizi Microsoft come Microsoft 365. Funzioni di Azure può essere usato per l'automazione effettiva. Lo scenario di assegnazione di tag al centro di costo illustra questo modello. Altri scenari comuni includono:

  • monitoraggio di processi IT, ad esempio richieste di modifica o approvazioni e
  • invio di notifiche tramite posta elettronica al termine dell'attività di automazione.

• Esporre come web hook o API. Le attività di automazione che usano Funzioni di Azure possono essere integrate in applicazioni di terze parti o anche in strumenti da riga di comando, esponendo la funzione come web hook/API usando un trigger HTTP. In PowerShell e Python sono disponibili più metodi di autenticazione per proteggere l'accesso esterno alla funzione. L'automazione avviene in risposta agli eventi esterni specifici dell'app, ad esempio l'integrazione con power apps o GitHub. Gli scenari comuni includono:

  • attivazione dell'automazione per un servizio con errori e
  • onboarding degli utenti nelle risorse dell'organizzazione.

• Creare l'interfaccia ChatOps. Questo modello consente ai clienti di creare un'interfaccia operativa basata su chat ed eseguire funzioni di sviluppo e operazioni e comandi in linea con la collaborazione umana. Questa funzionalità può essere integrata con Azure Bot Framework e usare i comandi di Microsoft Teams o Slack per la distribuzione, il monitoraggio, le domande comuni e così via. Un'interfaccia ChatOps crea un sistema in tempo reale per la gestione degli eventi imprevisti di produzione, con ogni passaggio documentato automaticamente nella chat. Per altre informazioni, vedere How ChatOps can help you DevOps better (Come ChatOps può aiutarti a migliorare DevOps).

• Automazione ibrida. Questo modello usa gli Connessione ibridi del servizio app Azure per installare un componente software nel computer locale. Questo componente consente l'accesso sicuro alle risorse nel computer. La possibilità di gestire gli ambienti ibridi è attualmente disponibile nei sistemi basati su Windows usando le funzioni di PowerShell. Gli scenari comuni includono:

  • gestione dei computer locali e
  • gestione di altri sistemi dietro il firewall (ad esempio, un'istanza locale di SQL Server) tramite un jump server.

Componenti

Questa architettura è costituita dai componenti seguenti:

• Funzioni di Azure. Funzioni di Azure fornire le funzionalità di calcolo serverless basate su eventi in questa architettura. Una funzione esegue attività di automazione, quando vengono attivate da eventi o avvisi. In due scenari, viene richiamata una funzione con una richiesta HTTP. La complessità del codice deve essere ridotta al minimo, sviluppando la funzione senza stato e idempotente.

  Più esecuzioni di una funzione idempotente creano gli stessi risultati. Per mantenere l'idempotenza, il ridimensionamento delle funzioni nello scenario di limitazione viene mantenuto semplicistico. Nell'automazione del mondo reale assicurarsi di aumentare o ridurre le prestazioni in modo appropriato. Leggere Ottimizzare le prestazioni e l'affidabilità di Funzioni di Azure per le procedure consigliate durante la scrittura delle funzioni.

• App per la logica di Azure. Le app per la logica possono essere usate per eseguire attività più semplici, facilmente implementate usando i connettori predefiniti. Queste attività possono variare dalle notifiche tramite posta elettronica all'integrazione con applicazioni di gestione esterne. Per informazioni su come usare App per la logica con applicazioni di terze parti, vedere Integrazione aziendale di base in Azure.

  App per la logica non fornisce codice o progettazione visiva con codice ridotto e può essere usata da sola in alcuni scenari di automazione. Leggere questo confronto tra Funzioni di Azure e App per la logica per vedere quale servizio può adattarsi allo scenario.

• Griglia di eventi. Griglia di eventi include il supporto predefinito per gli eventi di altri servizi di Azure, nonché eventi personalizzati (detti anche argomenti personalizzati). Gli eventi operativi, ad esempio la creazione di risorse, possono essere facilmente propagati alla funzione di automazione, usando il meccanismo predefinito di Griglia di eventi.

  Griglia di eventi semplifica l'automazione basata su eventi con un modello di pubblicazione-sottoscrizione, consentendo un'automazione affidabile per gli eventi recapitati tramite HTTPS.

• Monitoraggio di Azure. Gli avvisi di Monitoraggio di Azure possono monitorare le condizioni critiche ed eseguire azioni correttive usando i gruppi di azioni di Monitoraggio di Azure. Questi gruppi di azioni sono facilmente integrati con Funzioni di Azure. Ciò è utile per controllare e correggere eventuali condizioni di errore nell'infrastruttura, ad esempio la limitazione delle richieste del database.

• Azione di automazione. Questo ampio blocco rappresenta altri servizi con cui la funzione può interagire, per fornire la funzionalità di automazione. Ad esempio, Microsoft Entra ID per la convalida dei tag come nel primo scenario o un database di cui eseguire il provisioning come nel secondo scenario.

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Framework ben progettato di Microsoft Azure.

Resilienza

Funzioni di Azure

Gestire i timeout HTTP

Per evitare timeout HTTP per un'attività di automazione più lunga, accodare questo evento in un bus di servizio e gestire l'automazione effettiva in un'altra funzione. Lo scenario di automazione delle risposte di limitazione illustra questo modello, anche se il provisioning effettivo delle UR di Azure Cosmos DB è veloce.

Durable Functions, che mantiene lo stato tra le chiamate, offre un'alternativa all'approccio precedente. Durable Functions supporta solo linguaggi specifici.

Errori del log

Come procedura consigliata, la funzione deve registrare eventuali errori nell'esecuzione di attività di automazione. In questo modo è possibile risolvere correttamente le condizioni di errore. Funzioni di Azure supporta l'integrazione in modo nativo con Application Insights come sistema di telemetria.

Concorrenza

Verificare il requisito di concorrenza per la funzione di automazione. La concorrenza è limitata impostando la variabile maxConcurrentRequests nel file host.json. Questa impostazione limita il numero di istanze di funzioni simultanee in esecuzione nell'app per le funzioni. Poiché ogni istanza utilizza CPU e memoria, questo valore deve essere regolato per le operazioni a elevato utilizzo di CPU. Abbassare il valore maxConcurrentRequests se le chiamate di funzione sembrano troppo lente o non sono in grado di completare. Per altri dettagli, vedere la sezione Configurare i comportamenti dell'host per gestire meglio la concorrenza .

Idempotenza

Assicurarsi che la funzione di automazione sia idempotente. Monitoraggio di Azure e Griglia di eventi possono generare avvisi o eventi che indicano la progressione, ad esempio l'evento sottoscritto, viene risolto, attivato, in corso e così via, il provisioning della risorsa viene eseguito correttamente, creato correttamente e così via o anche inviare falsi avvisi a causa di una configurazione errata. Assicurarsi che la funzione agisca solo sugli avvisi e sugli eventi pertinenti e ignori tutti gli altri, in modo che gli eventi false o non configurati in modo errato non causino risultati indesiderati. Per altre informazioni, vedere Progettazione di Funzioni di Azure per un input identico.

Griglia di eventi

Se il flusso di lavoro usa Griglia di eventi, verificare se lo scenario potrebbe generare un volume elevato di eventi, sufficiente per incollare la griglia. Vedere Recapito di messaggi di Griglia di eventi e riprovare a comprendere come gestisce gli eventi quando il recapito non viene riconosciuto e modificare la logica di conseguenza. Il flusso di lavoro del centro di costo non implementa controlli aggiuntivi, poiché controlla solo gli eventi di creazione delle risorse in un gruppo di risorse. Il monitoraggio delle risorse create in un'intera sottoscrizione può generare un numero maggiore di eventi, richiedendo una gestione più resiliente.

Monitoraggio di Azure

Se viene generato un numero sufficientemente elevato di avvisi e l'automazione aggiorna le risorse di Azure, potrebbero essere raggiunti limiti di limitazione di Azure Resource Manager . Ciò può influire negativamente sul resto dell'infrastruttura in tale sottoscrizione. Evitare questa situazione limitando la frequenza degli avvisi generati da Monitoraggio di Azure. È anche possibile limitare gli avvisi generati per un determinato errore. Per altre informazioni, vedere la documentazione sugli avvisi di Monitoraggio di Azure.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per altre informazioni, vedere Panoramica del pilastro della sicurezza.

Controllare l'accesso alla funzione

Limitare l'accesso a una funzione attivata tramite HTTP impostando il livello di autorizzazione. Con l'autenticazione anonima , la funzione è facilmente accessibile con un URL, http://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME>ad esempio . L'autenticazione a livello di funzione può offuscare l'endpoint HTTP, richiedendo chiavi di funzione nell'URL. Questo livello viene impostato nel file function.json:

{
  "bindings": [
    {
      "authLevel": "function",
      "type": "httpTrigger",
      "direction": "in",
      "name": "Request",
      "methods": [
        "get",
        "post"
      ]
    },
    {
      "type": "http",
      "direction": "out",
      "name": "Response"
    }
  ]
}

Per l'ambiente di produzione, potrebbero essere necessarie strategie aggiuntive per proteggere la funzione. In questi scenari, le funzioni vengono eseguite all'interno della piattaforma Azure da altri servizi di Azure e non verranno esposte a Internet. L'autorizzazione della funzione è talvolta sufficiente per le funzioni a cui si accede come web hook.

Prendere in considerazione l'aggiunta di livelli di sicurezza all'autenticazione delle funzioni, ad esempio

• autenticazione con certificati client o
• assicurarsi che il chiamante faccia parte di o abbia accesso alla directory che ospita la funzione, abilitando servizio app Authentication.

L'autenticazione a livello di funzione è l'unica opzione disponibile per i gruppi di azioni di Monitoraggio di Azure usando Funzioni di Azure.

Se la funzione deve essere chiamata da un'applicazione o un servizio di terze parti, è consigliabile fornire l'accesso a tale applicazione con un livello Gestione API. Questo livello deve applicare l'autenticazione. Gestione API ha un livello di consumo integrato con Funzioni di Azure, che consente di pagare solo se l'API viene eseguita. Per altre informazioni, vedere Creare ed esporre le funzioni con OpenAPI.

Se il servizio chiamante supporta endpoint di servizio o collegamento privato, è possibile considerare le opzioni più costose seguenti:

• Usare un piano di servizio app dedicato, in cui è possibile bloccare le funzioni in una rete virtuale per limitare l'accesso. Questo non è possibile in un modello serverless basato sul consumo.
• Usare il piano Funzioni di Azure Premium, che include una rete virtuale dedicata da usare dalle app per le funzioni.

Per confrontare i prezzi e le funzionalità tra queste opzioni, leggere Funzioni di Azure scalabilità e hosting.

Controllare a cosa può accedere la funzione

Le identità gestite per le risorse di Azure, una funzionalità di Microsoft Entra, semplificano il modo in cui la funzione autentica e accede ad altre risorse e servizi di Azure. Il codice non deve gestire le credenziali di autenticazione, poiché è gestito da Microsoft Entra ID.

Sono disponibili due tipi di identità gestite:

• Identità gestite assegnate dal sistema: vengono create come parte della risorsa di Azure e non possono essere condivise tra più risorse. Questi vengono eliminati quando la risorsa viene eliminata. Usare questi elementi per scenari, che coinvolgono una singola risorsa di Azure o che necessitano di identità indipendenti. Entrambi gli scenari usano identità assegnate dal sistema perché aggiornano solo una singola risorsa. Le identità gestite sono necessarie solo per aggiornare un'altra risorsa. Ad esempio, una funzione può leggere i tag di risorsa senza un'identità gestita. Vedere queste istruzioni per aggiungere un'identità assegnata dal sistema alla funzione.

• Identità gestite assegnate dall'utente: queste vengono create come risorse di Azure autonome. Questi possono essere condivisi tra più risorse e devono essere eliminati in modo esplicito quando non sono più necessari. Leggere queste istruzioni su come aggiungere un'identità assegnata dall'utente alla funzione. Usare questi elementi per gli scenari che:

  • Richiedere l'accesso a più risorse che possono condividere una singola identità o
  • È necessaria la pre-autorizzazione per proteggere le risorse durante il provisioning o
  • Disporre di risorse riciclate di frequente, mentre le autorizzazioni devono essere coerenti.

Dopo aver assegnato l'identità alla funzione di Azure, assegnargli un ruolo usando il controllo degli accessi in base al ruolo di Azure per accedere alle risorse. Ad esempio, per aggiornare una risorsa, è necessario assegnare il ruolo Collaboratore all'identità della funzione.

Ottimizzazione dei costi

L'ottimizzazione dei costi riguarda l'analisi dei modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Panoramica del pilastro di ottimizzazione dei costi.

Usare il calcolatore dei prezzi di Azure per stimare i costi. Di seguito sono riportate alcune considerazioni per ridurre i costi.

App per la logica di Azure

Le app per la logica hanno un modello di prezzi con pagamento in base al consumo. I trigger, le azioni e le esecuzioni del connettore vengono conteggiati ogni volta che si esegue un'app per la logica. Tutte le azioni riuscite e non riuscite, inclusi i trigger, vengono considerate come esecuzioni.

Anche le app per la logica hanno un modello tariffario fisso. Se è necessario eseguire app per la logica che comunicano con risorse protette in una rete virtuale di Azure, è possibile crearle in un ambiente del servizio di integrazione (I edizione Standard).

Per informazioni dettagliate, vedere Modello di prezzi per App per la logica di Azure.

In questa architettura, le app per la logica vengono usate nello scenario di assegnazione di tag al centro di costo per orchestrare il flusso di lavoro.

I connettori predefiniti vengono usati per connettersi a Funzioni di Azure e inviare una notifica tramite posta elettronica quando viene completata un'attività di automazione. Le funzioni vengono esposte come web hook/API usando un trigger HTTP. Le app per la logica vengono attivate solo quando si verifica una richiesta HTTPS. Si tratta di un modo conveniente rispetto a una progettazione in cui le funzioni eseguano continuamente il polling e controllino determinati criteri. Ogni richiesta di polling viene a consumo come azione.

Per altre informazioni, vedere Prezzi di App per la logica.

Funzioni di Azure

Funzioni di Azure sono disponibili con i tre piani tariffari seguenti.

• Piano a consumo. Questo è il piano serverless più conveniente disponibile, in cui si paga solo per il tempo di esecuzione della funzione. In questo piano, le funzioni possono essere eseguite per un massimo di 10 minuti alla volta.

• Piano Premium. È consigliabile usare Funzioni di Azure piano Premium per scenari di automazione con requisiti aggiuntivi, ad esempio una rete virtuale dedicata, una durata di esecuzione più lunga e così via. Queste funzioni possono essere eseguite fino a un'ora e devono essere scelte per attività di automazione più lunghe, ad esempio l'esecuzione di backup, l'indicizzazione del database o la generazione di report.

• Piano di servizio app. Gli scenari di automazione ibrida che usano le Connessione ibride del servizio app Azure, dovranno usare il piano di servizio app. Le funzioni create in questo piano possono essere eseguite per una durata illimitata, simile a un'app Web.

In questi scenari di automazione Funzioni di Azure vengono usati per attività quali l'aggiornamento dei tag in Microsoft Entra ID o la modifica della configurazione di Azure Cosmos DB aumentando le UR a un valore superiore. Il piano a consumo è appropriato per questo caso d'uso perché tali attività sono interattive e non a esecuzione prolungata.

Azure Cosmos DB

Azure Cosmos DB fattura la velocità effettiva con provisioning e l'archiviazione usata ogni ora. La velocità effettiva con provisioning è espressa in unità richiesta al secondo (UR/sec), che può essere usata per operazioni di database tipiche, ad esempio inserimenti, letture. Archiviazione vengono fatturati per ogni GB usato per i dati e l'indice archiviati. Per altre informazioni, vedere Modello di prezzi di Azure Cosmos DB.

In questa architettura, quando le richieste di accesso ai dati ad Azure Cosmos DB superano la capacità in unità richiesta (o UR), Monitoraggio di Azure attiva gli avvisi. In risposta a tali avvisi, un gruppo di azioni di Monitoraggio di Azure è configurato per chiamare la funzione di automazione. La funzione ridimensiona le UR a un valore superiore. Ciò consente di ridurre i costi perché si paga solo per le risorse necessarie per i carichi di lavoro su base oraria.

Per ottenere una stima rapida dei costi del carico di lavoro, usare il calcolatore della capacità di Azure Cosmos DB.

Per altre informazioni, vedere la sezione Costo in Microsoft Azure Well-Architected Framework.

Considerazioni sulla distribuzione

Per i flussi di lavoro di automazione critici che gestiscono il comportamento dell'applicazione, è necessario ottenere una distribuzione senza tempi di inattività usando una pipeline DevOps efficiente. Per altre informazioni, vedere Distribuzione back-end serverless.

Se l'automazione copre più applicazioni, mantenere le risorse richieste dall'automazione in un gruppo di risorse separato. Un singolo gruppo di risorse può essere condiviso tra l'automazione e le risorse dell'applicazione, se l'automazione copre una singola applicazione.

Se il flusso di lavoro prevede una serie di funzioni di automazione, raggruppare le funzioni in un unico scenario in una singola app per le funzioni. Per altre informazioni, vedere Gestire l'app per le funzioni.

Quando si distribuisce l'applicazione, sarà necessario monitorarla. Prendere in considerazione l'uso di Application Insights per consentire agli sviluppatori di monitorare le prestazioni e rilevare i problemi.

Per altre informazioni, vedere la sezione DevOps in Microsoft Azure Well-Architected Framework.

Azioni imperative sulle risorse di Azure

In entrambi gli scenari precedenti, il risultato finale è stato un cambiamento nello stato delle risorse di Azure tramite l'interazione diretta di Azure Resource Manager. Anche se si tratta del risultato previsto, considerare l'impatto che si verifica nell'ambiente se le risorse modificate sono state originariamente distribuite in modo dichiarativo, ad esempio dai modelli Bicep o Terraform. A meno che tali modifiche non vengano replicate nuovamente nei modelli di origine, l'utilizzo successivo di tali modelli potrebbe annullare le modifiche apportate da questa automazione. Prendere in considerazione l'impatto della combinazione di modifiche imperative alle risorse di Azure distribuite regolarmente tramite modelli.

Distribuire lo scenario

Per distribuire lo scenario del centro di costo, vedere la procedura di distribuzione in GitHub.

Passaggi successivi

• Formazione: Introduzione alle Funzioni di Azure
• Documentazione: Introduzione alle Funzioni di Azure
• Che cos'è Griglia di eventi di Azure?

Risorse correlate

• Procedura dettagliata del codice: applicazione serverless con Funzioni
• Progettazione dell'architettura delle funzioni serverless
• Architetture di riferimento per le funzioni serverless