برای استفاده موثرتر از Puppet، باید نحوه ساخت ماژول ها و مانیفست ها را بدانید. این آموزش شما را با نحوه کار این مؤلفه‌های Puppet با راه‌اندازی یک پشته LAMP در سرور اوبونتو 14.04 آشنا می‌کند.

الزامات

• نصب عروسک (استاد و عامل). بیشتر در مورد آن -.
• امکان ایجاد حداقل یک سرور مجازی اوبونتو 14.04 برای خدمت به گره عامل Puppet.

اصول اولیه کد عروسکی

منابع

کد عروسکی بیشتر از منابع تشکیل شده است. منبع قطعه ای از کد است که وضعیت سیستم را توصیف می کند و تغییرات مورد نیاز آن را تعیین می کند. برای مثال:

کاربر ("میچل":
اطمینان => حاضر،
uid => "1000"،
gid => "1000"،
shell => "/ bin / bash",
خانه => "/ خانه / میچل"
}

یک بیانیه منبع دارای فرمت زیر است:

منبع_نوع ("نام_منبع"
ویژگی => مقدار
...
}

برای مشاهده انواع منابع Puppet دستور را وارد کنید:

منابع عروسکی --انواع

در این راهنما با انواع منابع بیشتر آشنا خواهید شد.

مانیفست ها

مانیفست یک فیلمنامه ارکستراسیون است. به برنامه های عروسکی با پسوند pp مانیفست می گویند. مانیفست پیش‌فرض Puppet /etc/puppet/manifests/site.pp است.

کلاس ها

مانند هر زبان برنامه نویسی معمولی، کلاس ها مسئول سازماندهی و استفاده مجدد از بخش هایی از یک ارکستراسیون هستند.

تعریف کلاس شامل یک بلوک کد است که نحوه عملکرد کلاس را توضیح می دهد. هنگامی که یک کلاس را تعریف کردید، می توانید از آن در مانیفست های خود استفاده کنید.

تعریف کلاس دارای فرمت زیر است:

کلاس example_class (
...
کد
...
}

این کد کلاس example_class را تعریف می کند. کد Puppet در پرانتزهای فرفری خواهد بود.

اعلان کلاس جایی است که یک کلاس خاص در کد شما فراخوانی می شود. با اعلام یک کلاس، Puppet کد آن را پردازش می کند.

یک اعلان کلاس می تواند معمولی و بر اساس نوع منبع باشد.

یک اعلان کلاس معمولی با استفاده از کلمه کلیدی include به کد اضافه می شود.

شامل example_class باشد

هنگامی که بر اساس نوع منبع اعلان می شود، کلاس در قالب منبع اعلان می شود:

کلاس ("example_class":)

این اعلان به شما امکان می دهد تا پارامترهای کلاس را به کد خود اضافه کنید که مقادیر مشخصه کلاس استاندارد را لغو می کند. برای مثال:

گره "host2" (
کلاس ("apache":) # از ماژول apache استفاده کنید
apache :: vhost ("example.com": # منبع vhost را تعریف کنید
پورت => "80"،
docroot => "/ var / www / html"
}
}

ماژول ها

ماژول مجموعه ای از مانیفست ها و فایل های دیگر است که به روشی از پیش تعریف شده سازماندهی شده اند که اشتراک گذاری و استفاده مجدد از بخش های جداگانه ارکستراسیون را آسان تر می کند. ماژول ها به شما کمک می کنند تا کد Puppet خود را سازماندهی کنید زیرا می توانید از آنها برای تقسیم کد خود به چند مانیفست استفاده کنید.

ماژول های عروسکی در دایرکتوری / etc / puppet / modules ذخیره می شوند.

نوشتن مانیفست

می توانید با استفاده از مثال نصب یک پشته LAMP روی سرور اوبونتو (در نتیجه) نوشتن مانیفست ها، ماژول ها و کلاس های عروسکی را تمرین کنید.

بنابراین، برای هماهنگ کردن سرور اوبونتو 14.04 و نصب پشته LAMP روی آن، به منابعی برای انجام کارهایی مانند این نیاز دارید:

• نصب پکیج apache2
• راه اندازی سرویس apache2
• نصب بسته سرور MySQL، mysql-server.
• راه اندازی سرویس mysql
• نصب پکیج php5
• ایجاد یک اسکریپت تست PHP، info.php.
• به روز رسانی شاخص apt قبل از نصب هر بسته.

در زیر سه نمونه کد Puppet را مشاهده خواهید کرد که با استفاده از آنها می توانید چنین راه اندازی پشته LAMP را دریافت کنید.

مثال اول به شما یاد می دهد که چگونه مانیفست های اولیه را در یک فایل بنویسید. مثال دوم به شما کمک می کند تا کلاس و ماژول را بر اساس مانیفست های نوشته شده قبلی بسازید و استفاده کنید. در مثال سوم، نحوه استفاده از ماژول های عمومی از پیش ساخته شده برای نصب پشته LAMP را خواهید آموخت.

توجه داشته باشید: بهتر است از یک سرور مجازی جدید برای تست استفاده کنید.

مثال 1: نصب LAMP با مانیفست واحد

مانیفست Puppet را می توان روی گره عامل نوشت و سپس با استفاده از دستور Puppet App اجرا کرد (برای این کار نیازی به نصب ویزارد و عامل ندارید).

در این بخش، نحوه نوشتن مانیفست هایی را یاد خواهید گرفت که از این نوع اعلان منابع استفاده می کنند:

• exec: اجرای دستورات.
• بسته: نصب بسته ها.
• خدمات: مدیریت خدمات.
• فایل: مدیریت فایل

ایجاد مانیفست

یک مانیفست جدید ایجاد کنید:

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

کد زیر را به آن اضافه کنید تا منابع مورد نیاز را اعلام کنید.

# اجرای دستور "apt-get update"
exec ("apt-update": # منبع exec "apt-update"
command => "/ usr / bin / apt-get update" # دستوری که این منبع را اجرا می کند
}
# نصب بسته apache2
بسته ("apache2":
نیاز => Exec ["apt-update"]، # درخواست "apt-update" قبل از نصب بسته
اطمینان حاصل کنید که => نصب شده است،
}
# سرویس apache2 را راه اندازی کنید
سرویس ("apache2":
اطمینان => در حال اجرا،
}
# نصب mysql-server
بسته ("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"
}

اعمال مانیفست

برای استفاده از مانیفست جدید، دستور را وارد کنید:

عروسک sudo application --test

یک نتیجه حجمی تولید می کند که تمام تغییرات در وضعیت محیط را نشان می دهد. اگر هیچ خطایی در خروجی وجود ندارد، باید بتوانید آدرس IP خارجی یا نام دامنه خود را در مرورگر باز کنید. یک صفحه تست PHP با اطلاعات پشته روی صفحه ظاهر می شود. این بدان معناست که آپاچی و PHP کار می کنند.

پشته LAMP اکنون با استفاده از Puppet بر روی سرور نصب شده است.

این یک مانیفست نسبتاً ساده است زیرا می توان آن را روی عامل اجرا کرد. اگر یک Puppet Master نداشته باشید، سایر گره‌های عامل نمی‌توانند از این مانیفست استفاده کنند.

سرور Puppet Master تغییرات وضعیت سرور را هر 30 دقیقه بررسی می کند.

مثال 2: نصب پشته LAMP با استفاده از یک ماژول

اکنون سعی کنید یک ماژول ساده بر اساس مانیفست LAMP که در قسمت قبل نوشتید ایجاد کنید.

برای ایجاد یک ماژول، یک دایرکتوری جدید در دایرکتوری modules ایجاد کنید (نام آن باید با نام ماژول مطابقت داشته باشد). این دایرکتوری باید شامل دایرکتوری manifests و فایل init.pp باشد. فایل init.pp کلاس Puppet را مشخص می کند (نام آن نیز باید با نام ماژول مطابقت داشته باشد).

ایجاد ماژول

به سرور Puppet Master بروید و یک ساختار دایرکتوری برای ماژول ایجاد کنید:

سی دی / غیره / عروسک / ماژول
لامپ sudo mkdir -p / آشکار می شود

فایل init.pp را در ویرایشگر ایجاد و باز کنید:

لامپ sudo vi / manifests / init.pp

کلاس لامپ را در فایل وارد کنید:

چراغ کلاس (
}

محتوای مانیفست را از بخش 1 کپی کرده و در بلوک کلاس لامپ قرار دهید. اکنون تعریفی برای لامپ کلاس دارید. سایر مانیفست ها می توانند از این کلاس به عنوان یک ماژول استفاده کنند.

ذخیره کنید و فایل را ببندید.

استفاده از یک ماژول در مانیفست اصلی

اکنون می توانید مانیفست اصلی را تنظیم کنید و از ماژول لامپ برای نصب پشته LAMP روی سرور استفاده کنید.

در سرور Puppet Master فایل زیر را ویرایش کنید:

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

به احتمال زیاد، فایل در حال حاضر خالی است. خطوط زیر را به آن اضافه کنید:

پیش فرض گره ()
گره "لامپ-1" (
}

توجه داشته باشید: لامپ-1 را با نام میزبان عامل Puppet خود در جایی که می خواهید پشته را نصب کنید جایگزین کنید.

بلوک گره به شما امکان می دهد کد Puppet را مشخص کنید که فقط برای برخی از گره ها اعمال می شود.

بلوک پیش‌فرض برای تمام گره‌های عاملی که بلوک جداگانه ندارند اعمال می‌شود (آن را خالی بگذارید). بلوک لامپ-1 روی گره عامل لامپ-1 اعمال خواهد شد.

خط زیر را به این بلوک اضافه کنید که از ماژول لامپ استفاده می کند:

ذخیره کنید و فایل را ببندید.

Node agent Puppet اکنون می تواند تنظیمات را از سرور اصلی دانلود کرده و پشته LAMP را نصب کند. اگر می‌خواهید همین الان تغییراتی ایجاد کنید، دستور را روی عامل اجرا کنید:

سودو عامل عروسکی --تست

ماژول ها راحت ترین راه برای استفاده مجدد از کد Puppet هستند. علاوه بر این، ماژول ها به شما کمک می کنند تا کد خود را به طور منطقی سازماندهی کنید.

مثال 3: نصب LAMP با استفاده از ماژول های در دسترس عموم

ماژول MySQL به روشی مشابه استفاده می شود. خطوط زیر را به بلوک گره اضافه کنید:

کلاس ("mysql :: سرور":
root_password => "رمز عبور"،
}

همچنین می توانید پارامترها را به یک ماژول MySQL ارسال کنید.

منبعی اضافه کنید که info.php را در مکان صحیح کپی کند. از پارامتر منبع استفاده کنید. خطوط زیر را به بلوک گره اضافه کنید:

فایل ("info.php": # نام فایل منبع
path => "/var/www/html/info.php"، # مسیر هدف
اطمینان => فایل،
نیاز => کلاس ["apache"]، # کلاس apache برای استفاده
منبع => "puppet: ///modules/apache/info.php"، # جایی که می خواهید فایل را کپی کنید
}

این اعلان کلاس از پارامتر منبع به جای پارامتر محتوا استفاده می کند. این گزینه نه تنها از محتوای فایل استفاده می کند، بلکه آن را کپی می کند.

فایل عروسکی: ///modules/apache/info.php Puppet به /etc/puppet/modules/apache/files/info.php کپی می‌شود.

ذخیره کنید و فایل را ببندید.

فایل info.php ایجاد کنید.

sudo sh -c "echo""> /etc/puppet/modules/apache/files/info.php"

Node agent Puppet اکنون می تواند تنظیمات را از سرور اصلی دانلود کرده و پشته LAMP را نصب کند. اگر می خواهید در حال حاضر تغییراتی در محیط عامل ایجاد کنید، دستور را در این گره اجرا کنید:

سودو عامل عروسکی --تست

این دستور تمام به‌روزرسانی‌های گره فعلی را دانلود کرده و پشته را روی آن نصب می‌کند. برای تأیید اینکه Apache و PHP کار می کنند، آدرس IP یا دامنه گره را در مرورگر باز کنید:

http://lamp_1_public_IP/info.php

نتیجه

شما اکنون دانش اولیه ماژول ها و مانیفست های Puppet را دارید. سعی کنید خودتان یک مانیفست و ماژول ساده ایجاد کنید.

Puppet برای مدیریت فایل های پیکربندی برنامه عالی است.

برچسب ها:،

عروسک خیمه شب بازییک فریمورک بین پلتفرمی است که به sysadmin ها اجازه می دهد تا کارهای رایج را با استفاده از کد انجام دهند. این کد به شما امکان می دهد کارهای مختلفی از نصب برنامه های جدید گرفته تا بررسی مجوزهای فایل یا به روز رسانی حساب های کاربری را انجام دهید. عروسک خیمه شب بازینه تنها در طول نصب اولیه سیستم، بلکه در کل چرخه عمر سیستم عالی است. در بیشتر موارد عروسک خیمه شب بازیدر پیکربندی مشتری / سرور استفاده می شود.

این بخش نصب و پیکربندی را نشان می دهد عروسک خیمه شب بازیدر پیکربندی مشتری / سرور این مثال ساده نحوه نصب را نشان می دهد آپاچیاستفاده كردن عروسک خیمه شب بازی.

نصب و راه اندازی

برای نصب عروسک خیمه شب بازیدر ترمینال وارد کنید:

Sudo apt-get install puppetmaster

در ماشین مشتری (یا ماشین‌ها) وارد کنید:

عروسک نصب Sudo apt-get

سفارشی سازی

قبل از پیکربندی عروسک، ممکن است بخواهید یک ورودی اضافه کنید DNS CNAMEبرای puppet.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 عروسک خیمه شب بازی

آدرس‌های IP و نام‌های دامنه مثال را با آدرس‌های واقعی و نام سرور و مشتری خود جایگزین کنید.

حالا بیایید منابعی را برای آن تنظیم کنیم آپاچی 2... یک فایل ایجاد کنید /etc/puppet/manifests/site.ppحاوی موارد زیر:

بسته ("apache2": اطمینان => نصب شده) سرویس ("apache2": اطمینان => درست، فعال کردن => درست، نیاز => بسته ["apache2"])

گره "meercat02.example.com" (شامل apache2)

جایگزین کردن meercat02.example.comبه نام واقعی شما عروسک خیمه شب بازیمشتری.

مرحله نهایی برای این ساده است عروسک خیمه شب بازیسرور در حال راه اندازی مجدد سرویس است:

Sudo /etc/init.d/puppetmaster راه اندازی مجدد

در حال حاضر در عروسک خیمه شب بازیهمه چیز روی سرور پیکربندی شده است و زمان پیکربندی کلاینت فرا رسیده است.

ابتدا بیایید سرویس را راه اندازی کنیم عروسک خیمه شب بازیعامل برای اجرا ویرایش / غیره / پیش فرض / عروسک به جای مقدار شروع کنیدبر روی آره:

Sudo /etc/init.d/puppet start

بازگشت به عروسک خیمه شب بازیسرور برای امضای گواهی مشتری با استفاده از دستور:

Sudo puppetca --sign meercat02.example.com

بررسی / var / log / syslogبرای هر گونه خطای پیکربندی اگر همه چیز خوب پیش رفت، بسته آپاچی 2و وابستگی های آن بر روی نصب خواهد شد عروسک خیمه شب بازیمشتری.

این مثال بسیار ساده است و ویژگی ها و مزایای زیادی را نشان نمی دهد. عروسک خیمه شب بازی... برای اطلاعات بیشتر ببین

مدیریت تعداد زیادی از سیستم های یونیکس راحت نیست. برای تغییر یک پارامتر، مدیر باید با هر دستگاه تماس بگیرد، اسکریپت ها فقط تا حدی می توانند کمک کنند، و نه در همه شرایط.

