ცოტა ხნის წინ, ჟურნალის გვერდებზე, ჩვენ გადავხედეთ Cfengine დისტანციური კონფიგურაციის მართვის სისტემას UNIX მანქანებისთვის, რაც მნიშვნელოვნად ამარტივებს სისტემის ადმინისტრატორის ცხოვრებას მრავალი ქსელის კვანძის კონფიგურაციის ნაბიჯების ავტომატიზაციის გზით. მაგრამ, რაც არ უნდა მოსახერხებელი იყოს Cfengine, მას აქვს ბევრი მინუსი, რაც არ გააჩნია სისტემას, რომელსაც ეწოდება Puppet.

წარმოიდგინეთ თქვენი თავი სისტემის ადმინისტრატორის როლში, რომელიც პასუხისმგებელია UNIX-ის ტიპის ოპერაციული სისტემების ასობით მანქანის ფუნქციონირების შენარჩუნებაზე. თითოეული მათგანი მოითხოვს კონფიგურაციას, პერიოდულ განახლებას და მონიტორინგს და ვარაუდობენ, რომ ბევრი მათგანი ასრულებს მსგავს ფუნქციებს.

ორი მესამედი სამუშაო სადგურია, კიდევ რამდენიმე მარშრუტიზატორი, დანარჩენი კი რამდენიმე ვებ სერვერი და მონაცემთა მაღაზიები. კითხვა: როგორ მართოთ მთელი ეს ბიზნესი? უმარტივესი პასუხია, უბრალოდ დაუკავშირდეთ თითოეულ მათგანს SSH-ის გამოყენებით და განახორციელოთ საჭირო ცვლილებები. თუმცა, ამ მეთოდს ორი პრობლემა აქვს. პირველ რიგში, ეს არის ძალიან შრომატევადი. მეორეც, ადმინისტრატორს მუდმივად მოუწევს მრავალი ერთფეროვანი მოქმედების შესრულება (მაგალითად, OpenOffice.org-ის ყველა სამუშაო სადგურზე განახლებისთვის, თქვენ მოგიწევთ იგივე ბრძანებების შესრულება რამდენჯერმე). თქვენ შეგიძლიათ სცადოთ ამ პრობლემის თავიდან აცილება რამდენიმე სკრიპტის დაწერით, რომლებიც თავად დაუკავშირდებიან თითოეულ მანქანას და შეასრულებენ წინასწარ დაწერილ ბრძანებებს. მაგრამ აქაც პრობლემები გელით.

სკრიპტები მუდმივად უნდა შეიცვალოს, რათა მოერგოს მათ თითოეულ ამოცანას; სკრიპტებს მოუწევთ გაითვალისწინონ განსხვავებები ოპერაციულ სისტემებსა და ვერსიებში და მათ დიდი ხნის განმავლობაში მოუწევთ გამართვა, სანამ გამოყენებული იქნება გაშვებულ მანქანებზე. ზოგადად, comme il faut. სწორი პასუხია ეგრეთ წოდებული დისტანციური კონფიგურაციის მართვის სისტემების გამოყენება, რომელთა ყველაზე ცნობილი წარმომადგენლები არიან ღია კოდის სისტემები Cfengine და Puppet. ასეთი სისტემები იღებენ ყველა პასუხისმგებლობას მანქანის კონფიგურაციის სასურველ ფორმამდე მიყვანისთვის, რაც მოითხოვს ადმინისტრატორს მხოლოდ აღწერს სისტემის საბოლოო მდგომარეობას სპეციალურ ენაზე (მაგალითად, აღწერა, თუ რომელი პაკეტები უნდა იყოს დაინსტალირებული OS-ში, რომელიც ხაზები უნდა დაემატოს კონფიგურაციის ფაილებს, რომელი ბრძანებები უნდა შესრულდეს და ა.შ.). ამის შემდეგ, ყველა კვანძი თავად მიიღებს ინფორმაციას საჭირო მდგომარეობის შესახებ სერვერისგან და ავტომატურად დააკონფიგურირებს სისტემას. ამ მექანიზმის წყალობით, ახალი მანქანების სრული კონფიგურაცია შესაძლებელია ადამიანის ჩარევის გარეშე, ხოლო არსებულის ხელახალი კონფიგურაცია შესაძლებელია მხოლოდ რამდენიმე ხაზის დამატებით სახელმწიფო აღწერილობაში.

თოჯინა?

ჩვენ უკვე მივუძღვენეთ მთელი სტატია Cfengine სისტემას, ამიტომ დღეს ჩვენ ყურადღებას გავამახვილებთ თოჯინების სისტემაზე, რომელსაც კარგად შეიძლება ვუწოდოთ მისი იდეოლოგიური მემკვიდრე. თოჯინა შეიმუშავა ლუკ კანიესმა, რომელმაც დაიღალა Cfengine-ის შეზღუდვებით და გადაწყვიტა უკეთესი ვერსიის შექმნა ნულიდან. თუ უკვე იყენებდით Cfenfine-ს, თქვენ ალბათ იპოვით Puppet-ს უფრო მოსახერხებელ და მძლავრ სისტემას. თოჯინების სახელმწიფო ენა უფრო მაღალი დონის და მოქნილია, ამიტომ ადმინისტრატორებს არ სჭირდებათ ფიქრი იმაზე, როგორიცაა ცალკეული წესების დაწერა თითოეული OS ტიპისთვის ან დეტალურად, თუ როგორ უნდა შეასრულონ ტრივიალური მოქმედებები. თოჯინა საშუალებას აძლევს თავის ოსტატს ფოკუსირება მოახდინოს იმაზე, რისი გაკეთებაც სურს, ნაცვლად იმისა, თუ როგორ უნდა გააკეთოს ეს (მაგალითად, კონკრეტული პაკეტის დაყენება სისტემის ნებისმიერ მხარდაჭერილ OS-ზე, თქვენ უბრალოდ უნდა დაწეროთ სიტყვასიტყვით რამდენიმე სტრიქონი, რომელშიც ნათქვამია: „დააინსტალირე ეს პროგრამა. მისი ინსტალაციისთვის აუცილებელი ბრძანებების აღწერის ნაცვლად). თოჯინა დაწერილია უბრალო Ruby ენაზე, რაც აადვილებს მის ადაპტირებას კონკრეტულ ამოცანასთან და აფართოებს მის ფუნქციონირებას (მოწოდებულია დანამატების მოქნილი სისტემა).

გარდა ამისა, Cfengine-ის განვითარების მოდელისგან განსხვავებით, რომელიც არსებითად ტრიალებს ერთ ადამიანზე, Puppet-ს ჰყავს ენთუზიასტების დიდი საზოგადოება, რომლებიც აუმჯობესებენ კოდს, აზიარებენ კონფიგურაციის მაგალითებს და წერენ დოკუმენტაციას.

მთლიანობაში, თოჯინა უფრო თანამედროვე და კარგად შემუშავებული სისტემაა. Cfengine-ის მსგავსად, ის მხარს უჭერს თითქმის ყველა თანამედროვე UNIX-ის მსგავს ოპერაციულ სისტემას (მათ შორის MacOS X) და ასევე შეუძლია იმუშაოს Cygwin გარემოში Windows-ის თავზე. მისი დამოკიდებულების სიაში შედის მხოლოდ Ruby თარჯიმანი და Factor ინსტრუმენტი, ამიტომ ინსტალაციასთან დაკავშირებული პრობლემები არ უნდა იყოს (სამართლიანი რომ ვიყოთ, Cfengine-ის დამოკიდებულების სია კიდევ უფრო მოკლეა).

ინსტალაცია

Cfengne-ის მსგავსად, Puppet არის კლიენტ-სერვერის სისტემა, რომელიც შედგება საკონტროლო სერვერისა და სლავური კვანძებისგან. სერვერი ინახავს კვანძების საბოლოო მდგომარეობების აღწერას (რომელსაც Puppet-ის ტერმინებით მანიფესტი ეწოდება) და ელოდება მათ დაკავშირებას. ყოველ ნახევარ საათში (ნაგულისხმევად) კლიენტი უერთდება სერვერს, იღებს მისგან საბოლოო მდგომარეობის აღწერას, ადარებს მას მიმდინარე მდგომარეობას და, თუ ის და/ან აღწერილი მდგომარეობა შეიცვალა, ახდენს სისტემის ხელახლა კონფიგურაციას და შემდეგ. მიდის დასაძინებლად. კომუნიკაცია ხორციელდება დაშიფრული არხის საშუალებით, ამიტომ გამორიცხულია სახელმწიფო აღწერილობის ჩანაცვლების საფუძველზე შეტევები (მაგრამ თუ თავდამსხმელი აიღებს სერვერს, მაშინ ყველა კვანძი იქნება მისი კონტროლის ქვეშ).

თოჯინა შედის ყველა პოპულარული დისტრიბუციის საცავებში, ამიტომ მისი დაყენება არ უნდა იყოს რთული. მაგალითად, Debian/Ubuntu-ზე Puppet კლიენტი შეიძლება დაინსტალირდეს ასე:

