تُعَد إدارة ضبط الخادم (يُشار إليها أيضًا باسم أتمتة تقانة المعلومات IT Automation) حلًا لتحويل إدارة بنيتك التحتية إلى الشيفرة البرمجية الأساسية، ولوصف جميع العمليات اللازمة لنشر خادم في مجموعة من سكربتات الإعداد المسبق Provisioning Scripts التي يمكن إصدارها وإعادة استخدامها بسهولة، ويمكنها تحسين التكامل لأيّ بنية خادم تحتية بصورة كبيرة بمرور الوقت.

تحدثنا في مقال سابق عن الفوائد الرئيسية لتنفيذ إستراتيجية إدارة الضبط لبنية الخادم التحتية، وكيفية عمل أدوات إدارة الضبط والعناصر المشتركة بين هذه الأدوات. سنوضح في هذا المقال عملية أتمتة إعداد الخادم المسبق باستخدام الأداة Puppet، وهي أداة شائعة لإدارة الضبط قادرة على إدارة البنية التحتية المعقدة بطريقة شفافة باستخدام خادم رئيسي Master لتنسيق ضبط العقد، وسنركز على مصطلحات اللغة والصياغة والميزات اللازمة لإنشاء مثال مبسط للأتمتة الكاملة لنشر خادم ويب Ubuntu 18.04 باستخدام أباتشي Apache.

تحتوي القائمة التالية على جميع الخطوات التي نحتاجها للأتمتة حتى الوصول إلى هدفنا:

1. حدّث ذاكرة apt المخبئية.
2. ثبّت خادم أباتشي Apache.
3. أنشئ مجلد المستند الجذر المُخصَّص.
4. ضع ملف index.html في المستند الجذر المخصص.
5. طبّق قالبًا لإعداد المضيف الوهمي المخصص.
6. أعِد تشغيل أباتشي.

سنبدأ بإلقاء نظرة على المصطلحات التي تستخدمها أداة Puppet، ثم سنتعرّف على ميزات اللغة الرئيسية التي يمكن استخدامها لكتابة ملفات البيان Manifests، وسنشاركك في النهاية المثال الكامل لتتمكّن من تجربته بنفسك.

ملاحظة: يهدف هذا المقال إلى تعريفك بلغة Puppet وكيفية كتابة ملفات البيان لأتمتة إعداد خادمك المسبق. اطّلع على تثبيت الأداة Puppet لإدارة بنية الخوادم التحتية لمعرفة الخطوات اللازمة لتثبيت أداة Puppet والبدء باستخدامها.

هذا المقال جزء من سلسلة حول إدارة ضبط الخوادم، وإليك روابط فصول السلسلة:

• مدخل إلى إدارة ضبط الخوادم Configuration Management
• مبادئ إدارة ضبط الخوادم Configuration Management: كتابة دليل تشغيل الأداة Ansible
• مبادئ إدارة ضبط الخوادم Configuration Management: كتابة ملفات البيان Manifests للأداة Puppet
• مبادئ إدارة ضبط الخوادم Configuration Management: كتابة الوصفات Recipes في الأداة Chef

البدء باستخدام الأداة Puppet

يجب أن نتعرف أولًا على المصطلحات والمفاهيم المهمة التي قدمتها أداة Puppet قبل البدء بالعمل.

مصطلحات Puppet

تحتوي القائمة التالية على أهم المصطلحات التي تستخدمها أداة Puppet:

• جهاز Puppet الرئيسي Master: الخادم الرئيسي الذي يتحكم في الضبط على العقد.
• عقدة الوكيل الخاصة بالأداة Puppet: عقدة يتحكم فيها جهاز Puppet الرئيسي.
• ملف البيان Manifest: ملف يحتوي على مجموعة من التعليمات لتنفيذها.
• المورد Resource: جزء الشيفرة البرمجية الذي يصرّح عن عنصر في النظام وكيفية تغيير حالته، فمثلًا يجب لتثبيت حزمة تحديدُ المورد package والتأكد من ضبط حالته على أنه "مُثبَّت".
• الوحدة Module: مجموعة من ملفات البيان والملفات الأخرى ذات الصلة المنظمة بطريقة مُعرَّفة مسبقًا لتسهيل مشاركة وإعادة استخدام أجزاء من الإعداد المسبق.
• الصنف Class: تُستخدَم الأصناف في الأداة Puppet لتنظيم الإعداد المسبق بصورة أفضل وتسهيل إعادة استخدام أجزاء من الشيفرة البرمجية كما هو الحال مع لغات البرمجة العادية.
• الحقائق Facts: المتغيرات العامة التي تحتوي على معلومات حول النظام مثل واجهات الشبكة ونظام التشغيل.
• الخدمات Services: تُستخدَم لبدء تغييرات حالة الخدمة مثل إعادة تشغيل الخدمة أو إيقافها.

تُكتَب عمليات الإعداد المسبق الخاصة بالأداة Puppet باستخدام لغة المجال المحدَّد Domain Specific Language -أو DSL اختصارًا- المخصَّصة والتي تعتمد على لغة روبي Ruby.

الموارد Resources

تُعرَّف المهام أو الخطوات باستخدام الأداة Puppet من خلال التصريح عن الموارد، ويمكن أن تمثل الموارد الحزم والملفات والخدمات والمستخدمين والأوامر، ويكون لها حالة تؤدي إلى بدء تغيير النظام في حالة اختلاف حالة المورد المُصرَّح عنه عن حالته الحالية في النظام، فمثلًا سيؤدي ضبط المورد package على القيمة installed في ملف البيان إلى بدء تثبيت الحزمة على النظام إن لم مُثبَّتةً مسبقًا.

يكون مورد الحزمة package كما يلي:

package { 'nginx':
    ensure  => 'installed'
}

يمكنك تنفيذ أيّ أمر عشوائي من خلال التصريح عن المورد exec كما يلي:

exec { 'apt-get update':
    command => '/usr/bin/apt-get update'
}

لاحظ أن الجزء apt-get update في السطر الأول ليس التصريح عن الأمر الفعلي، بل هو معرِّفٌ لهذا المورد الفريد، إذ يجب في أغلب الأحيان الإشارة إلى موارد أخرى من موردٍ ما، ونستخدم معرّفها لذلك، حيث يكون المعرّف في حالتنا هو apt-get update، ولكن يمكن أن يكون أيّ سلسلة نصية أخرى.

اعتمادية الموارد Resource Dependency

يجب أن تضع في بالك أن الأداة Puppet لا تقيّم الموارد بترتيب تعريفها نفسه عند كتابة ملفات البيان، ويُعَد ذلك مصدر ارتباك شائع للأشخاص المبتدئين في استخدام الأداة Puppet، إذ يجب أن تعرِّف الموارد اعتماديتها بين بعضها البعض صراحةً، وإلّا فلن يكون هناك ضمان بشأن المورد الذي يجب تقييمه وتنفيذه أولًا.

لنفترض أنك تريد تنفيذ أمرٍ ما، ولكن يجب التأكد من تثبيت الاعتمادية أولًا كما يلي:

package { 'python-software-properties':
    ensure => 'installed'
}

exec { 'add-repository':
    command => '/usr/bin/add-apt-repository ppa:ondrej/php5 -y'
    require => Package['python-software-properties']
}

يأخذ الخيار require مرجعًا لمورد آخر بوصفه وسيطًا له، ونشير في هذه الحالة إلى مورد الحزمة Package المُعرَّف بوصفه python-software-properties. لاحظ أننا نستخدم exec و package وغير ذلك للتصريح عن الموارد (بأحرف صغيرة)، بينما نستخدم Exec و Package وغير ذلك (بأحرف كبيرة) عند الإشارة إلى الموارد المُعرَّفة مسبقًا.

لنفترض الآن أنه يجب التأكد من تنفيذ مهمةٍ قبل مهمة أخرى، حيث يمكننا استخدام الخيار before في هذه الحالة كما يلي:

package { 'curl':
    ensure => 'installed'
    before => Exec['install script']
}

