Considerazioni sull'automazione della piattaforma per Red Hat Enterprise Linux in Azure

Questo articolo descrive come gestire l'automazione per Red Hat Enterprise Linux (RHEL) in Azure. Descrive considerazioni di progettazione, raccomandazioni di progettazione e opzioni per vari strumenti all'interno dell'ecosistema di Azure che è possibile usare per ottenere un ambiente coerente e stabile. Questo articolo fornisce indicazioni che si allineano a vari scenari dei clienti, requisiti aziendali, procedure operative e maturità tecnica.

Panoramica

Quando si automatizza RHEL per le zone di destinazione di Azure, si usano Red Hat Infrastructure Standard (RH-IS) e il modello di adozione standard di Red Hat Infrastructure (RH-ISAM) associato per allineare la gestione del ciclo di vita della zona di destinazione di Azure. Standardizzare i sistemi per fornire una base affidabile per la soluzione. RH-IS definisce l'ambiente operativo standard che comprende il set predefinito di componenti e configurazioni software. È possibile applicare questi componenti e configurazioni ai sistemi tramite RH-ISAM, un set di principi operativi DevOps o Git, modelli di Azure Resource Manager (modelli ARM), Terraform, interfaccia della riga di comando di Azure e Azure PowerShell.

È possibile automatizzare varie operazioni. Ad esempio, è possibile usare l'automazione per:

• Effettuare il provisioning dei componenti.
• Gestire i sistemi.
• Eseguire l'evoluzione della piattaforma.
• Incorporare le operazioni dell'infrastruttura.
• Configurare i cicli di vita dell'applicazione e del carico di lavoro.

È possibile implementare queste operazioni tramite l'infrastruttura come codice (IaC) e la configurazione come codice. Per ridurre gli errori e aumentare l'affidabilità, definire e testare le configurazioni. Per velocizzare le migrazioni di massa, automatizzare il provisioning. Le configurazioni automatizzate riducono le deviazioni della configurazione e assicurano che i sistemi funzionino correttamente.

Considerazioni relative alla progettazione

Red Hat Identity Management (IdM) offre una piattaforma centralizzata e unificata che è possibile usare per gestire archivi di identità, criteri di autenticazione e criteri di autorizzazione per i sistemi RHEL. In uno scenario ibrido è possibile estendere l'infrastruttura Red Hat IdM esistente in una rete privata virtuale o in Azure ExpressRoute. Questa configurazione connette gli ambienti locali con la zona di destinazione RHEL all'interno di Azure. Per supportare scenari di identità cloud ibrida, estendere l'ambiente locale in Azure in modo da poter integrare i carichi di lavoro con Microsoft Entra. Per altre informazioni, vedere Autenticazione di Microsoft Entra.

Come soluzione alternativa per la gestione delle identità, è possibile aggiungere RHEL per creare un trust esterno con Windows Server Active Directory o partecipare direttamente a una foresta di Active Directory di Windows Server esistente. Per altre informazioni, vedere Integrare i sistemi RHEL direttamente con Windows Server Active Directory.

Red Hat Satellite è la singola origine di contenuto che viene distribuita ai sistemi RHEL gestiti. Satellite include pacchetti e patch Red Hat e pacchetti non Microsoft e pacchetti personalizzati sviluppati dai team di sviluppo di applicazioni. Satellite funge da gateway per Red Hat Insights, che offre un'analisi predittiva delle configurazioni per riconoscere i rischi per la sicurezza o le prestazioni. Se si distribuiscono immagini RHEL con pagamento in base al consumo preconfigurate, è possibile sfruttare Red Hat Update Infrastructure per Azure, che è uno strumento di aggiornamento integrato nelle immagini con pagamento in base al consumo.

Considerazioni sulla progettazione di Red Hat Ansible Automation Platform

