<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
    <channel>
        <title>LaraDep - Unser Blog</title>
        <link>https://www.laradep.com/de/blog</link>
        <description>Lesen Sie die neuesten Nachrichten und Updates</description>
        <language>de</language>
        <lastBuildDate>Wed, 20 May 2026 23:15:40 +0000</lastBuildDate>
        <atom:link href="https://www.laradep.com/de/feed.xml" rel="self" type="application/rss+xml"/>

                    <item>
                <title><![CDATA[Wie Workspace-Isolation in LaraDep mein Multi-Client-Management verändert hat]]></title>
                <link>https://www.laradep.com/de/blog/workspace-isolation-mehrere-kunden</link>
                <guid isPermaLink="true">https://www.laradep.com/de/blog/workspace-isolation-mehrere-kunden</guid>
                <pubDate>Wed, 04 Mar 2026 09:30:00 +0000</pubDate>

                                    <description><![CDATA[Mehrere Kunden in einem Ansible-Setup ohne klare Trennung zu verwalten, ist wie alle Schlüssel an einem Ring ohne Beschriftung zu tragen. Hier erkläre ich, wie das Worksp]]></description>
                
                                    <content:encoded><![CDATA[Der Zustand vor der Workspace-IsolationBevor ich das Workspace-Modell in LaraDep einbaute, sah ein Multi-Client-Setup so aus: ein Git-Repository, ein Ansible-Vault für alle Secrets, nach Kunden benannte Ordner und eine ungeschriebene Team-Vereinbarung „fass nicht an, was nicht deins ist". Funktioniert das? Technisch ja. Sicher? Absolut nicht.Umgebungen zu verwechseln ist in einem solchen Setup eine Frage der Unaufmerksamkeit, nicht der bösen Absicht. Man wechselt in den falschen Ordner im Terminal, startet einen Run gegen Produktion statt Staging, und das Ergebnis sagt einem, was passiert ist. Mit Glück ist es nur verlorene Zeit. Ohne Glück ist es ein Vorfall.Was Workspace-Isolation in der Praxis bedeutetIn LaraDep ist ein Workspace ein Datenkontext, der physisch trennt:Server und ihre Gruppen von anderen Workspaces.Ansible-Variablen und den Secret-Store von anderen Workspaces.Run-Historie und Audit-Einträge nach Workspace-Kontext.Berechtigungen — wer was in einem bestimmten Workspace tun kann.Den Workspace zu wechseln bedeutet nicht nur einen anderen Browser-Tab. Es bedeutet, dass man versehentlich nichts im falschen Kontext anzeigen oder ausführen kann, weil das System es nicht erlaubt. Das ist kein „wir hoffen, dass Sie es bemerken". Das ist eine strukturelle Einschränkung.Ein konkreter Fall: AgenturbetriebFür Agenturen ist das Workspace-Modell wahrscheinlich der größte Mehrwert von LaraDep. Jeder Kunde bekommt einen eigenen Workspace. Das Onboarding eines neuen Projekts bedeutet, einen Workspace zu erstellen, Server hinzuzufügen, Variablen zu konfigurieren und Berechtigungen zuzuweisen. Das ist ein expliziter Akt — kein „gib Jan Zugriff auf den Ordner".Run-Audits funktionieren nach Workspace-Kontext. Wenn ein Kunde fragt „was haben Sie letzten Monat bei uns gemacht", ist die Antwort ein paar Klicks entfernt, keine Stunde des Wühlens in der Git-Historie.Wo das Workspace-Modell nicht ausreichtWorkspace-Isolation ist eine Governance-Schicht, kein Ersatz für gute Template Composition oder Runbook-Disziplin. Wenn das Playbook das Falsche tut, fängt der Workspace das nicht ab. Jede Schutzschicht löst ein anderes Problem, und das Workspace-Modell löst genau und nur: Kontext- und Zugriffstrennung.Für ein vollständiges Betriebsmodell braucht man Workspace-Isolation zusammen mit Preflight, Templates und Audit-Historie. Jede Schicht hilft allein weniger als alle zusammen.Nächster Schritt: Vollständiger Kontext steht in der Dokumentation und im Vergleich.]]></content:encoded>
                
                                    <category><![CDATA[Sicherheit]]></category>
                
                
                            </item>
                    <item>
                <title><![CDATA[MCP + Ansible: was mich überraschte und was wirklich funktioniert]]></title>
                <link>https://www.laradep.com/de/blog/mcp-ansible-was-mich-ueberraschte-und-was-funktioniert</link>
                <guid isPermaLink="true">https://www.laradep.com/de/blog/mcp-ansible-was-mich-ueberraschte-und-was-funktioniert</guid>
                <pubDate>Wed, 11 Feb 2026 10:00:00 +0000</pubDate>

                                    <description><![CDATA[Ich baute MCP in LaraDep mit geringen Erwartungen ein. Schnelle Abfragen über Logs und Metadaten erwiesen sich als nützlicher als erwartet. Hier ist eine ehrliche Einschä]]></description>
                
                                    <content:encoded><![CDATA[Wie MCP zu LaraDep kamIch bemerkte das Model Context Protocol, als Anthropic die Spezifikation veröffentlichte. Erste Reaktion: interessantes Protokoll, aber für den Ansible-Betrieb eher ein Spielzeug als ein Werkzeug. Ich versuchte es trotzdem — denn der beste Weg, eine Hypothese zu testen, ist sie umzusetzen und zu sehen, was passiert.Das Ergebnis überraschte mich. Nicht weil es revolutionär war, sondern wegen der konkreten Stellen, wo es tatsächlich Zeit spart, und der Bereiche, wo es eine nette Demo ohne realen Betriebseffekt bleibt.Was MCP in LaraDep verfügbar machtDer MCP-Server in LaraDep gibt Daten über standardisierte Werkzeuge frei. Ein KI-Assistent kann abfragen:Eine Liste der letzten Runs mit Ergebnissen und Zeitstempeln.Details eines bestimmten Runs nach UUID — Eingaben, Ausgaben, Preflight-Status.Einen Run-Log-Stream zur Fehleranalyse.Server- und Gruppenlisten mit ihren Metadaten.Informationen darüber, welche Passwörter und Tokens im System vorhanden sind und wann sie zuletzt geändert wurden.Was MCP niemals zurückgibt: die Werte von Passwörtern und Tokens. Das ist keine konfigurierbare Einstellung — es ist eine fest einprogrammierte Eigenschaft des Systems.Wo MCP wirklich Zeit spartDer wertvollste Anwendungsfall ist die Fehlersuche nach einem Vorfall. Anstatt ins Admin-Panel zu gehen, den Run zu suchen, das Log zu öffnen, bis zum Fehler zu scrollen und das Geschehene mental zu rekonstruieren, frage ich einfach: „Geh durch das Run-Log für [UUID], finde den ersten Fehler und fasse den Kontext zusammen." Die Antwort kommt in Sekunden. Das spart 5–10 Minuten pro Incident-Review.Der zweite Anwendungsfall ist eine schnelle Infrastruktur-Statusabfrage: „Welche Server befinden sich in der Gruppe web-production, und wann lief der letzte erfolgreiche Run?" Früher klickte ich mich durch das Admin-Interface; jetzt ist es eine einzige Frage.Wo MCP nicht hilftMCP hilft nicht, wenn man eine Änderung vornehmen muss. Es ist ein rein schreibgeschütztes Werkzeug zum Lesen von Zustand und Daten. Über MCP können keine Runs gestartet, keine Konfigurationen geändert und keine Einträge gelöscht werden — das ist so gewollt. Der KI-Assistent ist ein analytisches Werkzeug, kein Operator.Es hilft auch nicht, wenn das Betriebsproblem im Playbook selbst oder in der Template-Logik liegt. Dafür braucht man Betriebswissen und Code-Review, keine KI über Metadaten.Meine EmpfehlungWenn man Ansible-Betrieb verwaltet und Claude, Cursor oder Windsurf nutzt, lohnt es sich, MCP auszuprobieren. Es ist kein Game-Changer, aber ein solides Ergänzungswerkzeug zum bestehenden Workflow. Besonders für Incident-Response und schnelle Statusabfragen ist der Nutzen klar.Nächster Schritt: Vollständiger Kontext steht in der Dokumentation und im Vergleich.]]></content:encoded>
                
                                    <category><![CDATA[MCP / AI]]></category>
                                    <category><![CDATA[Automatisierung]]></category>
                
                
                            </item>
                    <item>
                <title><![CDATA[Warum Preflight mehr als eine Statusanzeige ist: einen Run stoppen, bevor er Schaden anrichtet]]></title>
                <link>https://www.laradep.com/de/blog/warum-preflight-mehr-als-eine-statusanzeige-ist</link>
                <guid isPermaLink="true">https://www.laradep.com/de/blog/warum-preflight-mehr-als-eine-statusanzeige-ist</guid>
                <pubDate>Wed, 21 Jan 2026 09:00:00 +0000</pubDate>

                                    <description><![CDATA[Preflight behandelte ich ursprünglich als Formalität. Dann kam ein Run, der fehlerfrei durchlief und trotzdem Probleme verursachte, weil wir nicht die richtigen Fragen st]]></description>
                
                                    <content:encoded><![CDATA[Als mir klar wurde, dass ich Preflight falsch angingLange dachte ich, Preflight bedeute „prüfen, ob der Server erreichbar und Ansible installiert ist". Technisch funktioniert das, aber praktisch reicht es nicht aus. Ein Run, den man gegen den falschen Server oder mit einer ungültigen Variable auslöst, besteht diese Art von Preflight und richtet dann genau den Schaden an, den man vermeiden wollte.Der Wendepunkt war ein konkreter Vorfall: ein Staging-Run mit DB_HOST versehentlich auf einen Produktionswert gesetzt, der aus einem anderen Workspace kopiert worden war. Preflight meldete nichts, weil der Server erreichbar war. Der Run lief durch. Die Produktionsdatenbank erhielt inkonsistente Daten.Was echtes Preflight abdecken mussNach diesem Vorfall schrieb ich neu, was Preflight in LaraDep bedeutet. Technische Erreichbarkeit reicht nicht — man muss den Kontext des Runs überprüfen. Vier Dinge haben mir seitdem mehr Stress erspart, als ich erwartet hatte:Korrektheit des Targets: Ist das wirklich der Server oder die Gruppe, die ich ändern will? Kein versehentlicher Staging/Produktions-Tausch.Vollständigkeit der Eingaben: Sind alle Pflichtfelder mit sinnvollen Werten befüllt?Konfigurationskonsistenz: Befinden sich die Abhängigkeiten, auf die das Template setzt, im erwarteten Zustand?Berechtigungsprüfung: Hat der angemeldete Benutzer das Recht, diese Änderung in diesem Workspace auszuführen?Wie das in der Praxis aussiehtPreflight in LaraDep ist ein Gate, kein Statuslicht. Wenn eine Bedingung nicht stimmt, startet der Run nicht, und man bekommt eine konkrete Beschreibung, was fehlt. Das ist keine höfliche Warnung — das ist ein hartes Stopp. Anfangs hat mich das ein wenig geärgert. Dann erinnerte ich mich an diesen Vorfall und begann es zu schätzen.Für Teams, in denen mehrere Personen Änderungen auslösen, ist das besonders wichtig. Ein erfahrener Operator führt mental selbst ein Preflight durch. Ein Junior oder ein neuer Kollege tut das nicht — und das Gate ist das, was sie vor ehrlichen Fehlern schützt.Was Preflight nicht lösen wirdPreflight fängt keine logischen Fehler im Playbook selbst ab. Wenn das Template das Falsche korrekt tut, sagt Preflight einem das nicht. Deshalb müssen gute Template Composition und Workflow-Disziplin neben Preflight existieren, nicht statt ihm. Jede Schicht löst ein anderes Problem.Nächster Schritt: Vollständiger Kontext steht in der Dokumentation und im Vergleich.]]></content:encoded>
                
                
                
                            </item>
            </channel>
</rss>
