Централизирано управление на конфигурацията Puppet Foreman

Тази статия ще обхване инсталирането и конфигурирането на пакета Puppet + Foreman за централизирано управление на конфигурацията.

За сървъра, на който ще бъде инсталиран пакетът Puppet + Foreman, ще се използва виртуална машина (1 CPU, 2 Gb RAM, 20 Gb HDD), като клиенти ще бъдат физически компютри, на които е инсталиран Ubuntu. Конфигурацията на моя виртуален сървър с горните характеристики ми позволява да обслужвам 500 клиента без проблеми (може и повече).

Инсталирането на Puppet е доста просто (всички следващи команди се изпълняват като root):

С тези команди изтегляме deb пакета от сайта за разработчици на марионетки и го инсталираме. Този пакет puppetlabs-release-trusty.deb, когато е инсталиран, създава файла /etc/apt/sources.list.d/puppetlabs.list, в който са регистрирани хранилищата за марионетки, и също импортира gpg ключа, който е подписал хранилището за марионетки. Ние не инсталираме самия Puppetmaster, той ще бъде инсталиран автоматично при инсталиране на Foreman.

Това завършва инсталирането на Puppet, нека продължим с инсталирането на уеб интерфейса на Foreman:

Тук добавихме файла /etc/apt/sources.list.d/foreman.list, в който въведохме хранилищата от Foreman, и също добавихме ключа от това хранилище. След като добавихме хранилището, актуализирахме списъка с пакети и инсталирахме foreman-installer - това е пакетът, който ви позволява да инсталирате Foreman.

След това трябва да настроим правилното име на компютъра. Регистрираме се в /etc/hosts и /etc/hostname

Рестартираме нашия сървър.

Стартирайте нашия инсталатор с командаforeman-installer -i.

Питаме се дали сме готови за инсталация, отговаряме с „y“, последвано от меню, в което можете да изберете допълнителни конфигурации на Foreman идопълнителни модули. Инсталираме стандартната конфигурация, така че избираме елемента „Запазване и стартиране“ и инсталацията започва (възможно е да инсталирате с командата foreman-installer без опцията -i, тогава ще имаме основна инсталация, -i означава интерактивен режим).

Отне ми около 5 минути за инсталиране, след инсталирането виждаме съобщение за успешна инсталация, това съобщение съдържа нашите параметри за достъп до Foreman.

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

Тук ще бъдат изброени нашите клиенти.

Така завършихме инсталирането на пакета Puppet + Foreman. Нека опитаме да добавим марионетен клиент и да видим какво се променя в уеб интерфейса.

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

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

# марионетен сертификат --списък --всички "zeppelin" (SHA256) 43:64:08:BF:DB:AF:7C:17:5B:DE:3C:CE:22:8B:40:6A:13:60:B7:F4:2C:38:B6:57:E5:FA:EA:CC:63:FB:87:EB + "sr v .co.com" (SHA256) 04:CB:EB:CF:B2:D1:09:3C:74:00:20:A9:87:24:4B:CE:40:CC:0A:73:1D:F6:E4:24:7D:34:6E:4E:6C:17:DF:61 (алтернативни имена: "DNS:куклен", "DNS:куклен .co.com", "DNS:srv.co.com")

Тук виждаме, че имаме 2 сертификата, единият не е подписан с името zeppelin, а другият е подписан (+) с името srv.co.com. Неподписаният сертификат е сертификатът от нашия новоинсталиран клиент.

Можете да използвате командатаpuppet cert --sign $client_nameза подписване на сертификат. Също така, за да подписваме сертификати, можем да използваме уеб интерфейса от Foreman, за това трябва да отидем в менюто "Инфраструктура" - "Капсули" -„Сертификати“ и тук можете да подпишете или изтриете сертификата.

# марионетен сертификат --списък --всички + "srv.co.com" (SHA256) 04:CB:EB:CF:B2:D1:09:3C:74:00:20:A9:87:24:4B:CE:40:CC:0A:73:1D:F6:E4:24:7D:34:6E:4E:6C:17:DF:61 ( алтернативни имена: "DNS:puppet", "DNS:puppet.co.com", "DNS:srv.co.com") + "zeppelin" (SHA256) 03:C6:FF:F9:4D:10:7C:7D:6C:32:A7:E8:0C:9F:DA:FB:DD:43:B6:E5:36:79:DD:E3:0 4 :41:D3:58:9F:6A:C4:8F

Отидете в менюто "Възли" - "Всички възли" - тук виждаме 2 сървъра (новият сървър може да не се появи веднага, но след известно време, за да се появи веднага, трябва да изпълните командатаpuppet agent -tна клиента след подписване на сертификата).

По подразбиране Foreman взема манифести от папката /etc/puppet/environments по-надолу в записа за среда. Сега ще добавим манифест към Foreman и ще се опитаме да го приложим към един от нашите клиенти. Създайте папкаmkdir -p /etc/puppet/environments/production/modules/vsftpd/manifests, пуснете файла init.pp в тази папка:

Сега, за да може нашия модул с манифеста да се появи във Foreman, трябва да отидете в менюто „Настройки“ – „Класове за кукли“ и да щракнете върху „Импортиране от srv.co.com“.

Маркирайте средата, от която се нуждаем, с птица и щракнете върху „Актуализиране“.

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

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

Натискаме бутона „Промяна“, стигаме до друга страница с настройките на посочения възел, след което щракваме върху втория раздел „Куклени класове“ и виждаме нашия клас „vsftpd“.

Избираме нашия клас (знак +), той се премества вляво от „Налични класове“ до „Включени класове“, потвърждаваме промените.