Red Hat Ansible Automation Platform (AAP) consente di standardizzare flussi di lavoro tecnici e attività ricorrenti. È possibile usare AAP per orchestrare i flussi di lavoro, effettuare il provisioning dei processi per i nuovi sistemi e creare attività operative ricorrenti. Per ridurre la complessità, usare una piattaforma e un linguaggio di automazione comuni. I flussi di lavoro completamente automatizzati accelerano l'innovazione delle applicazioni e semplificano le migrazioni di carichi di lavoro di massa in ambienti locali e ambienti cloud.

I vantaggi di RHEL come strategia di automazione della piattaforma includono:

• I nuovi sistemi hanno il provisioning completamente automatizzato su larga scala, migliorando la velocità di migrazione di massa.

• Maggiore uniformità delle installazioni di applicazioni e configurazione dei sistemi testati nei sistemi fisici e nei sistemi virtuali.

• Aggiornamenti continui perché la gestione delle patch è immediatamente disponibile.

• Piattaforma standardizzata e semplificata per offrire nuove applicazioni e carichi di lavoro. Il personale ha tempo aggiuntivo per offrire una maggiore innovazione.

È possibile implementare:

• Istanza di AAP autogestito tramite l'infrastruttura locale, l'infrastruttura cloud o entrambi. È possibile usare una distribuzione RHEL o una distribuzione di Red Hat OpenShift Container Platform.

• Istanza di AAP autogestito in un cloud pubblico.

• Istanza di AAP gestita in un cloud pubblico.

Red Hat AAP self-managed in locale o nel cloud

Distribuire Red Hat AAP in Microsoft Azure in modalità self-managed in un'infrastruttura locale, cloud o ibrida per ottenere i vantaggi seguenti:

• Architettura e scalabilità: determinare l'architettura ideale per supportare la piattaforma di automazione. È possibile basare l'architettura sull'infrastruttura RHEL o su una distribuzione di operatori OpenShift. In base alle dimensioni e ai requisiti della flotta, scegliere il numero e il dimensionamento delle istanze di controller, nodi di esecuzione e istanze dell'hub di automazione privato. Per altre informazioni sull'architettura, la progettazione, la configurazione e la scalabilità, vedere la guida alla pianificazione di Red Hat AAP.

• Configurazione di Azure: ottimizzare l'architettura di automazione per la progettazione e la configurazione di Azure dell'organizzazione.

• Supporto della mesh di automazione: usare la funzionalità mesh di automazione AAP per distribuire i carichi di lavoro di automazione tra nodi cloud ibridi che stabiliscono connessioni peer-to-peer usando reti esistenti. Posizionare i nodi hop in una posizione in base ai criteri di progettazione della sicurezza e alla topologia di rete.

• Architettura dell'hub di automazione: ottimizzare un'architettura dell'hub di automazione per la scalabilità e il posizionamento di istanze dell'hub di automazione privato. Ottimizzare le configurazioni per migliorare la distribuzione sicura dei contenuti di automazione e l'accesso alle origini dell'ambiente di esecuzione vicine alle risorse di esecuzione di automazione. È possibile scegliere a quali raccolte di contenuti e versioni Ansible possono accedere gli utenti di automazione.

Red Hat AAP gestito o autogestito in Azure

Red Hat AAP in Microsoft Azure è disponibile tramite un'applicazione gestita o un'applicazione autogestito, che offre i vantaggi seguenti:

• Un rapido ritorno sugli investimenti (ROI) grazie alla facilità d'uso: è possibile distribuire AAP in Azure direttamente da Azure Marketplace. Questa soluzione gestita è attiva immediatamente dopo la distribuzione ed è possibile iniziare a automatizzare la gestione delle risorse di Azure in pochi minuti. Red Hat gestisce l'infrastruttura, quindi è possibile considerare gli altri sistemi fondamentali per l'azienda.

