Menu

Správa konfigurace v DevOps Practices

configuration management devops practices

Vyzkoušejte Náš Nástroj Pro Odstranění Problémů

Co je Configuration Management v DevOps Practices?

Koncept Kontinuální testování v DevOps bylo podrobně vysvětleno v našem předchozím tutoriálu.

Klíčovým vrcholem správy konfigurace v DevOps je poskytování,

  1. Infrastruktura jako kód
  2. Konfigurace jako kód

Musí číst => Exkluzivní řada výukových programů DevOps

jak vrátit pole řetězců v javě

Správa konfigurace v praxi DevOps

V praxi DevOps existuje řada výhod „Infrastruktura jako kód“ a „Konfigurace jako kód“.

    • Konfigurace jsou řízeny verzí
    • Automatizované a standardizované
    • Odebere závislost
    • Bezchybná infra nastavení
    • Posiluje spolupráci mezi provozním a vývojovým týmem
    • Oprava posunu konfigurace
    • Zacházení s infrastrukturou jako s flexibilním zdrojem
    • Automatické škálování infrastruktury
    • Zachování konzistence v nastavení

VIDEO Část 4 Blok 1: Správa konfigurace- 23 minut 7 sekund

Přepis:

V této části se dozvíme o Správa konfigurace, správa vydání a monitorování výkonu aplikací v DevOps.

Tady v bloku 1 se zaměříme na správu konfigurace a pochopíme, co je správa konfigurace a jak se liší v DevOps a tradičních metodách.

Nejprve si povíme, co je Configuration Management?

Správa konfigurace, jak název sám vysvětluje, není nic jiného než správa všech konfigurací prostředí, na kterých je softwarová aplikace hostována.

Jak víme, v rámci SDLC v DevOps máme různá prostředí, počínaje testováním jednotek, testováním integrace, testováním systému, akceptačním testováním a testováním koncových uživatelů.

Ve svých dřívějších tutoriálech jsem také vysvětlil, že nastavení prostředí pro tyto testy by se postupně stalo složitějším, protože by se posunulo k předprodukčnímu a produkčnímu prostředí.

Správa konfigurace je tedy v zásadě automatizovaný proces pro správu všech konfigurací každého z těchto prostředí.

Jaký je tedy rozdíl mezi tradiční správou konfigurace a správou konfigurace DevOps?

V našich tradičních metodách správy konfigurace tým používal ke správě těchto konfigurací různých prostředí prostřednictvím formální dokumentace, přičemž každá z konfigurací se zaznamenávala v dokumentech a konfigurační tým nebo manažer používaný ke zpracování správy verzí těchto dokumentů.

A jakmile dojde ke změnám, převezme také odpovědnost za nastavení prostředí a ruční správu konfigurací

Nyní v DevOps jsou obvykle všechny tyto procesy správy konfigurace velmi dobře automatizované a konfigurace jsou zapouzdřeny ve formě kódu nebo skriptů a řízeny pomocí nástroje pro správu verzí.

V této souvislosti můžeme nazvat, že tým operací je integrován s vývojem při správě prostředí prostřednictvím nástroje pro správu jedné verze.

Klíčovým vrcholem správy konfigurace v DevOps je tedy poskytování,

      1. Infrastruktura jako kód
      2. Konfigurace jako kód

Co vlastně znamená „infrastruktura jako kód“? Definuje celou definici prostředí jako kód nebo skript namísto záznamu ve formálním dokumentu.

Co tedy zahrnuje definice prostředí? Definice prostředí obecně zahrnuje nastavení serverů, konfiguraci sítí a nastavení dalších výpočetních prostředků, které jsou součástí nastavení IT infrastruktury. Všechny tyto podrobnosti by tedy byly zapsány jako soubor nebo ve formě kódu a zkontrolovány do nástroje pro správu verzí.

Tento skript nebo kód, který je zaškrtnut v řízení verzí, by se stal jediným zdrojem definování prostředí nebo dokonce aktualizace těchto prostředí.

Jen pro jednoduchost Příklad , pokud musíme přidat server do konkrétního prostředí, vše, co bychom udělali, je aktualizovat tyto informace do skriptů prostředí a spustit doručovací kanál, namísto ručního přechodu a vytočení nového prostředí s přidaným serverem nebo hledání pomoc administrátorů systému.

Krása spočívá v tom, že vývojář nebo tester nemusí být expertem na správu systému, aby nastavil své servery pro vývoj nebo testování.

