AI-ARC · Percorso 4: Costruire e gestire
Azure Arc e Azure Local come Hybrid Control Plane
Tre giorni dopo i quali Arc non è più solo un agent sui Suoi server, ma una control plane con regole che ha fissato Lei.
- Durata
- 3 giorni
- Gruppo
- da 4 a 12 persone
- Formato
- Inhouse · Da remoto · Nel lab
- Lingua
- Tedesco o inglese
- Preavviso
- da 4 settimane
- Prezzo
- 23.700 € forfettario, IVA esclusa
Erogazione a partire da quattro partecipanti effettivamente iscritti. La data viene confermata per iscritto dopo aver concordato contenuti, prerequisiti e disponibilità.
Per chi è questo track
Team di piattaforma che gestiscono o introducono Azure Local e vogliono impostare in modo pulito la gestione via Azure Arc invece di ereditarla. Anche per team davanti alla decisione di fondo tra esercizio connesso e separato, che per questa hanno bisogno di fatti invece di sensazioni.
Per chi no
Non per team senza alcun contatto con Azure, che hanno prima bisogno di una prospettiva di piattaforma complessiva. Loro partono nel Sovereign AI Platform Engineering (AI-PLATFORM).
Situazione di partenza
Azure Local è nel rack o sulla lista degli acquisti e con lui arriva Azure Arc come livello di gestione. Nel team non è chiaro quali risorse vengano proiettate in Azure e come, quali policy dovrebbero valere fin dall’inizio e cosa significhi davvero l’esercizio Connected in termini di flussi di dati. Intanto Disconnected Operations aleggia nella discussione senza che nessuno abbia verificato i requisiti di accesso.
Questo esiste dopo il track
- Un modello di risorse Arc per la Sua organizzazione: management group, subscription, gruppi di risorse, tag e taglio RBAC, documentato come diagramma
- Una base di policy con le dieci regole più importanti per partire, versionata come codice
- Una catena GitOps funzionante nel Lab: modifica di configurazione via pull request invece che a mano
- Un quadro decisionale Connected contro Disconnected con catalogo di criteri, panoramica dei flussi di dati e inquadramento onesto dell’Eligibility
- Una raccomandazione documentata per il modello di esercizio della Sua organizzazione con i punti di verifica aperti
Prerequisiti
Conoscenze di base dei concetti Azure come subscription, gruppi di risorse e RBAC ed esperienza di esercizio con server o Kubernetes. La pratica con Azure Local aiuta, ma viene fornita nel Lab.
Preparazione prima del track
Risponde in anticipo a dieci domande sulla Sua situazione di partenza: uso attuale di Azure, numero e sedi dei sistemi, vincoli regolatori e il motivo per cui Disconnected è in discussione. Da qui nasce la base dei casi per il Giorno 3.
Contenuto della fornitura
- 3 giornate di formazione, tenute da Dino Bordonaro
- Accesso al Lab con istanze Azure Local e area tenant Azure propria per ogni team
- Modelli di policy e GitOps come repository versionati da riutilizzare
- Catalogo di criteri Connected contro Disconnected come modello decisionale
- Certificati di partecipazione e documentazione formativa verificabile in sede di audit
- Follow-up di 60 minuti con il team 4 settimane dopo il corso
Agenda
Giorno 1
Cosa proietta davvero Arc
Il modello di risorse Arc dall’interno: server, Kubernetes, servizi dati e Azure Local come risorse proiettate. Quali dati fluiscono in quale direzione e cosa resta locale? Chiarimento sul diagramma dei flussi di dati, non sull’immagine di marketing.
Topologia delle risorse per la Sua organizzazione
Management group, subscription, gruppi di risorse, tag e RBAC: esercizio sul proprio caso. Decisione concreta: dove separa la produzione dal test e chi può fare cosa a livello Arc?
Onboarding nel Lab
Ogni team collega ad Arc istanze Azure Local e altri sistemi, nella versione di volta in volta disponibile. Nel farlo si protocolla quali endpoint, account e permessi l’onboarding richieda davvero.
Mettere a punto l’RBAC
Taglio dei ruoli nella pratica: team di esercizio, team di sicurezza, auditor. Test con tre identità per vedere se i confini tengono. Chi vede troppo o può troppo viene corretto.
Risultato della giornata: modello di risorse documentato
Ogni team ha fatto l’onboarding dei propri sistemi in Arc e documentato un modello di risorse con taglio RBAC come diagramma, verificato con accessi di test reali.
Giorno 2
La policy come guardrail, non come freno
Azure Policy su risorse Arc: audit contro deny, iniziative, eccezioni con data di scadenza. Esercizio di selezione: quali dieci policy appartengono al Suo set di partenza e quale unica tra loro sta su deny?
Posare la base GitOps
Configurazione come codice con Flux su Kubernetes Arc-enabled: struttura dei repository, separazione degli ambienti, vie di approvazione. La questione di fondo viene decisa: cosa non deve mai più essere cambiato dal portale?
Esercizio: modifica via pull request
Ogni team modifica una configurazione di workload esclusivamente tramite una pull request e osserva la consegna attraverso la catena GitOps. Poi la controprova: una modifica manuale al sistema viene riconosciuta come drift e riportata indietro.
Azure Local sotto Arc nel quotidiano
Update, monitoring e vista di capacità su Azure Local attraverso il livello Arc, nella versione di volta in volta disponibile. Bilancio onesto: cosa la control plane copre bene oggi e dove restano necessari strumenti locali.
Risultato della giornata: catena di policy e GitOps in funzione
Ogni team ha assegnato dieci policy, consegnato una modifica via pull request e riconosciuto e corretto in modo dimostrabile un drift di configurazione. Repository e definizioni delle policy vanno via con il team come artefatti.
Giorno 3
Connected e Disconnected senza ideologia
I due modelli di esercizio nel confronto sobrio: flussi di dati, vie di update, perimetro funzionale, onere di esercizio. Azure Local Disconnected Operations viene inquadrato con onestà: ad accesso limitato, con verifica di Eligibility, non ordinabile liberamente, perimetro funzionale nella versione di volta in volta disponibile.
Il catalogo di criteri
Elaborazione di una griglia decisionale: vincoli regolatori, requisiti di latenza e autonomia, personale, supportabilità, costi. Ogni criterio riceve una pesatura e una domanda di verifica misurabile.
Lavoro sul caso: la Sua organizzazione nel quadro decisionale
Ogni team applica il catalogo alla propria situazione di partenza dalla preparazione ed elabora una raccomandazione: Connected, avviare la verifica Disconnected o modello misto. La raccomandazione viene difesa davanti al gruppo.
La realtà dell’Eligibility e il piano B
Percorso reale verso Disconnected Operations: requisiti, processo di verifica, orizzonte temporale. Per ogni team viene fissato un piano B nel caso la verifica fallisca o duri troppo.
Risultato della giornata: raccomandazione motivata sul modello di esercizio
Ogni team ha un quadro decisionale documentato con catalogo di criteri pesato, una raccomandazione per la propria organizzazione e una lista dei punti di verifica aperti con i responsabili.
Esercitazioni e quota lab
Circa metà del tempo è lavoro pratico: onboarding Arc di sistemi reali, test RBAC con più identità, assegnazioni di policy e una catena GitOps completa con drift di configurazione provocato, tutto su istanze Azure Local del nostro Lab.
Piattaforme
Svolgimento sul nostro ambiente Lab con Azure Local e un’area tenant Azure propria per ogni team, su richiesta nel Suo tenant, purché i permessi siano disponibili. Tutte le funzioni Arc e Azure Local valgono nella versione di volta in volta disponibile, trattiamo Disconnected Operations come offerta ad accesso limitato con verifica di Eligibility. BORDONARO è un partner indipendente, non una filiale Microsoft.
Prova di transfer
Tre prove documentate: il modello di risorse con test RBAC superati, la catena GitOps con drift riconosciuto e la raccomandazione sul modello di esercizio difesa davanti al gruppo. Tutto viene consegnato come parte della documentazione formativa.
Artefatti che porta con sé
- Modello di risorse Arc con taglio RBAC come diagramma e descrizione
- Set di partenza delle policy come definizioni versionate
- Modello di repository GitOps con separazione degli ambienti
- Catalogo di criteri Connected contro Disconnected con pesatura
- Raccomandazione sul modello di esercizio per la propria organizzazione con punti di verifica aperti
Estensioni opzionali
- LLMOps per ambienti connessi, separati e Air-Gap (AI-OPS) per l’esercizio nel modello separato
- Sovereign AI Platform Engineering (AI-PLATFORM) per la costruzione completa della piattaforma
- Accompagnamento della Sua verifica di Eligibility Disconnected come servizio separato
Delimitazione
Il corso produce un quadro decisionale e pattern di gestione provati, non un ambiente già migrato. La realizzazione del modello di risorse nel Suo tenant e un’eventuale richiesta Disconnected sono prestazioni di progetto e vengono incaricate separatamente.
Domande frequenti
Potete semplicemente portarci Disconnected Operations?
No, e nessuno può farlo seriamente. Azure Local Disconnected Operations è ad accesso limitato, Microsoft verifica l’Eligibility per ogni cliente. Il corso La rende capace di decidere e di presentare la richiesta: dopo saprà se il percorso conviene per Lei e qual è il piano B.
Il corso funziona anche da remoto?
Sì, l’ambiente Lab è completamente raggiungibile da remoto e le esercitazioni sono pensate per questo. Per il lavoro sul caso del Giorno 3 consigliamo comunque la presenza, perché la discussione sul modello di esercizio guadagna dalla lavagna condivisa. Entrambe le opzioni sono prenotabili.
Finora usiamo poco Azure. Il corso è prematuro?
Se Azure Local è deciso o nella rosa ristretta no, anzi è proprio il momento giusto, perché il modello di risorse lo progetta ancora partendo da un foglio bianco. Se la base Azure manca del tutto, chiariamo nel colloquio preliminare se convenga una giornata di fondamenti preliminare.