• Integrazione semplificata: AAP in Azure è integrato con i servizi di Azure. Microsoft e Red Hat hanno sviluppato e testato la raccolta Ansible per Azure, quindi è necessaria una configurazione minima e si ottiene il supporto massimo. Usare AAP in Azure come parte della strategia di automazione cloud ibrida per unificare la gestione e l'automazione tra cloud ibrido, Internet delle cose e distribuzioni perimetrali.

• Spesa di Azure con commit esistente: è possibile usare la spesa di commit esistente con Microsoft per acquistare Red Hat AAP in Azure. Usare la spesa di cui è stato eseguito il commit in modo che i team dell'intera organizzazione possano distribuire, configurare e automatizzare facilmente i componenti. La fatturazione integrata consente di ottenere una fattura e una visibilità completa sul costo.

• Automazione oltre il cloud: con AAP in Azure è possibile distribuire applicazioni nel cloud di Microsoft Azure e quindi estenderle nell'infrastruttura. Distribuire, eseguire e ridimensionare applicazioni in ambienti cloud ibridi e di Azure.

• Supporto: Red Hat e Microsoft hanno collaborato per creare AAP in Azure per garantire operazioni coerenti e incentrate sulla sicurezza. Red Hat gestisce, servizi e supporta l'applicazione in modo che il team IT possa concentrarsi sulla distribuzione di strategie di automazione.

Altre considerazioni sulla modalità gestita

È possibile installare AAP in Azure in modalità gestita in modo che si tratti di un'applicazione gestita. Red Hat gestisce sia le risorse di Azure sottostanti che il software in esecuzione. Tale infrastruttura viene eseguita nel tenant di Azure.

Il gruppo di risorse dell'applicazione gestita è separato da altri gruppi di risorse nel tenant. Red Hat ha accesso solo al gruppo di risorse dell'applicazione gestita, senza visibilità su altre risorse tenant.

Per altre informazioni, vedere Panoramica delle applicazioni gestite di Azure.

AAP in Azure in modalità gestita usa i gruppi di risorse seguenti:

• Un gruppo di risorse nuovo o esistente nel tenant. Questo gruppo di risorse include una singola risorsa che fa riferimento alla distribuzione di AAP in un'applicazione gestita di Azure. Red Hat ha accesso all'app gestita per eseguire il supporto, la manutenzione e gli aggiornamenti. Red Hat, tuttavia, non gestisce il gruppo di risorse.

• Gruppo di risorse gestite multi-tenant (MRG) che contiene la maggior parte dell'infrastruttura necessaria per gestire AAP in Azure. Il tenant di Red Hat e il tenant condividono questo gruppo di risorse multi-tenant. Red Hat ha il controllo amministrativo completo. È possibile accedere in sola lettura al gruppo di risorse.

• Gruppo di risorse del pool di nodi del servizio Azure Kubernetes (NPRG) servizio Azure Kubernetes. Microsoft richiede un server dei criteri di rete per le distribuzioni del servizio Azure Kubernetes. Un server dei criteri di rete contiene risorse usate dal servizio Azure Kubernetes per funzionare. Questo gruppo di risorse viene creato nella distribuzione. Red Hat non gestisce questo gruppo di risorse. Per altre informazioni, vedere la documentazione del servizio Azure Kubernetes Microsoft.

Per AAP in Azure in modalità gestita, considerare anche i fattori seguenti:

• Quando si installa AAP in Azure, si sceglie se la distribuzione è pubblica o privata, che influisce sul modo in cui gli utenti possono accedere alle interfacce utente AAP.

• Indipendentemente dal fatto che si scelga una distribuzione pubblica o privata, è necessario configurare il peering di rete per la comunicazione in uscita da AAP alle reti private che contengono risorse da automatizzare. È possibile configurare il peering di rete da AAP in Azure alla rete virtuale di Azure privata e alle reti locali o alle reti multicloud in cui esiste il routing di transito con Azure.

Altre considerazioni sulla modalità self-managed