$ sudo apt-get install puppet

და სერვერი ასეთია:

$ sudo apt-get დააინსტალირე მარიონეტული თოჯინების ოსტატი

კლიენტისა და სერვერის კონფიგურაციის ფაილები ინახება /etc/puppet დირექტორიაში. მათგან ყველაზე მნიშვნელოვანია ფაილი /etc/puppet/manifests/site.pp, რომელიც შეიცავს მანიფესტს.

ის ინახავს მდგომარეობების აღწერას და უნდა არსებობდეს მხოლოდ სერვერზე. გამართვის გამარტივებისთვის, მოდით დავამატოთ მას მარტივი კონფიგურაცია:

კლასის პაროლი (
ფაილი ("/etc/passwd":
მფლობელი => root,
ჯგუფი => root,
რეჟიმი => 644,
}
}
ნაგულისხმევი კვანძი (
მოიცავს passwd
}

ეს სტრიქონები აღწერს მდგომარეობას, როდესაც /etc/passwd ფაილის მფლობელი უნდა იყოს root და მისი ნებართვები დაყენებულია 644-ზე. ჩვენ უფრო დეტალურად განვიხილავთ manifest ფაილის ფორმატს შემდეგ განყოფილებაში. მეორე ყველაზე მნიშვნელოვანი ფაილია /etc/puppet/puppet.conf. ის ადგენს სერვერისა და კლიენტების კონფიგურაციას, ამიტომ ის უნდა იყოს წარმოდგენილი თოჯინების ქსელში ორგანიზებულ ყველა მანქანაზე. Ubuntu-ში ეს ფაილი შეიცავს მინიმალურ საჭირო და უმეტეს შემთხვევაში საკმარის პარამეტრებს. ქვემოთ მოცემულია ისინი კომენტარებით:

# vi /etc/puppet/puppet.conf
# სტანდარტული დირექტორია ბილიკები
logdir=/var/log/თოჯინა
vardir=/var/lib/თოჯინა
ssldir=/var/lib/თოჯინა/ssl
rundir=/var/run/თოჯინა
# ფაქტორი ინსტრუმენტის ადგილმდებარეობა,
# გამოიყენება OS-ის შესახებ ინფორმაციის მისაღებად
factpath=$vardir/lib/facter
# დანამატების სინქრონიზაცია
# (დაინსტალირებული დანამატები სერვერზე - ისინი კოპირებულია კლიენტებზე)
pluginsync=true
# კატალოგი შაბლონებით (მათ შესახებ წაიკითხეთ ქვემოთ)
templatedir=$confdir/თარგები
# სინქრონიზაცია etckeeper-თან
# (ვინ იცის, გაიგებს, სხვებს არ სჭირდებათ)
prerun_command=/etc/puppet/etckeeper-commitpre
postrun_command=/etc/თოჯინა/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 puppetca -- სია

აირჩიეთ ჰოსტი სიიდან და მოაწერეთ ხელი მის სერტიფიკატს:

$ sudo puppetca -- ნიშანი nomad.grinder.com

ან ყველაფერს ერთდროულად ვაწერთ ხელს:

$ sudo puppetca --ნიშანი --ყველა

ახლა თქვენ შეგიძლიათ კლიენტების გაშვება საბრძოლო რეჟიმში. მაგრამ ჯერ თქვენ უნდა შეიყვანოთ Puppet სერვერის სახელი კონფიგურაციის ფაილში (ნაგულისხმევად მისი სახელი უბრალოდ თოჯინაა):

$sudo su
# echo "" >> /etc/puppet/puppet.conf
# echo "server=puppet-server.com" >> /etc/puppet/puppet.conf
#გასვლა

კლიენტების გაშვება:

$ sudo /etc/init.d/puppet start

სახელმწიფო აღწერის ენა

როგორც ზემოთ აღვნიშნეთ, Puppet იყენებს საკუთარ ენას ოპერაციული სისტემის საბოლოო მდგომარეობის აღსაწერად, რომლის დახმარებით სისტემის ადმინისტრატორი აზუსტებს რა ფორმაში უნდა იყოს OS კომპონენტები, რათა მან მიაღწიოს სასურველ მდგომარეობას. ეს არის საკმაოდ რთული ენა, რომელიც, მიუხედავად ამისა, ბევრად უფრო მარტივია, ვიდრე ნებისმიერი პროგრამირების ენა. თუ ზედაპირულად მაინც იცნობთ ბაშის სკრიპტირების ენას, ადვილად გაიგებთ თოჯინების ენას. ენის მთავარი ელემენტია რესურსები, რომლებიც გამოიყენება აღწერისთვის, თუ რა ფორმით უნდა გადაიზარდოს OS-ის ერთ-ერთი კომპონენტი. მაგალითად, შემდეგი მარტივი რესურსი აღწერს /etc/passwd ფაილის სასურველ მდგომარეობას:

# vi /etc/puppet/manifests/site.pp
ფაილი ("/etc/passwd":
მფლობელი => "ძირი"
}

აქ ფაილი არის რესურსის ტიპი. სულ რამდენიმე ათეული მათგანია, დაწყებული რესურსებიდან, რომლებიც მართავენ ფაილებს, როგორც ამ მაგალითში, პაკეტებსა და სერვისებამდე. ხაზი /etc/passwd არის რესურსის სახელი.

ფაილის ტიპის შემთხვევაში, სახელი იგივეა, რაც ფაილის გზა, მაგრამ ზოგიერთ სხვა ტიპში სახელი შეიძლება იყოს თვითნებური. ხაზის მფლობელი => "root" აღწერს მფლობელის ატრიბუტის დაყენებას root, ანუ ამბობს, რომ მითითებული ფაილის მფლობელი უნდა იყოს ადმინისტრატორი.

რესურსების თითოეულ ტიპს აქვს ატრიბუტების საკუთარი ნაკრები, რომლებიც ხელმისაწვდომია მოდიფიკაციისთვის, ასევე არის სპეციალური მეტა ატრიბუტები, რომლებიც შეიძლება გამოყენებულ იქნას ნებისმიერ რესურსში. რესურსების ერთ-ერთი მნიშვნელოვანი თვისებაა მათთან დაკავშირების შესაძლებლობა. ეს შეიძლება გამოყენებულ იქნას დამოკიდებულების ჯაჭვების შესაქმნელად. შემდეგი ჩანაწერი ქმნის /etc/group რესურსს, რომელიც დამოკიდებულია /etc/passwd რესურსზე (დამოკიდებულებები მითითებულია საჭირო მეტა ატრიბუტის გამოყენებით):

# vi /etc/puppet/manifests/site.pp
ფაილი ("/etc/group":
მოითხოვს => ფაილი ["/etc/passwd"],
მფლობელი => "ძირი",
}

ეს ნიშნავს, რომ /etc/group რესურსის კონფიგურაცია შესაძლებელია (აღწერილ ფორმაზე მიყვანა) მხოლოდ მაშინ, როცა /etc/passwd რესურსი არის კონფიგურირებული. რესურსები შეიძლება დაჯგუფდეს რესურსების კოლექციებად, რომელსაც ეწოდება კლასები. ეს აუცილებელია იმისათვის, რომ გაერთიანდეს მსგავსი რესურსები მნიშვნელობით და შესრულებული დავალების ტიპით ერთ აბსტრაქტულ რესურსში. მაგალითად, მოხერხებულობისთვის, ჩვენ შეგვიძლია გავაერთიანოთ nginx ვებ სერვერის ინსტალაცია და გაშვება იმავე სახელწოდების ერთ აბსტრაქტულ რესურსში:

# vi /etc/puppet/manifests/site.pp
კლასი nginx (
პაკეტი ("nginx":
უზრუნველყოს => დაინსტალირებული
}
სერვისი ("nginx":
უზრუნველყოს => გაშვება,
მოითხოვს => პაკეტი ["nginx"],
}
}

აქ, პაკეტის რესურსის ტიპი გამოიყენება სისტემაზე nginx პაკეტის დასაყენებლად, ხოლო სერვისი გამოიყენება ამავე სახელწოდების სერვისის გასაშვებად. მოთხოვნით ჩვენ ვაიძულებთ სისტემას სერვისის დაწყება მხოლოდ იმ შემთხვევაში, თუ პაკეტი წარმატებით დაინსტალირებულია. კლასების მოხერხებულობა იმაში მდგომარეობს, რომ ისინი ასევე შეიძლება შევიდეს იმის მიხედვით:

# vi /etc/puppet/manifests/site.pp
სერვისი ("კალმარი":
უზრუნველყოს => გაშვება,
მოითხოვს => კლასი ["nginx"],
}

როგორც რეალურ OOP ენებში, კლასებს შეუძლიათ ერთმანეთისგან მემკვიდრეობა და ატრიბუტების გადალახვა:

# vi /etc/puppet/manifests/site.pp
კლასის პაროლი (
ფაილი ("/etc/passwd":
მფლობელი => "ძირი",
ჯგუფი => "ძირი",
}
}
კლასი passwd-bsd მემკვიდრეობით იღებს passwd (
ფაილი["/etc/passwd"] (ჯგუფი => "ბორბალი")
}

აქ passwd-bsd კლასი მემკვიდრეობით იღებს passwd-ს, რათა გადალახოს /etc/passwd რესურსის ჯგუფის ატრიბუტი (BSD სისტემებზე /etc/passwd ეკუთვნის ბორბლის ჯგუფს, ამიტომ ჩვენ შევქმენით ცალკე კლასი ასეთი სისტემებისთვის). მოგვიანებით განვიხილავთ ალტერნატიული ატრიბუტების მნიშვნელობების არჩევის უფრო სწორ და აშკარა გზას პირობების გამოყენებით.

ცვლადები ნებისმიერი პროგრამირების ენის ერთ-ერთი განუყოფელი კომპონენტია და Puppet-საც აქვს ისინი. ცვლადები იწყება $ ნიშნით და შეიძლება შეიცავდეს ნებისმიერ რიცხვს, სტრიქონს ან ლოგიკურ მნიშვნელობას (true, false):

$want_apache = მართალია
$apache_version = "2.2.14"

Puppet-ის ერთ-ერთი ყველაზე მძლავრი ცვლადთან დაკავშირებული მახასიათებელია მისი ინტეგრაცია ფაქტორ-მანქანის ინფორმაციის ინსტრუმენტთან. ეს პროგრამა აბრუნებს ყველა მანქანას სპეციფიკურ ინფორმაციას გასაღები-მნიშვნელობის წყვილების სახით, რომლებიც გადაიქცევა იმავე სახელწოდების ცვლადებად Puppet-ში. თოჯინების ენაზე პირობით ინსტრუქციებთან ერთად, მათი გამოყენება შესაძლებელია რესურსის ატრიბუტების შესაცვლელად, რაც დამოკიდებულია აპარატის თვისებებზე.

მაგალითად, ზემოთ აღწერილი passwd კლასი შეიძლება ადვილად გადაიწეროს, რომ ავტომატურად შეარჩიოს ატრიბუტი OS ტიპის მიხედვით (თავად კლასის საჭიროების გარეშე):

# vi /etc/puppet/manifests/site.pp
ფაილი ("/etc/passwd":
მფლობელი => "ძირი",
ჯგუფი => $kernel ? (
Linux => "root",
FreeBSD => "ბორბალი",
},
}

იმისდა მიხედვით, თუ რომელ ოპერაციულ სისტემაზე იქნება გაანალიზებული მანიფესტის ეს ფრაგმენტი, ჯგუფის ატრიბუტის მნიშვნელობა იქნება ფესვი ან ბორბალი. პირობითი ოპერატორის გარდა, Puppet ენა ასევე მხარს უჭერს შემთხვევის შერჩევის ოპერატორს, რომელიც შეიძლება გამოყენებულ იქნას კონკრეტული რესურსის შესაქმნელად, ცვლადის მნიშვნელობიდან გამომდინარე:

# vi /etc/puppet/manifests/site.pp
საქმე $ოპერაციული სისტემა (
redhat: (სერვისი ("httpd": უზრუნველყოს => გაშვება))
debian: (სერვისი ("apache": უზრუნველყოს => გაშვება))
ნაგულისხმევი: ( სერვისი ( "apache2": უზრუნველყოს =>
სირბილი))
}

ეს კოდი განსაზღვრავს ტიპის სერვისის რესურსის სხვადასხვა ვარიანტს ოპერაციული სისტემის მიხედვით (სერვისის სახელები შეიძლება განსხვავდებოდეს Linux დისტრიბუციებს შორის, ამიტომ, რომელი სერვისი უნდა გაუშვას Puppet-მა, ინდივიდუალურად უნდა იყოს მითითებული თითოეული მათგანისთვის).

ნაგულისხმევი ვარიანტი გამოიყენება, თუ ცვლადის მნიშვნელობა არ ემთხვევა არცერთ წინა ვარიანტს. გარდა ადრე განხილული ფაილის, პაკეტისა და სერვისის რესურსების ტიპებისა, Puppet მხარს უჭერს რესურსების სხვა ტიპებს, მათ შორის მესამე მხარის დეველოპერების მიერ შექმნილ რესურსებს. მათი დეტალური აღწერა, მაგალითების, მხარდაჭერილი ატრიბუტებისა და მახასიათებლების ჩათვლით, შეგიძლიათ იხილოთ ოფიციალურ დოკუმენტაციაში - http://docs.puppetlabs.com/references/stable/type.html. ქვემოთ მოცემულია ყველაზე ხშირად გამოყენებული სია და მოკლე აღწერა:

პოპულარული მარიონეტული რესურსების ტიპები

• cron - მართეთ კრონის სამუშაოები
• exec - გაუშვით სკრიპტები და ბრძანებები
• ფაილი - ფაილების მართვა
• filebucket - ფაილის სარეზერვო
• ჯგუფი - ჯგუფის მართვა
• ჰოსტი - მართეთ ჩანაწერები /etc/hosts ფაილში
• ინტერფეისი - ქსელის ინტერფეისების კონფიგურაცია
• mount - სამონტაჟო ფაილური სისტემები
• შეტყობინება - გაგზავნეთ შეტყობინება თოჯინების ჟურნალის ფაილში
• პაკეტი - პაკეტის მართვა
• სერვისი - სერვისის მართვა
• sshkey - SSH კლავიშების მართვა
• მოწესრიგებული - ფაილების წაშლა პირობებიდან გამომდინარე
• მომხმარებლის - მომხმარებლის მენეჯმენტი
• ზონები - სოლარისის ზონის მართვა

Puppet ენის მეორე ყველაზე მნიშვნელოვანი ელემენტი რესურსების შემდეგ არის კვანძები. მათი დახმარებით ადმინისტრატორს შეუძლია აღწეროს რომელ მანქანებზე უნდა იყოს გამოყენებული გარკვეული რესურსები და კლასები. სხვა სიტყვებით რომ ვთქვათ, ეს არის თოჯინების ქსელში მონაწილე თითოეული მანქანისთვის ინდივიდუალური კონფიგურაციის განსაზღვრის საშუალება. კვანძის უმარტივესი მაგალითი მოცემულია სტატიის დასაწყისში განყოფილებაში "ინსტალაცია":

# vi /etc/puppet/manifests/site.pp
ნაგულისხმევი კვანძი (
მოიცავს passwd
}

ეს არის ნაგულისხმევი კვანძის განმარტება, რომელიც მოიცავს passwd რესურსს/კლასს. ნაგულისხმევი სახელი ნიშნავს "ყველა სხვა კვანძს", ამიტომ სადღაც ზემოთ განსაზღვრული passwd რესურსი/კლასი კონფიგურირებული იქნება თითოეულ მათგანზე. მოიცავს საკვანძო სიტყვა აქ გამოიყენება მოხერხებულობისთვის, ფაქტობრივად, ყველა კლასი და რესურსი შეიძლება იყოს აღწერილი უშუალოდ კვანძის აღწერაში, მაგრამ ეს არ არის რეკომენდებული. ნაგულისხმევის გარდა, კვანძის სახელში შეგიძლიათ მიუთითოთ აპარატის ქსელის სახელი (მაშინ კვანძში აღწერილი ყველა რესურსი კონფიგურირებული იქნება მხოლოდ ამ მანქანაზე), ან თვითნებური სახელი (მაშინ ეს კვანძი შეიძლება მემკვიდრეობით გადავიდეს სხვა კვანძმა) . იმის გასაგებად, თუ როგორ მუშაობს ეს ყველაფერი კლასებთან და რესურსებთან ერთად, მოდით შევხედოთ მზა თოჯინების მანიფესტის მაგალითს, რომელიც გამოიყენება ორი ქსელური აპარატის კონფიგურაციისთვის (ვებ სერვერი და NTP სერვერი):

# vi /etc/puppet/manifests/site.pp
# SSH სერვერის ინსტალაცია და გაშვება
კლასი sshd (
პაკეტი (openssh-სერვერი: უზრუნველყოს => დაინსტალირებული)
სერვისი (sshd:
სახელი => $ოპერაციული სისტემა ? (
Fedora => "sshd",
debian => "ssh",
ნაგულისხმევი => "sshd",
},
ჩართვა => true,
უზრუნველყოს => გაშვება,
}
}
# დააინსტალირეთ და გაუშვით Apache
კლასი httpd(
პაკეტი (httpd: უზრუნველყოს => დაინსტალირებული)
სერვისი (httpd:
ჩართვა => true,
უზრუნველყოს => გაშვება,
}
}
# NTP სერვერის ინსტალაცია და გაშვება
კლასი ntpd (
პაკეტი (ntp-სერვერი: უზრუნველყოს => დაინსტალირებული)
მომსახურება (
ntp სერვერი:
ჩართვა => true,
უზრუნველყოს => გაშვება,
}
}
# საბაზისო კვანძი, გამოიყენება მხოლოდ როგორც ყველა დანარჩენის მშობელი
კვანძის ბაზა (
მოიცავს sshd
}
# კვანძი, სადაც განთავსდება ვებ სერვერი
node web.server.com მემკვიდრეობით იღებს ბაზას (
მოიცავს httpd
}
# NTP სერვერის კვანძი
კვანძი ntp.server.com მემკვიდრეობით იღებს ბაზას (
მოიცავს ntpd
}

