Infrastructure as Code

Z Wikipedie, otevřené encyklopedie

Infrastructure as Code, Infrastruktura jako kód (IaC) je proces správy a provisioningu (vytváření) počítačových datových center pomocí strojově čitelných definičních souborů místo fyzické konfigurace hardwaru nebo interaktivních konfiguračních nástrojů.[1] IT infrastruktura spravovaná tímto procesem může sestávat jak z fyzických zařízení, jako jsou servery, tak z virtuálních strojů a příslušných konfiguračních prostředků. Definice infrastruktury mohou být ukládány ve verzovacím systému. IaC může používat buď skripty anebo deklarativní definice, ne však manuální procesy; termín však je častěji používán k propagaci deklarativních přístupů.

Úvod[editovat | editovat zdroj]

IaC vzniklo jako odezva na potíže, které představovalo utility computing a WWW frameworky druhé generace. Spuštění Amazon Web Services Elastic Compute Cloud a verze 1.0 Ruby on Rails o několik měsíců dříve,[2] způsobilo v roce 2006 ve firmě rozsáhlé problémy se škálováním služeb, ke kterým dříve docházelo pouze v obřích multinacionálních společnostech.[3] S objevováním nových nástrojů pro zvládnutí tohoto stále rostoucího problému se zrodila myšlenka IaC. Myšlenka vytvářet infrastrukturu pomocí kódu, a mít pak možnost navrhovat, implementovat, a nasazovat infrastruktury aplikací s využitím best practices – postupů prověřených v oblasti vývoje softwaru, se zalíbila jak vývojářům softwaru tak správcům IT infrastruktury. Možnost zacházet s infrastrukturou jako s kódem a používat stejné nástroje jako v jiných softwarových projektech umožňovala vývojářům zrychlit nasazování aplikací.[4]

Přidaná hodnota a výhody[editovat | editovat zdroj]

Výhody IaC lze rozdělit do tří měřitelných kategorií: cena, rychlost, a riziko.[zdroj?] Snížení ceny si klade za cíl pomáhat produkční firmě nejen finančně, ale také snížením potřebného množství lidí a práce, což znamená, že díky odstraňování manuálních komponent jsou lidé schopni zaměřit své úsilí na jiné úkoly.[zdroj?] Automatizace infrastruktury díky rychlejšímu provádění konfigurace zrychluje její nasazení a díky lepší viditelnosti pomáhá jiným týmům ve firmě pracovat rychleji a efektivněji. Automatizace odstraňuje rizika způsobená lidskými chybami, jako je chybná manuální konfigurace; jejich odstranění přispívá ke snížení doby výpadků a prostojů a zvyšuje spolehlivost. Tyto výsledky a atributy pomáhají firmě k implementaci kultury DevOps kombinující fungování vývoje a provozu.[5]

Typy přístupů[editovat | editovat zdroj]

Obecně existují dva přístupy k IaC: deklarativní (funkční) a imperativní (procedurální). Zatímco Deklarativní přístup se zaměřuje na to, co má být výsledným cílem konfigurace; imperativní přístup se zaměřuje na to, jak je nutné infrastrukturu změnit, aby příslušné požadavky splňovala.[6] Deklarativní přístup definuje požadovaný stav a systém vykoná, co je potřebné, aby byl požadovaný stav dosažen. Imperativní přístup definuje určité příkazy, které musí být provedeny ve vhodném pořadí, aby výsledkem byl požadovaný stav.[7]

Metody[editovat | editovat zdroj]

Podle způsobu, jakým se dopravuje konfigurace do serverů rozeznáváme metodu push a pull. U metody pull si server stahuje svoji konfiguraci z řídícího serveru. U metody push řídící server sám odesílá konfiguraci na cílový systém.[8]

Nástroje[editovat | editovat zdroj]

