کلاس cfpuppetserver

• deployuser = "deploypuppet" - نام کاربری برای استقرار خودکار به‌روزرسانی‌های پیکربندی
• deployuser_auth_keys = undef - فهرست کلیدها برای $deployuser
• repo_url = undef - URI مخزن (مثال: ssh://user@host/repo یا file:///some/path)
• puppetserver = true - آیا باید مؤلفه Puppet Server را روی این گره نصب کرد یا خیر
• puppetdb = true - آیا باید کامپوننت PuppetDB را روی این گره نصب کرد یا خیر
• puppetdb_port = 8081 - پورت برای PuppetDB
• setup_postgresql = true - آیا کامپوننت PostgreSQL روی این گره نصب شود (فقط در صورتی که نصب PuppetDB فعال باشد)
• service_face = "any" - نام cfnetwork::face منبع برای پذیرش اتصالات ورودی
• 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 (اولین جزء نام ماژول است، بقیه مسیر زیر فایل/پوشه در ماژول است)

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

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

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

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

Puppet، مانند cfengine، یک سیستم کلاینت-سرور است که از یک زبان اعلامی، یعنی زبان اجباری برای توصیف وظایف و کتابخانه ها برای اجرای آنها استفاده می کند. مشتریان به صورت دوره ای (30 دقیقه به طور پیش فرض) به سرور مرکزی متصل می شوند و آخرین پیکربندی را دریافت می کنند. در صورت عدم تطابق تنظیمات دریافتی با وضعیت سیستم، اجرا شده و در صورت نیاز گزارشی از عملیات انجام شده به سرور ارسال خواهد شد. سرور می تواند پیام ها را در syslog یا یک فایل ذخیره کند، یک نمودار RRD ایجاد کند و آنها را به یک ایمیل مشخص ارسال کند. لایه‌های انتزاعی تراکنش و منابع، حداکثر سازگاری را با تنظیمات و برنامه‌های موجود فراهم می‌کنند و به شما این امکان را می‌دهند که بدون نگرانی در مورد تفاوت در اجرا و شرح دستورات و فرمت‌های فایل، روی اشیاء سیستم تمرکز کنید. مدیر فقط با نوع شی کار می کند، Puppet بقیه موارد را بر عهده دارد. بنابراین، نوع بسته‌ها حدود 17 سیستم بسته را می‌شناسد؛ سیستم مورد نیاز به طور خودکار بر اساس اطلاعات مربوط به نسخه توزیع یا سیستم شناسایی می‌شود، اگرچه در صورت لزوم، مدیر بسته می‌تواند مجبور شود.

برخلاف اسکریپت‌ها، که اغلب استفاده از آن‌ها در سیستم‌های دیگر امکان‌پذیر نیست، پیکربندی‌های Puppet نوشته شده توسط مدیران شخص ثالث، در اکثر موارد، بدون مشکل در هر شبکه دیگری کار می‌کنند. در کتاب آشپزی عروسکی [ http://www.reductivelabs.com/trac/puppet/tags/puppet%2Crecipe] در حال حاضر سه دوجین دستور پخت آماده وجود دارد. Puppet در حال حاضر به طور رسمی از سیستم عامل ها و خدمات زیر پشتیبانی می کند: Debian، RedHat/Fedora، Solaris، SUSE، CentOS، Mac OS X، OpenBSD، Gentoo و MySQL، LDAP.

زبان عروسکی

برای حرکت رو به جلو، ابتدا باید عناصر و قابلیت های اساسی زبان را درک کنید. زبان یکی از نقاط قوتعروسک خیمه شب بازی با کمک آن، منابعی که مدیر برای مدیریت برنامه ریزی می کند و اقدامات شرح داده می شود. برخلاف اکثر راه حل های مشابه، Puppet به زبان اجازه می دهد تا دسترسی به تمام منابع مشابه را در هر سیستمی در یک محیط ناهمگن ساده کند. توصیف منبع معمولاً از یک نام، نوع و ویژگی ها تشکیل شده است. به عنوان مثال، اجازه دهید به فایل /etc/passwd اشاره کنیم و ویژگی های آن را تنظیم کنیم:

file("/etc/passwd":

مالک => ریشه،

گروه => ریشه،

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

مسیر /var/puppet/config

اجازه دهید *.domain.com

اجازه 192.168.0.*

اجازه 192.168.1.0/24

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

و سپس هنگام توصیف منبع به این بخش می رویم.

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

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

file("/etc/passwd":

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

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

فایل (sshdconfig:

name => $operatingsystem ? (

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

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

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

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

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

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

$homeroot = "/home"

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

$(homeroot)/$name

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

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

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

file("/etc/apache2/conf.d":

منبع => "puppet:// puppet://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 ($group، $fullname، $ingroups) (

user("$name":

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

نظر => "$fullname"،

gid => "$group",

گروه ها => $ inggroups،

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

shell => "/bin/bash",

home => "/home/$name"،

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

exec("$name homedir":

command => “/bin/cp -R /etc/skel /home/$name; /bin/chown -R $name:$group /home/$name،

ایجاد => "/home/$name"،

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

حالا برای ایجاد یک جدید حسابفقط با user_homedir تماس بگیرید.

user_homedir("sergej":

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

نام کامل => “Sergej Jaremchuk”,

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

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

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

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

محدوده =>

exec("/usr/bin/apt-get update":

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

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

نصب عروسک

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 ​​‎ -ropenssl -e "puts:yep"

~$ ruby‎ -rxmlrpc/client -e "puts:yep"

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

$ sudo /usr/bin/puppetmasterd --nonodes

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

file("/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/puppet

vardir = /var/lib/puppet

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 در مقاله به سادگی امکان پذیر نیست. اما همانطور که می بینید، این یک ابزار کاربردی و انعطاف پذیر است که به شما امکان می دهد اکثر مشکلات مدیریت همزمان تعداد زیادی سیستم را حل کنید. اگر خط کاری شما نیاز به راه اندازی چندین سیستم دارد. و مهمتر از همه، این پروژه موفق شد یک جامعه کوچک اما دائماً در حال رشد را جمع کند. بنابراین، بیایید امیدوار باشیم که یک ایده خوب اجازه داده نشود که بمیرد یا کنار برود.

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

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

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

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

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 راه اندازی مجدد

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

ابتدا بیایید سرویس را پیکربندی کنیم عروسک خیمه شب بازیعاملی برای راه اندازی /etc/default/puppet را ویرایش کنید و مقدار را جایگزین کنید شروع کنیدبر آره:

Sudo /etc/init.d/puppet start

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

Sudo puppetca --sign meercat02.example.com

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

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

سرگئی یارمچوک

پیکربندی متمرکز سیستم های یونیکس با استفاده از Puppet

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

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

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

Puppet، مانند Cfengine، یک سیستم سرویس گیرنده-سرور است که از یک زبان اعلامی برای توصیف وظایف و کتابخانه ها برای پیاده سازی آنها استفاده می کند. مشتریان به صورت دوره ای (به طور پیش فرض هر 30 دقیقه) به سرور مرکزی متصل می شوند و آخرین پیکربندی را دریافت می کنند. در صورت عدم تطابق تنظیمات دریافتی با وضعیت سیستم، اجرا شده و در صورت نیاز گزارشی از عملیات انجام شده به سرور ارسال خواهد شد. سرور پیام می تواند آن را در syslog یا یک فایل ذخیره کند، یک نمودار RRD ایجاد کند و آن را به ایمیل مشخص شده ارسال کند. لایه‌های انتزاعی تراکنش و منابع، حداکثر سازگاری را با تنظیمات و برنامه‌های موجود فراهم می‌کنند و به شما این امکان را می‌دهند که بر روی اشیاء سیستم تمرکز کنید بدون اینکه نگران تفاوت در اجرا و شرح دستورات دقیق و فرمت‌های فایل باشید. مدیر فقط با نوع شی کار می کند، Puppet بقیه موارد را بر عهده دارد. بنابراین، نوع بسته‌ها حدود 17 سیستم بسته را می‌شناسد؛ سیستم مورد نیاز به‌طور خودکار بر اساس اطلاعات مربوط به نسخه توزیع یا سیستم شناسایی می‌شود، اگرچه در صورت لزوم، می‌توان مدیریت بسته را به اجبار تنظیم کرد.

برخلاف اسکریپت‌ها، که اغلب استفاده از آنها در سیستم‌های دیگر غیرممکن است، پیکربندی‌های Puppet که توسط مدیران شخص ثالث نوشته شده‌اند، عمدتاً بدون مشکل در هر شبکه دیگری کار می‌کنند. کتاب آشپزی عروسکی در حال حاضر سه دوجین دستور پخت آماده دارد. Puppet در حال حاضر به طور رسمی از سیستم عامل ها و خدمات زیر پشتیبانی می کند: Debian، RedHat/Fedora، Solaris، SUSE، CentOS، Mac OS X، OpenBSD، Gentoo و MySQL، LDAP.

زبان عروسکی

برای حرکت رو به جلو، ابتدا باید عناصر و قابلیت های اساسی زبان را درک کنید. زبان یکی از نقاط قوت عروسک است. این منابعی را که مدیر برنامه ریزی برای مدیریت می کند و اقداماتی که انجام می دهد را توصیف می کند. برخلاف اکثر راه حل های مشابه، Puppet به زبان اجازه می دهد تا دسترسی به تمام منابع مشابه را در هر سیستمی در یک محیط ناهمگن ساده کند. توصیف منبع معمولاً از یک نام، نوع و ویژگی ها تشکیل شده است. به عنوان مثال، اجازه دهید به فایل /etc/passwd اشاره کنیم و ویژگی های آن را تنظیم کنیم:

file("/etc/passwd":

مالک => ریشه،

گروه => ریشه،

حالت => 644،

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

مسیر /var/puppet/config

*.domain.com را مجاز کنید

اجازه 127.0.0.1

اجازه 192.168.0.*

اجازه 192.168.1.0/24

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

و سپس هنگام توصیف منبع به این بخش مراجعه می کنیم:

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

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

file("/etc/passwd":

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

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

فایل (sshdconfig:

نام => $operatingsystem ? (

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

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

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

سرویس(sshd:

اطمینان حاصل کنید => درست است،

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

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

$homeroot = "/home"

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

$(homeroot)/$name

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

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

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

file("/etc/apache2/conf.d":

منبع => "puppet:// puppet://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 ($group، $fullname، $ingroups) (

کاربر("$name":

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

نظر => "$fullname"،

Gid => "$group",

گروه ها => $inggroups،

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

Shell => "/bin/bash"،

صفحه اصلی => "/home/$name"،

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

Exec("$name homedir":

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

ایجاد => "/home/$name"،

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

اکنون، برای ایجاد یک حساب کاربری جدید، فقط با user_homedir تماس بگیرید:

user_homedir("sergej":

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

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

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

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

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

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

محدوده =>

exec("/usr/bin/apt-get update":

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

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

نصب عروسک

Puppet به Ruby (نسخه 1.8.1 و بالاتر) با پشتیبانی OpenSSL و کتابخانه های XMLRPC و همچنین کتابخانه Faster نیاز دارد. مخزن اوبونتو 7.04 که برای نصب آزمایشی استفاده شد، قبلاً شامل بسته توله سگ است:

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

~$ ruby‎ -rxmlrpc/client -e "puts:yep"

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

$ sudo /usr/bin/puppetmasterd --nonodes

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

کلاس سودو(

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

مالک => ریشه،

گروه => ریشه،

حالت => 440،

پیش فرض گره(

سودو را شامل شود

همه فایل های پیکربندی، چه سرور و چه کلاینت، در /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/puppet

vardir = /var/lib/puppet

rundir = /var/run

# یک گزارش به سرور ارسال کنید

گزارش = درست

برای جلوگیری از تایپ دستی همه چیز، می توانید با استفاده از خود puppetd یک الگو ایجاد کنید:

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

به طور مشابه، می توانید site.pp را روی سرور ایجاد کنید:

$ puppetd --genmanifest > /etc/puppet/manifests/site.pp

یک فایل دیگر، tagmail.conf، به شما امکان می‌دهد آدرس‌های ایمیلی را که گزارش‌ها به آن‌ها ارسال می‌شوند، مشخص کنید. در ساده ترین حالت، می توانید از یک خط استفاده کنید:

همه: [ایمیل محافظت شده]

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

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

$ sudo puppetd --server grinder.com --waitforcert 60 –test

فایروال باید اجازه اتصال به پورت 8140 را بدهد.

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

$ sudo puppetca –list

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

$ sudo puppetca –sign nomad.grinder.com

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

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

موفق باشید!

1. وب سایت پروژه BladeLogic – http://www.bladelogic.com.
2. وب سایت پروژه OpsWare http://www.opsware.com است.
3. وب سایت پروژه Cfengine http://www.cfengine.org است.
4. وب سایت پروژه عروسکی http://reductivelabs.com/projects/puppet است.
5. کتاب آشپزی عروسکی - http://www.reductivelabs.com/trac/puppet/tagspuppet%2Crecipe.
6. کتابخانه سریعتر -