AI-ARC · Pfad 4: Bauen und betreiben
Azure Arc und Azure Local als Hybrid-Control-Plane
Drei Tage, nach denen Arc nicht mehr nur ein Agent auf Ihren Servern ist, sondern eine Control-Plane mit Regeln, die Sie selbst gesetzt haben.
- Dauer
- 3 Tage
- Gruppe
- bis 12 Personen
- Format
- Inhouse · Remote · Im Lab
- Sprache
- Deutsch oder Englisch
- Preis
- 23.700 € pauschal, zzgl. MwSt.
Für wen dieser Track ist
Plattform-Teams, die Azure Local betreiben oder einführen und die Verwaltung über Azure Arc sauber aufsetzen wollen, statt sie zu erben. Auch für Teams, die vor der Grundsatzentscheidung zwischen verbundenem und getrenntem Betrieb stehen und dafür Fakten statt Bauchgefühl brauchen.
Für wen nicht
Nicht für Teams ohne Azure-Berührung, die zuerst eine Gesamtplattform-Perspektive brauchen. Die starten im Sovereign AI Platform Engineering (AI-PLATFORM).
Ausgangssituation
Azure Local steht im Rack oder auf der Beschaffungsliste, und mit ihm kommt Azure Arc als Verwaltungsebene. Im Team ist unklar, welche Ressourcen wie in Azure projiziert werden, welche Policies von Anfang an gelten sollten und was der Connected-Betrieb an Datenflüssen wirklich bedeutet. Gleichzeitig geistert Disconnected Operations durch die Diskussion, ohne dass jemand die Zugangsvoraussetzungen geprüft hat.
Das existiert nach dem Track
- Ein Arc-Ressourcenmodell für Ihr Haus: Management-Groups, Subscriptions, Ressourcengruppen, Tags und RBAC-Zuschnitt, als Diagramm dokumentiert
- Eine Policy-Grundlage mit den zehn wichtigsten Regeln für den Start, als Code versioniert
- Eine funktionierende GitOps-Kette im Lab: Konfigurationsänderung per Pull-Request statt per Handarbeit
- Ein Entscheidungsbild Connected gegen Disconnected mit Kriterienkatalog, Datenfluss-Übersicht und ehrlicher Eligibility-Einordnung
- Eine dokumentierte Empfehlung für das Betriebsmodell Ihres Hauses mit den offenen Prüfpunkten
Voraussetzungen
Grundkenntnisse in Azure-Konzepten wie Subscriptions, Ressourcengruppen und RBAC sowie Betriebserfahrung mit Servern oder Kubernetes. Azure-Local-Praxis ist hilfreich, wird aber im Lab gestellt.
Vorarbeit vor dem Track
Sie beantworten vorab zehn Fragen zu Ihrer Ausgangslage: vorhandene Azure-Nutzung, Anzahl und Standorte der Systeme, regulatorische Auflagen und der Grund, aus dem Disconnected überhaupt diskutiert wird. Daraus entsteht die Fallgrundlage für Tag 3.
Lieferumfang
- 3 Trainingstage, gehalten von Dino Bordonaro
- Lab-Zugang mit Azure-Local-Instanzen und eigenem Azure-Tenant-Bereich je Team
- Policy- und GitOps-Vorlagen als versionierte Repositories zur Weiterverwendung
- Kriterienkatalog Connected gegen Disconnected als Entscheidungsvorlage
- Teilnahmezertifikate und revisionssichere Schulungsdokumentation
- 60-minütiges Follow-up mit dem Team 4 Wochen nach dem Kurs
Agenda
Tag 1
Was Arc wirklich projiziert
Das Arc-Ressourcenmodell von innen: Server, Kubernetes, Datenservices und Azure Local als projizierte Ressourcen. Welche Daten fließen dabei in welche Richtung, und was bleibt lokal? Klärung am Datenfluss-Diagramm, nicht am Marketing-Bild.
Ressourcen-Topologie für Ihr Haus
Management-Groups, Subscriptions, Ressourcengruppen, Tags und RBAC: Übung am eigenen Fall. Konkrete Entscheidung: Wo trennen Sie Produktion von Test, und wer darf auf Arc-Ebene was?
Onboarding im Lab
Jedes Team verbindet Azure-Local-Instanzen und weitere Systeme mit Arc, in der jeweils verfügbaren Version. Dabei wird protokolliert, welche Endpunkte, Konten und Berechtigungen das Onboarding tatsächlich verlangt.
RBAC scharf stellen
Rollenzuschnitt in der Praxis: Betriebsteam, Sicherheitsteam, Auditor. Test mit drei Identitäten, ob die Grenzen halten. Wer zu viel sieht oder zu viel darf, wird nachjustiert.
Tagesergebnis: dokumentiertes Ressourcenmodell
Jedes Team hat seine Systeme in Arc onboarded und ein Ressourcenmodell mit RBAC-Zuschnitt als Diagramm dokumentiert, geprüft mit echten Testzugriffen.
Tag 2
Policy als Leitplanke, nicht als Bremse
Azure Policy auf Arc-Ressourcen: Audit gegen Deny, Initiativen, Ausnahmen mit Ablaufdatum. Auswahlübung: Welche zehn Policies gehören in Ihre Startmenge, und welche einzige davon steht auf Deny?
GitOps-Grundlage legen
Konfiguration als Code mit Flux auf Arc-enabled Kubernetes: Repository-Struktur, Umgebungs-Trennung, Freigabewege. Die Grundsatzfrage wird entschieden: Was darf nie wieder per Portal geändert werden?
Übung: Änderung per Pull-Request
Jedes Team ändert eine Workload-Konfiguration ausschließlich über einen Pull-Request und beobachtet die Auslieferung durch die GitOps-Kette. Danach die Gegenprobe: eine manuelle Änderung am System wird als Drift erkannt und zurückgerollt.
Azure Local unter Arc im Alltag
Updates, Monitoring und Kapazitätssicht auf Azure Local über die Arc-Ebene, in der jeweils verfügbaren Version. Ehrliche Bilanz: was die Control-Plane heute gut abdeckt und wo weiterhin lokale Werkzeuge nötig sind.
Tagesergebnis: laufende Policy- und GitOps-Kette
Jedes Team hat zehn Policies zugewiesen, eine Änderung per Pull-Request ausgeliefert und einen Konfigurationsdrift nachweislich erkannt und korrigiert. Repositories und Policy-Definitionen gehen als Artefakte mit.
Tag 3
Connected und Disconnected ohne Ideologie
Die beiden Betriebsmodelle im nüchternen Vergleich: Datenflüsse, Update-Wege, Funktionsumfang, Betriebsaufwand. Azure Local Disconnected Operations wird ehrlich eingeordnet: zugangsbeschränkt, mit Eligibility-Prüfung, nicht frei bestellbar, Funktionsumfang in der jeweils verfügbaren Version.
Der Kriterienkatalog
Erarbeitung eines Entscheidungsrasters: regulatorische Auflagen, Latenz- und Autonomie-Anforderungen, Personal, Supportfähigkeit, Kosten. Jedes Kriterium bekommt eine Gewichtung und eine messbare Prüffrage.
Fallarbeit: Ihr Haus im Entscheidungsbild
Jedes Team wendet den Katalog auf die eigene Ausgangslage aus der Vorarbeit an und erarbeitet eine Empfehlung: Connected, Disconnected-Prüfung anstoßen oder Mischmodell. Die Empfehlung wird vor der Gruppe verteidigt.
Die Eligibility-Realität und der Plan B
Durchgehen des realen Wegs zu Disconnected Operations: Voraussetzungen, Prüfprozess, Zeithorizont. Für jedes Team wird ein Plan B festgehalten, falls die Prüfung scheitert oder zu lange dauert.
Tagesergebnis: begründete Betriebsmodell-Empfehlung
Jedes Team hat ein dokumentiertes Entscheidungsbild mit gewichtetem Kriterienkatalog, einer Empfehlung für das eigene Haus und einer Liste der offenen Prüfpunkte samt Verantwortlichen.
Übungen und Lab-Anteil
Rund die Hälfte der Zeit ist Handarbeit: Arc-Onboarding echter Systeme, RBAC-Tests mit mehreren Identitäten, Policy-Zuweisungen und eine vollständige GitOps-Kette mit provoziertem Konfigurationsdrift, alles auf Azure-Local-Instanzen unseres Labs.
Plattformen
Durchführung auf unserer Lab-Umgebung mit Azure Local und einem eigenen Azure-Tenant-Bereich je Team, auf Wunsch in Ihrem Tenant, sofern Berechtigungen vorliegen. Alle Arc- und Azure-Local-Funktionen gelten in der jeweils verfügbaren Version, Disconnected Operations behandeln wir als zugangsbeschränktes Angebot mit Eligibility-Prüfung. BORDONARO ist unabhängiger Partner, keine Microsoft-Niederlassung.
Transfernachweis
Drei dokumentierte Nachweise: das Ressourcenmodell mit bestandenen RBAC-Tests, die GitOps-Kette mit erkanntem Drift und die vor der Gruppe verteidigte Betriebsmodell-Empfehlung. Alles wird als Teil der Schulungsdokumentation übergeben.
Mitgenommene Artefakte
- Arc-Ressourcenmodell mit RBAC-Zuschnitt als Diagramm und Beschreibung
- Policy-Startmenge als versionierte Definitionen
- GitOps-Repository-Vorlage mit Umgebungs-Trennung
- Kriterienkatalog Connected gegen Disconnected mit Gewichtung
- Betriebsmodell-Empfehlung für das eigene Haus mit offenen Prüfpunkten
Optionale Erweiterungen
- LLMOps für verbundene, getrennte und Air-Gap-Umgebungen (AI-OPS) für den Betrieb im getrennten Modell
- Sovereign AI Platform Engineering (AI-PLATFORM) für den vollständigen Plattformaufbau
- Begleitung Ihrer Disconnected-Eligibility-Prüfung als separater Service
Abgrenzung
Der Kurs erzeugt ein Entscheidungsbild und geübte Verwaltungsmuster, keine fertig migrierte Umgebung. Die Umsetzung des Ressourcenmodells in Ihrem Tenant und eine etwaige Disconnected-Beantragung sind Projektleistungen und werden separat beauftragt.
Häufige Fragen
Können Sie uns Disconnected Operations einfach mitbringen?
Nein, und das kann niemand seriös. Azure Local Disconnected Operations ist zugangsbeschränkt, Microsoft prüft die Eligibility je Kunde. Der Kurs macht Sie entscheidungs- und antragsfähig: Sie wissen danach, ob sich der Weg für Sie lohnt und was Plan B ist.
Funktioniert der Kurs auch remote?
Ja, die Lab-Umgebung ist vollständig remote erreichbar und die Übungen sind dafür ausgelegt. Für die Fallarbeit an Tag 3 empfehlen wir trotzdem Präsenz, weil die Betriebsmodell-Diskussion vom gemeinsamen Whiteboard profitiert. Beides ist buchbar.
Wir nutzen Azure bisher kaum. Ist der Kurs verfrüht?
Wenn Azure Local gesetzt oder in der engeren Wahl ist, nein, dann ist genau jetzt der richtige Zeitpunkt, weil Sie das Ressourcenmodell noch auf der grünen Wiese entwerfen. Fehlt die Azure-Grundlage komplett, klären wir im Vorgespräch, ob ein vorgelagerter Grundlagen-Tag sinnvoll ist.