AAP in Azure in modalità autogestito offre molti degli stessi vantaggi di AAP gestito. Tuttavia, quando la modalità gestita viene eseguita all'interno di un cluster del servizio Azure Kubernetes, le risorse della piattaforma di automazione in modalità self-managed sono basate su macchine virtuali (VM).

Per AAP in Azure in modalità autogestito, considerare i fattori seguenti:

• Ansible basato su eventi è incluso nell'offerta self-managed in Azure. L'automazione basata su eventi consente di ridurre le attività manuali e di offrire un ambiente IT efficiente incentrato sull'innovazione. Ansible basato su eventi elabora gli eventi, determina le risposte appropriate e quindi esegue azioni automatizzate per correggere l'evento.

• Le sottoscrizioni sono disponibili in 100 incrementi di nodi gestiti attivi. Sono disponibili in offerte pubbliche o offerte private.

• Le risorse vm che supportano AAP in Azure in modalità autogestito possono essere costituite interamente da immagini di Azure Marketplace o da una combinazione di immagini di Azure Marketplace e immagini gestite dal cliente.

Suggerimenti per la progettazione

Quando si gestisce la piattaforma RHEL per le zone di destinazione di Azure, usare contenuti certificati Red Hat e raccolte di contenuto convalidate dall'hub di automazione Red Hat. Le raccolte seguenti hanno ruoli importanti nel framework di automazione:

• redhat.rhel_idm

  • Configurare le macchine virtuali primarie idM.
  • Configurare le repliche IdM.
  • Integrare e configurare i client RHEL con IdM.

• redhat.satellite, redhat.satellite_operations e redhat.rhel_system_roles

  • Distribuire Satellite e Capsule.
  • Creare e configurare oggetti satellite e impostazioni.
  • Effettuare il provisioning e configurare i sistemi RHEL.

• ansible.*, ansible.controller e infra.controller_configuration

  • Configurare AAP.
  • Creare e configurare le impostazioni e i modelli di processo AAP.

La raccolta Ansible per Azure include oltre 250 moduli che è possibile usare per interrogare, gestire e automatizzare i tipi di risorse di Azure, ad esempio:

• AKS.
• Gruppi di sicurezza delle applicazioni.
• Registro Azure Container.
• Servizi di database di Azure.
• Azure Key Vault.
• Database SQL di Azure.
• Macchine virtuali di Azure.
• Microsoft Entra ID.
• Reti.
• Archiviazione.

Distribuzione dell'infrastruttura della piattaforma principale

Definire concetti e processi per distribuire in modo efficace l'infrastruttura della piattaforma principale e supportare una piattaforma RHEL nel modello di zone di destinazione di Azure.

Per altre informazioni, vedi:

• Linee guida per la progettazione della zona di destinazione di Azure per considerazioni sull'automazione della piattaforma.

• Ciclo di vita dello sviluppo. Esplorare le considerazioni chiave sulla progettazione e le raccomandazioni sull'uso dell'automazione per creare una zona di destinazione. Queste linee guida illustrano il repository, il ramo, le compilazioni automatizzate, la distribuzione e la strategia di rollback.

• IaC. Esplorare i vantaggi dell'implementazione delle zone di destinazione di Azure tramite IaC. Informazioni sulle considerazioni relative alla struttura del codice, agli strumenti e alla tecnologia.

• Ambienti. Informazioni su come usare più ambienti per compilare, testare e rilasciare codice con maggiore velocità e frequenza. Questo approccio rende la distribuzione il più semplice possibile.

• Sviluppo basato su test. Informazioni su come usare unit test per migliorare la qualità delle nuove funzionalità e apportare miglioramenti alla codebase della zona di destinazione di Azure.

Quando sono disponibili gli strumenti di gestione del codice sorgente necessari e i processi di gestione del codice sorgente stabiliti dalle sezioni precedenti, è possibile implementare l'automazione. Sviluppare codice di automazione Ansible con l'associazione IaC o la configurazione come codice per distribuire l'infrastruttura di base e supportare la piattaforma RHEL per il modello di zone di destinazione di Azure. Per le distribuzioni greenfield, è possibile automatizzare le attività seguenti per un'implementazione ambientale completa. Per le distribuzioni brownfield, è possibile automatizzare solo le attività richieste dal caso d'uso.

