Jak używać modułów lalek do automatyzacji infrastruktury IT?

Wcześniej administratorzy systemów używali skryptów powłoki do uruchamiania swoich serwerów, a ta metoda miała zerową skalowalność. Ciągłe modyfikowanie skryptów dla setek lub tysięcy ciągle zmieniających się serwerów i ich konfiguracji systemowych jest trudnym zadaniem.

W tym artykule na moduły i manifesty marionetkowe zobaczmy, jak moglibyśmy wykorzystać moduły marionetkowe do automatyzacji konfiguracji serwera, instalacji programów i zarządzania systemem.

Ten blog obejmie następujące tematy:

• Wprowadzenie do programowania lalek
• Kluczowe terminy w programowaniu lalek
• Przepływ pracy programu lalek
• Demonstracja: automatyzacja instalacji Apache i MySQL

Wprowadzenie do programowania lalek

Marionetka jest jednym z popularnych narzędzi DevOps, które jest szeroko stosowane do zarządzania konfiguracją. Służy do wywoływania konsystencja w infrastrukturze. Puppet może zdefiniować infrastrukturę jako kod, zarządzać wieloma serwerami i wymuszać konfigurację systemu, pomagając w ten sposób w automatyzacji procesu zarządzania infrastrukturą.

Puppet mawłasny język konfiguracji, Puppet DSL . Podobnie jak w przypadku innych programów DevOps, Puppet automatyzuje zmiany, eliminując ręczne zmiany sterowane przez skrypty. Jednak Puppet nie jest po prostu kolejnym językiem powłoki ani czystym językiem programowania, takim jak PHP. Zamiast tego Puppet używado deklaratywne podejście oparte na modelu do automatyzacji IT. Dzięki temu Puppet może zdefiniować infrastrukturę jako kod i wymusić konfigurację systemu za pomocą programów.

Zanim przejdziemy do demonstracji, przyjrzyjmy się kilku podstawowym aspektom programowania lalek.

zastosowanie analityki dużych zbiorów danych

Kluczowe terminy w programowaniu lalek

Manifesty

Nazywa się program lalek oczywisty i ma nazwę pliku z .pp rozbudowa. Domyślnym głównym manifestem Puppet jest /etc/puppet/manifests/site.pp . (To definiujeglobalne konfiguracje systemu, takie jak konfiguracja LDAP, serwery DNS lub inne konfiguracje, które mają zastosowanie do każdego węzła).

Zajęcia

Wewnątrz tych manifestów są nazywane bloki kodu zajęcia inne moduły mogą dzwonić. Klasy konfigurują duże lub średnie fragmenty funkcjonalności, takie jak wszystkie pakiety, pliki konfiguracyjne i usługi potrzebne do uruchomienia aplikacji. Klasy ułatwiają ponowne użycie kodu Puppet i poprawiają czytelność.

Zasoby

Kod lalek składa się głównie z deklaracji zasobów. ZA ratunek opisuje konkretny element dotyczący pożądanego stanu systemu. Na przykład może zawierać informację, że powinien istnieć określony plik lub że pakiet powinien zostać zainstalowany.

Moduły lalek

Z wyjątkiem głównegosite.ppoczywisty,przechowuje manifestyw moduły .

Cały nasz kod Puppet jest zorganizowany w modułach, które są podstawowymi elementami składowymi lalki, które możemy ponownie wykorzystać i udostępniać. Każdy moduł zarządza konkretnym zadaniem w infrastrukturze, takim jak instalacja i konfiguracja oprogramowania.

Moduły zawierają klasy Puppet, zdefiniowane typy, zadania, plany zadań, możliwości, typy zasobów i wtyczki, na przykład niestandardowe typy lub fakty. Zainstaluj moduły w Puppetścieżka modułu. Puppet ładuje całą zawartość z każdego modułu w module-path, udostępniając ten kod do użytku.

Puppetlabs ma predefiniowane moduły, z których możemy korzystać natychmiast, pobierając je z PuppetForge . Możesz także stworzyć niestandardowy moduł lalek dostosowany do twoich wymagań.

Przepływ pracy programu lalek

