Инсталиране и конфигуриране на Puppet сървър. Инсталирайте марионетка и създайте своя първи манифест. Пълен списък с параметри на Bash за скрипта за инициализиране на клиент Puppet

Неотдавна на страниците на списанието разгледахме системата дистанционно Cfengine UNIX машинна конфигурация, която прави живота много по-лесен системен администраторчрез автоматизиране на стъпките за конфигуриране на множество мрежови възли. Но колкото и удобен да е Cfengine, той има много недостатъци, които система, наречена Puppet, няма.

Представете си себе си в ролята на системен администратор, отговорен за поддържането на функционалността на стотици машини, работещи с операционни системи тип UNIX. Всеки от тях изисква конфигурация, периодично обновяване и мониторинг, като се предполага, че много от тях изпълняват сходни функции.

Две трети са работни станции, още няколко са рутери, а останалите са няколко уеб сървъра и хранилища за данни. Въпрос: как да управлявате целия този бизнес? Най-простият отговор е просто да се свържете с всеки от тях чрез SSH и да направите необходимите промени. Този метод обаче има два проблема. Първо, това е много трудоемко. Второ, администраторът постоянно ще трябва да извършва много монотонни действия (например, за да актуализирате OpenOffice.org на всички работни станции, ще трябва да изпълните едни и същи команди няколко десетки пъти). Можете да опитате да избегнете този проблем, като напишете няколко скрипта, които сами ще се свързват към всяка машина и ще изпълняват предварително написани команди. Но и тук ви очакват проблеми.

Скриптовете постоянно ще трябва да се променят, за да се адаптират към всяка задача; Скриптовете ще трябва да вземат предвид разликите в операционните системи и версиите и ще трябва да бъдат отстранявани грешки за дълго време, преди да бъдат приложени към работещи машини. Като цяло, не комилфо. Правилният отговор е да се използват така наречените системи за управление на отдалечена конфигурация, най-известните представители на които са отворени системи Cfengine и Puppet. Такива системи поемат всички отговорности за привеждане на конфигурацията на машината до желаната форма, като изискват от администратора само да опише крайното състояние на системата на специален език (например описание на това кои пакети трябва да бъдат инсталирани в операционната система, които трябва да се добавят редове към конфигурационните файлове, кои команди трябва да бъдат изпълнени и т.н.). След това всички възли сами ще получат информация за необходимото състояние от сървъра и ще извършат автоматично конфигуриране на системата. Благодарение на този механизъм новите машини могат да бъдат напълно конфигурирани без човешка намеса, а съществуващите могат да бъдат преконфигурирани чрез добавяне само на няколко реда към описанието на състоянието.

Куклен?