• Creare gruppi di risorse di Azure.
• Creare reti virtuali.
• Creare subnet.
• Creare gruppi di sicurezza di rete.
• Creare immagini dorate RHEL 8.x e 9.x per Azure tramite Red Hat Image Builder automatizzato.
• Creare una macchina virtuale primaria IdM (provisioning pre-satellite). Configurare la macchina virtuale primaria IdM tramite la configurazione come codice.
• Creare una macchina virtuale satellite (provisioning pre-satellite). Configurare Satellite tramite la configurazione come codice.
• Creare macchine virtuali Capsule (provisioning satellite). Configurare Capsule tramite la configurazione come codice.
• Creare macchine virtuali di replica IdM (provisioning satellite). Configurare le repliche IdM tramite la configurazione come codice.
• Creare un'infrastruttura AAP (provisioning satellite), tra cui:
  • Macchine virtuali del controller di automazione.
  • Macchine virtuali del nodo di esecuzione.
  • Macchine virtuali del nodo hop (facoltativo).
  • Macchine virtuali dell'hub di automazione.
  • Macchine virtuali Ansible guidate dagli eventi (se abilitate).
  • Database di Azure per PostgreSQL server e i database necessari per i componenti ansible basati su controller, hub e eventi. La disponibilità elevata o il ripristino di emergenza Database di Azure per PostgreSQL configurazioni richiedono un'automazione aggiuntiva tramite la distribuzione della replica, il log shipping o Crunchy Postgres.
• Creare servizi di bilanciamento del carico (gateway applicazione).
  • Front-end per le macchine virtuali Capsule
  • Front-end per macchine virtuali controller AAP
  • Front-end per le macchine virtuali dell'hub di Automazione
• Creare gruppi di sicurezza delle applicazioni.
  • Infrastruttura IdM
  • Infrastruttura AAP
  • Infrastruttura satellite o capsule

Gestione del ciclo di vita del sistema RHEL

Dopo aver implementato l'infrastruttura della piattaforma principale, è possibile implementare l'automazione per le applicazioni RHEL e i cicli di vita dei carichi di lavoro. Il flusso di lavoro seguente descrive un'implementazione di automazione di esempio per una pipeline del ciclo di vita di sviluppo:

1. Aggiornare la data di fine del filtro errata e pubblicare il contenuto in Satellite.

2. Promuovere le visualizzazioni contenuto (CV) e le visualizzazioni di contenuto composito (CCV) allo sviluppo.

3. Distribuire sistemi di test di sviluppo RHEL dai gruppi host satellite. Le immagini d'oro RHEL 8.x e 9.x per Azure tramite Red Hat Image Builder automatizzato vengono definite come risorse di calcolo di Azure in Satellite.

4. Aggiornare o creare gruppi di sicurezza di rete di Azure in base ai percorsi di comunicazione delle applicazioni.

5. Aggiornare o creare gruppi di sicurezza delle applicazioni di Azure per offrire sicurezza a più livelli per gli stack di applicazioni a più livelli.

6. Aggiornare i sistemi di sviluppo RHEL e distribuire e configurare le applicazioni desiderate da Satellite development CV o CCV.

   • Eseguire la distribuzione in una singola istanza RHEL per uno stack di applicazioni semplice.
   • Eseguire la distribuzione in diverse istanze di RHEL per stack di applicazioni a più livelli.
   • Configurare uno stack di applicazioni.

7. Eseguire un framework di test dell'applicazione.

   • Se il test non riesce, inviare una notifica all'amministrazione dell'automazione OnCall per facilitare la risoluzione dei problemi e l'analisi. Uscire dal flusso di lavoro di automazione. I sistemi di test RHEL rimangono distribuiti per l'analisi degli errori post-mortem.
   • Se il test ha esito positivo, continuare i passaggi.

