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

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

دو سوم ایستگاه های کاری، چند مورد دیگر روتر و بقیه چندین وب سرور و ذخیره سازی داده ها هستند. سوال: چگونه می توان این همه تجارت را مدیریت کرد؟ ساده ترین پاسخ این است که به سادگی با استفاده از SSH به هر یک از آنها متصل شوید و تغییرات لازم را انجام دهید. اما این روش دو مشکل دارد. اولاً، بسیار کار بر است. ثانیاً، مدیر به طور مداوم مجبور است بسیاری از اقدامات یکنواخت را انجام دهد (به عنوان مثال، برای به روز رسانی OpenOffice.org در تمام ایستگاه های کاری، باید چندین ده بار دستورات مشابه را اجرا کنید). می توانید با نوشتن چندین اسکریپت که خود به هر دستگاه متصل می شوند و دستورات از پیش نوشته شده را اجرا می کنند، از این مشکل جلوگیری کنید. اما در اینجا نیز مشکلاتی در انتظار شماست.

اسکریپت ها باید دائماً اصلاح شوند تا آنها را با هر کار تطبیق دهند. اسکریپت‌ها باید تفاوت‌های موجود در سیستم‌عامل‌ها و نسخه‌ها را در نظر بگیرند، و قبل از اعمال بر روی ماشین‌های در حال اجرا باید برای مدت طولانی اشکال زدایی شوند. به طور کلی، comme il faut نیست. پاسخ صحیح استفاده از سیستم های به اصطلاح مدیریت پیکربندی از راه دور است که معروف ترین نمایندگان آن هستند. سیستم های باز Cfengine و Puppet. چنین سیستم هایی تمام مسئولیت ها را برای آوردن پیکربندی ماشین به عهده می گیرند نوع مناسب، مدیر را ملزم می کند که وضعیت نهایی سیستم را به زبانی خاص توصیف کند (به عنوان مثال شرحی از بسته هایی که باید در سیستم عامل نصب شوند، چه خطوطی باید به فایل های پیکربندی اضافه شوند، چه دستوراتی باید اجرا شوند و غیره). ). پس از این، تمام گره ها خود اطلاعاتی در مورد وضعیت مورد نیاز از سرور دریافت می کنند و پیکربندی خودکار سیستم را انجام می دهند. به لطف این مکانیزم، ماشین‌های جدید را می‌توان به طور کامل بدون دخالت انسان پیکربندی کرد و ماشین‌های موجود را می‌توان تنها با افزودن چند خط به توضیحات وضعیت، دوباره پیکربندی کرد.

عروسک خیمه شب بازی؟