ეს ერთი შეხედვით მარტივი კონფიგურაცია საკმაოდ ბევრს აკეთებს: ის დაინსტალირებს Apache-ს და მუშაობს აპარატზე web.server.com-ზე და NTP სერვერზე დაინსტალირებული და მუშაობს მოწყობილობაზე. ntp.server.com. გარდა ამისა, ორივე მანქანა დააინსტალირებს SSH სერვერს. ეს კონფიგურაცია ნაკლებად სავარაუდოა, რომ მოერგოს თუნდაც ერთ ადმინისტრატორს; ის სერიოზულად უნდა გაუმჯობესდეს, რათა ასწავლოს სერვერების სწორად კონფიგურაცია, ახალი კონფიგურაციების და სხვა ფაილების მიღება მთავარი Puppet სერვერიდან.

თუმცა, ეს ნათლად აჩვენებს თოჯინის ძალას. მარტივი კონფიგურაციის გამოყენებით, ჩვენ ვაიძულებდით მანქანებს თავად დააინსტალიროთ და გაუშვათ საჭირო პროგრამული უზრუნველყოფა და შევინარჩუნოთ იგი მუშა მდგომარეობაში (თუ სერვერი გაფუჭდა, თავად Puppet ხელახლა დააკონფიგურირებს სისტემების საჭირო მდგომარეობაში მოსაყვანად).

ფაილის სერვერი

დისტანციური ადმინისტრირების მრავალი ამოცანის გადაჭრა შეუძლებელია მანქანებზე დამატებითი ფაილების კოპირების გარეშე. ეს შეიძლება იყოს წინასწარ მომზადებული კონფიგურაციები, ვებ გვერდები Apache-სთვის, პაკეტები, რომლებიც არ არის ოფიციალურ საცავში და მრავალი სხვა. ამ ფაილების დისტანციურ მასპინძლებზე გადაცემის პროცესის გასაადვილებლად, Puppet შეიცავს ფაილ სერვერს.

ფაილის სერვერის პარამეტრები ინახება /etc/puppet/fileserver.conf ფაილში. იმისათვის, რომ აიძულოთ თოჯინა, კლიენტებს მიაწოდოს კონკრეტული დირექტორიაში შიგთავსი, თქვენ უნდა ჩაწეროთ მასში რამდენიმე სტრიქონი:

# vi /etc/puppet/fileserver.conf
გზა = /var/თოჯინა/ფაილები
დაუშვით *.server.com

ეს ორი ხაზი მიუთითებს, რომ /var/puppet/files დირექტორია ხელმისაწვდომი უნდა იყოს სერვერ.com დომენის ყველა ჰოსტისთვის. გარდა ამისა, ჩვენ შეგვიძლია განვსაზღვროთ ნებადართული აპარატის სრული დომენის სახელი ან მისი IP მისამართი და ასევე გამოვრიცხოთ არასასურველი დირექტივის უარყოფის გამოყენებით. ამ დირექტორიაში არსებული ნებისმიერი ფაილი შეიძლება შემდეგ გადავიდეს კლიენტში ფაილის რესურსის გამოყენებით. Მაგალითად:

# vi /etc/puppet/manifests/site.pp
ფაილი ("/etc/httpd/conf/httpd.conf":
წყარო => "თოჯინა://httpd/httpd.conf",
რეჟიმი => 644,
}

httpd.conf ფაილი, რომელიც მდებარეობს სერვერზე /var/puppet/files/httpd დირექტორიაში, დაკოპირდება სამიზნე მანქანაში რესურსის სახელში მითითებულ გზაზე.

დასკვნები

ამ სტატიაში ჩვენ განვიხილეთ თოჯინების შესაძლებლობების ძალიან მცირე ნაწილი. სინამდვილეში, ეს არის რთული სისტემა, რომლის სრულად აღწერა მხოლოდ წიგნის ფურცლებზეა შესაძლებელი. ამავდროულად, Puppet-ის კონფიგურაცია და შენარჩუნება ძალიან მარტივია, მით უმეტეს, რომ ინტერნეტში შეგიძლიათ იპოვოთ მისი კონფიგურაციის უამრავი მაგალითი.

ინფორმაცია

• Puppet იყენებს HTTP პროტოკოლს, ამიტომ მისი გაშვება შესაძლებელია ვებ სერვერის ქვეშ მუშაობის გასაუმჯობესებლად.
• თოჯინების გამოყენება შესაძლებელია ერთი ადგილობრივი მანქანის ავტომატური კონფიგურაციისა და შესანარჩუნებლად.
• 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 - რესურსის ტიპები

ვირტუალური სერვერების ადმინისტრირება თოჯინების გამოყენებით

ნაწილი 1: თოჯინების ინსტალაცია და კონფიგურაცია

შინაარსის სერია:

სერვერის გარემოს ორგანიზების პროცესში ვირტუალიზაციის ხელსაწყოების ან ღრუბლოვანი სერვისების გამოყენებით, ინდივიდუალური სერვერების რაოდენობა სწრაფად იზრდება. ყოველ ჯერზე, როდესაც თქვენ შექმნით ახალ სერვერს, საჭიროა შესაბამისი პროგრამული უზრუნველყოფის ინსტალაცია და კონფიგურაცია. უფრო მეტიც, სერვერის კონფიგურაციების სინქრონიზაცია მოითხოვს დამატებით ძალისხმევას, როგორიცაა shell სკრიპტების დაწერა ჭურვი.

Puppet პროგრამული უზრუნველყოფის გამოყენებით, თქვენ შეგიძლიათ სწრაფად შექმნათ ახალი სერვერი და დააკონფიგურიროთ მისი პარამეტრები მხოლოდ რამდენიმე ბრძანებით, ყოველგვარი სირთულის გარეშე. გარდა ამისა, Puppet პერიოდულად მოაწყობს შექმნილი სერვერების კონფიგურაციის სინქრონიზაციას.

იმისდა მიუხედავად, რომ ეს პროგრამა ჩვეულებრივ გამოიყენება დიდი სერვერის სტრუქტურების სამართავად (მაგალითად, მონაცემთა ცენტრებში ან ვებ სერვისებში მომხმარებლების დიდი რაოდენობით), ის ასევე შეიძლება გამოყენებულ იქნას რამდენიმე სერვერის შესანარჩუნებლად (მაგალითად, ლოკალურ ქსელში. პატარა ოფისში ან სახლის ქსელში).

თოჯინების ისტორია

თოჯინების პროექტი შემუშავებულია Puppet Labs-ის მიერ და ვრცელდება როგორც ღია კოდის პროგრამული უზრუნველყოფა. პროგრამას აქვს მოქნილი მოდულური სტრუქტურა: ამჟამად 200-ზე მეტი გაფართოების მოდული დაიწერა Puppet-ისთვის.

თოჯინას მხარს უჭერს არა მხოლოდ დეველოპერული კომპანია, არამედ ძალიან აქტიური მომხმარებელთა საზოგადოება.

თოჯინების დაყენება და მომზადება სამუშაოდ

თოჯინების ფუნქციონირება ორგანიზებულია კლიენტ-სერვერის სქემის მიხედვით. თითოეული კლიენტი პერიოდულად ურთიერთობს მართვის მთავარ სერვერთან (ან რამდენიმე ასეთ სერვერთან) და სინქრონიზებს მის კონფიგურაციას. სტანდარტულად, ასეთი საკომუნიკაციო სესიები ტარდება ყოველ ნახევარ საათში. ამიტომ, Puppet-ის ნორმალური მუშაობის უზრუნველსაყოფად, დაგჭირდებათ მინიმუმ ორი დაინსტალირებული სერვერი: ერთი იმოქმედებს როგორც მასტერ სერვერი, ხოლო მეორე (ან სხვები) იმოქმედებს როგორც მასზე დაქვემდებარებული სერვერები, ანუ ამ კონტექსტში ჩვენ შეგვიძლია უწოდეთ მათ სერვერები.

იმისათვის, რომ დააინსტალიროთ Puppet ჰოსტზე, რომელიც მართავს სხვა სერვერებს, როგორც მართვის ძირითადი სერვერი, თქვენ უნდა გაუშვათ ბრძანებები, რომლებიც ნაჩვენებია სიაში 1. გაითვალისწინეთ, რომ ეს ბრძანებები გაშვებულია როგორც root. ფესვი.