8. Promuovere cv e CCV a controllo di qualità (QA).

9. Eliminare definitivamente i sistemi di test di sviluppo RHEL.

Le fasi successive nella pipeline del ciclo di vita sono leggermente diverse dalla fase del ciclo di vita di sviluppo. Solo la fase di sviluppo usa la pubblicazione iniziale del contenuto e la promozione INIZIALE cv e CCV per lo sviluppo. L'esempio seguente descrive un flusso di lavoro di automazione per le pipeline del ciclo di vita non di sviluppo, ad esempio qa, preproduzione e pipeline di produzione.

1. Distribuire sistemi di test di controllo di qualità RHEL dai gruppi host satellite. Le immagini d'oro RHEL 8.x e 9.x per Azure tramite Red Hat Image Builder automatizzato vengono definite come risorse di calcolo di Azure in Satellite.

2. Aggiornare o creare gruppi di sicurezza di rete di Azure in base ai percorsi di comunicazione delle applicazioni.

3. Aggiornare o creare gruppi di sicurezza delle applicazioni di Azure per offrire sicurezza a più livelli per gli stack di applicazioni a più livelli.

4. Aggiornare i sistemi di controllo di qualità RHEL e distribuire e configurare le applicazioni desiderate da CV o CCV in Controllo di qualità satellite.

   • Eseguire la distribuzione in una singola istanza RHEL per uno stack di applicazioni semplice.
   • Eseguire la distribuzione in diverse istanze di RHEL per stack di applicazioni a più livelli.
   • Configurare uno stack di applicazioni.

5. Eseguire un framework di test dell'applicazione.

   • Se il test non riesce, inviare una notifica all'amministrazione dell'automazione OnCall per facilitare la risoluzione dei problemi e l'analisi. Uscire dal flusso di lavoro di automazione. I sistemi di test RHEL rimangono distribuiti per l'analisi degli errori post-mortem.
   • Se il test ha esito positivo, continuare i passaggi.

6. Alzare di livello i CV e i CCV all'ambiente di produzione.

7. Distruggere i sistemi di test RHEL QA.

Altre considerazioni sulla progettazione per gli strumenti nativi di Azure

Automazione di Azure

Per automatizzare attività di gestione frequenti, dispendiose in termini di tempo e soggette a errori, è possibile usare la funzionalità di automazione dei processi in Automazione di Azure. Questa funzionalità consente di concentrarsi sul lavoro che aggiunge valore aziendale. L'automazione dei processi riduce gli errori e aumenta l'efficienza, riducendo i costi operativi. Per altre informazioni, vedere Panoramica dell'automazione.

L'automazione dei processi supporta l'integrazione dei servizi di Azure e di altri sistemi partner, ad esempio Red Hat, che è necessario distribuire, configurare e gestire i processi end-to-end. È anche possibile usare questa funzionalità per creare runbook grafici di PowerShell e Python.

È possibile usare runbook per un'ampia gamma di attività di automazione, ad esempio la gestione delle risorse, l'avvio e l'arresto delle macchine virtuali e la gestione delle attività di manutenzione sia all'interno di Azure che all'esterno di Azure. Per altre informazioni, vedere panoramica dell'autenticazione dell'account Automazione di Azure e Runbook in Automazione di Azure.

Nella tabella seguente vengono descritti i tipi di runbook supportati.

Usare i webhook per soddisfare le richieste e garantire il recapito continuo e le operazioni attivando l'automazione tramite App per la logica di Azure, Funzioni di Azure, prodotti o servizi di gestione dei servizi IT, DevOps o sistemi di monitoraggio.

