Koti › neuvoja › Master of puppets: Puppet-etäkokoonpanonhallintajärjestelmän asennus ja konfigurointi. Master of puppets: Puppet-etäkokoonpanonhallintajärjestelmän asennus ja konfigurointi Nukke asennus

Master of puppets: Puppet-etäkokoonpanonhallintajärjestelmän asennus ja konfigurointi. Master of puppets: Puppet-etäkokoonpanonhallintajärjestelmän asennus ja konfigurointi Nukke asennus

Käyttääksesi Puppetia tehokkaammin sinun on ymmärrettävä, miten moduulit ja manifestit rakennetaan. Tämä opetusohjelma opastaa sinut läpi, kuinka nämä Puppet-komponentit toimivat asettamalla LAMP-pinon Ubuntu 14.04 -palvelimelle.

Vaatimukset

Puppetin asennus (mestari ja agentti). Lisää tästä -.
Mahdollisuus luoda vähintään yksi Ubuntu 14.04 -virtuaalipalvelin palvelemaan Puppet-agenttisolmua.

Nukkekoodin perusteet

Resurssit

Nukkekoodi koostuu pääasiassa resursseista. Resurssi on koodinpätkä, joka kuvaa järjestelmän tilaa ja määrittää sen tarvitsemat muutokset. Esimerkiksi:

user("mitchell":
varmista => läsnä,
uid => "1000",
gid => "1000",
shell => "/bin/bash",
home => "/home/mitchell"
}

Resurssiilmoitus on seuraavassa muodossa:

resurssi_tyyppi("resurssin_nimi"
attribuutti => arvo
...
}

Voit tarkastella kaikkia Puppet-resurssityyppejä antamalla komennon:

nukkeresurssi --tyypit

Saat lisätietoja resurssityypeistä tästä oppaasta.

Manifestit

Manifesti on orkestrointikäsikirjoitus. Nukkeohjelmia, joiden laajennus on .pp, kutsutaan luetteloiksi. Puppetin oletusluettelo on /etc/puppet/manifests/site.pp.

Luokat

Kuten kaikilla tavallisilla ohjelmointikielellä, luokat ovat vastuussa orkestroinnin osien järjestämisestä ja uudelleenkäytöstä.

Luokan määritelmässä on koodilohko, joka kuvaa luokan toimintaa. Kun olet määrittänyt luokan, voit käyttää sitä luetteloissa.

Luokkamäärittelyllä on seuraava muoto:

luokka esimerkki_luokka(
...
koodi
...
}

Tämä koodi määrittelee luokan example_class. Puppet-koodi on aaltosulkeissa.

Luokkailmoitus on paikka koodissa, jossa tiettyä luokkaa kutsutaan. Luokkamäärityksellä Puppet käsittelee koodinsa.

Luokkailmoitus voi olla tavallinen ja resurssityypin mukaan.

Tavallinen luokkailmoitus lisätään koodiin sisällyttämällä avainsana.

sisältää esimerkki_luokka

Kun luokka ilmoitetaan resurssityypiksi, se ilmoitetaan resurssimuodossa:

class("esimerkki_luokka":)

Tämän ilmoituksen avulla voit lisätä koodiisi luokkaparametreja, jotka ohittavat luokkaattribuuttien oletusarvot. Esimerkiksi:

solmu "host2" (
class ("apache": ) # käytä apache-moduulia
apache::vhost ( "example.com": # määrittele vhost-resurssi
portti => "80",
docroot => "/var/www/html"
}
}

Moduulit

Moduuli on joukko luetteloita ja muita tiedostoja, jotka on järjestetty ennalta määritetyllä tavalla, mikä tekee orkestroinnin yksittäisten osien jakamisesta ja uudelleenkäytöstä helppoa. Moduulit auttavat järjestämään Puppet-koodia, koska niitä voidaan käyttää koodin erottamiseen useiksi luetteloiksi.

Puppet-moduulit on tallennettu /etc/puppet/modules-hakemistoon.

Manifestin kirjoittaminen

Voit harjoitella Puppet-luetteloiden, moduulien ja luokkien kirjoittamista käyttämällä esimerkkiä LAMP-pinon asentamisesta Ubuntu-palvelimelle (tuloksena on ).

Joten Ubuntu 14.04 -palvelimen organisoimiseksi ja LAMP-pinon asentamiseksi siihen tarvitset resursseja seuraaviin toimiin:

apache2-paketin asentaminen.
apache2-palvelun käynnistäminen.
paketin asennus MySQL-palvelin, mysql-palvelin.
mysql-palvelun käynnistäminen.
php5-paketin asennus
PHP-testiohjelman luominen, info.php.
apt-indeksin päivittäminen ennen kunkin paketin asentamista.

Alta löydät kolme esimerkkiä Puppet-koodista, joita voidaan käyttää tällaisen LAMP-pinon asennukseen.

Ensimmäinen esimerkki opettaa sinulle, kuinka perusluettelot kirjoitetaan yhteen tiedostoon. Toinen esimerkki auttaa sinua kokoamaan ja käyttämään luokkaa ja moduulia aiemmin kirjoitettujen luetteloiden perusteella. Kolmas esimerkki näyttää, kuinka voit käyttää valmiita julkisia moduuleja LAMP-pinon asentamiseen.

Huomautus: Testaukseen on parempi käyttää uutta virtuaalipalvelinta.

Esimerkki 1: LAMP:n asentaminen yhdellä luettelolla

Puppet-luettelo voidaan kirjoittaa agenttisolmuun ja suorittaa sitten käyttämällä puppet apply -komentoa (sinulla ei tarvitse olla master- ja agenttiasetuksia tehdäksesi tämän).

Tässä osiossa opit kirjoittamaan luetteloita, jotka käyttävät tämäntyyppisiä resurssiilmoituksia:

exec: Suorita komennot.
paketti: asenna paketit.
palvelu: palvelunhallinta.
tiedosto: tiedostonhallinta.

Luettelon luominen

Luo uusi luettelo:

sudo vi /etc/puppet/manifests/lamp.pp

Lisää siihen seuraava koodi ilmoittaaksesi tarvittavat resurssit.

# suorita "apt-get update" -komento
exec("apt-update": # resurssi exec "apt-update"
komento => "/usr/bin/apt-get update" # komento, jonka tämä resurssi suorittaa
}
# asenna apache2-paketti
paketti("apache2":
request => Exec["apt-update"], # pyydä "apt-update" ennen paketin asentamista
varmista => asennettu,
}
# käynnistä apache2-palvelu
service("apache2":
varmista => juokseminen,
}
# asenna mysql-server
paketti ("mysql-server":
request => Exec["apt-update"], # pyydä "apt-update" asentamalla uudelleen
varmista => asennettu,
}
# käynnistä mysql-palvelu
service("mysql":
varmista => juokseminen,
}
# asenna php5-paketti
paketti("php5":
request => Exec["apt-update"], # pyydä "apt-update" ennen asennusta
varmista => asennettu,
}
# käynnistä info.php-palvelu
file("/var/www/html/info.php":
varmista => tiedosto,
sisältö => "", # phpinfo-koodi
request => Paketti["apache2"], # pyyntö paketille "apache2"
}

Manifestin soveltaminen

Käytä uutta luetteloa antamalla komento:

sudo puppet apply --test

Se näyttää laajan tuloksen, joka näyttää kaikki muutokset ympäristön tilassa. Jos tulosteessa ei ole virheitä, sinun pitäisi pystyä avaamaan ulkoinen IP-osoite tai verkkotunnus selaimessasi. Näytölle tulee testitesti. PHP sivu pinon tiedoilla. Tämä tarkoittaa, että Apache ja PHP toimivat.

Nyt LAMP-pino on asennettu palvelimelle Puppetin avulla.

Tämä on melko yksinkertainen manifesti, koska se voidaan suorittaa agentille. Jos sinulla ei ole Puppet Masteria, muut agenttisolmut eivät voi käyttää tätä luetteloa.

Puppet-pääpalvelin tarkistaa palvelimen tilan muutokset 30 minuutin välein.

Esimerkki 2: LAMP-pinon asentaminen moduulin avulla

Yritä nyt luoda yksinkertainen moduuli edellisessä osiossa kirjoittamasi LAMP-luettelon perusteella.

Luodaksesi moduulin, luo uusi hakemisto moduulihakemistoon (sen nimen on vastattava moduulin nimeä). Tämän hakemiston tulee sisältää manifestihakemisto ja init.pp-tiedosto. Init.pp-tiedosto määrittää Puppet-luokan (sen nimen tulee myös vastata moduulin nimeä).

Moduulin luominen

Siirry Puppet-pääpalvelimelle ja luo moduulille hakemistorakenne:

cd /etc/puppet/modules
sudo mkdir -p lamppu/manifestit

Luo ja avaa init.pp-tiedosto editorissa:

sudo vi lamp/manifests/init.pp

Lisää lamppuluokka tiedostoon:

luokan lamppu (
}

Kopioi luettelon sisältö osiosta 1 ja liitä se lamppuluokkalohkoon. Sinulla on nyt lamppuluokan määritelmä. Muut luettelot voivat käyttää tätä luokkaa moduulina.

Tallenna ja sulje tiedosto.

Pääluettelossa olevan moduulin käyttäminen

Nyt voit määrittää pääluettelon ja asentaa LAMP-pinon palvelimelle lamppumoduulin avulla.

Muokkaa Puppet Master -palvelimella seuraavaa tiedostoa:

sudo vi /etc/puppet/manifests/site.pp