ჩამონათვალი 1. მარიონეტული სერვერის პაკეტის დაყენება მთავარ ბრძანებისა და მართვის სერვერზე

# yum -y დააინსტალირეთ თოჯინების სერვერი # chkconfig puppetmaster # სერვისის თოჯინების ოსტატის დაწყებაზე

სლავური სერვერების პაკეტები დაინსტალირებულია კლიენტ ჰოსტებზე, როგორც ნაჩვენებია სიაში 2 (ბრძანებები ასევე შესრულებულია როგორც სუპერმომხმარებელი ფესვი).

ჩამონათვალი 2. თოჯინების პაკეტის დაყენება კლიენტ ჰოსტზე

# yum -y დააინსტალირე მარიონეტული # chkconfig მარიონეტული # სერვისის მარიონეტული დაწყება

თუ მთავარი საკონტროლო სერვერის ჰოსტი დაცულია firewall-ით, ხოლო კლიენტის ჰოსტები განლაგებულია ამ ბუხართან შედარებით „გარეთ“ (მაგალითად, კომპიუტერები ლოკალურ ქსელში), მაშინ მთავარ სერვერზე აუცილებელია TCP პორტის გახსნა. ნომერი 8140 და, თუ ეს შესაძლებელია, გახადეთ ის ხელმისაწვდომი მხოლოდ კლიენტ ჰოსტებისთვის. თუ ყველა ოპერაცია შესრულებულია ერთ კომპიუტერზე (localhost), მაშინ არ არის საჭირო მანიპულაციები firewall-თან.

თოჯინების საფუძვლები

მარიონეტული პერსპექტივიდან, ყველა კონფიგურაცია განისაზღვრება და აღწერილია, როგორც რესურსები ( რესურსები), რომელსაც შეიძლება ეწოდოს საკონტროლო გარემოს ძირითადი სტრუქტურული კომპონენტები. რესურსები შეიძლება იყოს ფაილები, სერვერის სერვისები, პროგრამული პაკეტები და ა.შ. უფრო მეტიც, რესურსი შეიძლება იყოს ერთი ჭურვის ბრძანების ზარი. მაგალითად, მე-3 სიაში აღწერილი ტიპის რესურსი ფაილიწარმოადგენს ფაილს /etc/passwd, რომელიც ცნობილია ყველასთვის, რომლის მფლობელიც არის ფესვი.

ჩამონათვალი 3. რესურსის აღწერა - ფაილი /etc/passwd

ფაილი ("/etc/passwd": მფლობელი => root, რეჟიმი => 644, )

რესურსები შეიძლება დაჯგუფდეს გარკვეული მახასიათებლების მიხედვით: მაგალითად, ნებისმიერ ფაილს ჰყავს მფლობელი და მდებარეობს ფაილურ სისტემაში კონკრეტულ მისამართზე (ბილიკზე), თითოეულ მომხმარებელს აქვს შესვლის სახელი, პერსონალური იდენტიფიკატორი (UID) და ჯგუფის იდენტიფიკატორი ( GID). ამ მახასიათებლების შესაბამისად ყალიბდება რესურსების ტიპები. უფრო მეტიც, რესურსის ტიპის ყველაზე მნიშვნელოვანი მახასიათებლები, როგორც წესი, ერთნაირია ყველა ოპერაციულ სისტემაში, განხორციელების მცირე დეტალების მიუხედავად. ანუ, რესურსის აღწერა შეიძლება მთლიანად აბსტრაქტული იყოს მისი განხორციელებიდან კონკრეტულ ოპერაციულ სისტემაში.

ზემოაღნიშნული წინაპირობებიდან გამომდინარე, ჩამოყალიბდა რესურსების აბსტრაქციის ფენა. RAL) თოჯინების პროგრამები. RAL ყოფს რესურსებს ტიპებად ( ტიპები), რომლებიც არიან მაღალი დონის მოდელები და პროვაიდერები ( პროვაიდერები), რომელიც წარმოადგენს რესურსების ქვედა დონის, პლატფორმის სპეციფიკურ იმპლემენტაციას. ეს RAL ორგანიზაცია საშუალებას გაძლევთ დაწეროთ რესურსების აღწერილობები ისე, რომ გამოიყენება თითქმის ნებისმიერი სისტემისთვის.

RAL სინქრონიზაციის ციკლი

Puppet იყენებს RAL სისტემის რესურსების მდგომარეობის წასაკითხად და შესაცვლელად. როგორც დეკლარაციული მონიტორინგისა და კონტროლის სისტემა, Puppet იწყებს თავის სამუშაო ციკლს ინფორმაციის მოპოვებით, თუ რა მდგომარეობაში უნდა იყოს რესურსი. რესურსების სინქრონიზაცია იყენებს RAL-ს, რათა მოითხოვოს მიმდინარე მდგომარეობა, შეადაროს ის სასურველ მდგომარეობას და განახორციელოს ნებისმიერი საჭირო ცვლილება, თუ რაიმე განსხვავება გამოვლინდება.

რესურსის აღწერილობის სტრუქტურა

როგორც ზემოთ აღინიშნა, თოჯინაში, ყველა რესურსი არის გარკვეული ტიპის მაგალითი ( რესურსის ტიპი), რომლითაც იწყება თავად აღწერა. რესურსი იდენტიფიცირებულია სახელით ( სათაური), რომელიც იწერება ერთ ბრჭყალებში გახსნის ხვეული ბრეკეტის შემდეგ და მოსდევს ორწერტილს. შემდეგი, ტიპის ატრიბუტები განისაზღვრება ახალ ხაზზე ( ატრიბუტები), ზოგიერთი ატრიბუტი საერთოა ყველა ტიპისთვის, ზოგი კი უნიკალურია ამ კონკრეტული ტიპის რესურსისთვის. თითოეულ ატრიბუტს აქვს მნიშვნელობა ( ღირებულება), ამიტომ ატრიბუტების ჩანაწერებს შესაბამისი მნიშვნელობებით აქვთ ზოგადი ფორმა ატრიბუტი => მნიშვნელობა.

თოჯინების რესურსის აღწერის ენის ზოგადი იდეა შეიძლება მიღებულ იქნეს 4 ჩამონათვალიდან, რომელიც აჩვენებს უმარტივეს შემთხვევას - "მომხმარებლის" ტიპის რესურსის აღწერა ( მომხმარებელი).

ჩამონათვალი 4. მარიონეტული რესურსის აღწერის ენის სინტაქსი მომხმარებლის მაგალითის გამოყენებით

მომხმარებელი ( "alex": უზრუნველყოს => present, uid => "501", gid => "admin", shell => "/bin/bash", მთავარი => "/home/alex", managementhome => true, )

თითოეული ატრიბუტის განსაზღვრის სტრიქონი მთავრდება მძიმით, ხოლო დახურვის ხვეული ფრჩხილი მიუთითებს, რომ რესურსის განმარტება დასრულებულია.

შემდეგი კონფიგურაცია, რომელიც ნაჩვენებია სიაში 5, აყენებს პაკეტს openssh-სერვერი, მომსახურებით სარგებლობის დაშვება sshdნაგულისხმევი და გაუშვით შემოწმება, რათა დარწმუნდეთ, რომ სერვისი რეალურად ჩართულია და მუშაობს.

ჩამონათვალი 5. რესურსის აღწერა - sshd სერვისი (ინსტალაცია, გაშვება, გადამოწმება)

პაკეტი ("openssh-server": უზრუნველყოს => დაინსტალირებული, ) სერვისი ("sshd": ჩართვა => true, უზრუნველყოს => გაშვება, საჭირო => პაკეტი["openssh-server"], )

ახლა თქვენ უნდა გამოიყენოთ ზემოაღნიშნული კონფიგურაციები შესაბამის სერვერებზე. თოჯინების პაკეტში ნაგულისხმევად შედის სპეციალური რესურსის კონფიგურაციის ფაილი. საიტი.გვ, რომელიც მდებარეობს დირექტორიაში / და ა.შ./თოჯინა/მანიფესტები. თუ რესურსის კონფიგურაციის პარამეტრები არ არის ძალიან რთული, მაშინ ისინი შეიძლება დაემატოს ამ ფაილს ხელით: მაგალითად, 3 და 4 განცხადების შიგთავსი ზემოთ.

ყველა საჭირო პროგრამის დაინსტალირებისა და გააქტიურების შემდეგ, და კონფიგურაციის ფაილების გენერირება, აუცილებელია დაარეგისტრიროთ ყველა სლავური სერვერი (კლიენტი) მთავარ საკონტროლო სერვერზე და დაადასტუროთ რეგისტრაციის ავთენტურობა ( ნიშანი), ანუ გაიაროს ერთგვარი სერტიფიცირება. სლავურ სერვერებზე რეგისტრაცია ხორციელდება შემდეგი ბრძანებით (ასევე საჭიროა სუპერმომხმარებლის უფლებები ფესვი):

