<?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 - Náš blog</title>
        <link>https://www.laradep.com/cs/blog</link>
        <description>Sledujte naše nejnovější články a novinky</description>
        <language>cs</language>
        <lastBuildDate>Wed, 20 May 2026 22:27:15 +0000</lastBuildDate>
        <atom:link href="https://www.laradep.com/cs/feed.xml" rel="self" type="application/rss+xml"/>

                    <item>
                <title><![CDATA[Jak workspace isolation v LaraDep změnil způsob, jakým řídím více klientů]]></title>
                <link>https://www.laradep.com/cs/blog/workspace-isolation-vice-klientu</link>
                <guid isPermaLink="true">https://www.laradep.com/cs/blog/workspace-isolation-vice-klientu</guid>
                <pubDate>Wed, 04 Mar 2026 09:30:00 +0000</pubDate>

                                    <description><![CDATA[Spravovat více klientů v jednom Ansible setupu bez jasného oddělení je jako mít všechny klíče na jednom kroužku bez popisků. Tady je, jak workspace model tento problém ře]]></description>
                
                                    <content:encoded><![CDATA[Stav před workspace isolationNež jsem workspace model zapracoval do LaraDep, vypadal multi-client setup takto: jeden Git repozitář, jeden Ansible vault pro všechny secrety, složky pojmenované podle klientů a nepsaná dohoda v týmu "nesahej na to, co není tvoje". Funguje to? Technicky ano. Bezpečně? Absolutně ne.Záměna prostředí je v takovém setupu otázka nepozornosti, ne zlého úmyslu. Přejdete na špatnou složku v terminálu, spustíte run na produkci místo na staging a teprve výsledek vám řekne, co se stalo. Pokud máte štěstí, je to jen ztracený čas. Pokud nemáte, je to incident.Co workspace isolation znamená v praxiV LaraDep je workspace datový kontext, který fyzicky odděluje:Servery a jejich skupiny od jiných workspace.Ansible proměnné a secret store od jiných workspace.Run historii a auditní záznamy po workspace kontextu.Oprávnění — kdo může co dělat v daném workspace.Přepnutí workspace neznamená jen jinou záložku v prohlížeči. Znamená to, že nemůžete omylem zobrazit ani spustit nic v nesprávném kontextu, protože systém vám to nedovolí. Není to "doufáme, že si všimnete". Je to strukturální omezení.Konkrétní případ: agenturní provozPro agentury je workspace model asi největší přidaná hodnota LaraDep. Každý klient dostane vlastní workspace. Onboarding nového projektu znamená vytvořit workspace, přidat servery, nastavit proměnné a přiřadit přístupová práva. Je to explicitní akt — ne „dejte Honzovi přístup k složce".Audit běhů funguje po workspace kontextu. Když se klient zeptá "co jste u nás dělali minulý měsíc", mám odpověď za pár kliknutí, ne za hodinu hledání v Git historii.Kde workspace model nestačíWorkspace isolation je governance vrstva, ne náhrada za dobrou template composition nebo runbook disciplínu. Pokud váš playbook dělá špatnou věc, workspace to nezachytí. Každá vrstva ochrany řeší jiný problém a workspace model řeší právě a jen: oddělení kontextů a přístupů.Pro kompletní provozní model potřebujete workspace isolation spolu s preflight, šablonami a auditní historií. Samostatně každá vrstva pomáhá méně, než všechny dohromady.Další krok: Kontext k článku najdete v dokumentaci a na stránce srovnání.]]></content:encoded>
                
                                    <category><![CDATA[Bezpečnost]]></category>
                
                
                            </item>
                    <item>
                <title><![CDATA[MCP + Ansible: co mě překvapilo a co opravdu funguje]]></title>
                <link>https://www.laradep.com/cs/blog/mcp-ansible-co-prekvapilo-a-co-funguje</link>
                <guid isPermaLink="true">https://www.laradep.com/cs/blog/mcp-ansible-co-prekvapilo-a-co-funguje</guid>
                <pubDate>Wed, 11 Feb 2026 10:00:00 +0000</pubDate>

                                    <description><![CDATA[MCP jsem do LaraDep přidal s nízkými očekáváními. Rychlé dotazy nad logy a metadaty se ukázaly být užitečnější, než jsem čekal. Tady je upřímný přehled.]]></description>
                
                                    <content:encoded><![CDATA[Jak MCP přišlo do LaraDepModel Context Protocol jsem zaznamenal, když Anthropic vydal specifikaci. Prvotní reakce: zajímavý protokol, ale pro Ansible provoz to bude spíš hračka než nástroj. Přesto jsem to zkusil — protože nejlepší způsob, jak ověřit hypotézu, je implementovat ji a podívat se, co se stane.Výsledek mě překvapil. Ne tím, že by to bylo revoluční, ale tím, kde to skutečně šetří čas a kde je to stále jen hezká ukázka bez reálného dopadu.Co MCP v LaraDep zpřístupňujeMCP server v LaraDep vystavuje data přes standardizované nástroje. AI asistent může přes MCP dotazovat:Přehled posledních runů s výsledky a timestampy.Detail konkrétního runu podle UUID — vstupy, výstupy, status preflight.Log stream runu pro analýzu chyby.Seznam serverů a skupin s jejich metadaty.Informace o tom, která hesla a tokeny v systému existují a kdy byly naposledy změněny.Co MCP nikdy nevrátí: hodnoty hesel a tokenů. Toto není konfigurovatelné nastavení — je to pevně zabudovaná vlastnost systému.Kde MCP skutečně šetří časNejpřínosnější případ použití je troubleshooting po incidentu. Místo abych šel do administrace, hledal run, otevíral log, scrolloval dolů na chybu a pak si to mental-modeloval, prostě se zeptám: "Projdi log běhu [UUID], identifikuj první chybu a shrň kontext." Odpověď přijde za pár sekund. Šetří to 5-10 minut na každý incident review.Druhý případ je quick review stavu infrastruktury: "Jaké servery jsou ve skupině web-production a kdy naposledy proběhl úspěšný run?" Opět — dříve jsem musel proklikat admin rozhraní, teď je to jedna otázka.Kde MCP nepomůžeMCP nepomůže, pokud potřebujete provést změnu. Je to čistě read-only nástroj pro čtení stavu a dat. Spouštět runy, měnit konfiguraci ani mazat záznamy přes MCP nelze — a to záměrně. AI asistent je analytický nástroj, ne operátor.Také nepomůže, pokud váš provozní problém spočívá v samotném playboooku nebo v logice šablon. Na to potřebujete provozní znalost a review kódu, ne AI nad metadaty.Moje doporučeníPokud řídíte Ansible provoz a používáte Claude, Cursor nebo Windsurf, vyplatí se MCP zkusit. Není to game-changer, ale je to solidní doplněk k existujícímu workflow. Zejména pro incident response a quick status queries je návratnost jasná.Další krok: Kontext k článku najdete v dokumentaci a na stránce srovnání.]]></content:encoded>
                
                                    <category><![CDATA[MCP / AI]]></category>
                                    <category><![CDATA[Automatizace]]></category>
                
                
                            </item>
                    <item>
                <title><![CDATA[Proč preflight není jen kontrolka: jak zastavit run dřív, než udělá škodu]]></title>
                <link>https://www.laradep.com/cs/blog/proc-preflight-neni-jen-kontrolka</link>
                <guid isPermaLink="true">https://www.laradep.com/cs/blog/proc-preflight-neni-jen-kontrolka</guid>
                <pubDate>Wed, 21 Jan 2026 09:00:00 +0000</pubDate>

                                    <description><![CDATA[Preflight jsem původně bral jako formalitu. Pak přišel jeden run, který prošel bez chyby a přesto způsobil problém, protože jsme se neptali na správné věci.]]></description>
                
                                    <content:encoded><![CDATA[Kdy mi došlo, že preflight dělám špatněDlouho jsem si myslel, že preflight znamená "zkontroluj, jestli je server dostupný a Ansible nainstalovaný". Technicky to sice funguje, ale prakticky to nestačí. Run, který spustíte na špatném serveru nebo s neplatnou proměnnou, projde preflightem a pak způsobí přesně ten druh škody, kterému jste se chtěli vyhnout.Zlomový okamžik byl konkrétní incident: staging run, proměnná DB_HOST nastavená na produkční hodnotu omylem překopírovanou z jiného workspace. Preflight nic neřekl, protože server byl dostupný. Run proběhl. Databáze v produkci dostala nekonzistentní data.Co skutečný preflight musí zahrnovatPo tom incidentu jsem přepsal, co preflight v LaraDep znamená. Nestačí technická dostupnost — musí se ověřit kontext runu. To jsou čtyři věci, které mi od té doby ušetřily víc stresu, než bych čekal:Správnost targetu: Je to opravdu ten server nebo skupina, kterou chci změnit? Žádná záměna staging/produkce.Kompletnost vstupů: Jsou všechny povinné proměnné vyplněné a mají smysluplné hodnoty?Konzistence konfigurace: Jsou závislosti, ze kterých template vychází, v očekávaném stavu?Ověření oprávnění: Má přihlášený uživatel právo spustit tuto změnu v tomto workspace?Jak to vypadá v praxiPreflight v LaraDep je gate, ne jen zelená kontrolka. Pokud jakákoli podmínka nesedí, run se nespustí a dostanete konkrétní popis, co chybí. Není to zdvořilé varování — je to tvrdé zastavení. A ano, zpočátku mě to trochu štvalo. Pak jsem si vzpomněl na ten incident a ocenil jsem to.Pro týmy, kde víc lidí spouští změny, je tohle obzvlášť důležité. Seniorní člen si preflight mentálně provede sám. Juniorní člen nebo nový kolega ne — a právě pro ně je gate zásadní.Co preflightem nevyřešítePreflight nezachytí logické chyby v samotném playboooku. Pokud vaše šablona dělá špatnou věc správně, preflight vám to neřekne. Proto je potřeba mít dobrou template composition a workflow disciplínu vedle preflightu, ne místo něj. Každý vrstva řeší jiný problém.Další krok: Kontext k článku najdete v dokumentaci a na stránce srovnání.]]></content:encoded>
                
                
                
                            </item>
            </channel>
</rss>