exec { 'install script':
    command => '/usr/bin/curl http://example.com/some-script.sh'

تنسيق ملف البيان

تُعَد ملفات البيان مجموعة من تصريحات عن الموارد باستخدام الامتداد ‎.pp. يمكنك العثور فيما يلي على مثال لدليل تشغيل Playbook بسيط يؤدي مهمتين هما: تحديث ذاكرة apt المخبئية ثم تثبيت vim:

exec { 'apt-get update':
    command => '/usr/bin/apt-get update'
}

package { 'vim':
    ensure => 'installed'
    require => Exec['apt-get update']
}

سنرى لاحقًا مثالًا واقعيًا أكثر عن ملف البيان بالتفصيل، ولكن سيعطيك القسم التالي نظرة عامة على أهم العناصر والميزات التي يمكن استخدامها لكتابة ملفات بيان Puppet.

كتابة ملفات البيان

أصبحت الآن على دراية بالمصطلحات الأساسية والتنسيق العام لملف البيان في Puppet، لذا سنتعرف على بعض ميزات ملف البيان.

التعامل مع المتغيرات

يمكن تعريف المتغيرات في أي وقت في ملف البيان، وأكثر أنواع المتغيرات شيوعًا هي السلاسل النصية ومصفوفات السلاسل النصية، والأنواع الأخرى مدعومة أيضًا مثل القيم المنطقية والقيم المُعمَّاة المختصرة Hashes.

يعرّف المثال التالي متغير سلسلة نصية يُستخدَم لاحقًا ضمن موردٍ ما:

$package = "vim"

package { $package:
   ensure => "installed"
}

استخدام الحلقات Loops

تُستخدم الحلقات عادةً لتكرار مهمة باستخدام قيم دخل مختلفة، فمثلًا يمكنك إنشاء مهمة واحدة واستخدام حلقة لتكرار المهمة مع جميع الحزم المختلفة التي تريد تثبيتها بدلًا من إنشاء 10 مهام لتثبيت 10 حزم مختلفة. أبسط طريقة لتكرار مهمة بقيم مختلفة في Puppet هي باستخدام المصفوفات كما في المثال التالي:

$packages = ['vim', 'git', 'curl']

package { $packages:
   ensure => "installed"
}

تدعم الأداة Puppet من الإصدار 4 طرقًا إضافية لتكرار المهام، فمثلًا يطبّق المثال التالي الشيء نفسه الذي طبّقه المثال السابق، ولكن باستخدام المكرِّر each، حيث يمنحك هذا الخيار مزيدًا من المرونة لتكرار تعريفات الموارد:

$packages.each |String $package| {
  package { $package:
    ensure => "installed"
  }
}

استخدام التعليمات الشرطية

يمكن استخدام التعليمات الشرطية لتحديد ما إذا كان يجب تنفيذ كتلة من الشيفرة البرمجية أم لا ديناميكيًا بناءً على متغير أو خرج أمرٍ ما. تدعم الأداة Puppet معظم البنى الشرطية التي يمكنك العثور عليها باستخدام لغات البرمجة التقليدية مثل تعليمات if/else و case، وتدعم بعض الموارد مثل exec السمات التي تعمل بوصفها تعليمة شرطية، ولكنها تقبل فقط خرج الأمر بوصفه شرطًا.

لنفترض أنك تريد تنفيذ أمر بناءً على حقيقة Fact، إذ يجب في هذه الحالة استخدام أحد البنى الشرطية المدعومة مثل if/else عندما تريد اختبار قيمة متغير كما يلي:

if $osfamily != 'Debian' {
 warning('This manifest is not supported on this OS.')
}
else {
 notify { 'Good to go!': }
}

يوجد موقف شائع آخر عندما تريد وضع شرط لتنفيذ أمرٍ ما بناءً على خرج أمرٍ آخر، حيث يمكنك في هذه الحالة استخدام التعليمة onlyif أو unless كما في المثال الآتي، إذ لن يُنفَّذ هذا الأمر إلّا عندما يكون خرج ‎/bin/which php ناجحًا، أي أنّ الأمر ينتهي مع الحالة 0:

exec { "Test":
 command => "/bin/echo PHP is installed here > /tmp/test.txt",
 onlyif => "/bin/which php"
}

وبالمثل، سينفَّذ الأمر التعليمة unless في جميع الأوقات، إلّا عندما ينتهي الأمر الموجود ضمنها بنجاح:

exec { "Test":
 command => "/bin/echo PHP is NOT installed here > /tmp/test.txt",
 unless => "/bin/which php"
}

التعامل مع القوالب

تُستخدَم القوالب لإعداد ملفات الضبط، مما يسمح باستخدام المتغيرات والميزات الأخرى التي تهدف إلى جعل هذه الملفات أكثر تنوعًا وقابلية لإعادة الاستخدام. تدعم الأداة Puppet تنسيقين مختلفين للقوالب هما: قوالب Puppet المُضمَّنة Embedded Puppet -أو EPP اختصارًا- وقوالب روبي المُضمَّنة Embedded Ruby -أو ERB اختصارًا، ولكن يعمل تنسيق EPP فقط مع الإصدارات الحديثة من الأداة Puppet (بدءًا من الإصدار 4.0).

يوجد فيما يلي مثال على قالب ERB لإعداد مضيف أباتشي Apache الوهمي باستخدام متغير لإعداد المستند الجذر لهذا المضيف:

<VirtualHost *:80>
    ServerAdmin webmaster@localhost
    DocumentRoot <%= @doc_root %>

    <Directory <%= @doc_root %>>
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

يجب لتطبيق القالب إنشاء المورد file الذي يعرض محتوى القالب باستخدام التابع template، وإليك طريقة تطبيق هذا القالب لاستبدال مضيف أباتشي الوهمي الافتراضي:

file { "/etc/apache2/sites-available/000-default.conf":
    ensure => "present",
    content => template("apache/vhost.erb") 
} 

تضع الأداة Puppet بعض الافتراضات عند التعامل مع الملفات المحلية لفرض التنظيم والتقسيم إلى وحدات Modularity، حيث ستبحث الأداة Puppet عن ملف قالب vhost.erb ضمن المجلد apache/templates في مجلد وحداتك.

تعريف وبدء الخدمات

تُستخدَم موارد الخدمة service للتأكد من تهيئة الخدمات وتفعيلها، وتُستخدَم لبدء إعادة تشغيل الخدمة. لنأخذ مثالنا السابق لاستخدام القالب، حيث ضبطنا مضيف أباتشي الوهمي. إذا أردتَ التأكد من إعادة تشغيل أباتشي بعد تغيير المضيف الوهمي، فيجب أولًا إنشاء مورد خدمة service لخدمة أباتشي. إليك طريقة تعريف هذا المورد في Puppet:

service { 'apache2':
    ensure => running,
    enable => true
}

يجب الآن تضمين الخيار notify لبدء إعادة التشغيل عند تعريف المورد كما يلي:

file { "/etc/apache2/sites-available/000-default.conf":
    ensure => "present",
    content => template("vhost.erb"),
    notify => Service['apache2'] 
}

مثال عن ملف البيان

لنلقِ الآن نظرة على ملف البيان الذي سيؤدي إلى أتمتة عملية تثبيت خادم ويب أباتشي على نظام لينكس أوبنتو Ubuntu كما ناقشنا سابقًا. يمكنك العثور على المثال الكامل بما في ذلك ملف القالب لإعداد أباتشي وملف HTML ليخدّمه خادم الويب على Github، ويحتوي المجلد على الملف Vagrantfile الذي يتيح لك اختبار ملف البيان في إعداد مبسط باستخدام آلة افتراضية تديرها الأداة Vagrant.

إليك ملف البيان الكامل:

$doc_root = "/var/www/example"

exec { 'apt-get update':
  command => '/usr/bin/apt-get update'
}

package { 'apache2':
  ensure  => "installed",
  require => Exec['apt-get update']
}

file { $doc_root:
  ensure => "directory",
  owner => "www-data",
  group => "www-data",
  mode => 644
}

file { "$doc_root/index.html":
  ensure => "present",
  source => "puppet:///modules/main/index.html",
  require => File[$doc_root]
}

file { "/etc/apache2/sites-available/000-default.conf":
  ensure => "present",
  content => template("main/vhost.erb"),
  notify => Service['apache2'],
  require => Package['apache2']
}

service { 'apache2':
  ensure => running,
  enable => true
}

لنتعرّف على كل جزء من ملف البيان السابق بمزيد من التفصيل:

• يبدأ ملف البيان في السطر الأول بتعريف المتغير ‎$doc_root الذي يُستخدَم لاحقًا في تعريف المورد.
• ينفّذ المورد exec في الأسطر 3-5 الأمر apt-get update.
• يثبّت مورد الحزمة package في الأسطر 7-10 الحزمة apache2 محدّدًا أن مورد apt-get update مطلوب، مما يعني أنه لن يُنفَّذ إلا بعد تقييم المورد المطلوب.
• نستخدم مورد الملف file في الأسطر 12-17 لإنشاء مجلد جديد سيكون بمثابة المستند الجذر. يمكن استخدام المورد file لإنشاء مجلدات وملفات، ويُستخدَم لتطبيق القوالب ونسخ الملفات المحلية إلى الخادم البعيد، حيث يمكن تنفيذ هذه المهمة في أيّ مرحلة من الإعداد المسبق، لذلك لم نكن بحاجة إلى ضبط أيّ خيار require هنا.
• نستخدم مورد ملف file آخر في الأسطر 19-23 لنسخ ملف index.html المحلي إلى المستند الجذر ضمن الخادم، حيث نستخدم المعامل source للسماح لأداة Puppet بمعرفة مكان العثور على الملف الأصلي. تعتمد هذه التسمية على الطريقة التي تتعامل بها Puppet مع الملفات المحلية، فإذا ألقيت نظرة على مستودع المثال على Github، فسترى كيفية إنشاء بنية المجلد للسماح لأداة Puppet بالعثور على هذا المورد، ويجب إنشاء مجلد المستند الجذر قبل تنفيذ هذا المورد، لذا ضمّنا الخيار require الذي يشير إلى المورد السابق.
• يُستخدَم مورد ملف جديد في الأسطر 25-30 لتطبيق قالب أباتشي وإعلام الخدمة بإعادة التشغيل. نُظِّمت عملية الإعداد المسبق في وحدة تسمى main، لذا يكون مورد القالب هو main/vhost.erb. نستخدم التعليمة require للتأكد من أن مورد القالب template لا يُنفَّذ إلّا بعد تثبيت الحزمة apache2، وإلّا فلن تكون بنية المجلد التي يستخدمها أباتشي موجودة بعد.ص
• يصرّح مورد الخدمة service في الأسطر 32-35 عن الخدمة apache2، والتي نعلِمها بإعادة التشغيل من المورد الذي يطبّق قالب المضيف الوهمي.

الخلاصة

تُعَد الأداة Puppet أداة قوية لإدارة الضبط وتستخدم لغة DSL مُخصَّصة ومعبّرة لإدارة موارد الخادم وأتمتة المهام، وتقدّم لغتها مواردًا متقدمة يمكن أن توفّر مرونة إضافية لضبط إعدادك المسبق، إذ يجب أن تتذكر أن الموارد لا تُقيَّم بترتيب تعريفها نفسه، لذا يجب توخي الحذر عند تحديد الاعتماديات بين الموارد لإنشاء سلسلة التنفيذ الصحيحة.

سنلقي نظرة على الأداة Chef في المقال التالي، وهي أداة قوية أخرى لإدارة الضبط وتستفيد من لغة برمجة روبي Ruby لأتمتة إدارة البنية التحتية والإعداد المسبق.

ترجمة -وبتصرُّف- للمقال Configuration Management 101: Writing Puppet Manifests لصاحبته Erika Heidi.

اقرأ أيضًا

• تنصيب Puppet لإدارة البنية التَّحتِيَّة للخواديم
• الإدارة عن بعد باستخدام Puppet على خواديم أوبنتو
• تنصيب Puppet لإدارة البنية التَّحتِيَّة للخواديم

Puppet هو إطار عمل متعدد المنصات يُمكِّن مدراء النظام من إجراء المهام الشائعة باستخدام الكود؛ يمكن أن يقوم الكود بالعديد من المهام، من تثبيت برمجية جديدة إلى التحقق من أذونات الملفات، أو تحديث حسابات المستخدم؛ إن Puppet ليس رائعًا فقط أثناء عملية التثبيت الأساسية للنظام، بل أيضًا أثناء «دورة حياة» النظام بأكملها. يُستخدَم Puppet في معظم الحالات بنمط ضبط «خادوم/عميل».

سيغطي هذا الدّرس طريقة تثبيت وضبط Puppet كخادوم/عميل، سيشرح المثال البسيط الآتي طريقة تثبيت خادوم أباتشي باستخدام Puppet.

التثبيت

أدخِل الأمر الآتي في طرفية الخادوم لتثبيت Puppet:

sudo apt-get install puppetmaster

وعلى جهاز أو أجهزة العميل؛ أدخِل الأمر:

sudo apt-get install puppet

الضبط

قبل ضبط Puppet، ربما عليك إضافة سجل «DNS CNAME» من أجل puppet.example.com، حيث example.com هو النطاق الخاص بك؛ حيث يتحقق عملاء Puppet من سجل DNS للنطاق puppet.example.com كاسم خادوم Puppet، أو «Puppet Master»؛ وسنشرح خدمة أسماء النطاق (DNS) في درسٍ لاحقٍ في هذه السلسلة.

إذا لم تشأ أن تستخدم DNS، فبإمكانك إضافة قيود إلى ملف ‎/etc/hosts في الخادوم والعميل. على سبيل المثال، أضِف ما يلي في ملف ‎/etc/hosts على خادوم Puppet:

127.0.0.1 localhost.localdomain localhost puppet
192.168.1.17 puppetclient.example.com puppetclient

وأضِف قيدًا للخادوم على كل عميل Puppet:

192.168.1.16 puppetmaster.example.com puppetmaster puppet

ملاحظة: استبدل عناوين IP الموجودة في المثال السابق بعناوين IP لخادومك وعملائك.

لنهيّء الآن بعض الموارد من أجل حزمة apache2، أنشئ الملف ‎/etc/puppet/modules/apache2 ‎/manifests/init.pp الذي يحتوي الآتي:

class apache2 { 
  package { 'apache2': 
    ensure => installed, 
  } 
  
  service { 'apache2': 
    ensure => true, 
    enable => true, 
    require => Package['apache2'], 
  } 
}

أنشئ الآن الملف ‎/etc/puppet/manifests/site.pp الذي يحتوي على:

node 'pupetclient.example.com' {
  include apache2 
}

ملاحظة: استبدل pupetclient.example.com باسم مضيف عميل Puppet الحقيقي.

الخطوة النهائية لخادوم Puppet البسيط هي إعادة تشغيل العفريت:

sudo service puppetmaster restart

لقد أتممنا ضبط خادوم Puppet، حان الآن الوقت لضبط العميل.

أولًا، اضبط عفريت Puppetagent لكي يعمل، أي عدِّل ملف ‎/etc/default/puppet مغيّرًا START إلى yes:

START=yes

ثم ابدأ تشغيل الخدمة:

sudo service puppet start

واعرض بصمة (fingerprint) شهادة العميل:

sudo puppet agent --fingerprint

وبالعودة إلى خادوم Puppet، اعرض طلبات توقيع الشهادات:

sudo puppet cert list

وفي خادوم Puppet، تأكد من بصمة العميل ووقِّع على شهادة العميل بكتابة:

sudo puppet sign pupetclient.example.com

وفي عميل Puppet، شغِّل برنامج puppet يدويًا في الأمامية (foreground)؛ هذه الخطوة ليست مطلوبة لكنها أفضل طريقة لاختبار وتنقيح عمل خدمة puppet.

sudo puppet agent --test

راجع ‎/var/log/syslog لأيّة أخطاء بالضبط؛ إذا جرى كلُ شيءٍ على ما يرام، فستُثبَّت حزمة apache2 وجميع اعتمادياتها على عميل Puppet.

ملاحظة: هذا المثال بسيطٌ جدًا، ولا يُظهِر العديد من ميزات ومحاسن Puppet؛ راجع القسم المصادر التالية للمزيد من المعلومات .

مصادر

• توثيق موقع Puppet الرسمي.
• راجع أيضًا كتاب «Pro Puppet».
• مصدر آخر لمعلوماتٍ إضافية هو صفحة ويكي أوبنتو «Puppet»

ترجمة -وبتصرف- للمقال Ubuntu Server Guide: Puppet.

هذا المقال هو الجزء الثّالث من سلسلة استخدام puppet لإدارة الخواديم التي تتكوّن من كل من:

• تنصيب Puppet لإدارة البنية التَّحتِيَّة للخواديم
• ملفّات البيان (Manifests) والوحدات (Modules) في Puppet
• كيف تستخدم Foreman لإدارة نقاط Puppet على الخادوم Ubuntu 14.04

مُقدمة

Foreman هي أحد الأدوات مَفتوحة المَصدر، والّتي تُستخدم في إدارة الخواديم، وذلك بتوفير طريقة سهلة ومرنة في العمل جنبًا إلى جنبٍ مع الأداة Puppet (أو Chef) وذلك بهدف أتمتة المهام ونشر التطبيقات، وهي مناسبة لكافة أحجام البُنى التَّحْتِيَّة، وتعمل على معظم توزيعات لينكس. تُقدّم هذه التسهيلات عبر توفير واجهة ويب، وAPI، وبالإضافة إلى أوامر الطرفية CLI، مما يجعل الإعداد المُسبق provisioning ومُراقبة الخواديم أسهل من أي وقتٍ مضى.

سيتناول هذا الشرح كيفيّة تنصيب الأداة Foreman مع الأداة Puppet، واستخدامها في إدارة الخواديم. سيتمّ استغلال Foreman في قدرتها على إصدار التقارير وميزة External Node Classifier والّتي يُشار إليها بالاختصار (ENC)، بهدف تسهيل إدارة الأداة Puppet.

مُتَطَلَّبات بيئة العمل

سيتمّ تنصيب الأداة Foreman على خادوم جديد، يحمل الاسم “foreman”، وسيُمثل خادومًا مَركزيًّا آخر للأداة Puppet. يُمكن تنصيب الأداة Foreman على الخادوم المَركزيّ الحالي، ولكن يجب التنبه هنا إلى أنّه سيتمّ استبدال ملف البيان الافتراضيّ site.pp بمَلفّ جديد، وذلك من شأنه أنّ يُلغي العلاقة بين العُملاء الحاليين والخادوم المَركزيّ، ويُمكن تجاوز ذلك بالإعداد مرّة أخرى ليُدير الخادوم Foreman نقاط العُملاء هذه Puppet agent nodes

تَعتمد الأداة Foreman على الأداة Puppet بشكل كبير لإدارة إعدادات العُملاء، ولذلك فمن الضروريّ توفّر الأمور التّالية قبل البدء بتطبيق محتويات هذا الشرح:

• صلاحيّة وصول كامل: بالاستعانة بالأمر sudo يُمكن عمل كافّة التغيرات المطلوبة.
• خدمة DNS على الشبكة الخاصّة: إعداد خدمة DNS لترجمة أسماء الخواديم إلى IPs أي (Forward DNS lookup)، وترجمة الـIPs إلى أسماء الخواديم أي (reverse DNS lookup)، ويَجب على كل خادوم أنّ يَمتلك اسمًا فريدًا خاصًا به على مستوى الشبكة الداخلية. يُمكن الرجوع إلى الشرح الخاصّ كيفية إعداد خادوم DNS في الشبكة الخاصّة. في حال عدم توفّر خادوم DNS، فيُمكن استخدام الملف hosts لترجمة العناوين.
• إعداد الجدار الناري firewall: من الضروريّ الوصول إلى الخادوم المَركزيّ الخاصّ بالأداة Puppet عبر المنفذ 8140، ولذلك يجب التأكد من عدم منع الجدار الناري لهذا المنفذ. يُمكن الاستعانة بالشرح التّالي لمعرفة كيفية السماح بالطلبات الواردة باستخدام UFW.

بعد إتمام المُتَطَلَّبات السابقة من المُمكن الآن الانتقال إلى إنشاء الخادوم Foreman والذي سيكون بنفس الوقت هو خادوم مَركزيّ Puppet master.

إنشاء خادوم Foreman

سيتمّ إنشاء خادوم جديد يعمل بالتوزيعة Ubuntu 14.04 x64، ويحمل اسم المجال المؤهل بالكامل “foreman.nyc2.example.com”، وإعداد خادوم DNS بناءً على هذا الاسم.

يُمكن الرُجوع إلى القسم الخاصّ بـ صيانة سجلات DNS في حال عدم توفّر المَعرفة لفعل ذلك. في حقيقة الأمر كل ما يجب عمله هو إضافة سجلّين الأول من نوع “A” والثاني من نوع “PRT”، والسماح للعميل الجديد بعمل استعلامات دوريّة recursive queries، وأيضًا يجب التأكد من إعداد DNS لترجمة أسماء الخواديم من دون استخدام “اسم النطاق المُؤهل بالكامل” Fully Qualified Domain Name

التأكّد من أنّ اسم الخادوم هو اسم المجال المؤهل بالكامل:

لمعرفة اسم الخادوم الكامل FQDN يُمكن استخدام الأمر التّالي

hostname –f

الأمر السابق يجب أنّ يَعرض اسم المجال المؤهل بالكامل الخاصّ بالخادوم أي “foreman.nyc2.example.com”، وفي حال عرض اسم فقط أي “foreman” فيجب إجراء التعديلات التالية:

• تحرير الملف hosts ليُشير السجل 127.0.0.1 إلى اسم المجال الكامل.

سيتمّ استخدام المُحرر Vi:

sudo vi /etc/hosts

السجل سيكون بالشكل التّالي:

127.0.1.1       foreman

ليُعدّل ويصبح بالشكل التّالي:

127.0.1.1       foreman.nyc2.example.com foreman

• تحرير الملف hostname

سيتمّ تحرير المَلفّ الخاصّ باسم الخادوم:

sudo vi /etc/hostname

يجب التأكد من أنّ الاسم هو اسم المجال الكامل:
 

“foreman.nyc2.example.com”

ولتطبيق التعديلات بشكل مُباشر وآني يُمكن تنفيذ الأمر التّالي:

sudo hostname --file /etc/hostname

تنصيب الأداة Foreman

سيتمّ استخدم المُنصب الخاصّ بالأداة Foreman، فهو أسهل طريقة لتنصيب هذه الأداة مع المُكونات الخاصّة بها، مع إعدادات افتراضيّة تسمح لنا بالعمل بشكل أسرع مع الأداة، وذلك بتوفير العناصر التّالية:

• تنصيب الأداة Foreman
• تنصيب الأداة Puppet
• خادوم الويب Apache مع SSL والوحدة Passenger

سيتمّ في البداية إضافة مستودع Foreman:

sudo sh -c 'echo "deb http://deb.theforeman.org/ trusty 1.5" > /etc/apt/sources.list.d/foreman.list'
sudo sh -c 'echo "deb http://deb.theforeman.org/ plugins 1.5" >> /etc/apt/sources.list.d/foreman.list'
wget -q http://deb.theforeman.org/pubkey.gpg -O- | sudo apt-key add –

تحميل المُنصب:

sudo apt-get update && sudo apt-get install foreman-installer

قبل تشغيل المُنصب يجب التأكد من أنّ الأمر ping $(hostname –f) يُظهر العنوان الحقيقي للخادوم وليس العنوان 127.0.0.1

تشغيل المُنصب:

sudo foreman-installer

الأمر السابق يعرض مُخرجات output كما في التّالي:

Your puppet version does not support progress bar
Preparing installation Done
  Success!
  * Foreman is running at https://foreman.nyc2.example.com
      Default credentials are 'admin: hzdQZPZ97KJ32BKn '
  * Foreman Proxy is running at https://foreman.nyc2.example.com:8443
  * Puppetmaster is running at port 8140
  The full log is at /var/log/foreman-installer/foreman-installer.log

تدلّ السطور السابقة على استكمال تنصيب الأداة بشكل صحيح. كما تعرض بيانات الدخول المُستخدمة مع واجهة الويب.

تفعيل Diffs

يَسمح تفعيل الخيار “diffs” لمُدير النظام باستعراض تغييرات مَلفّ الإعدادات على شكل تقرير ضِمن الأداة Foreman Reports.

ولتفعيل هذه الميزة سيتمّ تحرير المَلفّ puppet.conf:

sudo vi /etc/puppet/puppet.conf

وتغيير قيمة الخيار show_diff إلى true:

    show_diff     = true

إضافة الخادوم Foreman إلى قاعدة البيانات

يَقوم الأمر puppet agent بإضافة الخادوم “foreman” إلى قاعدة البيانات الخاصّة بالأداة Foreman، وبذلك يكون الخادوم “foreman” أول عميلٍ خاصّ بالأداة Foreman، وتتمّ إدارته من قبلها.

sudo puppet agent –test

تسجيل الدخول باستخدام واجهة الويب

يجب في بداية الأمر الدخول وتغير كلمة المرور الخاصّة بحساب المُدير admin، حيثُ يُمكن الوصول لواجهة الويب عن طريق الشبكة العامّة public network الخاصّة بالخادوم الافتراضيّ الخاصّ VPS، إما عن طريق اسم المجال المؤهل بالكامل أو عنوان الـIP public network.

يَستخدم Foreman بشكل افتراضيّ شهادات الأداة Puppet، والّتي على الأغلب لن تكون مَوثوقة بالنسبة للمُتصفح. يُمكن تجاهل التحذير الخاص بالمُتصفح في الوقت الحالي، أو يُمكن استبدال الشهادة الحالية بأُخرى تُطابق اسم المجال ومُوقعة من قبل مُفوّض شهادات مَوثوق (trusted CA authority). بغض النظر عن الطريقة المُتبعة في الاستمرار ستكون صفحة تسجيل الدخول على الشكل التّالي:

عند تنصيب الأداة Foreman بالأمر foreman-installer كانت بيانات الدخول الافتراضيّة على الشكل التّالي، والّتي سيتمّ استخدامها لتسجيل الدخول:

• اسم المُستخدم: admin
• كلمة المُرور: hzdQZPZ97KJ32BKn

لوحة المعلومات المُختصرة الخاصّة بالأداة Foreman

يُظهر تسجيل الدخول مُباشرةً لوحة التحكم، ويُعرض من خلالها نظرة شاملة على بيئة عمل Puppet، حيثُ يوجد مُلَخَّص يُسمى “حالة إعدادات المُضيف” (Host Configuration Status)، والذي يَعرض عدد نقاط العُملاء (Puppetagent nodes) وحالة كلٍ منها. يُظهر المُلَخَّص الحالي خادوم وحيد وذلك في القسم “good host”.

يوجد في الجانب الأسفل من المُلَخَّص السابق مُلَخَّص آخر للأحداث الأخيرة، ورسمٌ بيانيٌ مع عدد العُملاء الّتي قامت بعمل اتصال في الثلاثين دقيقة الأخيرة. تُقدّم هذه المعلومات لمحة عامّة وشاملة عن عمل منظومة Puppet.

كما ستكون لوحة المعلومات على الشكل التّالي عند وجود أي خطأ:

تغيير كلمة مرور حساب المُدير Admin Password

تمّت الإشارة سابقًا إلى ضرورة تغيير كلمة مُرور حساب المُدير admin ولعمل ذلك يجب التوجّه إلى “Admin User” في الزاوية العلوية من جهة اليمين والنقر على “My account”:

ومنها إلى النماذج واختيار الكلمة المناسبة.

إضافة خدمة مُزامنة الوقت NTP إلى Foreman

تتطلّب Puppet الحفاظ على دقةٍ وانسجامٍ في الوقت بين الخواديم، ولهذا سوف يُستخدم Foreman لإدارة خدمة NTP على المُضيف “foreman” والذي هو بنفس الوقت Puppet master.

يُمكن التوجّه إلى https://forge.puppetlabs.com والبحث عن الوحدة NTP لمعرفة المزيد عنها وماتُقدمه، والّتي ستكون بالاسم puppetlabs/ntp.

سيتمّ تنصيب الأداة NTP البيئة “production” الخاصّة بالأداة Puppet master وذلك عبر الأمر التّالي:

sudo puppet module install -i /etc/puppet/environments/production/modules puppetlabs/ntp

من المُفترض عرض مخرجات كما في التّالي والتي تدل على تنصيب الوحدة module بشكل صحيح:

Notice: Preparing to install into /etc/puppet/environments/production/modules ...
Notice: Downloading from https://forge.puppetlabs.com ...
Notice: Installing -- do not interrupt ...
/etc/puppet/environments/production/modules
└─┬ puppetlabs-ntp (v3.1.2)
  └── puppetlabs-stdlib (v4.3.2)

قد تمّ تنصيب الوحدة على Puppet master، ولكن يجب إضافتها إلى الأداة Foreman قبل أنّ يُصبح بالإمكان استخدامها.

في واجهة الويب الخاصّة بالأداة Foreman، ومن القائمة “configure” والاختيار “puppet classes”:

سيتمّ النقر على الزر “Import from foreman.nyc2.example.com”:

ومن ثمّ اختيار بيئة العمل “production”، ثُمّ الضغط على الزر “update”، وبذلك تكون الوحدة ntp مُستوردة imported داخل الأداة Foreman، وجاهزة للاستخدام.

الاستغناء عن الإعدادات الافتراضيّة للأداة NTP

من الجيّد اختيار إعدادات مُخصّصة بدلًا من الافتراضيّة للأداة NTP لتوافق الموقع الجغرافي للخواديم الخاصّة بنا، ويُمكن الرجوع إلى صفحة المشروع لاختيار الخيار الأنسب.

في الصفحة السابقة وهي “Puppet Classes”، وبعد الضغط على الصنف “ntp”، سيتمّ الانتقال إلى وضع التحرير، ومنه إلى التبويب “Smart Class Parameter”

وبعد التدرّج بالصفحة إلى الأسفل يوجد اختيار بالاسم “servers” في الشريط الجانبيّ

بعد اختيار “servers”، سيتمّ اختيار “Override”، وذلك لكتابة الإعدادات المُخصّصة. بعد ذلك سيتمّ اختيار نوع المُعامل ليكون على شكل مصفوفة array، وبعد ذلك سيتمّ تغيير القيمة الافتراضيّة إلى القيم المُخصّصة، وذلك على شكل مصفوفة.

["0.us.pool.ntp.org","1.us.pool.ntp.org","2.us.pool.ntp.org","3.us.pool.ntp.org"]

أصبح من المُمكن تطبيق الإعدادات وذلك بالضغط على “Submit”. بعد تطبيق الإعدادات المُخصّصة فإن أي عميل يستخدم هذه الوحدة ستكون هذه الإعدادات المُخصّصة هي الافتراضيّة الخاصّة به.

إعداد Foreman ليستخدم الوحدة NTP

أصبح الآن من المُمكن استخدام الوحدة NTP في إدارة الأداة NTP على المُضيف Foreman.

من القائمة “Hosts”، ومن ثمّ الاختيار “ALL Hosts”، ومن ثمّ زر التحرير “Edit” على الجانب الأيمن.

من التبويب “puppet classes”، ومن القسم الخاصّ بالأصناف المُتاحة، سيتمّ الضغط على الصنف “ntp” لتوسيعه، بعد ذلك سيتمّ الضغط على إشارة الزائد (+) الّتي بجانب الخيار “ntp”.

سينتقل الصنف “ntp” بعد الضغط على إشارة الزائد إلى القسم الخاصّ بالأصناف المُدرجة. بذلك ستُطبّق هذه الوحدة على العُملاء عند اتصالها مع الخادوم المَركزيّ، ولتطبيق الإعدادات سيتمّ الضغط على “submit”.

استعراض إعدادات Puppet

بعد الانتهاء من إعداد المُضيف السابق والضغط على زر “الإرسال”، سيتمّ الانتقال التلقائي إلى صفحة مُلخّص المُضيف.

ولرؤية المعلومات الّتي تمّ تطبيقها على العميل عند الاتصال بالخادوم المَركزيّ، يُمكن الضغط على زر “YAML”.

لتُعرض المعلومات على الشكل التّالي:

---
classes:
  ntp:
    server_list:
    - 0.us.pool.ntp.org
    - 1.us.pool.ntp.org
    - 2.us.pool.ntp.org
    - 3.us.pool.ntp.org
parameters:
  puppetmaster: foreman.nyc2.example.com
  root_pw: 
  foreman_env: production
  owner_name: Admin User
  owner_email: root@nyc2.example.com
environment: production

تشغيل عميل Puppet

سيتمّ تطبيق التغييرات السابقة الآن، ودون الحاجة للانتظار للاتصال التّالي، ولذلك سيتمّ تشغيل نسخة العميل من الأداة Puppet على الخادوم Foreman.

sudo puppet agent –test

بهذا يكون قد تمّ استخدام الأداة Foreman لإعداد الخادوم “foreman”، وإنّ إعداد بقية خواديم العُملاء هو مُشابه تمامًا لما تمّ عمله مع الخادوم “foreman”.

إضافة عُملاء جُدد إلى Foreman

الآن بعد أنّ انتهى إعداد الخادوم Foreman، أصبح بالإمكان إضافة المزيد من hosts لتصبح مُدارة من قبل الأداة Foreman، وطريقة الإضافة هي نفس طريقة إضافة نقاط عُملاء Puppet إلى الخادوم المَركزيّ. يتوفّر المزيد من التفاصيل في [الجزء الأول](رابط الجزء الأول) من هذه السلسلة. مع الانتباه إلى ربط العُملاء مع الخادوم المَركزيّ للأداة Puppet (وهو الخادوم Foreman في نفس الوقت).

يجب توقيع الشهادة الخاصّة بكل عميل على الخادوم Foreman، ويتمّ ذلك عبر سطر الأوامر، كما تمّ الأمر مع إعداد Puppet، أو من المُمكن استخدام واجهة الويب الخاصّة بالأداة Foreman.

يُمكن استخدام واجهة الويب لتوقيع الشهادات من الصفحة “smart proxy” والاختيار “Certificates”.

أو بالإمكان حذف شهادة عميل حاليّة:

الخاتمة

الآن وبعد أنّ تمّ بناء خادوم Foreman، أصبح من المُمكن استخدام الوحدات الخاصّة بالأداة Puppet على مستوى مُتقدم من الفعاليّة لإدارة الخواديم على مستويات متعددة وفي كامل البِنيَة التَّحتيَّة، ومن المُستحسن الآن استعراض المزيد من الوحدات المُتوفّرة على مُجتمع Puppet، أو حتّى كتابة وحدة جديدة مخصّصة لُتلبي احتياجات مُعيّنة.

ترجمة -وبتصرّف- للمقال How To Use Foreman To Manage Puppet Nodes on Ubuntu 14.04 لصاحبه Mitchell Anicas

هذا المقال هو الجزء الثّاني من سلسلة استخدام puppet لإدارة الخواديم التي تتكوّن من كل من:

• تنصيب Puppet لإدارة البنية التَّحتِيَّة للخواديم
• ملفّات البيان (Manifests) والوحدات (Modules) في Puppet
• كيف تستخدم Foreman لإدارة نقاط Puppet على الخادوم Ubuntu 14.04

مُقدمة

بعد إتمام إعداد منظومة Puppet الّتي تعتمد على مفهوم الخادم المَركزيّ والعُملاء، أصبح من المُلائم الآن التطرّق إلى آليّة كتابة الوحدات modules ومَلفّات البيان manifests، ولكي تُستخدام الأدة Puppet بالشكل الأمثل، يجب فهم بنية أوتركيبة هذا النوع من الملفات. سوف يتناول هذا الشرح أساسيات الشيفرة الخاصّة بالأداة Puppet، وكيفيّة بناء مَلفّات البيان والوحدات التي تساعد على فهم المبادئ الأساسية في استخدام Puppet لإدارة الخوادم، وذلك عن طريق شرح ثلاث طرق لاستخدام هذه الأداة في إعداد حِزم LAMP على خادم Ubuntu 14.04 يعمل على "خادم افتراضيّ خاصّ" VPS.

مُتَطَلَّبات بيئة العمل

قبل الشروع في تطبيق مُحتويات هذا الشرح من الضروريّ توفّر بيئة عمل تستخدم نظام العُملاء والخادم المَركزيّ باستخدام الأداة Puppet، ويمكن الرجوع إلى الجزء الأول من هذا الشرح لمزيد من التفاصيل عن كيفية تنصيب Puppet لإدارة البنية التحتية للخوادم ، كما أنّه يجب توفّر خادم جديد ليكون نقطة عميل (Puppet agent node) للخادم المَركزيّ Puppet master.

إنشاء نقطة عميل جديدة

سيتمّ إنشاء خادم جديد يعمل بتوزيعة أوبونتو 14.04 ويحمل الاسم “lamp-1”، وتنصيب الأداة Puppet عليه، وضمّه إلى بقيّة العُملاء المُدارة من قبل الخادم المَركزيّ، وذلك بنفس الطريقة الّتي تمّت بها إضافة العُملاء في الجزء الأول.

أساسيات كتابة شيفرة Puppet

ستتمّ مراجعة بعض المفاهيم والمُصطلحات المُرتبطة بالأداة Puppet، وذلك قبل الخوض في التفاصيل في كتابة الشيفرة الخاصّة بها.

المَوارد

تتكوّن شيفرة الأداة Puppet بشكلٍ أساسيّ من تصريحات المَورِد resource declarations، والّتي تَصف حالةً مُعينة من النظام، مثل اسم مُستخدم مُعين أو وجوب وجود مَلفٍّ مُعين، أو حتّى وجوب توفّر أحد الحزم على الخادم. في الشيفرة التّالية مثالٌ على تصريح مَورِد لاسم مُستخدم مُعيّن:

user { 'samir':
  ensure     => present,
  uid        => '1000',
  gid        => '1000',
  shell      => '/bin/bash',
  home       => '/home/samir'
}

تَكون بنية تصريح المَورِد على الشكل التّالي:

resource_type { 'resource_name'
  attribute => value
  ...
}

نوع المَورِد { 'اسم المَورِد'
  الخاصيّة => القيمة
  ...
}

يصف تصريح المَورِد السابق مَورِدًا مُعينًا وهو اسم المُستخدم "samir" والخواصّ الخاصّة به. يتمّ استعراض أنواع المَوارِد الافتراضيّة المُتاحة للأداة Puppet، بتنفيذ الأمر التّالي:

puppet resource --types

مَلفّات البيان Manifests

تُدعى التعليمات الخاصّة بالأداة Puppet بمَلفّات البيان manifests، والّتي تحتوي على شيفرة Puppet، وهذه الملفات تستخدم اللاحقة .pp. يوجد مَلفّ البيان الافتراضيّ في المسار /etc/puppet/manifests/site.pp.

في الجزء الأول من هذا الشرح تمّ كتابة مَلفّ بيانٍ كانت مُهمته إنشاء مَلفّ وتنصيب خادم الويب Apache، سوف يتمّ كتابة المزيد من هذا النوع من المَلفّات في هذا الجزء.

الأصناف Classes

الأصناف في Puppet هي عبارة عن قطعة من الشيفرة البرمجية والتي من المُمكن استدعائها في أي مكان من شيفرةً ما. تُوتيح استخدام الأصناف إعادة استخدام الشيفرة، مما يُقلّل من وقت التعديل وصيانة الشيفرة في وقتٍ لاحقٍ. كما تجعل هذه الأصناف من مَلفّ البيان أوضح وأسهل في الفهم والقراءة.

كيفيّة تعريف الصنف

يجعل تعريف الصنف من الصنف مُستخدمًا في أجزاءٍ مُختلفة من مَلفّات البيان manifests، ولكن في نفس الوقت هذه الأصناف لا تُفسر. يوضح المثال التّالي كيفيّة كتابة وتعريف الصنف في Puppet.

class example_class {
  ...
  code
  ...
}

تُعرّفُ السطورُ السابقة صنفًا بالاسم “example_class”، وتتوضع الشيفرة الخاصّة بالأدة Puppet بين الحاصِرتين “{}”

التصريح عن الأصناف

لا يتمّ التصريح عن الصنف إلا عندما يتمّ استدعاؤه في مَلفّ البيان manifest، حيثُ أنّ هذا التصريح يخبر الأداة Puppet أنّ تقوم بتفسير evaluate الشيفرة المُتوضعة داخل هذا الصنف، ويُمكن التصريح عن الأصناف بطريقتين مختلفتين: طريقةٌ عادية normal، وطريقةٌ تشبه طريقة التصريح عن المَورِد resource-like.

تَكون طريقة التصريح العادية باستخدام الكلمة المفتاحيّة include ضمّن شيفرة الأداة Puppet، كما في المثال التّالي:

include example_class

ستقوم الأداة Puppet بتفسير الشيفرة الموجودة داخل الصنف “example_class” بعد التصريح السابق.

يحدث النوع الثّاني من التصريح عندما يتمّ التصريح عن الصنف كما هو الحال عند التصريح عن مَورِد، و كما في المثال التّالي:

class { 'example_class': }

يسمح استخدام النوع الثّاني من التصريح resource-like بتحديد مُعاملات parameters، والتي تقوم بتجاهل وتجاوز القيم الافتراضيّة لخواصّ الصنف class attributes. في حال الرجوع إلى الجزء الأول من هذا الشرح فسيتضح أنّه بالفعل قد تمّ استخدام هذا النوع من التصاريح عندما تمّ استخدام الوحدة المُقدمة من معامل Puppet لتنصيب خادم الويب Apache على الخادم “host2”.

node 'host2' {
  class { 'apache': }             # use apache module
  apache::vhost { 'example.com':  # define vhost resource
    port    => '80',
    docroot => '/var/www/html'
  }
}

والآن بعد أنّ تمّ شرح المَوارِد ومَلفّات البيان والأصناف، سيتمّ تناول الوحدات modules بمزيد من التفصيل.

الوحدات Modules

تتألّف الوحدات من مجموعة من مَلفّات البيان manifests ومجموعة من المُعطيات (مثل الحقائق facts ومَلفّات files، ونماذج templates)، ولهذه المجموعة تنظيم مساري مُحدد. تُساعد الوحدات على تنظيم شيفرة الأداة Puppet، حيثُ أنّها تُقدم المُرونة في تقسيم الشيفرة البرمجية المتمثّلة بمَلفّات البيان إلى أجزاءٍ مُستقلة، ويُعتبر ذلك طريقةً فعّالةً وعمليّة في استخدام الوحدات لتنظيم معظم مَلفّات البيان manifests الخاصّة بالأداة Puppet.

تُوضع الوحدات modules الخاصّة بالأداة Puppet في المسار /etc/puppet/modules.

سيتمّ التطرّق إلى التفاصيل اللازمة لكتابة وحدة مُبسّطة basic module، ولمزيد من التفاصيل يُمكن الرجوع إلى التوثيق الرّسميّ والجزء الخاص بأساسيات الوحدة في Puppet.

تطوير مَلفّ البيان

لشرح كيفيّة كتابة ملفّات البيان الخاصّة، والأصناف والوحدات، سوف يتمّ استخدام Puppet لإعداد وتنصيب حِزم LAMP على نظام التشغيل أوبونتو (بشكل مُشابه إلى هذا الشرح)، ومن الجيّد قراءة هذا الشرح لمعرفة كيفيّة تنصيب وإعداد هذه الحِزم بشكلٍ يدويّ قبل استخدام Puppet في ذلك.

الهدف النهائي الذي يصبو إليه هذا الشرح هو خادم أوبونتو مع العناصر التّالية:

• تنصيب حزمة خادم الويب Apache
• تشغيل خدمة خادم الويب Apache
• تنصيب حزمة خادم قواعد البيانات MySQL
• تشغيل خدمة خادم قواعد البيانات MySQL
• تنصيب حزمة PHP5
• مَلفّ script لاختبار PHP وهو الملف info.php
• تحديث "أداة الحزم المتقدمة" apt قبل تنصيب الحِزم السابقة.

فيما يلي ثلاثة أقسام تشرح طُرقًا مُختلفة لاستخدام الأداة Puppet لتحقيق نفس الغاية، وهي خادم يحتوي على الحِزم LAMP ويعمل بشكل مُلائم. سيُوضّح المثال الأول كيفيّة كتابة مَلفّ بيان وحيد وبشكل مُبسّط، أما المثال الثّاني سيوضّح كيفيّة بناء واستخدام الأصناف والوحدات بناءً على مَلفّ البيان المطوّر في المثال الأول، وأخيرًا سيوضّح المثال الثّالث كيفيّة استخدام وحداتٍ مُطوّرة بشكل مُسبق لإعداد حِزم LAMP بشكلٍ سريعٍ وسهل.

المثال الأول: تنصيب حِزم LAMP باستخدام مَلفّ بيان وحيد:

هذا المثال هو مُلائم جدًا لمُدراء الأنظمة الذين لم يكتبوا مَلفّ بيان من قبل، سيُطوَّر مَلفُّ البيان على نقطة عميل Puppet agent node، ويُنفذ باستخدام الأمر puppet apply، ولذلك ليس من الضروريّ توفّر منظومة العُملاء والخادم المَركزيّ لإتمام هذا المثال.

سيتمّ التركيز على كيفيّة كتابة مَلفّ بيان يَستخدم الأنواع التّالية من تصاريح المَورِد resource declarations:

• exec: لتنفيذ الأوامر مثل الأمر apt-get
• package: لتنصيب حزمة باستخدام الأداة apt
• service: لتأكد من عمل خدمة ما
• file: للتأكد من وجود ملفٍ ما أوعدمه

إنشاء مَلفّ البيان

سيتمّ إنشاء مَلفّ بيان جديد على خادم جديد يحمل الاسم "lamp-1" باستخدام الأمر التّالي:

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

وبإضافة السطور التالية إلى المَلفّ السابق يكون قد تمّ التصريح عن المَوارِد المطلوبة.

# تحديث أداة الحزم المتقدمة
exec { 'apt-update':                    # exec resource named 'apt-update'
  command => '/usr/bin/apt-get update'  # command this resource will run
}

# تنصيب خادم أباتشي
package { 'apache2':
  require => Exec['apt-update'],        # require 'apt-update' before installing
  ensure => installed,
}

# التأكد من عمل خدمة أباتشي
service { 'apache2':
  ensure => running,
}

# تنصيب خادم قاعدة البيانات
package { 'mysql-server':
  require => Exec['apt-update'],        # require 'apt-update' before installing
  ensure => installed,
}

# التأكد من عمل خادم قاعدة البيانات
service { 'mysql':
  ensure => running,
}

# تنصيب لغة بي إتش بي
package { 'php5':
  require => Exec['apt-update'],        # require 'apt-update' before installing
  ensure => installed,
}

# التأكد من وجود مَلفّ
file { '/var/www/html/info.php':
  ensure => file,
  content => '<?php  phpinfo(); ?>',    # phpinfo code
  require => Package['apache2'],        # require 'apache2' package before creating
}

أصبح من المُمكن الآن استخدام الأمر puppet apply، الذي يُعتبر من نوع standalone، فهو يختلف عن الأمر puppet agent الذي يستدعي مَلفّ البيان من الخادم المَركزيّ. لتنفيذ مَلفّ البيان وهو ما سوف يتمّ عمله على الخادم "lamp-1" سيتمّ تنفيذ الأمر التّالي:

sudo puppet apply --test

سوف يتمّ عرض سطور عدّة كمخرجات output، يَظهر من خلالها حالة الخادم والتغييرات الّتي تمّت عليه، وذلك بشكل مُتوافق مع ما تمّ التصريح به من مَوارِد في مَلفّ البيان manifest. في حال عدم وجود أخطاء،أو مشاكل في عملية الإعداد، فيُفترض عند استعراض الصفحة info.php عرض معلومات تُشير إلى عمل خادم الويب Apache ولغة PHP كما هو مطلوب.

لم يكن الإعداد السابق إلّا إعدادًا بسيطًا لما يُمكن عمله بالأداة Puppet، وذلك أنّه لم يتمّ استخدام منظومة الخادم المَركزيّ والعُملاء (agent/master setup)، أيضًا لا يتوفّر مَلفّ البيان السابق لبقية العُملاء لاستخدامه مرّةً أُخرى، كما لاتقوم الأداة Puppet بالتَفحّصِ بشكل دوريٍّ (كلّ 30 دقيقة) من حالة خوادمها في حال أنّها مُتوافقة مع ما هو مُعدّ لها في مَلفّ البيان.

في المثال الثّاني، سوف يتمّ تحويل مَلفّ البيان السابق إلى وحدة module، وبذلك يُصبح من المُمكن استخدامه مع بقيّة العُملاء.

المثال الثّاني: تنصيب حِزم LAMP باستخدام الوحدات modules

سيتمّ إنشاء وحدة مُبسّطة اعتمادًا على مَلفّ بيان حِزم LAMP المُطوّر في المثال السابق، وذلك بالاستعانة بالخادم المَركزيّ Puppet master. يتمّ إنشاء وحدة جديدة عبر إنشاء مسار جديد في المسار modules الخاصّ بالأداة Puppet، وهذا المسار يجب أنّ يُطابق اسم الوحدة الجديدة، مُحتويًا بداخله مسارًا بالاسم manifests، وبداخله مَلفّ init.pp. هذا المَلفّ يجب أنّ يحتوي فقط على صنف يُطابق اسم الوحدة.

إنشاء الوحدة Module

لإنشاء وحدة جديدة سيتمّ إنشاء مسار جديد بالاسم lamp، والذي هو اسم الوحدة أيضًا:

cd /etc/puppet/modules
sudo mkdir -p lamp/manifests

ومن ثُمّ إنشاء وتحرير مَلفّ الوحدة init.pp

sudo vi lamp/manifests/init.pp

داخل هذا المَلفّ سيتمّ إنشاء صنف بالاسم “lamp”

class lamp {

}

بعد ذلك سيتمّ نسخ مُحتويات مَلفّ البيان الّذي تمّ إنشاؤه في المثال الأول داخل هذا الصنف، وبذلك يكون قد تمّ تعريف صنف جديد بالاسم “lamp”، ولكن الشيفرة التي يحتويها هذا الصنف لن يتمّ تفسيرها (evaluate) هنا، ولكنها أصبحت جاهزة لكي تُستدعى (أي يُصرح عنها)، وأصبح بالإمكان الوصول إلى هذا الصنف كوحدة module من قبل مَلفّات البيان الأُخرى، وذلك فقط لأنّه يُحقّق قواعد تعريف الوحدة طبقًا للأداة Puppet.

استخدام الوحدات Modules في مَلفّ البيان الرئيسيّ

بعد أنّ تمّ إنشاء مَلفّ وحدة مُبسّط، سيتمّ إعداد مَلفّ البيان الرئيسيّ (main manifest) لاستخدامه في تنصيب حِزم LAMP على الخادم “lamp-1”.

على الخادم الرئيسيّ للأداة Puppet والذي يحمل الاسم “puppet” سيتمّ تحرير مَلفّ البيان الرئيسيّ:

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

ومن ثمّ إضافة السطور التّالية، مع الانتباه أنّه في حال وجود إعدادات مُسبقة في هذا المَلفّ من الجزء الأول فلا بأس من خذفها.

node default { }

node 'lamp-1' {

}

تَسمح قطعة نقطة node block بتحديد شيفرة Puppet التي سوف تُطبّق على نقطة عميل مُعين، وتُطبّق النقطة “default” على جميع نقاط العُملاء التي لا تملك قطعة نقطة مُحددة لها، وهي في المثال السابق فارغة ولن يتمّ التعديل عليها. ما يهم من المثال السابق هو قطعة النقطة الّتي تحمل الاسم “lamp-1” والّتي سوف تُطبّق على العميل “lamp-1” فقط.

سيتمّ تضمين الوحدة “lamp” داخل قطعة النقطة “lamp-1”.

  include lamp

ستكون النتيجة النهائيّة للمّلفّ السابق على الشكل التّالي:

de default { } 

node 'lamp-1' {
  include lamp 
}              

بعد الإعداد السابق، ستقوم نسخة العميل من الأداة Puppet الموجودة على الخادم “lamp-1” عند سحب الإعدادات الخاصّة بها من الخادم المَركزيّ، بتفسير مَلفّ البيان الرئيسي وتنفيذ الوحدة “lamp” لإعداد حِزم LAMP، وفي حال الرغبة في التجربة المُباشرة دون انتظار الاتصال التلقائيّ، بالإمكان تنفيذ الأمر التّالي على الخادم “lamp”

sudo puppet agent --test

بعد استكمال كافة الإعدادات من الجيّد التأكد من أنّ الأمور تيسير على مايُرام، وذلك باستعراض الصفحة info.php على خادم “lamp”.

http://lamp_1 _IP/info.php

أو استخدام الأداة cURL من الطرفيّة terminal.

من المُلاحظ أنّه بالإمكان الآن إعادة استخدام الوحدة الخاصّة بالخادم “lamp” الّتي تمّ إنشاؤها بالتصريح عنها في node blocks أُخرى. إنّ استخدام الوحدات هو أفضل طريقة لتهيئة شيفرة Puppet لإعادة استخدامها مرّة أُخرى، كما أنّ استخدام الوحدات يُساعد على تنظيم الشيفرة بأسلوب منطقيّ، الأمر الذي ينعكس على قراءة وفهم الشيفرة الخاصّة بالأدة Puppet.

المثال الثّالث: تنصيب حِزم LAMP باستخدام وحدات مُعدّة مُسبقًا

يوجد مُستودعٌ خاصٌّ بالوحدات مُتوفّر على Puppet Forge، والذي يُسهل من الإعداد عند تطوير البِنْيَة التَّحْتِيَّة. يُمكن تنصيب الوحدات المُعدّة مُسبقًا بشكلٍ سريعٍ عبر الأمر puppet module، ومن ضمن هذه الوحدات المُعدّة مُسبقًا يوجد وحدات خاصّة بتنصيب خادم الويب Apache وخادم قواعد البيانات MySQL. لذلك سوف يتمّ استخدامُ هذه الوحدات الجاهزة في إعداد حِزم LAMP.

تنصيب وحدات Apache وMySQL

سيتمّ تنصيب الوحدة ذات الاسم puppetlabs-apache على الخادم “master” باستخدام الأمر التّالي:

sudo puppet module install puppetlabs-apache

يَعرض الأمر السابق مُخرجات تُشير إلى تنصيب الوحدات بشكل صحيح:

Notice: Preparing to install into /etc/puppetlabs/puppet/modules ...
Notice: Downloading from https://forgeapi.puppetlabs.com ...
Notice: Installing -- do not interrupt ...
/etc/puppet/modules
└─┬ puppetlabs-apache (v1.0.1)
  ├── puppetlabs-concat (v1.0.0) [/etc/puppet/modules]
  └── puppetlabs-stdlib (v3.2.0) [/etc/puppet/modules]

أيضًا الوحدة الخاصّة بخادم قاعدة البيانات puppetlabs-mysql:

sudo puppet module install puppetlabs-mysql

وبهذا تكون الوحدات “apache” و”mysql” جاهزة للاستخدام.

تحرير مَلفّ البيان الرئيسي

أما الآن وبعد أنّ تمّ تحميل هذه الوحدات، سيتمّ تحرير مَلفّ البيان الرئيسي ليستخدم الوحدات الجديدة لتنصيب حِزم LAMP، وذلك بتحرير هذا الملف على الخادم “master”.

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

يُمكن حذف أيّة إعدادات مُسبقة في حال وجودها، ومن ثمّ إضافة السطور التّالية:

node default { }

node 'lamp-1' {

}

سيتمّ التصريح عن صنف باستخدام نمط المَورِد ليستخدم الوحدة الّتي تحمل الاسم “apache”، وذلك داخل النقطة “lamp-1”:

class { 'apache':                # use the "apache" module
    default_vhost => false,        # don't use the default vhost
    default_mods => false,         # don't load default mods
    mpm_module => 'prefork',       # use the "prefork" mpm_module
  }
   include apache::mod::php        # include mod php
   apache::vhost { 'example.com':  # create a vhost called "example.com"
    port    => '80',               # use port 80
    docroot => '/var/www/html',    # set the docroot to the /var/www/html
  }

تقبل الوحدة “apache” مُعاملات parameters، والّتي من شأنها إلغاء الإعدادات الافتراضيّة الخاصّة بها، في السطور السابقة تمّ تمرير بعض الإعدادات البسيطة، حيثُ تمّ تعطيل المُضيف الافتراضيّ، والاستعاضة عنه بمُضيف يستطيع استخدام PHP، لمزيد من التفاصيل، يُمكن مُراجعة الموقع الرسميّ.

استخدام الوحدة الخاصّة بخادم قواعد البيانات MySQL مُشابه لاستخدام الوحدة الخاصّة Apache. لن يتمّ تعقيد الإعداد هنا باعتبار أنّه لن يتمّ استخدام قواعد البيانات في مثالنا بشكلٍ فعليّ. سيتمّ إضافة السطور إلى داخل node block.

 class { 'mysql::server':
    root_password => 'password',
  }

كما في وحدة خادم الويب Apache، من المُمكن تخصيص إعداد وحدة MySQL بتمرير مُعاملات parameters، ولمزيد من التفاصيل يُمكن الرجوع إلى الموقع الرسميّ.

أما الآن فسيتمّ إضافة مَلفّ مَورِد مُهمته التأكد من نسخ المف info.php إلى المكان المُلائم. هذه المرّة سيتمّ استخدام المُعامل “source”، كما هو مُوضح في السطور التّالية.

  file { 'info.php':                                # file resource name
    path => '/var/www/html/info.php',               # destination path
    ensure => file,
    require => Class['apache'],                     # require apache class be used
    source => 'puppet:///modules/apache/info.php',  # specify location of file to be copied
  }

يختلف التصريح السابق نسبيًا عمّا تمّ سابقًا، الاختلاف هو أنّه تمّ استخدام المُعامل “source” بدلًا من المُعامل “content”، حيثُ يخبر المُعامل “Source” الأداة Puppet بأنّ تقوم بنسخ المَلف بدلًا من كتابة محتواه. تُفسّر الأداة Puppet المصدر المُحدد (القيمة) puppet:///modules/apache/info.php إلى /etc/puppet/modules/apache/files/info.php، ولذلك يجب إنشاء مَلفّ المصدر لكي يعمل تصريح المَورِد السابق بشكل صحيح.

يتمّ إنشاء الملف info.php بتنفيذ الأمر التّالي:

sudo sh -c 'echo "<?php  phpinfo(); ?>" > /etc/puppet/modules/apache/files/info.php'

بعد أنّ يقوم العميل “lamp-1” بسحب إعداداته من الخادم المَركزيّ، سيقوم بتفسير evaluate مَلفّ البيان الرئيسيّ وتطبيق الوحدة الّتي تُشكل إعداد حِزم LAMP. لتطبيق الإعدادات الجديدة بشكل مُباشر يُمكن استخدام الأمر التّالي على الخادم “lamp-1”:

sudo puppet agent --test

بعد الانتهاء، ستكون حِزم LAMP مُنصبة، كما في المثال الأول، وللتأكد من عمل خادم الويب Apache وPHP، يُمكن استعراض الصفحة التّالية:

http://lamp_1 _IP/info.php

تَعرض الصفحة السابقة معلومات عن استكمال تنصيب مُفسّر PHP بشكلٍ مُلائم، أيضًا بذلك يكون خادم الويب Apache مُنصبًا بشكل صحيح.

الخاتمة

في هذه المرحلة وبعد مُتابعة الأمثلة السابقة وتطبيقها، والّتي قَدمت معرفة أساسية في استخدام الشيفرة الخاصّة بالأداة Puppet، وطريقة كتابة مَلفّ بيانٍ مُبسّط، وتطوير الوحدات modules، أصبح من المُمكن استخدام Puppet لإعداد أمورٍ أُخرى في منظومة الخوادم، وإدارتها بشكل يُلبي الحاجة أكثر مما هو عليه الأمر من دونها.

يُعتبر استخدام الأداة Puppet في إدارة النظام والمُستخدمين والتطبيقات وغيره من المَوارد بدايةً جيّدة لاستغلال هذه الأداة بالشكل الأمثل. مع الانتباه إلى أنّ تغيير هذه المَوارد يجب أنّ يتمّ على الخادم المَركزيّ، وإلا سوف يتم إلغاء هذه التغييرات في المرّة القادمة الّتي تقوم بها العُملاء بالاتصال الدوريّ لسحب إعداداتها من الفهرس الخاصّ بها.

في الجزء الثّالث والأخير من هذه السلسلة سيتمّ التعرّف على الأداة Foreman لإدارة العُملاء. 

ترجمة -وبتصرّف- للمقال Getting Started With Puppet Code: Manifests and Modules

ستتناول هذه السلسلة حول استخدام puppet لإدارة الخواديم، والّتي هي عبارة عن ثلاثة أجزاء، الأداة Puppet وما تُقدمه لمُدراء الخوادم من تسهيلات في إدارة وإعداد الخوادم، وكيفيّة كتابة الشيفرة الخاصّة بهذه الأداة، كما سيتمّ التعامل مع الأداة Foreman والتعرّف على ماتُقدمه في هذا الخصوص. تُركز السلسلة على التطبيق العمليّ، لذلك يُنصح بالتطبيق المُباشر للأفكار المَطروحة فذلك أفضل سبيلٍ لتثبيث المَعلومة واحتراف التعامل مع هذه الأداة.

مقالات سلسلة "استخدام puppet لإدارة الخواديم :

• تنصيب Puppet لإدارة البنية التَّحتِيَّة للخواديم
• ملفّات البيان (Manifests) والوحدات (Modules) في Puppet
• كيف تستخدم Foreman لإدارة نقاط Puppet على الخادوم Ubuntu 14.04

مُقدّمة

تُقدم مَعامل Puppet أداةً لإدارة الإعدادات وتُطلق عليها Puppet، ومُهمتها مُساعدةُ مُدراء الأنظمة في أتمتت الإعداد المُسبق provisioning وإعداد وإدارة البِنْيَة التَّحْتِيَّة الخاصّة بالخوادم. يُقلل التخطيط المُسبق واستخدام أدوات إدارة الإعدادات مثل الأداة Puppet من الوقت المُستغرق في تكرار المَهام الأساسية، ويُساعد على التأكّد من أنّ الإعدادات مَضْبُوطَةً بشكل دقيق، وتقومُ على أساسٍ واحد فيما بينها في جميع الخوادم. سيتوفّر المَزيد مِن الوقت الذي من المُمكن استغلاله في تحسين جوانب أُخرى في إعداد مَنظومة العمل، بعد احتراف إدارة الخوادم باستخدام الأداة Puppet أو حتّى أي أداة أتمتة أُخرى.

يتوفّر إصداران من الأداة Puppet، إصدار المشاريع الكبيرة والمؤسسات Puppet Enterprise، والمَفتوح المَصدر. تعمل الأداة Puppet على مُعظم توزيعات نظام التشغيل لينكس ومُختلف مِنصّات UNIX وأنظمة التشغيل Windows.

سيتناول هذا الشرح كيفيّة تنصيب الإصدار مفتوح المَصدر من الأداة Puppet على نظام رئيسيّ Master ومُمثل/عميل Agent، حيثُ يتألّف هذا النظام أو التقسيم من خادمٍ مركزيّ Puppet Master يحتوي جميع الإعدادات والبيانات المطلوبة لاستكمال المنظومة الإدارية للخوادم، وباقي الخوادم هي عُمَلاء للجهاز المَركزيّ Puppet Agent، والتي تُدار من قِبَله.

مُتَطَلَّبات بيئة العمل

يَتطلّب تطبيق وإتمام هذا الشرح صلاحيّة وصولٍ كامل root access على جميع الخوادم الّتي ستكون جزء من منظومة Puppet، كما يُطلب إنشاء خادم جديد بتوزيعة Ubuntu الإصدار 14.04 والذي سوف يُمثل النظام المَركزيّ للأداة Puppet.

قبل الشروع بتنصيب الأداة Puppet يجب التأكّد من الأمور التّالية:

• نظام أسماء النطاقات DNS للشبكة الخاصّة: يجب إعداد خادم DNS لتحويل العناوين بالاتّجاهين، من الأسماء إلى IPs ومن IPs إلى الأسماء، ويَجب على كل خادم أنّ يَمتلك اسمًا فريدًا خاصًا به. يُمكن الرجوع إلى الشرح التّالي بعنوان: إعداد خادم الـ DNS في الشبكة الداخليّة لإعداد الخادم الداخليّ، ويَجب استخدام المَلفّ hosts لترجمة الأسماء إلى عنوانين IPs بشكلٍ يدويٍّ في حال عدم توفّر مُخدم DNS.
• مَنافِذُ مَفتوحة على الجدارِ الناريّ firewall: تعمل الأداة Puppet على المنفذ 8140، لذلك في حال وجود جدارٍ ناريٍّ يُقيد الوصول عبر هذا المنفذ فيُمكن الرجوع إلى الشرح الخاصّ بالأداة UFW لاستعراض الخطواط المَطلوبة للسماح بمرور الطلبات عَبْر هذا المَنفذ.

سيتمّ العمل على الخوادم التّالية الآن، ولاحقًا سيُضاف إليها خادمٌ في الجزء الثّاني، وآخر في الثّالث.

ستتمّ تنصيب الأداة Puppet على جميع الخوادم السابقة. بيئة العمل السابقة هي نفسها الّتي تمّ العمل بها في هذا الدّرس.

إنشاء الخادوم المَركزيّ Puppet Master Server

سيتمُّ استخدام توزيعة أوبونتو الإصدار 14.04 لتَكوْن الخادم المَركزيّ، ويحمل الخادم الاسم “puppet”.

يُمكن الرُجوع إلى القسم الخاصّ بـ صيانة سجلات DNS في حال عدم توفّر المَعرفة لفعل ذلك. في حقيقة الأمر كل ما يجب عمله هو إضافة سجلّين الأول من نوع "A" والثاني من نوع "PRT"، والسماح للعميل الجديد بعمل استعلامات دوريّة recursive queries، وأيضًا يجب التأكد من إعداد DNS لترجمة أسماء الخوادم من دون استخدام "اسم النطاق المُؤهل بالكامل" Fully Qualified Domain Name.

استخدام الاسم "puppet" للجهاز المَركزيّ سوف يُبسّط إعداد خوادم العُملاء بشكلٍ نسبيٍّ، وذلك لأنّه الاسم الافتراضيّ الذي سوف تَستخدمه هذه العُملاء عند مُحاولتها الاتصال مع الخادم الرئيسيّ Puppet Master.

تنصيب NTP

يجب على الخادم الرئيسيّ/المَركزيّ puppet master الحفاظ على توقيتٍ دقيقٍ في ساعة النظام لتفادي أو تجنب المشاكل المُحتملة عند إصدار شهادات العُملاء، وذلك بصفته مُفوّض الشّهادة للعُملاء agent. حيثُ كما يبدو أنّ صلاحيّة هذه الشهادات قد تنتهي عند وجود تعارضٍ في الوقت، ومن أجل ذلك سوف نستخدم "بروتوكول توقيت الشبكة" Network Time Protocol والذي يُشار إليه بالاختصار NTP.

من المُمكن عمل مُزامنة يدويّة ولمرّة واحدة باستخدام الأمر ntpdate

sudo ntpdate pool.ntp.org

يقوم الأمر السابق بتحديث الوقت، ولكن من الضروريّ الاعتماد على الأداة ntpd من أجل المُزامنة التلقائيّة وذلك من شأنه أنّ يقلّل من زمن ظاهرة "انجراف الوقت" Clock drift.

sudo apt-get update && sudo apt-get -y install ntp

من الشائع تحديث إعدادات بروتوكول NTP ليستخدم "pools zones" قريبةً جغرافيًا من خادم NTP، حيثُ من المُمكن الرجوع إلى مشروع NTP والبحث عن أقرب pool zone إلى مركز البيانات datacenter المُستخدم، وللتعديل سوف يتمّ تحرير الملف المُسمى ntp.conf بواسطة المُحرر Vi، والذي سوف يتمّ استخدامه طوال هذه السلسلة في التحرير.

sudo vi /etc/ntp.conf

سوف يتمّ إضافة الخوادم التّالية في بداية مَلفّ الإعدادات:

server 0.us.pool.ntp.org
server 1.us.pool.ntp.org
server 2.us.pool.ntp.org
server 3.us.pool.ntp.org

يتمّ حِفظ الإعدادات السابقة إما بتنفيذ الأمر :wq، أي الحفظ والخروج، أو عبر الاختصار ZZ. والآن يجب إعادة تشغيل الخدمة ليتمّ إضافة الخوادم الجديدة.

sudo service ntp restart

تنصيب الخادوم المَركزيّ Install Puppet Master

يوجد طرقٌ عدّة لتنصيب Puppet Master الإصدار مفتوح المصدر، سوف يتمّ استخدام حزمةٍ خاصّة مُقدمة من Puppet Labs وتُسمى “puppetmaster-passenger”، والّتي تتضمّن Puppet master بالإضافة إلى خادم ويب مُجهزٍ بشكل مُسبق للعمل مُباشرةً (Passenger مع Apache)، وذلك من شأنه أنّ يُسهل عمليّة الإعداد مُقارنةً مع الحزمة الأساسيّة فقط puppetmaster.

يقوم الأمر التّالي بتحميل الحزمة السابقة الذكر من موقع PuppetLabs في المَسار الرئيسيّ $HOME

cd ~; wget https://apt.puppetlabs.com/puppetlabs-release-trusty.deb

ولتنصيب الحزمة يتمّ تنفيذ الأمر التّالي:

sudo dpkg -i puppetlabs-release-trusty.deb

ومن ثمّ التحديث للحصول آخر الحزم المُتوفّرة.

sudo apt-get update

ومن ثمّ تنصيب حزمة puppetmaster-passenger.

sudo apt-get install puppetmaster-passenger

وبهذا يكون قد تمّ تنصيب:

• الخادم المَركزيّ Puppet master
• خادم الويب Apache
• الحِزم المَطلوبة لعملية الإعداد

بسبب استخدام الحزمة الخاصّة (Apache مع Passenger) يتحكم خادم الويب Apache بالأداة Puppet master، بمعنى أنّ هذه الخدمة سوف تعمل عندما يعمل خادم الويب Apache، وتتوقف بتوقفه.

قبل المُتابعة سوف يتمُ إيقاف Puppet master وذلك بإيقاف خدمة apache2:

sudo service apache2 stop

قفل الإصدار الحالي

يُسبب في بعض الأحيان الانتقال من إصدارٍ لإصدارٍ آخر إلى توقّف منظومة الأدة Puppet عن العمل بشكلٍ مُلائمٍ، لذلك من الجيّد الحفاظ على إصدار الأداة Puppet في كامل المَنظومة على إصدار مُوحّد. وفي حال التحديث، من الضروريّ تحديث النسخة المَركزيّة master قبل نسخة العُملاء agent، حيثُ أنّ النسخة المَركزيّة لاتستطيع إدارة نُسخ العُملاء مع إصدارٍ أحدث من إصدارها.

لمعرفة الإصدار الحالي للأداة Puppet يُمكن تنفيذ الأمر التّالي:

puppet help | tail -n 1

الإصدار الحالي والذي تعتمد عليه هذه السلسلة هو Puppet v3.7.4. من المُمكن استخدام الأداة APT وميزة pin لقفل إصدار الأداة Puppet للتحديثات الجذرية major والبسيطة minor والسماح بالترقيعات patches -يُمكن الرُجوع إلى الإدارة الدلاليّة لنُسخ البرمجيات لمزيد من التفاصيل حول إدارة الإصدار- ولذلك سوف يتمّ إنشاء مَلفّ جديد في المسار الخاصّ بتفضيلات الأداة apt.

sudo vi /etc/apt/preferences.d/00-puppet.pref

كما سوف يتمّ قفل التحديثات لثلاث حزم وهي: puppet، puppet common، puppetmaster-passenger وذلك بإضافة السطور التالية إلى المَلف السابق.

# /etc/apt/preferences.d/00-puppet.pref
Package: puppet puppet-common puppetmaster-passenger
Pin: version 3.7*
Pin-Priority: 501

إعداد الأسماء والشهادات

تستخدم الأداة Puppet شهادات SSL لتوثيق الاتصال بين الخادم المَركزيّ والعُملاء، حيثُ يُمثل الجهاز المَركزيّ دور "مُفوّض الشهادة" certificate authority، ويجب على CA أنّ يُولد الشهادة الخاصّة به والّتي تُستخدم في توقيع طلبات شهادات العُملاء.

التخلّص من الشهادات الحاليّة

يجب حذف أيّة شهادات SSL حاليّة قد تمّ إنشاؤها أثناء تنصيب حزمة puppet لإعداد مُفوّض الشهادة بشكل مُلائم. المسار الافتراضيّ لشهادات SSL الخاصّة بالحزمة توجد في المسار التّالي: /var/lib/puppet/ssl

sudo rm -rf /var/lib/puppet/ssl

إعداد الشهادة

عند إنشاء شهادة الجهاز المَركزيّ، يجب إضافة أي اسم DNS من المُمكن أنّ تستخدمه العُملاء للاتصال مع الجهاز المَركزيّ puppet master، في المثال الحالي سوف يتمّ إضافة اسم الخادم “puppet”، و"اسم نطاق مؤهل بالكامل" “puppet.nyc2.example.com”، وذلك بتحرير مَلفّ الإعدادات التّالي:

sudo vi /etc/puppet/puppet.conf

والذي يحتوي على البيانات التّالية:

[main]
logdir=/var/log/puppet
vardir=/var/lib/puppet
ssldir=/var/lib/puppet/ssl
rundir=/var/run/puppet
factpath=$vardir/lib/facter
templatedir=$confdir/templates

[master]
# These are needed when the puppetmaster is run by passenger
# and can safely be removed if webrick is used.
ssl_client_header = SSL_CLIENT_S_DN
ssl_client_verify_header = SSL_CLIENT_VERIFY

سيتمّ حذف السطر الخاصّ بالخيار templatedir بعد أنّ أصبح غير مُستخدمًا بعد الآن، ومن ثمّ إضافة السطرين التاليين إلى نهاية القسم [main].

certname = puppet
dns_alt_names = puppet,puppet.nyc2.example.com

من الضروريّ تخصيص اسم الشهادة certname بالاسم “puppet”، لأنّ إعدادات Apache/Passenger مُعدّة لأنّ يكون اسم الشهادة بهذا الاسم. في جميع الأحوال يُمكن تخصيص الاسم حسب الرغبة بالتعديل على مَلفّ الإعداد الخاصّ بـApache:

/etc/apache2/sites-available/puppetmaster.conf

وبهذا يكون قد تمّ الانتهاء من الإعداد بشكل مُلائم بعد الحفظ والخروج.

توليد شهادةٍ جديدة

يتمّ إنشاء شهادة جديدة بتنفيذ الأمر التّالي:

sudo puppet master --verbose --no-daemonize

الأمر السابق سوف يعرض معلومات تُشير إلى إنشاء الشهادات ومفاتيح SSL، كما يُشير السطر الأخير بدء عمل الأداة Notice: Starting Puppet master version 3.7.4

Info: Creating a new SSL key for ca
Info: Creating a new SSL certificate request for ca
Info: Certificate Request fingerprint (SHA256): EC:7D:ED:15:DE:E3:F1:49:1A:1B:9C:D8:04:F5:46:EF:B4:33:91:91:B6:5D:19:AC:21:D6:40:46:4A:50:5A:29
Notice: Signed certificate request for ca
...
Notice: Signed certificate request for puppet
Notice: Removing file Puppet::SSL::CertificateRequest puppet at '/var/lib/puppet/ssl/ca/requests/puppet.pem'
Notice: Removing file Puppet::SSL::CertificateRequest puppet at '/var/lib/puppet/ssl/certificate_requests/puppet.pem'
Notice: Starting Puppet master version 3.7.4

لمعرفة معلومات عن الشهادة التي تمّ إصدارها بالإمكان تنفيذ الأمر التّالي:

sudo puppet cert list -all

يعرض الأمر السابق قائمة بجميع الشهادات المُوقعة وطلبات الشهادة غير المُوقعة. حتّى الآن سوف يعرض الأمر السابق الشهادة الخاصّة بالخادم الرئيسيّ فقط، وذلك لأنّه لم يتمّ إضافة أي شهادات أخرى ليتمّ عرضها.

+ "puppet" (SHA256) A5:72:AA:19:AF:E8:D2:9A:E8:99:B9:F0:19:B6:0A:7D:05:0D:0D:F6:BA:CE:F5:09:6F:73:0F:0C:DE:24:11:84 (alt names: "DNS:puppet", "DNS:puppet.nyc2.example.com")

إلى هنا تكون الخدمة الخاصّة بالجهاز المَركزيّ Puppet master service هي تقريبًا جاهزة للعمل.

إعداد الجهاز المَركزيّ Puppet Master

يحتوي مَلفّ الإعداد الرئيسيّ الخاصّ بالأداة puppet المُسمى puppet.conf على ثلاثة أقسام: [main] و [master] و [agent]. كما هو واضح، يحتوي القسم الرئيسي “main” على الإعدادات العامّة أو الشاملة، أما القسم المُسمى “master” فيحتوي على الإعدادات الخاصّة بالخادم الرئيسي puppet master، ويحتوي القسم “agent” على الإعدادات الخاصّة بخوادم العُملاء. بغض النظر عن التعديلات السابقة الّتي تمّت على هذا المَلفّ، تعمل الإعدادات الافتراضيّة بشكل مُناسب في بيئة العمل البسيطة وغير المُعقدة. يُمكن الرجوع إلى التوثيق الرسمي لمزيد من التفاصيل حول مَلفّ puppet.conf. ولتحرير هذا المَلف يُمكن تنفيذ الأمر التّالي:

sudo vi /etc/puppet/puppet.conf

مَلفّ البيان الرئيسيّ (Main Manifest File)

تستخدم الأداة Puppet لغة مُحددة المجال DSL وهي اختصار domain-specific language، ومُهمّة هذه اللغة هي كتابة أوصاف أو تصوّرات مَلفّ الإعدادات الخاصّ بالنظام، وتُحفظ هذه الأوصاف في ملفات تُسمى “mainfests”، والّتي تحمل اللاحقة .pp. يتوضّع مَلفّ الـ manifest الرئيسيّ وهو الافتراضيّ في المسار /etc/puppet/manifests/site.pp. سوف يتمّ تناول أساسيات التعامل مع هذا النوع من الملفات فيما بعد، ولكن الآن سيتمّ استخدام مَلفّ خُلَّبي placeholder للمُتابعة:

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

تشغيل الخادوم المَركزيّ Puppet Master

أصبح من المُمكن الآن تشغيل Puppet master عبر تشغيل خدمة apache2:

sudo service apache2 start

يعمل الخادم الرئيسيّ Puppet master كما يجب، ولكن حتى الآن هو لا يُدير أيًا من العُملاء بعد.

تنصيب خوادم العُملاء Puppet Agent

يجب تنصيب أداة العميل الخاصة بالأداة Puppet على جميع الخوادم التي من المُفترض إدارتها من قبل الجهاز المَركزيّ Puppet master، في أغلب الحالات هذا يتضمّن كل الخوادم في البِنْيَة التَّحْتِيَّة، حيثُ كما تمّت الإشارة في المُقدمة أنّ الأداة Puppet مُتوافقة مع أغلب توزيعات لينوكس الشائعة، وبعض منصات يونكس وأنظمة التشغيل "ويندوز". بسبب الاختلاف في الإعداد بين الأنظمة سوف يتمّ التركيز على خوادم Ubuntu و Debian، أما التعليمات الخاصّة بالتنصيب على بقيّة المنصات فيُمكن الحصول عليها من التوثيق الرسميّ: Puppet Labs Docs

ملاحظة: من المُهم جدًا إعداد جميع العُملاء لاستخدام DNS مُلائم قبل تنصيب نسخة العُملاء على الخوادم.

التعامل مع خوادم Ubuntu / Debian

تستخدم جميع خوادم العُملاء في أمثلة هذا الشرح توزيعة أوبونتو 14.04، وذلك باستخدام خادم افتراضيّ خاصّ VPS، والإعدادات التّالية سوف يتمّ تطبيقها على جميع هذه الخوادم وهي: host1، host2، ns1، ns2.

سوف يتمّ في البداية تحميل الحزمة من موقع مَعامل Puppet كما حصل مع نسخة Puppet master.

cd ~; wget https://apt.puppetlabs.com/puppetlabs-release-trusty.deb

تنصيب الحزمة:

sudo dpkg -i puppetlabs-release-trusty.deb

تحديث قوائم الحزم المُتوفّرة:

sudo apt-get update

تنصيب حزمة العُملاء puppet:

sudo apt-get install puppet

الأداة بشكل افتراضيّ تَكون غير مُفعلة، ولتغيير ذلك يجب تحديث مَلفّها الافتراضيّ:

sudo vi /etc/default/puppet

تغيير قيمة START إلى “yes”:

START=yes

قفل الإصدار الحالي

سوف يتمّ استخدام ميزة pin الخاصة بالأداة apt لقفل الإصدار الحالي الخاصّ بـ Puppet agent:

sudo vi /etc/apt/preferences.d/00-puppet.pref

لقفل الإصدار الحالي سوف يتمّ إضافة السطور التّالية إلى المَلفّ السابق:

# /etc/apt/preferences.d/00-puppet.pref
Package: puppet puppet-common
Pin: version 3.7*
Pin-Priority: 501

إعداد نسخة العميل Puppet Agent

قبل تشغيل نسخة العميل من الضروريّ تغيير بعض الإعدادات، وذلك بتحرير مَلفّ إعداد نسخة العميل puppet.conf، وهو نسخة مُطابقة لنسخة لملف الإعداد الأوليّ لنسخة Puppet master:

sudo vi /etc/puppet/puppet.conf

سيتمّ حذف السطر الخاصّ بالخَيار templatedir كما تمّ سابقَا مع نسخة الخادم المَركزيّ، بالإضافة إلى ذلك سوف يتمّ حذف القسم المُسمى [master] وكافة السطور الّتي تخصّه.

إنّ تمكّنت الخوادم من الاتصال بالخادم المَركزيّ Puppet master بالاسم “puppet”، فيُمكن للعُملاء استخدام هذا الاسم للاتصال بالخادم المَركزيّ، أما في حال عدم توفّر الجهاز المَركزيّ تحت الاسم “puppet” فيجب إضافة اسم المجال الكامل FQDN الخاصّ بالخادم المَركزيّ Puppet master، ومن المُستحسن عمل ذلك في جميع الأحوال.

[agent]
server = puppet.nyc2.example.com

بعد الإعدادات السابقة أصبحت نسخة العميل من الأداة Puppet agent جاهزة للعمل، وذلك بتنفيذ الأمر التّالي:

sudo service puppet start

لن يُظهر تنفيذ الأمر السابق أيّة مُخرجات output في حال أنّ الإعدادات طُبقت بشكل صحيح. يتمّ عند التشغيل الأول للأداة Puppet agent توليد شهادة SSL وإرسال طلب توقيع signing request إلى الخادم المَركزيّ Puppet master، وبعد أنّ يُوقع الخادم المَركزيّ شهادة العميل سيكون الاتصال جاهزًا بينهما.

تجدرُ الإشارة هنا أنّه في حال كان هذا العميل هو العميل الأول، فمن المُستحسن محاولة توقيع الشهادة على الخادم المَركزيّ Puppet master قبل إضافة باقي العُملاء، وعندما يتمّ التأكد من أنّ الأمور تجري على ما يُرام، عندها يُمكن إضافة باقي العُملاء من دون التخوف من وقوع مُشكلات مُحتملة مع باقي الخوادم.
توقيع طلب العُملاء على الخادم المَركزيّ:

تُرسل الأداة Puppet عند تشغيلها للمرّة الأولى على خادم العميل Puppet agent طلب توقيع شهادة إلى الخادم المَركزيّ Puppet master، ولن يتمكّن الخادم المَركزيّ من التحكم بالخادم العميل حتى يوقع على هذه الشهادة. سوف يتمّ توضيح هذه النقطة في الفقرة التّالية.

عرض طلبات الشهادة الحالية

يتمّ تنفيذ الأمر التّالي على الجهاز المَركزيّ Puppet master ليَعرض جميع طلبات الشهادة غير المُوقعة:

sudo puppet cert list

سيُظهر الأمر السابق طلبًا وحيدًا حتّى الآن، وهو للعميل الذي تمّ إعداده سابقًا، وسيبدو بالشكل التّالي، حيثُ الاسم هو اسم المجال الكامل FQDN:

"host1.nyc2.example.com" (SHA256) 5F:DB:E0:6D:8B:1F:C8:A3:04:4E:CD:48:6F:9F:D7:89:14:38:FB:5B:EF:2F:09:76:C5:13:A9:E0:4D:D2:C5:FC

يجب الانتباه هنا إلى أنّ المُخرج السابق لا يحتوي على إشارة الزائد (+)، وذلك يُشير إلى أنّ هذه الشهادة غير مُوقعة بعد.

توقيع الطلب

يُستخدم الأمر puppet cert sign لتوقيع طلب شهادة، ويُضاف إلى هذا الأمر اسم الخادم الخاصّ بهذه الشهادة، على سبيل المثال لتوقيع طلب الخادم host1.nyc2.example.com، فسوف يتم تنفيذ الأمر التّالي:

sudo puppet cert sign host1.nyc2.example.com

الأمر السابق يَعرضُ المُخرَج التّالي، والذي يُشير إلى توقيع طلب الشهادة.

Notice: Signed certificate request for host1.nyc2.example.com
Notice: Removing file Puppet::SSL::CertificateRequest host1.nyc2.example.com at '/var/lib/puppet/ssl/ca/requests/host1.nyc2.example.com.pem'

أصبح بإمكان الخادم المَركزيّ Puppet master بعد توقيع طلب الشهادة من الاتصال والتحكم بهذه النقطة node والتي تنتمي إليها هذه الشهادة المُوقعة.

يُمكن استخدام الأمر التّالي لتوقيع جميع الطلبات الحالية وذلك باستخدام الخيار -all.

sudo puppet cert sign --all

إبطال الشهادات

يحتاج مُدير النظام في بعض الحالات إلى حذف أحد العُملاء من الخادم المَركزيّ، ربما لأسباب تتعلق بتحليل المشاكل، أو لأي سببٍ آخر، حيثُ يُمكن إبطال شهادة العميل من الخادم المَركزيّ باستخدام الخيار clean مع اسم الخادم، كما في المثال التّالي:

sudo puppet cert clean hostname

استعراض جميع الطلبات المُوقعة

يُستخدم الأمر التّالي لاستعراض جميع الطلبات المُوقعة وغير المُوقعة

sudo puppet cert list –all

يَعرض الأمر السابق جميع الطلبات مع الانتباه أنّ الطلبات المُوقعة تُسبق بإشارة الزائد

  "ns2.nyc2.example.com"   (SHA256) E4:F5:26:EB:B1:99:1F:9D:6C:B5:4B:BF:86:14:40:23:E0:50:3F:C1:45:D0:B5:F0:68:6E:B2:0F:41:C7:BA:76
+ "host1.nyc2.example.com" (SHA256) 71:A2:D3:82:15:0D:80:20:D4:7E:E3:42:C2:35:87:83:79:2B:57:1D:D5:5A:EC:F6:8B:EE:51:69:53:EB:6B:A1
+ "host2.nyc2.example.com" (SHA256) F4:79:A6:7C:27:0C:EA:8E:BC:31:66:FF:F2:01:AB:B1:35:7B:9F:5E:C8:C9:CE:82:EE:E8:2F:23:9F:0C:2B:ED
+ "puppet"                 (SHA256) 05:22:F7:65:64:CF:46:0E:09:2C:5D:FD:8C:AC:9B:31:17:2B:7B:05:93:D5:D1:01:52:72:E6:DF:84:A0:07:37 (alt names: "DNS:puppet", "DNS:puppet.nyc2.example.com")

الخطوات الأولى مع الأداة Puppet

بعد تجهيز بيئة العمل، سيتمّ التركيز في الفقرات التالية على كيفية عمل بعض المُهِمّات أو الواجبات الأساسية للخوادم وذلك باستخدام الأداة Puppet، وذلك في سبيل عرض الخطوط العريضة لهذه الأداة وآلية عملها.

كيف تُجمّع الحقائق

تجمع الأداة Puppet الحقائق حول جميع العُقد المُرتبطة بها، وذلك باستخدام أداةٍ تُسمى “facter”. تَجمع الأداة Facter جميع المعلومات المُفيدة في إعداد النظام بشكل افتراضيّ، مثل اسم نظام التشغيل، عنواين برتوكول الانترنت IP، ومفاتيح SSH، وغيرها من المعلومات. كما مِن المُمكن إضافة حقائق مُخصّصة حسب الحاجة لأداء بعض الإعدادات الخاصّة.

يُمكن الاستفادة من هذه الحقائق المُجمّعة في حالات عديدة. على سبيل المثال، يُمكن إنشاء نموذج إعدادات خادم ويب وتعيين العناوين المُلائمة لمُضيف افتراضي مُحدد دون الآخر، أويُمكن استخدامها في التحكم بمسار الإعدادات، أي تطبيق إعداد معين على حسب حقيقة معينة، فعند معرفة أن النظام هو نظام أوبونتو، فسيكون اسم الخدمة الخاصّة بخادم الويب هي apache2، وفي حال كان نظام التشغيل هو CentOS، فستكون الخدمة الخاصّة بخادم الويب هي httpd. الأمثلة السابقة هي تبسيط لما يُمكن عمله باستخدام هذه الحقائق المُجمّعة.

لاستعراض قائمة الحقائق والّتي تمّ جمعها بشكلٍ تلقائيّ على خادم العميل يُمكن استخدام الأمر التّالي:

facter

كيفيّة تنفيذ مَلفّ البيان الرئيسي The Main Manifest

تقوم العُملاء الخاصّة بالأداة Puppet بالاتصال بالخادم المَركزيّ Puppet master دوريًا كل 30 دقيقة تقريبًا، مُرسلةً حقائق factsعن نفسها إليه، بالإضافة إلى سحب فهرس (catalog) مَلفات البيان، والتي هي قائمة مُجمّعة (compiled) للمَوارِد وحالتها المَطلوبة والمُرتبطة مع هذه العُملاء، وتُحدّد هذه القائمة من قِبل مَلفّ البيان الرئيسيّ main manifest، وفيما بعد تُحاول نقاط العُملاء تطبيق التَغَيُّرات لتُلائم الحالة المَطلوبة. يستمر التسلسل السابق بالتكرار طالما أنّ الخادم المَركزيّ يعمل ومُتصل مع نقاط العُملاء.

تنفيذ التَغَيُّرات على نقاط العُملاء بشكلٍ يدويٍّ ومُباشر

يُمكن المُبادرة بعمل اتصال يدويّ بين أحد نقاط العُملاء والخادم المَركزيّ، رُبما لتسريع عملية التطبيق أو في سبيل تحديد مُشكلة ما، أو لمعرفة كيف سوف يؤثّر مَلفّ البيان على أحد الخوادم دون تطبيقه على جميع الخوادم، ويتمّ ذَلِك عبر بتنفيذ الأمر التّالي على الخادم العميل:

puppet agent --test

سيقوم الأمر السابق بتطبيق مَلفّ البيان الرئيسي main manifest على الخادم العميل، كما يَعرض هذا الأمر المُخرجات التّالية:

Info: Caching certificate_revocation_list for ca
Info: Retrieving plugin
Info: Caching catalog for host1
Info: Applying configuration version '1423707894'
Info: Creating state file /var/lib/puppet/state/state.yaml
Notice: Finished catalog run in 0.01 seconds

تطبيق مَلفِ بيانٍ كيفيٍ ولمرّة واحدة

يُتيح الأمر puppet apply تنفيذ مَلفات بيانٍ اختياريّة لاترتبط بمَلف البيان الرئيسيّ، وعلى نقاط العُملاء مُعينة.

sudo puppet apply /etc/puppet/modules/test/init.pp

تشغيل مَلفّات البيان بهذا النمط مفيدٌ عندما يكون المُراد اختبار مَلفّ بيان جديد على أحد العُملاء، أو عندما يَكون المُراد تنفيذ مَلفّ البيان لمرّة واحدة فقط، مُثلًا لاستهلال العميل إلى حالة مُعينة.

إنشاء مَلفّ بيانٍ رئيسيٍّ مُبسَط

تمّت الإشارة سابقًا إلى أنّ مَلفّ البيان الرئيسي على الخادم المَركزيّ من المُفترض تواجده في المسار /etc/puppet/manifests/ وبالاسم site.pp. سيتمّ إضافة بعض التعديلات البسيطة لهذا المَلف:

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

السطور التّالية تصف مَورِد مَلفّ file resource:

file {'/tmp/example-ip':                                            # التصريح عن مَورد مَلفّ ومسار المَلف
  ensure  => present,                                               # التأكد من وجود المَلف
  mode    => 0644,                                                  # تحديد صلاحيات المَلف
  content => "Here is my Public IP Address: ${ipaddress_eth0}.\n",  # تحديد مُحتوى المَلف واستخدام الحقائق
}

يقوم مَلفّ البيان السابق بإنشاء مَلفٍ في المسار /tmp/، والتأكد من وجوده وبالاسم example-ip مع صلاحيات -rw-r--r--، ومُحتوى نصيّ يتضمّن عنوان الـIP الخاصّ بالخادم العميل.

بالإمكان إما الانتظار حتّى يقوم الخادم العميل بالاتصال مع الخادم المَركزيّ بشكل آليٍّ، أوتنفيذ الأمر puppet agent –test على أحد نقاط العُملاء. لمُشاهدة التغييرات التي قام بها مَلفّ البيان السابق، وبعد ذلك يُمكن تنفيذ الأمر التّالي على الخادم العميل:

Cat /tmp/example-ip

والذي سوف يَعرض السطرَ التّالي مع اختلاف العنوان بطبيعة الحال:

Here is my Public IP Address: 10.0.2.15.

استهداف عميلٍ مُحدد

من المُهم معرفة أنّه بالإمكان تعريف مَورد مُحدد لعميلٍ مُعين دون الآخرين، ولذلك على الخادم المَركزيّ، ومنه المَلف site.pp:

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

سيتمّ إضافة السطور التّالية:

node 'ns1', 'ns2' {    # تطبيق المَورد التّالي على الخوادم المُحددة فقط
  file {'/tmp/dns':    # التصريح عن مَورد مَلفّ ومسار المَلف
    ensure => present, # التأكد من وجود المَلف
    mode => 0644,      # تحديد صلاحيات المَلف
    content => "Only DNS servers get this file.\n",
  }
}

node default {}       # تطبيق المَوارد على النقاط التي لم تُعرّف بشكل مُحدد.

ستتأكّد الأداة Puppet من وجود المَلف /tmp/dns على الخادمين "ns1" و“ns2”، ومن المُمكن تطبيق الأمر puppet agent –test على الخادمين آنفي الذّكر لعدم الانتظار إلى حين الطلب التلقائي من العُملاء.

يجدُر الذكر هنا أنّه في حال عدم تعريف مَورد، فإن الأداة Puppet سوف لن تقوم بإجراء أيّة تعديلات على العُملاء، أي في حال حذف المَوارد السابقة من مَلفّ البيان، فإنّ الأداة Puppet لن تَحذف الملفات التي قامت بإنشائها سابقًا، إلا إذا تمّ التصريح بذلك عبر تعديل قيمة ensure إلى absent والّتي تعني غائب أو لا وجود له.

في حقيقة الأمر لايُظهر تطبيق الأمثلة السابقة قوة الأداة Puppet وما الذي يُمكنها فعله، ولكنه يُبرهن على الأقل أنّها تعمل كما هو مُخططٌ لها.

استخدام الوحدات Modules

تُستخدم الوحدات modules لتجميع المهام في صيغة واحدة، ويتوفّر العديد من هذه الوحدات في مُجتمع Puppet، مع العلم أنّه يُمكن كتابة وحدة جديدة وعدم التقيد بما يوفره المُجتمع من هذه الوحدات.

سيتمّ تنصيب وحدة مُعدّة مُسبقًا من موقع Puppet باستخدام الأمر puppetlabs-apache:

sudo puppet module install puppetlabs-apache

تحذير: لا يُفترض استخدام الوحدة السابقة في حال وجود خادم الويب Apache، وذلك من شأنه أنّ يُلغي أيّة إعدادات تُدار من قبل الأداة Puppet.

يجب الآن تحرير المَلف site.pp، لكي يَستخدم الوحدة المُنصبة (apache). وعلى سبيل المثال سيتمّ اختيار الخادم “host2” لتنصيب خادم الويب Apache لتوضيح المثال:

node 'host2' {
  class { 'apache': }             # use apache module
  apache::vhost { 'example.com':  # define vhost resource
    port    => '80',
    docroot => '/var/www/html'
  }
}

ستقوم الأداة Puppet بتنصيب خادم الويب Apache على العميل “host2”، وإعداد مُضيف افتراضيّ “example.com”، مُصغيًا على المنفذ 80، مع document root بالمسار /var/www/html.

على الخادم “host2” يُمكن تنفيذ الأمر التّالي لتسريع عمليّة التطبيق:

sudo puppet agent --test

يَعرض الأمر السابق مُخرجات تُشير إلى تنصيب خادم الويب Apache. بعد استكمال التنصيب، من المُمكن التأكد من عمل خادم الويب بالشكل المطلوب عبر زيارة صفحة الترحيب الافتراضيّة الخاصّة به.

خاتمة

تمّ التطرّق في هذا الجزء إلى كيفيّة تنصيب الأداة Puppet، وإعدادها إعدادًا أوليًا، وبذلك أصبح بالإمكان التعمّق في المزيد من التفاصيل الخاصّة بهذه الأداة وماتقدمه من تسهيلات لمُدير النظام، وذلك عبر مَلفّات البيان والوحدات الّتي سيتمّ التركيز عليها في الجزء الثاني من هذه السلسلة.

ترجمة -وبتصرّف- للمقال How To Install Puppet To Manage Your Server Infrastructure