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
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
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
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
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
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
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
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
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