Todennäköisimmin päällä Tämä hetki tiedosto on tyhjä. Lisää siihen seuraavat rivit:

solmun oletusarvo ( )
solmu "lamppu-1" (
}

Huomautus: Korvaa lamppu 1 sen Puppet-agentin isäntänimellä, johon pino asennetaan.

Solmulohkon avulla voit määrittää Puppet-koodin, joka koskee vain joitain solmuja.

Oletuslohko koskee kaikkia agenttisolmuja, joilla ei ole yksittäistä lohkoa (jätä se tyhjäksi). Lamppu-1-lohko lisätään lamppu-1-agenttisolmuun.

Lisää seuraava rivi tähän lamppumoduulia käyttävään lohkoon:

Tallenna ja sulje tiedosto.

Nyt Puppet-agenttisolmu voi ladata asetukset pääpalvelimelta ja asentaa LAMP-pinon. Jos haluat tehdä muutoksia juuri nyt, suorita komento agentissa:

sudo nukke agentti --testi

Moduulit ovat kätevin tapa käyttää Puppet-koodia uudelleen. Lisäksi moduulit auttavat sinua järjestämään koodisi loogisesti.

Esimerkki 3: LAMP:n asentaminen julkisia moduuleja käyttäen

MySQL-moduulia käytetään samalla tavalla. Lisää solmulohkoon seuraavat rivit:

class("mysql::palvelin":
root_password => "salasana",
}

Voit myös välittää MySQL-moduulin parametreja.

Lisää resurssi, joka kopioi info.php:n haluttuun paikkaan. Käytä lähdeparametria. Lisää solmulohkoon seuraavat rivit:

file("info.php": # resurssitiedoston nimi
polku => "/var/www/html/info.php", # kohdepolku
varmista => tiedosto,
vaatia => Luokka["apache"], # käytettävä apache-luokka
source => "puppet:///modules/apache/info.php", # sijainti, johon tiedosto kopioidaan
}

Tämä luokkamääritys käyttää lähdeparametria sisällön sijaan. Tämä vaihtoehto ei vain käytä tiedoston sisältöä, vaan myös kopioi sen.

Puppet kopioi tiedoston puppet:///modules/apache/info.php kansioon /etc/puppet/modules/apache/files/info.php.

Tallenna ja sulje tiedosto.

Luo info.php-tiedosto.

sudo sh -c "echo""> /etc/puppet/modules/apache/files/info.php"

Nyt Puppet-agenttisolmu voi ladata asetukset pääpalvelimelta ja asentaa LAMP-pinon. Jos haluat tehdä muutoksia agenttiympäristöön juuri nyt, suorita komento tässä solmussa:

sudo nukke agentti --testi

Tämä komento lataa kaikki nykyisen solmun päivitykset ja asentaa pinon siihen. Varmista, että Apache ja PHP toimivat, avaamalla solmun IP-osoite tai toimialue selaimessa:

http://lamppu_1_julkinen_IP/info.php

Johtopäätös

Sinulla on nyt perustiedot Puppet-moduulien ja manifestien kanssa työskentelystä. Yritä luoda yksinkertainen luettelo ja moduuli itse.

Puppet sopii erinomaisesti sovellusten määritystiedostojen hallintaan.

Tunnisteet: ,
Vähän runoutta. Näyttäisi siltä, että tämän artikkelin pitäisi olla koko sarjan lähtökohta, mutta kohdeyleisönä ovat silti kokeneemmat Open Source Puppet Labs -tuotteiden käyttäjät, jotka eivät ole tyytyväisiä yksittäisiin, huonosti integroituihin Puppet Forgen moduuleihin. Kuten kaikissa "kirjasto vs. kehys" -tapauksissa, maksettava hinta on integroidun ratkaisun tekijän maailmankuvan noudattaminen.

Vähän siitä, miten Puppet toimii

Nukke on ensisijaisesti erityinen kieli järjestelmän lopullisen tilan ilmoittamiseen. Vertailun vuoksi GNU Makefile on erittäin sopiva, jossa riippuvuuksien suoran kuvauksen lisäksi on mahdollista oudostella täysillä.

Nuken abstraktio on jotain tällaista ( murtaa kuvioita - unohda kaikki, mitä tiesit ohjelmointitermeistä!).

Solmu on joukko kokoonpanoja tietylle kohdejärjestelmälle. Itse asiassa tämä on luokan erikoistapaus.
Luokka on joukko deklaratiivista logiikkaa, joka sisältyy solmun kokoonpanoon tai muihin luokkiin. Luokassa ei ole ilmentymiä eikä menetelmiä, mutta siinä on logiikassa määriteltyjä parametreja ja muuttujia. Itse asiassa se on pikemminkin menettely, joka voi periä toisen proseduurin yksinkertaisesti lisäämällä koodia ja jolla on ei niin banaalinen muuttujien laajuus.
Tyyppi- mutta tämä näyttää enemmän klassiselta luokalta - se olettaa esiintymiä, joilla on nimi ja ehdottomasti annetut parametrit, mutta ei sen enempää. Tyypin erityinen toteutus voidaan kirjoittaa Puppet-skriptiksi define:n kautta, joka luo esiintymiä muita tyyppejä, tai Ruby-laajennukseksi, jolla on fantastinen lento.
Resurssi- Nämä ovat itse asiassa nimettyjä tyyppien esiintymiä. Jokainen resurssin nimi on yksilöllinen tietyn tyypin sisällä solmun (hakemiston) kokoonpanossa.
Muuttujat- No, lyhyesti sanottuna, nämä ovat vakioita... Ennen Puppet 4:ää asiat olivat vielä huonompia niiden laajuuden kanssa. Nyt se riittää: määrittelypaikan ulkopuolelta käyttöä varten on määritettävä täysin pätevä tunniste, paitsi luokan periytymisen tapauksessa.

Puppetia voidaan käyttää paikalliseen käyttöön ilman verkkoa tai siihen liittyvää infrastruktuuria. Tätä voidaan käyttää säilökuvien luomiseen. On jopa kokonainen liike, joka kannattaa keskitetystä palvelimesta luopumista.

Ideologisesti oikein Puppet-infrastruktuuri koostuu agentista - kohdejärjestelmän etuoikeutetusta palvelusta - ja palvelimesta, joka jakaa arvokkaita ohjeita deklaratiivisten resurssihakemistojen muodossa agenttien pyynnöstä. Suojaus toteutetaan yksityisen julkisen avaimen infrastruktuurin tasolla (X.509). Yksinkertaisesti sanottuna, samat mekanismit kuin HTTPS:ssä, mutta omalla CA:lla ja pakollisella vahvistuksella asiakkaan varmenne.

Yksinkertaistetussa muodossa käyttöönottomenettely näyttää suunnilleen tältä:

Käsittely TLS:n ja X.509:n kautta (yhteyden muodostaminen, CRL:n päivitys, varmennerajoitusten tarkistaminen jne.)
Agentti saa palvelimelta faktageneraattoreita, joissa on välimuisti ja kaikki asiat (tarkemmin sanottuna kaikki vedetään moduulien lib/-kansioista). Oman Ruby-skriptin lisääminen kiinnostavien tietojen keräämiseen ei ole vaikeaa.
Agentti kerää tietoja kohdejärjestelmästä ja lähettää ne palvelimelle. Kaikki tosiasiat voidaan helposti tarkastella manuaalisesti nukkefaktapuhelun kautta. Nämä tosiasiat ovat saatavilla globaaleina muuttujina.
Palvelin kokoaa luettelon resursseista ja lähettää sen agentille. Tämän alla piilee kokonainen kerros erilaisia käsitteitä.
Agentti hakee kaiken tarvittavan palvelimelta ja tuo järjestelmän määritettyyn muotoon. Agentti itse ei tiedä mitä tehdä resursseille, se luottaa tietyntyyppisten resurssien tarjoajien (semanttinen käännös on "toteuttaja", ei toimittaja) toteuttamiseen. Jotkut palveluntarjoajat ovat vakioita ja sisältyvät Puppet-paketteihin, kun taas loput vedetään moduuleista.

Voit nauttia kaikista herkuista lisää pullat muodossa:

Moduuli- kokoelma deklaratiivisia Puppet-skriptejä, Ruby-laajennuksia Puppetille, tiedostoja, tiedostomalleja, Hiera-tietoja ja paljon muuta. Oikeampi termi olisi "paketti".
Ympäristö- joukko skriptejä, moduuleja ja Hiera-tietoja. Kun infrastruktuuri muuttui monimutkaisemmaksi, tuli väistämättä jakaa konfiguraatio pidemmälle kuin standardijako solmujen mukaan. Pohjimmiltaan tätä tarvitaan pilottiinnovaatioihin ja banaaliseen kulunvalvontaan (kun kaikilla ylläpitäjillä ei ole pääsyä kaikkiin IT-infrastruktuurin solmuihin).
Hiera- hierarkkinen tietokanta. Tämä muotoilu voi olla hyvin pelottava. Luultavasti tästä syystä sitä muutettiin myöhempien versioiden dokumentaatiossa. Itse asiassa tämä on erittäin yksinkertainen ja kätevä mekanismi kokoonpanon purkamiseen YAML- tai JSON-tiedostoista. Hierarkia on kyky määrittää useiden asetustiedostojen lukujärjestys - ts. näiden tiedostojen hierarkia/prioriteetti.
- Sen lisäksi, että Puppet hakee tietoja funktiokutsulla, se hakee oletusluokkaparametreja, mikä on tärkein kohokohta.
- Tietenkin Hiera tukee faktojen interpolointia ja jopa erikoistoimintojen kutsumista.
- Puppet 4.3:ssa toteutimme samat toiminnot uudelleen tukemaan globaalin tietokannan lisäksi myös paikallista ympäristön ja moduulin tietokantaa, vaikka kirjoittaja on jo löytänyt useita ongelmia niiden toteutuksessa (PUP-5983, PUP-5952 ja PUP -5899), jotka Puppet Labs korjasi välittömästi.
- Useita strategioita tuetaan arvojen poimimiseen kaikista hierarkian tiedostoista:
  - ensimmäinen - ensimmäinen prioriteetin mukaan löydetty arvo palautetaan
  - ainutlaatuinen - kerää kaikki arvot yksiulotteiseen taulukkoon ja poistaa kaksoiskappaleet
  - hash - yhdistää kaikki löydetyt YAML Hash. Päällekkäiset avaimet valitaan prioriteetin mukaan.
  - deep on pohjimmiltaan rekursiivinen versio hashista