თოჯინა -- ტესტი -- მიმტანი 30 -- სერვერი MASTER_SERVER_ADDRESS

Იმის მაგივრად MASTER_SERVER_ADDRESSთქვენ უნდა მიუთითოთ მთავარი საკონტროლო სერვერის რეალური მისამართი.

მას შემდეგ, რაც ყველა საჭირო კლიენტი დარეგისტრირდება, მე-6 სიაში ნაჩვენები ბრძანებები შესრულდება მთავარ საკონტროლო სერვერზე.

ჩამონათვალი 6. რეგისტრირებული კლიენტების სერტიფიცირება მთავარ საკონტროლო სერვერზე

puppetca --list # აჩვენებს რეგისტრირებული კლიენტების მისამართების სიას puppetca -- მოაწერე CLIENT_SERVER_ADDRESS # CLIENT_SERVER_ADDRESS-ის ნაცვლად, მიუთითე რეალური კლიენტის მისამართი # ბრძანება მეორდება თითოეული კლიენტის მისამართისთვის

რეგისტრაციისა და სერტიფიცირების დასრულების შემდეგ, Puppet ავტომატურად გამოიყენებს რესურსის ზემოთ აღწერილ კონფიგურაციებს რეგისტრირებულ კლიენტებზე.

# აქ ასევე იწერება სერვერის რეალური მისამართი სერვერი = MASTER_SERVER_ADDRESS

თოჯინა ახლა სრულად არის კონფიგურირებული და მუშაობს. Slave სერვერების რესურსის კონფიგურაციის ავტომატური სინქრონიზაცია შესრულდება ყოველ 30 წუთში. თქვენ შეგიძლიათ ნახოთ პროცესი ბრძანების გაშვებით:

კუდი -f /var/log/messages

დასკვნა

ამ სტატიაში ჩვენ განვიხილეთ Puppet-ის დაყენების და კონფიგურაციის პროცესი მთავარ საკონტროლო სერვერზე და კლიენტის სერვერებზე, რომელთა სტატუსზე მონიტორინგი მოხდება. ამ სერიის შემდეგი სტატია განიხილავს თოჯინების კონფიგურაციის მაგალითებს სისტემის ადმინისტრატორის საერთო ამოცანების შესასრულებლად.

Puppet-ის უფრო ეფექტურად გამოსაყენებლად, თქვენ უნდა გესმოდეთ, როგორ არის აგებული მოდულები და მანიფესტები. ეს გაკვეთილი გაგაცნობთ, თუ როგორ მუშაობს ეს Puppet კომპონენტები Ubuntu 14.04 სერვერზე LAMP სტეკის დაყენებით.

მოთხოვნები

• თოჯინების ინსტალაცია (ოსტატი და აგენტი). მეტი ამის შესახებ -.
• მინიმუმ ერთი Ubuntu 14.04 ვირტუალური სერვერის შექმნის შესაძლებლობა, რათა მოემსახუროს Puppet აგენტის კვანძს.

თოჯინების კოდის საფუძვლები

რესურსები

მარიონეტული კოდი ძირითადად შედგება რესურსებისგან. რესურსი არის კოდის ნაწილი, რომელიც აღწერს სისტემის მდგომარეობას და განსაზღვრავს მისთვის საჭირო ცვლილებებს. Მაგალითად:

მომხმარებელი ("მიტჩელი":
უზრუნველყოს => აწმყო,
uid => "1000",
gid => "1000",
shell => "/bin/bash",
მთავარი => "/home/mitchell"
}

რესურსის დეკლარაციას აქვს შემდეგი ფორმატი:

რესურსის_ტიპი ("რესურსის_სახელი"
ატრიბუტი => მნიშვნელობა
...
}

თოჯინების რესურსის ყველა ტიპის სანახავად, გაუშვით ბრძანება:

მარიონეტული რესურსი --ტიპები

თქვენ შეიტყობთ მეტი რესურსის ტიპების შესახებ ამ სახელმძღვანელოში.

მანიფესტები

მანიფესტი არის საორკესტრო სცენარი. თოჯინების პროგრამებს .pp გაფართოებით ეწოდება მანიფესტები. ნაგულისხმევი თოჯინების მანიფესტი არის /etc/puppet/manifests/site.pp.

კლასები

როგორც ნებისმიერ ჩვეულებრივ პროგრამირების ენაში, კლასები პასუხისმგებელნი არიან ორკესტრის ნაწილების ორგანიზებასა და ხელახლა გამოყენებაზე.

კლასის განმარტებაში არის კოდის ბლოკი, რომელიც აღწერს როგორ მუშაობს კლასი. კლასის განსაზღვრის შემდეგ, შეგიძლიათ გამოიყენოთ იგი manifests-ში.

კლასის განმარტებას აქვს შემდეგი ფორმატი:

კლასი მაგალითი_კლასი(
...
კოდი
...
}

ეს კოდი განსაზღვრავს example_class კლასს. თოჯინების კოდი იქნება ხვეული ბრეკეტებში.

კლასის დეკლარაცია არის ადგილი კოდში, სადაც არის კონკრეტული კლასის გამოძახება. კლასის დეკლარაციის საშუალებით, Puppet ამუშავებს მის კოდს.

კლასის დეკლარაცია შეიძლება იყოს ჩვეულებრივი და რესურსის ტიპის მიხედვით.

რეგულარული კლასის დეკლარაცია ემატება კოდს, საკვანძო სიტყვის გამოყენებით.

მოიცავს მაგალითი_კლასს

როდესაც გამოცხადებულია რესურსის ტიპად, კლასი გამოცხადებულია რესურსის ფორმატში:

კლასი ("მაგალითი_კლასი":)

ეს დეკლარაცია საშუალებას გაძლევთ დაამატოთ კლასის პარამეტრები თქვენს კოდში, რომელიც არღვევს კლასის ატრიბუტების ნაგულისხმევ მნიშვნელობებს. Მაგალითად:

კვანძი "მასპინძელი2" (
კლასი ("apache": ) # გამოიყენეთ apache მოდული
apache::vhost ( "example.com": # განსაზღვრეთ vhost რესურსი
პორტი => "80",
docroot => "/var/www/html"
}
}

მოდულები

მოდული არის წინასწარგანსაზღვრული გზით ორგანიზებული მანიფესტებისა და სხვა ფაილების ჯგუფი, რაც აადვილებს ორკესტრის ცალკეული ნაწილების გაზიარებას და ხელახლა გამოყენებას. მოდულები გვეხმარება თოჯინების კოდის ორგანიზებაში, რადგან მათი გამოყენება შესაძლებელია კოდის მრავალ მანიფესტში გამოსაყოფად.

თოჯინების მოდულები ინახება /etc/puppet/modules დირექტორიაში.

მანიფესტის დაწერა

შეგიძლიათ ივარჯიშოთ თოჯინების მანიფესტების, მოდულების და კლასების წერაში Ubuntu სერვერზე LAMP სტეკის დაყენების მაგალითის გამოყენებით (შედეგი იქნება ).

ასე რომ, Ubuntu 14.04 სერვერის ორკესტრირებისთვის და მასზე LAMP სტეკის დასაყენებლად, გჭირდებათ რესურსები შემდეგი მოქმედებებისთვის:

• apache2 პაკეტის დაყენება.
• apache2 სერვისის დაწყება.
• MySQL სერვერის პაკეტის, mysql-სერვერის ინსტალაცია.
• Mysql სერვისის დაწყება.
• php5 პაკეტის დაყენება
• PHP ტესტის სკრიპტის შექმნა, info.php.
• Apt ინდექსის განახლება თითოეული პაკეტის დაყენებამდე.

ქვემოთ ნახავთ თოჯინების კოდის სამ მაგალითს, რომლებიც შეიძლება გამოყენებულ იქნას LAMP სტეკის დაყენების მისაღწევად.

პირველი მაგალითი გასწავლით როგორ ჩაწეროთ ძირითადი მანიფესტები ერთ ფაილში. მეორე მაგალითი დაგეხმარებათ შეიკრიბოთ და გამოიყენოთ კლასი და მოდული, რომელიც დაფუძნებულია ადრე დაწერილ მანიფესტებზე. მესამე მაგალითი გაჩვენებთ, თუ როგორ გამოიყენოთ წინასწარ ჩაშენებული საჯარო მოდულები LAMP სტეკის დასაყენებლად.

შენიშვნა: ტესტირებისთვის უმჯობესია გამოიყენოთ ახალი ვირტუალური სერვერი.

მაგალითი 1: LAMP-ის დაყენება ერთი მანიფესტით

თოჯინების მანიფესტი შეიძლება დაიწეროს აგენტის კვანძზე და შემდეგ შესრულდეს მარიონეტული განაცხადის ბრძანების გამოყენებით (ამისთვის არ გჭირდებათ ოსტატისა და აგენტის დაყენება).

