дома › Совети › Master of puppets: Инсталирање и конфигурирање на системот за управување со далечинска конфигурација Puppet. Master of puppets: Инсталирање и конфигурирање на системот за управување со далечинска конфигурација Puppet Инсталирање кукла

Master of puppets: Инсталирање и конфигурирање на системот за управување со далечинска конфигурација Puppet. Master of puppets: Инсталирање и конфигурирање на системот за управување со далечинска конфигурација Puppet Инсталирање кукла

За да го користите Puppet поефикасно, треба да разберете како се градат модулите и манифестациите. Овој туторијал ќе ве проучи како функционираат овие компоненти на куклата со поставување на стек LAMP на серверот Ubuntu 14.04.

Барања

Инсталирање кукла (господар и агент). Повеќе за ова -.
Способност да се создаде барем еден виртуелен сервер на Ubuntu 14.04 за да му служи на јазолот на агентот Puppet.

Основи на куклен код

Ресурси

Куклен код главно се состои од ресурси. Ресурсот е парче код што ја опишува состојбата на системот и ги одредува промените што му се потребни. На пример:

корисник ("мичел":
обезбеди => присутни,
uid => "1000",
gid => "1000",
школка => "/bin/bash",
дома => "/home/michelle"
}

Декларацијата за ресурси го има следниов формат:

resource_type ("ресурс_име"
атрибут => вредност
...
}

За да ги видите сите видови ресурси на кукли, издадете ја командата:

куклен ресурс --типови

Ќе дознаете повеќе за видовите ресурси во ова упатство.

Манифести

Манифестот е сценарио за оркестрација. Куклените програми со екстензија .pp се нарекуваат манифестации. Стандардниот манифест за кукли е /etc/puppet/manifests/site.pp.

Часови

Како и во секој редовен програмски јазик, часовите се одговорни за организирање и повторна употреба на делови од оркестрацијата.

Во рамките на дефиницијата на класата е блок од код кој опишува како работи класата. Откако ќе дефинирате класа, можете да ја користите во манифестации.

Дефиницијата на класата го има следниов формат:

класа пример_класа(
...
код
...
}

Овој код ја дефинира класата example_class. Кодот за кукли ќе биде во кадрави загради.

Декларација за класа е местото во кодот каде што се повикува одредена класа. Со декларација за класа, Puppet го обработува својот код.

Декларацијата за класа може да биде обична и по тип на ресурс.

Во кодот се додава редовна декларација за класа со помош на клучниот збор вклучува.

вклучи пример_класа

Кога се декларира како тип на ресурс, класата се декларира во формат на ресурси:

класа („пример_класа“:)

Оваа декларација ви овозможува да додадете параметри на класа во вашиот код што ги отфрлаат стандардните вредности на атрибутите на класата. На пример:

јазол „домаќин2“ (
класа („апачи“: ) # користете модул за апачи
apache::vhost ( "example.com": # дефинирајте го ресурсот на vhost
порта => "80",
docroot => "/var/www/html"
}
}

Модули

Модулот е група на манифестации и други датотеки организирани на предефиниран начин што го олеснува споделувањето и повторното користење на поединечни делови од оркестрацијата. Модулите помагаат да се организира куклен код бидејќи тие можат да се користат за раздвојување на кодот во повеќе манифестации.

Куклените модули се зачувани во директориумот /etc/puppet/modules.

Пишување манифест

Можете да вежбате пишување кукли манифестации, модули и класи користејќи го примерот за инсталирање на стек LAMP на Ubuntu сервер (резултатот ќе биде ).

Значи, за да оркестрирате Ubuntu 14.04 сервер и да инсталирате стек LAMP на него, потребни ви се ресурси за следните дејства:

инсталирање на пакетот apache2.
стартување на услугата apache2.
инсталација на пакет MySQL сервер, mysql-сервер.
стартување на услугата mysql.
инсталирање на php5 пакет
креирање на PHP тест скрипта, info.php.
ажурирање на индексот apt пред да го инсталирате секој пакет.

Подолу ќе најдете три примери на куклен код што може да се користи за да се постигне такво поставување на стек LAMP.

Првиот пример ќе ве научи како да напишете основни манифестации во една датотека. Вториот пример ќе ви помогне да соберете и користите класа и модул базирани на претходно напишани манифестации. Третиот пример ќе ви покаже како да користите претходно изградени јавни модули за да инсталирате стек LAMP.

Забелешка: За тестирање подобро е да користите свеж виртуелен сервер.

Пример 1: Инсталирање LAMP со еден манифест

Манифестот Puppet може да се напише на јазолот на агентот, а потоа да се изврши со помош на командата за примена на кукли (не треба да имате подесување господар и агент за да го направите ова).

Во овој дел, ќе научите да пишувате манифести кои ќе ги користат овие типови декларации за ресурси:

exec: Изврши команди.
пакет: инсталирајте пакети.
услуга: управување со услуги.
датотека: управување со датотеки.

Креирање манифест

Создадете нов манифест:

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

Додадете го следниов код во него за да ги пријавите потребните ресурси.

# извршете ја командата „apt-get update“.
exec("apt-update": # resource exec "apt-update"
команда => "/usr/bin/apt-get ажурирање" # команда што ќе ја извршува овој ресурс
}
# инсталирај пакет apache2
пакет ("apache2":
бара => Exec ["apt-update"], # request "apt-update" пред да го инсталираш пакетот
осигурајте се => инсталирано,
}
# стартувајте ја услугата apache2
услуга ("apache2":
обезбеди => трчање,
}
# инсталирај mysql-сервер
пакет ("mysql-сервер":
бара => Exec ["apt-update"], # request "apt-update" со повторно инсталирање
осигурајте се => инсталирано,
}
# стартувајте ја услугата mysql
услуга ("mysql":
обезбеди => трчање,
}
# инсталирај php5 пакет
пакет ("php5":
бара => Exec ["apt-update"], # request "apt-update" пред инсталацијата
осигурајте се => инсталирано,
}
# стартувајте ја услугата info.php
датотека ("/var/www/html/info.php":
обезбедете => датотека,
содржина => "", # phpinfo код
бара => Пакет["apache2"], # барање за пакет "apache2"
}

Примена на манифест

За да го користите новиот манифест, внесете ја командата:

судо кукла применува --тест

Ќе прикаже обемен резултат кој ги прикажува сите промени во состојбата на околината. Ако нема грешки во излезот, треба да можете да ја отворите вашата надворешна IP адреса или име на домен во вашиот прелистувач. На екранот ќе се појави тест тест. PHP страницасо информации за стекот. Ова значи дека Apache и PHP работат.

Сега стекот LAMP е инсталиран на серверот со помош на Puppet.

Ова е прилично едноставен манифест бидејќи може да се изврши на агент. Ако немате Puppet master, другите јазли на агенти нема да можат да го користат овој манифест.

Главниот сервер Puppet проверува дали состојбата на серверот се менува на секои 30 минути.

Пример 2: Инсталирање на стек LAMP со помош на модул

Сега обидете се да креирате едноставен модул заснован на манифестот LAMP што го напишавте во претходниот дел.

За да креирате модул, креирајте нов директориум во директориумот модули (неговото име мора да одговара на името на модулот). Овој директориум треба да содржи директориум за манифестации и датотека init.pp. Датотеката init.pp ја одредува класата Puppet (неговото име исто така мора да одговара на името на модулот).

Креирање на модул

Одете до мастер серверот Puppet и креирајте структура на директориуми за модулот:

cd /etc/puppet/modules
судо мкдир -п светилка/манифести

Креирајте и отворете ја датотеката init.pp во уредникот:

sudo vi lamp/manifests/init.pp

Вметнете ја класата на светилката во датотеката:

класа светилка (
}

Копирајте ја содржината на манифестот од делот 1 и залепете ја во блокот од класата на светилката. Сега имате дефиниција за класа на светилка. Другите манифестации ќе можат да ја користат оваа класа како модул.

