Nástroje pro pokročilou virtualizaci a orchestraci serverů
Diplomová práce
Studijní program: N2612 – Elektrotechnika a informatika Studijní obor: 1802T007 – Informační technologie Autor práce: Bc. Vojtěch Šindler
Vedoucí práce: Ing. Roman Špánek, Ph.D.
Liberec 2016
Advanced tools for server virtualization and orchestration
Diploma thesis
Study programme: N2612 – Electrotechnology and informatics Study branch: 1802T007 – Information technology
Author: Bc. Vojtěch Šindler
Supervisor: Ing. Roman Špánek, Ph.D.
Abstrakt
Diplomová práce se zabývá problematikou pokročilé virtualizace a orchestrace serverů. V prvních třech kapitolách je čtenář seznámen se základními pojmy týkající se virtualizace a orchestrace. V dal- ších kapitolách se diplomová práce zaměřuje na platformy chef a puppetDB, které jsou hojně využívány k orchestraci výpočetních zdrojů. Poslední dvě kapitoly jsou určeny praktické implementaci platforem chef a puppetDB.
Klíčová slova
virtualizace, orchestrace, Puppet, PuppetDB, Puppet Enterprise, Chef, Chef server
Abstract
This thesis deals with the advanced virtualization and orchestration servers. The first three chapters the reader is familiar with the basic concepts related to virtualization and orchestration. In subsequent chapters, the thesis focuses on the platforms chef and puppetDB, which are widely used for orchestration of computing resources. The last two chapters are practical implementation platforms chef and puppetDB.
Key words
virtualization, orchestration, Puppet, PuppetDB, Puppet Enterpri- se, Chef, Chef server
Poděkování
Děkuji vedoucímu práce Ing. Romanu Špánkovi, Ph.D za neocenitelné rady a pomoc při tvorbě diplomové práce.
Dále bych chtěl poděkovat rodině a přátelům bez jejichž pomoci bych studium nikdy nedokončil.
6
Obsah
Seznam zkratek . . . 9
1 Virtualizace 12 1.1 Virtuální stroj. . . 12
1.2 Typy virtualizace . . . 13
1.2.1 Aplikační virtualizace . . . 13
1.2.2 Hardwarová virtualizace . . . 14
1.3 Hypervisor. . . 15
2 Orchestrace 17 2.1 Orchestace v cloud computingu . . . 18
3 DevOps 19 4 Chef 21 4.1 Chef components . . . 21
4.1.1 Workstations . . . 22
4.1.2 Cookbooks . . . 24
4.1.3 Nodes - Uzle . . . 26
4.1.4 The Chef Server . . . 27
4.1.5 Analytics . . . 28
5 Puppet DB 29 5.1 MCollective . . . 29
5.1.1 Možnosti MCollective . . . 30
5.2 Hiera . . . 30
5.3 Puppet Dashboard . . . 31
5.4 The Foreman . . . 31
5.4.1 Architektura Foremana . . . 32
5.5 Geppetto . . . 33
6 Docker 34
6.1 Architektura Dockeru. . . 34
6.1.1 Uvnitř Dockeru . . . 35
6.1.2 Jádro Dockeru . . . 36
7 Aplikace platformy Chef 38 7.1 Workstation . . . 39
7.1.1 Kitchen . . . 40
7.2 Chef server . . . 42
7.2.1 Párování Chef serveru s Uzlem . . . 42
8 Aplikace platformy PuppetDB 45 8.1 Puppet master . . . 46
8.2 Puppet agent . . . 47
8.2.1 Správa nodů . . . 48
8.3 PuppetDB . . . 50
9 Chef vs. PuppetDB 53
Přílohy 59
A Zdrojové soubory konfigurace SSH v Chefu 60
B Zdrojové soubory konfigurace NTP v PuppetDB 63
C Obsah přiloženého CD 66
8
Seznam zkratek
TUL Technická univerzita v Liberci
FM Fakulta mechatroniky, informatiky a mezioborových studií Technické uni- verzity v Liberci
OS Operační systém
NIC Network Interface Card VM Virtual Machine
VMM Virtual Machine Monitor
DevOps Development and (IT) Operations SaS Software as a Service
LXC Linux Containers
DSL Domain Specific Language
Úvod
Od dob vynálezu počítačů datovaných do 30. let 20. stol. uběhlo více jak 80 let.
Vývoj, který během té doby počítače zaznamenali je ohromný. Stejně jako v mi- nulosti kdy jedním z důležitých milníků vývoje počítačů bylo uvedení procesoru 386, bylo pro dnešní informatiku důležitým krokem postupné nasazování serverové virtualizace.
Celá problematika pokročilé virtualizace a orchestrace, kterou se zabývá tato diplomová práce, je spojená s masivním nástupem virtualizace v průběhu několika posledních let, a sním spojený nástup cloudových technologií se dle mého názoru dostáváme do bodu, který zde již v minulosti byl použit, na mysli mám architekturu host-terminál. V dnešní době roste poptávka po cloudových řešeních a rok od roku je jejich procento na celkovém trhu zvyšuje.
Z důvodu zajištění vysoké dostupnosti a bezpečnosti v oblasti ochrany dat bývají výpočetní zdroje přesouvány do datacenter, přičemž zákazníci se k ním vzdáleně připojují a celé IT tak částečně směřuje k architektuře host-terminál.
Díky přesunu výpočetního výkonu do datacenter vzniká problém se správou vý- početních zdrojů. Bylo potřeba zavést takové nástroje, aby veškerá zpráva výpočet- ních zdrojů mohla probíhat decentralizovaně.
Při správném použití virtualizace je možné dosáhnout informačních systém s vysokou dostupností, ale je zde nutné vše řádně nastavit. Do nedávné doby nee- xistovali nástroje, které by celý ten proces dokázali zautomatizovat. Právě touto automatizací, označovanou jako orchestrací se zabývá má diplomová práce.
V průběhu času se objevily nástroje, které byli schopné do určité míry proces na- sazení virtuálního stroje zautomatizovat. Jedním z mnoha je MS Active Directory, který dokáže rozdělit infrastruktury na domény a skupiny uživatelů. U každé domé- ny či skupiny uživatelů lze nastavit aplikace, které mají být přístupné už od prvního přihlášení. Celé toto řešení funguje, ale není multiplatformní a je čistě určeno pro správu desktopových či virtuálních stanic běžících na OS Windows. Naštěstí během několika let vznikly nástroje, skrze které je možné spravovat libovolnou platformu,
10
nic méně určitá omezení tu stále jsou a to u OS Windows. Tato omezení jsou způso- bená tím, že zdrojové soubory jádra OS Windows nejsou šiřitelná pod licencí GNU.
V této diplomové práci se zaměřím na nejvíce používané orchestrátory, kterými jsou Chef a PuppetDB.
Právě popisem a aplikací těchto dvou platforem se bude zabývat má diplomová práce. V úvodní bude nastíněna základní problematika virtualizace, orchestrace a DevOps. V případě DevOps se jedná i zjednodušené spravování cloudovách platforem jako jsou docker a MS Azzure.
Cílem diplomové práce je seznámení s prostředky pro pokročilou virtualizaci a orchestraci severů, dále pak, porovnání dostupných řešení a následnou pilotní realizaci využití.
Někoho může napadnout otázka má-li nasazení orchestrace nějaký smysl, tuto otázku lze částečně přirovnat k problematice nasazení NoSQL databázím.
Jedním z mnoha způsobů využití orchestrátorů využití je tam, kde je nutné spra- vovat velké množství výpočetních zdrojů. Mezi další možnosti využití kontinuálním vývoji aplikací, kdy se kód přesouvá z testovacího prostředí do produkčního a díky podpoře continous integration.
Continuos integration je vhodné používat tam, kde spolu spolupracuje více dis- tribuovaných týmů, které potřebují mít jednoduše zaručeno, že se předává aplikace s celým prostředím, přesně v tom stavu a s takovými aktualizacemi jako má jiný tým. Díky tomu je možné snazší testování aplikace dále pak případná simulaci chyb.
Má diplomová práce hledá způsoby využití orchestrátorů v praxi. Dále bych rád ověřil jedno z hlavních hesel orchestrace, kterým je ”Write once use many”. Jinak řečeno neopakovat to co jednou bylo již použito. Dá se tedy využít služeb, kde jsou již určité tipy konfigurací vytvořeny. Administrátor je nemusí řešit a může se zabývat podstatnějšími věcmi.
1 Virtualizace
S tímto pojmem se můžeme potkávat již od 60. let 20. století století. V IT pojem virtualizace popisuje vytvořené virtuální (imaginární) prostředí, kde je možné vy- tvářet různé objekty. Mezi nejčastěji vytvářený objekt patří počítač, takový počítač je označován jako virtuální stroj (z angl. Virtual machine).
Již od doby svého vzniku spolu tyto dva termíny úzce souvisí. První vytvořený virtuální stroj je vázán se vznikem experimetálního systému IBM M44/44X.
Se vznikem virtuálních strojů, bylo nezbytné vytvořit unufikované prostředí, ve kterém by bylo možné virtuální stroje zpravovat. Toto prostředí bylo později ozna- čeno jako hypervisory. [14]
1.1 Virtuální stroj
Tímto pojmem je nejčastěji označována implementace jakéhokoliv stroje, nejčastěji však počítače, který umožňuje spouštět stejné aplikace jako na fyzickém počítači.
Virtuální stroje je možné rozdělit do dvou skupin na základě jejich funkčnosti:
• System virtual machine
Tento virtuální stroj poskytuje kompletní systémové služby, které jsou nezbytné pro realizaci plnohodnotného OS tam kde:
– není možné poskytnout dostatečné hardwarové vybavení – nutná optimalizace výpočetních zdrojů.
• Process virtual machine
Tento typ virtuálního stroje je určen ke spuštění jediného programu, ta- kový virtuální stroj je vhodné vytvořit tam, kde je zapotřebí poskytnout op- timalizované, přenosné a flexibilní prostředí, které je navrženo na míru dané situaci. [14][13]
12
Samotný virtuální počítač je víceúčelové zařízení, i přesto má své klady a zápory [13]:
+ Možný chod více OS na jednom fyzickém stroji + Snadná údržba
+ Zajištění vysoké dostupnosti
- Vytvořený virtuální počítač nedosahuje výkonu fyzického PC - Problém pří více násobném přístupu VM na stejný diskový oddíl.
- Systém slouží pro správu VM (tzv. Hypervisor) má svojí vlastní režii
1.2 Typy virtualizace
V současné době se virtualizace rozděluje do dvou větvím a to na [12]
• Aplikační virtualizaci
• Hardwarovou virtualizaci
1.2.1 Aplikační virtualizace
V tomto případě se jedná o použití speciálního softwaru, který umožňuje zapouz- dření aplikace do svého vlastního prostředí. Je možné, za určitých okolností, spustit aplikaci pro Win32 (Win64) na Unixových systémech.
Aplikace není spouštěna na úrovni jádra operačního systému, ale na aplikační úrovni (neprivilegovaný mód). Ke komunikaci s jádrem OS používá prostředníka (interpreta), který umožňuje přístup k hardwarovým prvkům. Jako interpreta lze uvést: Cintrix XenApp, Microsoft App-V, Sandboxie, etc. [12]
Obrázek 1.1: Popis aplikační virtualizace [22]
1.2.2 Hardwarová virtualizace
Hardwarová virtualizace se váže a pojí s vytvářením VMs, každý VMs se chová jako fyzické PC. Software spuštěný na VM je oddělen od přímé přístupu k hardwaro- vým zdrojům virtualizační platformou (hypervisorem), v jistém slova smyslu vzniká abstrakce hardwarových zdrojů. [11]
Hardwarová virtualizace se postupem času vyvíjela. V současné době mezi nejvíce používané typy patří:
• Částečná virtualizace
U částečné virtualizace není virtuální a hardwarová vrstva plně oddělena, všechny provozované VM sdílejí jeden adresní prostor. Klíčovou funkcí částečné virtualizace je správná virtualizace adresového prostoru tak, aby každá VM měla kozistentní adresový prostor.
• Plná virtualizace
Plná virtualizace nastává ve chvíli, kdy jsou jsou všechny části počítače virtualizovány. V tu chvíli nemůže provazovaný OS rozpoznat rozdíl mezi fyzic- kým a virtuálním počítačem, není tedy nutné modifikovat spuštěné programy.
Jedná se o ideální stav, kdy je virtuální a fyzická vrstva plně oddělena.
• Paravirtualizace
Paravirtualizace nastává ve chvílí, kdy je nutné sdílet mezi VMs některé hardwarové prvky počítače, ve kterém jsou spuštěny, jedná se sice o zmenše- ní úrovně abstrakce, ale odměnou je menší zvětšení efektivity VMs. I přesto
14
má paravirtualizace své nevýhody, ta spočívá v nutnosti řízení přístupu ke sdíleným hardwarovým zdrojům (např: přístup k NIC). [14][11]
1.3 Hypervisor
Hypervisor (dříve označovaný jako VMM - z angl. Virtual Machine Monitor) je ozna- čení softwaru, který umožňuje na jednom počítači (hostitelském) spuštění jednoho či více VM.
Hypervizor řídí přístup VM k hardwarovým prvkům hostitelského počítače, dále je jeho činností [14][10]:
• Vytváření VM
• Správa VM
• Oddělení spuštěných VM
V roce 1974 zavedl pan P. Goldberg dělení hypervisorů do dvou skupin:
• nativní (bare-metal hypervisor)
Hypervizor je provozován přímo na hostileském počítači, kde řídí přístup VM k hardwarovým zdrojům. Hostovaný OS funguje pod úrovní hypervisoru.
Takto provozovaný hypervisor představuje model VM, který byl navržen v 70. letech 20. stol. V současné době je hlavním představitelem této kategorie hypervisor ESXi od firmy VMware.
• hostovaný
Tento druh hypervizoru je spuštěn v rámci operačního systému. Vrstva, která obstarává správu VM se nachází nad vrstvou OS. Typickým představi- telem této skupiny je MS Hyper-V.
Obrázek 1.2: Dělení hypervisorů [23]
16
2 Orchestrace
Orchestrace popisuje uspořádaní, řízení a koordinaci počítačových systémů a služeb.
Použití orchestrace se často pojí s nasazením:
• architektury orientované na služby
• virtualizace
• konvergence služeb a architektury
• provisioning aplikací
Orchestrace je v tomto smyslu sladění aplikací, infrastruktury a dat, dále vymezuje politiku, úrovně a automatizaci spravovaných služeb, dále také: release polici, user polici, etc. Vzniká tedy infrastruktura aplikací, která může být upravena na základě jejich potřeb. Další náplní orchestrace je centralizovaná správa výpočetních zdrojů, orchestrace mimo jiné poskytuje měření spotřebovaného výpočetního výkonu a s tím spojené účtování služeb. Pro administrátory je nejdůležitějším benefitem zjed- nodušená správa celé výpočetních zdrojů, kdy stačí provádět změny v konfiguraci na jednom místě, změna se následně rozdistribuje bez dalších nutných zásahů [9].
S pojmem v orchestrace se v IT můžeme setkat v posledních dvou letech. I přesto to neznamená, že něco jako orchestrace v minulosti neexistovalo. Jen se to tak nenazývalo.
Mezi předchůdce orchestrátorů lze zařadit MS Active Directory. Ten do určité míry podporuje automatizaci při zavádění nových strojů, ale rozhodně se nedá říci, že by se dal použít při vývoji aplikací, kde je v současné době žádoucí simulovat běhové prostředí. Dá se říci, že jediné co MS Active Directory perfektně umí je správa uživatelských účtů, dále je nutné zmínit že se nejedná o multiplatformní službu. MS Active Directory lze provozovat pouze na platformě Windows.
2.1 Orchestace v cloud computingu
Cloud comuting představuje více členitou a specifickou architekturu, kde je nutné dbát na přesné dodržování pracovních postupů, které se nasazují v různých domé- nách. Na jedné úrovni jsou firemní procesy, a na jiné úrovni se nacházejí provozní procesy. Orchestrátor by měl být schopen provádět úpravy na všechny úrovní clou- dové infrastruktury [9].
Hlavní rozdílem oproti klasickému nasazení je, že prováděné změny jsou zpraco- vány a dokončeny jako procesy v rámci jedné domény. Proto orchestrace obsahuje metody pro práci s větším počtem klientů.
V této souvislosti je celkovým cílem dosáhnout maximalizace výpočetních zdrojů, minimalizace nákladů, mapování výkonu, vytížení jednotlivých aplikací dále pak dojde k značné úspoře lidské práce a tudíž i ke snížení pravděpodobnosti chyby zaviněné lidským faktrorem a v neposlední řadě zvýšení efektivity nsazování patchů a dalších aplikací nahrávaných do cloudové infrastruktury. Díky tomu je možné docílit efektivnější údržbu služeb [8].
Oblasti použití orchestrace:
• dynamické škálování
• dynamické připojování a automatizace propojených služeb
• etc.
18
3 DevOps
Termín DevOps vznikl při kombinací dvou souvisejících trendů vývoje, jedná se kombinaci agilního vývoje a širšího pojetí spolupráce mezi vývojovým a provozním týmem. Díky dochází k lepší komunikaci mezi týmy v průběhu celého životního procesu a celý vývoj směřuje směrem k architekturám orientovaným na služby.
Samotná zkratka DevOps je spojením dvou anglických slov Develop a Operation.
Kde Dev představuje skupinu vývojářů a Ops skupiny systémových administrátorů a inženýrů a bezpečnostních specialistů.
Při vývoji metodou DevOps je kladen důraz na komunikaci, integraci mezi Dev, Ops týmem a zadavatelem. Cílem DevOps je zrychlení, zefektivnění a zkvalitnění produkce aplikací a služeb [7][15].
Obrázek 3.3: DevOps [24]
Procesy DevOps jsou cíleny na:
• testovaní kvality
• rozvoj produktu (vydávání nových verzí)
• zrychlení vydávání nových verzí
• oprava nalezených bezpečnostních trhlin Body nutné ke správnému zavedení DevOps:
1. Využití metod agilního programování 2. Pravidelné schůzky se zadavatelem 3. vysoká dostupnost
Vyvíjená aplikace by měla být vždy dostupná, což z technologického hle- diska (většinou) znamená použití virtualizace (nebo celé cloudové infrastruk- tury).
4. využití automatizace konfiguračních nástrojů 5. zavedení automatických testů aplikace
Dá se jednoduše říct, že DevOps podporuje standartizaci vývojových prostředí a po- stupů. DevOps můžeme tedy chápat jako jakési ucelené řešení vývoje ať už aplikací, služeb či infrastruktur [7][6].
20
4 Chef
Chef je automatizační platforma, jejíž cílem je přeměna infrastruktury do podoby kódu. Je jedno jestli provoz probíhá na vlastních serverech či na cloudové infrastruk- tuře, chef je vždy schopen automatizovat celý proces nasazení a to bez ohledu na umístění v síti popřípadě velikosti aplikací. Jádro této aplikace je napsáno v jazyce Ruby. Díky tomu je možné psát v jazyce DSL (z angl. domain specific language) různé skripty, pro které se používá anglické označení ”recepis”.
Chef umožňuje rozdělit jakoukoliv architekturu na pomyslné stavební kameny, ze kterých je potom možné skládat funkční celky. Proto bývá nasazován tam, kde je nutné zefektivnit a zautomatizovat konfiguraci a údržbu serverů (je jedno zda se jed- ná o fyzický či virtuální server). V současné době bývá častým jevem implementace do cloudových platforem, například [4]:
• OpenStack
• MS Azure
• Rackspace
• Docker
• etc.
4.1 Chef components
Následující obrázek naznačuje vztahy mezi jednotlivými komponenty Chefu. Všech- ny zobrazené komponenty komunikují na základě architektury server - client (Chef - client).
Mezi jednotlivé komponenty Chefu patří [5]:
• Workstation – Cookbooks
– Ruby
• Node
• Chef Server
• Chef Analitics
Zvláštní skupinu tvoří tzv. Chef Supermarket. Jedná se místo, které je určeno ke sdílení Cookbooks vytvořených komunitou. Cookbooks, které jsou součástí Chef supermarketu, může využít libovolný počet uživatelů, kteří chtějí daný Cookbook zahrnout do svého systému [5].
Obrázek 4.4: Komponenty chefu [25]
4.1.1 Workstations
Jako workstation je možné si představit počítač, který je specificky uzpůsoben ke konfigurování a spouštění nástrojů obsažených v prostředí Chefu. Nástroje Chefu jsou ovládány skrze příkazový řádek, přes který je možné synchronizovat repozitáře a cookbooks na Chef serveru dále komunikovat s uzly nebo aplikace v Chefu.
Chef obsahuje mnoho použitelných nástrojů, které jsou obsaženy v tzv. Chef de- velopmeng kit, tento balíček podporuje integraci a tzv. unit testing, dále definuje pracovní postupy a bezpečnostní politiky, které je nutné dodržovat při tvorbě Co- okbooks. Chef sám o sobě nedokáže kontrolovat kroky, které jsou spojeny s jeho implementací. Pokud tedy má dojít k nějaké interagci na vzniklou chybu řídí se svým výchozím nastavením, které lze bez sebemenších problémů změnit [5].
22
Chef developmeng kit obsahuje tyto nástroje:
• Chef-client
• Chef
• Ohai
• Chef-zero
• nástroje podporující Unit testing jako např: ChefSpec, Kitchen, apod.
• Soubory obsahující bezpečností politiky a implementační standarty
• Chef provisioning
Ne všechny z výše uvedených nástrojů jsou použity na workstation PC. Mezi využívané nástroje patří [5]:
Chef Jedná se o nástroj, který slouží pro práci s položkami v chef-repo, kde jsou primírně cookbooks uloženy.
Knife Tento nástroj je obdobou nástroje Chef a slouží pro interakci s objekty či uzly Chefu.
Chef-repo Úložiště, ve kterém jsou Cookbooks uloženy, další důležitou funkcí je jejich údržba a testování.
• Cookbooks obsahují recepis, atributy, definice, šablony, testy, apod.
• Chef-repo by měl být synchronizován
ChefSpec Slouží k simulaci chování v rámci Chef Node. Jedná se o nejrychlejší cestu, jak testovat funkčnost zroje a recipes.
Kitchen Použití spočívá v automatickém testování dat v libovolné kombinaci.
4.1.2 Cookbooks
jsou hlavním stavební jednotkou Chef infrastruktury, jejich obsah tvoří základní konfigurace a bezpečnostní mechanismy, které definují vše, co je potřebné ke správ- nému nasazení, přesněji se jedná o:
• Recepis (popisuje prostředky a jejich pořadí v jakém mají být použity)
• Hodnoty atributů
• Distribuce souborů
Chef-client je napsán v jazyce ruby, ten je určen jako referenční jazyk pro vytváření cookbooks a definování recipes jako rozšíření o DSL pro konkrétní zdroje [5].
Složení Cookbooks:
Atributy Atributy slouží ať v Cookbooks či recipes ke změnám vychozího nastavení uzlu. Při načítaní Chef-clienta na uzlu jsou jeho hodnoty porovnány s hodnotami v atributech, a v případě nutnosti jsou nahrazeny. Každá Cookbook má atributy uloženy v souborech, první se načte default.rb další soubory jsou načteny (pokud jsou k dispozici) v lexikografickém pořadí. [5]
Definice Definice je kód, který je používán skrze všechny recipes v rámci jedné Cookbooks jako makro. Definice je vytvořena pomocí libovoného kódu, který je zabalen do zdrojových souborů chef-clienta. Definice se chová podobně jako atributy, ale jsou zde jisté rozdíly [5]:
• Definice neobsahuje definici výpočetních zdrojů
• soubor je uložen v adresáři /definitions.
• Je spuštěn ještě před samotným chef-clientem
Soubory slouží pro přenos z podadresáře Cookbook_Name/files. Na této cestě jsou umístěny soubory, které spouští Chef-client. Soubory jsou spouštěny na základě názvu hostitele, použitého OS, či tak jak je to vhodné. Soubory jsou umístěni v podadresáři Cookbook_Name/files/default. [5]
Knihovny umožňují zahrnut libovolný kód psaný v ruby do Cookbook, a to buď jako extension, které je spouštěné v rámci Chef-clienta, nebo jako zcela novou funkci.
Soubory jsou umístěny v podadresáři /library [5]
24
Metadata Obsah souboru s metadaty slouží k analýze pro Chev server, jestli je použitá Cookbook na každém uzlu správně implementována. Samotná metadata se ukládají do souboru metadata.rb. [5]
Recipes Pokud je Cookbook základní stavebním kamenem tak recipes jsou základ- ní konfigurační částí. Recipes je stejně jako Cookbooks napsaný v jazyce ruby, dále vymezuje potřebné věci nutné ke konfiguraím částí systému. Recepis nemůže existo- vat mimo Cookbook, ale v rámci jedné Cookbook může být spojeno více recepis do jednoho. Recepis musí být vždy přídán do run-listu, aby mohl být používán Chef- clientem. Pořadí, ve kterém jsou recepis spouštěni závisí na pořadí v jakém jsou uloženy v run listu. [5]
Chef-client spustí recepis pouze na vyžádání. Pokud by nastala situace kdy, chef- client spustí recepis více než jednou, tak i přesto výsledný systém vždy stejný. [5]
Resources (Zdroje) jsou důležité k pro nasazení konfigurační politiky, která:
• Popisuje stav položky konfigurace
• Deklaruje kroky nutné k uvedení do požadovaného stavu
• Určuje zdrojový typ souborů (package, Templates, services)
• Jsou seskupeny do recepis popisujících potřebnou konfiguraci
V případě, že zdroj představuje část systému, poskytovatel služby potom definuje kroky nutné k provedení do požadovaného stavu. [5]
Template Jako template označíme rozšířený ruby kód, který je použit ke gene- rování statického textového souboru. Teplates jsou výborným nástrojem k editaci konfiguračních souborů. Rozšířené ruby soubory (ERB), které jsou označovány za templates jsou umístěny v Cookbook_name/templates [5]
Testy Testování Cookbooks zvyšuje jejich kvalitu tím, že zajistí aby jejich funkč- nost byla přesně taková jakou autor zamýšlel. Cele testování probíhá formou unit testů, které se provádějí skrze nástroje [5]:
• Kitchen
• ChefSpec
4.1.3 Nodes - Uzle
Pod uzlem si lze představit jakékoliv zařízení (ať virtuální či fyzické), které je spra- vováno pomocí Chefu.
Typy nejčastěji používaných zařízení (služeb) jsou následující [5]:
• Server
• Cloud
• VM
• Síťové zařízení
Jedná se o síťová, která je možné konfigurovat (např.: Arista, Cisco, Jupiter Networks).
• Docker
Mezi komponenty uzlů, které jsou přímo pod správou Chefu patří:
Chef client Chef client je provozován na každém uzlu, který je pod správou Chefu.
Při inicializaci Chef clienta dojde k provedení kroků, které jsou nezbytné k uvedení uzlu do požadovaného stavu. Mezi tyto kroky patří [5]:
• Registrace a autentifikace uzlu proti Chef serveru
• Synchronizace Cookbooks
• Změna atributů uzlu
Komunikace mezi uzlem a Chef serverem je Šifrována pomocí šifrovacího algoritmu RSA. Samotný veřejný klíč se používá pro autentifikaci uzlu, Chef server potom přidělí pouze ty data, které bezpodmínečně potřebuje. Chef server je schopen na základě klíče rozhodnout zda se jedná o registrovaný uzel, pokud ano je uzlu povolen přístup k datům, v opačném případě není uzel přidán do architektruy Chefu.[5]
Ohai Tento nástroj se používá ke zjištění jednotlivých atributů uzlu. Ohai běží od chvíle, kdy byl na uzlu poprvé inicializován Chef client, jedná se přímo o komponentu Chef klienta. Mezi informace, které Ohai zpracovává patří:
• údaje o CPU
26
• využití sítě
• názvy domén
• podrobnosti o OS
• specifická nastavení OS
• etc.
Atributy, které Ohai pozoruje jsou porovnávány s hodnotami obsažených uvnitř Cookbooks. V případě odchýlení, od předepsaných hodnot, se Chef client postará o nápravu.
4.1.4 The Chef Server
Chef server funguje jako rozbočovač informací v rámci celé architektury. Jsou na něm uloženy veškeré Cookbooks, bezpečnostní politiky týkající se uzlů a metadata popisující každý registrovaný uzel, dále na vyžádání (Chef clineta) rozesílá potřebné informace (např: Cookbooks) potřebné ke konfiguraci uzlu.[5]
Hledání v Chef severu
Další z primárních vlastností Chef serveru je řízení uzlů, k tomu je využíváno webové rozhraní, skrze které je možná úprava těchto objektů jako jsou:
• uzle
• typy uzlů
• změna bezpečnostních politik
• změna přístupových údajů k Chef serveru
• Data bag
Data bag Data bag je globální proměnná ve formátu JSON a je přístupná pouze ze Chef serveru. Obsahem této proměnné je indexován a může bát nahrán jako recipe nebo je použit během vyhledávání. [5]
Bezpečnostní politiky (opatření)
Bezpečnostní politiky určují proces mapování operačních závislostí na objekty, které jsou uloženy v Chef serveru. Mezi tyto závislosti patří:
• Definice typů uzlů (např: web server)
• Informace a hesla uživatelských účtů uložených v zabezpečené části chef ser- veru (přístupné z uzlu, kde proběhla autentifikace na základě správných SSL certifikátů)
• Editace a vytváření specifických Cookbooks, pomocí kterých jsou nasazována jednotlivá bezpečnostní opatření.
4.1.5 Analytics
Chef analitics je platforma poskytují v reálném čase přehled o všech možných změ- nách v rámci celé Chef architektury.[5]
Jak tomu již bývá u pokročilejších reportovacích systémů zvykem, je pouze na na administrátorovy, které upozornění bude chtít zobrazovat např [5]:
• stroje kde selhal Chef client
• upload Cookbooks na chef server
• zdroje, které byli aktualizovány za pomocí Chef clienta
Veškerá tato oznámění je možné zasílat emailem, či zobrazovat do chatovacích služeb (např: Slack, HipChat,…).
Reporty mohou být generovány jak pro celou architekturu tak i pro konkrétní uzly [5].
28
5 Puppet DB
Stejně jako u své konkurence kterou je Chef, je PuppetDB automatizační platformou.
Stále je jedno zda provoz probíhá na fyzických, virtuálních serverech či na cloudové infrastruktuře. Ve všech těchto případech je PuppetDB schopen celý proces nasazení, zprávy nebo údržby zautomatizovat, přičemž je úplně jedno jak je výsledný systém (síť) členitá. Jádro PuppetDB je psáno v jazyce Ruby, ale v praxi se požívá tzv.
”JRuby”. Různé konfigurační skripty, které se označují jako ”Moduly” a ”Manifesty”, jsou psané v jazyku DSL (z angl. domain specific language).
Rozdílů mezi Chefem a PuppetDB není mnoho, ale přeci se liší v přístupu ke svým uzlům. V případě Cheafa si uzly samy hlídají zda nedošlo ke změně Recepies, oproti tomu PuppetDB jak již z názvu je zřejmé své uzly ovládá, to znamená že nahrávání modulů a manifestů řídí master node [16].
Infrastruktura PuppetDB se skládá z:
• MCollecitove
• Hiera
• PuppetDB
• Puppet Dashboard
• The Foreman
• Geppetto
5.1 MCollective
Mariotte Collective, též známý jako MCollective. Jedná se o framework pro urče- ný pro správu serverů, které je potřeba orchestrovat, mězi jeho další použití patří paralelní spouštění systémů [17].
Mezi přednosti MCollective při práci s velkým počtem počítačů patří [17]:
• Pro účely vyhledávání počítačů se používá vyhledávání na úrovni metadat.
Jako zdroj dat slouží v tomto případě PuppetBD, popřípadě prohledává celou síť a seznam si tvoří sám.
• Místo pomalého přímého připojení na každý hostitelský počítač se pro pu- blikování či odběr používá mezi vrstva, která komunikuje se všemi počítači najednou
5.1.1 Možnosti MCollective
MCollective je určen pro správu počítačů/serverů v malých skupinách nebo na úrov- ni celého systému, kde je PuppetDB nasazen.
Každý zapojený server obdrží požadavky ve stejnou dobu, ale na reakci na po- žadavek (např.: update databáze) odpoví jen ty servery, kterých se dotaz týká, z těchto serverů je možné vybrat určitou skupinu, která má tento update provést. Dále je nutné, aby Puppet server znal konfiguraci každého uzlu. K tomu slouží nástroj s názvem Facter.
Je pouze na administrátorovi, jestli si napíše modul sám nebo použije něco, co již bylo vytvořeno komunitou. MCollective sám o sobě implementuje autentizaci SSL či RSA [17].
5.2 Hiera
Hiera je hlavní konfigurační nástroj postavený tak, aby se uzel (loutka) dal snáze snáze konfigurovat bez použití opakujících se kroků [18].
Uzly mohou požadovat jakékoliv údaje, které jsou potřeba k jeho správnému chodu. Hiera tyto informace nejen získává, ale také tyto informace na vyžádání dále poskytuje. Samotnou konfiguraci uzlů ulehčuje [18]:
• snadné přepsání výchozích dat
• bezproblémové opětovné používání modulů, není nutné modifikovat kód, stačí dát nová data Hiere, ta je zpracuje a dostatečně upraví
• Snadnější publikování vlastních vytvořených modulů
30
5.3 Puppet Dashboard
Jedná se webový interface určený ke správě Puppetu. Je možné skrze něj provádět analýzu zasílaných reportů, upravovat parametry uzlů a v neposlední řadě provádět obnovu dat.
Puppet Dashboard (stejně jaký samotný Puppet) je napsán v ”Ruby on Rail”.
Díky tomu je možné Puppet Dashboard provozovat na většině dnešních unixových systémech, ale pro jeho chod je nutné doinstalovat [19]:
• RubyGems
• Rake
• MySQL
• Ruby-MySQL
Po kompletní instalaci je možné Puppet spravovat skrze následující prohlížeče:
• Chorme (libovolná verze)
• Firefox od verze 3.5 a vyšší
• Safari od verze 4 a vyšší
• Internet Explorer od verze 8 a vyšší
5.4 The Foreman
Forem je open source projekt, který pomáhá správcům systému se správou serverů po celou dobu jejich existence. Foreman se používá nejen v PuppetDB, ale také v [27]:
• Chef
• Salt
• etc.
Jednoduše řečeno se používá tam, kde je důležité zautomatizovat opakující se úlohy, či v případě, kdy je nutné urychlit nasazení aplikací, či proaktivně řídit změny ve virtuálním prostředí.
Foreman je komplexní balík služeb pro administrátory. Poskytuje webový fron- tend, CLI a REST API, které slouží k vlastní customizaci.
Foreman se používá v distribucích RDO a Rhos (Red Hat OpenStack).
Při nasazení je možné [27]:
• Provádět update celé hardwarové infrastruktury
• Vytvářet a spravovat instance jak na soukromých tak veřejných cloudech
• Spravovat velké množství hostitelských strojů
• Docílit automatického vytvoření instalačního obrazu s cílem optimalizovat jeho nasazení
5.4.1 Architektura Foremana
Foreman obsahuje centrální prvek, který je odpovědný za poskytování služeb jako je například:
• webové GUI
• počáteční konfigurace hostitelských systémů
• etc.
V případě kdy je povolena bezobslužná instalace, je Foreman schopen celý proces plně automatizovat. Tím že instance Foremana je na každém hostitelském stroji, je možné se s nimi spojit prostřednictví tzv. ”Smart Proxy” [27].
32
Obrázek 5.5: Architektura Foremana [27]
5.5 Geppetto
Gepeto je integrovaná sada nástrojů, která má za cíl zjednodušit proces vývoje modulů a manifestů, slouží k validaci modulů a manifestů psaných v jazyce DSL.
Můžeme si položit otázku jak taková validace probíhá. Geppetto je jednodu- chý textový nástroj, který obsahuje sadu validátorů a analyzátorů kódů. Pro vyšší uživatelský komfort je Geppeto přístupný jako plugin do prostředí Eclipse [21].
6 Docker
Jedná se o opensource platformu určenou pro vývoj a spuštění aplikací. Docker je pro snadnou a rychlou implementaci aplikací. Díky dockeru je možné vytvořit aplikaci bez nutnosti správy potřebného množství hardwaru. Použití dockeru je v současné době dost oblíbené a často se jeho nasazení uvadí v souvislosti s DevOps.
Docker v sobě kombinuje jakou si virtualizační platformu, známou jako kontaj- ner (značně odlehčenou oproti klasickým VM), na které je možné spravovat svojí aplikaci. Dále je možné spojovat více kontajnerů do jednoho funkčního celku.
Jinak řečeno dává Docker vývojářům způsob spustit libovolnou aplikaci bez- pečně (především izolovaně) uvnitř kontejneru. V zásadě je možné provozovat více kontajnerů na jednom hostitelském systému. Samotný kontajner zatěžuje systém podstatně méně než běžná VM, z toho vyplývá vyšší účinnost použitého hardwaru.
[3][1]
Samotné použití Dockeru je vhodné pro:
• Distribuci rozpracované aplikace mezi různými týmy
• používání aplikace v produkčním prostředí, přičemž je jedno zda je aplikace spuštěna v lokální sítí čí cloudu.
6.1 Architektura Dockeru
Docker obsahuje dvě primární složky a to [2]
1. Docker (samotnou platformu kontejnerů)
2. DOcker Hub (SaS platformu pro sdílení a právu kontejnerů)
Samotná architektura je postavená na principu klient-server. Jako server zde slouží Docker Deamon, a ten sám obstarává provoz a distribuci kontejnerů. Oproti tomu Docker klinet slouží ke komunikace se serverem (s Docker deamonem). Docker deamonem a Docker client mohou na stejném systému, nebo je možné připojit
34
Docker klienta vzdáleně k Docker deamon. Docker klient a Docker deamon spolu komunikují prostřednictvím Rest API [2] [3].
Obrázek 6.6: Architektura Dockeru [26]
Docker Deamon Jak vidět na obrázku výše, Dokcer deamon je spuštěn na hosti- telském PC a uživatel s ním komunikuje prostřednictvím Docker klineta [2]
Docker klient Primární komunikační uživatelské rozhraní, které slouží k zadávání příkazů ke zpracování. Komunikace s Docker deamonem je obousměrná. [2]
6.1.1 Uvnitř Dockeru
Samotný docker je složen ze tří částí a to:
Docker images Jedná se o šablonu, která je určena pouze pro čtení. Samotná šablo- na může obsahovat nainstalovaný OS spolu s potřebnými aplikacemi (např: Ubuntu s Apache serverem). Images jsou pak použity k vytvoření kontejneru. Docker umož- ňuje snadné vytvoření, správu a stažení images.
Každý images je složen z mnoha vrstev. Docker využívá speciální systém souborů, označovaný jako Union, aby vše spojil do jednoho Docker image. Souborový systém union vytváří oddělené adresáře, označované jako brach (větvě). Jednotlivé větve jsou pak postupně transparentně překrývány až do doby, než je systém ucelený.
Pokud by někdy nastala změna jakékoliv z větví, tak není nutné znovu načíst celý images (jako v případě VM), ale je nahrazen (či přestavěn) pouze ten úsek, který byl změněn [2].
Docker registry Účelem registrů je držet informace o umístění a stavu images.
Docker registry mohou být jak veřejné tak i soukromé. Veřejné registry jsou pří- stupny prostřednictvím Docker Hubu. TO napomáhá znovu použitelnosti již vytvo- řených images, ať vašich či jiných vývojářů [2].
Docker kontejner Obsahují vše, co je potřebné k běhu provozovaných aplikací. Kaž- dý kontejner je pak vytvořen z Docker images a následně spuštěn. Lze jej prostřednic- tvím Docker klienta jednoduše pozastavit, vypout či smazat. Kontajner je izolovaný (zapouzdřený) od ostatních aplikací a kontajnerů. Samozřejmě toto zapouzdření je možné částečně vypnout, při propojování kontejnerů do jednoho funkčního celku, ale to je již čistě na zvážení vývojáře.
Mezi základní stavební kameny každého kontejneru patří použitý OS a přidaná meta-data. V závislosti na použitém Docker image vím co kontejner obsahuje a jaký proces je potřebné spustit. Samotná aplikační meta-data jsou přidána ve formě větví (z angl. branches) a celý postup začlenění je popsán výše [2].
6.1.2 Jádro Dockeru
Jádro Dockeru je napsáno v jazyce Go a ke svému správnému chodu je potřeba některých funkcí [2]:
Jmenné prostory Jmenné prostory jsou potřebné k poskytnutí izolovaného pro- středí. Při spouštění kontejneru Docker utvoří sadu jmenných prostorů. Vzniká tedy izolační vrstva, která zabraňuje komunikaci mimo vlastní jmenný prostor.
Kontrolní skupiny Jsou klíčové k běhu aplikace v izolovaném prostředí. Nejenže definují přístup k hardwarovým zdrojům, ale také umožňují jejich sdílení s jinými kontejnery a zároveň nastavení (např: určení priority, maximální velikosti, …).
Souborový systém Union Spadá pod rodinu souborových systémů Unionfs. Tato rodina souborových systémů je převážně využívána na Linuxových distribucích. Tím se dostáváme k faktu, že Docker je výhodné používat se OS na bázi unixu. Rozšíření pro OS x86 je v současné době možné a to jen intervenci Microsoftu.
36
Formát kontejneru Deafultní formá kontejneru je označován jako libcontainer. Dí- ky použitému souborovému systému Docker kontajner stejnou strukturu jako LXC.
V současné době se již pracuje na integraci jiných formátů kontejneru, jako například v OS BSD či Solaris Zone.
7 Aplikace platformy Chef
Pro samotnou práci je potřeba mít v systému nainstalovaný chef client. V případě OS ubuntu se instalace provádí skrze příkaz: sudo apt-get install chef. Spolu s chef clientem se nainstaluje překladač pro programovací jazyk ruby a to pomocí příkazu sudo apt-get install ruby.
Obrázek 7.7: Architektura Chefu [28]
V architektuře chef může workstation představovat jakýkoliv libovolný počítač.
Svým způsobem se jedná o decentralizovanou architekturu. Konfigurační soubor tzv.
Cookbook se dá nahrát přímo na node, ale výhodnější je nahrát cookbook na chef server, odkud si změnu stáhnou všechny nody sami.
38
7.1 Workstation
Pomocí workstationu je možné vytvářet konfigurační souboru, tzv. recipes, kde jde dále skládat do jednoho souboru tzv. cookbook.
Listing 7.1: Příklad recipes
apt_updte ’ Update t h e apt c a c h e f o r 24 hour ’ do f r e q u e n c y 86 _400
a c t i o n : ’ p e r i o d i c ’ end
pac kage ’ apache2 ’ s e r v i c e ’ apache2 ’ do
s u p p o r t s : s t a t u s => t r u e a c t i o n [ : e n a b l e , : s t a r t ] end
f i l e ’ / v a r /www/ html / i n d e x . html ’ do c o n t e n t ’<html>
<body>
<h1>H e l l o i ’m h er e </h1>
</body>
</html >’
end
Tento recipes slouží k instalaci a updatu služby apache. Údaj frequency nám říká po kolika sekundách se skript znova spustí. V místě action: periodic znamená, že bude skript pouštěn pravidelně, aniž by musel být spustěn chef-client. Toho by bylo docíleno pokud by místo klíčového slova periodic bylo použito slovo update.
Sekce package ’apache2’ nainstaluje samotnou službu a poslední část vytvoří novou stránku na adrese 127.0.0.1 (jinak známe jako localhost).
Pokud máme již takto vytvořený recipe. Je nutné přejít k vytvoření cookbook knife cookbook create cookbook_name.
Listing 7.2: Struktura cookbook a t t r i b u t e s
d e f i n i t i o n s f i l e s
d e f a u l t CHANGELOG. md
l i b r a r i e s metadata . rb p r o v i d e r s README. md
r e c i p e s
d e f a u l t . rb r e s o u r c e s
t e m p l a t e s
d e f a u l t
S vytvářením cookbook je nutné počítat, že při její aplikaci v infrastruktuře, může vyvstat problém, který může vést až k pádu celé infrastruktury. Z tohoto důvodu se zavádí tzv. unit testing, který probíhá skrze testovací framework kitchen.
7.1.1 Kitchen
Jak bylo zmíněno výše kitchen se používá pro testování cookbooks na libovolných datech a platformách.
Define kitchen se nachází v souboru .kitchen.yml. Tento soubor je vytvořen au- tomaticky, a to při vytvoření nové cookbook.
Samotné testování pobíhá na virtuálním stroji, který framework kitchen spustí pro potřeby testování. Je tedy nutné, aby workstation podporovala virtualizaci a měla v sobě naistalovaný patřičný hypervisor.
V mé diplomové práci jsem používal OS Ubuntu 14.04, do kterého bylo nutné doinstalovat programy
1. VirtualBox 2. Vargant
Pokud jsou již oba tyto programy nainstalované, a máme připravený cookbook k testování, tak dalším krokem je editace souboru .kitchen.yml.
40
Samotné testování probíhá v několika krocích:
1. kitchen create
v této fázi se vytvoří testovací VM s požadovanou konfigurací uvedenou v .kitchem.yml
2. kitchen converge
provádění požadované konfigurace uvedené v cookbook na VM 3. kitchen login
spuštění VM, dále probíhám přihlášení na VM skrze SSH 4. verify
manuální ověření požadované konfigurace 5. kitchen destroy
Vypnutí a zničení VM
Listing 7.3: Struktura .kitchen.yml d r i v e r :
name : v a g r a n t #nazev o v l d a c e s k r z e k t e r y s e p r i s t u p u j e k VM
p r o v i s i o n e r :
name : c h e f _ z e r o
p l a t f o r m s :
- name : ubuntu - 1 4 . 0 4 #v i r t u a l i z o v a n ý OS d r i v e r : #D e f i n i c e v l a s t n o s t i VM
c u s t o m i z e : #D e f i n i c e v e l i k o s t i pameti RAM memory : 256
s u i t e s :
- name : d e f a u l t r u n _ l i s t :
- r e c i p e [ motd_ubuntu : : d e f a u l t ] #v o l a n i cookbook
#( p r o v a d e n i r e c i p e s d e f a u l t ) a t t r i b u t e s :
7.2 Chef server
Nasazení a zprovoznění samotného chef serveru není o moc složitější než počáteční konfigurace chef-client. Jediné na co je nutné dát pozor je podporovaný OS. Dle dokumentace Chefu jsou je možné provozovat chef server pouze na linuxových sys- témech, přesněji na Ubuntu (od verze 10.04) a Red Hatu (od verze 5).
Po nainstalování je zapotřebí provést konfiguraci serveru. Toho bude docíleno změnou konfiguračního chef-server.rb souboru nacházející se v /etc/opscode/. Pro provedení konfiguračních změn stačí spustit příkaz sudo chef-server-ctl reconfigure.
Po jeho dokončení bude přístupné webové rozhraní chef serveru na adrese 127.0.0.1:80. Zvenčí bude administrace viděna pod IP adresou serveru. Po prvotní konfiguraci není schopen chef server prováděn žádné složité úkony, je nutné doin- stalovat nutné nástroje. Prvním z těchto nástrojů je chef-manage. V mé diplomové práci se vyskytl problém při instalaci této komponenty (instalace neprobíhala tak já bylo popsáno v dokumentaci, bylo nutné nainstalovat chef-manage z jiného zdroje).
Dalším nástrojem je opscode-reporting, tato komponenta obstarává reporting celého Chefu.
Na závěr je dobré zmínit, že server je nutné po každé instalaci nové komponen- ty rekonfigurovat za pomocí příkazu: sudo chef-server-ctl reconfigure, po opětovné konfiguraci severu je zapotřebí porvést konfiguraci nainstalovaného doplňku.
7.2.1 Párování Chef serveru s Uzlem
Pro správnou synchronizaci cookbook je nutné uzlovou stanici propojit s Chef ser- verem. V chef terminologii je toto spojení označováno jako tzv. bootstrap.
Před samotným pokusem o komunikaci, mezi serverem a uzlovým bodem, je potřeba vytvořit organizaci, pod kterou bude uzlový prvek spadat. Organizaci lze svým způsobem přirovnat k doméně používané v MS Active Directory.
Každá vytvořená organizace musí být navázána na existujícího uživatele, je tedy nutné nejprve založit uživatele a až poté vytvořit organizaci.
Listing 7.4: Příkaz sloužící k vytvoření uživatele sudo c h e f - s e r v e r - c t l u s e r - c r e a t e ADMIN_USER_NAME
ADMIN_FIRST_NAME ADMIN_LAST_NAME ADMIN_EMAIL ADMIN_PASSWORD - - f i l e n a m e ADMIN_USER_NAME. pem
42
Listing 7.5: Příkaz sloužící k vytvoření organizace sudo c h e f - s e r v e r - c t l org - c r e a t e ORG_SHORT_NAME ”
FULL_ORG_NAME” - - a s s o c i a t i o n _ u s e r ADMIN_USER_NAME
K provedení bootstrapingu je potřeba nástroj knife, který je součástí chef-clientu, ale pro jeho použití je potřeba získat konfigurační soubor knife.rb. Tento lze vyge- nerovat v administrátorském rozhraní chef serveru.
Komunikace uzlového bodu a serveru je zabezpečená šifrovacím algoritmem RSA.
Je tedy nutné vygenerovat veřejný klíč, který bude sloužit pro připojení uzlu k serveru. Veřejný klíč stejně tak jako konfigurační soubor nástroje knife je nutné vygenerovat. Oba vygenerované souboru je nutné uložit do složky .chef.
Stažené soubory je dobré uložit na místo, kde budou vždy k dispozici. V mém případě byly uloženy v /home/vojtech/chef/.chef. Dále je nutné zjistit zda je uzlový bod schopen navázat spojení se serverem. K tomu poslouží příkazy:
• knife ssl fetch
Příkaz slouží ke stažení ssl certifikátů
• knife check
příkaz sloužící pro kontrolu spojení se serverem
Celý tento postup je nutné aplikovat i v případě workstation PC a to z důvodu uživatelsky příjemnějšího nahrávání cookbook na chef server.
Pro účel názorné ukázky bude použita cookbook vytvořena v kapitole7.1. Samot- né nahrání tvoří příkaz knife cookbook upload COOKBOOK_NAME. Po nahrání cookbook na server již stačí ji přiřadit k uzlovému bodu pomocí příkazu knife boot- strap ADDRESS --ssh-user USER --ssh-password ’PASSWORD’ --sudo --use-sudo- password --node-name node1 --run-list ’recipe[COOKBOOK_NAME]’. Otázkou je jak bude probíhat update cookbook v případě její změny, v zásadě záleží jak je cookbook napsána, update může probíhat:
1. Periodicky 2. Kontinuálně 3. Manuálně
Bod číslo 1 a 2 je přímo přímo definován v cookbook. Jediným rozdílem může být běh chef-clienta, v případě kontinuálního updatu běží neustále, je tedy nut- né takovému uzlu přidělit více paměti RAM. Ruční update lze provést za pomocí příkazu knife ssh ADDRESS ’sudo chef-client’ --manual-list --ssh-user USER --ssh- password ’PASSWORD’.
44
8 Aplikace platformy PuppetDB
Stejně jako Chef je jádro PuppetDB napsáno v jazyce ruby, zde určitá podoba těchto platforem nekončí. Celou strukturu uzlů lze v podstatě rozdělit na dvě kategorie a to na master node a slaves node. Hromadné označení podřadných uzlů je zde oprávněně, v celé architektuře může být pouze jeden uzel jako master.
Pro svůj chod potřebuje PuppetDB, aby na každém slave nodu byl nainstalován puppet agent, dále musí v celé architektuře být přítomen puppet master, který je nainstalován na master nodu. Samotná databáze PuppetDB není pro provoz nut- ná, ale bez jejího použití by nešlo používat téměř všech pokročilých služeb, které PuppetDB nabízí.
Na master nodu vždy běží PuppetDB server, která má na starost získávání dat od slave uzlů, dále pak jsou v něm uloženy veškeré konfigurační soubory, které se v PuppetDB označují jako moduly a manifesty, přičemž modul se skládá z více manifestů.
Na straně podřízených uzlů běží tzv. puppet agent, který hlídá požadovanou konfiguraci na základě modulu, který byl uzlu přiřazen, narozdíl od chef-clienta se puppet agent spouští každých 30 minut, kdežto chef-client je spuštěn neustále.
V případě schody konfigurace uzlu se svým manifestem neprovádí puppet agent žádnou akci, v opačném případě nastane rekonfigurace uzlu dle nových parametrů
Ještě před samotnou instalací platformy, je nutné si uvědomit, že PuppetDB je možné provozovat ve dvou variantách, a to jako Open Source Puppet či Puppet Enterprise. Dá se říci, že největším rozdílem je přítomnost GUI ve verzi enterprise, i když je verze enterprise zpoplatněna, dá se zdarma použít ke správě infrastruktury o maximální velikosti 10 uzlů.
Obrázek 8.8: Jak puppetDB funguje
8.1 Puppet master
Při konfiguraci infrastruktury je dobré začít s konfigurací master nodu. V diplomové práci jsem použil verzi enterprise, jelikož se jedná o komerční software tak jeho in- stalační souboru přístupné skrze standartní linuxové repositáře. Ke stažení je nutná registrace na adrese https://goo.gl/bd7zC8.
Po spuštění instalačního souboru, je uživatel vyzván, aby pokračoval v instalaci skrze webové rozhraní, které běží na portu 3000 (vzorová adresa https://192.168.
22.130:3000). Po ukončení instalace je možné ovládat master node dvěma způsoby a to pomocí:
1. Konzole
2. Webového rozhraní (přístupné z IP adresy master nodu)
46
Listing 8.1: Instalace Puppet Enterprise Puppet E n t e r p r i s e v2016 . 1 . 2 i n s t a l l e r
Puppet E n t e r p r i s e d o c u m e n t a t i o n can be found a t h t t p : / / d o c s . p u p p e t l a b s . com/ pe / 2 0 1 6 . 1 /
- - - - STEP 1 : GUIDED INSTALLATION
B e f o r e you b e g i n , c h o o s e an i n s t a l l a t i o n method . We’ ve p r o v i d e d a few p a t h s t o c h o o s e from .
. . . . .
I n s t a l l i n g s e t u p p a c k a g e s .
P l e a s e go t o h t t p s : / / m a s t e r . l o c a l . c z : 3 0 0 0 i n your b r o w s e r t o c o n t i n u e
. . . .
8.2 Puppet agent
Z důvodu bezpečnosti ve firemních prostředích jsou instalační souboru puppet agen- ta staženy přímo z master nodu. V případě, kdy je puppet agent instalován na node se stejnou verzí OS, jako je na master nodu, stačí použít příkaz: curl -k https://master-hostname:8140/packages/current/install.bash | sudo bash. V přípa- dech kdy tomu tak není, je zapotřebí povolit instalaci agenta na straně master nodu, kde do políčka class je nutné zadat třídu odpovídající danému systému, v případě centOS 7 AMD64 je odpovídající třídou pe_repo::platform::el_7_x86_64 viz. ob- rázek 8.9.
Díky tomu, že se instalační soubory puppet agenta se stahují z repositářů master modu, je zajištěno automatické párování obouvou uzlů.
Komunikace mezi uzly je šifrovaná a běží na portu 22. SSL certifikáty jsou vytvo- řeny během instalačního procesu. Po dokončení instalace je nutné ověřit dostupnost master nodu to pomocí příkazu puppet agent -t, tento příkazu je nutné spouštět jako root. Mohou nastat případu kdy puppet agent nebude moci najít master node, v tom případě je nutné doplnít příkaz a parametr ”–servermaster-hostname” a jeho výsledná podoba by byla puppet agent --server master-hostname -t
V průběhu řešení diplomové práce jsem narazil na zajímavý problém. Parametr
master-hostname musí být uložemo na DNS, popřípadě stačí mít uložený záznam v /etc/hosts. Pokud záznam ani na jednom z výše jmenovaných nebude uveden, pak by někdo mohl nabýt předpokladu, že nahrazení master-hostname za jeho IP adresu bude fungovat, z mého testování vyplývá, že tento předpoklad je mylný.
Obrázek 8.9: Povolení instalace puppet agenta
8.2.1 Správa nodů
Na rozdíl od Chefu nemá puppetDB pevnou adresářovou strukturu základních kon- figuračním souborů, ty jsou v této architektuře označovány jako manifesty. Pokud je potřeba provádět více manifestů najednou, tak vzniklá struktura je označována jako modul.
Rozdíly mezi Chefem a PuppetDB zde nekončí. U Chefu nahrávání recipes a co- okbook probíhá ze speciální stroje, který je označován jako wokrstation, ze kterého je potom nutné provést nahrání na Chef server. PuppetDB prvek jako workstati- on ve své architektuře nemá. Vývoj manifestů a modulů může probíhat kdekoliv, ale díky vestavěnému analyzátoru jsou moduly a manifesty vyvíjeny přímo na mas- ter nodu. Veškeré již vytvořené moduly a manifesty musí být umístěny na adrese /etc/puppetlabs/code/environments/production/modules.
Samotné přiřazení probíhá vždy na úrovni master nodu. Změny v celé architek- tuře se projeví po 30 minutách, samozřejmě se dá tento interval obejít a změny
48
na slave nodu implementovat okamžitě, k tomu slouží již mnhokrát použitý výraz sudo puppet agent -t.
Manifest
Základní stavební položka PuppetDB. Manifesty stejně tak jako recepty jsou psá- ny v DSL. I když oba konfigurační soubory spojuje skriptovací stejný jazyk, jejich struktura je podobná, ale v určitých částech používá puppet odlišnou syntaxi viz.
následující příklad8.2.1.
Modul
Modul lze přirovnat k Cookbook. Jejich struktura je více méně stejná. Oproti Chefu neslouží k vytvoření modulu příkaz, takže celou tuto strukturu je potřeba vytvořit ručně.
Stejně jako cookbook obsahuje modul prvek, ve kterém dochází k inicializaci všech použitých manifestů. Tím to souborem je init.pp.
Listing 8.2: Struktura modulu
���
CONTRIBUTING . md���
e x a m pl e s���
i n i t . pp���
f i l e s ����
ht t p d ���
G e m f i l e ���
CHANGELOG. md���
checksums . j s o n ���
l i b ����
f a c t e r �����
a p a c h e _ v e r s i o n . rb . . . .