ამ განყოფილებაში თქვენ ისწავლით მანიფესტების დაწერას, რომლებიც გამოიყენებენ რესურსების ამ ტიპის დეკლარაციებს:

• exec: შეასრულეთ ბრძანებები.
• პაკეტი: დააინსტალირეთ პაკეტები.
• სერვისი: სერვისის მენეჯმენტი.
• ფაილი: ფაილების მართვა.

მანიფესტის შექმნა

შექმენით ახალი მანიფესტი:

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

დაამატეთ მას შემდეგი კოდი, რათა გამოაცხადოთ საჭირო რესურსები.

# გაუშვით ბრძანება "apt-get განახლება".
exec("apt-update": # რესურსი exec "apt-update"
command => "/usr/bin/apt-get განახლება" # ბრძანება, რომელსაც ეს რესურსი იმუშავებს
}
# დააინსტალირეთ apache2 პაკეტი
პაკეტი ("apache2":
მოითხოვს => Exec["apt-update"], # მოითხოვეთ "apt-update" პაკეტის დაყენებამდე
უზრუნველყოს => დაინსტალირებული,
}
# დაიწყეთ apache2 სერვისი
სერვისი ("apache2":
უზრუნველყოს => გაშვება,
}
# დააინსტალირეთ mysql სერვერი
პაკეტი ("mysql-server":
მოითხოვს => Exec["apt-update"], # მოთხოვნა "apt-update" ხელახლა ინსტალაციის გზით
უზრუნველყოს => დაინსტალირებული,
}
# დაიწყეთ mysql სერვისი
სერვისი ("mysql":
უზრუნველყოს => გაშვება,
}
# დააინსტალირეთ php5 პაკეტი
პაკეტი ("php5":
მოითხოვს => Exec ["apt-update"], # მოთხოვნა "apt-update" ინსტალაციამდე
უზრუნველყოს => დაინსტალირებული,
}
# დაიწყეთ info.php სერვისი
ფაილი ("/var/www/html/info.php":
უზრუნველყოს => ფაილი,
შინაარსი =>"", # phpinfo კოდი
მოითხოვს => პაკეტი ["apache2"], # მოთხოვნა პაკეტისთვის "apache2"
}

მანიფესტის გამოყენება

ახალი მანიფესტის გამოსაყენებლად, შეიყვანეთ ბრძანება:

სუდო თოჯინა ვრცელდება --ტესტი

ის აჩვენებს მოცულობით შედეგს, რომელიც აჩვენებს გარემოს მდგომარეობის ყველა ცვლილებას. თუ გამომავალში არ არის შეცდომები, თქვენ უნდა შეძლოთ თქვენი გარე IP მისამართის ან დომენის სახელის გახსნა თქვენს ბრაუზერში. ეკრანზე გამოჩნდება PHP ტესტის გვერდი სტეკის ინფორმაციით. ეს ნიშნავს, რომ Apache და PHP მუშაობს.

ახლა LAMP სტეკი დაინსტალირებულია სერვერზე Puppet-ის გამოყენებით.

ეს საკმაოდ მარტივი მანიფესტია, რადგან ის შეიძლება შესრულდეს აგენტზე. თუ თქვენ არ გაქვთ თოჯინების ოსტატი, სხვა აგენტის კვანძები ვერ გამოიყენებენ ამ მანიფესტს.

თოჯინების მასტერ სერვერი ამოწმებს სერვერის მდგომარეობის ცვლილებას ყოველ 30 წუთში.

მაგალითი 2: LAMP სტეკის დაყენება მოდულის გამოყენებით

ახლა სცადეთ შექმნათ მარტივი მოდული, რომელიც დაფუძნებულია წინა განყოფილებაში დაწერილი LAMP მანიფესტზე.

მოდულის შესაქმნელად შექმენით ახალი დირექტორია მოდულების დირექტორიაში (მისი სახელი უნდა ემთხვეოდეს მოდულის სახელს). ეს დირექტორია უნდა შეიცავდეს manifests დირექტორიას და init.pp ფაილს. init.pp ფაილი განსაზღვრავს Puppet კლასს (მისი სახელი ასევე უნდა ემთხვეოდეს მოდულის სახელს).

მოდულის შექმნა

გადადით Puppet Master სერვერზე და შექმენით დირექტორია სტრუქტურა მოდულისთვის:

cd /etc/თოჯინა/მოდულები
sudo mkdir -p ნათურა/მანიფესტები

შექმენით და გახსენით init.pp ფაილი რედაქტორში:

sudo vi ნათურა/მანიფესტები/init.pp

ჩადეთ ნათურის კლასი ფაილში:

კლასის ნათურა (
}

დააკოპირეთ manifest-ის შინაარსი 1-ლი განყოფილებიდან და ჩასვით ნათურის კლასის ბლოკში. ახლა თქვენ გაქვთ ნათურის კლასის განმარტება. სხვა მანიფესტებს შეეძლებათ გამოიყენონ ეს კლასი მოდულად.

შეინახეთ და დახურეთ ფაილი.

მოდულის გამოყენება მთავარ მანიფესტში

ახლა თქვენ შეგიძლიათ დააკონფიგურიროთ მთავარი მანიფესტი და გამოიყენოთ ნათურის მოდული სერვერზე LAMP სტეკის დასაყენებლად.

Puppet Master სერვერზე შეცვალეთ შემდეგი ფაილი:

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

სავარაუდოდ, ფაილი ამ მომენტში ცარიელია. დაამატეთ მას შემდეგი სტრიქონები:

კვანძის ნაგულისხმევი ( )
კვანძი "ნათურა-1" (
}

შენიშვნა: შეცვალეთ lamp-1 თქვენი Puppet აგენტის ჰოსტის სახელით, რომელზეც დასტა უნდა დააინსტალიროთ.

კვანძის ბლოკი საშუალებას გაძლევთ მიუთითოთ თოჯინების კოდი, რომელიც ვრცელდება მხოლოდ ზოგიერთ კვანძზე.

ნაგულისხმევი ბლოკი ვრცელდება ყველა აგენტის კვანძზე, რომელსაც არ აქვს ინდივიდუალური ბლოკი (დატოვეთ იგი ცარიელი). ნათურა-1 ბლოკი გამოყენებული იქნება ნათურა-1 აგენტის კვანძზე.

დაამატეთ შემდეგი ხაზი ამ ბლოკს, რომელიც იყენებს ნათურის მოდულს:

შეინახეთ და დახურეთ ფაილი.

ახლა Puppet აგენტის კვანძს შეეძლება ჩამოტვირთოს პარამეტრები ძირითადი სერვერიდან და დააინსტალიროს LAMP სტეკი. თუ გსურთ ცვლილებების შეტანა ახლავე, გაუშვით ბრძანება აგენტზე:

სუდო მარიონეტული აგენტი --ტესტი

მოდულები ყველაზე მოსახერხებელი გზაა თოჯინების კოდის ხელახლა გამოყენებისთვის. გარდა ამისა, მოდულები დაგეხმარებათ თქვენი კოდის ლოგიკურად ორგანიზებაში.

მაგალითი 3: LAMP-ის დაყენება საჯარო მოდულების გამოყენებით

MySQL მოდული გამოიყენება ანალოგიურად. დაამატეთ შემდეგი ხაზები კვანძის ბლოკში:

class ("mysql::server":
root_password => "პაროლი",
}

თქვენ ასევე შეგიძლიათ გაიაროთ MySQL მოდულის პარამეტრები.

დაამატეთ რესურსი, რომელიც დააკოპირებს info.php-ს სასურველ ადგილას. გამოიყენეთ წყაროს პარამეტრი. დაამატეთ შემდეგი ხაზები კვანძის ბლოკში:

file("info.php": # რესურსის ფაილის სახელი
გზა => "/var/www/html/info.php", # სამიზნე გზა
უზრუნველყოს => ფაილი,
მოითხოვს => კლასი ["apache"], გამოსაყენებლად # apache კლასი
წყარო => "puppet:///modules/apache/info.php", # მდებარეობა ფაილის კოპირებისთვის
}

ეს კლასის დეკლარაცია იყენებს წყაროს პარამეტრს შინაარსის ნაცვლად. ეს პარამეტრი არა მხოლოდ იყენებს ფაილის შინაარსს, არამედ აკოპირებს მას.

Puppet დააკოპირებს ფაილს puppet:///modules/apache/info.php /etc/puppet/modules/apache/files/info.php.

შეინახეთ და დახურეთ ფაილი.

შექმენით info.php ფაილი.

სუდო შ -გ "ექო""> /etc/puppet/modules/apache/files/info.php"

ახლა Puppet აგენტის კვანძს შეეძლება ჩამოტვირთოს პარამეტრები ძირითადი სერვერიდან და დააინსტალიროს LAMP სტეკი. თუ გსურთ ცვლილებების შეტანა აგენტის გარემოში ახლავე, გაუშვით ბრძანება ამ კვანძზე:

სუდო მარიონეტული აგენტი --ტესტი

ეს ბრძანება ჩამოტვირთავს ყველა განახლებას მიმდინარე კვანძისთვის და დააინსტალირებს მასზე დასტას. იმისათვის, რომ დარწმუნდეთ, რომ Apache და PHP მუშაობენ, გახსენით კვანძის IP მისამართი ან დომენი ბრაუზერში:

http://lamp_1_public_IP/info.php

დასკვნა

ახლა თქვენ გაქვთ საბაზისო ცოდნა თოჯინების მოდულებთან და მანიფესტებთან მუშაობის შესახებ. სცადეთ თავად შექმნათ მარტივი მანიფესტი და მოდული.

Puppet შესანიშნავია აპლიკაციის კონფიგურაციის ფაილების მართვისთვის.

ტეგები: ,

როდესაც თქვენს მიერ მართული სერვერების რაოდენობა ათზე ნაკლებია, იშვიათად თუ ფიქრობს ვინმე მათ ცენტრალიზებულ მენეჯმენტზე, ეს შეიძლება არ იყოს საჭირო. როდესაც არსებობს ათობით სერვერი, ცენტრალიზებული პროგრამული უზრუნველყოფა და კონფიგურაციის მართვა ძალზე სასარგებლოა. როდესაც ასობით და ათასობით სერვერია, ეს სასიცოცხლოდ მნიშვნელოვანია. ამ ტიპის მრავალი პროგრამა არსებობს, მაგალითად: Chef, CFEngine, ... ეს უკანასკნელი იქნება განხილული ამ პოსტში.

თოჯინა ითვლება ამ ტიპის ერთ-ერთ საუკეთესო გადაწყვეტად. მას იყენებენ ისეთი კომპანიები, როგორიცაა Google, Citrix და Red Hat. ეს არის Ruby პროგრამირების ენაზე დაწერილი კლიენტ-სერვერის აპლიკაცია, რომელიც განაწილებულია ორ ვერსიად:

• Puppet Open Source - სრულიად უფასო ვერსია
• Puppet Enterprise - უფასოა 10 სერვერზე, შემდეგ საჭიროა ლიცენზიები

მოდით განვიხილოთ Puppet Open Source სერვერისა და აგენტის დაყენება, რომლებიც შედის ყველაზე თანამედროვე დისტრიბუციების პაკეტებში. შემდეგ ვისაუბრებთ Ubuntu 12.04 Precise Pangolin-ზე.

თოჯინების უკანა ბოლო ე.წ თოჯინების ოსტატი, დავიწყოთ ინსტალაცია იქიდან:

:~# apt-get install puppetmaster

ახლა კი კლიენტი:

:~# apt-get install puppet

კლიენტის კონფიგურაციის ფაილში /etc/puppet/puppet.confთქვენ უნდა ისაუბროთ სერვერზე შემდეგი განყოფილების დამატებით:

Server=puppet.local report=true pluginsync=false

საწყის ეტაპზე უმჯობესია გამორთოთ pluginsync.

მოდით გავუშვათ მარიონეტული კლიენტი ისე, რომ მან შექმნას მოთხოვნა სერტიფიკატის შესახებ:

:~# puppetd --verbose --ტესტი ინფორმაცია: ახალი SSL გასაღების შექმნა linux.local ინფორმაციისთვის: სერთიფიკატის ქეშირება ca ინფორმაციისთვის: ახალი SSL სერთიფიკატის მოთხოვნის შექმნა linux.local ინფორმაციისთვის: სერთიფიკატის მოთხოვნა თითის ანაბეჭდისთვის (md5): E5: EA:AC:5B:22:9A:BA:42:B8:A1:63:9E:1F:1F:23:51 გასვლა; სერთიფიკატი ვერ მოიძებნა და ლოდინის სერთიფიკატი გამორთულია

სერვერზე, თქვენ უნდა შეამოწმოთ, რომ სერთიფიკატის მოთხოვნა მიღებულია და, თუ ასეა, გასცეთ სერთიფიკატი:

:~# puppetca -- სია "linux.local" (E5:EA:AC:5B:22:9A:BA:42:B8:A1:63:9E:1F:1F:23:51) :~# puppetca - - ხელი მოაწერეთ linux.local შეტყობინებას: ხელმოწერილი სერტიფიკატის მოთხოვნა linux.local-ისთვის: ფაილის წაშლა Puppet::SSL::CertificateRequest linux.local მისამართზე "/var/lib/puppet/ssl/ca/requests/linux.local.pem"

გაიმეორეთ წინა ნაბიჯი კლიენტზე:

:~# puppetd --verbose --ტესტის ინფორმაცია: სერტიფიკატის ქეშირება linux.local-ისთვის: მოდულის ინფორმაციის მოძიება: ქეშირება Certifikata_revocation_list ca ინფორმაციისთვის: კატალოგის ქეშირება linux.local ინფორმაციისთვის: კონფიგურაციის ვერსიის გამოყენება "1356278451" ფაილის ინფორმაცია / მდგომარეობის შექმნა var/lib/puppet/state/state.yaml შენიშვნა: დასრულებული კატალოგის გაშვება 0,02 წამში

მშვენიერია, ყველაფერი მუშაობს. გადავიდეთ პირველი მანიფესტის შექმნაზე. მანიფესტები ან კონფიგურაციები აღწერილია სპეციალურ დეკლარაციულ ენაზე. ჩვენ მაშინვე შევეჩვევით კარგ ნივთებს, გამოვიყენებთ მოდულურ სტრუქტურას და კლასებს. მაგალითად, დავწეროთ მოდული, რომელიც განაახლებს ფაილს / და ა.შ. მასპინძლებიჩვენს ყველა სერვერზე.

მოდით შევამოწმოთ სად ეძებს თოჯინა მოდულებს:

:~# თოჯინა ვრცელდება --configprint მოდულის გზა /etc/puppet/modules:/usr/share/puppet/modules

შექმენით დირექტორიები თქვენი მოდულისთვის

:~# cd /etc/puppet/modules :~# mkdir hosts; cd ჰოსტები; mkdir გამოხატავს; cd გამოიხატება

უნდა გამოიძახოთ პირველი მანიფესტი, რომელიც ასევე ცნობილია როგორც მთავარი მოდულის ფაილი init.pp

კლასის მასპინძლები ( # puppet.local host ( "puppet.local": უზრუნველყოს => "present", target => "/etc/hosts", ip => "192.168.0.1", host_aliases => "თოჯინა", ) # linux.local ჰოსტი ("linux.local": უზრუნველყოს => "present", target => "/etc/hosts", ip => "192.168.0.2", host_aliases => "linux", ) )

ნაგულისხმევად, თოჯინა ეძებს ფაილს /etc/puppet/manifests/site.ppკონფიგურაციის ჩასატვირთად, მოდით მივიყვანოთ იგი შემდეგ ფორმაში:

კვანძის ნაგულისხმევი (შეიცავს მასპინძლებს)

ჩვენ ვამოწმებთ მანიფესტს სერვერზე:

:~# თოჯინა ვრცელდება --verbose /etc/puppet/manifests/site.pp ინფორმაცია: კონფიგურაციის ვერსიის გამოყენება "1356281036" შენიშვნა: /Stage//Host/ უზრუნველყოს: შექმნილი ინფორმაცია: FileBucket დამატება (md5)შენიშვნა: /Stage// მასპინძელი/დარწმუნება: შექმნილი შეტყობინება: დასრულებული კატალოგის გაშვება 0.03 წამში

კლიენტზე:

:~# ll /etc/hosts rw-r--r-- 1 root root 290 Dec 16 19:10 /etc/hosts :~# puppetd --verbose --ტესტი ინფორმაცია: linux.local-ისთვის კატალოგის ქეშირება: ვრცელდება კონფიგურაციის ვერსია "1356283380" ინფორმაცია: FileBucket დაამატებს (md5) შენიშვნა: /Stage/Hosts/Host/ensure: შექმნილი შეტყობინება: /Stage/Hosts/Host/ უზრუნველყოს: შექმნილი შეტყობინება: დასრულებული კატალოგის გაშვება 0,04 წამში :~# ll / ა.შ. /hosts -rw-r--r-- 1 root root 551 Dec 23 20:43 /etc/hosts

მას შემდეგ რაც დავრწმუნდებით, რომ ყველაფერი მუშაობს, ჩვენ ვაძლევთ სერვისის დაწყების უფლებას /etc/default/თოჯინაშეცვლა:

# დაიწყეთ თოჯინა ჩექმაზე? START=დიახ

სერვისის დაწყება

:~# სამსახურის მარიონეტული დაწყება

Puppet გამოკითხავს puppetmaster სერვერს ყოველ 30 წუთში კონფიგურაციის ცვლილებებისთვის და, საჭიროების შემთხვევაში, დაარეგულირებს სისტემას შესაბამისად.