مسلماً مدیران شبکه ویندوز در موقعیت بهتری قرار دارند. کافی است تنظیمات خط‌مشی‌های گروه را تغییر دهید و پس از مدتی همه رایانه‌های موجود در شبکه، از جمله آن‌هایی که سیستم‌عامل اخیراً نصب شده‌اند، در مورد نوآوری «یاد بگیرند»، البته اگر به آنها مربوط می‌شود. با نگاهی به تاریخ طولانی یونیکس، متوجه خواهید شد که چیزی شبیه به این اتفاق نیفتاده است. راه حل هایی مانند kickstart وجود دارد که به نصب اولیه سیستم عامل کمک می کند، اما بهینه سازی بیشتر تلاش زیادی می کند. راه حل های تجاری مانند BladeLogic و OpsWare فقط تا حدی مشکل اتوماسیون تنظیمات را حل می کنند، مزیت اصلی آنها وجود یک رابط گرافیکی است و فقط می توان آنها را در سازمان های بزرگ خریداری کرد. البته پروژه‌هایی وجود دارند که راه‌حل‌های رایگان ارائه می‌دهند، اما در تمام مدت وجودشان، نتوانسته‌اند یک جامعه بزرگ ایجاد کنند. به عنوان مثال، Cfengine در بین مدیران چندان محبوب نیست، اگرچه علاوه بر لینوکس، می توان از آن در * BSD، Windows و Mac OS X استفاده کرد. شاید این به دلیل پیچیدگی نسبی ایجاد تنظیمات باشد. هنگام توصیف وظایف، باید ویژگی های هر سیستم خاص را در نظر بگیرید و هنگام اجرای دستورات، دنباله اقدامات را به صورت دستی کنترل کنید. یعنی مدیر باید به خاطر داشته باشد که برای برخی از سیستم ها باید adduser را برای دیگران useradd بنویسید، مکان فایل ها را در سیستم های مختلف در نظر بگیرید و غیره. این امر فرآیند نوشتن دستورات را با ترتیب بزرگی پیچیده می کند، ایجاد پیکربندی صحیح در پرواز بسیار دشوار است و خواندن تنظیمات ایجاد شده پس از مدتی عملا غیرممکن است. با وجود مجوز GPL، Cfengine در واقع یک پروژه تک نفره است که بر همه تغییرات نظارت می کند و علاقه زیادی به ایجاد یک جامعه باز ندارد. در نتیجه، قابلیت‌های cfengine برای توسعه‌دهنده کاملاً رضایت‌بخش است، اما برای مدیران دیگر این یک سردرد غیر ضروری است. برای بهبود cfengine، افزونه‌های مختلفی توسط توسعه‌دهندگان شخص ثالث ایجاد شد که اغلب اوضاع را بدتر می‌کرد. نویسنده چندین ماژول از این دست برای cfengine، Luke Kanies، در نهایت تصمیم گرفت ابزار مشابهی را توسعه دهد، اما بسیاری از کاستی‌های cfengine را نداشت.

ویژگی های عروسکی

Puppet مانند cfengine یک سیستم کلاینت-سرور با استفاده از یک زبان اجباری برای توصیف وظایف و یک کتابخانه برای اجرای آنها است. مشتریان به صورت دوره ای (30 دقیقه به طور پیش فرض) به سرور مرکزی متصل می شوند و آخرین پیکربندی را دریافت می کنند. در صورتی که تنظیمات دریافتی با وضعیت سیستم مطابقت نداشته باشد، اجرا می شود و در صورت نیاز گزارشی از عملیات انجام شده به سرور ارسال می شود. سرور می تواند پیام ها را در syslog یا یک فایل ذخیره کند، یک برنامه RRD ایجاد کند، آنها را به ایمیل مشخص شده ارسال کند. لایه‌های اضافی انتزاع Transaction و Resource حداکثر سازگاری را با تنظیمات و برنامه‌های موجود فراهم می‌کنند و به شما این امکان را می‌دهند که بر روی اشیاء سیستم تمرکز کنید بدون اینکه نگران تفاوت در اجرا و شرح دستورات دقیق و فرمت‌های فایل باشید. مدیر فقط با نوع شی کار می کند، 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، این زبان به شما اجازه می دهد تا دسترسی به تمام منابع مشابه را در هر سیستمی در یک محیط ناهمگن ساده کنید. توصیف یک منبع معمولاً از نام، نوع و ویژگی ها تشکیل شده است. به عنوان مثال، اجازه دهید به فایل / etc / passwd اشاره کنیم و ویژگی های آن را تنظیم کنیم:

فایل ("/ etc / passwd":

مالک => ریشه،

گروه => ریشه،

اکنون کلاینت هایی که به سرور متصل می شوند فایل / etc / passwd را کپی کرده و ویژگی های مشخص شده را تنظیم می کنند. منابع متعدد را می توان با جدا کردن آنها با نقطه ویرگول در یک قانون تعریف کرد. و اگر فایل کانفیگ استفاده شده در سرور با کلاینت فرق دارد یا اصلا استفاده نمی شود چه باید کرد؟ به عنوان مثال، این وضعیت ممکن است هنگام تنظیم اتصالات VPN ایجاد شود. در این حالت باید با استفاده از دستور منبع به فایل اشاره کنید. دو گزینه وجود دارد، طبق معمول برای تعیین مسیر فایل دیگر، دو URI پروتکل نیز پشتیبانی می شوند: فایل و عروسک. در حالت اول، از پیوند به یک سرور NFS خارجی استفاده می شود، در نسخه دوم، یک سرویس NFS مانند بر روی سرور Puppet راه اندازی می شود که منابع را صادر می کند. در مورد دوم، به طور پیش فرض، مسیر نسبت به دایرکتوری ریشه عروسکی - / etc / puppet مشخص می شود. یعنی، عروسک پیوند: //server.domain.com/config/sshd_config با فایل / etc / puppet / config / sshd_config مطابقت دارد. شما می توانید این دایرکتوری را با استفاده از دستور filebucket لغو کنید، اگرچه استفاده از بخشی به همین نام در فایل /etc/puppet/fileserver.conf صحیح تر است. در این صورت می توانید دسترسی به سرویس را فقط از آدرس های خاصی محدود کنید. به عنوان مثال، اجازه دهید بخش تنظیمات را توضیح دهیم.

مسیر / var / عروسک / پیکربندی

اجازه * .domain.com

اجازه 192.168.0. *

اجازه 192.168.1.0/24

انکار * .wireless.domain.com

و سپس هنگام توضیح منبع به این بخش مراجعه کنید.

منبع => "Puppet: //server.domain.com/config/sshd_config"

نام منبع قبل از دو نقطه ظاهر می شود. در ساده ترین موارد، به سادگی می توانید به عنوان یک نام مشخص کنید، بهتر است از نام مستعار یا متغیرها استفاده کنید. نام مستعار با استفاده از دستور مستعار تنظیم می شود. مسیر کامل فایل در پیکربندی های پیچیده تر

فایل ("/ etc / passwd":

نام مستعار => passwd

گزینه دیگری برای ایجاد نام مستعار در مواردی که باید با سیستم عامل های مختلف سر و کار داشته باشید مناسب است. به عنوان مثال، بیایید یک منبع برای توصیف فایل sshd_config ایجاد کنیم:

فایل (sshdconfig:

نام => سیستم عامل $؟ (

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

پیش فرض => "/ etc / ssh / sshd_config"

در این مثال با یک انتخاب روبرو هستیم. فایل برای Solaris به طور جداگانه مشخص شده است، برای بقیه فایل / etc / ssh / sshd_config انتخاب خواهد شد. اکنون این منبع به صورت sshdconfig قابل دسترسی است، بسته به سیستم عامل، مسیر صحیح انتخاب خواهد شد. به عنوان مثال، اجازه دهید نشان دهیم که اگر دیمون sshd در حال اجرا باشد و یک فایل جدید دریافت شود، سرویس باید دوباره راه اندازی شود.

اطمینان => درست است،

اشتراک => فایل

معمولاً هنگام کار با داده های کاربر از متغیرها استفاده می شود. به عنوان مثال، ما مکان دایرکتوری های خانگی کاربر را شرح می دهیم:

$ homeroot = "/ home"

اکنون فایل های یک کاربر خاص به عنوان قابل دسترسی است

$ (homeroot) / نام $

پارامتر نام $ با نام حساب کاربر پر می شود. در برخی موارد، تعریف یک مقدار پیش فرض برای یک نوع خاص راحت است. به عنوان مثال، برای نوع exec، دایرکتوری ها اغلب مشخص می شوند که در آنها باید به دنبال یک فایل اجرایی بگردید:

Exec (مسیر => "/ usr / bin: / bin: / usr / sbin: / sbin")

در این صورت، اگر نیاز دارید به چندین فایل و دایرکتوری پیوست شده اشاره کنید، می توانید از پارامتر Recurse استفاده کنید.

فایل ("/etc/apache2/conf.d":

منبع => "عروسک: // عروسک: //server.domain.com/config/apache/conf.d"،

بازگشت => "درست"

چندین منبع را می توان در کلاس ها یا تعاریف ترکیب کرد. کلاس ها توضیحات کاملی از یک سیستم یا سرویس هستند و به صورت مجزا مورد استفاده قرار می گیرند.

"/ Etc / passwd": مالک => ریشه، گروه => ریشه، حالت => 644;

"/ Etc / shadow": مالک => ریشه، گروه => ریشه، حالت => 440

مانند زبان های شی گرا، کلاس ها را می توان باطل کرد. به عنوان مثال، در FreeBSD، گروهی که این فایل ها را در اختیار دارد چرخ است. بنابراین، برای اینکه منبع را به طور کامل بازنویسی نکنیم، یک کلاس freebsd جدید ایجاد می کنیم که از کلاس لینوکس به ارث می رسد:

کلاس freebsd لینوکس را به ارث می برد (

فایل ["/ etc / passwd"] (group => wheel);

فایل ["/ etc / shadow"] (گروه => چرخ)

برای راحتی، همه کلاس ها را می توان در یک فایل جداگانه قرار داد که می تواند همراه با دستورالعمل include باشد. تعاریف می توانند چندین پارامتر را به عنوان آرگومان در نظر بگیرند، اما از وراثت پشتیبانی نمی کنند و زمانی استفاده می شوند که شما نیاز به توصیف اشیاء قابل استفاده مجدد دارید. به عنوان مثال، اجازه دهید فهرست اصلی کاربر و دستورات مورد نیاز برای ایجاد یک حساب کاربری جدید را تعریف کنیم.

user_homedir (گروه $، $ نام کامل، $ ingroups) را تعریف کنید (

کاربر ("$ name":

اطمینان => حاضر،

نظر => "$ نام کامل"،

gid => "گروه $"،

گروه => $ درون گروه،

عضویت => حداقل،

shell => "/ bin / bash",

خانه => "/ خانه / نام $"،

نیاز => گروه [گروه $]،

exec ("$ name homedir":

فرمان => “/ bin / cp -R / etc / skel / home / $ name; / bin / chown -R $ نام: $ group / home / $ name "،

ایجاد => "/ خانه / نام $"،

نیاز => کاربر [$ name]،

اکنون برای ایجاد یک حساب کاربری جدید، کافیست به user_homedir بروید.

user_homedir ("sergej":

گروه => "سرگژ"،

نام کامل => "Sergej Jaremchuk"،

ingroups => ["رسانه"، "ادمین]

توضیحات جداگانه ای از گره ها (گره) وجود دارد که از وراثت و همچنین کلاس ها پشتیبانی می کنند. هنگامی که کلاینت به سرور Puppet متصل می شود، قسمت گره مربوطه جستجو می شود و تنظیمات خاصی برای این کامپیوتر نمایش داده می شود. می توانید از پیش فرض گره برای توصیف همه سیستم های دیگر استفاده کنید. شرح همه انواع در سند "مرجع نوع" آمده است، که در هر صورت باید با آن آشنا شوید، حداقل برای درک تمام ویژگی های زبان عروسکی. انواع مختلف به شما امکان می دهد دستورات مشخص شده را اجرا کنید، از جمله زمانی که شرایط خاصی برآورده می شود (به عنوان مثال، تغییر فایل پیکربندی)، کار با cron، اطلاعات کاربری و گروه های کاربری، رایانه ها، نصب منابع، شروع و توقف خدمات، نصب، به روز رسانی و حذف بسته ها، کار با کلیدهای SSH، مناطق Solaris و غیره. به همین راحتی می توان لیست بسته هایی را که در توزیع ها با استفاده از apt به روز می شوند، روزانه بین ساعت 2 تا 4 دریافت کرد.

برنامه (روزانه:

دوره => روزانه،

محدوده =>

exec ("/ usr / bin / به روز رسانی apt-get":

برنامه => روزانه

در این مدت، هر سیستم فقط یک بار به روز می شود و پس از آن کار انجام شده در نظر گرفته می شود و از رایانه مشتری حذف می شود. زبان عروسکی از دیگر ساختارهای آشنا پشتیبانی می کند: شرایط، توابع، آرایه ها، نظرات و موارد مشابه.

نصب عروسک

Puppet به Ruby (> = 1.8.1) با پشتیبانی OpenSSL و کتابخانه های XMLRPC و همچنین کتابخانه Faster نیاز دارد. http://reductivelabs.com/projects/facter]. مخزن اوبونتو 7.04 مورد استفاده در نصب آزمایشی از قبل شامل بسته توله سگ است.

$ sudo apt-cache عروسک جستجو

عروسکی - مدیریت پیکربندی متمرکز برای شبکه ها

Puppetmaster - دیمون کنترل مدیریت پیکربندی متمرکز

در حین نصب، تمام وابستگی های بسته لازم نصب می شوند: facter libopenssl-ruby libxmlrpc-ruby.

$ sudo apt-get install puppet puppetmaster

با دستور می توانید کتابخانه های Ruby را بررسی کنید.

$ ruby ​​‎ -ropenssl -e "می‌گذارد: بله"

~ $ ruby ​​‎ -rxmlrpc / client -e "می‌گذارد: بله"

اگر هیچ خطایی دریافت نشد، همه چیزهایی که نیاز دارید قبلاً گنجانده شده است. فایل هایی که پیکربندی سیستم مورد نظر را در اصطلاح Puppet توصیف می کنند مانیفست نامیده می شوند. هنگام راه‌اندازی، دیمون سعی می‌کند فایل /etc/puppet/manifests/site.pp را بخواند، در صورت عدم وجود، یک پیام هشدار صادر می‌کند. هنگام آزمایش، می‌توانید به دیمون بگویید در حالت مستقلی کار کند که در آن مانیفست مورد نیاز نیست

$ sudo / usr / bin / puppetmasterd —nonodes

در صورت لزوم، می توانید فایل های دیگر را به عنوان مثال با توضیحات کلاس به site.pp متصل کنید. برای اجرای آزمایشی می توانید ساده ترین دستور را در این فایل وارد کنید.

فایل ("/ etc / sudoers":

مالک => ریشه،

گروه => ریشه،

تمام فایل های پیکربندی هم برای سرور و هم برای کلاینت در / etc / puppet قرار دارند. فایل fileserver.conf که در بالا در مورد آن صحبت کردیم اختیاری است و تنها در صورتی استفاده می شود که Puppet به عنوان یک سرور فایل نیز کار کند. در اوبونتو، این فایل زیر شاخه / etc / puppet / files را صادر می کند. دایرکتوری فرعی ssl حاوی گواهینامه ها و کلیدهایی است که برای رمزگذاری در طول اتصالات سرویس گیرنده استفاده می شود. اولین باری که puppetmasterd را راه اندازی می کنید، کلیدها به طور خودکار ایجاد می شوند، می توانید آنها را به صورت دستی با دستور ایجاد کنید.

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

فایل های 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 puppetca --list

nomad.grinder.com

و گواهی مشتری را امضا می کنیم.

$ sudo puppetca –sign nomad.grinder.com

اکنون مشتری می تواند آزادانه به سرور متصل شود و تنظیمات را دریافت کند.

متأسفانه نمایش تمام قابلیت های Puppet در محدوده مقاله به سادگی امکان پذیر نیست. اما همانطور که می بینید، این یک ابزار کاربردی و انعطاف پذیر است که به شما امکان می دهد اکثر وظایف مدیریت همزمان تعداد زیادی سیستم را حل کنید. اگر به دلیل شغل خود مجبور به پیکربندی چندین سیستم هستید. و مهمتر از همه، این پروژه موفق شده است یک جامعه کوچک، اما دائماً در حال رشد را جمع آوری کند. پس بیایید امیدوار باشیم که یک ایده خوب اجازه نداشته باشد بمیرد یا دور شود.

کمی شعر.به نظر می رسد که کل چرخه باید با این مقاله شروع شود، اما همچنان مخاطبان هدف، کاربران باتجربه تر محصولات آزمایشگاه های عروسکی منبع باز هستند که از ماژول های انفرادی کمی یکپارچه با Puppet Forge راضی نیستند. مانند هر مورد دیگری "کتابخانه در مقابل چارچوب"، بازپرداخت از جهان بینی نویسنده راه حل یکپارچه پیروی می کند.

کمی در مورد نحوه کار عروسک

Puppet در درجه اول یک زبان خاص برای تعریف بیانی وضعیت نهایی سیستم است. برای مقایسه، GNU Makefile بسیار مناسب است، جایی که، علاوه بر توصیف مستقیم وابستگی‌ها، می‌توان به طور کامل تقلب کرد.

انتزاع عروسکی تقریباً به شرح زیر است ( شکستن الگوها - هر چیزی را که در مورد اصطلاحات برنامه نویسی می دانستید فراموش کنید!).

• گرهمجموعه ای از تنظیمات برای یک سیستم هدف خاص است. در واقع این یک مورد خاص از کلاس است.
• کلاسمجموعه ای از منطق اعلامی است که در پیکربندی گره یا کلاس های دیگر گنجانده شده است. کلاس هیچ نمونه یا متد ندارد، اما دارای پارامترها و متغیرهایی است که در منطق تعریف شده اند. در واقع، این بیشتر رویه‌ای است که می‌تواند رویه دیگری را با ایجاد کدهای بی‌اهمیت و نه دامنه متغیر کاملاً بی‌اهمیت به ارث ببرد.
• نوع (نوع)- اما این در حال حاضر بیشتر شبیه یک کلاس کلاسیک به نظر می رسد - قرار است نمونه هایی با نام و پارامترهای قطعاً داده شده داشته باشد، اما نه چیزی بیشتر. یک پیاده‌سازی مشخص از یک نوع را می‌توان به‌عنوان یک اسکریپت عروسکی از طریق تعریف، که نمونه‌هایی از انواع دیگر را ایجاد می‌کند، یا به‌عنوان یک پسوند روبی با پروازی از تخیل نوشت.
• منبع- در واقع، اینها نمونه هایی از Types هستند. نام هر منبع در یک نوع خاص در یک پیکربندی گره (دایرکتوری) منحصر به فرد است.
• متغیرها- خوب، خلاصه، اینها ثابت هستند ... قبل از Puppet 4، دامنه آنها حتی بدتر بود. اکنون کافی است: برای استفاده از خارج از محل تعریف، یک شناسه کاملاً واجد شرایط باید مشخص شود، به جز در مورد ارث بری کلاس.

Puppet را می توان برای استقرار محلی بدون شبکه و زیرساخت مرتبط استفاده کرد. این می تواند برای ایجاد تصاویر ظروف استفاده شود. حتی یک سری از مدافعان برای رها کردن یک سرور متمرکز وجود دارد.

از نظر ایدئولوژیک درست، زیرساخت Puppet شامل یک عامل - یک سرویس ممتاز در سیستم هدف و یک سرور است که دستورالعمل‌های ارزشمندی را در قالب فهرست‌های منابع اعلامی در صورت درخواست از عوامل صادر می‌کند. امنیت در سطح زیرساخت کلید عمومی خصوصی (X.509) اجرا می شود. به عبارت ساده، همان مکانیسم‌هایی که در HTTPS وجود دارد، اما با CA خاص خود و تأیید گواهی اجباری مشتری.

در یک شکل ساده، روش استقرار به این صورت است:

1. پردازش TLS و X.509 (ایجاد اتصال، به‌روزرسانی CRL، بررسی محدودیت‌های گواهی، و غیره)
2. عامل، مولدهای واقعیت را از سرور با حافظه پنهان و همه چیز دریافت می کند (به طور دقیق تر، همه چیز را از lib / پوشه ها در ماژول ها خارج می کند). اضافه کردن اسکریپت روبی خود برای جمع آوری اطلاعات مورد علاقه دشوار نیست.
3. عامل اطلاعات مربوط به سیستم مورد نظر را جمع آوری کرده و به سرور ارسال می کند. همه حقایق را می توان با دست از طریق چالش حقایق عروسکی بررسی کرد. این حقایق به عنوان متغیرهای جهانی در دسترس هستند.
4. سرور یک فهرست منبع را کامپایل می کند و آن را برای عامل ارسال می کند. در زیر این یک لایه کامل از مفاهیم مختلف نهفته است.
5. عامل هر آنچه را که نیاز دارد از سرور بیرون می کشد و سیستم را به فرم مشخص شده می آورد. در عین حال، خود عامل نمی داند چگونه با منابع برخورد کند، بر اجرای ارائه دهنده "s" (ترجمه معنایی "مترجم" خواهد بود، نه ارائه دهنده) انواع خاصی از منابع متکی است. ارائه دهندگان استاندارد هستند و در بسته های Puppet گنجانده شده اند و بقیه از ماژول ها خارج می شوند.

برای لذت بردن از تمام لذت ها، نان های اضافی به شکل زیر وجود دارد:

• مدول- مجموعه ای از اسکریپت های نمایشی Puppet، پسوندهای Ruby برای Puppet، فایل ها، قالب های فایل، داده های Hiera و موارد دیگر. اصطلاح صحیح تر «بسته» است.
• محیط- مجموعه ای از اسکریپت ها، ماژول ها و داده های Hiera. با پیچیدگی زیرساخت، به ناچار لازم بود پیکربندی بیشتر از تقسیم استاندارد به گره ها تقسیم شود. اساساً، این برای نوآوری‌های آزمایشی و کنترل دسترسی پیش پا افتاده (زمانی که همه مدیران به تمام گره‌های زیرساخت فناوری اطلاعات دسترسی ندارند) مورد نیاز است.
• هیرا- پایگاه داده سلسله مراتبی این فرمول می تواند بسیار ترسناک باشد. احتمالاً به همین دلیل است که در اسناد نسخه های بعدی تغییر کرده است. در واقع، این یک مکانیسم بسیار ساده و راحت برای کشیدن پیکربندی از فایل های YAML یا JSON است. سلسله مراتب شامل توانایی تعیین ترتیبی است که در آن چندین فایل پیکربندی خوانده می شوند - یعنی. سلسله مراتب / اولویت این فایل ها.
  • علاوه بر کشیدن داده‌ها با فراخوانی تابع، Puppet پارامترهای کلاس پیش‌فرض را می‌کشد که برجسته‌ترین نقطه است.
  • البته Hiera از درون یابی واقعیت و حتی فراخوانی توابع ویژه پشتیبانی می کند.
  • Puppet 4.3 دوباره همان عملکرد را اجرا کرد تا نه تنها از پایگاه داده جهانی، بلکه از پایگاه داده محلی برای محیط و ماژول نیز پشتیبانی کند، اگرچه نویسنده قبلاً چندین مشکل در اجرای آنها پیدا کرده است (PUP-5983، PUP-5952 و PUP-5899). ) که فورا توسط آزمایشگاه عروسکی رفع شد.
  • چندین استراتژی برای کشیدن مقادیر از همه فایل ها در امتداد سلسله مراتب پشتیبانی می شود:
    • اول - اولین مقداری که در اولویت قرار می گیرد برگردانده می شود
    • منحصر به فرد - تمام مقادیر را در یک آرایه یک بعدی جمع آوری می کند و موارد تکراری را حذف می کند
    • هش - همه هش های YAML یافت شده را به هم متصل می کند. کلیدهای تکراری بر اساس اولویت انتخاب می شوند.
    • عمیق - اساسا یک نوع بازگشتی از هش
  • زیبایی این است که استراتژی واکشی را می توان در هنگام فراخوانی تابع lookup () مشخص کرد، زیرا و در هر فایل سلسله مراتبی از طریق کلید ویژه lookup_options که بطور فعال در ماژول cfnetwork استفاده می شود.
• PuppetDB- در واقع، لایه ای از منطق تجاری در اطراف یک پایگاه داده رابطه ای (PostgreSQL) است که به شما امکان می دهد گزارش های حقایق و استقرارهای انجام شده را ذخیره کنید و منابع را برای وارد کردن بعدی به فهرست ها در سایر گره ها یا انتخاب از طریق توابع ویژه صادر کنید. همچنین یک پوزه وب به شکل داشبورد عروسکی وجود دارد.
• X.509 PKI- زیرساخت گواهینامه ها که قبلاً ذکر شد، که استفاده از آن برای سایر خدمات بدون نیاز به مدیریت زیرساخت جداگانه بسیار راحت است.
• MCCollective- به ظاهر یک چیز مفید برای راه اندازی کار مبتنی بر رویداد در مزرعه سرور است، اما نویسنده به امنیت یک راه حل خاص اعتماد ندارد.
• عروسک ساز- یک منطقه باز برای انتشار و دانلود ماژول ها.
• برخی ویژگی های دیگر در قالب کنترل دستگاه های خارجی مانند تجهیزات سیسکو و استقرار بر روی فلز خالی، اما این داستان دیگری است.

نکات ایمنی و دسترسی

لازم است درک کنیم که سرور عروسکی به یک آسیب پذیری کل زیرساخت فناوری اطلاعات تبدیل می شود، زیرا پیکربندی نهایی تمام سیستم ها را تعیین می کند. در موارد خاص، انجام جداسازی منطقی است - یک سرور جداگانه برای عناصر زیرساخت حیاتی با دسترسی بسیار محدود و به روز رسانی دستی، و دوم برای هر چیز دیگری.

در دسترس بودن Puppet Server توانایی مدیریت کل زیرساخت را تعیین می کند. منطقی است که سرور عروسکی را در یک ماشین مجازی در یک ابر شخص ثالث قابل اعتمادتر و سریع تر از قابلیت های خود میزبانی کنید. از طرف دیگر، چندین سرور باید نصب شوند.

در هر صورت نباید سرویس های دیگری را روی سیستم نصب کنید که سرور عروسکی با زنگ و سوت در آن مستقر می شود. مجازی سازی و کانتینری سازی به شما کمک می کند.

چند مستر (چند سرور عروسکی مستقل)

• در این مورد، تنها یک سرور به عنوان یک CA (مرجع صدور گواهی) عمل می کند - عدم دسترسی به آن به این معنی است که اضافه کردن گره های جدید غیرممکن است.
  • Puppet به فریمورک های شخص ثالث X.509 اجازه می دهد تا در صورت کار نکردن داخلی، استفاده شوند.
• تمام تنظیمات (محیط) باید در کنترل منبع نگه داشته شوند و در هر سرور به طور همزمان مستقر شوند.
• تنها چیزی که مشترک است پایگاه داده PostgreSQL است که سازماندهی در دسترس بودن بالای آن از حوصله این مقاله خارج است.
• ماژول cfpuppetserver از نصب سرور اصلی (با CA) و ثانویه پشتیبانی می کند.

چه تغییر قابل توجهی نسبت به نسخه های قدیمی تر

سازنده توضیحات کامل دارد.

• همه سرویس ها به JVM، JRuby و Jetty منتقل شده اند. در پس مزایای آشکار ادغام، معایبی نیز از نظر مصرف حافظه وجود دارد.
• توابع لامبدا برای پردازش مجموعه ها اضافه شده است - اکنون دیگر نیازی به برش عصا در Ruby یا چرخاندن از طریق create_resources نیست ()
• یک ابزار قالب EPP ظاهر شده است - اساساً همان ERB، اما با Puppet DSL به جای Ruby،
• ساختار دایرکتوری فایل پیکربندی پیش فرض تغییرات زیادی کرده است
• پشتیبانی از ارائه دهندگان داده برای محیط ها و ماژول ها اضافه شده است (هک بیشتری لازم نیست).
• کاهش نقش هیرا جهانی. یک دستور جدید مرتبط با جستجوی عروسکی.

نصب و راه اندازی

این فرآیند کاملاً ابتدایی است، اما مستلزم رعایت یک توالی مشخص از مراحل است. از آنجایی که انجام این کار به صورت دستی یک کار ناسپاس است، نویسنده یک چیز بد را به شما یاد می دهد، یعنی دانلود اسکریپت های نامفهوم از اینترنت و اجرا به عنوان روت در سیستم شما.

سه جزء اصلی سرور عبارتند از Puppet Server، PuppetDB و PostgreSQL. همه آنها می توانند در یک گره جمع شوند یا به دو یا سه سیستم تقسیم شوند. Puppet Server و Puppet DB را می توان بارها راه اندازی کرد، اما PostgeSQL یک گره شکست واحد است. رویکردهای مختلفی برای تکرار و خوشه‌بندی PostgeSQL وجود دارد. یک رویکرد راحت در مورد سرورهای اولیه و ثانویه، Master + Read-Only Slave است که در خود PuppetDB به عنوان یک گره پایگاه داده اولیه و فقط خواندنی پشتیبانی می‌شود، اما این تنظیم را خودکار می‌کند. زمان می برد و بنابراین هنوز در دسترس نیست. بخشی از ماژول cfpuppetserver است.

خود پیکربندی را می توان به سادگی حتی در سیستم فایل همراه با سرور عروسکی ذخیره کرد، اما مانند نوشتن اسکریپت روی یک وب سرور تولیدی است. مناسب ترین راه حل مخزن git است. ابزار r10k قادر است تمام شاخه های مخزن را بکشد و آنها را به عنوان محیط های جداگانه در سرور عروسکی مستقر کند. R10k در کشیدن وابستگی ها بسیار بد است، بنابراین از عروسک کتابدار در بالا استفاده می شود. بلافاصله باید توجه داشت که اصلی ترین محیط عروسکی متعارف "تولید" است. بنابراین در مخزن پیکربندی باید از شاخه ای با نام "production" استفاده کنید نه "master".

سیستم مورد نیاز

سخت افزار توسط خود سازنده توضیح داده شده است. ماژول cfpuppetserver در حال حاضر فقط از Debian Jessie + و Ubuntu Trusty + پشتیبانی می کند.

پیکربندی در Git

برای خود r10k، مکان مخزن واقعا مهم نیست - نکته اصلی در دسترس بودن آن است. به عنوان مثال، برای اهداف آزمایشی، مخزن را می توان در همان سیستم با دسترسی فایل: // میزبانی کرد. یک شروع خوب مثال پیکربندی codingfuture / puppet-exampleenv است.

1. مخزن را شبیه سازی کنید: git clone https://github.com/codingfuture/puppet-exampleenv my-puppet-conf && cd my-puppet-conf
2. ما تنظیمات کلی را برای دسترسی ادمین با استفاده از نکات موجود در نظرات تنظیم می کنیم:
   • $ EDITOR data / common.yaml
3. بیایید یک پیکربندی گره ایجاد کنیم:
   • $ MY_DOMAIN - نام دامنه ریشه (به عنوان مثال، example.org)
   • $ HOST_NAME - نام میزبان مشتری بدون دامنه
   • داده mkdir / $ MY_DOMAIN
   • cp data / example.com / puppet.yaml data / $ (MY_DOMAIN) /puppet.yaml
   • $ EDITOR nano -w data / $ (MY_DOMAIN) /puppet.yaml - پیکربندی یک گره با Puppet Server همانطور که در نظرات خواسته شده است
   • cp data / example.com / host.yaml data / $ (MY_DOMAIN) / $ (HOST_NAME) .yaml
   • $ EDITOR nano -w data / $ (MY_DOMAIN) / $ (HOST_NAME) .yaml - تنظیم یک گره دلخواه طبق نکات در نظرات
4. ما به سرور Git خود فشار می آوریم یا آن را به صورت محلی در گره با سرور Puppet از طریق rsync یا scp در دسترس قرار می دهیم. مخزن محلی به عنوان یک مرحله میانی مناسب است تا زمانی که سرور Git از خود Puppet مستقر شود. به یک معنا، این شبیه به ساخت یک کامپایلر در چند مرحله است.

ما از ابتدا روی یک سیستم تمیز نصب می کنیم

ماژول cfpuppetserver به شما امکان می دهد همه چیز را با استفاده از خود Puppet نصب کنید، اما برای نصب اولیه، عملیات اصلی توسط اسکریپت Bash کپی می شود.

در سیستم هدف:

1. اسکریپت نصب را دانلود کنید: wget https://raw.githubusercontent.com/codingfuture/puppet-cfpuppetserver/master/setup_puppetserver.sh
2. ما به اسکریپت نگاه می کنیم و در حاشیه اخم می کنیم: کمتر setup_puppetserver.sh
3. اجرا کنید: bash setup_puppetserver.sh عروسک $ (MY_DOMAIN).
   • مثال با مخزن راه دور: bash setup_puppetserver.sh ssh: // [ایمیل محافظت شده]/ عروسکی-کنف
   • مثال محلی: فایل bash setup_puppetserver.sh: /// root / puppetconf /
4. ما نگاه می کنیم که چگونه سیستم پف می کند و همه چیز را خیلی سریع نصب نمی کند.
5. اگر مخزن راه دور:
   • ایجاد کلید SSH برای root "a: ssh-keygen -t rsa -b 2048
   • ما کلید عمومی /root/.ssh/id_rsa.pub را در سرور Git راه دور ثبت می کنیم ...
   • ... و یک قلاب Git را با دستور زیر در آنجا راه اندازی کنید: / usr / bin / ssh -T [ایمیل محافظت شده]$ (MY_DOMAIN) ./puppetdeploy.sh
6. پیاده سازی پیکربندی را به صورت دستی شروع می کنیم: /etc/puppetlabs/deploy.sh
7. امتحان کردن نحوه عملکرد آن روی خود سرور: / opt / puppetlabs / bin / puppet agent --test
8. تنظیمات شبکه، فیلتر شبکه و دسترسی SSH را بررسی کنید

اضافه کردن گره های مدیریت شده

1. نام کامل سرور Puppet باید از طریق DNS در میزبان مدیریت شده در دسترس باشد، یا باید در هاست / etc / هاست کدگذاری شود.
   • مثال: echo "128.1.1.1 puppet.example.com" >> / etc / hosts
2. در گره سرور عروسکی، اسکریپت زیر را اجرا کنید /root/genclientinit.sh $ (HOST_NAME). $ (MY_DOMAIN).
3. کل نتیجه را کپی کرده و در خط فرمان در سیستم هدف قرار دهید.
4. منتظر اتمام اجرا و اجرا / opt / puppetlabs / bin / puppet agent --test هستیم. در اولین راه اندازی، یک درخواست امضای گواهی ایجاد می شود.
5. برای امضای گواهی به گره Puppet Server بروید.
   • لیست گواهی عروسکی - امضای گواهی را برای پارانویای اضافه بررسی کنید.
   • علامت گواهی عروسکی $ (HOST_NAME) $ (MY_DOMAIN) - در واقع، ما گواهی را امضا می کنیم.
6. ما به گره مدیریت شده برمی گردیم و دوباره: / opt / puppetlabs / bin / puppet agent --test` را اجرا می کنیم. این روند استقرار را مجبور می کند.
7. ما منتظر تکمیل استقرار از طریق عامل عروسکی هستیم.
8. تمام است، شما یک زیرساخت حداقلی Puppet آماده دارید!

خروجی نمونه /root/genclientinit.sh

بش</ etc / cflocation fi اگر تست کنید! -z ""؛ سپس echo -n> / etc / cflocationpool fi در صورت تست! -z "\ $ http_proxy"؛ سپس http_proxy export https_proxy = "\ $ http_proxy" صادرات HTTP_PROXY = "\ $ http_proxy" صادرات HTTPS_PROXY = "\ $ http_proxy" fi echo host.example.com> / etc / نام میزبان hostname host.example.com if! که lsb-release | خواندن؛ سپس apt-get install lsb-release fi codename = \ $ (lsb_release -cs) if test -z "\ $ codename"; سپس بازتاب "نام کد صحیح شناسایی نشد" خروج 1 فی wget https://apt.puppetlabs.com/puppetlabs-release-pc1-\$(codename).deb dpkg -i puppetlabs-release-pc1 - \ $ (نام رمز) .deb mkdir -p / etc / puppetlabs / puppet cat> /etc/puppetlabs/puppet/puppet.conf<علامت گواهی عروسکی host.example.com "echo" از CTRL + C برای متوقف کردن چرخه استفاده کنید، در صورتی که به دلایل مختلف ناموفق بود "Sleep 5 done EOT"

توضیحات ماژول

لیست کامل پارامترهای اسکریپت نصب اولیه Bash

~ # ./setup_puppetserver.sh استفاده: ./setup_puppetserver.sh [ [ [ [] ] ] ]

• r10k_repo_url - URI مخزن Git
• certname - نام دامنه کاملاً واجد شرایط میزبان
• cflocation - cf_location را مقداردهی اولیه کنید
• cflocationpool - مقداردهی اولیه واقعیت cf_location_pool
• http_proxy - سرور پروکسی برای درخواست های HTTP و HTTPS

لیست کامل پارامترهای Bash برای اسکریپت init کلاینت Puppet

~ # /root/genclientinit.sh استفاده: ./genclientinit.sh [ [ []]]
معنی پارامترها مانند اسکریپت قبلی است.

کلاس cfpuppetserver

• deployuser = "deploypuppet" - نام کاربری برای استقرار خودکار به روز رسانی های پیکربندی
• deployuser_auth_keys = undef - فهرست کلیدها برای $ deployuser
• repo_url = undef - Repository URI (مثال: ssh: // [ایمیل محافظت شده]/ مخزن یا فایل: /// some / path)
• puppetserver = true - آیا باید مؤلفه Puppet Server را روی این گره نصب کرد یا خیر
• puppetdb = true - آیا کامپوننت PuppetDB روی این گره نصب شود یا خیر
• puppetdb_port = 8081 - پورت برای PuppetDB
• setup_postgresql = true - آیا کامپوننت PostgreSQL روی این گره نصب شود (فقط در صورتی که نصب PuppetDB فعال باشد)
• service_face = "any" - cfnetwork :: نام منبع iface برای پذیرش اتصالات ورودی
• puppetserver_mem = خودکار - RAM برای سرور عروسکی در مگابایت (حداقل 192 مگابایت)
• puppetdb_mem = خودکار - RAM برای PuppetDB در مگابایت (حداقل 192 مگابایت)
• postgresql_mem = خودکار - RAM برای PostgreSQL در مگابایت (حداقل 128 مگابایت)

cfpuppetserver :: کلاس puppetdb

• postgresql_host = "localhost" - آدرس پایگاه داده
• postgresql_listen = $ postgresql_host - مقدار مستقیماً به دستورالعمل listen_addresses PostgreSQL می رود.
• postgresql_port = 5432 - پورت پایگاه داده
• postgresql_user = "puppetdb" - کاربر PuppetDB در پایگاه داده
• postgresql_pass = "puppetdb" - رمز عبور کاربر PuppetDB در پایگاه داده
• postgresql_ssl = false - فعال کردن رمزگذاری اتصال بر اساس گواهی‌های Puppet PKI

cfpuppetserver :: کلاس puppetserver

• علامت خودکار = نادرست - نباید در محیط تولید استفاده شود، مگر در DMZ. این فقط برای اتوماسیون تست وجود دارد.
• global_hiera_config = "cfpuppetserver / hiera.yaml" - مسیر فایل پیکربندی پیش‌فرض Hiera طبق قوانین Puppet (اولین جزء نام ماژول است، بقیه مسیر زیر فایل‌ها / پوشه در ماژول است)

شما می توانید کمک کنید و مقداری سرمایه برای توسعه سایت انتقال دهید



مدتی پیش، لیست سرورهای موجود در بوکمارک های من از 200 فراتر رفت. با افزایش تعداد سرورها، استقرار هر پیکربندی جدید یا نصب بسته های جدید باعث اتلاف زمان زیادی می شود. بنابراین تصمیم گرفتم از عروسک استفاده کنم.
عروسک خیمه شب بازی(Puppet انگلیسی) یک برنامه کاربردی سرویس دهنده-کلینت بین پلتفرمی است که به شما امکان می دهد پیکربندی سیستم عامل ها و برنامه های نصب شده بر روی چندین کامپیوتر را به صورت متمرکز مدیریت کنید. Puppet به زبان برنامه نویسی Ruby نوشته شده است.

همچنین گفته می شود که Puppet یک سیستم مدیریت پیکربندی از راه دور است که مهمترین آنها سیستم های منبع باز Cfengine و Puppet است.

پس از خواندن نقدها، تصمیم گرفتم از عروسک استفاده کنم.

نصب و پیکربندی سرور عروسکی:
نصب سرور عروسکی:
سرور عروسکی را در OpenSuSE 11.4 نصب کنید:

زیپر در سرور عروسکی

نام سرور را به عروسک تغییر دهید:
/ etc / HOSTNAME:

رکورد DNS باید به 127.0.0.2 برود
گربه / غیره / میزبان:

127.0.0.2 عروسک عروسکی.سایت

به کاربر حقوق بدهید عروسک خیمه شب بازی:

بیایید سرویس Puppet Master را شروع کنیم:

شروع rcpuppetmasterd

بیایید شروع Daemon عروسکی را به بارگذاری خودکار اضافه کنیم:

chkconfig -a puppetmasterd

پیکربندی سرور عروسکی:
بیایید دایرکتوری را تعریف کنیم که در آن فایل‌ها ذخیره می‌شوند که سرور عروسکی در مانیفست‌هایی از نوع فایل به ماشین‌های کلاینت منتقل می‌کند.

vim / etc / puppet / fileserver

مسیر / غیره / عروسک / فایل ها
اجازه *

mkdir / etc / puppet / files

عروسک chown -R: عروسک / غیره / عروسک / فایل

بیایید یک فایل از هر محتوایی برای استقرار و آزمایش روی مشتریان ایجاد کنیم

لمس / غیره / عروسک / فایل ها / آزمایش عروسکی

سرور عروسکی را مجددا راه اندازی کنید:

rcpuppetmasterd راه اندازی مجدد

عروسک خیمه شب بازیاز زبان خود برای توصیف وضعیت نهایی سیستم عامل استفاده می کند که به کمک آن sysadmin مشخص می کند که چه نوع اجزای سیستم عامل باید آورده شود تا به وضعیت مطلوب برسد. وضعیت می تواند به معنای وجود یک فایل خاص، پوشه، سرویس های در حال اجرا بسته های نصب شده، به روز رسانی ها و موارد دیگر باشد. تمام تنظیمات حالت در فایل ها یا مانیفست هایی که در دایرکتوری قرار دارند توضیح داده می شوند: / etc / puppet / manifests. این فایل ها دارای نام هایی مانند * pp.

بیایید ساده ترین را ایجاد کنیم بیانیه:
/etc/puppet/manifests/1.file.pp:

فایل ("/ tmp / puppettesting":
منبع => "عروسک: /// فایل ها / تست عروسکی"،
}

برای اعمال این مانیفست:
درخواست عروسک 1.file.pp

نصب و پیکربندی کلاینت عروسکی:

زیپ در عروسک

بیایید حقوق عروسکی را به کاربر بدهیم:

chown -R puppet.puppet / var / lib / puppet /

برای برقراری ارتباط با سرور عروسکی، سرویس گیرنده عروسکی درخواستی برای تایید گواهی ارسال می کند، پس از تایید سرور این درخواست، کلاینت عروسکی شروع به استفاده از مانیفست های در نظر گرفته شده برای آن می کند. ما درخواستی برای تایید گواهی ارسال خواهیم کرد:

در سرور، می‌توانیم ببینیم که چه درخواست‌های تأییدی در انتظار هستند:

"puppet-client.localdomain" (B5: 12: 69: 63: DE: 19: E9: 75: 32: 2B: AA: 74: 06: F6: 8E: 8A)

تائید می کنیم:

puppetca -- علامت "puppet-client.localdomain"

وقت آن است که ساده ترین نمونه های ایجاد مانیفست را در نظر بگیریم:
یک فایل /etc/puppet/manifests/site.pp ایجاد کنید:

پیش فرض گره (
فایل ("/ tmp / puppettesting":
منبع => "Puppet: /// files / Puppettesting",
}
سرویس ("ntp":
اطمینان => در حال اجرا،
فعال کردن => درست،
}
بسته ("htop":
اطمینان حاصل کنید که => نصب شده است،
}
}

پیش فرض - برای همه مشتریان اعمال شود
file - این بخش می گوید برای ایجاد یا بازنویسی فایل / tmp / puppettesting که روی سرور در پوشه / etc / puppet / files قرار دارد.
سرویس: بررسی کنید که آیا سرویس در حال اجرا است، اگر شروع نشده است، آن را راه اندازی کنید و همچنین آن را به راه اندازی اضافه کنید
بسته: بررسی کنید که آیا بسته htop روی کلاینت نصب شده است یا خیر و اگر نه، آن را نصب کنید.

برای بررسی، روی کلاینت اجرا کنید:

همانطور که می بینید، ntp به بارگذاری خودکار روی کلاینت اضافه شد، دیمون ntp راه اندازی شد، بسته htop نصب شد و فایل puppettesting در پوشه / tmp / کپی شد.

اطلاعات: ذخیره کاتالوگ برای puppet-client.localdomain
اطلاعات: اعمال نسخه پیکربندی "1370163660"
توجه: / مرحله [اصلی] // گره [پیش‌فرض] / سرویس [ntp] / اطمینان حاصل کنید: اطمینان حاصل کنید که «stoped» به «running» تغییر کرده است.
توجه: / مرحله [اصلی] // گره [پیش‌فرض] / بسته [htop] / اطمینان: ایجاد شد
توجه: / مرحله [اصلی] // گره [پیش‌فرض] / فایل [/ tmp / puppettesting] / اطمینان: محتوای تعریف شده به عنوان "(md5)"
توجه: کاتالوگ تمام شده در 3.95 ثانیه اجرا می شود

در مقاله بعدی نمونه های پیچیده تری از ایجاد مانیفست و رابط وب داشبورد عروسکی را شرح خواهم داد.

انواع منابع محبوب عروسکی
کرون- مدیریت شغلی کرون
اجرایی- راه اندازی اسکریپت ها و دستورات
فایل- مدیریت فایل
سطل فایل- پشتیبان گیری از فایل
گروه- مدیریت گروه
میزبان- مدیریت ورودی ها در فایل / etc / hosts
رابط- پیکربندی رابط های شبکه
کوه- نصب سیستم های فایل
اعلام کردن- ارسال پیام به فایل لاگ Puppet
بسته بندی- مدیریت بسته
سرویس- مدیریت خدمات
sshkey- مدیریت کلید SSH
مرتب- حذف فایل ها بسته به شرایط
کاربر- مدیریت کاربر
مناطق- مدیریت منطقه سولاریس