Będziemy używać języka deklaratywnego Puppet do opisania pożądanego stanu systemu w plikach zwanych manifestami. Manifesty opisują, jak należy konfigurować zasoby sieciowe i systemu operacyjnego, takie jak pliki, pakiety i usługi.

Kompilacje Puppet manifestują się w katalogi i stosuje każdy katalog do odpowiedniego węzła, aby zapewnić tę konfigurację twęzeł jest poprawnyw całej Twojej infrastrukturze.

Demonstracja: Automatyzacja instalacji Apache i MySQL

Ten artykuł o modułach lalek jest praktyczny, który pokaże dwa sposoby korzystania z modułu lalek, a także nauczy Cię, jak to zrobić zautomatyzować instalacja serwera skonfigurowanego z tymi dwoma modułami.

• • Tworzenie modułu Puppet od podstaw - moduł Apache
  • Korzystanie z modułu Puppet z PuppetForge - moduł MySQL
  • Automatyzacja instalacji modułów marionetkowych od Puppet Master do Puppet Agent

Na początek upewnij się, że masz przygotowaną infrastrukturę Puppet, która zawierałaby główny serwer marionetek i 2 agentów marionetek.

• Mistrz marionetek: Ubuntu 18.04.0
• Agent 1: Ubuntu 18.04.2018
• Agent 2:CentOS7

Oto zarys tego, co osiągniemy w tym ćwiczeniu:

Zacznijmy więc od praktycznych rzeczy:

Tworzenie modułu od podstaw

W tym module marionetkowym zajmiemy się zadaniami takimi jak pobieranie pakietu Apache, konfigurowanie plików i konfigurowanie wirtualnych hostów.

• W Puppet Master przejdź do katalogu modułu Puppet i utwórz katalog Apache:

  cd / etc / puppet / modules sudo mkdir apache

• Z wnętrza katalogu Apache utwórz podkatalogi: manifesty, szablony, pliki i przykłady.

  cd apache sudo mkdir {manifesty, szablony, pliki, przykłady}

• Przejdź do katalogu manifestów:

  manifesty cd

• Stąd podzielimy moduł na klasy w oparciu o cele tej sekcji kodu.

init.pp -> aby pobrać pakiet Apache

params.pp -> aby zdefiniować dowolne zmienne i parametry

config.pp -> do zarządzania dowolnymi plikami konfiguracyjnymi usługi Apache.

vhosts.pp -> do zdefiniowania wirtualnych hostów.

