Когато броят на сървърите, които управлявате, е по-малък от десет, рядко някой се замисля за тяхното централизирано управление, това може да не е необходимо. Когато има десетки сървъри - централизирано управлениеСофтуерът и конфигурациите са изключително полезни. Когато има стотици и хиляди сървъри, това е жизненоважно. Има много програми от този вид, например: Chef, CFEngine, ... Последното ще бъде обсъдено в тази публикация.
Куклата заслужено се счита за една от най-добрите решениятака. Използва се от компании като Google, Citrix и червена шапка. Това е само по себе си клиент-сървър приложениенаписан на езика за програмиране Ruby, който се разпространява в две версии:
- Куклен Отворен код- напълно безплатна версия
- Puppet Enterprise - безплатно за до 10 сървъра, след което са необходими лицензи
Нека помислим за инсталирането на Puppet Open Source сървър и агент, които са включени в пакетите на повечето съвременни дистрибуции. След това ще говорим за Ubuntu 12.04 Precise Pangolin.
Сървърна частКукла се нарича кукловод, нека започнем инсталацията от там:
:~# 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 известие: Подписано искане за сертификат за известие 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 host ( "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 минути за промени в конфигурацията и, ако е необходимо, ще коригира системата съответно.
Говорихме за това какво е управление на конфигурацията и как да внедрите тази технология във вашата инфраструктура.
Забележка: Този урок е направен на Ubuntu 14.04 и Apache.
Този урок ще ви помогне да подготвите автоматизирана оркестрация на сървъра с помощта на инструмента за управление на конфигурацията Puppet. Ще се запознаете с основните термини, синтаксис и функции на Puppet. В резултат на това ще получите напълно автоматизирано, просто внедряване, което се състои от следните стъпки:
- Актуализирайте индекса на пакета.
- Инсталиране на Apache.
- Създайте персонализирана основна директория на документ.
- Създаване на файл index.html в него.
- Прилагане на шаблон за задаване на персонализиран виртуален хост.
- Рестартиране на Apache.
Забележка: Този урок се фокусира върху създаването на манифести - марионетни скриптове за автоматизиране на конфигурацията. Можете да прочетете повече за Puppet в статиите:
Начало на работа
Преди да започнете да разработвате своя манифест, трябва да сте запознати с някои основни термини на Puppet.
Куклена терминология
- Puppet Master: Главният сървър, който управлява конфигурацията на възлите.
- Puppet Agent: Подчинен възел, който докладва на главния.
- Манифест: сценарий за оркестрация.
- Ресурс: Част от код, който дефинира промените, необходими на системата.
- Модул: Група от манифести и други файлове, организирани по предварително определен начин, който улеснява споделянето и повторно използванеотделните му части от оркестрацията.
- Клас: Както във всеки нормален език за програмиране, класовете са отговорни за организирането и повторното използване на части от оркестрацията.
- Факти: глобални системни променливи.
- Услуги: промяна на статуса на услуга (стартиране, спиране и др.).
Куклената оркестрация е разработена на DSL език, който е базиран на Ruby.
Ресурси
Puppet определя задачите, използвайки ресурси. Ресурсите могат да представляват пакети, файлове, услуги, потребители и команди. Те могат да имат състояние, което ще накара системата да се промени, ако състоянието на декларирания ресурс се различава от сегашно състояниесистеми. Например ресурс на пакет с инсталирано състояние в манифеста ще започне да инсталира пакета, ако пакетът не е бил инсталиран преди това. Такъв ресурс изглежда така:
пакет ("apache2":
осигурете => "инсталиран"
Ресурсът exec ви позволява да изпълните всяка команда:
exec("apt-get update":
команда => '/usr/bin/apt-get актуализация'
Имайте предвид, че apt-get update в примера по-горе не е декларация на команда, а идентификатор на ресурс. Често в Puppet трябва да препращате към други ресурси и това става с помощта на техните идентификатори.
Зависимост от ресурси
Когато пишете манифести, е важно да запомните, че Puppet не използва ресурси в реда, в който са дефинирани. Ресурсите трябва ясно да определят зависимостта си един от друг, в в противен случайневъзможно е да се разбере в какъв ред ще бъдат прочетени и изпълнени ресурсите или дали изобщо ще бъдат изпълнени.
Пример е следният код; той дефинира зависимостта на ресурса и след това самия ресурс:
package("python-software-properties":
осигурете => "инсталиран"
}
exec("добавяне на хранилище":
команда => "/usr/bin/add-apt-repository ppa:ondrej/php5 -y"
изискват => Пакет["python-software-properties"]
Опцията за изискване приема препратка към друг ресурс като параметър. IN в такъв случайРесурсът Package се определя от пакета python-software-properties.
Забележка: Декларациите за ресурси започват с малка буква (exec, пакет), а зависимостите започват с главна буква (Exec, Package).
Например, трябва да сте сигурни, че една задача е изпълнена преди втората. За това се използва опцията преди.
package("curl":
осигурете => "инсталиран"
преди => Exec["инсталационен скрипт"]
exec("инсталационен скрипт":
команда => "/usr/bin/curl http://example.com/some-script.sh"
Формат на манифеста
Манифестите са колекции от ресурси с разширение .pp. По-долу е даден пример за прост манифест, който прави две неща: актуализира индекса на пакета и инсталира vim.
exec("apt-get update":
команда => "/usr/bin/apt-get актуализация"
}
пакет ("vim":
осигурете => "инсталиран"
изискват => Exec["apt-get update"]
Забележка: В края на това ръководство ще намерите пълен кодКуклен манифест.
Писане на манифест
Променливи
Променливите могат да бъдат дефинирани навсякъде в манифеста. Най-често срещаните типове променливи са низове и масиви от низове, но Puppet поддържа и други типове.
Този код дефинира променлив низ, който по-късно може да се използва в манифеста:
$package = "vim"
пакет ( $package:
осигурете => "инсталиран"
Цикли
Циклите обикновено се използват за повторение на задача, като се използват различни входни стойности. Тоест, вместо да създавате 10 задачи за инсталиране на 10 различни пакета, можете да създадете една задача и да използвате цикъл, за да повторите задачата, за да инсталирате всички пакети.
Най-лесният начин да дефинирате цикъл в Puppet е с масив, като този:
$packages = ["vim", "git", "curl"]
пакет ( $packages:
осигурете => "инсталиран"
От версия 4 Puppet поддържа допълнителни пътекиза сортиране на задачи. Кодът по-долу прави същото като предишния код, но този път използва итератора на each. Тази опция улеснява създаването на ресурсни цикли:
$packages.each |Низ $package| (
пакет ( $package:
осигурете => "инсталиран"
Използване на условни изрази
Условните изрази могат да се използват за динамично конфигуриране (например, когато трябва да решите дали да изпълните задача въз основа на променлива или резултат от команда).
Puppet поддържа повечето условни структуритрадиционни езици за програмиране (например оператори if/else и case); В допълнение, някои ресурси (като exec) поддържат атрибути, които действат като условни изрази, но приемат изхода на команда само като условие.
Да приемем, че искате да изпълните команда въз основа на факт. В такъв случай, за да проверите стойността на променлива, трябва да използвате една от поддържаните условни структури, като if/else:
if $osfamily != "Debian" (
предупреждение („Този манифест не се поддържа от тази операционна система.“)
notify("Добре!":)
Условните изрази също често се използват в ИТ автоматизацията, когато изпълнението на една команда зависи от изхода на друга команда. В такива случаи, само ако или освен ако не се използва, както е показано в примера по-долу. Следната команда ще бъде изпълнена само ако /bin/which php изходът е успешен:
команда => "/bin/echo PHP е инсталиран тук > /tmp/test.txt",
onlyif => "/bin/which php"
По същия начин операторът unless ще изпълни командата само ако командата в unless не е била изпълнена.
команда => "/bin/echo PHP НЕ е инсталиран тук > /tmp/test.txt",
освен ако => "/bin/кой php"
Използване на шаблони
Шаблоните обикновено се използват в конфигурационните файлове и ви позволяват да добавяте променливи и други функции, които правят файловете по-гъвкави и многократно използвани. Puppet поддържа два шаблонни формата
- Вграден Puppet (EPP): Работи само с Puppet 4+.
- Вграден Ruby (ERB)
По-долу е примерен ERB шаблон за създаване на виртуален хост Apache, който използва променлива за създаване главна директориятози хост:
ServerAdmin webmaster@localhost
DocumentRoot<%= @doc_root %>
AllowOverride All
Изисквайте всички предоставени
За да приложите шаблон, трябва да създадете файлов ресурс, който показва съдържанието на шаблона, като използвате метода на шаблона. За да замените виртуалния хост на Apache по подразбиране, използвайте този шаблон:
осигурете => "настояще",
съдържание => шаблон ("apache/vhost.erb")
В този случай Puppet ще търси шаблона vhost.tpl в директорията apache/templates.
Дефиниране на услуги
Ресурсите на услугата променят състоянието си системна услуга(например спиране или рестартиране).
Нека разгледаме предишния примерен шаблон, който е предназначен за създаване на виртуален хост Apache. За да сте сигурни, че Apache ще се рестартира след промяна на виртуалния хост, трябва да създадете сервизен ресурс. Това се прави така:
услуга ("apache2":
гарантирам => работи,
активиране => вярно
За да идентифицирате ресурс, използвайте опцията за уведомяване.
файл ("/etc/apache2/sites-available/000-default.conf":
осигурете => "настояще",
съдържание => шаблон ("vhost.erb"),
уведомяване => Услуга["apache2"]
Примерен манифест
Сега можете да компилирате целия код в този урок в един манифест, който ще автоматизира инсталирането на Apache на Ubuntu 14.04.
Забележка: Актуализирана версия на манифеста може да бъде намерена в Github. Тази папка също съдържа Vagrant файл, който ви позволява да тествате манифеста при опростена инсталация с помощта на виртуална машинаСкитник.
$doc_root = "/var/www/example"
exec("apt-get update":
команда => "/usr/bin/apt-get актуализация"
}
пакет ("apache2":
осигурете => "инсталиран",
изискват => Exec["apt-get update"]
}
файл ($doc_root:
осигурете => "директория",
собственик => "www-данни",
група => "www-данни",
режим => 644
}
файл ("$doc_root/index.html":
осигурете => "настояще",
източник => "кукла ///модули/главен/индекс.html",
изисквам => Файл[$doc_root]
}
файл ("/etc/apache2/sites-available/000-default.conf":
осигурете => "настояще",
съдържание => шаблон ("main/vhost.erb"),
notify => услуга ["apache2"],
изисквам => Пакет["apache2"]
}
услуга ("apache2":
гарантирам => работи,
активиране => вярно
- Първият ред съдържа променливата $doc_root, която по-късно се използва за деклариране на ресурса.
- Редове 3-5: Ресурсът exec изпълнява командата apt-get update.
- Редове 7-10: Ресурсът на пакета инсталира пакета apache2, зависи от apt-get update. Тоест този ресурс ще бъде изпълнен само ако необходимият ресурс е изпълнен.
- Редове 12-17: Файловият ресурс създава нова основна директория. Файловият ресурс може да създава файлове и директории, да прилага шаблони и да копира локални файлове отдалечен сървър. Тази задача може да се изпълни на всеки етап от оркестрацията, така че не изисква зависимости.
- Редове 19-23: Друг файлов ресурс копира файла index.html в основната директория на сървъра. Параметърът източник позволява на Puppet да намери изходния файл. Този код се основава на метода на обработка локални файловев Puppet. Можете да намерите структура на директория в хранилището на Github, която ще позволи на Puppet да намери този ресурс. Основната директория трябва да бъде създадена преди изпълнението на този ресурс, така че тук се използва опцията за изискване.
- Редове 25-30: Този файлов ресурс прилага шаблона на Apache и рестартира услугата. IN в този примероркестрацията се организира с помощта на основния модул (следователно първоначалният шаблон ще бъде main/vhost.erb). Опцията за изискване гарантира, че ресурсът ще бъде изпълнен само ако пакетът apache2 е инсталиран.
- Редове 32-35: Ресурсът на услугата рестартира услугата apache2.
Заключение
Puppet е мощен инструмент за управление на конфигурацията, който използва DSL за управление на сървърни ресурси и автоматизиране на задачи. Този език предлага допълнителни ресурси, които осигуряват гъвкавост на оркестрацията.
Когато работите с Puppet, е важно да запомните, че ресурсите не винаги се четат и изпълняват в същия ред, в който са дефинирани. Бъдете много внимателни, когато създавате веригата за изпълнение.
Етикети: ,Куклене междуплатформена рамка, която позволява на системните администратори да изпълняват общи задачи с помощта на код. Кодът ви позволява да направите различни задачиот инсталиране на нови програми до проверка на разрешения за файлове или актуализиране на потребителски акаунти. Кукленотлично не само по време на първоначалната инсталация на системата, но и през цялото време жизнен цикълсистеми. В повечето случаи Кукленизползвани в конфигурацията клиент/сървър.
Този раздел показва инсталация и конфигурация Кукленв конфигурация клиент/сървър. Този прост пример показва как да инсталирате Apacheизползвайки Куклен.
Инсталация
За монтаж Кукленвъведете в терминала:
Sudo apt-get инсталирайте puppetmaster
На клиентската машина(и) въведете:
Sudo apt-get инсталира марионетка
Настройки
Преди да настроите марионетка, може да искате да добавите запис DNS CNAMEЗа кукла.example.com, Където example.com- това е вашият домейн. Клиенти по подразбиране Кукленпроверете DNS за puppet.example.com като име на сървър за марионетки ( Кукловод). Вижте услугата за име на домейн за допълнителни подробности относно използването на DNS.
Ако не възнамерявате да използвате DNS, можете да добавите записи към файла /etc/hosts на сървъра и клиента. Например във файла /etc/hosts Куклендобавяне на сървър:
127.0.0.1 localhost.localdomain localhost марионетка 192.168.1.17 meercat02.example.com meercat02
На всеки КукленВ клиента добавете запис за сървъра:
192.168.1.16 meercat.example.com meercat марионетка
Заменете IP адресите и имената на домейни от примера с вашите действителни сървърни и клиентски адреси и имена.
Сега нека настроим някои ресурси за apache2. Създайте файл /etc/puppet/manifests/site.ppсъдържащ следното:
Пакет ( "apache2": гарантиране => инсталирано) услуга ( "apache2": осигуряване => вярно, активиране => вярно, изискване => Пакет["apache2"] )
Възел "meercat02.example.com" (включете apache2)
Сменете meercat02.example.comна сегашното си име Кукленклиент.
Последната стъпка за това просто Кукленсървърът трябва да рестартира услугата:
Sudo /etc/init.d/puppetmaster рестартирайте
Сега на Кукленвсичко е конфигурирано на сървъра и е време да конфигурирате клиента.
Първо, нека конфигурираме услугата Кукленагент за стартиране. Редактирайте /etc/default/puppet, като замените стойността СТАРТНа да:
Sudo /etc/init.d/puppet start
Да се върнем към Кукленсървър за подписване на клиентския сертификат с помощта на командата:
Sudo puppetca --sign meercat02.example.com
Проверете /var/log/syslogза евентуални грешки в конфигурацията. Ако всичко е минало добре, пакетът apache2и неговите зависимости ще бъдат инсталирани на Кукленклиент.
Този пример е много прост и не показва много от функциите и предимствата. Куклен. За Допълнителна информациявиж
Автор: Люк Каниес
Дата на публикуване: 2 май 2012 г
Превод: А. Панин
Дата на превод: 27 август 2013 г
18.1. Въведение
Puppet е инструмент за управление на ИТ инфраструктура, разработен с помощта на езика за програмиране Ruby и използван за автоматизиране на поддръжката на центрове за данни и управление на сървъри Google компании, Twitter, Нюйоркската фондова борса и много други организации. Развитието на проекта се подпомага основно от организацията Puppet Labs, която постави основите за неговото развитие. Puppet може да управлява от 2 до 50 000 сървъра и да се поддържа от екип от един или стотици системни администратори.
Puppet е инструмент, предназначен да настройва и поддържа вашите компютри; Използвайки неговия прост език за конфигуриране, можете да кажете на Puppet как искате да бъдат конфигурирани вашите машини и той ще ги преконфигурира, ако е необходимо, за да отговарят на вашите спецификации. Докато променяте тази спецификация с течение на времето поради обстоятелства като актуализации на пакети, добавяне на нови потребители или актуализации на конфигурация, Puppet автоматично ще актуализира конфигурацията на вашите машини, за да съответства на спецификацията. В случай, че вече са конфигурирани правилно, Puppet няма да свърши никаква работа.
Като цяло Puppet изпълнява всички възможни действия, насочени към използване на функции съществуваща системада си вършиш работата; т.е. в дистрибуции, базирани на технологии RedHat, той ще използва помощната програма yum за управление на пакети и init.d за управление на услуги, докато в операционната система OS X ще използва помощна програма dmgза управление на пакети и launchd за управление на услуги. Една от основните цели на проекта Puppet е да изпълнява полезна работанезависимо дали кодът на проекта Puppet или самата система се използва за това, така че следното системни стандартиса критични.
Проектът Puppet е изграден на базата на опит с много други инструменти. В свят на приложения с отворен код програмен коднай-голямо влияние върху неговото развитие имаше проектът CFEngine, който беше първият инструмент за конфигуриране с общо предназначениеотворен код, както и проектът ISconf, който използва помощната програма make, за да свърши цялата работа, което от своя страна предизвика Специално вниманиекъм изрично описани зависимости в системата. В света на търговския софтуер, Puppet може да се разглежда като конкурент на проектите BladeLogic и Opsware (които по-късно бяха придобити от повече от големи компании), всеки от които се продаваше успешно, когато беше представен Puppet, но всеки от тези инструменти беше продаден на ръководители на големи компании, вместо да бъде разработен в съответствие с непосредствените изисквания за качествени инструменти за системни администратори. Целта на проекта Puppet беше да решава проблеми, подобни на тези, решавани от тези инструменти, докато беше предназначен за напълно различни потребители.
Като прост примерметод за използване на Puppet, ето част от кода, за да се уверите, че услугата Secure Shell (SSH) е инсталирана и конфигурирана правилно: клас ssh ( пакет ( ssh: secure => инсталиран ) файл ( "/etc/ssh/sshd_config": източник = > "puppet:///modules/ssh/sshd_config", уверете се => присъства, изисква => Пакет ) услуга ( sshd: уверете се => работи, изисква => , Пакет] ))
Този код ви позволява да сте сигурни, че пакетът ще бъде инсталиран, файлът ще бъде поставен на необходимото място и услугата ще бъде стартирана. Трябва да се отбележи, че сме описали зависимостите между ресурсите, така че винаги ще извършваме всяка работа в правилната последователност. Този клас може да бъде свързан с всеки възел, за да приложи дадена конфигурация в рамките на този възел. Моля, имайте предвид, че изграждащи блокове Кукленски конфигурацииса структурирани обекти, в този случай обектите пакет, файл и услуга. В терминологията на Puppet ние наричаме тези обекти ресурси ( ресурси) и всички спецификации за конфигурация на Puppet се състоят от тези ресурси и зависимостите между тях.
Една нормална Puppet инсталация ще съдържа десетки или дори стотици от тези части от код, които наричаме класове ( класове); Ние съхраняваме тези класове на диск във файлове, наречени манифести, и също така групираме логически свързани класове заедно в групи, наречени модули ( модули). Например, може да имате ssh модул с този ssh клас и всякакви други логически свързани класове, заедно с модулите mysql, apache и sudo.
Повечето взаимодействия с Puppet се извършват с помощта на черупкаили винаги работещи HTTP услуги, но има и такива графични интерфейсиза изпълнение на задачи като обработка на отчети. Puppet Labs предоставя и реклама софтуерни продуктиза работа с Puppet, който използва уеб GUI.
Първият прототип на Puppet е разработен през лятото на 2004 г., а пълното развитие на проекта започва през февруари 2005 г. Първоначално е проектиран и разработен от Luke Kanies, системен администратор с богат опит в разработването на малки инструменти, но без опит в разработването на проекти, съдържащи повече от 10 000 реда код. По същество Люк Каниес научи умения за програмиране по време на разработването на проекта Puppet, което повлия на архитектурата на проекта както положително, така и отрицателно.
Puppet е разработен първоначално и предимно като инструмент за системни администратори, който да улесни живота им, позволявайки им да вършат работата си по-бързо, по-ефективно и с по-малко грешки. Първата ключова иновация за прилагане на този принцип бяха ресурсите, описани по-горе, които са примитиви Puppet; те могат да се прехвърлят между операционни системи, като същевременно представят детайлите на изпълнението абстрактно, което позволява на потребителя да мисли за резултатите от работата, а не как да ги постигне. Този набор от примитиви е внедрен в слоя за абстракция на ресурси на Puppet.
Ресурсите за кукли трябва да са уникални за даден възел. Можете да имате само един пакет с име "ssh", една услуга с име "sshd" и един файл с име "/etc/ssh/sshd_config". Това ограничение предотвратява взаимни конфликти между различни части на вашите конфигурации и вие осъзнавате тези конфликти в началото на процеса на конфигуриране. Ние наричаме тези ресурси по техните типове и имена, т.е. пакет и услуга. Можете да използвате пакет и услуга с едно и също име, тъй като те са свързани с различни видове, но не и два пакета или услуги с едно и също име.
Втората ключова иновация в Puppet е способността директни инструкциизависимости между ресурсите. Използвани преди това инструменти, насочени към изпълнение на отделни задачи, без да се вземат предвид връзките между тези задачи; Puppet беше първият инструмент, който изрично заявява, че зависимостите са основна част от вашите конфигурации, които от своя страна трябва да бъдат моделирани по съответния начин. Той създаде графика на ресурсите и техните зависимости като един от основните типове данни и почти всички действия на Puppet зависят от тази графика (наречена каталог), нейните върхове и ръбове.
Последно важен компонент Puppet е език за конфигурация. Този език е декларативен и е предназначен повече за описание на конфигурацията, отколкото за пълноценно програмиране - той почти напълно повтаря конфигурационния формат на Nagios, но също така е създаден под значително влияние на езиците от CFEngine и Ruby.
В основата функционални компоненти Puppet има два принципа, ръководещи развитието си: трябва да бъде възможно най-лесен за използване, с предпочитание към използваемостта пред функциите; и също така трябва да се разработи първо под формата на рамка и второ - приложение, по този начин, ако желаете разработчици на трети странище могат да създават своите приложения, базирани на софтуерни компоненти Puppet. Беше ясно, че в допълнение към рамката е необходимо и широко използвано, висококачествено приложение, но първият приоритет на разработчиците все още беше рамката, а не приложението. Много хора все още вярват, че Puppet е самото приложение, а не рамката, върху която е внедрено.
След като изгради първия си прототип на Puppet, Люк стана като цяло добър разработчик на Perl с известен опит в скриптирането на shell и известен C опит, придобит най-вече от работата със системата CFEngine. В допълнение, той имаше опит в изграждането на системи за синтактичен анализ за прости езици, като е разработил две такива системи, които да работят с малки инструменти, и повторно разработване на системата за синтактичен анализ на CFEngine от нулата, за да я направи по-лесна за поддръжка (този код не е прехвърлен към проекта поради незначителни несъвместимости).
Решението да се използва динамичен език за внедряване на Puppet беше взето доста бързо поради значително по-високата производителност на разработчиците и разпространението от този типезици, но самият избор се оказа доста труден. Първоначалните прототипи в Perl бяха отхвърлени, така че бяха проведени експерименти за намиране на други езици. Направен е опит за използване Език Python, но Лука смята този език за значително противоречащ на неговия възглед за света. След като чу приятел да говори за предимствата на новия език, Люк опита да използва Ruby и създаде работещ прототип за четири часа. Когато започна пълномащабното разработване на Puppet, езикът Ruby беше практически непознат, така че решението да се използва беше голям риск, но в този случай продуктивността на разработчиците отново изигра решаваща роля при избора на език. У дома отличителна черта Ruby език, от понеот Perl беше лесно да се създадат нейерархични класови връзки, докато езикът не противоречи на умствената дейност на разработчика Luke, което беше критично.
Представете си себе си в ролята на системен администратор, отговорен за поддържането на функционалността на стотици машини, работещи с операционни системи тип UNIX. Всяка изисква конфигурация и периодично актуализиране и наблюдение, но се очаква много да изпълняват подобни функции. Две трети са работни станции, още няколко са рутери, останалите са няколко уеб сървъра и хранилища за данни. Въпрос: как да управлявате целия този бизнес?
Най-простият отговор е просто да се свържете с всеки от тях чрез SSH и да влезете необходими промени. Този метод обаче има два проблема. Първо, това е много трудоемко. Второ, администраторът постоянно ще трябва да извършва много монотонни действия (например, за да актуализирате OpenOffice.org на всички работни станции, ще трябва да изпълнявате едни и същи команди няколко десетки пъти). Можете да опитате да избегнете този проблем, като напишете няколко скрипта, които сами ще се свързват към всяка машина и ще изпълняват предварително написани команди. Но и тук ни чакат проблеми. Скриптовете ще трябва постоянно да се модифицират, за да отговарят на всяка задача, скриптовете ще трябва да вземат предвид разликите в операционните системи и версиите и ще трябва да бъдат отстранявани грешки за дълго време, преди да бъдат приложени към работещи машини. Като цяло не е камийо.
Правилният отговор е да се използват така наречените системи дистанционноконфигурации, най-известните представители на които са отворени системи Cfengine и Puppet. Такива системи поемат всички отговорности за привеждане на конфигурацията на машината правилния тип, като се изисква от администратора само описание на крайното състояние на системата на специален език(например описание на това какви пакети трябва да бъдат инсталирани в операционната система, към кои редове трябва да се добавят конфигурационни файлове, какви команди трябва да се изпълняват и т.н.). След това всички възли сами ще получат информация за необходимото състояние от сървъра и автоматично ще конфигурират системата. Благодарение на този механизъм новите машини могат да бъдат напълно конфигурирани без човешка намеса, а съществуващите могат да бъдат преконфигурирани чрез добавяне само на няколко реда към описанието на състоянието.
Куклен?
Puppet е разработен от Luke Kanies, който се уморява от ограниченията на Cfengine и решава да създаде по-добра версия от нулата. Ако вече сте използвали Cfenfine, вероятно ще намерите Puppet за по-удобна и мощна система. Държавният език на Puppet е по-високо ниво и гъвкав, така че администраторите не трябва да се притесняват за неща като писане на отделни правила за всеки тип ОС или Подробно описаниеизвършване на тривиални действия. Puppet ви позволява да се съсредоточите върху какво Каквотой иска да направи, вместо как да го направи (например, за да инсталирате определен пакет на някоя от операционните системи, поддържани от системата, е достатъчно да напишете буквално няколко реда, казвайки „Инсталирайте тази програма“, вместо да описвате командите, необходими за инсталирането му). Puppet е написан на прост език Ruby, което го прави лесен за персонализиране конкретна задачаи разширяване на функционалността (осигурена е гъвкава система за добавки). Освен това, за разлика от модела на разработка на Cfengine, който по същество се върти около един човек, Puppet има голяма общност от ентусиасти, които правят подобрения в кода, споделят примери за конфигурация и пишат документация.
Като цяло Puppet изглежда по-модерна и сложна система с добър дизайн. Подобно на Cfengine, той поддържа почти всички съвременни UNIX-подобни операционни системи (включително MacOS X) и може също да работи в среда Cygwin върху Windows. Неговият списък със зависимости включва само интерпретатора на Ruby и инструмента Factor, така че не би трябвало да има проблеми с инсталацията (честно казано, списъкът със зависимости на Cfengine е още по-кратък).
Файлов сървър
Много задачи отдалечено администриранене може да се реши без копиране на машини допълнителни файлове. Това могат да бъдат предварително подготвени конфигурации, уеб страници за Apache, пакети, които не са в официалното хранилище и много други. За да улесни процеса на прехвърляне на тези файлове към отдалечени възли, Puppet включва файлов сървър.
Настройки файлов сървърсе съхраняват във файла /etc/puppet/fileserver.conf. За да принудите Puppet да обслужва съдържанието на определена директория на клиенти, трябва да поставите няколко реда в нея:
Пътят = /var/puppet/files позволява *.server.com
Тези два реда показват, че директорията /var/puppet/files трябва да бъде достъпна за всички хостове в домейна server.com. Можем да посочим и пълното Име на домейнразрешената машина или нейния IP адрес, както и да отрежете нежеланите с помощта на директивата deny. След това всеки файл в тази директория може да бъде преместен на клиента с помощта на файловия ресурс. Например:
Файл ("/etc/httpd/conf/httpd.conf": източник => "кукла //httpd/httpd.conf", режим => 644, )
Файлът httpd.conf, намиращ се на сървъра в директорията /var/puppet/files/httpd, ще бъде копиран на целевата машина по пътя, указан в името на ресурса.
заключения
В тази статия разгледахме много малка част от възможностите на Puppet. Всъщност е много сложна система, които могат да бъдат описани напълно само на страниците на книга. В същото време Puppet е много лесен за конфигуриране и поддръжка, особено след като можете да намерите много примери за неговата конфигурация в Интернет.