Azure Arc rappresenta un significativo progresso nel cloud computing e offre una piattaforma di gestione unificata che estende le funzionalità di Azure agli ambienti locali, multicloud e perimetrali. Azure Arc si integra con il servizio Automazione di Azure tramite il framework di estensione della macchina virtuale per distribuire il ruolo di lavoro ibrido per runbook e semplificare l'onboarding nelle funzionalità di gestione degli aggiornamenti, rilevamento modifiche e inventario.

Per altre informazioni, vedere Connettere un server Linux esistente ad Azure Arc.

Modelli di Gestione risorse di Azure

IaC tramite modelli di Resource Manager offre un metodo dichiarativo coerente per distribuire e gestire le risorse di Azure. Usare i modelli di Resource Manager per definire l'infrastruttura necessaria per le applicazioni in un formato JSON. I modelli arm sono idempotenti, il che significa che è possibile distribuire lo stesso modello più volte e ottenere gli stessi tipi di risorse nello stesso stato.

Per altre informazioni, vedere la documentazione del modello di Resource Manager.

Esempio di JSON

{ 

  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#", 
  "contentVersion": "1.0.0.0", 
  "parameters": { 
    "location": { 
      "type": "string", 
      "defaultValue": "[resourceGroup().location]" 
    }, 
    "storageAccountName": { 
      "type": "string", 
      "defaultValue": "[format('toylaunch{0}', uniqueString(resourceGroup().id))]" 
    } 
  }, 
  "resources": [ 
    { 
      "type": "Microsoft.Storage/storageAccounts", 
      "apiVersion": "2021-06-01", 
      "name": "[parameters('storageAccountName')]", 
      "location": "[parameters('location')]", 
      "sku": { 
        "name": "Standard_LRS" 
      }, 
      "kind": "StorageV2", 
      "properties": { 
        "accessTier": "Hot" 
      } 
    } 
  ] 
}  

È possibile usare il linguaggio specifico del dominio Bicep per ridurre la complessità della sintassi JSON e ridurre al minimo la curva di apprendimento per gli utenti che non hanno familiarità con Azure. Bicep è un'astrazione trasparente rispetto a un modello di Resource Manager che usa JSON e Bicep mantiene le funzionalità del modello JSON. Durante la distribuzione, l'interfaccia della riga di comando Bicep converte un file Bicep in un modello di Resource Manager che usa JSON.

Gli esempi in questa sezione illustrano la differenza tra un file Bicep e il modello JSON equivalente. Entrambi gli esempi distribuiscono un account di archiviazione.

Esempio bicep

param location string = resourceGroup().location 
param storageAccountName string = 'toylaunch${uniqueString(resourceGroup().id)}' 
 

resource storageAccount 'Microsoft.Storage/storageAccounts@2021-06-01' = { 
  name: storageAccountName 
  location: location 
  sku: { 
    name: 'Standard_LRS' 
  } 
  kind: 'StorageV2' 
  properties: { 
    accessTier: 'Hot' 
  } 
} 

Azure DevOps

Azure DevOps è un set completo di strumenti di sviluppo che forniscono servizi di gestione dei progetti, integrazione continua e recapito continuo (CI/CD) e repository di codice sorgente per ambienti cloud e locali. È possibile combinare queste funzionalità con i piani di test di Azure, Azure Artifacts, App per la logica e Funzioni di Azure per facilitare la collaborazione, lo sviluppo e la distribuzione di progetti software moderni.

Azure Boards

Azure Boards supporta metodologie Agile per lo sviluppo di software cloud e la gestione dei progetti. Per altre informazioni, vedere la documentazione di Azure Boards e Configurare e personalizzare Azure Boards.

Per sfruttare al meglio Azure Boards, comprendere in che modo i team usano gli strumenti e le funzioni, ad esempio Scrum, Kanban e Scrumban e le relative dipendenze da configurazioni e personalizzazioni.

La tabella seguente riepiloga gli elementi principali da considerare quando si struttura il progetto.

Azure Pipelines

Azure Pipelines offre un modo rapido, semplice e sicuro per automatizzare le compilazioni del progetto con codice coerente e qualitativo disponibile.