Infrastruktura nastavená v DevOps bude tedy zcela automatizovaná a bude v zásadě sledovat skript, který je přihlášen k řízení verzí, počínaje instalací serverů, jejich konfigurací, instalací OS, dokud nebudou s nasazeným vytvořeny komunikační kanály těchto instancí. software.

Jaká je konfigurace jako kód?

Konfigurace jako kód není nic jiného než definování všech konfigurací serverů nebo jiných zdrojů jako kódu nebo skriptu a jejich kontrola do správy verzí.

Tyto konfigurační skripty, které se kontrolují do správy verzí, se spouští jako součást kanálu nasazení, aby se infrastruktura a její konfigurace nastavily automaticky.

Definování konfigurací zahrnuje parametry, které definují doporučené nastavení pro úspěšné spuštění softwaru. Nebo sada příkazů, které se mají nejprve spustit k nastavení softwarové aplikace. Nebo to může být konfigurace každé ze součástí softwaru, které mají být nastaveny, nebo konkrétní uživatelské role, uživatelská oprávnění atd.,

Jednoduchý Příklad by bylo nastavení přepínačů funkcí, kde jsou výchozí hodnoty nastaveny jako součást konfiguračního parametru.

Přidání dalšího portu do brány firewall by bylo další Příklad , které lze ve skriptu aktualizovat a později se tyto skripty spouští jako součást doručovacího kanálu.

K provedení automatizace infrastruktury na trhu je k dispozici několik nástrojů. Několik z nich je Chef, Puppet, Terraform atd., Chef and Puppet jsou nástrojem pro správu konfigurace na základě rubínů, zatímco Terraform je zajišťovacím nástrojem.

Vzhledem k tomu, že téměř všechny aplikace budou hostovány v cloudu AWS, dnes také poskytují RESTAPI, které lze pro tento účel využít.

Mám obrovský seznam výhod správy konfigurace v DevOps, místo toho, abych definoval infrastrukturu a konfigurace jako kód.

Pojďme je projít jeden po druhém.

Všechny konfigurace a podrobnosti infrastruktury jsou řízeny verzí, což je velká výhoda při implementaci DevOps.

# 1) To pomáhá týmu automaticky spravovat změny na serverech a konfiguraci a pomáhá rychle ladit, pokud něco selže, v krátkém časovém rozpětí a také umožňuje rychlé vrácení zpět k předchozí verzi, aniž by to zákazníkovi způsobilo jakékoli přerušení.

#dva) Jelikož jsou tyto skripty umístěny na centrálním serveru a všichni v týmu vědí, co je v každém z těchto skriptů a jaké jsou změny provedené v každé z těchto verzí. To také umožňuje týmu vrátit se ke starší verzi, pokud se v nejnovějších verzích vyskytne problém.

Představte si, že pokud dojde k selhání serveru, kolik času by trvalo jeho ruční obnovení. A teď, když definujeme infrastrukturu jako řízení skriptu a verze, můžeme ji okamžitě obnovit přechodem na dřívější verzi.

# 3) Správa konfigurací jako kódu také zabrání tomu, aby někdo omylem provedl změny v systému, a zabrání jakémukoli poškození způsobenému později ve výrobě.

Vzhledem k tomu, že správa konfigurace je zcela automatizovaná, je zcela vyloučen ruční zásah do nastavení nebo aktualizace.

Představte si dopad na náklady, kvalitu a čas, kdy dříve byli lidé závislí na lidských zdrojích, aby provedli tyto konfigurace ručně, a když některé konfigurace chybí nebo nejsou nastaveny podle potřeby.

Automatizace správy konfigurace tedy nejenže těží z úspory času, ale také z eliminace takových lidských chyb a zlepšení kvality. Standard kódování také pomohl týmu v dodržování specifikovaného standardu v kódování a automatizaci namísto sledování fantazie každého člověka, který píše průvodce konfigurací.

Jak již bylo zmíněno dříve, konfigurace dodávající jako kód odstranily závislost na jedné osobě nebo týmu s názvem správce konfigurace nebo konfigurační tým. Vývojový tým nemusí čekat, až konfigurační tým přijde a vyřeší jakýkoli problém s infrastrukturou nebo konfigurací.

Nebo dokonce pro nastavení infra a konfigurací, které jsou zcela automatizované a řízené verzí. Takže kdokoli v týmu, ať už je to vývojář nebo tester, může otáčet server a provádět konfigurace pro účely vývoje a testování. Nastavení serveru a konfigurací se proto stalo nezávislým na osobě.