- Kauneus on, että näytteenottostrategia voidaan määrittää sekä kutsuttaessa lookup()-funktiota, koska ja missä tahansa hierarkiatiedostossa erityisen lookup_options-avaimen kautta, jota käytetään aktiivisesti cfnetwork-moduulissa.
PuppetDB- olennaisesti relaatiotietokannan (PostgreSQL) ympärillä oleva liiketoimintalogiikkakerros, jonka avulla voit tallentaa raportteja tosiasioista ja suoritetuista käyttöönotoista ja viedä resursseja myöhempää tuontia varten muiden solmujen hakemistoihin tai valintoihin erikoistoiminnot. Siellä on myös verkkokäyttöliittymä Puppet Dashboardin muodossa.
X.509 PKI- jo mainittu varmenneinfrastruktuuri, jota on erittäin kätevä käyttää muihin palveluihin ilman erillistä infrastruktuuria.
MCollective- näyttää olevan hyödyllinen asia tapahtumapohjaiseen tehtävien käynnistämiseen palvelinfarmilla, mutta kirjoittajalla on tietty epäluottamus tietyn ratkaisun turvallisuuteen.
Puppet Forge- avoin alusta moduulien julkaisemista ja lataamista varten.
joitain muita ominaisuuksia säätimien muodossa ulkoisia laitteita tyyppisiä Cisco-laitteita ja käyttöönottoa paljaalla metallilla, mutta se on eri tarina

Huomautuksia turvallisuudesta ja saavutettavuudesta

Sinun on ymmärrettävä, että Puppet Serveristä tulee koko IT-infrastruktuurin haavoittuva kohta, koska... määrittää kaikkien järjestelmien lopullisen kokoonpanon. Erikoistapauksissa on järkevää tehdä erottelu - erillinen palvelin kriittisille infrastruktuurielementeille erittäin rajoitettu pääsy ja manuaalinen päivitys ja toinen kaikelle muulle.

Puppet Serverin saatavuus määrittää kyvyn hallita koko infrastruktuuria. On järkevää isännöidä Puppet Serveriä virtuaalikoneessa luotettavammassa ja nopeammin palautettavassa kolmannen osapuolen pilvessä kuin omat ominaisuudet. Tai sinun pitäisi asentaa useita palvelimia.

Joka tapauksessa sinun ei pitäisi asentaa muita palveluita järjestelmään, jossa Puppet Server kelloilla ja pillillä otetaan käyttöön. Virtualisointi ja kontitointi voivat auttaa sinua.

Multi-master (useita erillisiä nukkepalvelimia)

Tässä tapauksessa vain yksi palvelin toimii CA:na (varmentajana) - sen epäkäytettävyys tarkoittaa, että uusia solmuja ei voi lisätä.
- Puppetin avulla voit käyttää kolmannen osapuolen X.509-infrastruktuuria, jos sisäänrakennettu infrastruktuuri ei ole tyydyttävä.
Koko konfiguraatio (Ympäristö) on tallennettava versionhallintajärjestelmään ja otettava käyttöön jokaiselle palvelimelle samanaikaisesti.
Ainoa yhteinen asia on PostgreSQL-tietokanta, jonka korkean saatavuuden järjestäminen ei kuulu tämän artikkelin piiriin.
cfpuppetserver-moduuli tukee asennuksia ensisijaisena (CA:n kanssa) ja toissijaisena palvelimena.

Mikä merkittävää on muuttunut vanhemmista versioista

Valmistajalla on täydellinen kuvaus.

Kaikki palvelut ovat siirtyneet JVM:lle, JRubylle ja Jettylle. Huolimatta integraation ilmeisistä eduista, muistinkulutuksessa on myös haittoja.
Lambda-toiminnot on lisätty kokoelmien käsittelyyn - nyt ei tarvitse leikata kainalosauvoja Rubyssa tai pervertoida create_resources()
Työkalu EPP-mallien käsittelyyn on ilmestynyt - periaatteessa sama ERB, mutta Puppet DSL Rubyn sijaan,
Asetustiedostojen oletushakemistorakenne on muuttunut merkittävästi
Lisätty tuki ympäristöjen ja moduulien tiedontarjoajille (hakkerointia ei enää tarvita).
Globaalin Hieran roolin vähättely. Uusi ja siihen liittyvä komento on nukkehaku.

Asennus

Tämä prosessi on melko primitiivinen, mutta vaatii tietyn vaihesarjan noudattamisen. Koska tämän tekeminen manuaalisesti on kiittämätön tehtävä, kirjoittaja opettaa sinulle jotain pahaa, nimittäin käsittämättömien komentosarjojen lataamisen Internetistä ja niiden suorittamisen pääkäyttäjänä järjestelmässäsi.

Kolme pääpalvelinkomponenttia ovat itse Puppet Server, PuppetDB ja PostgreSQL. Ne voidaan kaikki pakata yhteen solmuun tai jakaa kahteen tai kolmeen järjestelmään. Puppet Server ja Puppet DB voidaan suorittaa useita kertoja, mutta PostgeSQL on yksi vikakohta. PostgeSQL:n replikointiin ja klusterointiin on erilaisia lähestymistapoja.. Kätevä lähestymistapa pää- ja toissijaisten palvelimien tapauksessa olisi Master + Read-Only Slave, jota PuppetDB itse tukee pää- ja vain luku -tietokantasolmuna, mutta automatisoi tällaisen asennus vie aikaa, eikä se siksi ole vielä saatavilla cfpuppetserver-moduulissa.

Itse konfiguraatio voidaan yksinkertaisesti tallentaa ainakin tiedostojärjestelmä yhdessä Puppet Serverin kanssa, mutta se on kuin skriptien kirjoittamista tuotantoverkkopalvelimelle. Sopivin ratkaisu on git-arkisto. r10k-apuohjelma voi vetää kaikki arkiston haarat ja ottaa ne käyttöön Puppet Serverille erillisinä ympäristöinä. r10k on melko huono vetää riippuvuuksia, joten kirjastonhoitaja-nukke käytetään päälle. On syytä huomata heti, että tärkein kanoninen Puppet Environment on "tuotanto". Tästä syystä määritysvaraston tulisi käyttää haaraa nimeltä "tuotanto" eikä "master".

Laitteistovaatimukset

Laitteiston on valmistaja itse kuvaillut. cfpuppetserver-moduuli tukee tällä hetkellä vain Debian Jessie+:aa ja Ubuntu Trusty+:aa.

Määritykset Gitissä

Itse r10k:lle arkiston sijainnilla ei ole paljon väliä - pääasia on sen saatavuus. Esimerkiksi testaustarkoituksia varten arkisto voidaan isännöidä samassa järjestelmässä ja käyttää tiedosto:// . Hyvä paikka aloittaa on codingfuture/puppet-exampleenv-kokoonpanoesimerkki.

Arkiston kloonaus: git clone https://github.com/codingfuture/puppet-exampleenv my-puppet-conf && cd my-puppet-conf
Asentaa Yleiset asetukset järjestelmänvalvojan pääsy kommenteissa olevien vihjeiden avulla:
- $EDITOR data/common.yaml
Luodaan solmukokoonpano:
- $MY_DOMAIN - juuriverkkotunnuksen nimi (esimerkiksi esimerkki.org)
- $HOST_NAME - asiakkaan isäntänimi ilman verkkotunnusta
- mkdir-tiedot/$MY_DOMAIN
- cp data/example.com/nukke.yaml data/$(OMA_DOMAIN)/nukke.yaml
- $EDITOR nano -w data/$(MY_DOMAIN)/puppet.yaml - solmun asettaminen Puppet Serverillä kommenteissa olevien ehdotusten mukaisesti
- cp data/example.com/host.yaml data/$(OMA_DOMAIN)/$(HOST_NAME).yaml
- $EDITOR nano -w data/$(MY_DOMAIN)/$(HOST_NAME).yaml - mielivaltaisen solmun asettaminen kommenteissa olevien ehdotusten perusteella
Lähetämme omalle Git-palvelimellemme tai teemme sen saataville paikallisesti Puppet Serverin solmussa rsyncin tai scp:n kautta. Paikallinen arkisto on kätevä välivaiheena, kunnes Git-palvelin otetaan käyttöön itse Puppetista. Tietyssä mielessä tämä muistuttaa kääntäjän kokoamista useissa vaiheissa.

Asennus tyhjästä puhtaaseen järjestelmään

cfpuppetserver-moduulin avulla voit asentaa kaiken itse Puppetin avulla, mutta alkuasennuksessa perustoiminnot kopioidaan Bash-skriptillä.