Azure Pipelines:

• Funziona con qualsiasi linguaggio o piattaforma.
• Esegue la distribuzione in diversi tipi di destinazioni contemporaneamente.
• Si integra con le distribuzioni di Azure.
• Si basa su computer Windows, Linux o Mac.
• Si integra con GitHub.
• Funziona con progetti open source.

Per altre informazioni, vedere la documentazione di Azure Pipelines.

A seconda delle esigenze dell'organizzazione, è possibile scegliere una delle quattro architetture principali per Azure Pipelines:

• Architettura di base di Azure Pipelines
• Architettura di Azure Pipelines per la funzionalità di App Web del servizio app Azure
• Architettura di Azure Pipelines con Azure DevTest Labs
• Architettura di Azure Pipelines per l'infrastruttura distribuita come servizio

Azure Repos

Azure Repos offre due tipi di controllo della versione, il controllo della versione Git e il controllo della versione centralizzato.

Per accedere al codice, connettere l'ambiente di sviluppo ad Azure Repos. Condividere il codice tramite:

• Riga di comando.
• Visual Studio Code.
• Xcode.
• Eclipse.
• IntelliJ.

Per altre informazioni, vedere la documentazione di Git di Azure Repos e controllo della versione di Team Foundation documentazione.

Usare le pipeline di versione e le origini di Azure Artifacts

Gli sviluppatori possono usare Azure Artifacts per pubblicare e usare vari tipi di pacchetti da feed e registri pubblici, ad esempio PyPI, Maven Central e NuGet.org. È possibile usare Azure Artifacts con Azure Pipelines per pubblicare artefatti di compilazione e pipeline, distribuire pacchetti o integrare file in varie fasi della pipeline per compilare, testare o distribuire l'applicazione.

Per altre informazioni, vedi:

• Azure Artifacts in Azure Pipelines.
• Pipeline di versione e origini di Azure Artifact.
• Introduzione alle autorizzazioni e all'accesso.

Integrare Criteri di Azure con Azure DevOps

Criteri di Azure si applica direttamente alle risorse all'interno degli ambienti Azure, ma i principi e la governance possono influenzare indirettamente le procedure di Azure DevOps. Ad esempio, Criteri di Azure può influire:

• Conformità nelle pipeline CI/CD: è possibile integrare i controlli di conformità nelle pipeline. Ad esempio, assicurarsi che qualsiasi infrastruttura distribuita tramite Azure DevOps sia conforme ai criteri definiti in Criteri di Azure.

• Coerenza dell'ambiente: usare Criteri di Azure per applicare configurazioni o tipi di risorse specifici per assicurarsi che gli ambienti distribuiti in tramite Azure DevOps siano coerenti e conformi.

• Sicurezza e governance: i criteri possono applicare gli standard di sicurezza e le procedure di governance sulle risorse gestite da Azure DevOps Projects. Questa normativa garantisce che il ciclo di vita dello sviluppo includa la conformità agli standard organizzativi e normativi.

Per integrare in modo efficace Criteri di Azure con Azure DevOps, è possibile usare Criteri di Azure funzionalità di conformità e controllo per informare le procedure DevOps. Apportare modifiche alle pipeline o alle definizioni IaC per allinearsi ai criteri dell'organizzazione applicati tramite Criteri di Azure.

Questa integrazione garantisce che le risorse distribuite e gestite tramite Azure DevOps siano sempre conformi agli standard di governance dell'azienda. Usare questo approccio per migliorare la sicurezza, la coerenza e la gestione dei costi in ambienti Azure.

Passaggi successivi

• Installare Azure PowerShell in Linux
• Usare Azure PowerShell in un contenitore Docker
• Documentazione di Azure PowerShell
• Installare l'interfaccia della riga di comando di Azure in Linux
• Eseguire l'interfaccia della riga di comando di Azure in un contenitore Docker
• Documentazione dell'interfaccia della riga di comando di Azure