1. Wprowadzenie do Puppet
Administratorzy systemu często utkną w serii powtarzalnych zadań: aktualizacji pakietów, zarządzaniu plikami konfiguracyjnymi, usługach systemowych, zadaniach cron, dodawaniu nowych konfiguracji, poprawianiu błędów itd. Te zadania są często powtarzalne i nieefektywne, a pierwszą reakcją na ich rozwiązanie jest ich automatyzacja, dlatego pojawiają się niestandardowe skrypty. Ze względu na złożoność środowiska, niestandardowe skrypty i aplikacje są wielokrotnie tworzone i trudno jest dopasować do wielu platform, a elastyczność i funkcjonalność są trudne do zagwarantowania, dlatego pojawiły się zautomatyzowane narzędzia do zarządzania konfiguracją, takie jak Puppet.
W świecie open source dostępnych jest wiele narzędzi konfiguracyjnych, a niektóre z kluczowych produktów w tej dziedzinie to:
Puppet (http://puppet.reductivelabs.com/): Narzędzie do zarządzania konfiguracją napisane w Ruby, które wykorzystuje architekturę C/S do konfigurowania klienta w języku deklaratywnym.
Cfengine (http://www.cfengine.org): Jedno z pierwszych otwartych narzędzi konfiguracyjnych, wydane w 1993 roku, jest również architekturą C/S, zwykle stosowaną w instytucjach edukacyjnych.
LCFG(http://www.lcfg.org/): Narzędzie do zarządzania konfiguracją dla architektur C/S, które wykorzystuje XML do definiowania konfiguracji.
Bcfg2: Narzędzie do zarządzania konfiguracją dla architektury C/S napisane w Pythonie, które wykorzystuje specyfikacje i odpowiedzi klientów do konfiguracji docelowego hosta.
Ten dokument poświęcony jest opisowi, jak korzystać z Puppet do zarządzania hostem, aplikacjami, programami w tle oraz różnymi usługami.
O Puppet:
1. Do czego służy Puppet?
Puppet to otwartoźródłowe narzędzie do zarządzania konfiguracją systemu oparte na Ruby, które opiera się na architekturze wdrożeń C/S. Głównym deweloperem jest Luke Kanies, który korzysta z licencji praw autorskich GPLv2. Od 1997 roku Kanies zajmuje się administracją systemu UNIX, a rozwój Puppet wynikał z tego doświadczenia. Niezadowolony z dostępnych narzędzi konfiguracyjnych, Kanies rozpoczął opracowywanie narzędzi w laboratorium redukcyjnym w latach 2001–2005. Wkrótce Reductive Labs wypuściło swój flagowy produkt, Puppet.
2. Cechy pupput
Wiele narzędzi do zarządzania konfiguracją systemu działa bardzo podobnie, na przykład cfengine. Co wyróżnia Puppet?
Składnia Puppet pozwala utworzyć osobny skrypt do budowania użytkownika na wszystkich docelowych hostach. Wszystkie docelowe hosty interpretują i wykonują moduł kolejno, korzystając ze składni odpowiedniej dla systemu lokalnego. Na przykład, jeśli taka konfiguracja jest wykonywana na serwerze Red Hat, utworz użytkownika za pomocą polecenia useradd; Jeśli taka konfiguracja jest wykonywana na hostie FreeBSD, używa się polecenia adduser.
Kolejnym niezwykłym aspektem Puppet jest jego elastyczność. Ze względu na charakter oprogramowania open source możesz swobodnie pobierać kod źródłowy Puppet, a jeśli napotkasz problemy i masz taką możliwość, możesz zmodyfikować lub ulepszyć kod Puppet, aby dopasował go do swojego środowiska. Ponadto deweloperzy społeczności i darczyńcy nadal rozwijają możliwości Puppet. Duża społeczność deweloperów i użytkowników również angażuje się w dostarczanie dokumentacji i wsparcia technicznego dla Puppet.
Puppet jest też łatwy do skalowania. Wsparcie dla niestandardowych pakietów oraz specjalne konfiguracje środowisk systemowych można szybko i łatwo dodać do instalatora Puppet.
3. Tryb pracy marionetek
Puppet to narzędzie do zarządzania konfiguracją architektury C/S, które instaluje pakiet puppet-server (znany jako Puppet master) na centralnym serwerze. Zainstaluj oprogramowanie klienta Puppet (nazywane Puppet Client) na docelowym hostie, który wymaga zarządzania. Gdy klient łączy się z Puppet masterem, plik konfiguracyjny zdefiniowany na Puppet masterze jest kompilowany i następnie uruchamiany na kliencie. Domyślnie każdy klient komunikuje się z serwerem co pół godziny, aby potwierdzić aktualizację informacji konfiguracyjnych. Jeśli pojawią się nowe informacje konfiguracyjne lub zostały zmienione, konfiguracja zostanie ponownie skompilowana i opublikowana dla każdego klienta do wykonania. Możesz też aktywnie wywołać aktualizację informacji konfiguracyjnych na serwerze, aby zmusić każdego klienta do ich konfiguracji. Jeśli informacje konfiguracyjne klienta zostaną zmienione, może on uzyskać oryginalną konfigurację od serwera, aby ją poprawić.
Zarządzanie konfiguracją: Instalacja i użycie marionetek (1)
4. Przyszłość Puppet
Wreszcie, Puppet to młode narzędzie, które wciąż jest w fazie rozwoju. Społeczność Puppet szybko się rozwija, a wiele nowych pomysłów jest nieustannie wprowadzanych, co skłania do codziennego rozwoju, aktualizacji i prezentacji modułów.
2. Konfiguracja i instalacja (Puppet 2.6.4 CentOS 5.4):
Konfiguruj repozytorium na serwerze marionetkowym i kliencie:
obroty -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm
[root@puppetmaster ~]# vi /etc/yum.repos.d/epel.repo
Dodaj do:
[epel-puppeta]
imię=epel puppet
baseurl=http://tmz.fedorapeople.org/repo/puppet/epel/5/$basearch/
enabled=0
gpgcheck=0
Dodaj repozytorium puppet.repo:
[root@puppetmaster ~]# vi /etc/yum.repos.d/puppet.repo
[lalkowe laboratorium]
nazwa=Pakiety Puppet Labs
baseurl=http://yum.puppetlabs.com/base/
enabled=0
gpgcheck=0
Instalacja Mistrza Marionetek:
[root@puppetmaster ~]# yum --enablerepo=epel,epel-puppet install puppet-server
Zmodyfikuj hosty i dodaj następujące dwa rekordy:
[root@puppetmaster ~]# vi /etc/hosts
192.168.0.10 puppetmaster.leju.com marionetka
192.168.0.100 puppetclient.leju.com
Konfiguracja marionetek:
[root@puppetmaster ~]# cd /etc/puppet/
[root@puppetmaster puppet]# vi puppet.conf
[główny]
# Katalog Księgi Lalek.
# Domyślna wartość to '$vardir/log'.
logdir = /var/log/puppet
# Gdzie przechowywane są pliki PID marionetek.
# Domyślna wartość to '$vardir/run'.
rundir = /var/biegnij/marionetka
# Gdzie przechowywane są certyfikaty SSL.
# Domyślna wartość to '$confdir/ssl'.
SSLDir = $vardir/SSL
[agent]
# Plik, w którym puppetd przechowuje listę klas
# związane z odzyskaną konfiguracją. Można załadować
# oddzielny plik wykonywalny "puppet" z użyciem klas ładowania "---loadclass"
# opcja.
# Domyślna wartość to '$confdir/classes.txt'.
Classfile = $vardir/classes.txt
# Gdzie puppetd buforuje lokalną konfigurację. An
rozszerzenie # oznaczające format pamięci podręcznej jest dodawane automatycznie.
# Domyślna wartość to '$confdir/localconfig'.
localconfig = $vardir/localconfig
serwer = puppetmaster.leju.com
raport = prawdziwy
słuchać = prawda
[mistrz]
ssl_client_header = SSL_CLIENT_S_DN
ssl_client_verify_header = SSL_CLIENT_VERIFY
autosign = prawdziwy
raporty = Przechowywanie
[root@puppetmaster puppet]# vi fileserver.conf
[pliki]
path /etc/puppet/files
Pozwól *
[moduły]
Pozwól *
[wtyczki]
Pozwól *
[root@puppetmaster kukiełka]# mkdir /etc/puppet/files
[root@puppetmaster lalka] # manifesty CD/
Utwórz site.pp, czyli plik konfiguracyjny dla lalkowych wpisów:
[root@puppetmaster manifests]# vi site.pp
import "modules.pp"
import "roles.pp"
importuj "nodes.pp"
# Ogólne ustawienia dla typów standardowych
Exec { path => "/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin" }
filebucket { main: server => "puppetmaster.leju.com" }
Plik { backup => main }
Utwórz modules.pp, aby importować moduły:
[root@puppetmaster manifests]# vi modules.pp
Import "test"
Utwórz roles.pp, aby zdefiniować role serwera:
[root@puppetmaster manifestuje]# vi roles.pp
klasa podstawowa {
include test
}
Utwórz nodes.pp, aby skonfigurować węzły serwera:
[root@puppetmaster manifests]# vi nodes.pp
węzeł 'basenode' {
include baseclass
}
Węzeł 'puppetclient.leju.com' dziedziczy Basenode {
tag("test")
}
Węzeł 'puppetmaster.leju.com' dziedziczy Basenode {
tag("test")
}
[root@puppetmaster manifestuje]# cd ..
[root@puppetmaster lalka]# Moduły mkdir
Stwórz moduł testowy:
[root@puppetmaster modułów]# mkdir -p test/manifesty/
[root@puppetmaster modułów]# mkdir test/pliki/
[root@puppetmaster moduły]# test płyty/pliki/
[root@puppetmaster pliki]# vi test.txt
Linia testowa!
[root@puppetmaster plików]# cd .. /manifests/
Stwórz klasę testową, aby dostarczyć plik klientowi:
[root@puppetmaster manifestuje]# vi init.pp
Test klasy {
plik { "/tmp/test.txt":
zapewnić => obecny,
grupa => "korzeń",
właściciel => "korzeń",
tryb => "0644",
źródło => "puppet:///test/test.txt"
}
}
Wprowadzenie Puppet Mastera:
[root@puppetmaster manifestuje]# /etc/init.d/puppetmaster start
Upewnij się, że port 8140 jest włączony.
Instalacja klienta marionetek:
[root@puppetclient ~]# yum --enablerepo="epel,epel-puppet" install puppet
Zmodyfikuj hosty i dodaj następujące dwa rekordy:
[root@puppetclient ~]# vi /etc/hosts
192.168.0.10 puppetmaster.leju.com marionetka
192.168.0.100 puppetclient.leju.com
Konfiguracja marionety:
[root@puppetclient ~]# cd /etc/puppet/
[root@puppetclient puppet]# vi puppet.conf
[główny]
# Katalog Księgi Lalek.
# Domyślna wartość to '$vardir/log'.
logdir = /var/log/puppet
# Gdzie przechowywane są pliki PID marionetek.
# Domyślna wartość to '$vardir/run'.
rundir = /var/biegnij/marionetka
# Gdzie przechowywane są certyfikaty SSL.
# Domyślna wartość to '$confdir/ssl'.
SSLDir = $vardir/SSL
[agent]
# Plik, w którym puppetd przechowuje listę klas
# związane z odzyskaną konfiguracją. Można załadować
# oddzielny plik wykonywalny "puppet" z użyciem klas ładowania "---loadclass"
# opcja.
# Domyślna wartość to '$confdir/classes.txt'.
Classfile = $vardir/classes.txt
# Gdzie puppetd buforuje lokalną konfigurację. An
rozszerzenie # oznaczające format pamięci podręcznej jest dodawane automatycznie.
# Domyślna wartość to '$confdir/localconfig'.
localconfig = $vardir/localconfig
serwer = puppetmaster.leju.com
raport = prawdziwy
słuchać = prawda
[root@puppetclient puppet]# vi namespaceauth.conf
[Puppetrunner]
Pozwól puppetmaster.leju.com
pozwól *.leju.com
[root@puppetclient lalka] # vi auth.conf
Dodaj pozwól * do ostatniej linii
......
Ścieżka /
auth dowolny
Pozwól *
[root@puppetclient kukiełka] # CD
Wykonaj marionetkę:
[root@puppetclient ~]# marionetka --noop --test --śledzenie --debugowanie
Jeśli Puppet Master nie ustawi: autosign=true, musi zostać wykonany w Puppet Master:
[root@puppetmaster ~]# certyfikat marionetek -l
puppetclient.leju.com
[root@puppetmaster ~]# certyfikat marionetek -s puppetclient.leju.com
Podpisz puppetclient.leju.com tak. Następnie wróć do klienta, aby wykonać tutaj:
[root@puppetclient ~]# marionetka --noop --test --śledzenie --debugowanie
Join — nie, konfiguracja nie zostanie faktycznie zastosowana na kliencie, głównie służy do testowania, sprawdzania, czy w wydruku nie ma błędów, i wykonania bez błędów:
[root@puppetclient ~]# marionetka --test --trace --debug
Zobacz dokument:
[root@puppetclient ~]# ll /tmp/
łącznie 8
-rw-r--r-- 1 korzeń 11 lut 25 22:35 test.txt
Dokument został wydany.
Możliwe jest także naciskanie na Puppet Mastera:
[root@puppetmaster ~]# puppet kick -d --prowadzący puppetclient.leju.com
Wywołujące puppetclient.leju.com
Zdobywanie statusu
Status to sukces
puppetclient.leju.com zakończył z kodem wyjścia 0
Ukończone
Zwracanie 0 oznacza, że kukiełka na kliencie została pomyślnie wyzwolona.
Ustaw marionetka na automatyczny start:
chkconfig --level 2345 puppet on
Zmodyfikuj Puppetmastera, aby używać Passenger
Passenger to rozszerzenie Apache 2.x do uruchamiania aplikacji Rails lub Rack w Apache. puppetmaster domyślnie używa WEBricka do świadczenia usług plikowych; jeśli masz wielu klientów puppet, wydajność usługi plików Puppetmastera będzie słaba, aby uczynić Puppetmaster bardziej odpornym, więc używaj Apache do świadczenia usług plikowych.
Instalacja:
[root@puppetmaster ~]# yum install httpd httpd-devel ruby-devel rubygems
Passenger 2.2.2 RHEL5 działa bez zarzutu.
Dodaj repozytorium foreman.repo:
[root@puppetmaster ~]# vi /etc/yum.repos.d/foreman.repo
[brygadzista]
nazwa=Repozytorium stabilnych Foremana
baseurl=http://yum.theforeman.org/stable
gpgcheck=0
enabled=1
[root@puppetmaster ~]# Mniam instalacja rubygem-passenger-2.2.2-1
[root@puppetmaster ~]# rubygem-rack-1.0.1-1
[root@puppetmaster ~]# Passenger-install-apache2-module
Instalacja modułu SSL Apache:
[root@puppetmaster ~]# pysznie instalacja mod_ssl
Aby skonfigurować aplikację Puppet rack:
mkdir -p /etc/puppet/rack/puppetmasterd/
mkdir /etc/puppet/rack/puppetmasterd/public /etc/puppet/rack/puppetmasterd/tmp
cp /usr/share/puppet/ext/rack/files/apache2.conf /etc/httpd/conf.d/puppetmasterd.conf
cp /usr/share/puppet/ext/rack/files/config.ru /etc/puppet/rack/puppetmasterd/
chown puppet /etc/puppet/rack/puppetmasterd/config.ru
[root@puppetmaster ~]# vi /etc/httpd/conf.d/passenger.conf
LoadModule passenger_module /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2/ext/apache2/mod_passenger.so
PassengerRoot /usr/lib/ruby/gems/1.8/gems/passenger-2.2.2
PassengerRuby /usr/bin/ruby
PassengerMaxPoolRozmiar 30
PassengerPoolIdleTime 1500
PassengerMaxRequests 1000
PassengerStatThrottleRate 120
RackAutoDetect wyłączony
RailsAutoDetect wyłączony
[root@puppetmaster ~]# vi /etc/httpd/conf.d/puppetmasterd.conf
# Pewnie chcesz dostroić te ustawienia
PassengerHighPerformance na
PassengerMaxPoolRozmiar 12
PassengerPoolIdleTime 1500
# PassengerMaxRequests 1000
PassengerStatThrottleRate 120
RackAutoDetect wyłączony
RailsAutoDetect wyłączony
Posłuchaj 8140
<VirtualHost *:8140>
SSLEngine on
SSLProtocol -ALL +SSLv3 +TLSv1
SSLCipherSuite WSZYSCY :! ADH:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP
SSLCertificateFile /var/lib/puppet/ssl/certs/puppetmaster.leju.com.pem
SSLCertificateKeyFile /var/lib/puppet/ssl/private_keys/puppetmaster.leju.com.pem
SSLCertificateChainFile /var/lib/puppet/ssl/ca/ca_crt.pem
SSLCACertificateFile /var/lib/puppet/ssl/ca/ca_crt.pem
# Jeśli Apache skarży się na nieprawidłowe podpisy w CRL, możesz spróbować je wyłączyć
# CRL sprawdza, komentując następną linijkę, ale nie jest to zalecane.
SSLCARevocationFile /var/lib/puppet/ssl/ca/ca_crl.pem
SSLVerifyClient opcjonalnie
SSLVerifyDepth 1
SSLOptions +StdEnvVars
# Poniższe nagłówki klienta pozwalają na działanie tej samej konfiguracji z Pound.
RequestHeader set X-SSL-Subject %{SSL_CLIENT_S_DN}e
RequestHeader set X-Client-DN %{SSL_CLIENT_S_DN}e
RequestHeader set X-Client-Verify %{SSL_CLIENT_VERIFY}e
DocumentRoot /etc/puppet/rack/puppetmasterd/public/
RackBaseURI /
<Katalog /etc/puppet/rack/puppetmasterd/>
Opcje Brak
DowolnieWyłącz brak
Rozkaz zezwala, odmawiaj
pozwól od wszystkich
</Directory>
</VirtualHost>
Zmodyfikuj plik konfiguracyjny puppetmastera, dodając następujące dwie linie:
[root@puppetmaster ~]# vi /etc/puppet/puppet.conf
[mistrz]
ssl_client_header = SSL_CLIENT_S_DN
ssl_client_verify_header = SSL_CLIENT_VERIFY
Zmodyfikuj /etc/sysconfig/puppetmaster:
[root@puppetmaster ~]# vi /etc/sysconfig/puppetmaster
# Dodaj następującą linię na końcu:
PUPPETMASTER_EXTRA_OPTS="--raportuje sklep"
Jeśli musisz raportować zarówno do brygadzisty, jak i do panelu marionetkowego, dodaj następujący punkt:
PUPPETMASTER_EXTRA_OPTS="--raportuje sklep, brygadzista, puppet_dashboard"
Zakończ usługę Puppetmaster i rozpocznij usługę Apache:
[root@puppetmaster ~]# /etc/init.d/puppetmaster stop
[root@puppetmaster ~]# /etc/init.d/httpd start
Boot nie uruchamia usługi puppetmaster, boot uruchamia usługę httpd:
[root@puppetmaster ~]# chkconfig --level 2345 puppetmaster wyłączony
[root@puppetmaster ~]# chkconfig --level 2345 httpd on
Upewnij się, że port 8140 jest włączony:
[root@puppetmaster ~]# netstat -tunlp |grep 8140
tcp 0 0 :::8140 :::* SŁUCHAJ 9834/httpd
Sprawdź po stronie klienta, czy dziennik błędów został wydrukowany:
[root@puppetclient ~]# marionetka --test --trace --debug |
Opublikowano 20.10.2014 09:47:45
|
|
|
