Zkratka proConfiguration ManagementTakéSpráva konfigurace, CM, SCM (Software Configuration Management)Pokročilý
Definice
Konfigurační management je disciplína, která udržuje nastavení serverů, aplikací a jejich verzí v definovaném, zdokumentovaném a opakovatelně obnovitelném stavu. Zahrnuje evidenci konfiguračních položek, řízení změn a nástroje jako Ansible, Puppet nebo Chef, které skutečný stav systému automaticky srovnávají s popisem uloženým ve verzovacím systému.
Nezaměňujte: V IT správě znamená konfigurační management automatizaci nastavení systémů, zatímco v projektovém a inženýrském řízení (ITIL, ISO) jde o evidenci konfiguračních položek a formální schvalování změn.
Jaký problém konfigurační management řeší
Ruční nastavování serverů vede k jevu, kterému se říká snowflake server: každý stroj je originál, nikdo přesně neví, co se na něm za dva roky měnilo, a když shoří, nikdo ho neumí složit zpět. Konfigurační management tenhle stav nahrazuje popisem. Požadovaná podoba systému (balíčky, uživatelé, soubory, služby, práva) je zapsaná v souborech, které leží v Gitu a procházejí code review jako jakýkoli jiný kód.
Deklarativní popis místo posloupnosti příkazů
Většina nástrojů popisuje cílový stav, ne cestu k němu. Místo „nainstaluj balíček, pak zapiš do souboru, pak restartuj službu“ se zapíše „balíček nginx má být přítomen, soubor má mít tenhle obsah, služba má běžet“. Nástroj si sám zjistí, co už platí, a udělá jen zbylý rozdíl. Odtud plyne idempotence: druhý a stý běh nad nezměněným systémem neudělá nic. Právě idempotence umožňuje spouštět konfiguraci pravidelně a tím potlačovat konfigurační drift, tedy pomalé rozjíždění strojů kvůli ručním zásahům a ad hoc opravám.
Konfigurační položka a řízení změn
Formálnější pojetí, se kterým pracuje ITIL i normy řady ISO/IEC 20000, staví na pojmu konfigurační položka (CI): cokoli, co má vlastní identitu a verzi, od serveru přes licenci po dokumentaci. Evidence položek a jejich vzájemných vazeb žije v CMDB. Cílem není katalog pro katalog, ale schopnost odpovědět na otázku „co se rozbije, když tuhle databázi vypnu“ a doložit auditorovi, kdo změnu schválil.
Vztah k infrastruktuře jako kódu a ke kontejnerům
Infrastruktura jako kód řeší vznik zdrojů: virtuální stroje, sítě, load balancery. Konfigurační management řeší, co je uvnitř běžícího stroje. V praxi se obojí kombinuje, protože Terraform server vytvoří a Ansible ho dovybaví. U kontejnerů se těžiště přesouvá jinam: image se sestaví jednou a dál se nemění, takže konfigurace uvnitř stroje ztrácí smysl a nahrazuje ji imutabilní artefakt plus nastavení předané proměnnými prostředí. Konfigurační management ale nezmizí: Kubernetes manifesty, Helm charty a ansible playbooky pro build agenty a bastion hosty jsou tatáž disciplína v jiném kabátě.
Kde bývá bolestivé místo
Nejčastější potíž nejsou nástroje, ale tajemství. Hesla, klíče a tokeny nesmí ležet v repozitáři v čitelné podobě, takže projekt potřebuje trezor (Vault, SOPS, cloudový secret manager) hned od začátku, ne až po prvním incidentu. Druhou bolestí je testování: konfigurační kód se snadno napíše a těžko ověří, proto se vyplácí zkušební prostředí, kde se playbook spustí nanečisto dřív, než se dotkne produkce.
Praktické minimum pro malý tým
- Veškerá konfigurace v Gitu, žádná změna přímo na serveru přes SSH.
- Oddělené hodnoty pro prostředí (dev, staging, produkce), stejný popis.
- Pravidelný běh v režimu kontroly, který hlásí rozdíl oproti požadovanému stavu.
- Šifrovaná tajemství a rotace klíčů.
Příklady z praxe
Ansible playbook, který drží webový server v daném stavu
Tým spravuje pět stejných webových serverů. Místo ručního přihlašování popíše požadovaný stav v playbooku a spustí ho proti celé skupině. Pokud někdo na jednom stroji ručně smaže konfigurační soubor nginxu, další běh ho vrátí zpět a nahlásí změnu; na ostatních strojích se neudělá nic.
- hosts: web become: true tasks: - name: Nginx je nainstalovaný ansible.builtin.package: name: nginx state: present - name: Konfigurace virtuálního hostu ansible.builtin.template: src: site.conf.j2 dest: /etc/nginx/conf.d/site.conf mode: "0644" notify: restart nginx - name: Služba běží a startuje po rebootu ansible.builtin.service: name: nginx state: started enabled: true handlers: - name: restart nginx ansible.builtin.service: name: nginx state: restartedAudit odhalí drift na jednom z uzlů
Provozní tým spouští konfiguraci každou noc v režimu kontroly bez zápisu. Ráno report ukáže, že jeden aplikační server má jinou verzi OpenSSL a vypnutý firewall, protože během incidentu někdo zasahoval ručně. Rozdíl se dořeší v kódu, ne na stroji, takže oprava platí i pro budoucí nově vytvořené uzly.
ansible-playbook site.yml --check --diff --limit app
Časté omyly
- MýtusKonfigurační management je zbytečný, když všechno běží v kontejnerech.
- Ve skutečnostiKontejnery přesouvají konfiguraci do image a manifestů, ale nemažou ji. Hostitelské uzly, CI agenti, klastrové zdroje i Helm hodnoty se pořád musí verzovat a řídit stejnou disciplínou.
- MýtusStačí mít skripty v Gitu, to je to samé.
- Ve skutečnostiShell skript popisuje kroky a při druhém spuštění může nadělat škodu, protože není idempotentní. Konfigurační management popisuje cílový stav a sám dopočítá rozdíl, což ho dělá bezpečně opakovatelným.
- MýtusCMDB je jen byrokracie pro auditory.
- Ve skutečnostiEvidence konfiguračních položek a vazeb mezi nimi je hlavně nástroj pro analýzu dopadu změn a rychlé řešení incidentů. Auditní hodnota je vedlejší efekt, ne hlavní důvod.
Časté dotazy
- Jaký nástroj konfiguračního managementu zvolit pro malý tým?
- Pro malý tým bývá nejsnazší start Ansible, protože nepotřebuje agenta na spravovaných strojích a pracuje přes SSH s popisem v YAML. Puppet a Chef mají silnější model vynucování stavu a hodí se pro velké, dlouho žijící flotily serverů, ale nesou vyšší provozní režii vlastního serveru a jazyka. Salt cílí na rychlou hromadnou komunikaci. Rozhodující kritérium není funkční výbava, ale to, co tým dokáže udržovat: špatně spravovaný Puppet je horší než jednoduchý, ale poctivě používaný Ansible.
- Jak konfigurační management zachází s hesly a klíči?
- Tajemství nikdy nepatří do repozitáře v otevřené podobě. Praktická řešení jsou tři: šifrování hodnot přímo v souborech (Ansible Vault, SOPS), externí trezor, ze kterého si nástroj hodnoty vytáhne za běhu (HashiCorp Vault), nebo cloudový secret manager napojený přes roli instance. Ve všech případech patří do konfigurace jen odkaz na tajemství, ne jeho obsah. Rotaci klíčů je dobré promyslet dřív, než jich v systému bude několik stovek.
- Co znamená konfigurační drift a jak se mu bránit?
- Konfigurační drift je stav, kdy se skutečné nastavení strojů postupně rozchází s popisem v repozitáři, typicky kvůli ručním zásahům při incidentech. Obranou je pravidelné automatické spouštění konfigurace, které rozdíl buď rovnou opraví, nebo alespoň nahlásí, a dále zákaz trvalých ručních změn přes SSH. Radikálnější variantou je imutabilní infrastruktura: server se neopravuje, ale zahodí a znovu vytvoří z aktuálního popisu, takže drift nemá kde vzniknout.
- Kdy konfigurační management nestačí a je potřeba něco dalšího?
- Konfigurační management popisuje obsah už existujících strojů, ale sám je neumí vytvořit ani zrušit. Jakmile projekt potřebuje zakládat virtuální sítě, databázové instance nebo load balancery, přidává se k němu nástroj pro infrastrukturu jako kód, například Terraform nebo Pulumi. Pro nasazování aplikací a jejich verzí se pak typicky používá samostatný deployment pipeline nebo GitOps nástroj. Tři vrstvy (zdroje, konfigurace, aplikace) je lepší držet oddělené, protože mají různou frekvenci změn.
Zdroje
- Configuration management(otevře se v novém okně)
- Kubernetes Documentation: Configuration(otevře se v novém okně)
- AWS Systems Manager Documentation(otevře se v novém okně)
- Git Documentation(otevře se v novém okně)
Související pojmy