Вече посветихме цяла статия на системата Cfengine, така че днес ще се съсредоточим върху системата Puppet, която може да се нарече неин идеологически наследник. Puppet е разработен от Luke Kanies, който се уморява от ограниченията на Cfengine и решава да създаде по-добра версия от нулата. Ако вече сте използвали Cfenfine, вероятно ще намерите Puppet за по-удобна и мощна система. Държавният език на Puppet е по-високо ниво и гъвкав, което означава, че администраторът не трябва да се тревожи за неща като писане на отделни правила за всеки тип ОС или Подробно описаниеизвършване на тривиални действия. Puppet позволява на господаря си да се съсредоточи върху това, което иска да направи, вместо върху това как да го направи (например, за да инсталирате определен пакет на която и да е от поддържаните от системата операционни системи, просто трябва да напишете буквално няколко реда, казвайки „Инсталирайте тази програма " вместо да описва командите, необходими за инсталирането му). Puppet е написано в на прост език Ruby, което улеснява адаптирането му към конкретна задача и разширяване на функционалността му (осигурена е гъвкава система от плъгини).

Освен това, за разлика от модела на разработка на Cfengine, който по същество се върти около един човек, Puppet има голяма общност от ентусиасти, които правят подобрения в кода, споделят примери за конфигурация и пишат документация.

Като цяло Puppet изглежда по-модерна и сложна система с добър дизайн. Подобно на Cfengine, той поддържа почти всички съвременни UNIX-подобни операционни системи (включително MacOS X) и може също да работи в среда Cygwin върху Windows. Неговият списък със зависимости включва само интерпретатора на Ruby и инструмента Factor, така че не би трябвало да има проблеми с инсталацията (честно казано, списъкът със зависимости на Cfengine е още по-кратък).

Инсталация

Подобно на Cfengne, Puppet е система клиент-сървър, която се състои от контролен сървър и подчинени възли. Сървърът съхранява описание на крайните състояния на възлите (което в термините на Puppet се нарича манифест) и ги чака да се свържат. На всеки половин час (по подразбиране) клиентът се свързва със сървъра, получава от него описание на крайното състояние, сравнява го с текущото и ако то и/или описаното състояние се е променило, преконфигурира системата и след това отива да спи. Комуникацията се осъществява чрез криптиран канал, така че атаките, базирани на подмяна на описанието на състоянието, са изключени (но ако нападател превземе сървъра, тогава всички възли ще бъдат под негов контрол).

Puppet е включен в хранилищата на всички популярни дистрибуции, така че инсталирането му не би трябвало да е трудно. Например, на Debian/Ubuntu клиентът Puppet може да бъде инсталиран по следния начин:

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

А сървъра е така:

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

Конфигурационните файлове на клиента и сървъра се съхраняват в директорията /etc/puppet. Най-важният от тях е файлът /etc/puppet/manifests/site.pp, който съдържа манифеста.

Той съхранява описание на състоянията и трябва да съществува само на сървъра. За по-лесно отстраняване на грешки, нека добавим проста конфигурация към него:

клас passwd(
файл ("/etc/passwd":
собственик => root,
група => корен,
режим => 644,
}
}
възел по подразбиране(
включи парола
}

Тези редове описват условие, при което собственикът на файла /etc/passwd трябва да е root и неговите разрешения са зададени на 644. Ще разгледаме по-отблизо файловия формат на манифеста в следващия раздел. Вторият най-важен файл е /etc/puppet/puppet.conf. Той задава конфигурацията на сървъра и клиентите, така че трябва да присъства на всички машини, организирани в мрежата Puppet. В Ubuntu този файл съдържа минимално необходимите и в повечето случаи достатъчни настройки. По-долу са дадени с коментари:

# vi /etc/puppet/puppet.conf
# Стандартни пътища на директория
logdir=/var/log/кукла
vardir=/var/lib/кукла
ssldir=/var/lib/puppet/ssl
rundir=/var/run/puppet
# Факторно местоположение на инструмента,
# използва се за получаване на информация за операционната система
factpath=$vardir/lib/facter
# Синхронизиране на плъгини
# (инсталирани добавки на сървъра - те се копират на клиенти)
pluginsync=true
# Каталог с шаблони (прочетете за тях по-долу)
templatedir=$confdir/templates
# Синхронизация с etckeeper
# (който знае, ще разбере, на другите не им трябва)
prerun_command=/etc/puppet/etckeeper-commitpre
postrun_command=/etc/puppet/etckeeper-commitpost

Конфигурационният файл може да включва голям брой различни опции, информация за които може да бъде получена чрез генериране на конфигурация по подразбиране:

$ sudo puppetmasterd -genconfig > /etc/puppet/
puppetd.conf.default

Клиентската конфигурация по подразбиране се генерира с помощта на друга команда:

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

Файловете Fileserver.conf и auth.conf се използват за конфигуриране файлов сървър(прочетете за това в раздела „Файлов сървър“) и удостоверяване. Още няма смисъл да ги пипаме. След като конфигурирането приключи, Puppet сървърът трябва да се рестартира:

$ sudo /etc/init.d/puppetmaster рестартирайте

След което той ще бъде готов да приема заявки от клиенти. Въпреки това, без подписан сертификат, никой клиент няма да може да получи манифеста от сървъра и да конфигурира машината.

Следователно трябва да стартираме клиентите на Puppet в тестов режим, за да могат да изпратят своите сертификати на сървъра за подписване (между другото, това може да се направи на всички машини едновременно с помощта на инструмента shmux):

$ sudo puppetd -server puppet-server.com -verbose -test

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

$ sudo марионетка --списък

Изберете хост от списъка и подпишете неговия сертификат:

$ sudo puppetca --sign nomad.grinder.com

Или подписваме всичко наведнъж:

$ sudo puppetca --знак --всички

Сега можете да стартирате клиенти в боен режим. Но първо трябва да въведете името на Puppet сървъра в конфигурационния файл (по подразбиране името му е просто Puppet):

$sudo su
# echo "" >> /etc/puppet/puppet.conf
# echo "server=puppet-server.com" >> /etc/puppet/puppet.conf
# изход

Стартиране на клиенти:

$ sudo /etc/init.d/puppet start

Език за описание на държавата

Както бе споменато по-горе, Puppet използва свой собствен език за описание на крайното състояние операционна система, с помощта на който системният администратор посочва до какъв вид трябва да бъдат приведени компонентите на ОС, за да достигне тя желаното състояние. Това е доста сложен език, който обаче е много по-прост от всеки език за програмиране. Ако сте поне повърхностно запознати със скриптовия език bash, лесно ще разберете езика Puppet. Ключовият елемент на езика са ресурсите, които се използват, за да опишат в каква форма трябва да се конвертира един от компонентите на ОС. Например следното най-простият ресурсописва желаното състояние на файла /etc/passwd:

# vi /etc/puppet/manifests/site.pp
файл ("/etc/passwd":
собственик => "root"
}

Тук файлът е типът ресурс. Има общо няколко десетки от тях, вариращи от ресурси, които управляват файлове, както в този пример, до пакети и услуги. Редът /etc/passwd е името на ресурса.

В случая на файловия тип името е същото като пътя до файла, но в някои други типове името може да бъде произволно. Редът owner => "root" описва настройката на атрибута owner на root, тоест казва, че собственикът посочен файлтрябва да има администратор.

Всеки тип ресурс има свой собствен набор от атрибути, достъпни за модифициране, плюс има специални мета атрибути, които могат да се използват във всеки ресурс. Едно от важните качества на ресурсите е възможността за свързване към тях. Това може да се използва за формиране на вериги на зависимости. Следният запис създава ресурса /etc/group, който зависи от ресурса /etc/passwd (зависимостите се посочват с помощта на атрибута meta meta):

# vi /etc/puppet/manifests/site.pp
файл ("/etc/group":
изисквам => Файл["/etc/passwd"],
собственик => "root",
}

Това означава, че ресурсът /etc/group може да бъде конфигуриран (доведен до описаната форма) само когато ресурсът /etc/passwd е конфигуриран. Ресурсите могат да бъдат групирани в колекции от ресурси, наречени класове. Това е необходимо, за да се комбинират ресурси, които са сходни по значение и тип изпълнявана задача в един абстрактен ресурс. Например, за удобство бихме могли да комбинираме инсталирането и стартирането на уеб сървъра nginx в един абстрактен ресурс със същото име:

# vi /etc/puppet/manifests/site.pp
клас nginx(
пакет ("nginx":
осигурете => инсталиран
}
услуга ("nginx":
гарантирам => работи,
изисквам => Пакет["nginx"],
}
}

Тук типът ресурс на пакета се използва за инсталиране на пакета nginx в системата, а услугата се използва за стартиране на услугата със същото име. С require принуждаваме системата да стартира услугата само ако пакетът е инсталиран успешно. Удобството на класовете е, че могат да се включват и в зависимост от:

# vi /etc/puppet/manifests/site.pp
услуга ("калмари":
гарантирам => работи,
изискват => Клас["nginx"],
}

Както в реалните ООП езици, класовете могат да се наследяват един от друг и да заместват атрибути:

# vi /etc/puppet/manifests/site.pp
клас passwd(
файл ("/etc/passwd":
собственик => "root",
група => "корен",
}
}
клас passwd-bsd наследява passwd (
Файл ["/etc/passwd"] ( група => "колело" )
}

Тук класът passwd-bsd наследява от passwd, за да замени груповия атрибут на ресурса /etc/passwd (на BSD системите /etc/passwd принадлежи към групата wheel, така че създадохме отделен клас за такива системи). По-късно ще разгледаме по-правилен и очевиден начин за избор на алтернативни стойности на атрибути с помощта на условия.

Променливите са един от неразделните компоненти на всеки език за програмиране и Puppet също ги има. Променливите започват със знак $ и могат да съдържат произволно число, низ или булева стойност (true, false):

$want_apache = вярно
$apache_version = "2.2.14"

Една от най-мощните функции на Puppet, свързани с променливи, е интегрирането му с инструмента за информация на машината facter. Тази помощна програма връща цялата информация, специфична за машината, под формата на двойки ключ-стойност, които се превръщат в променливи със същото име в Puppet. Заедно с условни инструкции на езика Puppet, те могат да се използват за промяна на ресурсните атрибути в зависимост от свойствата на машината.

Например класът passwd, описан по-горе, може лесно да бъде пренаписан, за да избира автоматично атрибут в зависимост от типа на ОС (без да е необходим самият клас):

# vi /etc/puppet/manifests/site.pp
файл ("/etc/passwd":
собственик => "root",
група => $ядро? (
Linux => "root",
FreeBSD => "колело",
},
}

В зависимост от това на коя операционна система ще бъде анализиран този фрагмент от манифеста, стойността на груповия атрибут ще бъде root или wheel. В допълнение към условния оператор, езикът Puppet поддържа и оператора за избор на регистър, който може да се използва за създаване на определен ресурс в зависимост от стойността на променлива:

# vi /etc/puppet/manifests/site.pp
случай $операционна система (
redhat: (услуга ("httpd": осигурете => работи))
debian: (услуга ("apache": осигурете => работи))
по подразбиране: ( услуга ( "apache2": secure =>
тичам))
}

Този код определя различни опцииресурс от тип услуга в зависимост от операционната система (имената на услугите в различните дистрибуции на Linux може да се различават, така че коя услуга да изпълнява Puppet трябва да се посочи индивидуално за всяка от тях).

Опцията по подразбиране се използва, ако стойността на променливата не съвпада с нито една от предишните опции. В допълнение към обсъдените по-рано типове ресурси за файлове, пакети и услуги, Puppet поддържа голям брой други типове ресурси, включително тези, създадени от разработчици на трети страни. Тяхното подробно описание, включително примери, поддържани атрибути и функции, може да бъде намерено в официалната документация - http://docs.puppetlabs.com/references/stable/type.html. По-долу има списък и Кратко описаниенай-използваните са:

Файлов сървър

Много задачи за отдалечено администриране не могат да бъдат решени без копиране на машини допълнителни файлове. Това могат да бъдат предварително подготвени конфигурации, уеб страници за Apache, пакети, които не са в официалното хранилище и много други. За да улесни процеса на прехвърляне на тези файлове към отдалечени хостове, Puppet включва файлов сървър.

Настройките на файловия сървър се съхраняват във файла /etc/puppet/fileserver.conf. За да принудите Puppet да обслужва съдържанието на конкретна директория на клиенти, трябва да поставите няколко реда в нея:

# vi /etc/puppet/fileserver.conf
път = /var/puppet/files
разреши *.server.com

Тези два реда показват, че директорията /var/puppet/files трябва да бъде достъпна за всички хостове в домейна server.com. Освен това можем да посочим пълния Име на домейнразрешената машина или нейния IP адрес, както и да отрежете нежеланите с помощта на директивата deny. След това всеки файл в тази директория може да бъде преместен на клиента с помощта на файловия ресурс. Например:

# vi /etc/puppet/manifests/site.pp
файл ("/etc/httpd/conf/httpd.conf":
източник => "кукла //httpd/httpd.conf",
режим => 644,
}

Файлът httpd.conf, намиращ се на сървъра в директорията /var/puppet/files/httpd, ще бъде копиран на целевата машина по пътя, посочен в името на ресурса.

заключения

В тази статия разгледахме много малка част от възможностите на Puppet. Всъщност това е сложна система, която може да бъде описана напълно само на страниците на книга. В същото време Puppet е много лесен за конфигуриране и поддръжка, особено след като можете да намерите много примери за неговата конфигурация в мрежата.

Информация

Puppet използва HTTP протокола, така че може да се изпълнява под уеб сървър за подобряване на производителността.
Puppet може да се използва за автоматично конфигуриране и поддържане на една локална машина.
Чрез комбиниране на Puppet, мрежова инсталация OS (pxe-install) и самосглобени инсталационни изображения, можете да създадете напълно самоконфигурираща се мрежа от машини, които могат да бъдат разгърнати само с една команда.
Много хора използват Puppet в работата си. големи компании, като Google, Fedora Project, Stanford University, Red Hat, Siemens IT Solution и SugarCRM.

Връзки

http://docs.puppetlabs.com - Документация за кукли
http://docs.puppetlabs.com/guides/language_tutorial.html - Пълно описаниеКуклен език
http://docs.puppetlabs.com/references/stable/type.html - Типове ресурси

Сергей Яремчук

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

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

Трябва да се признае, че Windows администратори-мрежите все още са в по-изгодна позиция. Просто променете настройките групови политики, а след известно време всички компютри в мрежата, включително и тези с наскоро инсталирана операционна система, „научават“ за иновацията, ако се отнася за тях, разбира се. Поглеждайки назад през дългия период на разработка на UNIX, можете да видите, че нищо подобно никога не се е утвърдило. Има решения като кикстарт, които помагат при първоначалното инсталиране на операционната система, но по-нататъшното развитие ще изисква значителни усилия. Търговските решения, като BladeLogic и OpsWare, решават проблема с автоматизирането на настройките само частично; основното им предимство е наличието на графичен интерфейс и само големи организации могат да си позволят да ги закупят. Има, разбира се, проекти, които предлагат безплатни решения, но през цялото си съществуване не са успели да създадат голяма общност. Например Cfengine не е много популярен сред администраторите, въпреки че в допълнение към Linux може да се използва в *BSD, Windows и Mac OS X. Това може да се дължи на относителната сложност на създаването на конфигурации. При описване на задачи е необходимо да се вземат предвид характеристиките на всяка конкретна система и ръчно да се контролира последователността от действия при изпълнение на команди. Тоест, администраторът трябва да помни, че за някои системи трябва да напишете adduser, за други - useradd, вземете предвид местоположението на файловете в различни системии така нататък. Това усложнява процеса на писане на команди с порядък, много е трудно да се създаде правилната конфигурация в движение и е почти невъзможно да се прочетат създадените конфигурации след известно време. Въпреки лиценза GPL, Cfengine е по същество проект от един човек, който контролира всички промени и не е много заинтересован от изграждането на отворено общество. В резултат на това възможностите на Cfengine са доста задоволителни за разработчика, но за други администратори това е по-скоро допълнително главоболие. За подобряване на Cfengine бяха създадени различни добавки от разработчици на трети страни, които често само влошаваха ситуацията. Авторът на няколко такива модула за Cfengine, Luke Kanies, в крайна сметка реши да разработи подобен инструмент, но без много от недостатъците на Cfengine.

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

Puppet, подобно на Cfengine, е система клиент-сървър, която използва декларативен език, за да опише задачи и библиотеки за тяхното изпълнение. Клиентите периодично (на всеки 30 минути по подразбиране) се свързват с централния сървър и получават най-новата конфигурация. Ако получените настройки не съответстват на състоянието на системата, те ще бъдат изпълнени и при необходимост ще бъде изпратен отчет за извършените операции до сървъра. Сървърът за съобщения може да го запише в syslog или във файл, да създаде RRD графика, да го изпрати до посочен имейл. Допълнителните слоеве за абстракция на транзакции и ресурси осигуряват максимална съвместимост със съществуващи настройки и приложения, което ви позволява да се съсредоточите върху системни обекти, без да се притеснявате за разликите в изпълнението и описанието подробни командии файлови формати. Администраторът работи само с типа обект, Puppet се грижи за останалото. По този начин типът пакети познава около 17 пакетни системи; необходимата ще бъде автоматично разпозната въз основа на информация за версията на дистрибуцията или системата, въпреки че, ако е необходимо, мениджърът на пакети може да бъде зададен принудително.

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

Куклен език

За да продължите напред, първо трябва да разберете основните елементи и възможности на езика. Езикът е един от силни страниКуклен. Той описва ресурсите, които администраторът планира да управлява, и действията, които предприема. За разлика от повечето подобни решения, Езикът на Puppet улеснява достъпа до всички подобни ресурси на всяка система в хетерогенна среда. Описанието на ресурса обикновено се състои от име, тип и атрибути. Например, нека посочим файла /etc/passwd и зададем неговите атрибути:

файл ("/etc/passwd":

Собственик => root,

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

Режим => 644,

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

Път /var/puppet/config

Разрешаване на *.domain.com

Разрешаване на 127.0.0.1

Разрешаване на 192.168.0.*

Разрешаване на 192.168.1.0/24

Отказ *.wireless.domain.com

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

източник => "кукла //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 демонът работи и получава нов файл, трябва да рестартирате услугата:

услуга (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": собственик => root, група => root, режим => 644;

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

Както в обектно-ориентираните езици, класовете могат да бъдат заменени. Например във FreeBSD груповият собственик на тези файлове е wheel. Ето защо, за да не пренапишем напълно ресурса, нека създадем нов клас freebsd, който ще наследи класа на Linux:

клас freebsd наследява linux (

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

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

За удобство могат да се поставят всички класове отделен файл, които трябва да бъдат включени с директивата за включване. Дефинициите могат да приемат множество параметри като аргументи, но не поддържат наследяване и се използват, когато трябва да опишете повторно използвани обекти. Например, нека дефинираме домашната директория на потребителя и командите, необходими за създаване на нов акаунт:

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

Потребител("$name":

Уверете се => присъства,

Коментар => "$пълно име",

Gid => "$group",

Групи => $ingroups,

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

Shell => "/bin/bash",

Начало => "/home/$name",

Изискване => Група[$group],

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 сървъра, съответният раздел на възела ще бъде претърсен и ще бъдат предоставени настройки, специфични само за този компютър. За да опишете всички други системи, можете да използвате подразбиране на възел. Описанието на всички типове е дадено в документа „Справочник на типове“, който трябва да се прочете във всеки случай, поне за да се разберат всички възможности на езика Puppet. Различни видовеви позволяват да изпълнявате определени команди, включително когато са изпълнени определени условия (например промяна на конфигурационен файл), работа с cron, потребителски идентификационни данни и групи, компютри, ресурси за монтиране, стартиране и спиране на услуги, инсталиране, актуализиране и премахване на пакети, работа със SSH ключове, Solaris зони и т.н. Ето как можете лесно да накарате списъка с пакети в дистрибуции, използвайки apt, да се актуализира ежедневно между 2 и 4 часа:

график (ежедневно:

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

Обхват =>

exec("/usr/bin/apt-get актуализация":

График => ежедневно

Актуализацията за този период ще бъде извършена от всяка система само веднъж, след което задачата се счита за изпълнена и ще бъде изтрита от клиентския компютър. Езикът Puppet поддържа други познати структури: условия, функции, масиви, коментари и други подобни.

Инсталиране на Puppet

Puppet изисква Ruby (версия 1.8.1 и по-нова) с поддръжка на OpenSSL и XMLRPC библиотеки, както и библиотеката Faster. Хранилището на Ubuntu 7.04, което беше използвано за тестовата инсталация, вече включва пакета puppy:

$ sudo apt-cache марионетка за търсене

~$ ruby -rxmlrpc/клиент -e "puts:yep"

да

Ако не се получат грешки, значи всичко, от което се нуждаете, вече е включено. Файловете, които описват желаната конфигурация на системите, се наричат манифести в терминологията на Puppet. Когато се стартира, демонът се опитва да прочете файла /etc/puppet/manifests/site.pp; ако той липсва, показва предупредително съобщение. Когато тествате, можете да кажете на демона да работи в самостоятелен режим, който не изисква манифест:

$ sudo /usr/bin/puppetmasterd --nonodes

Ако е необходимо, можете да свържете други файлове към site.pp, например с описания на класове. За тестово изпълнение можете да въведете най-простите инструкции в този файл.

клас sudo (

Файл ("/etc/sudoers":

Собственик => root,

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

Режим => 440,

възел по подразбиране(

Включете sudo

Всички конфигурационни файлове, сървърни и клиентски, се намират в /etc/puppet. Файлът fileserver.conf, за който вече говорихме, не е задължителен и се използва само ако Puppet ще работи и като файлов сървър. В Ubuntu този файл експортира поддиректорията /etc/puppet/files. Поддиректорията ssl съдържа сертификати и ключове, които ще се използват за криптиране при свързване на клиенти. Ключовете се създават автоматично при първото стартиране на puppetmasterd; можете да ги създадете ръчно с командата:

$ sudo /usr/bin/puppetmasterd --mkusers

Файловете puppetd.conf и puppetmasterd.conf са подобни. Те посочват някои параметри за работата на демоните на клиентската система и сървъра. Клиентският файл се различава само по присъствието параметър на сървъра, сочейки към компютъра, работещ с puppetmasterd:

сървър = grinder.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

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

За съжаление е невъзможно да се покажат всички възможности на Puppet в статията. Но, както можете да видите, това е функционален и гъвкав инструмент, който ви позволява да решите повечето от проблемите на едновременното администриране на голям брой системи. И най-важното, проектът успя да събере малка, но постоянно нарастваща общност. Затова да се надяваме, че една добра идея няма да бъде оставена да умре или да замине.

Късмет!

Уебсайт на проекта BladeLogic – http://www.bladelogic.com.
Уебсайтът на проекта OpsWare е http://www.opsware.com.
Уебсайтът на проекта Cfengine е http://www.cfengine.org.
Уебсайтът на проекта Puppet е http://reductivelabs.com/projects/puppet.
Готварска книга за кукли - http://www.reductivelabs.com/trac/puppet/tagspuppet%2Crecipe.
По-бърза библиотека –

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

Трябва да се признае, че администраторите Windows мреживсе още са в по-изгодна позиция. Достатъчно е да промените настройките на груповата политика и след известно време всички компютри в мрежата, включително тези с наскоро инсталирана операционна система, ще „научат“ за иновацията, ако тя ги засяга, разбира се. Поглеждайки назад през дългия период на разработка на Unix, ще забележите, че нищо подобно не се е утвърдило. Има решения като кикстарт, които помагат при първоначалното инсталиране на операционната система, но по-нататъшното развитие ще изисква значителни усилия. Търговски решения като BladeLogic и OpsWare само частично решават проблема с автоматизирането на настройките; основното им предимство е наличието на графичен интерфейс и те могат да бъдат закупени само в големи организации. Има, разбира се, проекти, предлагащи безплатни решения, но през цялото си съществуване те никога не са успели да създадат голяма общност. Например Cfengine не е много популярен сред администраторите, въпреки че в допълнение към Linux може да се използва в *BSD, Windows и Mac OS X. Това може да се дължи на относителната сложност на създаването на конфигурации. Когато описвате задачи, трябва да вземете предвид характеристиките на всяка конкретна система и ръчно да контролирате последователността от действия при изпълнение на команди. Тоест, администраторът трябва да помни, че за някои системи трябва да напишете adduser за други, useradd, да вземете предвид местоположението на файловете в различни системи и т.н. Това усложнява процеса на писане на команди с порядък, много е трудно да се създаде правилната конфигурация в движение и е почти невъзможно да се прочетат създадените конфигурации след известно време. Въпреки GPL лиценза, Cfengine всъщност е проект от един човек, който контролира всички промени и не се интересува много от изграждането на отворено общество. В резултат на това възможностите на cfengine са доста задоволителни за разработчика, но за други администратори това е по-скоро допълнително главоболие. За подобряване на cfengine бяха създадени различни добавки от разработчици на трети страни, което често само влошаваше ситуацията. Авторът на няколко такива модула за cfengine, Luke Kanies, в крайна сметка реши да разработи подобен инструмент, но без много от недостатъците на cfengine.

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

Puppet, подобно на cfengine, е система клиент-сървър, която използва декларативен, тоест задължителен език за описание на задачи и библиотеки за тяхното изпълнение. Клиентите периодично (30 минути по подразбиране) се свързват с централния сървър и получават най-новата конфигурация. Ако получените настройки не съответстват на състоянието на системата, те ще бъдат изпълнени и при необходимост ще бъде изпратен отчет за извършените операции до сървъра. Сървърът може да записва съобщения в syslog или във файл, да създава RRD графика и да ги изпраща на определен имейл. Допълнителните слоеве за абстракция на транзакции и ресурси осигуряват максимална съвместимост със съществуващите настройки и приложения, което ви позволява да се съсредоточите върху системни обекти, без да се притеснявате за разликите в изпълнението и описанието на подробни команди и файлови формати. Администраторът работи само с типа обект, Puppet се грижи за останалото. По този начин типът пакети познава около 17 пакетни системи; необходимата ще бъде автоматично разпозната въз основа на информация за версията на дистрибуцията или системата, въпреки че, ако е необходимо, мениджърът на пакети може да бъде принуден.

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

Куклен език

За да продължите напред, първо трябва да разберете основните елементи и възможности на езика. Езикът е една от силните страни на Puppet. С негова помощ се описват ресурсите, които администраторът планира да управлява и действията. За разлика от повечето подобни решения, Puppet позволява на езика да опрости достъпа до всички подобни ресурси на всяка система в хетерогенна среда. Описанието на ресурса обикновено се състои от име, тип и атрибути. Например, нека посочим файла /etc/passwd и зададем неговите атрибути:

файл ("/etc/passwd":

собственик => root,

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

Сега клиентите, след като се свържат със сървъра, ще копират файла /etc/passwd и ще инсталират посочените атрибути. Можете да дефинирате множество ресурси в едно правило, като ги разделяте с точка и запетая. Какво да направите, ако конфигурационният файл, използван на сървъра, се различава от клиентския или изобщо не се използва? Например, тази ситуация може да възникне при настройка VPN връзки. В този случай файлът може да се посочи с помощта на директивата източник. Тук има две опции, както обикновено, за указване на пътя към друг файл; два URI протокола също се поддържат: файл и марионетка. В първия случай се използва връзка към външен NFS сървър, във втория вариант на Puppet сървъра се стартира NFS-подобна услуга, която експортира ресурси. В последния случай пътят по подразбиране е относителен към главната директория на марионетката - /etc/puppet. Тоест връзката puppet://server.domain.com/config/sshd_config ще съответства на файла /etc/puppet/config/sshd_config. Можете да замените тази директория с помощта на директивата filebucket, въпреки че е по-правилно да използвате раздела със същото име във файла /etc/puppet/fileserver.conf. В този случай можете да ограничите достъпа до услугата само от определени адреси. Например, нека опишем раздела за конфигурация.

път /var/puppet/config

разреши *.domain.com

позволи 192.168.0.*

позволи 192.168.1.0/24

откажи *.wireless.domain.com

И тогава се обръщаме към този раздел, когато описваме ресурса.

източник => "кукла //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":

източник => “кукла // кукла://сървър.домейн.com/config/apache/conf.d”,

рекурсия => "вярно"

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

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

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

клас freebsd наследява linux (

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

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

За удобство всички класове могат да бъдат поставени в отделен файл, който да се свърже чрез директивата include. Дефинициите могат да приемат множество параметри като аргументи, но не поддържат наследяване и се използват, когато трябва да опишете повторно използвани обекти. Например, нека дефинираме домашната директория на потребителите и командите, необходими за създаване на нов акаунт.

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

потребител ("$name":

гарантирам => представям,

коментар => "$пълно име",

gid => "$group",

групи => $ingroups,

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

shell => "/bin/bash",

home => "/home/$name",

изисквам => Група[$group],

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 сървъра, съответният раздел на възела ще бъде претърсен и ще бъдат предоставени настройки, специфични само за този компютър. За да опишете всички други системи, можете да използвате подразбиране на възел. Описанието на всички типове е дадено в документа „Справочник на типове“, който трябва да се прочете във всеки случай, поне за да се разберат всички възможности на езика Puppet. Различни типове ви позволяват да изпълнявате определени команди, включително когато са изпълнени определени условия (например промяна на конфигурационен файл), работа с cron, потребителски идентификационни данни и групи, компютри, ресурси за монтиране, стартиране и спиране на услуги, инсталиране, актуализиране и премахване на пакети , работа с SSH ключове, Solaris зони и др. Ето колко лесно е да накарате списъка с пакети в дистрибуции, използващи apt, да се актуализира всеки ден между 2 и 4 часа.

график (ежедневно:

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

диапазон =>

exec("/usr/bin/apt-get актуализация":

график => ежедневно

Инсталиране на Puppet

Puppet изисква Ruby (>= 1.8.1) с поддръжка на OpenSSL и XMLRPC библиотеки, както и библиотеката Faster [ http://reductivelabs.com/projects/facter]. Хранилището на Ubuntu 7.04, което беше използвано за тестовата инсталация, вече включваше пакета puppy.

$ sudo apt-cache марионетка за търсене

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

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

По време на инсталацията ще бъдат инсталирани всички необходими пакети за зависимости: facter libopenssl-ruby libxmlrpc-ruby.

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

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

$ ruby -ropenssl -e "puts:yep"

~$ ruby -rxmlrpc/клиент -e "puts:yep"

Ако не се получат грешки, значи всичко, от което се нуждаете, вече е включено. Файловете, които описват желаната конфигурация на системите, се наричат манифести в терминологията на Puppet. Когато се стартира, демонът се опитва да прочете файла /etc/puppet/manifests/site.pp; ако той липсва, показва предупредително съобщение. Когато тествате, можете да кажете на демона да работи в офлайн режим, в който случай манифестът не е необходим

$ sudo /usr/bin/puppetmasterd --nonodes

файл ("/etc/sudoers":

собственик => root,

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

Всички конфигурационни файлове за сървъра и клиентите се намират в /etc/puppet. Файлът fileserver.conf, за който говорихме по-горе, не е задължителен и се използва само ако Puppet ще работи и като файлов сървър. В Ubuntu този файл експортира поддиректорията /etc/puppet/files. Поддиректорията ssl съдържа сертификати и ключове, които ще се използват за криптиране при свързване на клиенти. Ключовете се създават автоматично при първото стартиране на puppetmasterd; можете да ги създадете ръчно с командата.

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

Файловете puppetd.conf и puppetmasterd.conf са подобни. Те посочват някои параметри за работата на демоните на клиентската система и сървъра. Клиентският файл се различава само по наличието на сървърния параметър, който сочи към компютъра, на който работи puppetmasterd.

сървър = grinder.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 | grep кукла

марионетка 5779 0,0 1,4 27764 15404 ? Ssl 21:49 0:00 ruby /usr/sbin/puppetmasterd

Защитната стена трябва да позволява връзки на порт 8140.

На сървъра получаваме списък със сертификати, които трябва да бъдат подписани.

$ sudo марионетка --списък

nomad.grinder.com

И подписваме клиентския сертификат.

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

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

За съжаление, просто не е възможно да се покажат всички възможности на Puppet в статията. Но както можете да видите, това е функционален и гъвкав инструмент, който ви позволява да решите повечето от проблемите на едновременното администриране на голям брой системи. Ако работата ви изисква да настроите няколко системи. И най-важното, проектът успя да събере малка, но постоянно нарастваща общност. Затова да се надяваме, че една добра идея няма да бъде оставена да умре или да замине.

Когато броят на сървърите, които управлявате, е по-малък от десет, рядко някой се замисля за тяхното централизирано управление, това може да не е необходимо. Когато има десетки сървъри, централизираното управление на софтуера и конфигурацията е изключително полезно. Когато има стотици и хиляди сървъри, това е жизненоважно. Има много програми от този вид, например: Chef, CFEngine, Puppet... Последното ще бъде обсъдено в тази публикация.

Куклата заслужено се счита за една от най-добрите решениятака. Използва се от компании като Google, Citrix и Red Hat. Това е клиент-сървър приложение, написано на езика за програмиране Ruby, което се разпространява в две версии:

Puppet Open Source – напълно безплатна версия
Puppet Enterprise - безплатно за до 10 сървъра, след което са необходими лицензи

Нека помислим за инсталирането на Puppet Open Source сървър и агент, които са включени в пакетите на повечето съвременни дистрибуции. След това ще говорим за Ubuntu 12.04 Precise Pangolin.

Задната част на Puppet се нарича кукловод, нека започнем инсталацията от там:

:~# apt-get инсталира Puppetmaster

И сега клиентът:

:~# apt-get инсталиране марионетка

В конфигурационния файл на клиента /etc/puppet/puppet.confтрябва да говорите за сървъра, като добавите следния раздел:

Server=puppet.local report=true pluginsync=false

В началния етап е по-добре да изключите pluginsync.

Нека стартираме марионетния клиент, така че да създаде заявка за сертификат:

:~# puppetd --verbose --test info: Създаване на нов SSL ключ за linux.local info: Кеширане на сертификат за ca info: Създаване на нова заявка за SSL сертификат за linux.local info: Отпечатък на заявка за сертификат (md5): E5: EA:AC:5B:22:9A:BA:42:B8:A1:63:9E:1F:1F:23:51 Излизане; не е намерен сертификат и waitforcert е деактивиран

На сървъра трябва да проверите дали заявката за сертификат е получена и ако е така, издайте сертификат:

:~# марионетка --списък "linux.local" (E5:EA:AC:5B:22:9A:BA:42:B8:A1:63:9E:1F:1F:23:51) :~# марионетка - -sign linux.local note: Подписано искане за сертификат за linux.local известие: Премахване на файл Puppet::SSL::CertificateRequest linux.local в "/var/lib/puppet/ssl/ca/requests/linux.local.pem"

Повторете предишната стъпка на клиента:

:~# puppetd --verbose --test информация: Кеширане на сертификат за linux.local информация: Извличане на информация за плъгин: Кеширане на certificate_revocation_list за ca информация: Кеширане на каталог за linux.local информация: Прилагане на конфигурационна версия "1356278451" информация: Създаване на файл със състояние / var/lib/puppet/state/state.yaml забележка: Завършено изпълнение на каталога за 0,02 секунди

Страхотно, всичко работи. Нека да преминем към създаването на първия манифест. Манифестите или конфигурациите се описват на специален декларативен език. Веднага ще свикнем с хубавите неща, ще използваме модулна структура и класове. Например, нека напишем модул, който ще поддържа файла актуален /etc/hostsна всички наши сървъри.

Нека проверим къде марионетката търси модули:

:~# прилагане на марионетка --configprint modulepath /etc/puppet/modules:/usr/share/puppet/modules

Създайте директории за вашия модул

:~# cd /etc/puppet/modules :~# mkdir хостове; cd хостове; mkdir манифести; cd манифести

Трябва да се извика първият манифест, известен също като файл на главния модул init.pp

Хостове на клас ( # puppet.local хост ( "puppet.local": secure => "present", target => "/etc/hosts", ip => "192.168.0.1", host_aliases => "puppet", ) # linux.local хост ("linux.local": secure => "present", target => "/etc/hosts", ip => "192.168.0.2", host_aliases => "linux", ) )

По подразбиране Puppet търси файл /etc/puppet/manifests/site.ppза да заредим конфигурацията, нека я преведем в следната форма:

Възел по подразбиране (включва хостове)

Проверяваме манифеста на сървъра:

:~# puppet apply --verbose /etc/puppet/manifests/site.pp информация: Прилага се конфигурационна версия "1356281036" забележка: /Етап//Хост/осигуряване: създадена информация: FileBucket добавяне (md5)известие: /Етап// Хост/осигуряване: създадено известие: Изпълнението на каталога е завършено за 0,03 секунди

На клиента:

:~# ll /etc/hosts rw-r--r-- 1 root root 290 16 декември 19:10 /etc/hosts :~# puppetd --verbose --test информация: Кеширане на каталог за linux.local информация: Прилагане информация за версията на конфигурацията "1356283380": Бележка за добавяне на FileBucket (md5): /Stage/Hosts/Host/ensure: създадено известие: /Stage/Hosts/Host/ensure: създадено известие: Изпълнение на завършен каталог за 0,04 секунди:~# ll /etc /hosts -rw-r--r-- 1 root root 551 23 декември 20:43 /etc/hosts

След като сме сигурни, че всичко работи, разрешаваме услугата да стартира, в /etc/default/puppetпромяна:

# Стартиране на марионетка при зареждане? СТАРТ=да

Стартиране на услугата

:~# стартиране на марионетна услуга

Puppet ще анкетира сървъра на puppetmaster на всеки 30 минути за промени в конфигурацията и, ако е необходимо, ще коригира системата съответно.

Куклен?

Инсталация

Език за описание на държавата

Популярни видове ресурси за Puppet

Файлов сървър

заключения

Информация

Връзки

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

Куклен език

Инсталиране на Puppet