Tím se také zajistí, že vývojové týmy a týmy QA nepoužívají stejné servery pro své aktivity, což obvykle platilo dříve.

Infrastruktura a konfigurace definované jako společný kód spolu s automatizací a řízením verzí standardizují všechna prostředí a nastavení. To nejenže vývojářům usnadňuje ladění, ale také eliminuje lidské chyby, které vedou k bezchybnému infrainstalaci, jinak by došlo k obrovskému poškození, pokud by nebylo detekováno dříve.

Zde můžeme jasně vidět jasnou spolupráci mezi Dev a Ops, kde se oba spoléhají na jediný zdroj pro provádění infrastruktury a oba týmy se aktivně podílejí na automatizaci a nastavení celé správy konfigurace.

Tato spolupráce na dosažení společného cíle zvyšuje spolupráci mezi týmy, vývojem a provozem.

Oprava posunu konfigurace

Co je Configuration Drift?

Malé rozdíly a nekonzistence mezi servery, k nimž někdy dochází v důsledku ruční aktualizace, která se hromadí po určitou dobu, se nazývají Configuration drift.

To není dobrá situace, protože tato nekonzistence na serverech ponechává určité programové soubory jako manifest, hrací kniha se nespustí spolehlivě na všech serverech, a proto vede k selhání automatizace. Tomu je tedy třeba se vyhnout, aby tým mohl efektivně využívat automatizaci konfigurací.

Správa infra a konfigurace jako kódu a verze, která je ovládá, pomohla týmu vyhnout se nebo opravit jakýkoli druh konfiguračních posunů mezi různými prostředími nebo mezi vývojovými a produkčními nastaveními důsledným udržováním konfigurací napříč všemi servery.

Tým tedy může být nejlépe zajištěn podobným nastavením konfigurace na vývojovém nastavení jako ve výrobě. To jim také pomáhá simulovat produkční problémy v prostředí dev.

To pomáhá zabránit jakémukoli druhu neočekávaných změn, které by se některý z členů týmu mohl pokusit provést na infra, což by mohlo narušit nastavení a také vynutit tým, aby v nastavení neprovedl žádné změny, pokud nejsou přihlášeni jako kód do úložiště.

Poskytování infrastruktury a její konfigurace jako kódu umožnilo týmu spravovat ji jako flexibilní zdroj, který splňuje dynamické obchodní potřeby zákazníka.

Je to druh plug and play. Tým se může konkrétně dostat na konkrétní server nebo do sítě a provést na nich změny. Může to být jen aktualizace zajišťovacího serveru nebo přidání nebo úprava úložiště v konkrétní síti nebo dokonce aktualizace operačního systému a vše lze nezávisle aktualizovat jako flexibilní prostředek.

Dříve bylo nutné změnit jeden konfigurační parametr, což zabralo hodně času, zvláště když bylo nutné aktualizovat na všech serverech, ale nyní je to jen na jeden krok. Aktualizujte skript a nahrajte jej do nástroje pro správu verzí a je vše hotovo.

Existuje flexibilita zcela zrušit stávající infrastrukturu a zcela vychovat další. Správa infrastruktury a konfigurací je tedy nyní docela snadná. Cloudová řešení umožnila, aby se infrastruktura automaticky zvětšila přidáním dalších výpočetních nebo úložných zdrojů podle potřeby a zmenšením, pokud nejsou požadovány.

To umožnilo optimalizaci využití prostředků na základě poptávky. Pokud chceme zvětšit infrastrukturu zvětšením velikosti stroje, můžeme to udělat okamžitě. Podobně, pokud chceme škálovat nebo možná přidat další nastavení nebo přidat další klientské rozhraní, můžeme to udělat během několika sekund jednoduše aktualizací v kódu a spuštěním automatizovaného kanálu.

V neposlední řadě infrastruktura, doručování jako kód v kontrolovaném prostředí pomáhá udržovat konzistenci prostředí napříč různými instalacemi. To také pomáhá při ladění problému. Tomuto bodu jsem se do určité míry zabýval také dříve, když mluvím o driftu konfigurace.

To je vše a toto završuje náš rozhovor o správě konfigurace v DevOps, o tom, co je infrastruktura a konfigurace jako kód a jaké jsou její výhody.

V našem nadcházejícím tutoriálu budeme diskutovat aspekty správy vydání v DevOps.

Výukový program PREV | DALŠÍ výuka

Doporučené čtení

^