Kohdejärjestelmässä:

Lataa asennusskripti: wget https://raw.githubusercontent.com/codingfuture/puppet-cfpuppetserver/master/setup_puppetserver.sh
Katsomme skriptin läpi ja rypistelemme otsaa: less setup_puppetserver.sh
Suorita: bash setup_puppetserver.sh
nukke.$(MY_DOMAIN) .
- Esimerkki etävarastosta: bash setup_puppetserver.sh ssh:// [sähköposti suojattu]/puppet-conf
- Esimerkki paikallisesta: bash setup_puppetserver.sh file:///root/puppetconf/
Näemme, kuinka järjestelmä paisuu eikä asenna kaikkea kovin nopeasti.
Jos arkisto on etä:
- Luo SSH-avain juurille: ssh-keygen -t rsa -b 2048
- Rekisteröimme julkisen avaimen /root/.ssh/id_rsa.pub Git-etäpalvelimelle...
- ... ja siellä asetetaan Git-koukku kutsumalla seuraava komento: /usr/bin/ssh -T deploypuppet@puppet.$(OMA_DOMAIN) ./puppetdeploy.sh
Aloitamme määrityksen käyttöönoton manuaalisesti: /etc/puppetlabs/deploy.sh
Kokeillaan kuinka se toimii itse palvelimella: /opt/puppetlabs/bin/puppet agent --test
Tarkista verkkoasetukset, ylijännitesuoja ja SSH-yhteys

Hallittujen solmujen lisääminen

