Automated infrastructure
•Descargar como PPTX, PDF•
1 recomendación•787 vistas
Automated Infrastructure with Vagrant, Puppet and Docker by Laurynas Tretjakovas Learn the common pitfalls and challenges of manual infrastructure and how automated and versioned infrastructure can help you in continuous integration, continuous delivery and overall development process. The presentation will also cover some of the most common infrastructure examples when building and deploying Java application
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Automated infrastructure
Similar a Automated infrastructure (20)
Más de Kaunas Java User Group
Más de Kaunas Java User Group (13)
Último
Último (20)
Automated infrastructure
- 1. Automated Infrastructure Laurynas Tret jakovas laurynas.tret jakovas@gmail.com Kaunas Java User Group, 2014 1
- 2. Agenda • Manual Infrastructure vs Automated Infrastructure • Puppet • Docker • Vagrant • Demo • Q & A Kaunas Java User Group, 2014 2
- 3. Manual vs Automated Automated infrastructure has the following benefits: • Version control the configuration • Reusable • Cheaper for the organization • Provision a fleet of nodes with a single click • Works well with continious integration and delivery • New servers on demand – scalability • Smaller chance for human error • Is fun, motivates and creates a sense of accomplishment Kaunas Java User Group, 2014 3
- 4. Kaunas Java User Group, 2014 4
- 5. Puppet • Open source configuration management utility • Ensures that the node is in a defined state • Ruby DSL • Cross-platform • Agents can fetch configuration form the master • Enterprise edition is free if managing 10 or less nodes • Lots of modules in Puppet Forge Kaunas Java User Group, 2014 5
- 6. Puppet • Puppet configuration files are called manifests • Manifests do not apply actions from top to bottom, they use relationships to determine the order, in which the resources should be set up Kaunas Java User Group, 2014 6
- 7. Puppet Kaunas Java User Group, 2014 7
- 8. Kaunas Java User Group, 2014 8
- 9. Kaunas Java User Group, 2014 9
- 10. Kaunas Java User Group, 2014 10
- 11. Kaunas Java User Group, 2014 11
- 12. Puppet • Do not forget to define dependencies • Test your configuration with CI, use puppet parser validate and puppet-lint • Write module tests • Use puppet librarian to update and install modules • Manage node configuration with Hiera • Write classes and in the main fail only include the classes Kaunas Java User Group, 2014 12
- 13. Kaunas Java User Group, 2014 13
- 14. Docker • An open source platform for developers and system administrators to build, ship, and run distributed applications • “Dockerized” apps are portable and can run on most popular Linux distributions • On other OS, use boot2docker VM – a lightweight Linux distribution made specifically to run Docker containers • System administrators can use Docker to standardize development environments and abstract away differences in different OS distributions • Docker hub contains thousands of apps Kaunas Java User Group, 2014 14
- 15. Kaunas Java User Group, 2014 15
- 16. Docker Images Docker image is a read-only template. An image could contain an Ubuntu operating system with Tomcat and your web application installed. Images are used to create Docker containers. Docker provides a simple way to build new images or update existing images, or you can download Docker images that other people have already created. Docker images are the build component of Docker Kaunas Java User Group, 2014 16
- 17. Docker Registries Docker registries hold images. These are public or private stores from which you upload or download images. The public Docker registry is called Docker Hub. It provides a huge collection of existing images for your use. These can be images you create yourself or you can use images that others have previously created. Docker registries are the distribution component of Docker Kaunas Java User Group, 2014 17
- 18. Docker Containers Docker containers are similar to a directory. A Docker container holds everything that is needed for an application to run. Each container is created from a Docker image. Docker containers can be run, started, stopped, moved, and deleted. Each container is an isolated and secure application platform. Docker containers are the run component of Docker Kaunas Java User Group, 2014 18
- 19. Docker Images • Image name pattern – vendor/imageName:tag • Each image starts from a base image, for example a base Ubuntu image • Each image consists of a series of layers that are combined into a single image, every change to an image is a new layer, which can be saved as a new image • Docker images can be built by hand or by using a Dockerfile with a set of instructions Kaunas Java User Group, 2014 19
- 20. Docker Containers • Running a command from an image creates a container. After that command exits, container stops • One container should only do a single thing, don‘t run an ssh service • Upstart does not work in containers • To share data between containers create data volumes and mount them into containers Kaunas Java User Group, 2014 20
- 21. Docker Containers • Containers get an IP from a pool, there is no way to explicity assign an ip • Use –p flag to forward ports when starting a container • To access one container from the other, you have to link them: docker run -d --name web --link db:db training/webapp • Linked container‘s IP is available from the hosts file Kaunas Java User Group, 2014 21
- 22. Ubuntu with Oracle JDK Kaunas Java User Group, 2014 22
- 23. Tomcat 8 Kaunas Java User Group, 2014 23
- 24. Web Application Kaunas Java User Group, 2014 24
- 25. Docker • Group common commands into a single statement, so only one layer is created • Install with --no-install-recommends • Don‘t overwrite existing tags, use new ones each time so you can fall back easily • Use automated builds in the hub • Avoid private registries as Docker Hub server files over a cdn Kaunas Java User Group, 2014 25
- 26. Kaunas Java User Group, 2014 26
- 27. Vagrant • Create VMs locally for development • Portable and version controlled configuration • Replicate production environment • Every team member has the exact same setup • No more “works on my machine” • A place to test your automated infrastructure scripts • Has plugin API • Provisioning with Puppet, Chef, Ansible and more Kaunas Java User Group, 2014 27
- 28. Vagrant • Install Virtualbox or other VM provider • Install Vagrant • Create Vagrantfile with configuration • Base boxes are available from vagrant cloud • vagrant up Kaunas Java User Group, 2014 28
- 29. Vagrant • Vagrant can automatically build and run docker images for you • You do not save much from this, but it can spin up a boot2docker VM if your host OS does not support docker Kaunas Java User Group, 2014 29
- 30. Vagrant Kaunas Java User Group, 2014 30
- 31. Vagrant Kaunas Java User Group, 2014 31
- 32. Vagrant • Use shell provisioning to install and run Puppet • Use NFS file shares on Linux hosts • Do not write to shared folders, it is slow • On Windows hosts, even reading from shared folders can be slow, so avoid doing that as much as you can Kaunas Java User Group, 2014 32
- 33. Demo Kaunas Java User Group, 2014 33
Notas del editor
- Kalbėsiu apie: Rankomis valdomą infrastruktūrą ir jos minusus, Automatinę infrastruktūrą ir jos pliusais/minusais Tuomet konkrečiai pašnekėsiu apie keletą automatinės infrastruktūros įrankių: Vagrant, Puppet ir Docker. Tuomet parodysiu demo su Docker ir kaip jame paleisti java aplikaciją. Apie kiekvieną iš šių technologijų atskirai galima padaryti po prezentaciją, todėl šiandien paliesime tik patį paviršių ir svarbiausius dalykus.
- Jeigu infrastruktūrą yra automatinė, tai reikia kažkokio būdo kaip tą infrastruktūrą aprašyt. Jeigu turim kaip ją aprašyt, reiškias galim ir versijuot. O jeigu galim versijuot tai galim ir atrevertint esant reikalui. Galima pernaudot pilnas konfiguracijas ar jos dalis. Pvz turite konfigūracijos modulius Javai, Tocmatui, Jboss. Kitam projektui prireikė naujų aplinkų, bet tik su Java, Paėmėt Java modulį ir paleidot ant naujų serverių, viskas. Automatinė infrastruktūrą yra pigiau. Tarkime turime organizaciją užsiemančia smulkiais projektais. Kiekvienam projektui turi DEV, TEST, PROD aplinkas, load balancerius ir keletą duomenų bazių. Labai nesunkiai serverių skaičius gali išaugti iki 100 ir tai tikrai nėra daug. Jeigu rankomis valdotę infrastruktūrą, praktiškai kiekvienam iš projektų reikės dedikuoto žmogaus aplinkoms valdyti. Jeigu neturėsi kiekvienam atskirai, tai gali turėt bendrai kokius 10 100 serverių, arba vieną žmogų keliems projektams, bet dažniausiai nutinka taip, kad tų žmonių vistiek neužtenka ir darbai stringa, ypač atsiradus naujoms saugumo spragoms, kurios pastaruoju metu tikrai padažnėjo. Kaip buvo su shellsock. Tik paskelbė apie tai, visi pradėjo exploitinti per botnetus, paleidinėti vulnerability scannerius, į tokias spragas reikia labai greitai reaguoti. Rankinėje infrastruktūroje administratoriai eis per kiekvieną serverį ir updatins bash‘ą, o projektų darbai tuo metu lauks. Su automatine infrastruktūra galima turėti vos keletą žmonių, kurie spės padaryt darbus. Iš pradžių gali būt sunkiau, bet poto kai jau turės daug pernaudojamų dalių, bus žymiai greičiau ir paprasčiau. Taip pat galima valdyti userių roles, kiekviename serveryje rankomis nekurti userių. Kaip ir minėjau ankščiau, galimybė vienu kartu visiems serveriams ar serverių grupei atlikti kažkokius pakeitimus ir nesijungiant ir nesitreliojant su kiekvienu atskirai. Galima automatiškai konfigūruoti naujos jenkins slaves. Naują serverio konfigūracija tampa visos aplikacijos deliverinimo etapu. Taip pat automatinės infrastruktūros sistemos labai gerai veikia kartu su monitorinimo sistemomis. Jeigu jūsų visi serveriai cloud‘e, jūs galite labai lengvai paprašyti naujo serverio arba esamus pašalinti. Amazon AWS leidžia monitorinti trafficą ir pasiekus tam tikrą lygį, pridėti naujų serverių į stacką. Automatinė infrastruktūros sistema tada tą serverį sukonfigūruoja ir ideda ten aplikaciją. Naudojant kažkokia kitą cloud sistema galima pasileisti kokią kitą monitorinimo sistemą ir serverius kurti per API callsus. Kuo daugiau žingsnių reikia atlikti rankomis, tuo didesnė tikimybė, kad bus padaryta kažkokia klaida. Su atuomatine infrastruktūro taip nebus, jeigu buvo ištestuota. Ir toks taip vadinamas added bonus tai, kad tai yra žymiai įdomiau, linksmiau ir svarbiausia – motyvuoja. Tai tokį nuobodų darbą kaip serverių administravimas gali padaryt įdomų ir patiems programuotojams. O kai kažką tokio padarai tai ir pats jauti pasitenkinimą.
- Visų pirma, yra ir kitų alternatyvų. Būtinai pasidomėkite apie Chef ir Ansible. Pasakoju apie puppet nes kolkas tik su juo turiu patirties. Tai puppet yra open source mašinų konfigūravimo sistema. Tai iš pradžių reikia suprasti kaip tokios sistemos skiriasi nuo paprastų shell scriptų. Su shell scriptais taip pat galima iki tam tikro lygio automatizuoti infrastruktūrą. Tačiau naudojant shell scriptus, tu aprašai ką reikia padaryti, pvz įrašyk man duombazė, tada užkelk tokius duombazės konfigūracijos failus, tada įrašyk man tomcat‘ą, tada dar kažką ir dar kažką... Tačiau tokie dalykai labai greitai griūna kai bandai tą patį reikalą paleisti antrą kartą. Esant paprastiems install komandoms tai nepasijaučia, bet sudėtingesniai scenarijais jau reikia tikrinti ar scriptas leidžiasi pirmą kartą ar ne. Tai va, shell scriptams reikia pasakyti ką daryti, o puppetui tu sakai kokiam state turi būti mašina. Reiškias tu sakai, kad tau reikia duombazės su tokia ir tokia konfigūracija ir tomcato, tada jeigu pirmą kartą paleisi viską surašys. Jeigu antrą kartą paleisi jau nieko nedarys. Jeigu rankom prikeitaliosi duombazės konfigus, tai vėl paleidus jis tau tik configus pakeis į tuos kuriuos aprašei. Žodžiu užtikrina mašinos state‘ą. Ir toks dalykas yra netgi žymiai skaitomesnis, nes tau nebereikia skaityt ką shell scriptas daro ir koks viso to yra tikslas ir koks bus rezultatas, iš puppet manifestų viskas labai aiškiai matosi. Naudoja Ruby DSLą Veikia ant populiariausių linux distribucijų, taip pat ir ant windowsų. Paprastai manifestai turi būti tame pačiame serveryje kuris bus konfigūruojamas. Reiškias prieš tai į serverį reikia įrašyti puppet, ten sukelti failus ir paleisti komandą, tačiau galima sukonfigūruoti ir master serverį. Master serveris saugos visas agentų konfiūracijas ir kompiliuos manifestus, o agentai paprašys konfigūracijos ir masteris pats susigaudys kurią konfiguraciją jam reikia grąžinti. Agentas tuomet įsivykdis tuos skriptus. Pats puppet yra open source, tačiau yra ir enterprise versija. Enterprise versisjoje pagrinde yra WEB UI, kuriame galima matyti master serverius ir visus agentus, taip pat kada ten buvo paskutinį kartą provisioninta ir panašiai. Daugumai dalykų jau yra parašyti moduliai ir patalpinti į puppet forge, kuriuos tereikia parsisiųsti.
- Primenu, kad manifeste nevyksta reikalai nuo viršaus į apačią, nepamirškit nurodyti ryšius Konfigūracijai galima pakurti ci, kuris kiekvieno commito metu, paleistų parserį ar sintaksė validi ir praneštų apie puppet-lint klaidas ir warningus Įmanoma testus rašyti, gal šiek tiek per daug laiko užimti, nes dauguma dalyku sunku patestuoti realiai nepaleidus ir nepacheckinus kas įvyko Norint pasiimti modulį iš puppet forge, reikia rašyti puppet module install arba naudoti puppet librarian. Puppet librarian iš nurodyto failo parsiųs modulius į katalogą arba atnaujins. Poto paleidžiant puppet reikia nurody dvi modulių direktorijas – savo parašytų ir kur librarian updatina Naudokit Hiera. Hiera yra key value storage‘as konfigūracijai. Reiškias kiekvienas nodas gali turėti konfigus, su tais pačiais raktais, bet skirtingom reikšmėm. Tada manifestuose juos galima naudoti ir turėti tik vieną manifesto faila vienai mašinų grupei.
- Dockeris yra opensourcinė linux konteinerių sistemą. Supakuoji aplikaciją į docker konteinerius ir poto gali leist kur nori ant daugumos linux distribucijų Jeigu ant jūsų os dockeris neveikia, galima paleisti ant VM. Boot2docker ~30MB ir užsikrauna per ~5sec Galima naudoti dockerį visų aplinkų standartizavimui. Kiekvienas docker image‘as turi turėti base image, pagrindą. Toks pagrindas gali būti standartizuotas įmonėje. Jeigu pasikeičia pagrindas, poto daug darbo nereikia, kad ant najo viską perdaryt Yra docker hub kur jau yra dockerizuota daug aplikacijų, yra tomcatai jbosstai ir tt, duombazės įvairios. Tokias duombazes labai patogu naudot dirbant lokaliai
- Docker image‘ai turi būti atitinkamai pavadinti, va paternas. Lokaliai galima kaip nori vadint, bet pushinant į registrą reikia šito laikytis Viskas turi turėti base image Kiekvienas pakeitimas image sukuria naują sluoksnį, visi sluoksniai yra sujungiami, kad gauti image. Padarius kažkokį pakeitimą į image, turi gali toliau ir seną turėt ir naują išsisaugot su tuo pakeitimu Image galima ranka sudaryt ir poto išsaugot arba iš failo, perduodant instrukcijas
- Kai ant image paleidi komandą, pradeda veikti konteineris, tai kaip VM jau, kai ta komanda baigiasi, konteineris irgi nustoja veikti. Konteineriai turi daryt vieną ir vienintelį dalyką. Jeigu ant jo paleidot ssh servisą ir poto jungiatės per ssh, kad daryt dalykus tai jau blogai, taip pat ten neveiks upstarst ir kiti servisai, reikia leisti executables Kadangi pasibaigus komandai nutrūksta ir konteineris, reikia kažkaip persistinti duomenis. Tam yra data containers kuriuos poto galima mountinti į kitus konteinerius
- Vagrantas pagal nustatyta konfigūracija sukuria virtualią mašiną arba mašinas jeigu reikia clusterio. Konfigūracija yra versijuojama ir visi komandos nariai turi vienodą setupą. Tai yra didelis privalumas sprendžiant kažkokias problemas. Taip pat, jeigu projekte atsiranda naujas dependencis, jį sukonfigūruoti užtenka vienam komandos nariui, kitas tiesiog atsinaujins repositoriją ir gaus pakeitimus į virtualią mašiną. Tai gera proga replikuti production environentą. Reiškias jūs galite pasikelti su ta pačia linux distribucija ir versija, ten surašyti tos pačios versijos application serverius ir tt. Tai smarkiai sumažina šansą, kad productione kažkas neveiks. Na ir žinoma nenėra tokiu pasiteisinimų, kad pas mane lokaliai viskas veikė.
- Vagrantas pagal nustatyta konfigūracija sukuria virtualią mašiną arba mašinas jeigu reikia clusterio. Konfigūracija yra versijuojama ir visi komandos nariai turi vienodą setupą. Tai yra didelis privalumas sprendžiant kažkokias problemas. Taip pat, jeigu projekte atsiranda naujas dependencis, jį sukonfigūruoti užtenka vienam komandos nariui, kitas tiesiog atsinaujins repositoriją ir gaus pakeitimus į virtualią mašiną. Tai gera proga replikuti production environentą. Reiškias jūs galite pasikelti su ta pačia linux distribucija ir versija, ten surašyti tos pačios versijos application serverius ir tt. Tai smarkiai sumažina šansą, kad productione kažkas neveiks. Na ir žinoma nenėra tokiu pasiteisinimų, kad pas mane lokaliai viskas veikė.
- Pradžiai reikia labai nedaug, įsirašyti Virtualbox ar kitą VM providerį, tiesa vagrant su Vmware integracija yra mokamas, įsirašyti vagrantą, sukurto konfiguracijos failą ir parašyti vagrant up. Konfigūracijos failą dėti kartu su projektu ir commitinti. Vagrant cloud turi labai daug base boxu pradžiai. Dažniausiai žmonės ima base ubuntu/debian su įrašytu puppet ar chef.
- Pradžiai reikia labai nedaug, įsirašyti Virtualbox ar kitą VM providerį, tiesa vagrant su Vmware integracija yra mokamas, įsirašyti vagrantą, sukurto konfiguracijos failą ir parašyti vagrant up. Konfigūracijos failą dėti kartu su projektu ir commitinti. Vagrant cloud turi labai daug base boxu pradžiai. Dažniausiai žmonės ima base ubuntu/debian su įrašytu puppet ar chef.
- Galima iškart paleisti puppetą, bet per shellą geriau, nes prieš tai galima atnaujinti patį puppetą ir jo modulius Aš rekomenduočiau viską ko reikia projektui sukompiliuoti turėti lokaliai, o viską ko reikia paleidimui – vagrante. Tuomet .war‘ą pasiekti per shared folderius ir įsikopijuoti lokaliai