Зачувајте ја и затворете ја датотеката.

Користење на модул во главниот манифест

Сега можете да го конфигурирате главниот манифест и да го користите модулот за светилка за да го инсталирате стекот LAMP на серверот.

На главниот сервер Puppet, уредете ја следнава датотека:

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

Најверојатно на овој моментдатотеката е празна. Додадете ги следните редови на него:

стандарден јазол ( )
јазол „светилка-1“ (
}

Забелешка: Заменете го lamp-1 со името на домаќинот на вашиот Puppet агент на кој ќе го инсталирате стекот.

Блокот на јазли ви овозможува да наведете куклен код кој ќе важи само за некои јазли.

Стандардниот блок се однесува на сите јазли на агенти кои немаат поединечен блок (оставете го празен). Блокот на светилката-1 ќе се примени на јазолот за агент ламба-1.

Додадете ја следнава линија во овој блок, кој го користи модулот за ламба:

Зачувајте ја и затворете ја датотеката.

Сега јазолот Puppet агент ќе може да ги преземе поставките од главниот сервер и да го инсталира стекот LAMP. Ако сакате да направите промени во моментов, извршете ја командата на агентот:

судо куклен агент --тест

Модулите се најзгодниот начин за повторна употреба на куклен код. Покрај тоа, модулите ви помагаат логично да го организирате вашиот код.

Пример 3: Инсталирање LAMP користејќи јавни модули

Модулот MySQL се користи на сличен начин. Додадете ги следните линии во блокот на јазли:

класа ("mysql::сервер":
root_password => "лозинка",
}

Можете исто така да ги пренесете параметрите на модулот MySQL.

Додадете ресурс што ќе го копира info.php на саканата локација. Користете го параметарот извор. Додадете ги следните линии во блокот на јазли:

датотека ("info.php": # име на датотека на ресурс
патека => "/var/www/html/info.php", # целна патека
обезбедете => датотека,
бара => Класа ["apache"], # класа на apache да се користи
извор => "puppet:///modules/apache/info.php", # локација за копирање на датотеката
}

Оваа декларација за класа го користи параметарот извор наместо содржина. Оваа опција не само што ја користи содржината на датотеката, туку и ја копира.

Puppet ќе ја копира датотеката puppet:///modules/apache/info.php на /etc/puppet/modules/apache/files/info.php.

Зачувајте ја и затворете ја датотеката.

Направете датотека info.php.

судо ш -ц „ехо“"> /etc/puppet/modules/apache/files/info.php"

Сега јазолот Puppet агент ќе може да ги преземе поставките од главниот сервер и да го инсталира стекот LAMP. Ако сакате да направите промени во опкружувањето на агентот во моментов, извршете ја командата на овој јазол:

судо куклен агент --тест

Оваа команда ќе ги преземе сите ажурирања за тековниот јазол и ќе го инсталира стекот на него. За да бидете сигурни дека Apache и PHP работат, отворете ја IP адресата или доменот на јазолот во прелистувачот:

http://lamp_1_public_IP/info.php

Заклучок

Сега имате основни познавања за работа со кукли модули и манифестации. Обидете се сами да креирате едноставен манифест и модул.

Куклата е одлична за управување со датотеките за конфигурација на апликациите.

Тагови: ,
Малку поезија.Се чини дека овој напис треба да биде почетна точка за целата серија, но целната публика се сепак поискусните корисници на производите на Puppet Labs со отворен код кои не се задоволни со индивидуалните, слабо интегрирани модули со Puppet Forge. Како и во секој случај „библиотека наспроти рамка“, цената што треба да се плати е да се следи светогледот на авторот на интегрираното решение.

Малку за тоа како функционира Puppet

Куклата е првенствено специфичен јазик за декларативно одредување на конечната состојба на системот. За споредба, GNU Makefile е исклучително погодна, каде што, покрај директниот опис на зависностите, можно е да станете чудни до максимум.

Апстракцијата на куклата е нешто вака ( кршење на обрасци - заборавете на се што сте знаеле за програмските термини!).

Јазоле збир на конфигурации за одреден целен систем. Всушност, ова е посебен случај на класа.
Класае збир на декларативна логика што е вклучена во конфигурацијата на јазлите или други класи. Класата нема ниту инстанци ниту методи, но има параметри и променливи дефинирани во логиката. Всушност, тоа е попрво процедура која може да наследи друга процедура со едноставно додавање код и со не толку банален опсег на променливи.
Тип- но ова повеќе личи на класична класа - претпоставува примери со име и дефинитивно дадени параметри, но ништо повеќе. Специфична имплементација на типот може да се напише како куклена скрипта преку define , која создава примери од други типови, или како руби екстензија со фантазија.
Ресурс- ова се всушност именувани примери на Типови. Секое име на ресурс е единствено во специфичен тип во конфигурацијата на јазол (директориум).
Променливи- Па, накратко, ова се константи... Пред Кукла 4, работите беа уште полоши со нивниот опсег. Сега е адекватно: за употреба надвор од локацијата за дефиниција, мора да биде наведен целосно квалификуван идентификатор, освен во случај на наследување на класи.

Куклата може да се користи за локално распоредување без мрежа или поврзана инфраструктура. Ова може да се користи за создавање слики од контејнери. Постои дури и цело движење кое се залага за напуштање на централизиран сервер.

На идеолошки правилен начин, Куклената инфраструктура се состои од агент - привилегирана услуга на целниот систем - и сервер кој дистрибуира вредни инструкции во форма на директориуми со декларативни ресурси по барање од агенти. Безбедноста се спроведува на ниво на инфраструктурата на приватен јавен клуч (X.509). Едноставно кажано, истите механизми како во HTTPS, но со сопствен CA и задолжителна верификација клиент сертификат.

Во поедноставена форма, постапката за распоредување изгледа вака:

Обработка преку TLS и X.509 (воспоставување врска, ажурирање на CRL, проверка на ограничувањата на сертификатот итн.)
Агентот добива генератори на факти од серверот со кеширање и сите работи (поточно, сè е извлечено од папките lib/ во модулите). Не е тешко да додадете своја руби скрипта за да ги соберете информациите од интерес.
Агентот собира факти за целниот систем и го испраќа до серверот. Сите факти може лесно да се прегледаат рачно преку повикот за марионетски факти. Овие факти се достапни како глобални променливи.
Серверот составува каталог на ресурси и го испраќа до агентот. Под ова лежи цел слој на различни концепти.
Агентот повлекува сè што е потребно од серверот и го носи системот во наведената форма. Самиот агент не знае што да прави со ресурсите, тој се потпира на имплементација на провајдери (семантичкиот превод ќе биде „имплементатор“, а не снабдувач) на специфични видови ресурси. Некои провајдери се стандардни и се вклучени во куклените пакети, додека останатите се извлечени од модулите.

За да уживате во сите задоволства, има дополнителни лепчиња во форма на:

Модул- збирка декларативни скрипти за кукли, руби екстензии за кукли, датотеки, шаблони за датотеки, податоци на Hiera и многу повеќе. Поточен термин би бил „пакет“.
Животна средина- збир на скрипти, модули и податоци на Hiera. Како што инфраструктурата стана покомплексна, неизбежно стана неопходно да се подели конфигурацијата подалеку од стандардната поделба по јазли. Во основа, ова е потребно за пилот-иновации и банална контрола на пристап (кога не сите администратори имаат пристап до сите јазли на ИТ инфраструктурата).
Хиера- хиерархиска база на податоци. Оваа формулација може да биде многу застрашувачка. Веројатно затоа е сменет во документацијата на подоцнежните верзии. Всушност, ова е исклучително едноставен и удобен механизам за извлекување на конфигурации од YAML или JSON датотеки. Хиерархија е способност да се специфицира редоследот на читање на повеќе конфигурациски датотеки - т.е. хиерархија/приоритет на овие датотеки.
- Покрај преземањето податоци со повик на функција, Puppet ги повлекува стандардните параметри на класата, што е главниот белег.
- Се разбира, Hiera поддржува интерполација на факти, па дури и повикување специјални функции.
- Во Puppet 4.3, повторно ја имплементиравме истата функционалност за да ја поддржиме не само глобалната база на податоци, туку и локалната за животната средина и модулот, иако авторот веќе нашол неколку проблеми во нивната имплементација (PUP-5983, PUP-5952 и PUP -5899), кои беа веднаш поправени од Puppet Labs.
- Поддржани се неколку стратегии за извлекување вредности од сите датотеки во хиерархијата:
  - прво - се враќа првата вредност пронајдена по приоритет
  - уникатен - ги собира сите вредности во еднодимензионална низа и ги отстранува дупликатите
  - хаш - ги комбинира сите пронајдени YAML Хаш. Двојните копчиња се избираат по приоритет.
  - длабоко е во суштина рекурзивна верзија на хаш
- Убавината е што стратегијата за земање примероци може да се специфицира и при повикување на функцијата lookup(), затоа што и во која било датотека со хиерархија преку специјалниот клуч lookup_options, кој активно се користи во модулот cfnetwork.
PuppetDB- во суштина слој на деловна логика околу релациона база на податоци (PostgreSQL), која ви овозможува да зачувате извештаи за направени факти и распоредувања и да извезувате ресурси за последователен увоз во директориуми на други јазли или селекции преку специјални функции. Исто така постои и веб-интерфејс во форма на куклена табла.
X.509 PKI- веќе споменатата инфраструктура за сертификати, која е исклучително погодна за користење за други услуги без потреба од управување со посебна инфраструктура.
МЦКолектив- се чини дека е корисна работа за започнување задачи врз основа на настани на фарма на сервери, но авторот има одредена недоверба во безбедноста на одредено решение.
Кукла кованица- отворена платформа за објавување и преземање модули.
некои други карактеристики во форма на контроли надворешни уредитип на опрема на Cisco и распоредување на гол метал, но тоа е друга приказна

Белешки за безбедност и пристапност

Треба да разберете дека Puppet Server станува ранлива точка на целата ИТ инфраструктура, бидејќи ... ја одредува конечната конфигурација на сите системи. Во посебни случаи, има смисла да се направи сепарација - посебен сервер за критични инфраструктурни елементи со екстремно ограничен пристапи рачно ажурирање и второто за се останато.

Достапноста на Puppet Server ја одредува способноста за управување со целата инфраструктура. Има смисла да го хостирате Puppet Server на виртуелна машина во посигурен и брзо обновлив облак од трети страни отколку вашите сопствени можности. Или треба да инсталирате неколку сервери.

Во секој случај, не треба да инсталирате други услуги на системот каде што ќе биде распореден Puppet Server со ѕвона и свирки. Виртуелизацијата и контејнеризацијата можат да ви помогнат.

Мулти-мајстор (неколку посебни куклени сервери)

Во овој случај, само еден сервер делува како CA (Certificate Authority) - неговата недостапност значи дека е невозможно да се додадат нови јазли.
- Puppet ви овозможува да користите инфраструктура X.509 од трета страна ако вградената не е задоволителна.
Целата конфигурација (Environment) мора да се складира во систем за контрола на верзијата и да се распореди на секој сервер истовремено.
Единственото нешто заедничко е базата на податоци PostgreSQL, чија организација на висока достапност е надвор од опсегот на овој напис.
Модулот cfpuppetserver поддржува инсталации како примарен (со CA) и како секундарен сервер.

Што значајно се промени од постарите верзии

Производителот има целосен опис.

Сите услуги се преместени во JVM, JRuby и Jetty. И покрај очигледните предности на интеграцијата, има и недостатоци во однос на потрошувачката на меморија.
Функциите Ламбда се додадени за обработка на колекции - сега нема потреба да се сечат патерици во Ruby или да се изопачуваат преку create_resources()
Се појави алатка за обработка на EPP шаблони - во суштина истата ERB, но со Puppet DSL наместо Ruby,
Стандардната структура на директориумот на конфигурациските датотеки значително се промени
Додадена е поддршка за Даватели на податоци за средини и модули (хаковите повеќе не се потребни).
Намалување на улогата на глобалната Хиера. Нова и поврзана команда е пребарување на кукли.

Инсталација

Овој процес е прилично примитивен, но бара следење на одредена низа чекори. Бидејќи тоа рачно го правите е неблагодарна задача, авторот ќе ве научи на нешто лошо, имено, преземање неразбирливи скрипти од Интернет и нивно извршување како root на вашиот систем.

Трите главни компоненти на серверот се самиот Puppet Server, PuppetDB и PostgreSQL. Сите тие можат да се натрупаат во еден јазол или да се поделат на два или три системи. Puppet Server и Puppet DB може да се извршуваат повеќе пати, но PostgeSQL е единствена точка на неуспех. Постојат различни пристапи за репликација и кластерирање PostgeSQL. Пригоден пристап во случајот на главните и секундарните сервери би бил Master + Read-Only Slave, кој е поддржан во самата PuppetDB како главен и само за читање јазол на базата на податоци, но автоматизирајќи ги таквите поставувањето бара време и затоа сè уште не е достапно вклучено во модулот cfpuppetserver.

Самата конфигурација едноставно може да се зачува барем на датотечен системзаедно со Puppet Server, но тоа е како да пишувате скрипти на веб-сервер за производство. Најсоодветно решение е git складиштето. Услужната алатка r10k може да ги повлече сите гранки на складиштето и да ги распореди на Puppet Server како посебни околини. r10k е прилично лош во влечење на зависности, така што библиотекар-кукла се користи на врвот. Вреди да се напомене веднаш дека главната канонска куклена средина е „производството“. Затоа, складиштето за конфигурација треба да користи гранка наречена „производство“ наместо „господар“.

Системски барања

Хардверот е опишан од самиот производител. Модулот cfpuppetserver моментално поддржува само Debian Jessie+ и Ubuntu Trusty+.

Конфигурација во Git

За самиот r10k, локацијата на складиштето не е многу важна - главната работа е неговата достапност. На пример, за цели на тестирање, складиштето може да се хостира на истиот систем и да се пристапи преку file://. Добро место за почеток е примерот за конфигурација на codingfuture/puppet-exampleenv.

Клонирање на складиштето: git клон https://github.com/codingfuture/puppet-exampleenv my-puppet-conf && cd my-puppet-conf
Инсталирајте Општи поставувањаадминистраторски пристап користејќи совети во коментарите:
- $EDITOR податоци/common.yaml
Ајде да создадеме конфигурација на јазол:
- $MY_DOMAIN - име на root домен (на пример, example.org)
- $HOST_NAME - име на хост на клиентот без домен
- mkdir податоци/$MY_DOMAIN
- cp data/example.com/puppet.yaml data/$(MY_DOMAIN)/puppet.yaml
- $EDITOR nano -w data/$(MY_DOMAIN)/puppet.yaml - поставување јазол со Puppet Server според предлозите во коментарите
- cp data/example.com/host.yaml data/$(MY_DOMAIN)/$(HOST_NAME).yaml
- $EDITOR нано -w податоци/$(MY_DOMAIN)/$(HOST_NAME).yaml - поставување произволен јазол врз основа на предлозите во коментарите
Ние притискаме до нашиот сопствен Git сервер или го правиме достапен локално на јазол со Puppet Server преку rsync или scp. Локалното складиште е погодно како среден чекор додека серверот Git не се распореди од самиот Puppet. Во извесна смисла, ова потсетува на склопување на компајлер во неколку фази.

Инсталирање од нула на чист систем

Модулот cfpuppetserver ви овозможува да инсталирате сè користејќи го самиот Puppet, но за почетната инсталација, основните операции се дуплираат со скрипта Bash.