Existuje mnoho nástrojů, které poskytují funkcionalitu automatizace infrastruktury a používají IaC. Volně řečeno, jakýkoli framework nebo nástroj, který provádí změny nebo konfiguruje infrastrukturu deklarativně nebo imperativně pomocí programu lze považovat za IaC.[9] Tradičně byly pro IaC používány nástroje pro automatizaci životního cyklu serverů a nástroje pro správu konfigurací. Společnosti nyní používají také nástroje pro automatizaci průběžné konfigurace nebo samostatné IaC frameworky, jako například PowerShell DSC firmy Microsoft[10] nebo AWS CloudFormation.[11]

Automatizace průběžné konfigurace[editovat | editovat zdroj]

Všechny nástroje automatizace průběžné konfigurace (anglicky continuous configuration automation CCA) lze považovat za rozšíření tradičních IaC frameworků. Využívají IaC pro změny, konfiguraci a automatizaci infrastruktury, a poskytují také viditelnost, efektivitu a flexibilitu při správě infrastruktury.[3] Tyto další atributy poskytují bezpečnost a dodržování postupů na podnikové úrovni.

Aktivita komunity[editovat | editovat zdroj]

U CCA nástrojů s otevřeným zdrojovým textem je důležitým aspektem výběru aktivita jejich komunity. Jak uvádí Gartner Inc., hodnota CCA nástroje je „stejně závislá na obsahu a podpoře přispívající komunity uživatelů, jako na komerční vyspělosti a výkonu nástrojů pro automatizaci“.”[3] Společnosti jako Puppet a Chef, které se vývojem zabývají již dlouho, vytvořily své vlastní komunity. Chef využívá Chef Community Repository a Puppet PuppetForge.[12] Jiní dodavatelé spoléhají na ostatní komunity a využívají jiné IaC frameworky jako například PowerShell DSC.[10] Objevují se i noví dodavatelé, kteří se nesoustředí na obsah, ale na model založený na inteligenci produktu při přinášení obsahu. Tyto vizuální objektově orientované systémy fungují dobře pro vývojáře, ale obzvláště užitečné jsou pro produkčně orientované DevOps a operační složky, které více cení modelů než skriptování obsahu. Jak se obor stále vyvíjí a mění, komunitně založený obsah se stává stále důležitějším pro to, jak se nástroje IaC používají, pokud nejsou řízené modelem a objektově orientované.

K významným CCA nástrojům patří:

Nástroj Tvůrce Metoda Přístup Použitý jazyk Komentář
Chef Chef (2009) Pull Deklarativní a imperativní Ruby -
Otter Inedo Push Deklarativní a imperativní - orientovaný na Windows
Puppet Puppet (2005) Pull Deklarativní a imperativní C++ & Clojure od 4.0, Ruby -
SaltStack SaltStack Push a Pull Deklarativní a imperativní Python -
CFEngine Northern.tech Pull Deklarativní C -
Terraform HashiCorp (2014) Push Deklarativní Go -
Ansible / Ansible Tower Red Hat (2012) Push Deklarativní a imperativní Python -

K dalším nástrojům patří AWS CloudFormation, cdist, StackStorm, Juju, a Pulumi.

Vztah k DevOps[editovat | editovat zdroj]

IaC může být klíčovým prvkem, který dovolí zavedení osvědčených postupů (anglicky best practices) v DevOps – vývojáři se více zapojují do definování konfigurace a týmy Ops se zapojují dříve do vývojového procesu.[13] Nástroje, které využívá IaC, přinášejí viditelnost stavu a konfigurace serverů a v konečném důsledku tuto viditelnost zpřístupňují uživatelům v rámci firmy, což vede k propojení týmů a maximalizaci jejich výkonu.[14] Automatizace se obecně snaží odstraňovat nedorozumění a náchylost manuálních procesů k chybám a vede k vytvoření efektivnějších a produktivnějších procesů. Umožňuje flexibilně vytvářet lepší software a aplikace s méně výpadky celkově nákladově efektivním způsobem pro společnost. Cílem IaC je snížení složitosti, která snižuje efektivitu plynoucí z manuální konfigurace. V DevOps jsou automatizace a spolupráce považovány za centrální body; nástroje pro automatizaci infrastruktury jsou často obsaženy jako komponenty v DevOps toolchainu.[15]