ما قبلاً یک مقاله کامل را به سیستم Cfengine اختصاص داده‌ایم، بنابراین امروز بر روی سیستم عروسکی تمرکز خواهیم کرد که به خوبی می‌توان آن را جانشین ایدئولوژیک آن نامید. Puppet توسط Luke Kanies ساخته شد که از محدودیت های Cfengine خسته شد و تصمیم گرفت نسخه بهتری را از ابتدا ایجاد کند. اگر قبلاً از Cfenfine استفاده کرده اید، احتمالاً Puppet را سیستمی راحت تر و قدرتمندتر خواهید یافت. زبان دولتی Puppet سطح بالا و انعطاف پذیرتر است، به این معنی که مدیر نیازی به نگرانی در مورد چیزهایی مانند نوشتن قوانین جداگانه برای هر نوع سیستم عامل یا توضیحات مفصلانجام اقدامات بی اهمیت Puppet به استاد خود اجازه می دهد به جای اینکه چگونه آن را انجام دهد، روی کاری که می خواهد انجام دهد تمرکز کند (به عنوان مثال، برای نصب یک بسته خاص بر روی هر یک از سیستم عامل های پشتیبانی شده سیستم، فقط باید به معنای واقعی کلمه چند خط بنویسید: "این برنامه را نصب کنید. به جای توصیف دستورات لازم برای نصب آن). Puppet به زبان ساده Ruby نوشته شده است، که تطبیق آن با یک کار خاص و گسترش عملکرد آن را آسان می کند (یک سیستم انعطاف پذیر از پلاگین ها ارائه شده است).

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

به طور کلی، به نظر می رسد Puppet یک سیستم مدرن و پیچیده تر است طراحی خوب. مانند Cfengine، تقریباً از تمام سیستم عامل های مدرن یونیکس مانند (از جمله MacOS X) پشتیبانی می کند و همچنین می تواند در محیط Cygwin بالای ویندوز اجرا شود. لیست وابستگی آن فقط شامل مفسر Ruby و ابزار Factor است، بنابراین نباید مشکلی در نصب وجود داشته باشد (منصفانه، لیست وابستگی Cfengine حتی کوتاهتر است).

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

مانند Cfengne، Puppet یک سیستم مشتری-سرور است که از یک سرور کنترل و گره های برده تشکیل شده است. سرور شرحی از حالت های نهایی گره ها را ذخیره می کند (که در اصطلاح Puppet به آن مانیفست می گویند) و منتظر می ماند تا آنها متصل شوند. هر نیم ساعت (به طور پیش فرض)، کلاینت به سرور متصل می شود، توصیفی از وضعیت نهایی را از آن دریافت می کند، آن را با حالت فعلی مقایسه می کند و اگر آن و/یا وضعیت توصیف شده تغییر کرده باشد، سیستم را دوباره پیکربندی می کند و سپس به خواب می رود ارتباط از طریق یک کانال رمزگذاری شده انجام می شود، بنابراین حملات مبتنی بر جایگزینی توصیف وضعیت مستثنی می شوند (اما اگر یک مهاجم سرور را تصاحب کند، تمام گره ها تحت کنترل او خواهند بود).

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

$ sudo apt-get install puppet

و سرور به این صورت است:

$ sudo apt-get install puppet puppetmaster

فایل های پیکربندی کلاینت و سرور در دایرکتوری /etc/puppet ذخیره می شوند. مهمترین آنها فایل /etc/puppet/manifests/site.pp است که حاوی مانیفست است.

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

کلاس passwd(
file("/etc/passwd":
مالک => ریشه،
گروه => ریشه،
حالت => 644،
}
}
پیش فرض گره(
شامل passwd
}

این خطوط وضعیتی را توصیف می کنند که در آن مالک فایل /etc/passwd باید root باشد و مجوزهای آن روی 644 تنظیم شده است. ما در بخش بعدی نگاهی دقیق تر به فرمت فایل مانیفست خواهیم داشت. دومین فایل مهم فایل /etc/puppet/puppet.conf است. پیکربندی سرور و کلاینت‌ها را تنظیم می‌کند، بنابراین باید در تمام ماشین‌های سازمان‌دهی‌شده در شبکه Puppet وجود داشته باشد. در اوبونتو، این فایل حاوی حداقل تنظیمات لازم و در بیشتر موارد کافی است. در زیر آنها با نظرات آورده شده است:

# vi /etc/puppet/puppet.conf
# مسیرهای دایرکتوری استاندارد
logdir=/var/log/puppet
vardir=/var/lib/puppet
ssldir=/var/lib/puppet/ssl
rundir=/var/run/puppet
# مکان ابزار فاکتور،
# برای به دست آوردن اطلاعات در مورد سیستم عامل استفاده می شود
factpath=$vardir/lib/facter
# پلاگین ها را همگام سازی کنید
# (پلاگین های نصب شده روی سرور - آنها برای مشتریان کپی می شوند)
pluginsync=true
# کاتالوگ با الگوها (در مورد آنها در زیر بخوانید)
templatedir=$confdir/templates
# همگام سازی با etckeeper
# (کسی که می داند، می فهمد، دیگران به آن نیاز ندارند)
prerun_command=/etc/puppet/etckeeper-commitpre
postrun_command=/etc/puppet/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 --list

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

$ sudo puppetca --sign nomad.grinder.com

یا همه چیز را به یکباره امضا می کنیم:

$ sudo puppetca --sign --all

اکنون می توانید کلاینت ها را در حالت مبارزه راه اندازی کنید. اما ابتدا باید نام سرور Puppet را در فایل پیکربندی وارد کنید (به طور پیش فرض نام آن به سادگی عروسک است):

$sudo su
# echo "" >> /etc/puppet/puppet.conf
# echo "server=puppet-server.com" >> /etc/puppet/puppet.conf
#خروج

راه اندازی مشتریان:

$ sudo /etc/init.d/puppet start

زبان توصیف حالت

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

# vi /etc/puppet/manifests/site.pp
file("/etc/passwd":
مالک => "ریشه"
}

در اینجا فایل نوع منبع است. در مجموع چندین ده مورد از آنها وجود دارد، از منابعی که فایل ها را مدیریت می کنند، مانند این مثال، تا بسته ها و خدمات. خط /etc/passwd نام منبع است.

در مورد نوع فایل، نام همان مسیر فایل است، اما در برخی از انواع دیگر نام می تواند دلخواه باشد. خط مالک => "ریشه" تنظیم ویژگی مالک را به ریشه توصیف می کند، یعنی می گوید که مالک فایل مشخص شدهباید یک مدیر وجود داشته باشد

هر نوع منبع مجموعه ای از ویژگی های خاص خود را دارد که برای اصلاح در دسترس است، به علاوه ویژگی های متا خاصی وجود دارد که می توانند در هر منبعی استفاده شوند. یکی از ویژگی های مهم منابع، توانایی پیوند دادن به آنها است. این می تواند برای تشکیل زنجیره های وابستگی استفاده شود. ورودی زیر منبع /etc/group را ایجاد می‌کند که به منبع /etc/passwd بستگی دارد (وابستگی‌ها با استفاده از ویژگی متا الزامی مشخص می‌شوند):

# vi /etc/puppet/manifests/site.pp
file("/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
کلاس passwd(
file("/etc/passwd":
مالک => "ریشه"،
گروه => "ریشه"،
}
}
کلاس passwd-bsd passwd را به ارث می برد (
فایل["/etc/passwd"] (گروه => "چرخ")
}

در اینجا، کلاس passwd-bsd از passwd به ارث می برد تا ویژگی گروه منبع /etc/passwd را لغو کند (در سیستم های BSD، /etc/passwd به گروه چرخ تعلق دارد، بنابراین ما یک کلاس جداگانه برای چنین سیستم هایی ایجاد کردیم). بعداً به یک روش صحیح و واضح تر برای انتخاب مقادیر ویژگی جایگزین با استفاده از شرایط خواهیم پرداخت.

متغیرها یکی از اجزای جدایی ناپذیر هر زبان برنامه نویسی هستند و Puppet نیز آنها را دارد. متغیرها با علامت $ شروع می شوند و می توانند شامل هر عدد، رشته یا هر عددی باشند مقدار بولی(درست، نادرست):

$want_apache = درست است
$apache_version = "2.2.14"

یکی از قدرتمندترین ویژگی های مربوط به متغیرهای Puppet، ادغام آن با ابزار اطلاعات ماشین فاکتور است. این ابزار تمام اطلاعات مربوط به ماشین را در قالب جفت های کلید-مقدار باز می گرداند که در Puppet به متغیرهایی با همین نام تبدیل می شوند. همراه با دستورالعمل‌های شرطی در زبان Puppet، می‌توان از آنها برای تغییر ویژگی‌های منبع بسته به ویژگی‌های ماشین استفاده کرد.

به عنوان مثال، کلاس passwd که در بالا توضیح داده شد را می توان به راحتی بازنویسی کرد تا به طور خودکار یک ویژگی بسته به نوع سیستم عامل (بدون نیاز به کلاس) انتخاب شود:

# vi /etc/puppet/manifests/site.pp
file("/etc/passwd":
مالک => "ریشه"،
گروه => $kernel ? (
لینوکس => "ریشه"،
FreeBSD => "چرخ"،
},
}

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

# vi /etc/puppet/manifests/site.pp
مورد سیستم عامل $ (
redhat: (سرویس ("httpd": اطمینان => در حال اجرا))
debian: (سرویس ("apache": اطمینان => در حال اجرا))
پیش فرض: (سرویس ("apache2": اطمینان =>
دویدن))
}

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

اگر مقدار متغیر با هیچ یک از گزینه های قبلی مطابقت نداشته باشد از گزینه پیش فرض استفاده می شود. علاوه بر انواع فایل ها، بسته ها و منابع سرویس که قبلاً مورد بحث قرار گرفت، Puppet از تعداد زیادی از انواع منابع دیگر، از جمله مواردی که توسط توسعه دهندگان شخص ثالث ایجاد شده اند، پشتیبانی می کند. شرح مفصل آنها، از جمله مثال‌ها، ویژگی‌ها و ویژگی‌های پشتیبانی‌شده، را می‌توان در اسناد رسمی یافت - http://docs.puppetlabs.com/references/stable/type.html. در زیر لیست و شرح مختصرپرکاربردترین آنها عبارتند از:

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

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

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

# vi /etc/puppet/manifests/site.pp
پیش فرض گره(
شامل passwd
}

این تعریف گره پیش فرض است که شامل منبع/کلاس passwd است. نام پیش‌فرض به معنای «همه گره‌های دیگر» است، بنابراین منبع/کلاس passwd که در جایی بالا تعریف شده است، روی هر یک از آنها پیکربندی می‌شود. کلمه کلیدی include در اینجا برای راحتی استفاده می شود. علاوه بر پیش فرض، در نام گره می توانید نام شبکه دستگاه را مشخص کنید (سپس تمام منابع توضیح داده شده در گره فقط در این دستگاه پیکربندی می شوند) یا یک نام دلخواه (سپس این گره می تواند توسط گره دیگری به ارث برده شود) . برای درک اینکه چگونه همه اینها با کلاس ها و منابع کار می کند، بیایید به نمونه ای از یک مانیفست عروسکی آماده که برای پیکربندی دو ماشین شبکه (یک سرور وب و یک سرور NTP) استفاده می شود، نگاه کنیم:

# vi /etc/puppet/manifests/site.pp
# نصب و اجرای سرور SSH
کلاس sshd(
بسته (openssh-server: اطمینان => نصب شده)
سرویس(sshd:
name => $operatingsystem ? (
فدورا => "sshd",
debian => "ssh",
پیش فرض => "sshd",
},
فعال کردن => درست،
اطمینان => در حال اجرا،
}
}
# Apache را نصب و اجرا کنید
کلاس httpd(
بسته (httpd: اطمینان => نصب شده)
سرویس (httpd:
فعال کردن => درست،
اطمینان => در حال اجرا،
}
}
# نصب و راه اندازی سرور NTP
کلاس ntpd(
بسته (ntp-server: اطمینان => نصب شده)
خدمات (
ntp-server:
فعال کردن => درست،
اطمینان => در حال اجرا،
}
}
# گره پایه، که فقط به عنوان والد سایر گره ها استفاده می شود
پایه گره (
شامل sshd
}
# گره ای که وب سرور در آن قرار خواهد گرفت
node web.server.com پایه را به ارث می برد (
httpd را شامل شود
}
# گره سرور NTP
node ntp.server.com پایه را به ارث می برد (
شامل ntpd
}

این پیکربندی به ظاهر ساده کارهای زیادی انجام می‌دهد: Apache را بر روی دستگاه در web.server.com نصب و اجرا می‌کند و یک سرور NTP روی دستگاه نصب و اجرا می‌شود. ntp.server.com. علاوه بر این، هر دو ماشین یک سرور SSH نصب می کنند. بعید است که این پیکربندی حتی برای یک مدیر مناسب باشد. برای آموزش نحوه پیکربندی صحیح سرورها، دریافت تنظیمات جدید و سایر فایل ها از سرور اصلی Puppet، باید به طور جدی بهبود یابد.

با این حال، به وضوح قدرت Puppet را نشان می دهد. با استفاده از یک پیکربندی ساده، ماشین‌ها را وادار کردیم که نرم‌افزارهای لازم را خودشان نصب و اجرا کنند و آن را در حالت کار نگه دارند (در صورت خرابی سرور، خود Puppet دوباره پیکربندی می‌کند تا سیستم‌ها را به حالت مورد نیاز برساند).

سرور فایل

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

تنظیمات سرور فایل در فایل /etc/puppet/fileserver.conf ذخیره می شود. برای اینکه Puppet را مجبور کنید محتویات یک دایرکتوری خاص را به مشتریان ارائه دهد، باید چند خط در آن قرار دهید:

# vi /etc/puppet/fileserver.conf
path = /var/puppet/files
اجازه *.server.com

این دو خط نشان می دهد که دایرکتوری /var/puppet/files باید برای همه میزبان ها در دامنه server.com قابل دسترسی باشد. علاوه بر این، می‌توانیم نام دامنه کامل یک ماشین مجاز یا آدرس IP آن را مشخص کنیم و همچنین موارد ناخواسته را با استفاده از دستور deny قطع کنیم. هر فایلی در آن دایرکتوری می تواند با استفاده از منبع فایل به مشتری منتقل شود. به عنوان مثال:

# vi /etc/puppet/manifests/site.pp
file("/etc/httpd/conf/httpd.conf":
منبع => "Puppet://httpd/httpd.conf"،
حالت => 644،
}

فایل httpd.conf که بر روی سرور در پوشه /var/puppet/files/httpd قرار دارد، در مسیر مشخص شده در نام منبع در ماشین مورد نظر کپی می شود.

نتیجه گیری

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

اطلاعات

• Puppet از پروتکل HTTP استفاده می کند، بنابراین می توان آن را تحت وب سرور اجرا کرد تا عملکرد را بهبود بخشد.
• از Puppet می توان برای پیکربندی خودکار و نگهداری یک ماشین محلی استفاده کرد.
• با ترکیب Puppet، نصب سیستم عامل شبکه (pxe-install) و تصاویر نصب خود ساخت، می توانید یک شبکه کاملاً خود پیکربندی از ماشین ها ایجاد کنید که فقط با یک فرمان قابل استقرار هستند.
• بسیاری از شرکت های بزرگ مانند گوگل، پروژه فدورا، دانشگاه استنفورد، رد هت، زیمنس IT Solution و SugarCRM از Puppet در کار خود استفاده می کنند.

پیوندها

• http://docs.puppetlabs.com - مستندات عروسکی
• http://docs.puppetlabs.com/guides/language_tutorial.html - توضیحات کاملزبان عروسکی
• http://docs.puppetlabs.com/references/stable/type.html - انواع منابع

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

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

• متن باز عروسکی - کاملا نسخه رایگان
• Puppet Enterprise - رایگان برای حداکثر 10 سرور، پس از آن مجوز لازم است

بیایید نصب سرور و عامل منبع باز عروسکی را در نظر بگیریم که در بسته های اکثر توزیع های مدرن موجود است. در ادامه در مورد اوبونتو 12.04 Precise Pangolin صحبت خواهیم کرد.

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

و حالا مشتری:

در فایل پیکربندی مشتری /etc/puppet/puppet.confشما باید با اضافه کردن بخش زیر در مورد سرور صحبت کنید:

Server=puppet.local report=true pluginsync=false

در مرحله اولیه، بهتر است pluginsync را خاموش کنید.

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

در سرور، باید بررسی کنید که درخواست گواهینامه دریافت شده است و اگر چنین است، گواهی صادر کنید:

مرحله قبل را روی مشتری تکرار کنید:

عالیه همه چی کار میکنه بیایید به ایجاد اولین مانیفست ادامه دهیم. مانیفست‌ها یا پیکربندی‌ها به زبانی خاص توصیف می‌شوند. ما بلافاصله به چیزهای خوب عادت خواهیم کرد، از ساختار و کلاس های مدولار استفاده می کنیم. به عنوان مثال، اجازه دهید ماژولی بنویسیم که فایل را به روز نگه می دارد /etc/hostsدر تمام سرورهای ما

بیایید بررسی کنیم که عروسک کجا به دنبال ماژول ها می گردد:

دایرکتوری هایی برای ماژول خود ایجاد کنید

اولین مانیفست که به عنوان فایل ماژول اصلی نیز شناخته می شود، باید فراخوانی شود init.pp

میزبان کلاس ( # puppet.local host ( "puppet.local": sure => "present", target => "/etc/hosts", ip => "192.168.0.1", host_aliases => "puppet", ) # میزبان linux.local ("linux.local": اطمینان => "present", target => "/etc/hosts"، ip => "192.168.0.2"، host_aliases => "linux"، ) )

به طور پیش فرض، عروسک به دنبال یک فایل می گردد /etc/puppet/manifests/site.ppبرای بارگذاری پیکربندی، اجازه دهید آن را به فرم زیر بیاوریم:

پیش‌فرض گره (شامل میزبان‌ها)

ما مانیفست را در سرور بررسی می کنیم:

در مورد مشتری:

پس از اینکه مطمئن شدیم همه چیز کار می کند، اجازه می دهیم سرویس شروع به کار کند /etc/default/puppetتغییر:

# عروسک را روی چکمه شروع کنیم؟ START=بله

شروع سرویس

Puppet هر 30 دقیقه از سرور puppetmaster برای تغییرات پیکربندی نظرسنجی می کند و در صورت لزوم، سیستم را بر اساس آن تنظیم می کند.

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

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

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

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

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

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

رکورد DNS باید به 127.0.0.2 برود
cat /etc/hosts:

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

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

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

شروع rcpuppetmasterd

بیایید راه اندازی شیطان عروسکی را به استارت آپ اضافه کنیم:

chkconfig -a puppetmasterd

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

vim /etc/puppet/fileserver

مسیر /etc/puppet/files
اجازه *

mkdir /etc/puppet/files

chown -R puppet:puppet /etc/puppet/files

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

/etc/puppet/files/puppettetesting را لمس کنید

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

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

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

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

file("/tmp/puppettetesting":
منبع => "puppet:///files/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 ایجاد کنید:

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

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

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

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

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

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

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

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

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

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

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

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

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

• ماژول- مجموعه ای از اسکریپت های نمایشی 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 شخص ثالث استفاده کنید اگر زیرساخت داخلی رضایت بخش نیست.
• کل پیکربندی (Environment) باید در یک سیستم کنترل نسخه ذخیره شود و به طور همزمان در هر سرور مستقر شود.
• تنها چیزی که مشترک است پایگاه داده PostgreSQL است که سازماندهی در دسترس بودن بالای آن از حوصله این مقاله خارج است.
• ماژول cfpuppetserver از نصب سرور اصلی (با CA) و ثانویه پشتیبانی می کند.

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

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

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

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

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

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

پیکربندی در Git

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 مستقر شود. به یک معنا، این یادآور مونتاژ یک کامپایلر در چند مرحله است.

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

در سیستم هدف:

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:// [ایمیل محافظت شده]/puppet-conf
   • مثال با محلی: bash setup_puppetserver.sh file:///root/puppetconf/
4. ما می بینیم که چگونه سیستم پف می کند و همه چیز را خیلی سریع نصب نمی کند.
5. اگر مخزن از راه دور باشد:
   • یک کلید SSH برای ریشه ایجاد کنید: ssh-keygen -t rsa -b 2048
   • ما کلید عمومی /root/.ssh/id_rsa.pub را در سرور Git راه دور ثبت می کنیم...
   • ... و در آنجا با فراخوانی دستور زیر یک قلاب Git راه اندازی کردیم: /usr/bin/ssh -T deploypuppet@puppet.$(MY_DOMAIN) ./puppetdeploy.sh
6. ما شروع به استقرار پیکربندی به صورت دستی می کنیم: /etc/puppetlabs/deploy.sh
7. بیایید نحوه عملکرد آن بر روی خود سرور را امتحان کنیم: /opt/puppetlabs/bin/puppet agent --test
8. تنظیمات شبکه، فیلتر شبکه و دسترسی SSH خود را بررسی کنید

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

1. نام کاملاً واجد شرایط سرور عروسکی باید از طریق DNS در میزبان مدیریت شده در دسترس باشد یا به صورت کدهای سخت در /etc/hosts موجود باشد.
   • مثال: 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. ما منتظر تکمیل استقرار از طریق Puppet Agent هستیم.
8. تمام است، شما یک زیرساخت حداقلی Puppet آماده دارید!

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

ضربه شدید</etc/cflocation fi if test! -z ""؛ سپس echo -n >/etc/cflocationpool fi if test! -z "\$http_proxy"؛ سپس http_proxy export https_proxy="\$http_proxy" export HTTP_PROXY="\$http_proxy" export HTTPS_PROXY="\$http_proxy" fi echo host.example.com > /etc/hostname 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 برای توقف چرخه، در صورت عدم موفقیت به دلایل مختلف استفاده کنید" خواب 5 انجام شد EOT

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

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