Update, 17. listopadu 2016: vzali Jsme tento blog post série, rozšířil a obrátil ji do knihy s názvem Terraform: & Běží!
aktualizace, Červenec 8, 2019: Aktualizovali jsme tuto sérii příspěvků na blogu pro Terraform 0.12 a vydali 2. vydání Terraform: Up & Běh!
Toto je část 1 komplexního průvodce sérií Terraform. V úvodu k seriálu jsme diskutovali o tom, proč by každá společnost měla používat infrastructure-as-code (IAC). V tomto příspěvku budeme diskutovat o tom, proč jsme si vybrali Terraform jako náš nástroj výběru IAC.
Pokud hledáte na Internetu pro „infrastructure-as-kód“, je to docela snadné přijít s seznam nejpopulárnějších nástrojů:
- Kuchař
- Loutka
- Ansible
- SaltStack
- CloudFormation
- Terraform
Co není snadné je přijít na to, který z nich byste měli použít. Všechny tyto nástroje lze použít ke správě infrastruktury jako kódu. Všechny jsou open source, podporované velkými komunitami přispěvatelů a spolupracují s mnoha různými poskytovateli cloudu (s výraznou výjimkou CloudFormation, což je pouze uzavřený zdroj a AWS). Všechny nabízejí podporu podniku. Všechny jsou dobře zdokumentovány, a to jak z hlediska oficiální dokumentace, tak komunitních zdrojů, jako jsou příspěvky na blogu a otázky StackOverflow. Tak jak se rozhodnete?
to, Co dělá to ještě těžší je, že většina srovnání najdete on-line mezi tyto nástroje dělat víc, než seznam obecné vlastnosti každého nástroje a aby to vypadalo, že by mohl být stejně úspěšný s některou z nich. A i když je to technicky Pravda, není to užitečné. Je to trochu jako říkat programovém nováčku, že ty by mohly být stejně úspěšné budování internetové stránky s PHP, C, nebo Sestavy, — prohlášení, že je technicky vzato pravda, ale ten, který opomíjí obrovské množství informací, že by bylo nesmírně užitečné při vytváření správné rozhodnutí.
v tomto příspěvku se ponoříme do některých velmi specifických důvodů, proč jsme vybrali Terraform nad ostatními nástroji IAC. Stejně jako u všech technologií rozhodnutí, je to otázka kompromisů a priority, a zatímco vaše konkrétní priority mohou být jiné než naše, doufáme, že sdílení našeho myšlenkového procesu vám pomohou, aby vaše vlastní rozhodnutí. Zde jsou hlavní kompromisy, které jsme zvažovali:
- Konfigurace Řízení vs Provisioning
- Proměnlivých Infrastruktury vs Neměnné Infrastruktury
- Procesní vs Deklarativní
- Master vs Pána
- Agent vs Agentless
- Velká Komunita vs Malé Komunity
- Zralé vs Řezné Hrany
- Použití Více Nástrojů Dohromady,
Chef, Puppet, Ansible, a SaltStack jsou všechny konfigurační nástroje pro správu, což znamená, že jsou navrženy tak, aby nainstalovat a spravovat software na stávajících serverech. CloudFormation a Terraform jsou provisioning nástroje, což znamená, že jsou navrženy tak, aby poskytování samotné servery (stejně jako zbytek vaší infrastruktury, jako je vyrovnávání zatížení, databáze, síťové konfigurace, atd.), takže práce z konfigurace těchto serverů na jiné nástroje. Tyto dvě kategorie se vzájemně nevylučují, jako většina konfiguraci nástroje řízení mohou udělat určitý stupeň opravných položek a většina provisioning nástroje mohou udělat určitý stupeň řízení konfigurace. Zaměření na správu konfigurace nebo poskytování však znamená, že některé nástroje se lépe hodí pro určité typy úkolů.
zejména jsme zjistili, že pokud používáte Docker nebo Packer, drtivá většina vašich potřeb správy konfigurace je již postaráno. Pomocí Docker a Packer můžete vytvářet obrázky (například kontejnery nebo obrázky virtuálních strojů), které mají již nainstalovaný a nakonfigurovaný veškerý software, který váš server potřebuje. Jakmile máte takový obrázek, vše, co potřebujete, je server pro jeho spuštění. A pokud vše, co musíte udělat, je poskytování spoustu serverů, pak provisioning nástroj, jako je Terraform je typicky bude lepší fit než konfigurační nástroj pro správu (zde je příklad, jak používat Terraform nasazení Docker na AWS).
Proměnlivých Infrastruktury vs Neměnné Infrastruktury
Konfigurační nástroje pro správu, jako Chef, Puppet, Ansible, a SaltStack obvykle výchozí proměnlivých infrastruktury paradigma. Například, pokud řeknete, Šéfe nainstalovat novou verzi OpenSSL, bude aktualizace softwaru na vašich stávajících serverů a změny se budou dít v místě. Postupem času, jak používáte stále více aktualizací, každý server vytváří jedinečnou historii změn. To často vede k jevu známého jako konfigurace drift, kde každý server se stává mírně odlišné, než všechny ostatní, což vede k jemné, konfigurační chyby, které je obtížné diagnostikovat a téměř nemožné reprodukovat.
Pokud jste pomocí provisioning tool jako Terraform nasadit stroj obrazy vytvořené Docker nebo Balírny, pak každý „změna“ je ve skutečnosti nasazení nového serveru (stejně jako každá „změna“ do proměnné ve funkcionálním programování ve skutečnosti vrací novou proměnnou). Například, nasadit novou verzi OpenSSL, ty by se vytvořit nový obraz pomocí Packer nebo Docker s novou verzí OpenSSL již nainstalován, nasadit, že obraz přes sadu zcela nových serverů, a pak odpojení starých serverů. Tento přístup snižuje pravděpodobnost chyb v konfiguraci, usnadňuje přesně vědět, jaký software běží na serveru, a umožňuje vám kdykoli triviálně nasadit jakoukoli předchozí verzi softwaru. Samozřejmě je možné vynutit nástroje pro správu konfigurace, aby také prováděly neměnné nasazení, ale pro tyto nástroje to není idiomatický přístup, zatímco je to přirozený způsob, jak používat nástroje pro poskytování.
procedurální vs deklarativní
Chef a Ansible podporují procedurální styl, kde píšete kód, který krok za krokem určuje, jak dosáhnout požadovaného koncového stavu. Terraform, CloudFormation, SaltStack a loutka podporují deklarativnější styl, kde píšete kód, který určuje požadovaný koncový stav, a samotný nástroj IAC je zodpovědný za to, jak tento stav dosáhnout.
řekněme například, že jste chtěli nasadit 10 serverů („EC2 instance“ v AWS lingo) pro spuštění v1 aplikace. Zde je zjednodušený příklad Ansible šablonu, která to dělá s procesní přístup:
- ec2:
count: 10
image: ami-v1
instance_type: t2.micro
A zde je zjednodušený příklad Terraform šablonu, která dělá to samé pomocí deklarativní přístup:
resource "aws_instance" "example" {
count = 10
ami = "ami-v1"
instance_type = "t2.micro"
}
na povrchu, tyto dva přístupy mohou vypadat podobně, a když jste původně spouštět je s Ansible nebo Přeměně, budou produkovat podobné výsledky. Zajímavé je, co se stane, když chcete provést změnu.
představte si například, že se zvýšil provoz a chcete zvýšit počet serverů na 15. S Ansible, procedurální kód, který jsi napsal dříve, je už ne užitečné, pokud jste právě aktualizován počet serverů na 15 a zopakoval, že kód, to by nasadit 15 nových serverů, což vám dává 25 celkem! Takže místo toho si musíte být vědomi toho, co je již nasazeno, a napsat zcela nový procedurální skript pro přidání nových serverů 5:
- ec2:
count: 5
image: ami-v1
instance_type: t2.micro
S deklarativní kód, protože vše, co udělat, je deklarovat konec státu chcete, a Terraform přijde na to, jak se dostat do koncového stavu, Terraform bude také být vědomi toho, každý stát vytvořil v minulosti. Proto, aby se nasazení dalších 5 serverů, vše, co musíte udělat, je jít zpět na stejné Terraform šablonu a aktualizovat počítat od 10 do 15:
resource "aws_instance" "example" {
count = 15
ami = "ami-v1"
instance_type = "t2.micro"
}
Pokud jste provedli tuto šablonu, Terraform by si uvědomit, že se již vytvořil 10 serverů, a proto, že vše, co je potřeba udělat, bylo vytvořit 5 nových serverů. Ve skutečnosti, před spuštěním této šabloně, můžete použít Terraform je plan příkaz pro náhled, jaké změny by to udělat:
$ terraform plan+ aws_instance.example.11
ami: "ami-v1"
instance_type: "t2.micro"+ aws_instance.example.12
ami: "ami-v1"
instance_type: "t2.micro"+ aws_instance.example.13
ami: "ami-v1"
instance_type: "t2.micro"+ aws_instance.example.14
ami: "ami-v1"
instance_type: "t2.micro"+ aws_instance.example.15
ami: "ami-v1"
instance_type: "t2.micro"Plan: 5 to add, 0 to change, 0 to destroy.
Nyní co se stane, když chcete nasadit v2 služby? S procesní přístup, a to jak ze své předchozí Ansible šablony jsou opět není užitečné, takže budete muset napsat ještě další šablonu, vystopovat 10 serverů rozmístěných předchozí (nebo to bylo 15?) a pečlivě aktualizovat každý z nich na novou verzi. S deklarativní přístup Terraform, můžete jít zpět na přesně stejnou šablonu znovu a jednoduše změnit ami číslo verze na v2:
resource "aws_instance" "example" {
count = 15
ami = "ami-v2"
instance_type = "t2.micro"
}
Samozřejmě, výše uvedené příklady jsou zjednodušené. Ansible dělá vám umožní používat tagy hledání pro existující instance EC2 před nasazením nové (např. pomocí instance_tagscount_tag parametry), ale museli ručně zjistit, tento druh logiky pro každý zdroj se vám podaří s Ansible, založené na každý zdroj je minulost, může být překvapivě komplikovaná (např. hledání existujících instancí nejen podle značky, ale také verze obrázku, zóny dostupnosti atd.). To poukazuje na dva hlavní problémy s procesní IAC nástroje:
- Při jednání s procedurální kód, stav infrastruktury není zcela zachycen v kódu. Přečtení tří možných šablon, které jsme vytvořili výše, nestačí k tomu, abychom věděli, co je nasazeno. Také byste museli znát pořadí, v jakém jsme tyto šablony použili. Kdybychom je použili v jiném pořadí, mohli bychom skončit s jinou infrastrukturou, a to není něco, co můžete vidět v samotné kódové základně. Jinými slovy, Chcete-li uvažovat o Ansible nebo Chef codebase, musíte znát celou historii každé změny, která se kdy stala.
- znovupoužitelnost procesního kódu je ze své podstaty omezená, protože musíte ručně zohlednit aktuální stav kódové základny. Od státu se neustále mění, kód, který jste použili před týdnem již nemusí být použitelné, protože to byl navržen tak, aby změnit stav vaší infrastruktury, která již neexistuje. Jako výsledek, procedurální kódové základy mají tendenci se časem zvětšovat a komplikovat.
Na druhou stranu, s druh deklarativní přístup použitý v Terraform, kód vždy představuje nejnovější stav vaší infrastruktury. Na první pohled můžete zjistit, co je aktuálně nasazeno a jak je nakonfigurováno, aniž byste se museli starat o historii nebo načasování. To také usnadňuje vytváření opakovaně použitelného kódu, protože nemusíte ručně odpovídat za aktuální stav světa. Místo toho se soustředíte pouze na popis požadovaného stavu a Terraform zjistí, jak se automaticky dostat z jednoho státu do druhého. Výsledkem je, že Terraformní kódové základny mají tendenci zůstat malé a snadno pochopitelné.
samozřejmě existují i nevýhody deklarativních jazyků. Bez přístupu k plnému programovacímu jazyku je vaše expresivní síla omezená. Například, některé typy změn infrastruktury, jako je válcování, nulové prostoje nasazení, je těžké vyjádřit v čistě deklarativní podmínek. Podobně, bez schopnosti dělat „logiku“ (např. if-příkazy, smyčky), vytváření generických, opakovaně použitelných kódů může být složité (zejména v CloudFormation). Naštěstí, Terraform poskytuje řadu výkonných primitiv , jako vstupních proměnných, výstupních proměnných, modulů, create_before_destroycount, aby bylo možné vytvořit čisté, konfigurovatelný, modulární kód i v deklarativní jazyk. Budeme diskutovat o tyto nástroje více v Části 4, Jak vytvořit opakovaně použitelné infrastruktury s Terraform moduly a Části 5, Terraform tipy & triky: smyčky, if-prohlášení, a úskalí.
Master Versus Pána
ve výchozím nastavení, Chef, Puppet, SaltStack všechny vyžadují spuštění master serveru pro ukládání stavu vaší infrastruktury a distribuci aktualizací. Pokaždé, když chcete aktualizovat něco ve vaší infrastruktury, použití klienta (např. nástroj příkazového řádku) vydávat nové příkazy pro hlavní server a hlavní server buď tlačí aktualizace na všechny ostatní servery, nebo ty servery vytáhnout nejnovější aktualizace z master serveru na pravidelném základě.
hlavní server nabízí několik výhod. Za prvé, je to jediné centrální místo, kde můžete vidět a spravovat stav vaší infrastruktury. Mnoho nástrojů pro správu konfigurace dokonce poskytuje webové rozhraní (např. konzolu Chef, konzolu Puppet Enterprise) pro hlavní server, aby bylo snazší vidět, co se děje. Za druhé, některé hlavní servery mohou běžet nepřetržitě na pozadí a vynutit vaši konfiguraci. Tímto způsobem, pokud někdo provede ruční změnu na serveru, hlavní server může tuto změnu vrátit, aby se zabránilo posunu konfigurace.
nutnost spustit hlavní server má však některé závažné nevýhody:
- Extra infrastruktura: pro spuštění master musíte nasadit další server nebo dokonce cluster dalších serverů (pro vysokou dostupnost a škálovatelnost).
- údržba: musíte udržovat, aktualizovat, zálohovat, monitorovat a škálovat hlavní server(y).
- zabezpečení: musíte poskytnout klientovi způsob komunikace s hlavním serverem(servery) a způsob komunikace s ostatními servery, což obvykle znamená otevření dalších portů a konfiguraci dalších autentizačních systémů, což zvyšuje vaši plochu útočníkům.
Chef, Puppet, SaltStack mají různé úrovně podpory pro pána režimy, kde jste právě běží jejich software agenta na jednotlivé servery, typicky v pravidelných plán (např. cron, který se spouští každých 5 minut), a používat to, aby strhnout nejnovější aktualizace z verze ovládání (spíše než z master serveru). Tím se výrazně snižuje počet pohyblivých částí, ale, jak je popsáno v další části, stále zůstává řada nezodpovězených
otázky, zejména o tom, jak poskytování serverů a nainstalujte agenta software na nich na prvním místě.
Ansible, CloudFormation, Heat a Terraform jsou ve výchozím nastavení bez masterless. Nebo, abych byl přesnější, některé z nich se mohou spolehnout na hlavní server, ale je to již část infrastruktury, kterou používáte, a ne další kus, který musíte spravovat. Například, Terraform komunikuje s poskytovatelům cloudu pomocí cloud poskytovatele Api, takže v jistém smyslu, API servery jsou master servery, kromě toho, že nevyžadují žádnou zvláštní infrastrukturu nebo jakékoliv další autentizační mechanismy (tj., stačí použít API klíče). Ansible funguje tak, že se připojíte přímo ke každému serveru přes SSH, takže opět nemusíte spouštět žádnou další infrastrukturu ani spravovat další autentizační mechanismy(tj.
Agent Versus Agentless
Chef, Puppet a SaltStack vyžadují instalaci softwaru agenta (např. Agent obvykle běží na pozadí na každém serveru a je zodpovědný za
instalaci nejnovějších aktualizací správy konfigurace.
to má několik nevýhod:
- Bootstrapping: Jak si své servery vybavíte a nainstalujete na ně software agenta? Některé konfigurační nástroje pro správu kopat dolů na silnici, za předpokladu, že nějaké externí proces se bude starat o to pro ně (například, nejprve použít Terraform nasadit několik serverů s VM obraz, který má agent již nainstalován); jiné konfigurace nástroje řízení mají zvláštní bootstrapping proces, kde budete spouštět jednorázové příkazy k poskytování serverů pomocí cloud provider Api a nainstalujte agenta software na těchto serverech přes SSH.
- údržba: Musíte pečlivě Aktualizovat software agenta v pravidelných intervalech, dávat pozor, aby byl v synchronizaci s hlavním serverem, pokud existuje. Musíte také sledovat software agenta a restartovat jej, pokud dojde k chybě.
- zabezpečení: pokud software agenta stáhne konfiguraci z hlavního serveru (nebo z jiného serveru, pokud nepoužíváte master), musíte otevřít odchozí porty na každém serveru. Pokud hlavní server tlačí konfiguraci na agenta, musíte otevřít příchozí porty na každém serveru. V obou případech musíte zjistit, jak ověřit agenta na serveru, se kterým mluví. To vše zvyšuje vaši povrchovou plochu útočníkům.
ještě Jednou, Chef, Puppet, SaltStack mají různé úrovně podpory pro agentless režimy (např. sůl-ssh), ale tyto často pocit, jako by byli berte to jako nápad a ne vždy podporovat plnou sadu funkcí pro správu konfigurace nástroj. To je důvod, proč ve volné přírodě, výchozí nebo idiomatická konfigurace pro Kuchaře, loutka, a SaltStack téměř vždy zahrnuje agenta, a obvykle také mistra.
všechny tyto extra pohyblivé části zavádějí do vaší infrastruktury velké množství nových režimů selhání. Pokaždé, když dostanete zprávu o chybě ve 3 hodiny ráno, budete muset zjistit, jestli je chyba v kódu aplikace, nebo vaše IAC kód, nebo řízení konfigurace klienta, nebo master serveru(y), nebo tak, jak klient hovoří k master serveru(y), nebo, jak ostatní servery, mluvit k master serveru(y), nebo…
Ansible, CloudFormation, Heat, a Terraform nevyžadují k instalaci žádné další agenty. Nebo, abych byl přesnější, některé z nich vyžadují agenty, ale ty jsou obvykle již nainstalovány jako součást infrastruktury, kterou používáte. Například AWS, Azure, Google Cloud a všichni ostatní poskytovatelé cloudu se starají o instalaci, správu a ověřování softwaru agenta na každém ze svých fyzických serverů. Jako uživatel Terraformu se nemusíte starat o nic z toho: stačí vydat příkazy a agenti poskytovatele cloudu je provedou
na všech vašich serverech. S Ansible musí vaše servery spustit
démona SSH, který je stejně běžný na většině serverů.
velká komunita vs malá komunita
kdykoli vyberete technologii, vybíráte také komunitu. V mnoha případech může mít ekosystém kolem projektu větší dopad na vaše zkušenosti než vlastní kvalita samotné technologie. Společenství určuje, jak mnoho lidí se na projektu podílet, jak mnoho pluginů,
integrace a rozšíření jsou k dispozici, jak je to snadné najít pomoc online (např. blogové příspěvky, dotazy na StackOverflow), a jak snadné je, aby najmout někoho, aby ti pomohl (např. zaměstnanec, konzultant nebo support společnosti).
je těžké provést přesné srovnání mezi komunitami, ale některé trendy můžete najít vyhledáváním online. Níže uvedená tabulka ukazuje srovnání populární IAC nástroje, data jsem shromážděných v průběhu Května 2019, včetně toho, zda IAC nástroj je open source nebo closed source, co poskytovatelů cloudových služeb podporuje, celkový počet přispěvatelů a hvězdy na GitHub, kolik odevzdání a aktivní problémů tam bylo více než jeden měsíc období od poloviny dubna do poloviny Května, jak mnoho open source knihovny jsou k dispozici pro nástroj, počet otázek uvedených pro tento nástroj na StackOverflow, a počet pracovních míst, která zmiňují nástroj na Indeed.com.