Vztah k bezpečnosti[editovat | editovat zdroj]

Zpráva o cloudových hrozbách pro rok 2020 vydaná týmem Unit 42 bezpečnostní firmy Palo Alto Networks, který je zaměřen na bezpečnostní hrozby, informuje o existenci okolo 200 tisíc potenciálních zranitelností v šablonách IaC.[16]

Odkazy[editovat | editovat zdroj]

Reference[editovat | editovat zdroj]

V tomto článku byl použit překlad textu z článku Infrastructure as code na anglické Wikipedii.

  1. Wittig a Wittig 2016, s. 93.
  2. BOWER, Joseph L.; CHRISTENSEN, Clayton M. Disruptive Technologies: Catching the Wave. Harvard Business Review. 
  3. a b c FLETCHER, Colin; COSGROVE, Terrence. Innovation Insight for Continuous Configuration Automation Tools. [s.l.]: Gartner, 2015-08-26. Dostupné online. 
  4. RILEY, Chris. Version Your Infrastructure. DevOps.com. 2015-11-12. Dostupné online. 
  5. PHILLIPS, Andrew. Moving from Infrastructure Automation to True DevOps [online]. DevOps.com, 2015-05-14. Dostupné online. 
  6. Declarative v. Imperative Models for Configuration Management: Which Is Really Better? [online]. Scriptrock.com [cit. 2015-12-14]. Dostupné v archivu pořízeném dne 2015-03-31. 
  7. LOSCHWITZ, Martin. Choosing between the leading open source configuration managers. www.admin-magazine.com. Lawrence, KS USA: Linux New Media USA LLC, 2014-11-14. Dostupné online. 
  8. VENEZIA, Paul. Puppet vs. Chef vs. Ansible vs. Salt [online]. Network World, 2013-11-21 [cit. 2015-12-14]. Dostupné v archivu pořízeném dne 2018-07-18. 
  9. Garner Market Trends: DevOps – Not a Market, but Tool-Centric Philosophy That supports a Continuous Delivery Value Chain. [s.l.]: Gartner, 2015-02-18. 
  10. a b CHAGANTI, Ravikanth. DevOps, Infrastructure as Code, and PowerShell DSC: The Introduction. www.powershellmagazine.com. PowerShell Magazine, 2016-01-05. Dostupné online [cit. 2016-01-11]. 
  11. https://aws.amazon.com/about-aws/whats-new/2011/02/25/introducing-aws-cloudformation/
  12. STURGEON, Phil. Puppet or Chef? [online]. 2012-10-28 [cit. 2021-09-22]. Dostupné v archivu pořízeném dne 2016-02-01. 
  13. RAMOS, Martin. Continuous Integration: Infrastructure as Code in DevOps [online]. easydynamics.com, 2015-11-04 [cit. 2016-01-29]. Dostupné v archivu pořízeném z originálu dne 2016-02-06. 
  14. Infrastructure As Code: Fueling the Fire for Faster Application Delivery. [s.l.]: Forrester, březen 2015. 
  15. WURSTER, Laurie F.; COLVILLE, Ronni J.; HEIGHT, Cameron; TRIPATHI, Somendra; RASTOGI, Aditi. Emerging Technology Analysis: DevOps a Culture Shift, Not a Technology. [s.l.]: Gartner 
  16. Cloud Threat Report Shows Need for Consistent DevSecOps [online]. InformationWeek [cit. 2020-02-24]. Dostupné online. (anglicky) 

Literatura[editovat | editovat zdroj]

Související články[editovat | editovat zdroj]