Ten moduł będzie również korzystał z Hiera (wbudowany system wyszukiwania danych konfiguracyjnych klucz-wartość, używany do oddzielania danych od danych kodu Puppet, do przechowywania zmiennych dla każdego węzła.

Krok 1: Pobieranie pakietu Apache

Utwórz klasę init.pp

Teraz utworzymy plikinit.ppplik w katalogu manifestów, aby przechowywać pakiet Apache.
Ponieważ mamy 2 różne systemy operacyjne (ubuntu i CentOS7), które używają różnych nazw pakietów dla Apache, będziemy musieli użyć zmiennej$ apachename.

/etc/puppetlabs/code/environments/production/modules/apache/manifests/init.pp

klasa apache {pakiet {'apache': name => $ apachename, upewnij się => obecny,}}

pakiet Zasób pozwala na zarządzanie pakietem. Służy do dodawania, usuwania lub zapewniania obecności pakietu.

W większości przypadków Nazwa zasobu (apaczpowyżej) powinna być nazwą zarządzanego pakietu. Ze względu na różne konwencje nazewnictwanazywamy rzeczywistą nazwą pakietudalej z Nazwa odniesienie. Więc Nazwa , wywołuje niezdefiniowaną zmienną$ apachename.

zapewnić Reference zapewnia, że ​​pakiet jestteraźniejszość.

Utwórz plik params.pp

Plikparams.ppplik zdefiniuje potrzebne zmienne. Chociaż możemy zdefiniować te zmienne w ramachinit.ppfile, ponieważ więcej zmiennych będzie musiało być używanych poza samym typem zasobu, używając plikuparams.ppPlik umożliwia definiowanie zmiennych wJeśliinstrukcje i używane w wielu klasach.

Stwórzparams.ppplik i następujący kod.

/etc/puppetlabs/code/environments/production/modules/apache/manifests/params.pp

class apache :: params {if $ :: osfamily == 'RedHat' {$ apachename = 'httpd'} elsif $ :: osfamily == 'Debian' {$ apachename = 'apache2'} else {fail ('to nie jest obsługiwana dystrybucja. ')}}

Poza oryginałem init.ppclass, każda nazwa klasy musi się rozgałęziaćapacz. Nazywamy tę klasę apache :: params . Nazwa po podwójnym dwukropku powinna mieć wspólną nazwę z plikiem. NaJeśliinstrukcja służy do definiowania parametrów, czerpiąc z informacji dostarczonych przez Czynnik , Puppet ma facter jako część swojej instalacji. Tutaj Facter rozbije rodzinę systemów operacyjnych (rodzina), aby rozpoznać, czy tak jestczerwony kapeluszlubOparty na Debianie.

windows dodaj java do ścieżki

Po ostatecznym zdefiniowaniu parametrów musimy wywołać metodę params.pp plik i parametry doinit.pp. Aby to zrobić, musimy dodać parametry po nazwie klasy, ale przed otwierającym nawiasem klamrowym({).

Więcinit.ppktóry stworzyliśmy wcześniej, powinien wyglądać mniej więcej tak:

class apache ($ apachename = $ :: apache :: params :: apachename,) inherits :: apache :: params {pakiet {'apache': name => $ apachename, zapewnia => obecny,}}

Ciąg wartości $ :: apache :: params :: value mówi Puppet, aby pobierał wartości z pliku apacz moduły, params class, po którym następuje nazwa parametru. Fragment dziedziczy :: apache :: params pozwala nainit.ppdziedziczyć te wartości.

Krok 2: Zarządzaj plikami konfiguracyjnymi

Plik konfiguracyjny Apache będzie różny w zależności od tego, czy pracujesz na systemie opartym na Red Hacie czy Debianie.

Na końcu tej demonstracji możesz znaleźć następujące pliki zależności:httpd.conf(Czerwony kapelusz),apache2.conf(Debian).

• Skopiuj zawartość httpd.conf iapache2.confw osobnych plikach i zapisz je w formacie akta informatorw / etc / puppetlabs / code / environment / production / modules / apache / files .
• Edytuj oba pliki do wyłączyć utrzymać przy życiu. Będziesz musiał dodać linię KeepAlive Off whttpd.confplik. Jeśli nie chcesz zmieniać tego ustawienia, powinniśmy dodać komentarz na górze każdego z nichplik:
  /etc/puppetlabs/code/environments/production/modules/apache/files/httpd.conf

# Tym plikiem zarządza puppet

Dodaj te pliki doinit.ppplik, więc Puppet będzie znać lokalizację tych plików zarówno na serwerze głównym, jak i na węzłach agenta. Aby to zrobić, używamy plik ratunek.

/etc/puppetlabs/code/environments/production/modules/apache/manifests/init.pp

plik {'configuration-file': path => $ conffile, sure => file, source => $ confsource,}

Ponieważ mamy pliki konfiguracyjne w dwóch różnych lokalizacjach, nadajemy zasobowi ogólną nazwę plik konfiguracyjny z plikiem ścieżka zdefiniowany jako parametr zścieżkaatrybut.

zapewnić zapewnia, że ​​jest to plik.

źródło zapewnia lokalizację na wzorcu Puppet plików utworzonych powyżej.

Otworzyćparams.ppplik.

Definiujemy $ conffile i $ confsourcezmienne w ramachJeślikomunikat:

/etc/puppetlabs/code/environments/production/modules/apache/manifests/params.pp

if $ :: osfamily == 'RedHat' {... $ conffile = '/etc/httpd/conf/httpd.conf' $ confsource = 'puppet: ///modules/apache/httpd.conf'} elsif $: : osfamily == 'Debian' {... $ conffile = '/etc/apache2/apache2.conf' $ confsource = 'puppet: ///modules/apache/apache2.conf'} else {...

Musimy dodać parametry na początku plikuapaczdeklaracja klasy winit.ppplik, podobnie jak w poprzednim przykładzie.

Gdy plik konfiguracyjny ulegnie zmianie, Apache musi zostać zrestartowany. Aby to zautomatyzować, możemy skorzystać z zasobu usługiw połączeniu z notyfikować atrybut, który wywoła zasób do uruchomienia za każdym razem, gdy plik konfiguracyjny zostanie zmieniony:

/etc/puppetlabs/code/environments/production/modules/apache/manifests/init.pp

file {'configuration-file': path => $ conffile, sure => file, source => $ confsource, notify => Service ['apache-service'],} service {'apache-service': name => $ apachename, hasrestart => true,}

usługa zasób używa już utworzonego parametru, który zdefiniował nazwę Apache w systemach Red Hat i Debian.
hasrestart atrybut służy do wyzwalania restartu zdefiniowanej usługi.

Krok 3: Utwórz pliki hosta wirtualnego

W zależności od dystrybucji systemu pliki hosta wirtualnego będą zarządzane w różny sposób. Z tego powodu będziemy umieszczać kod dla hostów wirtualnych w plikuJeśliinstrukcja, podobna do tej używanej wparams.ppale zawiera rzeczywiste zasoby Puppet.

• Od wewnątrzapache / manifesty /katalog, utwórz i otwórz plikvhosts.ppplik. Dodaj szkielet plikuJeślikomunikat:

/etc/puppetlabs/code/environments/production/modules/apache/manifests/vhosts.pp

class apache :: vhosts {if $ :: osfamily == 'RedHat' {} elsif $ :: osfamily == 'Debian' {} else {}}

Lokalizacja pliku wirtualnego hosta na naszym serwerze CentOS 7 to/etc/httpd/conf.d/vhost.conf . Musisz utworzyć plik jako szablon we wzorcu marionetek. Zrób to samo dla pliku hostów wirtualnych Ubuntu, który znajduje się pod adresem/etc/apache2/sites-available/example.com.conf, wymianaexample.comz nazwą FQDN serwera.

• Przejdź do szablony plik w apacz moduł, a następnie utwórz dwa pliki dla swoich wirtualnych hostów:

W przypadku systemów Red Hat:
/etc/puppetlabs/code/environments/production/modules/apache/templates/vhosts-rh.conf.erb

ServerAdmin nazwa_serwera ServerAlias ​​www. DocumentRoot / var / www // public_html / ErrorLog /var/www//logs/error.log CustomLog /var/www//logs/access.log łącznie

W przypadku systemów Debian:
/etc/puppet/modules/apache/templates/vhosts-deb.conf.erb

ServerAdmin nazwa_serwera ServerAlias ​​www. DocumentRoot / var / www / html // public_html / ErrorLog /var/www/html//logs/error.log CustomLog /var/www/html//logs/access.log łącznieWymagaj wszystkich przyznanych

W tych plikach używamy tylko dwóch zmiennych: adminemail i Nazwa serwera . Zdefiniujemy je na podstawie węzła po węźle, w ramachsite.ppplik.

• Powrót dovhosts.ppplik. Do utworzonych szablonów można teraz odwoływać się w kodzie:

/etc/puppetlabs/code/environments/production/modules/apache/manifests/vhosts.pp

class apache :: vhosts {if $ :: osfamily == 'RedHat' {file {'/etc/httpd/conf.d/vhost.conf': secure => file, content => template ('apache / vhosts-rh .conf.erb '),}} elsif $ :: osfamily ==' Debian '{file {' /etc/apache2/sites-available/$servername.conf ': secure => file, content => template (' apache /vhosts-deb.conf.erb '),}} else {fail (' To nie jest obsługiwana dystrybucja. ')}}

Obie rodziny dystrybucyjne wywołująplikzasób i przejmij tytuł lokalizacji wirtualnego hosta w odpowiedniej dystrybucji. W przypadku Debiana oznacza to jeszcze raz odwoływanie się do$ servernamewartość. Plikzawartośćatrybut wywołuje odpowiednie szablony.

• Oba pliki hostów wirtualnych odwołują się do dwóch katalogów. Nie ma ich domyślnie w systemach. Możemy je tworzyć za pomocąplikzasób, każdy wJeślikomunikat. Kompletnyvhosts.confplik powinien przypominać:

/etc/puppetlabs/code/environments/production/modules/apache/manifests/vhosts.pp

class apache :: vhosts {if $ :: osfamily == 'RedHat' {file {'/etc/httpd/conf.d/vhost.conf': secure => file, content => template ('apache / vhosts-rh .conf.erb '),} file {[' / var / www / $ servername ',' / var / www / $ servername / public_html ',' / var / www / $ servername / log ',]: secure => katalog,}} elsif $ :: osfamily == 'Debian' {file {'/etc/apache2/sites-available/$servername.conf': secure => file, content => template ('apache / vhosts-deb. conf.erb '),} file {[' / var / www / $ servername ',' / var / www / $ servername / public_html ',' / var / www / $ servername / logs ',]: secure => directory ,}} else {fail ('To nie jest obsługiwana dystrybucja.')}}

Krok 4: Przetestuj moduł

• Przejdź doapache / manifesty /katalog, uruchom plik parser lalek na wszystkich plikach, aby upewnić się, że kodowanie Puppet przebiega bez błędów:

sudo / opt / puppetlabs / bin / puppet parser walidacja init.pp params.pp vhosts.pp

Powinien wrócić pusty, bez żadnych problemów.

• Przejdź do przykłady katalogu wapaczmoduł. Stworzyćinit.ppplik i dołącz utworzone klasy. Zastąp wartości$ servernamei$ adminemailz własnym:

/etc/puppetlabs/code/environments/production/modules/apache/examples/init.pp

serveremail = 'webmaster@example.com' $ servername = 'puppet.example.com' include apache include apache :: vhosts

• Przetestuj moduł, uruchamiając zastosowanie lalek z –Nie etykietka:
  sudo / opt / puppetlabs / bin / puppet apply --noop init.pp

Nie powinien zwracać żadnych błędów i wyświetlać, że wyzwoli odświeżenia ze zdarzeń. Aby zainstalować i skonfigurować apache na masterze Puppet, uruchom ponownie bez–Nie, jeśli jest taka potrzeba.

• Wróć do głównego katalogu Puppet, a następnie do plikumanifestuje sięteczka (nieten obecny w module Apache).

cd / etc / puppetlabs / kod / środowiska / produkcja / manifesty

Stwórzsite.ppplik,i dołącz moduł Apache dla każdego węzła agenta. Wprowadź również zmienne dlaadminemail i Nazwa serweraparametry. Twójsite.pppowinien wyglądać następująco:

/etc/puppetlabs/code/environments/production/manifests/site.pp

węzeł „puppet-agent-ubuntu.example.com” {$ adminemail = 'webmaster@example.com' $ servername = 'puppet.example.com' include apache include apache :: vhosts} node 'puppet-agent-centos.example .com '{$ adminemail =' webmaster@example.com '$ servername =' puppet.example.com 'include apache include apache :: vhosts}

Domyślnie usługa agenta Puppet na zarządzanych węzłach automatycznie sprawdza co 30 minut z serwerem głównym i stosuje wszelkie nowe konfiguracje z głównego. Możesz także ręcznie wywołać proces agenta Puppet pomiędzy automatycznymi uruchomieniami agenta. Aby ręcznie uruchomić nowy moduł na węzłach agentów, zaloguj się do węzłów i uruchom:

sudo / opt / puppetlabs / bin / puppet agent -t

Teraz, gdy nauczyliśmy się tworzyć moduł od podstaw, nauczmy się, jak używać istniejącego wcześniej modułu z kukiełkowej kuźni lalek.

Użyj modułu z PuppetForge

Kuźnia Marionetek ma już wiele modułów do uruchomienia serwera. Możemy je skonfigurować tak samo szeroko, jak moduł, który utworzyłeś, i oszczędzić czas, ponieważ nie musimy tworzyć modułu od podstaw.

Upewnij się, że jesteś w / etc / puppetlabs / code / environment / production / modules katalog i zainstaluj Moduł MySQL Puppet Forge przez PuppetLabs. Spowoduje to również zainstalowanie wszystkich wstępnie wymaganych modułów.

cd / etc / puppetlabs / code / environment / production / modules

moduł sudo / opt / puppetlabs / bin / puppet zainstaluj puppetlabs-mysql

Użyj Hiera do tworzenia baz danych

Zanim utworzysz pliki konfiguracyjne dla modułu MySQL, pamiętaj, że możesz nie chcieć używać tych samych wartości we wszystkich węzłach agentów. Aby dostarczyć Puppet poprawne dane dla każdego węzła, używamy Hiera. Będziesz używać innego hasła roota dla każdego węzła, tworząc w ten sposób różne bazy danych MySQL.

• Nawigować do/ etc / puppeti utwórz plik konfiguracyjny Hierahiera.yamlgłówniemarionetkainformator. Użyjesz domyślnych wartości Hiera:

/etc/puppetlabs/code/environments/production/hiera.yaml

--- wersja: 5 hierarchia: - nazwa: wspólna ścieżka: common.yaml wartości domyślne: data_hash: yaml_data datadir: data

• Utwórz plikcommon.yaml. Definiuje wartość domyślną korzeń hasło do MySQL:

/etc/puppetlabs/code/environments/production/common.yaml

mysql :: server :: root_password: 'hasło'

Używamycommon.yamlplikgdy zmienna nie jest zdefiniowana gdzie indziej. Oznacza to, że wszystkie serwery będą współdzielić to samo hasło root MySQL. Te hasła mogą być również szyfrowane w celu zwiększenia bezpieczeństwa.

• Aby użyć domyślnych ustawień modułu MySQL, możesz dodać plik include „:: mysql :: server” linia dosite.ppplik. Jednak w tym przykładzie nadpisujesz niektóre domyślne ustawienia modułu, aby utworzyć bazę danych dla każdego z węzłów.

Edytuj pliksite.ppplik z następującymi wartościami:

węzeł 'Puppetagent-ubuntu.example.com' {$ adminemail = 'webmaster@example.com' $ servername = 'hostname.example.com' include apache include apache :: vhosts include mysql :: server mysql :: db {'mydb_ $ {fqdn} ': user =>' myuser ', password =>' mypass ', dbname =>' mydb ', host => $ :: fqdn, grant => [' SELECT ',' UPDATE '], tag = > $ domain,}} node 'Puppetagent-centos.example.com' {$ adminemail = 'webmaster@example.com' $ servername = 'hostname.example.com' include apache include apache :: vhosts include mysql :: server mysql :: db {'mydb _ $ {fqdn}': user => 'myuser', password => 'mypass', dbname => 'mydb', host => $ :: fqdn, grant => ['SELECT', ' UPDATE '], tag => $ domain,}}

Automatyzacja instalacji modułów marionetkowych od Puppet Master do Puppet Agent

• Możesz uruchomić te aktualizacje ręcznie na każdym węźle, używając SSH do każdego węzła i wydając następujące polecenie:

sudo / opt / puppetlabs / bin / puppet agent -t

• W przeciwnym razie usługa agenta Puppet na zarządzanych węzłach będzie automatycznie sprawdzać z serwerem głównym co 30 minut i stosować wszelkie nowe konfiguracje z głównego.

Katalog został pomyślnie zastosowany na agencie Ubuntu

Katalog został pomyślnie zastosowany na agencie CentOS

W ten sposób cała instalacja dostaje zautomatyzowany na węzłach agentów, po prostu stosując katalog.Można znaleźć pliki kodu i zależności używane w tej demonstracji tutaj .

Mam nadzieję, że to demo pomogło ci w zrozumieniu modułów i manifestów marionetkowych oraz ich wykorzystania do automatyzacji infrastruktury IT.W takim przypadku twoja praca staje się tak łatwa, wystarczy określić konfiguracje w Puppet Master, a agenci Puppet automatycznie ocenią główny manifest i zastosują moduł, który określa konfigurację Apache i MySQL. Jeśli utkniesz z jakimikolwiek pytaniami, nie krępuj się ich opublikować .

Jeśli znalazłeś to Samouczek lalek istotnych, Sprawdź autorstwa Edureka, zaufanej firmy zajmującej się edukacją online, z siecią ponad 250 000 zadowolonych uczniów rozsianych po całym świecie. Szkolenie Edureka DevOps Certification Training pomaga uczniom zdobyć wiedzę na temat różnych procesów DevOps i narzędzi, takich jak Puppet, Jenkins, Nagios i GIT, do automatyzacji wielu kroków w SDLC.

znacznik html do podziału wiersza