На целниот систем:

Преземете ја скриптата за инсталација: wget https://raw.githubusercontent.com/codingfuture/puppet-cfpuppetserver/master/setup_puppetserver.sh
Гледаме низ сценариото и се намуртуваме: помалку setup_puppetserver.sh
Стартувај: bash setup_puppetserver.sh
кукла.$(MY_DOMAIN) .
- Пример со оддалечено складиште: bash setup_puppetserver.sh ssh:// [заштитена е-пошта]/кукла-конф
- Пример со локално: bash setup_puppetserver.sh file:///root/puppetconf/
Гледаме како системот се издува и не инсталира сè многу брзо.
Ако складиштето е оддалечено:
- Креирајте SSH клуч за root: ssh-keygen -t rsa -b 2048
- Го регистрираме јавниот клуч /root/.ssh/id_rsa.pub на оддалечениот Git сервер...
- ... и таму поставивме кука Git со повикување на следнава команда: /usr/bin/ssh -T deploypuppet@puppet.$(MY_DOMAIN) ./puppetdeploy.sh
Почнуваме рачно да ја распоредуваме конфигурацијата: /etc/puppetlabs/deploy.sh
Ајде да пробаме како работи на самиот сервер: /opt/puppetlabs/bin/puppet agent --test
Проверете ги вашите мрежни поставки, заштитник за пренапонии SSH пристап

Додавање управувани јазли