Това е всичко - нашият манифест е добавен за избрания сървър, остава да изчакаме, докато се приложи на клиента. Ако не искаме да чакаме, можем да отидем при клиента и да изпълним командатаpuppet agent -t, веднага след нейното изпълнение, манифестът ще бъде приложен към клиента и vsftpd ще бъде инсталиран на него (в нашия случай).

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

Hardcore conf в C++. Каним само професионалисти.

Чете сега

20 май 2011 г. в 14:43 ч

Ръководство на NSA за сигурна конфигурация на Linux сървър

Puppet, система за управление на конфигурацията. Част II

Puppet, система за управление на конфигурацията. Част I

Коментари 34

обслужва 500 клиенти без проблеми

С активен агент?

Защо се нуждаете от толкова често актуализиране на конфигурацията?

Не се шегувам, наистина ми е интересно.

Веднъж на половин час - разпределени ли са във времето или всички едновременно? Според мен това е една от основните опасни характеристики на използването на системи с независим агент. Например имаме база данни и няколко уеб сървъра. Най-простият вариант... Базата данни се актуализира с миграции, всичко това по интелигентен начин. Дори и с ръцете си, въпреки че вие също го искате автоматично. Но базата данни е актуализирана, но кодът на уеб сървърите ще бъде актуализиранxs в даден момент, но в рамките на половин час. Тоест всички тези 30минути, няма да знаем колко точно е последователна системата? И потребителите отиват и получават грешки или нещо нередно е записано в базата данни.

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

Съжалявам, но имам злоба към Puppet and Chef - мога да изброя много недостатъци :)

Имам обикновен Ubuntu 14.04 Desktop, управляван чрез Puppet и няма нужда да стартирам агента по-често или по някакъв начин да синхронизирам актуализации между машини. Агентите на тях стартират по различно време (тъй като всички компютри не се включват едновременно, а се включват на случаен принцип).

Интервалът от 30 минути ме устройва в случая, тъй като през Puppet основно инсталирам актуализации на ОС, инсталирам софтуер, проверявам работата на услугите, прокси настройките, инсталирам сертификати и т.н.(нищо, че не може да чака 30 минути).

Ако се направят промени на сървърите, тогава аз също все още нямам такива услуги (управлявани чрез Puppet), които да зависят една от друга. Когато се появят, мисля, че дотогава ще намеря решение.

Съгласен съм, за актуализиране на компютри, които са независими един от друг, решението може да е подходящо.

Това според мен е една от основните опасни характеристики на използването на системи с независим агент.

Мога ли да знам какво е вашето решение за този проблем?

Предпочитам да използвам push схема, при която има централен сървър, който познава цялата топология и може да взема решения относно реда, в който се изпълняват актуализациите на сървърите.

Първоначалното решение взехме "на челото" по следния начин - централният сървър избира група сървъри за актуализиране, записва необходимитепараметри (роли), след това се свързва отдалечено към всеки възел (паралелно, разпределено) и принудително стартира chef agent върху тях с даденото име на chef сървъра. Останалото е стандартно. След приключване на работата, възлите докладват на главния сървър и той избира следващата група.

По-късно напуснахме напълно Chef, като написахме собствен агент и малко опростихме и подобрихме схемата.

Съгласен съм, но дори и за тези цели, като администратор, следните точки биха ме напрегнали:

В сериозните мрежи бих предпочел да се контролират по-строго такива неща.

Е, отново, просто все още нямате този мащаб. А не задачата за пълноценно разгръщане.

sed -i '/\/var\/log\/puppet/a \server=srv.co.com' /etc/puppet/puppet.conf

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

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

Съжалявам, все пак ще се събера със статията. Тази тема отново ще бъде стимул.

И как бихте решили моя пример (плюс останалите, ако имате някакви мисли)? Чисто за статистика - искам да знам мненията на колегите.

Е, опасявам се, че няма да подобря много статистиката ви и няма да ви кажа нищо ново. Първо, готвачът/куклата наистина не знаят как да оркестрират, доколкото знам - те просто не са създадени за това. От това следва, че нито клъстерът, нитоте просто не могат да актуализират няколко взаимосвързани сървъра. Второ, марионетката не е предназначена за внедряване на приложения. Да, защото може да управлява конфигурацията на мениджъра на пакети (и поради редица други причини) е много удобно да инсталирате или актуализирате много, много пакети, включително в определен ред. Но - всичко това ще бъде направено не от шефа / марионетката, а от мениджъра на пакетите.

Вие знаете всичко това, разбира се, и без мен; Просто не искам да губя контекста на разговора.

Така. С всичко това, за да актуализирате взаимосвързани услуги на различни възли в определен ред, все още трябва да преоткриете колелото. Или, както описахте по-горе, променете конфигурацията на SCM в отделен процес и след това насилствено издърпайте агента. Наклонихме се към идеята за опаковане (deb/msi) на разработения софтуер и написването му (софтуер), като се вземат предвид възможните непоследователни състояния. Освен това новите пакети се излагат или по време на технологични прозорци, или по време на периоди на минимално натоварване на системата.

P.S. Един бегъл гугъл казва, че кукленото предприятие е способно на някакъв вид оркестрация. Никога през живота си не съм гледал RE, така че не мога да кажа нищо за него.

Голям плюс за вас за пакетите - не всеки прави това, а ако не го правят, тогава с внедряването има много забавни хемороиди с отстраняване.

Аз също не докоснах PE, но, съдейки по документацията, той не прави много - може просто да комбинира задачи на няколко етапа (например процентът на едновременно актуализираните сървъри). Особено в командния ред - половината работа на ръка.

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