Puppet Serverin täydellisen nimen on oltava saatavilla DNS:n kautta hallitussa isännässä tai kovakoodattuina tiedostoon /etc/hosts.
- Esimerkki: echo "128.1.1.1 puppet.example.com" >> /etc/hosts
Suorita Puppet Server -solmussa seuraava komentosarja /root/genclientinit.sh $(HOST_NAME).$(OMA_DOMAIN) .
Kopioi koko tulos ja liitä se komentorivi kohdejärjestelmässä.
Odotamme suorituksen loppua ja suoritamme /opt/puppetlabs/bin/puppet agent --test . Ensimmäisellä käynnistyksellä luodaan varmenteen allekirjoituspyyntö.
Menemme Puppet Server -solmuun allekirjoittamaan varmenteen.
- nukkesertifikaattiluettelo - tarkistamme sertifikaatin allekirjoituksen ylimääräisen vainoharhaisuuden varalta.
- nukkevarmenteen allekirjoitus $(HOST_NAME).$(MY_DOMAIN) - itse asiassa me allekirjoitamme varmenteen.
Palaamme hallittuun solmuun ja suoritamme: /opt/puppetlabs/bin/puppet agent --test` uudelleen. Tämä pakottaa käyttöönottoprosessin alkamaan.
Odotamme käyttöönoton valmistumista Puppet Agentin kautta.
Siinä kaikki, sinulla on minimaalinen Puppet-infrastruktuuri valmiina!

Esimerkkituloste tiedostosta /root/genclientinit.sh

lyödä</etc/cflocation fi jos testi ! -z ""; sitten echo -n >/etc/cflocationpool fi jos testi ! -z "\$http_välityspalvelin"; sitten vie http_proxy vienti https_proxy="\$http_proxy" vienti HTTP_PROXY="\$http_proxy" export HTTPS_PROXY="\$http_proxy" fi echo host.example.com > /etc/isäntänimi isäntänimi host.example.com jos ! joka lsb-julkaisu | lukea; sitten apt-get install lsb-release fi koodinimi=\$(lsb_release -cs) if test -z "\$koodinimi"; sitten echo "Oikean koodinimen havaitseminen epäonnistui" exit 1 fi wget https://apt.puppetlabs.com/puppetlabs-release-pc1-\$(koodinimi).deb dpkg -i puppetlabs-release-pc1-\$(koodinimi) .deb mkdir -p /etc/puppetlabs/puppet cat > /etc/puppetlabs/puppet/puppet.conf<nukke sertifikaatin merkki isäntä.esimerkki.com" echo "Käytä CTRL+C syklin pysäyttämiseen, jos epäonnistuu eri syistä" uni 5 valmis EOT

Moduulin kuvaus

Täydellinen luettelo alkuperäisen asennusohjelman Bash-parametreista

~# ./setup_puppetserver.sh Käyttö: ./setup_puppetserver.sh [ [ [ [] ] ] ]

r10k_repo_url - Git-tietovaraston URI
certname - isännän täysin hyväksytty verkkotunnus
cflocation - tosiasian cf_location alustus
cflocationpool - tosiasian cf_location_pool alustus
http_proxy - välityspalvelin HTTP- ja HTTPS-pyyntöjä varten

Täydellinen luettelo Puppet-asiakasohjelman alustuskomentosarjan Bash-parametreista

~# /root/genclientinit.sh Käyttö: ./genclientinit.sh [ [ []]]
Parametrien merkitys on sama kuin edellisessä skriptissä.

cfpuppetserver-luokka

deployuser = "deploypuppet" - käyttäjätunnus kokoonpanopäivitysten automaattista käyttöönottoa varten
deployuser_auth_keys = undef - $deployuser-avaimien luettelo
repo_url = undef - arkiston URI (esimerkki: ssh://user@host/repo tai file:///some/path)
puppetserver = true - asennetaanko Puppet Server -komponentti tähän solmuun
puppetdb = true - asennetaanko PuppetDB-komponentti tähän solmuun
puppetdb_port = 8081 - portti PuppetDB:lle
setup_postgresql = true - asennetaanko PostgreSQL-komponentti tähän solmuun (vain jos PuppetDB-asennus on käytössä)
service_face = "mikä tahansa" - cfnetwork::iface-resurssin nimi saapuvien yhteyksien hyväksymistä varten
puppetserver_mem = auto - RAM Puppet Serverille megatavuina (vähintään 192 Mt)
puppetdb_mem = automaattinen - RAM PuppetDB:lle megatavuina (vähintään 192 Mt)
postgresql_mem = automaattinen - RAM PostgreSQL:lle megatavuina (vähintään 128 Mt)

luokan cfpuppetserver::puppetdb

postgresql_host = "localhost" - tietokannan osoite
postgresql_listen = $postgresql_host - arvo menee suoraan listen_addresses PostgreSQL-käskyyn
postgresql_port = 5432 - tietokantaportti
postgresql_user = "puppetdb" - PuppetDB-käyttäjä tietokannassa
postgresql_pass = "puppetdb" - PuppetDB-käyttäjän salasana tietokannassa
postgresql_ssl = false - ota käyttöön Puppet PKI -varmenteisiin perustuva yhteyden salaus

luokka cfpuppetserver::nukkepalvelin

autosign = false - EI PIDÄ käyttää taisteluympäristössä, paitsi ehkä DMZ:ssä. On olemassa yksinomaan testiautomaatiota varten.
global_hiera_config = "cfpuppetserver/hiera.yaml" - polku oletusarvoiseen Hiera-määritystiedostoon Puppet-kanonien mukaan (ensimmäinen komponentti on moduulin nimi, loput polku moduulin tiedostojen/kansion alla)

Voit auttaa ja siirtää varoja sivuston kehittämiseen

Suuren määrän Unix-järjestelmien hallintaa ei voida kutsua käteväksi. Yhden parametrin muuttamiseksi järjestelmänvalvojan on otettava yhteyttä jokaiseen koneeseen; komentosarjat voivat auttaa vain osittain, eivätkä kaikissa tilanteissa.

On huomattava, että Windows-verkon ylläpitäjät ovat edelleen edullisemmassa asemassa. Riittää, kun muutat ryhmäkäytäntöasetuksia ja hetken kuluttua kaikki verkossa olevat tietokoneet, mukaan lukien ne, joissa on äskettäin asennettu käyttöjärjestelmä, "oppivat" innovaatiosta, jos se tietysti koskee heitä. Kun katsot taaksepäin pitkää Unix-kehitysjaksoa, huomaat, että mikään tällainen ei koskaan tarttunut. On olemassa ratkaisuja, kuten kickstart, jotka auttavat alkuasennuksessa käyttöjärjestelmä, mutta tarkentaminen vaatii huomattavia ponnisteluja. Kaupalliset ratkaisut, kuten BladeLogic ja OpsWare, ratkaisevat vain osittain asetusten automatisointiongelman; niiden tärkein etu on saatavuus GUI, ja niitä voi ostaa vain suurilta organisaatioilta. Ilmaisia ratkaisuja tarjoavia projekteja tietysti on, mutta koko olemassaolonsa aikana ne eivät ole koskaan pystyneet luomaan suurta yhteisöä. Esimerkiksi Cfengine ei ole kovin suosittu järjestelmänvalvojien keskuudessa, vaikka Linuxin lisäksi sitä voidaan käyttää *BSD:ssä, Windowsissa ja Mac OS X:ssä. Tämä voi johtua kokoonpanojen luomisen suhteellisen monimutkaisuudesta. Tehtäviä kuvattaessa on otettava huomioon kunkin järjestelmän ominaisuudet ja ohjattava manuaalisesti toimintojen järjestystä komentoja suoritettaessa. Toisin sanoen järjestelmänvalvojan on muistettava, että joissakin järjestelmissä tulee kirjoittaa adduser toisille, useradd, ottaa huomioon tiedostojen sijainti eri järjestelmissä ja niin edelleen. Tämä vaikeuttaa komentojen kirjoitusprosessia suuruusluokkaa; oikean kokoonpanon luominen lennossa on erittäin vaikeaa, ja luotuja kokoonpanoja on lähes mahdotonta lukea hetken kuluttua. GPL-lisenssistä huolimatta Cfengine on itse asiassa yhden miehen projekti, joka hallitsee kaikkia muutoksia eikä ole kovin kiinnostunut avoimen yhteiskunnan rakentamisesta. Tämän seurauksena cfenginen ominaisuudet ovat varsin tyydyttävät kehittäjälle, mutta muille ylläpitäjille se on ylimääräinen päänsärky. Kolmannen osapuolen kehittäjät loivat cfenginin parantamiseksi erilaisia lisäosia, jotka usein vain pahensivat tilannetta. Useiden tällaisten cfengine-moduulien kirjoittaja Luke Kanies päätti lopulta kehittää samanlaisen työkalun, mutta ilman monia cfengine-puutteita.

Nuken ominaisuudet

Puppet, kuten cfengine, on asiakas-palvelinjärjestelmä, joka käyttää deklaratiivista eli pakollista kieltä kuvaamaan tehtäviä ja kirjastoja niiden toteuttamiseksi. Asiakkaat muodostavat ajoittain (oletuksena 30 minuuttia) yhteyden keskuspalvelimeen ja vastaanottavat uusimmat asetukset. Jos vastaanotetut asetukset eivät vastaa järjestelmän tilaa, ne suoritetaan ja tarvittaessa lähetetään raportti suoritetuista toiminnoista palvelimelle. Palvelin voi tallentaa viestit syslogiin tai tiedostoon, luoda RRD-kaavion ja lähettää ne määritettyyn sähköpostiin. Muut Transaction- ja Resource Abstraction -tasot tarjoavat maksimaalisen yhteensopivuuden olemassa olevien asetusten ja sovellusten kanssa, jolloin voit keskittyä järjestelmäobjekteihin murehtimatta yksityiskohtaisten komentojen ja tiedostomuotojen toteutuksen ja kuvauksen eroista. Ylläpitäjä toimii vain objektityypin kanssa, Puppet hoitaa loput. Pakettityyppi tuntee siis noin 17 pakettijärjestelmää, joista tarvittava tunnistetaan automaattisesti jakelun tai järjestelmän versiotietojen perusteella, vaikka paketinhallintaa voidaan tarvittaessa pakottaa.

Toisin kuin komentosarjat, joita ei useinkaan ole mahdollista käyttää muissa järjestelmissä, kolmannen osapuolen järjestelmänvalvojien kirjoittamat Puppet-kokoonpanot toimivat suurimmaksi osaksi ilman ongelmia missään muussa verkossa. Nukkekeittokirjassa [ http://www.reductivelabs.com/trac/puppet/tags/puppet%2Crecipe] valmiita reseptejä on jo kolme tusinaa. Puppet tukee tällä hetkellä virallisesti seuraavia käyttöjärjestelmiä ja palveluita: Debian, RedHat/Fedora, Solaris, SUSE, CentOS, Mac OS X, OpenBSD, Gentoo ja MySQL, LDAP.

Nukkekieli

Jotta pääset eteenpäin, sinun on ensin ymmärrettävä kielen peruselementit ja ominaisuudet. Kieli on yksi niistä vahvuuksia Nukke. Sen avulla kuvataan resurssit, joita järjestelmänvalvoja aikoo hallita, ja toimet. Toisin kuin useimmat samankaltaiset ratkaisut, Puppet sallii kielen yksinkertaistaa pääsyn kaikkiin samanlaisiin resursseihin missä tahansa järjestelmässä heterogeenisessä ympäristössä. Resurssin kuvaus koostuu yleensä nimestä, tyypistä ja määritteistä. Osoitetaan esimerkiksi /etc/passwd-tiedostoa ja asetetaan sen attribuutit:

file("/etc/passwd":

omistaja => root,

ryhmä => juuri,

Nyt asiakkaat, jotka ovat muodostaneet yhteyden palvelimeen, kopioivat /etc/passwd-tiedoston ja asentavat määritetyt attribuutit. Voit määrittää useita resursseja yhdessä säännössä erottamalla ne puolipisteellä. Mitä tehdä, jos palvelimella käytetty asetustiedosto eroaa asiakaskoneista tai sitä ei käytetä ollenkaan? Tällainen tilanne voi syntyä esimerkiksi silloin, kun VPN-asetukset yhteyksiä. Tässä tapauksessa tiedosto voidaan osoittaa käyttämällä lähdedirektiiviä. Tässä on tavalliseen tapaan kaksi vaihtoehtoa määrittää polku toiseen tiedostoon; myös kaksi URI-protokollaa ovat tuettuja: tiedosto ja nukke. Ensimmäisessä tapauksessa linkki ulkoiseen NFS-palvelin, toisessa vaihtoehdossa Puppet-palvelimelle käynnistetään NFS-tyyppinen palvelu, joka vie resursseja. Jälkimmäisessä tapauksessa oletuspolku on suhteessa nukkepäähakemistoon - /etc/puppet. Eli linkki puppet://server.domain.com/config/sshd_config vastaa tiedostoa /etc/puppet/config/sshd_config. Voit ohittaa tämän hakemiston käyttämällä filebucket-direktiiviä, vaikka onkin oikein käyttää samannimistä osaa /etc/puppet/fileserver.conf-tiedostossa. Tässä tapauksessa voit rajoittaa pääsyä palveluun vain tietyistä osoitteista. Kuvataan esimerkiksi asetusosio.

polku /var/puppet/config

salli *.domain.com

salli 192.168.0.*

salli 192.168.1.0/24

kieltää *.wireless.domain.com

Ja sitten siirrymme tähän osioon kuvattaessa resurssia.

lähde => "puppet://server.domain.com/config/sshd_config"

Ennen kaksoispistettä on resurssin nimi. Yksinkertaisimmissa tapauksissa voit yksinkertaisesti määrittää aliaksen tai muuttujat nimeksi. Alias asetetaan käyttämällä aliasdirektiiviä. koko polku tiedostoon. Monimutkaisemmissa kokoonpanoissa

file("/etc/passwd":

alias => passwd

Toinen vaihtoehto aliaksen luomiseen on hyvä, kun joudut käsittelemään erilaisia käyttöjärjestelmiä. Luodaan esimerkiksi resurssi, joka kuvaa sshd_config-tiedostoa:

tiedosto (sshdconfig:

nimi => $käyttöjärjestelmä ? (

solaris => "/usr/local/etc/ssh/sshd_config",

oletus => "/etc/ssh/sshd_config"

Tässä esimerkissä olemme valinnan edessä. Solariksen tiedosto määritetään erikseen, kaikille muille valitaan tiedosto /etc/ssh/sshd_config. Nyt tätä resurssia voidaan käyttää nimellä sshdconfig, käyttöjärjestelmästä riippuen haluttu polku valitaan. Osoitamme esimerkiksi, että jos sshd-daemon on käynnissä ja vastaanotettu uusi tiedosto, sinun tulee käynnistää palvelu uudelleen.

varmista => totta,

tilaa => tiedosto

Muuttujia käytetään usein käytettäessä käyttäjätietoja. Kuvaamme esimerkiksi käyttäjien kotihakemistojen sijainnin:

$homeroot = "/home"

Nyt tietyn käyttäjän tiedostot ovat käytettävissä nimellä

$(homeroot)/$nimi

Parametri $name täytetään käyttäjän tilin nimellä. Joissakin tapauksissa on kätevää määrittää oletusarvo jollekin tyypille. Esimerkiksi exec-tyypin kohdalla ne osoittavat usein hakemistot, joista sen pitäisi etsiä suoritettavaa tiedostoa:

Exec (polku => "/usr/bin:/bin:/usr/sbin:/sbin")

Jos sinun on osoitettava useita sisäkkäisiä tiedostoja ja hakemistoja, voit käyttää recurse-parametria.

file("/etc/apache2/conf.d":

lähde => "puppet:// puppet://server.domain.com/config/apache/conf.d",

recurse => "tosi"

Useita resursseja voidaan yhdistää luokiksi tai määritelmiksi. Luokat ovat täydellinen kuvaus järjestelmästä tai palvelusta ja niitä käytetään erikseen.

"/etc/passwd": omistaja => juuri, ryhmä => juuri, tila => 644;

"/etc/shadow": omistaja => juuri, ryhmä => juuri, tila => 440

Kuten oliokielissä, luokat voidaan ohittaa. Esimerkiksi FreeBSD:llä näiden tiedostojen ryhmäomistaja on wheel. Siksi, jotta resurssia ei kirjoiteta kokonaan uudelleen, luodaan uusi luokka freebsd, joka perii linux-luokan:

luokan freebsd perii Linuxin (

Tiedosto[“/etc/passwd”] ( ryhmä => pyörä );

Tiedosto["/etc/shadow"] ( ryhmä => pyörä )

Mukavuussyistä kaikki luokat voidaan sijoittaa erilliseen tiedostoon, joka voidaan yhdistää include-direktiivin avulla. Määritelmät voivat ottaa useita parametreja argumenteiksi, mutta ne eivät tue periytymistä, ja niitä käytetään, kun sinun on kuvattava uudelleenkäytettäviä objekteja. Määritetään esimerkiksi käyttäjien kotihakemisto ja uuden tilin luomiseen tarvittavat komennot.

määritä user_homedir ($ryhmä, $kokonimi, $yhdysryhmät) (

user("$nimi":

varmista => läsnä,

kommentti => "$fullname",

gid => "$ryhmä",

ryhmät => $ryhmät,

jäsenyys => minimi,

shell => "/bin/bash",

home => "/koti/$nimi",

vaatia => Ryhmä[$ryhmä],

exec("$name homedir":

komento => “/bin/cp -R /etc/skel /home/$nimi; /bin/chown -R $nimi:$ryhmä /koti/$nimi",

luo => "/koti/$nimi",

vaatia => Käyttäjä[$nimi],

Nyt luomaan uusi tili ota yhteyttä user_homediriin.

user_homedir("sergej":

ryhmä => "sergej",

koko nimi => "Sergej Jaremchuk",

ingroups => ["media", "admin]

Solmuista, jotka tukevat periytymistä, kuten luokkia, on erilliset kuvaukset. Kun asiakas muodostaa yhteyden Puppet-palvelimeen, vastaava solmuosa etsitään ja vain tätä tietokonetta koskevat asetukset tarjotaan. Voit kuvata kaikkia muita järjestelmiä käyttämällä solmun oletusarvoa. Kuvaus kaikista tyypeistä on "Type Reference" -dokumentissa, joka on joka tapauksessa luettava, ainakin jotta ymmärrät kaikki Nukke-kielen ominaisuudet. Erilaisia tyyppejä antaa sinun suorittaa määrättyjä komentoja, mukaan lukien tietyt ehdot täyttyvät (esimerkiksi konfigurointitiedoston muuttaminen), työskennellä cronin, käyttäjätietojen ja ryhmien, tietokoneiden, asennusresurssien, palveluiden käynnistämisen ja pysäyttämisen, pakettien asentamisen, päivittämisen ja poistamisen, työskentelyn kanssa SSH-avaimet, Solaris-alueet ja niin edelleen. Näin helppoa on pakottaa apt-jakeluissa olevien pakettien luettelo päivittämään päivittäin 2-4 tunnin välein.

aikataulu (päivittäin:

ajanjakso => päivittäin,

alue =>

exec("/usr/bin/apt-get update":

aikataulu => päivittäin

Kukin järjestelmä suorittaa kyseisen ajanjakson päivityksen vain kerran, minkä jälkeen tehtävä katsotaan suoritetuksi ja se poistetaan asiakastietokoneelta. Puppet-kieli tukee muita tuttuja rakenteita: ehtoja, funktioita, taulukoita, kommentteja ja vastaavia.

Puppetin asentaminen

Puppet vaatii Rubyn (>= 1.8.1) OpenSSL-tuella ja XMLRPC-kirjastoilla sekä Faster-kirjaston [ http://reductivelabs.com/projects/facter]. Testiasennuksessa käytetty Ubuntu 7.04 -varasto sisälsi jo pentupaketin.

$ sudo apt-cache hakunukke

nukke — verkkojen keskitetty konfiguraatiohallinta

puppetmaster - keskitetty kokoonpanonhallinnan ohjausdemoni

Asennuksen aikana asennetaan kaikki tarvittavat riippuvuuspaketit: facter libopenssl-ruby libxmlrpc-ruby.

$ sudo apt-get asenna puppet puppetmaster

Voit tarkistaa Ruby-kirjastojen saatavuuden komennolla.

$ ruby -ropenssl -e "puts:yep"

~$ ruby -rxmlrpc/client -e "puts:yep"

Jos virheitä ei vastaanoteta, kaikki tarvitsemasi on jo mukana. Tiedostoja, jotka kuvaavat haluttua järjestelmän kokoonpanoa, kutsutaan Puppet-terminologiassa manifesteiksi. Kun daemon käynnistetään, se yrittää lukea tiedostoa /etc/puppet/manifests/site.pp; jos se puuttuu, se näyttää varoitusviestin. Testattaessa voit käskeä demonin toimimaan offline-tilassa, jolloin manifestia ei tarvita

$ sudo /usr/bin/puppetmasterd --nonodes

Tarvittaessa voit yhdistää muita tiedostoja site.pp:hen, esimerkiksi luokkakuvauksilla. Testausta varten voit kirjoittaa tähän tiedostoon yksinkertaisimmat ohjeet.

file("/etc/sudoers":

omistaja => root,

ryhmä => juuri,

Kaikki sekä palvelimen että asiakkaiden asetustiedostot sijaitsevat hakemistossa /etc/puppet. Fileserver.conf-tiedosto, josta puhuimme edellä, on valinnainen ja sitä käytetään vain, jos Puppet toimii myös tiedostopalvelimena. Ubuntussa tämä tiedosto vie /etc/puppet/files-alihakemiston. ssl-alihakemisto sisältää varmenteita ja avaimia, joita käytetään salaukseen liitettäessä asiakkaita. Avaimet luodaan automaattisesti, kun käynnistät puppetmasterdin ensimmäisen kerran; voit luoda ne manuaalisesti komennolla.

$ sudo /usr/bin/ puppetmasterd --mkusers.

puppetd.conf- ja puppetmasterd.conf-tiedostot ovat samanlaisia. Ne osoittavat joitain parametreja demonien toiminnalle asiakasjärjestelmässä ja palvelimessa. Asiakastiedosto eroaa vain palvelinparametrin läsnäolosta, joka osoittaa tietokoneeseen, jossa puppetmasterd on käynnissä.

palvelin = grinder.com

logdir = /var/log/puppet

vardir = /var/lib/nukke

rundir = /var/run

# lähetä raportti palvelimelle

Voit välttää kaiken kirjoittamisen manuaalisesti luomalla mallin käyttämällä itse puppetd-ohjelmaa.

$ puppetd --genconfig > /etc/puppet/puppetd.conf

Vastaavasti voit luoda site.pp:n palvelimelle.

$ puppetd --genmanifest > /etc/puppet/manifests/site.pp

Toinen tiedosto, tagmail.conf, antaa sinun määrittää sähköpostiosoitteet, joihin raportit lähetetään. Yksinkertaisimmassa tapauksessa voit käyttää yhtä riviä.

kaikki: [sähköposti suojattu]

Asetustiedostot eivät riitä, jotta asiakas voi muodostaa yhteyden palvelimeen. Tätä varten sinun on myös allekirjoitettava todistukset. Anna palvelimelle ensin tieto asiakasjärjestelmän uudesta tietokoneesta antamalla komento:

$ sudo puppetd --server grinder.com --waitforcert 60 --test

info: Todistuksen pyytäminen

varoitus: vertaisvarmennetta ei vahvisteta tässä SSL-istunnossa

huomautus: Ei saanut todistusta

Jos palautetaan eri rivi, kannattaa tarkistaa palvelimen toiminta.

$ ps aux | grep-nukke

nukke 5779 0,0 1,4 27764 15404 ? Ssl 21:49 0:00 ruby/usr/sbin/puppetmasterd

Palomuurin on sallittava yhteydet portissa 8140.

Palvelimella saamme luettelon varmenteista, jotka täytyy allekirjoittaa.

$ sudo puppetca --list

nomad.grinder.com

Ja allekirjoitamme asiakastodistuksen.

$ sudo puppetca -merkki nomad.grinder.com

Nyt asiakas voi vapaasti muodostaa yhteyden palvelimeen ja vastaanottaa asetuksia.

Valitettavasti ei yksinkertaisesti ole mahdollista näyttää kaikkia Puppetin ominaisuuksia artikkelissa. Mutta kuten näet, tämä on toimiva ja joustava työkalu, jonka avulla voit ratkaista suurimman osan ongelmista, jotka liittyvät useiden järjestelmien samanaikaiseen hallintaan. Jos työsi edellyttää useiden järjestelmien asentamista. Ja mikä tärkeintä, projekti onnistui kokoamaan pienen mutta jatkuvasti kasvavan yhteisön. Siksi toivotaan, että hyvän idean ei anneta kuolla tai mennä sivuun.

Nukke on monialustainen rakenne, joka mahdollistaa järjestelmänvalvojat Suorita yleisiä tehtäviä koodin avulla. Koodin avulla voit suorittaa erilaisia tehtäviä uusien ohjelmien asentamisesta tiedostojen käyttöoikeuksien tarkistamiseen tai käyttäjätilien päivittämiseen. Nukke ylivoimainen ei vain järjestelmän alkuasennuksen aikana, vaan koko järjestelmän elinkaaren ajan. Useimmissa tapauksissa nukke käytetään asiakas/palvelin-kokoonpanossa.

Tämä osa näyttää asennuksen ja konfiguroinnin Nukke asiakas/palvelin-kokoonpanossa. Tämä yksinkertainen esimerkki havainnollistaa asennuksen Apache käyttämällä Nukke.

Asennus

Asennusta varten Nukke syötä terminaaliin:

Sudo apt-get install puppetmaster

Kirjoita asiakaskoneisiin:

Sudo apt-get install nukke

asetukset

Ennen nuken asettamista kannattaa ehkä lisätä merkintä DNS CNAME varten nukke.esimerkki.fi, Missä esimerkki.fi- tämä on verkkotunnuksesi. Oletusasiakkaat Nukke tarkista nukkepalvelimen nimeksi DNS osoitteelle puppet.example.com ( Nukke mestari). Katso Domain Name Service lisätietoja DNS:n käytöstä.

Jos et aio käyttää DNS:ää, voit lisätä merkintöjä palvelimen ja asiakkaan /etc/hosts-tiedostoon. Esimerkiksi /etc/hosts-tiedostossa Nukke palvelin lisäys:

127.0.0.1 localhost.localdomain localhost nukke 192.168.1.17 meercat02.example.com meercat02

Jokaisella Nukke Lisää asiakassovellukseen merkintä palvelimelle:

192.168.1.16 meercat.example.com meercat puppet

Vaihda IP-osoitteet ja domain-nimet esimerkistä nykyisiin osoitteisiin ja palvelimen ja asiakkaiden nimiin.

Määritetään nyt joitain resursseja apache2. Luo tiedosto /etc/puppet/manifests/site.pp sisältää seuraavat:

Paketti ( "apache2": varmistaa => asennettu) palvelu ( "apache2": varmistaa => true, enable => true, vaadi => Paketti["apache2"] )

Solmu "meercat02.example.com" (sisältää apache2:n)

Korvata meercat02.example.com nykyiselle nimellesi Nukke asiakas.

Viimeinen vaihe tähän yksinkertaiseen Nukke palvelin käynnistää palvelun uudelleen:

Sudo /etc/init.d/puppetmaster käynnistyy uudelleen

Nyt päälle Nukke kaikki on määritetty palvelimella ja on aika määrittää asiakas.

Ensin määritetään palvelu Nukke agentti käynnistää. Muokkaa /etc/default/puppet ja korvaa arvon ALKAA päällä Joo:

Sudo /etc/init.d/puppet start

Palataan asiaan Nukke palvelin allekirjoittaa asiakassertifikaatin komennolla:

Sudo puppetca --sign meercat02.example.com

Tarkistaa /var/log/syslog asetusvirheiden varalta. Jos kaikki meni hyvin, paketti apache2 ja sen riippuvuudet asennetaan Nukke asiakas.

Tämä esimerkki on hyvin yksinkertainen, eikä siinä näy monia ominaisuuksia ja etuja. Nukke. varten lisäinformaatio Katso

Sergei Yaremchuk

UNIX-järjestelmien keskitetty konfigurointi Puppetin avulla

Suuren määrän UNIX-järjestelmien hallintaa ei voida kutsua käteväksi. Yhden parametrin muuttamiseksi järjestelmänvalvojan on otettava yhteyttä jokaiseen koneeseen; komentosarjat voivat auttaa vain osittain, eivätkä kaikissa tilanteissa.

On huomattava, että Windows-verkon ylläpitäjät ovat edelleen edullisemmassa asemassa. Riittää, kun muutat ryhmäkäytäntöasetuksia, ja hetken kuluttua kaikki verkossa olevat tietokoneet, myös ne, joissa on äskettäin asennettu käyttöjärjestelmä, "ottavat" selvää innovaatiosta, jos se tietysti koskee heitä. Kun katsot taaksepäin UNIX-kehityksen pitkää ajanjaksoa, voit nähdä, että mikään tällainen ei koskaan tarttunut. On olemassa ratkaisuja, kuten kickstart, jotka auttavat käyttöjärjestelmän alkuasennuksessa, mutta jatkokehitys vaatii paljon vaivaa. Kaupalliset ratkaisut, kuten BladeLogic ja OpsWare, ratkaisevat asetusten automatisoinnin ongelman vain osittain; niiden tärkein etu on graafisen käyttöliittymän olemassaolo, ja vain suurilla organisaatioilla on varaa ostaa niitä. Tietysti on projekteja, jotka tarjoavat ilmaisia ratkaisuja, mutta koko olemassaolonsa aikana ne eivät ole kyenneet luomaan suurta yhteisöä. Esimerkiksi Cfengine ei ole kovin suosittu järjestelmänvalvojien keskuudessa, vaikka Linuxin lisäksi sitä voidaan käyttää *BSD:ssä, Windowsissa ja Mac OS X:ssä. Tämä voi johtua kokoonpanojen luomisen suhteellisen monimutkaisuudesta. Tehtäviä kuvattaessa on tarpeen ottaa huomioon kunkin tietyn järjestelmän ominaisuudet ja ohjata manuaalisesti toimintojen järjestystä komentoja suoritettaessa. Eli järjestelmänvalvojan on muistettava, että joissakin järjestelmissä sinun tulee kirjoittaa adduser, toisille - useradd, ottaa huomioon tiedostojen sijainti eri järjestelmissä ja niin edelleen. Tämä vaikeuttaa komentojen kirjoitusprosessia suuruusluokkaa; oikean kokoonpanon luominen lennossa on erittäin vaikeaa, ja luotuja kokoonpanoja on lähes mahdotonta lukea hetken kuluttua. GPL-lisenssistä huolimatta Cfengine on pohjimmiltaan yhden miehen projekti, joka hallitsee kaikkia muutoksia eikä ole kovin kiinnostunut avoimen yhteiskunnan rakentamisesta. Tämän seurauksena Cfenginen ominaisuudet ovat varsin tyydyttävät kehittäjälle, mutta muille ylläpitäjille se on ylimääräinen päänsärky. Cfenginen parantamiseksi kolmannen osapuolen kehittäjät loivat erilaisia lisäosia, jotka usein vain pahensivat tilannetta. Useiden Cfenginen moduulien kirjoittaja Luke Kanies päätti lopulta kehittää samanlaisen työkalun, mutta ilman monia Cfenginen puutteita.

Nuken ominaisuudet

Puppet, kuten Cfengine, on asiakas-palvelinjärjestelmä, joka käyttää deklaratiivista kieltä kuvaamaan tehtäviä ja kirjastoja niiden toteuttamiseksi. Asiakkaat muodostavat ajoittain (oletuksena 30 minuutin välein) yhteyden keskuspalvelimeen ja vastaanottavat uusimmat asetukset. Jos vastaanotetut asetukset eivät vastaa järjestelmän tilaa, ne suoritetaan ja tarvittaessa lähetetään raportti suoritetuista toiminnoista palvelimelle. Viestipalvelin voi tallentaa sen syslogiin tai tiedostoon, luoda RRD-kaavion ja lähettää sen määritettyyn sähköpostiin. Muut Transaction- ja Resource Abstraction -tasot tarjoavat maksimaalisen yhteensopivuuden olemassa olevien asetusten ja sovellusten kanssa, jolloin voit keskittyä järjestelmäobjekteihin huolehtimatta eroista yksityiskohtaisten komentojen ja tiedostomuotojen toteutuksessa ja kuvauksessa. Ylläpitäjä toimii vain objektityypin kanssa, Puppet hoitaa loput. Pakettityyppi tuntee siis noin 17 pakettijärjestelmää, joista tarvittava tunnistetaan automaattisesti jakelun tai järjestelmän versiotietojen perusteella, vaikka paketinhallinta voidaan tarvittaessa asettaa väkisin.

Toisin kuin komentosarjat, joita ei useinkaan voida käyttää muissa järjestelmissä, kolmannen osapuolen järjestelmänvalvojien kirjoittamat Puppet-kokoonpanot toimivat useimmiten ilman ongelmia missään muussa verkossa. Puppet CookBookissa on jo kolme tusinaa valmiita reseptejä. Puppet tukee tällä hetkellä virallisesti seuraavia käyttöjärjestelmiä ja palveluita: Debian, RedHat/Fedora, Solaris, SUSE, CentOS, Mac OS X, OpenBSD, Gentoo ja MySQL, LDAP.

Nukkekieli

Jotta pääset eteenpäin, sinun on ensin ymmärrettävä kielen peruselementit ja ominaisuudet. Kieli on yksi Puppetin vahvuuksista. Se kuvaa resursseja, joita järjestelmänvalvoja aikoo hallita, ja heidän suorittamiaan toimia. Toisin kuin useimmat samankaltaiset ratkaisut, Puppet sallii kielen yksinkertaistaa pääsyn kaikkiin samanlaisiin resursseihin missä tahansa järjestelmässä heterogeenisessä ympäristössä. Resurssin kuvaus koostuu yleensä nimestä, tyypistä ja määritteistä. Osoitetaan esimerkiksi /etc/passwd-tiedostoa ja asetetaan sen attribuutit:

file("/etc/passwd":

Omistaja => juuri,

Ryhmä => juuri,

tila => 644,

Nyt palvelimeen yhdistävät asiakkaat kopioivat /etc/passwd-tiedoston ja asettavat määritetyt attribuutit. Voit määrittää useita resursseja yhdessä säännössä erottamalla ne puolipisteellä. Mutta entä jos palvelimella käytetty asetustiedosto eroaa asiakaskoneista tai sitä ei käytetä ollenkaan? Tämä tilanne voi syntyä esimerkiksi VPN-yhteyksiä määritettäessä. Tässä tapauksessa sinun tulee osoittaa tiedostoon lähdedirektiivin avulla. Tässä on kaksi vaihtoehtoa: voit tavalliseen tapaan määrittää polun toiseen tiedostoon ja käyttää myös kahta tuettua URI-protokollaa: tiedosto ja nukke. Ensimmäisessä tapauksessa käytetään linkkiä ulkoiseen NFS-palvelimeen, toisessa käynnistetään NFS-tyyppinen palvelu Puppet-palvelimelle, joka vie resursseja. Jälkimmäisessä tapauksessa oletuspolku on suhteessa nukkepäähakemistoon – /etc/puppet. Eli linkki puppet://server.domain.com/config/sshd_config vastaa tiedostoa /etc/puppet/config/sshd_config. Voit ohittaa tämän hakemiston käyttämällä filebucket-direktiiviä, vaikka onkin oikein käyttää samannimistä osaa /etc/puppet/fileserver.conf-tiedostossa. Tässä tapauksessa voit rajoittaa pääsyn palveluun vain tiettyihin osoitteisiin. Kuvataan esimerkiksi asetusosio:

Polku /var/puppet/config

Salli *.domain.com

Salli 127.0.0.1

Salli 192.168.0.*

Salli 192.168.1.0/24

Estä *.wireless.domain.com

Ja sitten viitataan tähän osioon kuvattaessa resurssia:

lähde => "puppet://server.domain.com/config/sshd_config"

Ennen kaksoispistettä on resurssin nimi. Yksinkertaisimmissa tapauksissa voit määrittää nimeksi tiedoston koko polun. Monimutkaisemmissa kokoonpanoissa on parempi käyttää aliasta tai muuttujia. Alias asetetaan käyttämällä aliasdirektiiviä:

file("/etc/passwd":

Alias => passwd

Toinen vaihtoehto aliaksen luomiseen on hyvä, kun joudut käsittelemään erilaisia käyttöjärjestelmiä. Luodaan esimerkiksi resurssi, joka kuvaa sshd_config-tiedostoa:

tiedosto (sshdconfig:

Nimi => $käyttöjärjestelmä ? (

Solaris => "/usr/local/etc/ssh/sshd_config",

Oletus => "/etc/ssh/sshd_config"

Tässä esimerkissä olemme valinnan edessä. Solariksen tiedosto määritetään erikseen, kaikille muille valitaan tiedosto /etc/ssh/sshd_config. Nyt tätä resurssia voidaan käyttää nimellä sshdconfig, käyttöjärjestelmästä riippuen haluttu polku valitaan. Osoitamme esimerkiksi, että jos sshd-daemon on käynnissä ja uusi tiedosto vastaanotetaan, palvelu tulee käynnistää uudelleen:

palvelu (sshd:

Varmista => totta,

Tilaa => Tiedosto

Muuttujia käytetään usein käytettäessä käyttäjätietoja. Kuvaamme esimerkiksi käyttäjien kotihakemistojen sijainnin:

$homeroot = "/home"

Nyt tietyn käyttäjän tiedostot ovat käytettävissä seuraavasti:

$(homeroot)/$nimi

Parametri $name täytetään käyttäjän tilin nimellä. Joissakin tapauksissa on kätevää määrittää oletusarvo jollekin tyypille. Esimerkiksi exec-tyypille on hyvin yleistä määrittää hakemistot, joista sen tulee etsiä suoritettavaa tiedostoa:

Exec ( polku => "/usr/bin:/bin:/usr/sbin:/sbin")

Jos sinun on osoitettava useita sisäkkäisiä tiedostoja ja hakemistoja, voit käyttää recurse-parametria:

file("/etc/apache2/conf.d":

Lähde => "puppet:// puppet://server.domain.com/config/apache/conf.d",

Recurse => "tosi"

Useita resursseja voidaan yhdistää luokiksi tai määritelmiksi. Luokat ovat täydellinen kuvaus järjestelmästä tai palvelusta, ja niitä käytetään erikseen:

luokan linux (

Tiedosto (

"/etc/passwd": omistaja => juuri, ryhmä => juuri, tila => 644;

"/etc/shadow": omistaja => juuri, ryhmä => juuri, tila => 440

luokan freebsd perii Linuxin (

Tiedosto["/etc/passwd"] ( ryhmä => pyörä );

Tiedosto["/etc/shadow"] ( ryhmä => pyörä )

Mukavuussyistä kaikki luokat voidaan sijoittaa erilliseen tiedostoon, joka on sisällytettävä include-direktiivin avulla. Määritelmät voivat ottaa useita parametreja argumenteiksi, mutta ne eivät tue periytymistä, ja niitä käytetään, kun sinun on kuvattava uudelleenkäytettäviä objekteja. Määritetään esimerkiksi käyttäjän kotihakemisto ja uuden tilin luomiseen tarvittavat komennot:

määritä user_homedir ($ryhmä, $kokonimi, $yhdysryhmät) (

User("$name":

Varmista => läsnä,

Kommentti => "$fullname",

Gid => "$ryhmä",

Ryhmät => $ryhmät,

Jäsenyys => minimi,

Shell => "/bin/bash",

Etusivu => "/koti/$nimi",

Require => Group[$group],

Exec("$name kotihakemisto":

Komento => "/bin/cp -R /etc/skel /home/$nimi; /bin/chown -R $nimi:$ryhmä /koti/$nimi",

Luo => "/home/$nimi",

Require => User[$name],

Luo uusi tili nyt ottamalla yhteyttä user_homediriin:

user_homedir("sergej":

Ryhmä => "sergej",

Koko nimi => "Sergej Jaremchuk",

Ingroups => ["media", " admin]

Periytymistä tukevista solmuista ja luokista on erilliset kuvaukset. Kun asiakas muodostaa yhteyden Puppet-palvelimeen, vastaava solmuosa etsitään ja vain tätä tietokonetta koskevat asetukset tarjotaan. Voit kuvata kaikkia muita järjestelmiä käyttämällä solmun oletusarvoa. Kuvaus kaikista tyypeistä on "Type Reference" -dokumentissa, joka on joka tapauksessa luettava, ainakin jotta ymmärrät kaikki Nukke-kielen ominaisuudet. Eri tyypit mahdollistavat tiettyjen komentojen suorittamisen, mukaan lukien tiettyjen ehtojen täyttyessä (esimerkiksi konfiguraatiotiedoston muuttaminen), cronin, käyttäjätietojen ja ryhmien, tietokoneiden, asennusresurssien, palveluiden käynnistämisen ja pysäyttämisen, pakettien asennuksen, päivityksen ja poistamisen. , työskentelee SSH-avainten, Solaris-vyöhykkeiden ja niin edelleen kanssa. Näin voit helposti pakottaa pakettien luettelon jakeluissa apt:lla päivittämään päivittäin 2-4 tunnin välein:

aikataulu (päivittäin:

Jakso => päivittäin,

Alue =>

exec("/usr/bin/apt-get update":

Aikataulu => päivittäin

Puppetin asentaminen

Puppet vaatii Rubyn (versio 1.8.1 ja uudemmat) OpenSSL-tuella ja XMLRPC-kirjastoilla sekä Faster-kirjaston. Testiasennuksessa käytetty Ubuntu 7.04 -varasto sisältää jo pentupaketin:

$ sudo apt-cache hakunukke

~$ ruby -rxmlrpc/client -e "puts:yep"

joo

$ sudo /usr/bin/puppetmasterd --nonodes

Tarvittaessa voit liittää muita tiedostoja site.pp:hen esimerkiksi luokkakuvauksilla. Testausta varten voit kirjoittaa tähän tiedostoon yksinkertaisimmat ohjeet.

luokan sudo(

Tiedosto("/etc/sudoers":

Omistaja => juuri,

Ryhmä => juuri,

tila => 440,

solmu oletus (

Sisällytä sudo

Kaikki asetustiedostot, sekä palvelin että asiakas, sijaitsevat hakemistossa /etc/puppet. Fileserver.conf-tiedosto, josta jo puhuimme, on valinnainen ja sitä käytetään vain, jos Puppet toimii myös tiedostopalvelimena. Ubuntussa tämä tiedosto vie /etc/puppet/files-alihakemiston. ssl-alihakemisto sisältää varmenteita ja avaimia, joita käytetään salaukseen liitettäessä asiakkaita. Avaimet luodaan automaattisesti, kun käynnistät puppetmasterdin ensimmäisen kerran; voit luoda ne manuaalisesti komennolla:

$ sudo /usr/bin/puppetmasterd --mkusers

palvelin = grinder.com

logdir = /var/log/puppet

vardir = /var/lib/nukke

rundir = /var/run

# lähetä raportti palvelimelle

raportti = totta

Voit välttää kaiken kirjoittamisen manuaalisesti luomalla mallin käyttämällä itse puppetd-ohjelmaa:

$ puppetd --genconfig > /etc/puppet/puppetd.conf

Vastaavasti voit luoda site.pp:n palvelimelle:

$ puppetd --genmanifest > /etc/puppet/manifests/site.pp

Toinen tiedosto, tagmail.conf, antaa sinun määrittää sähköpostiosoitteet, joihin raportit lähetetään. Yksinkertaisimmassa tapauksessa voit käyttää yhtä riviä:

kaikki: [sähköposti suojattu]

Asetustiedostot eivät riitä, jotta asiakas voi muodostaa yhteyden palvelimeen. Tätä varten sinun on myös allekirjoitettava todistukset.

Anna palvelimelle ensin tieto uudesta tietokoneesta kirjoittamalla komento asiakasjärjestelmään:

$ sudo puppetd --server grinder.com --waitforcert 60 -test

Palomuurin on sallittava yhteydet portissa 8140.

Palvelimella saamme luettelon varmenteista, jotka on allekirjoitettava:

$ sudo puppetca -lista

nomad.grinder.com

Ja allekirjoita asiakastodistus:

$ sudo puppetca -merkki nomad.grinder.com

Nyt asiakas voi vapaasti muodostaa yhteyden palvelimeen ja vastaanottaa asetuksia.

Valitettavasti on mahdotonta näyttää kaikkia Puppetin ominaisuuksia artikkelissa. Mutta kuten näet, tämä on toimiva ja joustava työkalu, jonka avulla voit ratkaista suurimman osan ongelmista, jotka liittyvät useiden järjestelmien samanaikaiseen hallintaan. Ja mikä tärkeintä, projekti onnistui kokoamaan pienen mutta jatkuvasti kasvavan yhteisön. Siksi toivotaan, että hyvän idean ei anneta kuolla tai mennä sivuun.

Onnea!