Целосно квалификуваното име на Puppet Server мора да биде достапно преку DNS на управуваниот хост или хардкодирано во /etc/hosts.
- Пример: ехо „128.1.1.1 puppet.example.com“ >> /etc/hosts
На јазолот со Puppet Server, извршете ја следнава скрипта /root/genclientinit.sh $(HOST_NAME).$(MY_DOMAIN) .
Копирајте го целиот резултат и залепете го командна линијана целниот систем.
Го чекаме крајот на извршувањето и го извршуваме /opt/puppetlabs/bin/puppet agent --test . При првото лансирање, ќе се генерира барање за потпишување сертификат.
Одиме во јазолот Puppet Server за да го потпишеме сертификатот.
- куклена листа на сертификати - го проверуваме потписот на сертификатот за дополнителна параноја.
- знак за куклен сертификат $(HOST_NAME).$(MY_DOMAIN) - всушност, ние го потпишуваме сертификатот.
Се враќаме во управуваниот јазол и повторно стартуваме: /opt/puppetlabs/bin/puppet agent --test`. Ова ќе принуди да започне процедурата за распоредување.
Чекаме да заврши распоредувањето преку Puppet Agent.
Тоа е тоа, имате подготвена минимална Куклена инфраструктура!

Пример излез од /root/genclientinit.sh

баш</etc/cflocation fi ако се тестира! -z ""; тогаш echo -n >/etc/cflocationpool fi ако тест ! -z "\$http_proxy"; потоа извезете http_proxy export https_proxy="\$http_proxy" извезете HTTP_PROXY="\$http_proxy" извезете HTTPS_PROXY="\$http_proxy" fi echo host.example.com > /etc/hostname име на домаќин host.example.com ако ! кое lsb-издавање | читај; потоа apt-get инсталирај lsb-release fi кодно име=\$(lsb_release -cs) if test -z "\$codename"; потоа ехо „Не успеав да се открие точното кодно име“ излез 1 fi wget https://apt.puppetlabs.com/puppetlabs-release-pc1-\$(кодно име).deb dpkg -i puppetlabs-release-pc1-\$(кодно име) .deb mkdir -p /etc/puppetlabs/puppet cat > /etc/puppetlabs/puppet/puppet.conf<кукла знак host.example.com" ехо "Користете CTRL+C за да го прекинете циклусот, ако не успее поради различни причини" спиење 5 завршено EOT

Опис на модулот

Комплетна листа на параметри на Bash за скриптата за почетна инсталација

~# ./setup_puppetserver.sh Употреба: ./setup_puppetserver.sh [ [ [ [] ] ] ]

r10k_repo_url - URI на складиштето Git
certname - целосно квалификувано име на домен на домаќинот
cflocation - иницијализација на фактот cf_location
cflocationpool - иницијализација на фактот cf_location_pool
http_proxy - прокси-сервер за HTTP и HTTPS барања

Комплетна листа на параметри на Bash за скриптата за иницијализација на клиентот Puppet

~# /root/genclientinit.sh Употреба: ./genclientinit.sh [ [ []]]
Значењето на параметрите е исто како и во претходната скрипта.

cfpuppetserver класа

deployuser = „deploypuppet“ - корисничко име за автоматско распоредување надградби на конфигурацијата
deployuser_auth_keys = undef - список на клучеви за $deployuser
repo_url = undef - URI на складиштето (пример: ssh://user@host/repo или file:///some/path)
puppetserver = точно - дали да се инсталира компонентата Puppet Server на овој јазол
puppetdb = точно - дали да се инсталира компонентата PuppetDB на овој јазол
puppetdb_port = 8081 - порта за PuppetDB
setup_postgresql = точно - дали да се инсталира компонентата PostgreSQL на овој јазол (само ако е овозможена инсталацијата на PuppetDB)
service_face = „било кој“ - име на cfnetwork::face ресурс за прифаќање дојдовни врски
puppetserver_mem = автоматско - RAM меморија за куклен сервер во мегабајти (минимум 192 MB)
puppetdb_mem = автоматско - RAM меморија за PuppetDB во мегабајти (минимум 192 MB)
postgresql_mem = автоматско - RAM меморија за PostgreSQL во мегабајти (минимум 128 MB)

класа cfpuppetserver::puppetdb

postgresql_host = "localhost" - адреса на базата на податоци
postgresql_listen = $postgresql_host - вредноста оди директно до listen_addresses PostgreSQL директива
postgresql_port = 5432 - порта за база на податоци
postgresql_user = "puppetdb" - корисник на PuppetDB во базата на податоци
postgresql_pass = "puppetdb" - лозинка на корисникот PuppetDB во базата на податоци
postgresql_ssl = false - овозможете шифрирање на врската врз основа на Puppet PKI сертификати

класа cfpuppetserver::puppetserver

автознак = неточно - НЕ ТРЕБА да се користи во борбена средина, освен можеби во DMZ. Постои исклучиво за тест автоматизација.
global_hiera_config = "cfpuppetserver/hiera.yaml" - патека до стандардната конфигурациска датотека Hiera според куклените канони (првата компонента е името на модулот, остатокот е патеката под датотеките/папката во модулот)

Можете да помогнете и да префрлите некои средства за развој на страницата

Управувањето со голем број Unix системи не може да се нарече погодно. За да промени еден параметар, администраторот треба да контактира со секоја машина; скриптите можат само делумно да помогнат, а не во сите ситуации.

Треба да се признае дека мрежните администратори на Windows сè уште се во поповолна позиција. Доволно е да ги промените поставките за групната политика и по некое време сите компјутери на мрежата, вклучително и оние со неодамна инсталиран оперативен систем, ќе „научат“ за иновацијата, ако тоа се разбира за нив се однесува. Гледајќи наназад во текот на долгиот период на развој на Unix, ќе забележите дека вакво нешто никогаш не се фатило. Постојат решенија како kickstart кои помагаат при првичната инсталација операционен систем, но дополнителното префинетост ќе бара значителен напор. Комерцијалните решенија како BladeLogic и OpsWare само делумно го решаваат проблемот со автоматизирање на поставките; нивната главна предност е достапноста GUI, а може да се купат само од големи организации. Има, се разбира, проекти кои нудат бесплатни решенија, но во текот на нивното постоење тие никогаш не биле во можност да создадат голема заедница. На пример, Cfengine не е многу популарен меѓу администраторите, иако освен во Linux, може да се користи и во *BSD, Windows и Mac OS X. Ова може да се должи на релативната сложеност на креирањето на конфигурации. Кога опишувате задачи, треба да ги земете предвид карактеристиките на секој специфичен систем и рачно да го контролирате редоследот на дејства при извршување на командите. Односно, администраторот мора да запомни дека за некои системи треба да напишете adduser за други, useradd, да ја земете предвид локацијата на датотеките на различни системи итн. Ова го отежнува процесот на пишување наредби по ред на големина, многу е тешко да се создаде правилна конфигурација во лет и речиси е невозможно да се прочитаат креираните конфигурации по некое време. И покрај лиценцата за GPL, Cfengine е всушност проект на еден човек кој ги контролира сите промени и не е многу заинтересиран за градење отворено општество. Како резултат на тоа, можностите на cfengine се доста задоволителни за развивачот, но за другите администратори тоа е прилично дополнителна главоболка. За да се подобри cfengine, беа креирани разни додатоци од трети лица програмери, што често само ја влошуваше ситуацијата. Авторот на неколку такви модули за cfengine, Лук Каниес, на крајот одлучи да развие слична алатка, но без многу недостатоци на cfengine.

Карактеристики на кукли

Puppet, како cfengine, е систем клиент-сервер кој користи декларативен, односно задолжителен јазик за опишување задачи и библиотеки за нивна имплементација. Клиентите периодично (30 минути стандардно) се поврзуваат со централниот сервер и ја добиваат најновата конфигурација. Доколку примените поставки не се совпаѓаат со состојбата на системот, тие ќе бидат извршени, а доколку е потребно, до серверот ќе се испрати извештај за извршените операции. Серверот може да зачувува пораки во syslog или датотека, да креира RRD график и да ги испрати на одредена е-пошта. Дополнителните трансакции и слоеви за апстракција на ресурси обезбедуваат максимална компатибилност со постоечките поставки и апликации, овозможувајќи ви да се фокусирате на системските објекти без да се грижите за разликите во имплементацијата и описот на деталните команди и формати на датотеки. Администраторот работи само со типот на објект, а за останатото се грижи Puppet. Така, типот на пакети знае околу 17 системи на пакети; потребниот автоматски ќе се препознае врз основа на информации за верзијата на дистрибуцијата или системот, иако, доколку е потребно, менаџерот на пакети може да биде принуден.

За разлика од скриптите, кои често не се возможни да се користат на други системи, конфигурациите за кукли напишани од администратори од трети страни, во најголем дел, ќе работат без проблеми на која било друга мрежа. Во куклен готвач [ http://www.reductivelabs.com/trac/puppet/tags/puppet%2Crecipe] веќе има триесетина готови рецепти. Puppet во моментов официјално ги поддржува следните оперативни системи и услуги: Debian, RedHat/Fedora, Solaris, SUSE, CentOS, Mac OS X, OpenBSD, Gentoo и MySQL, LDAP.

Куклен јазик

За да продолжите напред, прво мора да ги разберете основните елементи и способности на јазикот. Јазикот е еден од јаки страниКукла. Со негова помош се опишани ресурсите со кои администраторот планира да управува и активностите. За разлика од повеќето слични решенија, Puppet му дозволува на јазикот да го поедностави пристапот до сите слични ресурси на кој било систем во хетерогена средина. Описот на ресурсите обично се состои од име, тип и атрибути. На пример, да укажеме на датотеката /etc/passwd и да ги поставиме нејзините атрибути:

датотека ("/etc/passwd":

сопственик => корен,

група => корен,

Сега клиентите, откако ќе се поврзат со серверот, ќе ја копираат датотеката /etc/passwd и ќе ги инсталираат наведените атрибути. Можете да дефинирате повеќе ресурси во едно правило, раздвојувајќи ги со помош на точка-запирка. Што да направите ако конфигурациската датотека што се користи на серверот се разликува од клиентските или воопшто не се користи? На пример, оваа ситуација може да се појави кога Поставки за VPNврски. Во овој случај, датотеката може да се укаже на користење на изворната директива. Постојат две опции овде, како и обично, за да се одреди патеката до друга датотека; два URI протоколи се исто така поддржани: датотека и кукла. Во првиот случај, врска до надворешно NFS сервер, во втората опција, услуга слична на NFS се активира на серверот Puppet, кој извезува ресурси. Во вториот случај, стандардната патека е во однос на root директориумот на куклата - /etc/puppet. Односно, врската puppet://server.domain.com/config/sshd_config ќе одговара на датотеката /etc/puppet/config/sshd_config. Можете да го отфрлите овој директориум користејќи ја директивата за кофа за датотеки, иако е поправилно да се користи истоимениот дел во датотеката /etc/puppet/fileserver.conf. Во овој случај, можете да го ограничите пристапот до услугата само од одредени адреси. На пример, да го опишеме делот за конфигурација.

патека /var/puppet/config

дозволи *.domain.com

дозволи 192.168.0.*

дозволи 192.168.1.0/24

одбие *.wireless.domain.com

И тогаш се свртуваме кон овој дел кога го опишуваме ресурсот.

извор => "puppet://server.domain.com/config/sshd_config"

Пред дебелото црево е името на ресурсот. Во наједноставните случаи, можете едноставно да наведете алијас или променливи како име. Алијасот е поставен со помош на директивата за алијас. целосна патека до датотеката. Во посложени конфигурации

датотека ("/etc/passwd":

алијас => passwd

Друга опција за создавање алијас е добра кога треба да се справите со различни оперативни системи. На пример, ајде да создадеме ресурс што ја опишува датотеката sshd_config:

датотека (sshdconfig:

име => $оперативен систем ? (

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

стандардно => "/etc/ssh/sshd_config"

Во овој пример, ние сме соочени со избор. Датотеката за Solaris е наведена посебно, за сите други ќе биде избрана датотеката /etc/ssh/sshd_config. Сега овој ресурс може да се пристапи како sshdconfig, во зависност од оперативниот систем ќе се избере саканата патека. На пример, укажуваме дека ако sshd демонот работи и прима нова датотека, треба да ја рестартирате услугата.

осигурај => точно,

претплатете се => Датотека

Променливите често се користат при работа со кориснички податоци. На пример, ја опишуваме локацијата на домашните директориуми на корисникот:

$homeroot = "/home"

Сега до датотеките на одреден корисник може да се пристапи како

$(homeroot)/$име

Параметарот $name ќе се пополни со името на сметката на корисникот. Во некои случаи, погодно е да се дефинира стандардна вредност за некој тип. На пример, за типот exec, тие често ги означуваат директориумите во кои треба да ја бара извршната датотека:

Exec (пат => "/usr/bin:/bin:/usr/sbin:/sbin")

Ако треба да укажете на неколку вгнездени датотеки и директориуми, можете да го користите параметарот за повторување.

датотека ("/etc/apache2/conf.d":

извор => „кукла: / кукла / server.domain.com/config/apache/conf.d“,

рекурс => „вистинито“

Повеќе ресурси може да се комбинираат во класи или дефиниции. Класите се целосен опис на систем или услуга и се користат одделно.

"/etc/passwd": сопственик => корен, група => корен, режим => 644;

„/etc/shadow“: сопственик => корен, група => корен, режим => 440

Како и во објектно-ориентирани јазици, класите може да се отфрлат. На пример, на FreeBSD групниот сопственик на овие датотеки е тркалото. Затоа, за да не го преработиме целосно ресурсот, ајде да создадеме нова класа freebsd, која ќе ја наследи класата на Linux:

класата freebsd го наследува Linux (

Датотека[“/etc/passwd”] ( група => тркало );

Датотека[“/etc/shadow”] (група => тркало)

За погодност, сите класи може да се сместат во посебна датотека, која може да се поврзе со помош на директивата за вклучување. Дефинициите може да земат повеќе параметри како аргументи, но не поддржуваат наследување и се користат кога треба да опишете објекти за повеќекратна употреба. На пример, да го дефинираме домашниот директориум на корисници и командите потребни за создавање нова сметка.

дефинирај user_homedir ($group, $fullname, $ingroups) (

корисник („$name“:

обезбеди => присутни,

коментар => „$fullname“,

gid => "$група",

групи => $ingroups,

членство => минимум,

школка => "/bin/bash",

дома => "/home/$name",

бара => Група[$група],

exec("$name homedir":

команда => „/bin/cp -R /etc/skel /home/$name; /bin/chown -R $name:$group /home/$name",

создава => "/home/$name",

бара => Корисник[$name],

Сега да се создаде нов сметкасамо контактирајте со user_homedir.

user_homedir("сергеј":

група => "сергеј",

полно име => „Сергеј Јаремчук“,

inggroups => [„медиуми“, „администратор]

Постојат посебни описи на јазли кои поддржуваат наследување како класи. Кога клиентот ќе се поврзе со серверот Puppet, ќе се пребарува соодветниот дел на јазол и ќе се обезбедат поставки специфични само за овој компјутер. За да ги опишете сите други системи, можете да го користите стандардниот јазол. Опис на сите видови е даден во документот „Референца на типот“, кој во секој случај мора да се прочита, барем за да се разберат сите способности на куклен јазик. Различни видовиви овозможува да извршувате одредени команди, вклучително и кога се исполнети одредени услови (на пример, промена на конфигурациска датотека), работа со cron, кориснички ингеренции и групи, компјутери, монтажа ресурси, стартување и стопирање услуги, инсталирање, ажурирање и отстранување на пакети, работа со SSH клучеви, Соларис зони и така натаму. Ова е колку е лесно да се принуди списокот на пакети во дистрибуции со помош на apt да се ажурира секој ден помеѓу 2 и 4 часа.

распоред (дневно:

период => дневно,

опсег =>

exec("/usr/bin/apt-get ажурирање":

распоред => дневно

Ажурирањето за тој период секој систем ќе го изврши само еднаш, по што задачата се смета за завршена и ќе биде избришана од клиентскиот компјутер. Јазикот Puppet поддржува други познати структури: услови, функции, низи, коментари и слично.

Инсталирање кукла

Кукла бара Ruby (>= 1.8.1) со OpenSSL поддршка и XMLRPC библиотеки, како и библиотека Faster [ http://reductivelabs.com/projects/facter]. Складиштето на Ubuntu 7.04 што се користеше за тест инсталација веќе го вклучуваше пакетот за кученце.

$ sudo apt-cache кукла за пребарување

кукла — централизирано управување со конфигурации за мрежи

puppetmaster - централизиран контролен демон за управување со конфигурација

За време на инсталацијата, ќе се инсталираат сите потребни пакети за зависност: facter libopenssl-ruby libxmlrpc-ruby.

$ sudo apt-get инсталирај куклен мајстор

Можете да ја проверите достапноста на библиотеките на Ruby со командата.

$ ruby -ropenssl -e "става: да"

~$ ruby ‎-rxmlrpc/client -e „puts:yep“

Ако не се добиени грешки, тогаш сè што ви треба е веќе вклучено. Датотеките што ја опишуваат саканата конфигурација на системите се нарекуваат манифестации во куклена терминологија. Кога ќе се стартува, демонот се обидува да ја прочита датотеката /etc/puppet/manifests/site.pp; ако ја нема, прикажува предупредувачка порака. Кога тестирате, можете да му кажете на демонот да работи во офлајн режим, во тој случај манифестот не е потребен

$ sudo /usr/bin/puppetmasterd --nodes

Доколку е потребно, можете да поврзете други датотеки со site.pp, на пример со описи на класи. За тестирање, можете да ги внесете наједноставните инструкции во оваа датотека.

датотека ("/etc/sudoers":

сопственик => корен,

група => корен,

Сите конфигурациски датотеки и за серверот и за клиентите се наоѓаат во /etc/puppet. Датотеката fileserver.conf за која зборувавме погоре е опционална и се користи само ако Puppet ќе работи и како сервер за датотеки. На Ubuntu, оваа датотека го извезува поддиректориумот /etc/puppet/files. Поддиректориумот ssl содржи сертификати и клучеви кои ќе се користат за шифрирање при поврзување на клиенти. Копчињата се креираат автоматски првиот пат кога ќе го стартувате puppetmasterd; можете да ги креирате рачно со командата.

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

Датотеките puppetd.conf и puppetmasterd.conf се слични. Тие укажуваат на некои параметри за работа на демони на клиентскиот систем и серверот. Датотеката на клиентот се разликува само во присуство на параметарот на серверот, кој укажува на компјутерот на кој работи puppetmasterd.

сервер = мелница.com

logdir = /var/log/кукла

vardir = /var/lib/кукла

rundir = /var/run

# испрати извештај до серверот

За да избегнете рачно пишување сè, можете да креирате шаблон користејќи го самиот puppetd.

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

Слично на тоа, можете да креирате site.pp на серверот.

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

Друга датотека, tagmail.conf, ви овозможува да ги одредите адресите на е-пошта на кои ќе се испраќаат извештаи. Во наједноставниот случај, можете да користите една линија.

сите: [заштитена е-пошта]

Конфигурациските датотеки не се доволни за клиентот да се поврзе со серверот. За да го направите ова, исто така треба да ги потпишете сертификатите. Прво, за да го известите серверот за новиот компјутер на клиентскиот систем, внесете ја командата:

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

инфо: Се бара сертификат

предупредување: сертификатот од колеги нема да биде потврден во оваа SSL сесија

известување: Не добил сертификат

Ако се врати друга линија, треба да ја проверите работата на серверот.

$ ps aux | греп кукла

кукла 5779 0,0 1,4 27764 15404 ? Ssl 21:49 0:00 рубин / usr/sbin/puppetmasterd

Заштитниот ѕид мора да дозволи поврзување на портата 8140.

На серверот добиваме листа на сертификати што треба да се потпишат.

$ sudo puppetca --листа

nomad.grinder.com

И го потпишуваме сертификатот на клиентот.

$ sudo puppetca – знак nomad.grinder.com

Сега клиентот може слободно да се поврзе со серверот и да прима поставки.

За жал, едноставно не е можно да се прикажат сите можности на куклата во написот. Но, како што можете да видите, ова е функционална и флексибилна алатка која ви овозможува да ги решите повеќето од проблемите со истовремена администрација на голем број системи. Ако вашата линија на работа бара од вас да поставите неколку системи. И што е најважно, проектот успеа да собере мала, но постојано растечка заедница. Затоа, да се надеваме дека добрата идеја нема да дозволи да умре или да тргне настрана.

Куклае крос-платформска структура која овозможува системски администраториИзвршете вообичаени задачи користејќи код. Кодот ви овозможува да извршувате различни задачи од инсталирање нови програми до проверка на дозволите за датотеки или ажурирање на кориснички сметки. Кукласупериорен не само при првичната инсталација на системот, туку и во текот на целиот животен циклус на системот. Во повеќето случаи кукласе користи во конфигурацијата на клиент/сервер.

Овој дел покажува инсталација и конфигурација Куклаво конфигурација на клиент/сервер. Овој едноставен пример покажува како да се инсталира Апачикористење Кукла.

Инсталација

За инсталација Куклавнесете во терминал:

Sudo apt-get install puppetmaster

На клиентската машина(и), внесете:

Sudo apt-get install кукла

Поставки

Пред да поставите кукла можеби ќе сакате да додадете запис DNS CNAMEЗа puppet.example.com, Каде пример.com- ова е вашиот домен. Стандардни клиенти Куклапроверете го DNS за puppet.example.com како име на куклен сервер ( Мајстор на кукли). Видете Услуга за име на домен за дополнителни детали за користење на DNS.

Ако немате намера да користите DNS, можете да додадете записи во датотеката /etc/hosts на серверот и клиентот. На пример, во датотеката /etc/hosts Кукладодаде сервер:

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

На секој КуклаВо клиентот, додадете запис за серверот:

192.168.1.16 кукла meercat.example.com

Заменете ги IP адресите и имиња на домениод примерот до вашите моментални адреси и имиња на серверот и клиентите.

Сега ајде да поставиме некои ресурси за апачи2. Направете датотека /etc/puppet/manifests/site.ppшто го содржи следново:

Пакет ( "apache2": осигурај => инсталиран ) услуга ( "apache2": осигурај => точно, овозможи => точно, бара => пакет["apache2"] )

Јазол „meercat02.example.com“ (вклучи apache2)

Заменете meercat02.example.comна вашето сегашно име Куклаклиент.

Последниот чекор за ова едноставно Кукласерверот треба да ја рестартира услугата:

Sudo /etc/init.d/puppetmaster рестарт

Од сега Кукласè е конфигурирано на серверот и време е да го конфигурирате клиентот.

Прво, ајде да ја конфигурираме услугата Куклаагент за лансирање. Уреди /etc/default/puppet, заменувајќи ја вредноста СТАРТна да:

Судо /etc/init.d/puppet start

Да се вратиме на Кукласерверот за потпишување на сертификатот на клиентот користејќи ја командата:

Судо кукла -- знак meercat02.example.com

Проверете /var/log/syslogза какви било грешки во конфигурацијата. Ако сè беше добро, пакетот апачи2и неговите зависности ќе бидат инсталирани на Куклаклиент.

Овој пример е многу едноставен и не покажува многу од карактеристиките и придобивките. Кукла. За дополнителни информациипогледнете

Сергеј Јаремчук

Централизирана конфигурација на UNIX системи со помош на Puppet

Управувањето со голем број UNIX системи не може да се нарече практично. За да промени еден параметар, администраторот треба да контактира со секоја машина; скриптите можат само делумно да помогнат, а не во сите ситуации.

Треба да се признае дека мрежните администратори на Windows сè уште се во поповолна позиција. Доволно е да ги смените поставките за групната политика и по некое време сите компјутери на мрежата, вклучително и оние со неодамна инсталиран оперативен систем, ќе „научат“ за иновацијата, ако тоа се разбира за нив се однесува. Гледајќи наназад во текот на долгиот период на развој на UNIX, можете да видите дека вакво нешто никогаш не се фатило. Постојат решенија како kickstart кои помагаат при првичната инсталација на оперативниот систем, но понатамошниот развој ќе бара значителен напор. Комерцијалните решенија, како BladeLogic и OpsWare, само делумно го решаваат проблемот со автоматизирање на поставките; нивната главна предност е присуството на графички интерфејс и само големите организации можат да си дозволат да ги купат. Има, се разбира, проекти кои нудат бесплатни решенија, но во текот на нивното постоење не можеа да создадат голема заедница. На пример, Cfengine не е многу популарен меѓу администраторите, иако, покрај Linux, може да се користи и во *BSD, Windows и Mac OS X. Ова може да се должи на релативната сложеност на креирањето конфигурации. Кога се опишуваат задачите, неопходно е да се земат предвид карактеристиките на секој специфичен систем и рачно да се контролира редоследот на дејства при извршување на командите. Тоа е, администраторот мора да запомни дека за некои системи треба да напишете adduser, за други - useradd, да ја земете предвид локацијата на датотеките на различни системи итн. Ова го отежнува процесот на пишување наредби по ред на големина, многу е тешко да се создаде правилна конфигурација во лет и речиси е невозможно да се прочитаат креираните конфигурации по некое време. И покрај лиценцата за GPL, Cfengine во суштина е проект од еден човек кој ги контролира сите промени и не е многу заинтересиран за градење отворено општество. Како резултат на тоа, можностите на Cfengine се доста задоволителни за развивачот, но за другите администратори тоа е прилично дополнителна главоболка. За да се подобри Cfengine, беа креирани различни додатоци од трети лица програмери, што често само ја влошуваше ситуацијата. Авторот на неколку такви модули за Cfengine, Лук Каниес, на крајот одлучи да развие слична алатка, но без многу недостатоци на Cfengine.

Карактеристики на кукли

Puppet, како и Cfengine, е систем на клиент-сервер кој користи декларативен јазик за опишување задачи и библиотеки за нивно спроведување. Клиентите периодично (стандардно на секои 30 минути) се поврзуваат со централниот сервер и ја добиваат најновата конфигурација. Доколку примените поставки не се совпаѓаат со состојбата на системот, тие ќе бидат извршени, а доколку е потребно, до серверот ќе се испрати извештај за извршените операции. Серверот за пораки може да го зачува во syslog или датотека, да креира RRD график и да го испрати на наведената е-пошта. Дополнителните трансакции и слоеви за апстракција на ресурси обезбедуваат максимална компатибилност со постоечките поставки и апликации, овозможувајќи ви да се фокусирате на системските објекти без да се грижите за разликите во имплементацијата и описот на деталните команди и формати на датотеки. Администраторот работи само со типот на објект, а за останатото се грижи Puppet. Така, типот на пакети знае околу 17 системи на пакети; потребниот автоматски ќе се препознае врз основа на информации за верзијата на дистрибуцијата или системот, иако, доколку е потребно, менаџерот на пакети може да се постави насилно.

За разлика од скриптите, кои често е невозможно да се користат на други системи, конфигурациите за кукли напишани од администратори од трети страни главно ќе работат без проблеми на која било друга мрежа. Куклен готвач веќе има триесетина готови рецепти. Puppet во моментов официјално ги поддржува следните оперативни системи и услуги: Debian, RedHat/Fedora, Solaris, SUSE, CentOS, Mac OS X, OpenBSD, Gentoo и MySQL, LDAP.

Куклен јазик

За да продолжите напред, прво мора да ги разберете основните елементи и способности на јазикот. Јазикот е една од силните страни на Puppet. Ги опишува ресурсите со кои администраторот планира да управува и активностите што ги презема. За разлика од повеќето слични решенија, Puppet му дозволува на јазикот да го поедностави пристапот до сите слични ресурси на кој било систем во хетерогена средина. Описот на ресурсите обично се состои од име, тип и атрибути. На пример, да укажеме на датотеката /etc/passwd и да ги поставиме нејзините атрибути:

датотека ("/etc/passwd":

Сопственик => корен,

Група => корен,

Режим => 644,

Сега клиентите што се поврзуваат со серверот ќе ја копираат датотеката /etc/passwd и ќе ги постават наведените атрибути. Можете да дефинирате повеќе ресурси во едно правило, раздвојувајќи ги со помош на точка-запирка. Но, што ако конфигурациската датотека што се користи на серверот се разликува од клиентските или воопшто не се користи? На пример, оваа ситуација може да се појави при поставување VPN конекции. Во овој случај, треба да укажете на датотеката користејќи ја изворната директива. Овде има две опции; можете, како и обично, да ја одредите патеката до друга датотека, а исто така да ги користите двата поддржани URI протоколи: датотека и кукла. Во првиот случај, се користи врска до надворешен NFS сервер; во втората опција, услуга слична на NFS се активира на серверот Puppet, кој извезува ресурси. Во вториот случај, стандардната патека е во однос на root директориумот на куклата – /etc/puppet. Односно, врската puppet://server.domain.com/config/sshd_config ќе одговара на датотеката /etc/puppet/config/sshd_config. Можете да го отфрлите овој директориум користејќи ја директивата за кофа за датотеки, иако е поправилно да се користи истоимениот дел во датотеката /etc/puppet/fileserver.conf. Во овој случај, можете да го ограничите пристапот до услугата само на одредени адреси. На пример, да го опишеме делот за конфигурација:

Патека /var/puppet/config

Дозволи *.domain.com

Дозволи 127.0.0.1

Дозволи 192.168.0.*

Дозволи 192.168.1.0/24

Одбијте *.wireless.domain.com

И тогаш се повикуваме на овој дел кога го опишуваме ресурсот:

извор => "puppet://server.domain.com/config/sshd_config"

Пред дебелото црево е името на ресурсот. Во наједноставните случаи, можете едноставно да ја наведете целосната патека до датотеката како име. Во посложени конфигурации подобро е да се користи псевдоним или променливи. Алијасот е поставен со помош на директивата за алијас:

датотека ("/etc/passwd":

Алијас => passwd

датотека (sshdconfig:

Име => $оперативен систем ? (

Соларис => "/usr/local/etc/ssh/sshd_config",

Стандардно => "/etc/ssh/sshd_config"

Во овој пример, ние сме соочени со избор. Датотеката за Solaris е наведена посебно, за сите други ќе биде избрана датотеката /etc/ssh/sshd_config. Сега овој ресурс може да се пристапи како sshdconfig, во зависност од оперативниот систем ќе се избере саканата патека. На пример, укажуваме дека ако sshd демонот работи и е примена нова датотека, услугата треба да се рестартира:

услуга(sshd:

Обезбедете => точно,

Претплатете се => Датотека

$homeroot = "/home"

Сега до датотеките на одреден корисник може да се пристапи како:

$(homeroot)/$име

Параметарот $name ќе се пополни со името на сметката на корисникот. Во некои случаи, погодно е да се дефинира стандардна вредност за некој тип. На пример, за типот exec многу е вообичаено да се наведат директориумите во кои треба да се бара извршната датотека:

Exec ( патека => "/usr/bin:/bin:/usr/sbin:/sbin" )

Ако треба да укажете на неколку вгнездени датотеки и директориуми, можете да го користите параметарот за повторување:

датотека ("/etc/apache2/conf.d":

Извор => "puppet:// puppet://server.domain.com/config/apache/conf.d",

Повторување => „вистинито“

Повеќе ресурси може да се комбинираат во класи или дефиниции. Класите се целосен опис на систем или услуга и се користат одделно:

класа Linux (

Датотека (

"/etc/passwd": сопственик => корен, група => корен, режим => 644;

„/etc/shadow“: сопственик => корен, група => корен, режим => 440

класата freebsd го наследува Linux (

Датотека["/etc/passwd"] (група => тркало);

Датотека["/etc/shadow"] (група => тркало)

За погодност, сите класи може да се стават во посебна датотека, која мора да биде вклучена со помош на директивата за вклучување. Дефинициите може да земат повеќе параметри како аргументи, но не поддржуваат наследување и се користат кога треба да опишете објекти за повеќекратна употреба. На пример, да го дефинираме домашниот директориум на корисникот и командите потребни за создавање нова сметка:

дефинирај user_homedir ($group, $fullname, $ingroups) (

Корисник ("$name":

Обезбедете => присутни,

Коментар => „$fullname“,

Gid => „$group“,

Групи => $ingroups,

Членство => минимум,

Школка => "/bin/bash",

Почетна => "/home/$name",

Бара => Група[$група],

Exec("$name homedir":

Команда => "/bin/cp -R /etc/skel /home/$name; /bin/chown -R $name:$group /home/$name",

Создава => "/home/$name",

Бара => Корисник[$name],

Сега, за да креирате нова сметка, само контактирајте со user_homedir:

user_homedir("сергеј":

Група => "сергеј",

Целосно име => „Сергеј Јаремчук“,

Ингрупи => [„медиуми“, „админ]

Постојат посебни описи на јазли кои поддржуваат наследување, како и класи. Кога клиентот ќе се поврзе со серверот Puppet, ќе се пребарува соодветниот дел на јазол и ќе се обезбедат поставки специфични само за овој компјутер. За да ги опишете сите други системи, можете да го користите стандардниот јазол. Опис на сите видови е даден во документот „Референца на типот“, кој во секој случај мора да се прочита, барем за да се разберат сите способности на куклен јазик. Различни типови ви дозволуваат да извршувате одредени команди, вклучително и кога се исполнети одредени услови (на пример, промена на конфигурациска датотека), работа со cron, кориснички ингеренции и групи, компјутери, ресурси за монтирање, стартување и стопирање услуги, инсталирање, ажурирање и отстранување на пакети , работа со SSH клучеви, зони Solaris итн. Вака лесно можете да натерате списокот на пакети во дистрибуции со помош на apt да се ажурира секојдневно помеѓу 2 и 4 часа:

распоред (дневно:

Период => дневно,

Опсег =>

exec("/usr/bin/apt-get ажурирање":

Распоред => дневно

Инсталирање кукла

Puppet бара Ruby (верзија 1.8.1 и погоре) со OpenSSL поддршка и XMLRPC библиотеки, како и библиотека Faster. Складиштето на Ubuntu 7.04 што се користеше за тест инсталација веќе го вклучува пакетот за кученце:

$ sudo apt-cache кукла за пребарување

~$ ruby ‎-rxmlrpc/client -e „puts:yep“

да

Ако не се добиени грешки, тогаш сè што ви треба е веќе вклучено. Датотеките што ја опишуваат саканата конфигурација на системите се нарекуваат манифестации во куклена терминологија. Кога ќе се стартува, демонот се обидува да ја прочита датотеката /etc/puppet/manifests/site.pp; ако ја нема, прикажува предупредувачка порака. Кога тестирате, можете да му кажете на демонот да работи во самостоен режим, што не бара манифест:

$ sudo /usr/bin/puppetmasterd --nodes

Доколку е потребно, можете да поврзете други датотеки со site.pp, на пример, со описи на класи. За тестирање, можете да ги внесете наједноставните инструкции во оваа датотека.

класа судо (

Датотека ("/etc/sudoers":

Сопственик => корен,

Група => корен,

Режим => 440,

стандарден јазол(

Вклучете судо

Сите конфигурациски датотеки, и серверот и клиентот, се наоѓаат во /etc/puppet. Датотеката fileserver.conf, за која веќе зборувавме, е опционална и се користи само ако Puppet ќе работи и како сервер за датотеки. На Ubuntu, оваа датотека го извезува поддиректориумот /etc/puppet/files. Поддиректориумот ssl содржи сертификати и клучеви кои ќе се користат за шифрирање при поврзување на клиенти. Копчињата се креираат автоматски првиот пат кога ќе го стартувате puppetmasterd; можете да ги креирате рачно со командата:

$ sudo /usr/bin/puppetmasterd --mcusers

сервер = мелница.com

logdir = /var/log/кукла

vardir = /var/lib/кукла

rundir = /var/run

# испрати извештај до серверот

извештај = точно

За да избегнете рачно пишување сè, можете да креирате шаблон користејќи го самиот puppetd:

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

Слично на тоа, можете да креирате site.pp на серверот:

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

Друга датотека, tagmail.conf, ви овозможува да одредите адреси на е-пошта до кои ќе се испраќаат извештаи. Во наједноставниот случај, можете да користите една линија:

сите: [заштитена е-пошта]

Конфигурациските датотеки не се доволни за клиентот да се поврзе со серверот. За да го направите ова, исто така треба да ги потпишете сертификатите.

Прво, за да го известите серверот за новиот компјутер, внесете ја командата на системот на клиентот:

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

Заштитниот ѕид мора да дозволи поврзување на портата 8140.

На серверот добиваме список на сертификати што треба да се потпишат:

$ sudo puppetca –листа

nomad.grinder.com

И потпишете го сертификатот за клиентот:

$ sudo puppetca – знак nomad.grinder.com

Сега клиентот може слободно да се поврзе со серверот и да прима поставки.

За жал, невозможно е да се прикажат сите можности на куклата во статијата. Но, како што можете да видите, ова е функционална и флексибилна алатка која ви овозможува да ги решите повеќето проблеми со истовремена администрација на голем број системи. И што е најважно, проектот успеа да собере мала, но постојано растечка заедница. Затоа, да се надеваме дека добрата идеја нема да дозволи да умре или да тргне настрана.

Со среќа!