پرو ہوسٹر > بلاگ > انتظامیہ > کٹھ پتلی کا تعارف

کٹھ پتلی کا تعارف

کٹھ پتلی ایک کنفیگریشن مینجمنٹ سسٹم ہے۔ یہ میزبانوں کو مطلوبہ حالت میں لانے اور اس حالت کو برقرار رکھنے کے لیے استعمال ہوتا ہے۔

میں پپیٹ کے ساتھ پانچ سال سے کام کر رہا ہوں۔ یہ متن بنیادی طور پر سرکاری دستاویزات کے اہم نکات کا ترجمہ شدہ اور دوبارہ ترتیب دیا گیا تالیف ہے، جو ابتدائی افراد کو پپٹ کے جوہر کو تیزی سے سمجھنے کی اجازت دے گا۔

کٹھ پتلی کا تعارف

بنیادی معلومات

کٹھ پتلی کا آپریٹنگ سسٹم کلائنٹ سرور ہے، حالانکہ یہ محدود فعالیت کے ساتھ بغیر سرور کے آپریشن کو بھی سپورٹ کرتا ہے۔

آپریشن کا ایک پل ماڈل استعمال کیا جاتا ہے: پہلے سے طے شدہ طور پر، ہر آدھے گھنٹے میں ایک بار، کلائنٹ کنفیگریشن کے لیے سرور سے رابطہ کرتے ہیں اور اسے لاگو کرتے ہیں۔ اگر آپ نے Ansible کے ساتھ کام کیا ہے، تو وہ ایک مختلف پش ماڈل استعمال کرتے ہیں: ایڈمنسٹریٹر کنفیگریشن کو لاگو کرنے کا عمل شروع کرتا ہے، کلائنٹ خود کچھ بھی لاگو نہیں کریں گے۔

نیٹ ورک کمیونیکیشن کے دوران، دو طرفہ TLS انکرپشن استعمال کیا جاتا ہے: سرور اور کلائنٹ کے پاس اپنی ذاتی کلیدیں اور متعلقہ سرٹیفکیٹ ہوتے ہیں۔ عام طور پر سرور کلائنٹس کے لیے سرٹیفکیٹ جاری کرتا ہے، لیکن اصولی طور پر بیرونی CA استعمال کرنا ممکن ہے۔

منشور کا تعارف

کٹھ پتلی کی اصطلاح میں کٹھ پتلی سرور کو جڑیں نوڈس (نوڈس)۔ نوڈس کے لیے ترتیب لکھی ہوئی ہے۔ منشور میں ایک خصوصی پروگرامنگ زبان میں - Puppet DSL۔

کٹھ پتلی ڈی ایس ایل ایک اعلانیہ زبان ہے۔ یہ انفرادی وسائل کے اعلانات کی شکل میں نوڈ کی مطلوبہ حالت کو بیان کرتا ہے، مثال کے طور پر:

  • فائل موجود ہے اور اس میں مخصوص مواد ہے۔
  • پیکیج انسٹال ہے۔
  • سروس شروع ہو گئی ہے۔

وسائل آپس میں منسلک ہو سکتے ہیں:

  • انحصار ہیں، وہ اس ترتیب کو متاثر کرتے ہیں جس میں وسائل استعمال ہوتے ہیں۔
    مثال کے طور پر، "پہلے پیکج کو انسٹال کریں، پھر کنفیگریشن فائل میں ترمیم کریں، پھر سروس شروع کریں۔"
  • اطلاعات ہیں - اگر کوئی وسیلہ بدل گیا ہے، تو یہ اس کے سبسکرائب کردہ وسائل کو اطلاعات بھیجتا ہے۔
    مثال کے طور پر، اگر کنفیگریشن فائل بدل جاتی ہے، تو آپ خود بخود سروس کو دوبارہ شروع کر سکتے ہیں۔

مزید برآں، کٹھ پتلی DSL میں افعال اور متغیرات کے ساتھ ساتھ مشروط بیانات اور سلیکٹرز ہیں۔ مختلف ٹیمپلیٹنگ میکانزم بھی معاون ہیں - EPP اور ERB۔

کٹھ پتلی روبی میں لکھا گیا ہے، لہذا بہت سے تعمیرات اور اصطلاحات وہاں سے لی گئی ہیں۔ روبی آپ کو کٹھ پتلی کو بڑھانے کی اجازت دیتا ہے - پیچیدہ منطق، نئے قسم کے وسائل، افعال شامل کریں۔

جب کٹھ پتلی چل رہا ہے، سرور پر ہر مخصوص نوڈ کے لیے مینی فیسٹ ایک ڈائرکٹری میں مرتب کیے جاتے ہیں۔ ڈائریکٹری فنکشنز، متغیرات اور مشروط بیانات کی توسیع کی قدر کا حساب لگانے کے بعد وسائل اور ان کے تعلقات کی فہرست ہے۔

نحو اور کوڈ اسٹائل

یہاں سرکاری دستاویزات کے حصے ہیں جو آپ کو نحو کو سمجھنے میں مدد کریں گے اگر فراہم کردہ مثالیں کافی نہیں ہیں:

مینی فیسٹ کیسا لگتا ہے اس کی ایک مثال یہ ہے:

# Комментарии пишутся, как и много где, после решётки.
#
# Описание конфигурации ноды начинается с ключевого слова node,
# за которым следует селектор ноды — хостнейм (с доменом или без)
# или регулярное выражение для хостнеймов, или ключевое слово default.
#
# После этого в фигурных скобках описывается собственно конфигурация ноды.
#
# Одна и та же нода может попасть под несколько селекторов. Про приоритет
# селекторов написано в статье про синтаксис описания нод.
node 'hostname', 'f.q.d.n', /regexp/ {
  # Конфигурация по сути является перечислением ресурсов и их параметров.
  #
  # У каждого ресурса есть тип и название.
  #
  # Внимание: не может быть двух ресурсов одного типа с одинаковыми названиями!
  #
  # Описание ресурса начинается с его типа. Тип пишется в нижнем регистре.
  # Про разные типы ресурсов написано ниже.
  #
  # После типа в фигурных скобках пишется название ресурса, потом двоеточие,
  # дальше идёт опциональное перечисление параметров ресурса и их значений.
  # Значения параметров указываются через т.н. hash rocket (=>).
  resource { 'title':
    param1 => value1,
    param2 => value2,
    param3 => value3,
  }
}

انڈینٹیشن اور لائن بریکس مینی فیسٹ کا مطلوبہ حصہ نہیں ہیں، لیکن ایک تجویز کردہ ہے۔ سٹائل گائیڈ. خلاصہ:

  • دو اسپیس انڈینٹ، ٹیبز استعمال نہیں کیے جاتے ہیں۔
  • گھوبگھرالی منحنی خطوط وحدانی کو ایک جگہ سے الگ کیا جاتا ہے؛ کالون کو ایک جگہ سے الگ نہیں کیا جاتا ہے۔
  • ہر پیرامیٹر کے بعد کوما، بشمول آخری والا۔ ہر پیرامیٹر ایک الگ لائن پر ہے۔ پیرامیٹرز اور ایک پیرامیٹر کے بغیر کیس کے لیے ایک استثناء بنایا گیا ہے: آپ ایک لائن پر اور کوما کے بغیر لکھ سکتے ہیں (یعنی resource { 'title': } и resource { 'title': param => value }).
  • پیرامیٹرز پر تیر ایک ہی سطح پر ہونے چاہئیں۔
  • ان کے آگے وسیلہ رشتہ تیر لکھا جاتا ہے۔

pappetserver پر فائلوں کا مقام

مزید وضاحت کے لیے، میں "روٹ ڈائریکٹری" کا تصور پیش کروں گا۔ روٹ ڈائرکٹری وہ ڈائریکٹری ہے جس میں ایک مخصوص نوڈ کے لیے پپیٹ کنفیگریشن ہوتی ہے۔

روٹ ڈائرکٹری پپیٹ کے ورژن اور استعمال شدہ ماحول کے لحاظ سے مختلف ہوتی ہے۔ ماحولیات کنفیگریشن کے آزاد سیٹ ہیں جو علیحدہ ڈائریکٹریز میں محفوظ ہیں۔ عام طور پر گٹ کے ساتھ مل کر استعمال کیا جاتا ہے، اس صورت میں ماحول گٹ شاخوں سے بنائے جاتے ہیں۔ اس کے مطابق، ہر نوڈ ایک ماحول یا دوسرے میں واقع ہے. اسے نوڈ پر یا ENC میں ترتیب دیا جا سکتا ہے، جس کے بارے میں میں اگلے مضمون میں بات کروں گا۔

  • تیسرے ورژن میں ("پرانی کٹھ پتلی") بیس ڈائرکٹری تھی۔ /etc/puppet. ماحولیات کا استعمال اختیاری ہے - مثال کے طور پر، ہم انہیں پرانے کٹھ پتلی کے ساتھ استعمال نہیں کرتے ہیں۔ اگر ماحول استعمال کیا جاتا ہے، تو وہ عام طور پر ذخیرہ کیے جاتے ہیں۔ /etc/puppet/environments، روٹ ڈائرکٹری ماحولیات کی ڈائرکٹری ہوگی۔ اگر ماحول استعمال نہیں کیا جاتا ہے تو، روٹ ڈائرکٹری بیس ڈائرکٹری ہوگی۔
  • چوتھے ورژن ("نیا کٹھ پتلی") سے شروع کرتے ہوئے، ماحولیات کا استعمال لازمی ہو گیا، اور بنیادی ڈائریکٹری کو منتقل کر دیا گیا /etc/puppetlabs/code. اس کے مطابق، ماحول میں ذخیرہ کیا جاتا ہے /etc/puppetlabs/code/environmentsروٹ ڈائرکٹری ماحولیات کی ڈائرکٹری ہے۔

روٹ ڈائرکٹری میں ایک ذیلی ڈائرکٹری ہونی چاہیے۔ manifests، جس میں نوڈس کی وضاحت کرنے والے ایک یا زیادہ مینی فیسٹس ہوتے ہیں۔ اس کے علاوہ ایک ذیلی ڈائرکٹری بھی ہونی چاہیے۔ modules، جس میں ماڈیولز شامل ہیں۔ میں آپ کو تھوڑی دیر بعد بتاؤں گا کہ ماڈیول کیا ہیں۔ اس کے علاوہ، پرانے کٹھ پتلی کی ایک ذیلی ڈائرکٹری بھی ہو سکتی ہے۔ files، جس میں مختلف فائلیں ہوتی ہیں جنہیں ہم نوڈس میں کاپی کرتے ہیں۔ نئے پپٹ میں، تمام فائلوں کو ماڈیولز میں رکھا گیا ہے۔

مینی فیسٹ فائلوں میں توسیع ہوتی ہے۔ .pp.

ایک دو جنگی مثالیں۔

اس پر نوڈ اور وسائل کی تفصیل

نوڈ پر server1.testdomain ایک فائل بنانا ضروری ہے /etc/issue مواد کے ساتھ Debian GNU/Linux n l. فائل ایک صارف اور گروپ کی ملکیت ہونی چاہیے۔ root، رسائی کے حقوق ہونے چاہئیں 644.

ہم ایک منشور لکھتے ہیں:

node 'server1.testdomain' {   # блок конфигурации, относящийся к ноде server1.testdomain
    file { '/etc/issue':   # описываем файл /etc/issue
        ensure  => present,   # этот файл должен существовать
        content => 'Debian GNU/Linux n l',   # у него должно быть такое содержимое
        owner   => root,   # пользователь-владелец
        group   => root,   # группа-владелец
        mode    => '0644',   # права на файл. Они заданы в виде строки (в кавычках), потому что иначе число с 0 в начале будет воспринято как записанное в восьмеричной системе, и всё пойдёт не так, как задумано
    }
}

ایک نوڈ پر وسائل کے درمیان تعلقات

نوڈ پر server2.testdomain nginx چل رہا ہونا چاہئے، پہلے سے تیار کردہ ترتیب کے ساتھ کام کرنا۔

آئیے مسئلہ کو حل کریں:

  • پیکیج کو انسٹال کرنے کی ضرورت ہے۔ nginx.
  • یہ ضروری ہے کہ کنفیگریشن فائلوں کو سرور سے کاپی کیا جائے۔
  • سروس کو چلانے کی ضرورت ہے۔ nginx.
  • اگر کنفیگریشن اپ ڈیٹ ہو جائے تو سروس کو دوبارہ شروع کرنا ضروری ہے۔

ہم ایک منشور لکھتے ہیں:

node 'server2.testdomain' {   # блок конфигурации, относящийся к ноде server2.testdomain
    package { 'nginx':   # описываем пакет nginx
        ensure => installed,   # он должен быть установлен
    }
  # Прямая стрелка (->) говорит о том, что ресурс ниже должен
  # создаваться после ресурса, описанного выше.
  # Такие зависимости транзитивны.
    -> file { '/etc/nginx':   # описываем файл /etc/nginx
        ensure  => directory,   # это должна быть директория
        source  => 'puppet:///modules/example/nginx-conf',   # её содержимое нужно брать с паппет-сервера по указанному адресу
        recurse => true,   # копировать файлы рекурсивно
        purge   => true,   # нужно удалять лишние файлы (те, которых нет в источнике)
        force   => true,   # удалять лишние директории
    }
  # Волнистая стрелка (~>) говорит о том, что ресурс ниже должен
  # подписаться на изменения ресурса, описанного выше.
  # Волнистая стрелка включает в себя прямую (->).
    ~> service { 'nginx':   # описываем сервис nginx
        ensure => running,   # он должен быть запущен
        enable => true,   # его нужно запускать автоматически при старте системы
    }
  # Когда ресурс типа service получает уведомление,
  # соответствующий сервис перезапускается.
}

اس کے کام کرنے کے لیے، آپ کو کٹھ پتلی سرور پر تقریباً درج ذیل فائل لوکیشن کی ضرورت ہے:

/etc/puppetlabs/code/environments/production/ # (это для нового Паппета, для старого корневой директорией будет /etc/puppet)
├── manifests/
│   └── site.pp
└── modules/
    └── example/
        └── files/
            └── nginx-conf/
                ├── nginx.conf
                ├── mime.types
                └── conf.d/
                    └── some.conf

وسائل کی اقسام

معاون وسائل کی اقسام کی مکمل فہرست یہاں مل سکتی ہے۔ دستاویزات میں، یہاں میں پانچ بنیادی اقسام بیان کروں گا، جو میرے عمل میں زیادہ تر مسائل کو حل کرنے کے لیے کافی ہیں۔

سنچکا

فائلوں، ڈائریکٹریز، سملنک، ان کے مواد اور رسائی کے حقوق کا انتظام کرتا ہے۔

پیرامیٹرز:

  • وسائل کا نام فائل کا راستہ (اختیاری)
  • راستہ - فائل کا راستہ (اگر یہ نام میں متعین نہیں ہے)
  • کو یقینی بنانے کے - فائل کی قسم:
    • absent - ایک فائل کو حذف کریں۔
    • present - کسی بھی قسم کی فائل ہونی چاہیے (اگر کوئی فائل نہیں ہے تو ایک باقاعدہ فائل بنائی جائے گی)
    • file - باقاعدہ فائل
    • directory - ڈائریکٹری
    • link --.symlink
  • مواد — فائل کے مشمولات (صرف باقاعدہ فائلوں کے لیے موزوں، اس کے ساتھ استعمال نہیں کیا جا سکتا ذرائع یا ہدف)
  • ذرائع - اس راستے کا ایک لنک جہاں سے آپ فائل کے مواد کو کاپی کرنا چاہتے ہیں (کے ساتھ استعمال نہیں کیا جا سکتا مواد یا ہدف)۔ اسکیم کے ساتھ یا تو یو آر آئی کے طور پر بیان کیا جا سکتا ہے۔ puppet: (پھر کٹھ پتلی سرور سے فائلیں استعمال کی جائیں گی)، اور اسکیم کے ساتھ http: (مجھے امید ہے کہ یہ واضح ہے کہ اس معاملے میں کیا ہوگا)، اور یہاں تک کہ خاکہ کے ساتھ file: یا اسکیما کے بغیر مطلق راستے کے طور پر (پھر نوڈ پر مقامی FS کی فائل استعمال کی جائے گی)
  • ہدف - جہاں سملنک کو اشارہ کرنا چاہئے (کے ساتھ استعمال نہیں کیا جاسکتا مواد یا ذرائع)
  • مالک - وہ صارف جسے فائل کا مالک ہونا چاہیے۔
  • گروپ - وہ گروپ جس سے فائل کا تعلق ہونا چاہیے۔
  • موڈ فائل کی اجازت (بطور تار)
  • تکرار کرنا - بار بار چلنے والی ڈائریکٹری پروسیسنگ کو قابل بناتا ہے۔
  • صفائی - ان فائلوں کو حذف کرنے کے قابل بناتا ہے جن کا پپٹ میں بیان نہیں کیا گیا ہے۔
  • مجبور - ڈائریکٹریز کو حذف کرنے کے قابل بناتا ہے جو پپٹ میں بیان نہیں کی گئی ہیں۔

پیکج

پیکجوں کو انسٹال اور ہٹاتا ہے۔ اطلاعات کو ہینڈل کرنے کے قابل - اگر پیرامیٹر کی وضاحت کی گئی ہو تو پیکیج کو دوبارہ انسٹال کرتا ہے۔ reinstall_on_refresh.

پیرامیٹرز:

  • وسائل کا نام - پیکیج کا نام (اختیاری)
  • نام - پیکیج کا نام (اگر نام میں متعین نہیں ہے)
  • فراہم کنندہ - استعمال کرنے کے لئے پیکیج مینیجر
  • کو یقینی بنانے کے - پیکیج کی مطلوبہ حالت:
    • present, installed - کوئی بھی ورژن انسٹال ہے۔
    • latest - تازہ ترین ورژن انسٹال ہوا۔
    • absent - حذف کر دیا گیا (apt-get remove)
    • purged - کنفیگریشن فائلوں کے ساتھ حذف کر دیا گیا (apt-get purge)
    • held - پیکیج ورژن مقفل ہے (apt-mark hold)
    • любая другая строка - مخصوص ورژن انسٹال ہے۔
  • reinstall_on_refresh --.اگر true، پھر نوٹیفکیشن کی وصولی پر پیکیج کو دوبارہ انسٹال کیا جائے گا۔ ماخذ پر مبنی تقسیم کے لیے مفید ہے، جہاں تعمیراتی پیرامیٹرز کو تبدیل کرتے وقت پیکجوں کی تعمیر نو ضروری ہو سکتی ہے۔ طے شدہ false.

سروس

خدمات کا انتظام کرتا ہے۔ اطلاعات پر کارروائی کرنے کے قابل - سروس کو دوبارہ شروع کرتا ہے۔

پیرامیٹرز:

  • وسائل کا نام - سروس کا انتظام کیا جائے گا (اختیاری)
  • نام - وہ خدمت جس کا انتظام کرنے کی ضرورت ہے (اگر نام میں بیان نہیں کیا گیا ہے)
  • کو یقینی بنانے کے - خدمت کی مطلوبہ حالت:
    • running --.شروع کیا ۔
    • stopped --.روکا n
  • کو چالو کرنے کے - سروس شروع کرنے کی صلاحیت کو کنٹرول کرتا ہے:
    • true - آٹورن فعال ہے (systemctl enable)
    • mask - بھیس میں (systemctl mask)
    • false - آٹورن غیر فعال ہے (systemctl disable)
  • دوبارہ شروع کریں - سروس کو دوبارہ شروع کرنے کا حکم
  • محبت کا درجہ - سروس کی حیثیت کو چیک کرنے کے لئے کمانڈ
  • دوبارہ شروع کریں - اس بات کی نشاندہی کریں کہ آیا سروس initscript دوبارہ شروع کرنے کی حمایت کرتی ہے۔ اگر false اور پیرامیٹر کی وضاحت کی گئی ہے۔ دوبارہ شروع کریں - اس پیرامیٹر کی قدر استعمال کی جاتی ہے۔ اگر false اور پیرامیٹر دوبارہ شروع کریں متعین نہیں ہے - سروس روک دی گئی ہے اور دوبارہ شروع کرنا شروع کردی گئی ہے (لیکن systemd کمانڈ استعمال کرتا ہے۔ systemctl restart).
  • اسٹیٹس - اشارہ کریں کہ آیا سروس initscript کمانڈ کو سپورٹ کرتی ہے۔ status. اگر false، پھر پیرامیٹر کی قدر استعمال کی جاتی ہے۔ محبت کا درجہ. طے شدہ true.

عملدرآمد

بیرونی کمانڈز چلاتا ہے۔ اگر آپ پیرامیٹرز کی وضاحت نہیں کرتے ہیں۔ پیدا, صرف اس صورت میں, جب تک کہ یا تازگی سے، جب بھی کٹھ پتلی چلائی جائے گی کمانڈ چلائی جائے گی۔ اطلاعات پر کارروائی کرنے کے قابل - ایک کمانڈ چلاتا ہے۔

پیرامیٹرز:

  • وسائل کا نام - عمل کرنے کا حکم (اختیاری)
  • کمانڈ - عمل درآمد کرنے کا حکم (اگر یہ نام میں متعین نہیں ہے)
  • راستہ - وہ راستے جن میں قابل عمل فائل کو تلاش کرنا ہے۔
  • صرف اس صورت میں - اگر اس پیرامیٹر میں بیان کردہ کمانڈ صفر ریٹرن کوڈ کے ساتھ مکمل ہو جائے تو، مین کمانڈ پر عمل درآمد ہو جائے گا۔
  • جب تک کہ - اگر اس پیرامیٹر میں بیان کردہ کمانڈ غیر صفر ریٹرن کوڈ کے ساتھ مکمل ہو جائے تو مرکزی کمانڈ پر عمل درآمد کیا جائے گا۔
  • پیدا - اگر اس پیرامیٹر میں متعین فائل موجود نہیں ہے تو، مین کمانڈ کو عمل میں لایا جائے گا۔
  • تازگی سے --.اگر true، پھر کمانڈ صرف اس وقت چلائی جائے گی جب اس exec کو دوسرے وسائل سے اطلاع موصول ہوگی۔
  • cwd - ڈائریکٹری جس سے کمانڈ چلانا ہے۔
  • صارف - وہ صارف جس سے کمانڈ چلانی ہے۔
  • فراہم کنندہ - کمانڈ کو کیسے چلائیں:
    • مثبت - بچے کا عمل آسانی سے بنایا گیا ہے، اس کی وضاحت کرنا یقینی بنائیں راستہ
    • شیل - کمانڈ شیل میں شروع کی گئی ہے۔ /bin/sh، کی وضاحت نہیں کی جا سکتی ہے۔ راستہ، آپ گلوبنگ، پائپ اور دیگر شیل خصوصیات استعمال کرسکتے ہیں۔ عام طور پر خود بخود پتہ چل جاتا ہے اگر کوئی خاص حروف ہوں (|, ;, &&, || اور اسی طرح).

کرون

کرون جابز کو کنٹرول کرتا ہے۔

پیرامیٹرز:

  • وسائل کا نام - صرف ایک قسم کا شناخت کنندہ
  • کو یقینی بنانے کے - کراؤن جاب کی حالت:
    • present - اگر موجود نہیں ہے تو بنائیں
    • absent - اگر موجود ہو تو حذف کریں۔
  • کمانڈ - کیا حکم چلانے کے لئے
  • ماحول - کس ماحول میں کمانڈ چلانا ہے (ماحولیاتی متغیرات کی فہرست اور ان کی اقدار کے ذریعے =)
  • صارف - کس صارف سے کمانڈ چلانی ہے۔
  • منٹ, گھنٹہ, یوم ہفتہ, مہینے, مہینے کا دن - کرون کو کب چلانا ہے۔ اگر ان صفات میں سے کسی کی وضاحت نہیں کی گئی ہے، تو کرونٹاب میں اس کی قدر ہوگی۔ *.

پپٹ 6.0 میں کرون گویا باکس سے ہٹا دیا puppetserver میں، لہذا عام سائٹ پر کوئی دستاویز نہیں ہے۔ لیکن وہ باکس میں ہے کٹھ پتلی ایجنٹ میں، لہذا اسے الگ سے انسٹال کرنے کی ضرورت نہیں ہے۔ آپ اس کے لیے دستاویزات دیکھ سکتے ہیں۔ پپیٹ کے پانچویں ورژن کے لیے دستاویزات میںیا GitHub پر.

عام طور پر وسائل کے بارے میں

وسائل کی انفرادیت کے تقاضے

سب سے عام غلطی جس کا ہم سامنا کرتے ہیں۔ ڈپلیکیٹ اعلامیہ. یہ خرابی اس وقت ہوتی ہے جب ڈائرکٹری میں ایک ہی قسم کے ایک ہی نام کے دو یا زیادہ وسائل ظاہر ہوتے ہیں۔

لہذا، میں دوبارہ لکھوں گا: ایک ہی نوڈ کے مینی فیسٹ میں ایک ہی عنوان کے ساتھ ایک ہی قسم کے وسائل نہیں ہونے چاہئیں!

بعض اوقات ایک ہی نام کے ساتھ پیکیجز انسٹال کرنے کی ضرورت ہوتی ہے، لیکن مختلف پیکیج مینیجرز کے ساتھ۔ اس صورت میں، آپ کو پیرامیٹر استعمال کرنے کی ضرورت ہے nameغلطی سے بچنے کے لیے:

package { 'ruby-mysql':
  ensure   => installed,
  name     => 'mysql',
  provider => 'gem',
}
package { 'python-mysql':
  ensure   => installed,
  name     => 'mysql',
  provider => 'pip',
}

دیگر وسائل کی اقسام میں نقل سے بچنے میں مدد کے لیے اسی طرح کے اختیارات ہیں - name у سروس, command у عملدرآمد، اور اسی طرح.

میٹا پیرامیٹرز

وسائل کی ہر قسم میں کچھ خاص پیرامیٹرز ہوتے ہیں، قطع نظر اس کی نوعیت کچھ بھی ہو۔

میٹا پیرامیٹرز کی مکمل فہرست کٹھ پتلی دستاویزات میں.

مختصر فہرست:

  • کی ضرورت - یہ پیرامیٹر بتاتا ہے کہ یہ وسیلہ کن وسائل پر منحصر ہے۔
  • اس سے پہلے - یہ پیرامیٹر بتاتا ہے کہ کون سے وسائل اس وسائل پر منحصر ہیں۔
  • سبسکرائب - یہ پیرامیٹر بتاتا ہے کہ کن وسائل سے یہ وسیلہ اطلاعات موصول کرتا ہے۔
  • مطلع — یہ پیرامیٹر بتاتا ہے کہ کون سے وسائل اس وسائل سے اطلاعات وصول کرتے ہیں۔

تمام درج کردہ میٹا پیرامیٹرز یا تو ایک واحد وسیلہ لنک یا مربع بریکٹ میں لنکس کی ایک صف کو قبول کرتے ہیں۔

وسائل کے لنکس

وسائل کا لنک صرف وسائل کا ذکر ہے۔ وہ بنیادی طور پر انحصار کی نشاندہی کرنے کے لیے استعمال ہوتے ہیں۔ غیر موجود وسائل کا حوالہ دینا تالیف کی خرابی کا سبب بنے گا۔

لنک کا نحو اس طرح ہے: بڑے حرف کے ساتھ وسائل کی قسم (اگر قسم کے نام میں ڈبل کالون شامل ہیں، تو کالون کے درمیان نام کے ہر حصے کو کیپیٹلائز کیا جاتا ہے)، پھر اسکوائر بریکٹ میں وسائل کا نام (نام کا کیس) تبدیل نہیں ہوتا!) کوئی خالی جگہ نہیں ہونی چاہیے؛ مربع بریکٹ ٹائپ کے نام کے فوراً بعد لکھے جاتے ہیں۔

: مثال کے طور پر

file { '/file1': ensure => present }
file { '/file2':
  ensure => directory,
  before => File['/file1'],
}
file { '/file3': ensure => absent }
File['/file1'] -> File['/file3']

انحصار اور اطلاعات

یہاں دستاویزی.

جیسا کہ پہلے کہا گیا ہے، وسائل کے درمیان سادہ انحصار عبوری ہے۔ ویسے، انحصار شامل کرتے وقت محتاط رہیں - آپ سائیکلک انحصار بنا سکتے ہیں، جو تالیف کی غلطی کا سبب بنے گی۔

انحصار کے برعکس، اطلاعات عبوری نہیں ہیں۔ اطلاعات کے لیے درج ذیل اصول لاگو ہوتے ہیں:

  • اگر وسائل کو کوئی اطلاع موصول ہوتی ہے، تو اسے اپ ڈیٹ کر دیا جاتا ہے۔ اپ ڈیٹ کی کارروائیوں کا انحصار وسائل کی قسم - پر ہوتا ہے۔ عملدرآمد کمانڈ چلاتا ہے، سروس سروس دوبارہ شروع کرتا ہے، پیکج پیکیج کو دوبارہ انسٹال کرتا ہے۔ اگر وسائل میں اپ ڈیٹ کی کارروائی کی وضاحت نہیں کی گئی ہے، تو کچھ نہیں ہوتا ہے۔
  • کٹھ پتلی کے ایک رن کے دوران، وسائل کو ایک بار سے زیادہ اپ ڈیٹ نہیں کیا جاتا ہے۔ یہ ممکن ہے کیونکہ اطلاعات میں انحصار شامل ہوتا ہے اور انحصار گراف میں سائیکل نہیں ہوتے ہیں۔
  • اگر کٹھ پتلی کسی وسائل کی حالت کو تبدیل کرتا ہے، تو وسیلہ اس کے سبسکرائب کردہ تمام وسائل کو اطلاعات بھیجتا ہے۔
  • اگر کسی وسائل کو اپ ڈیٹ کیا جاتا ہے، تو یہ اس کے سبسکرائب کردہ تمام وسائل کو اطلاعات بھیجتا ہے۔

غیر متعینہ پیرامیٹرز کو سنبھالنا

ایک اصول کے طور پر، اگر کچھ ریسورس پیرامیٹر کی ڈیفالٹ ویلیو نہیں ہے اور یہ پیرامیٹر مینی فیسٹ میں متعین نہیں ہے، تو Puppet اس پراپرٹی کو نوڈ پر متعلقہ وسائل کے لیے تبدیل نہیں کرے گا۔ مثال کے طور پر، اگر قسم کا وسیلہ سنچکا پیرامیٹر متعین نہیں ہے۔ owner، پھر کٹھ پتلی متعلقہ فائل کے مالک کو تبدیل نہیں کرے گا۔

کلاسز، متغیرات اور تعریفوں کا تعارف

فرض کریں کہ ہمارے پاس کئی نوڈس ہیں جن میں کنفیگریشن کا ایک ہی حصہ ہے، لیکن ان میں فرق بھی ہے - ورنہ ہم ان سب کو ایک بلاک میں بیان کر سکتے ہیں۔ node {}. بلاشبہ، آپ کنفیگریشن کے ایک جیسے حصوں کو آسانی سے کاپی کر سکتے ہیں، لیکن عام طور پر یہ ایک برا حل ہے - کنفیگریشن بڑھ جاتی ہے، اور اگر آپ کنفیگریشن کے عمومی حصے کو تبدیل کرتے ہیں، تو آپ کو بہت سی جگہوں پر ایک ہی چیز کو ایڈٹ کرنا پڑے گا۔ ایک ہی وقت میں، غلطی کرنا آسان ہے، اور عام طور پر، DRY (اپنے آپ کو نہ دہرائیں) اصول ایک وجہ سے ایجاد کیا گیا تھا۔

اس مسئلے کو حل کرنے کے لیے اس طرح کا ڈیزائن موجود ہے۔ کلاس.

کلاسز۔

طبقے کے پاپیٹ کوڈ کا ایک نامزد بلاک ہے۔ کوڈ کو دوبارہ استعمال کرنے کے لیے کلاسز کی ضرورت ہے۔

سب سے پہلے کلاس کو بیان کرنے کی ضرورت ہے۔ تفصیل خود کہیں بھی وسائل کا اضافہ نہیں کرتی ہے۔ کلاس کو مینی فیسٹ میں بیان کیا گیا ہے:

# Описание класса начинается с ключевого слова class и его названия.
# Дальше идёт тело класса в фигурных скобках.
class example_class {
    ...
}

اس کے بعد کلاس کو استعمال کیا جا سکتا ہے:

# первый вариант использования — в стиле ресурса с типом class
class { 'example_class': }
# второй вариант использования — с помощью функции include
include example_class
# про отличие этих двух вариантов будет рассказано дальше

پچھلے کام کی ایک مثال - آئیے nginx کی انسٹالیشن اور کنفیگریشن کو کلاس میں منتقل کرتے ہیں:

class nginx_example {
    package { 'nginx':
        ensure => installed,
    }
    -> file { '/etc/nginx':
        ensure => directory,
        source => 'puppet:///modules/example/nginx-conf',
        recure => true,
        purge  => true,
        force  => true,
    }
    ~> service { 'nginx':
        ensure => running,
        enable => true,
    }
}

node 'server2.testdomain' {
    include nginx_example
}

متغیرات۔

پچھلی مثال کی کلاس بالکل بھی لچکدار نہیں ہے کیونکہ یہ ہمیشہ ایک ہی nginx کنفیگریشن لاتی ہے۔ آئیے کنفیگریشن متغیر کا راستہ بناتے ہیں، پھر اس کلاس کو کسی بھی کنفیگریشن کے ساتھ nginx انسٹال کرنے کے لیے استعمال کیا جا سکتا ہے۔

یہ کیا جا سکتا ہے۔ متغیرات کا استعمال کرتے ہوئے.

توجہ: کٹھ پتلی میں متغیرات ناقابل تغیر ہیں!

اس کے علاوہ، کسی متغیر تک اس کے اعلان کے بعد ہی رسائی حاصل کی جا سکتی ہے، ورنہ متغیر کی قدر undef.

متغیرات کے ساتھ کام کرنے کی مثال:

# создание переменных
$variable = 'value'
$var2 = 1
$var3 = true
$var4 = undef
# использование переменных
$var5 = $var6
file { '/tmp/text': content => $variable }
# интерполяция переменных — раскрытие значения переменных в строках. Работает только в двойных кавычках!
$var6 = "Variable with name variable has value ${variable}"

کٹھ پتلی کے پاس ہے۔ نام کی جگہیں، اور متغیرات، اس کے مطابق، ہیں مرئیت کا علاقہ: ایک ہی نام کے متغیر کو مختلف نام کی جگہوں میں بیان کیا جا سکتا ہے۔ متغیر کی قدر کو حل کرتے وقت، متغیر کو موجودہ نام کی جگہ، پھر منسلک نام کی جگہ، وغیرہ میں تلاش کیا جاتا ہے۔

نام کی جگہ کی مثالیں:

  • عالمی - کلاس یا نوڈ کی تفصیل سے باہر متغیرات وہاں جاتے ہیں۔
  • نوڈ کی تفصیل میں نوڈ نام کی جگہ؛
  • کلاس کی تفصیل میں کلاس نام کی جگہ۔

متغیر تک رسائی کے دوران ابہام سے بچنے کے لیے، آپ متغیر کے نام میں نام کی جگہ کی وضاحت کر سکتے ہیں:

# переменная без пространства имён
$var
# переменная в глобальном пространстве имён
$::var
# переменная в пространстве имён класса
$classname::var
$::classname::var

آئیے اس بات سے اتفاق کرتے ہیں کہ nginx کنفیگریشن کا راستہ متغیر میں ہے۔ $nginx_conf_source. پھر کلاس اس طرح نظر آئے گی:

class nginx_example {
    package { 'nginx':
        ensure => installed,
    }
    -> file { '/etc/nginx':
        ensure => directory,
        source => $nginx_conf_source,   # здесь используем переменную вместо фиксированной строки
        recure => true,
        purge  => true,
        force  => true,
    }
    ~> service { 'nginx':
        ensure => running,
        enable => true,
    }
}

node 'server2.testdomain' {
    $nginx_conf_source = 'puppet:///modules/example/nginx-conf'
    include nginx_example
}

تاہم، دی گئی مثال بری ہے کیونکہ کچھ "خفیہ علم" ہے کہ کلاس کے اندر کہیں فلاں اور فلاں نام کے ساتھ متغیر استعمال ہوتا ہے۔ اس علم کو عام کرنا زیادہ درست ہے - کلاسوں میں پیرامیٹرز ہو سکتے ہیں۔

کلاس کے پیرامیٹرز کلاس کے نام کی جگہ میں متغیرات ہیں، وہ کلاس ہیڈر میں بیان کیے گئے ہیں اور کلاس باڈی میں باقاعدہ متغیرات کی طرح استعمال کیے جا سکتے ہیں۔ مینی فیسٹ میں کلاس کا استعمال کرتے وقت پیرامیٹر کی قدریں بتائی جاتی ہیں۔

پیرامیٹر کو ڈیفالٹ ویلیو پر سیٹ کیا جا سکتا ہے۔ اگر کسی پیرامیٹر میں ڈیفالٹ ویلیو نہیں ہے اور استعمال کے وقت ویلیو سیٹ نہیں کی گئی ہے، تو اس سے تالیف میں خرابی پیدا ہوگی۔

آئیے اوپر دی گئی مثال سے کلاس کو پیرامیٹرائز کریں اور دو پیرامیٹرز شامل کریں: پہلا، مطلوبہ، کنفیگریشن کا راستہ ہے، اور دوسرا، اختیاری، nginx کے ساتھ پیکیج کا نام ہے (مثال کے طور پر، Debian میں، پیکیجز موجود ہیں nginx, nginx-light, nginx-full).

# переменные описываются сразу после имени класса в круглых скобках
class nginx_example (
  $conf_source,
  $package_name = 'nginx-light', # параметр со значением по умолчанию
) {
  package { $package_name:
    ensure => installed,
  }
  -> file { '/etc/nginx':
    ensure  => directory,
    source  => $conf_source,
    recurse => true,
    purge   => true,
    force   => true,
  }
  ~> service { 'nginx':
    ensure => running,
    enable => true,
  }
}

node 'server2.testdomain' {
  # если мы хотим задать параметры класса, функция include не подойдёт* — нужно использовать resource-style declaration
  # *на самом деле подойдёт, но про это расскажу в следующей серии. Ключевое слово "Hiera".
  class { 'nginx_example':
    conf_source => 'puppet:///modules/example/nginx-conf',   # задаём параметры класса точно так же, как параметры для других ресурсов
  }
}

پپٹ میں متغیرات ٹائپ کیے جاتے ہیں۔ کھاؤ بہت سے ڈیٹا کی اقسام. ڈیٹا کی قسمیں عام طور پر کلاسوں اور تعریفوں کو منتقل کردہ پیرامیٹر کی اقدار کی توثیق کرنے کے لیے استعمال ہوتی ہیں۔ اگر پاس شدہ پیرامیٹر مخصوص قسم سے مماثل نہیں ہے تو، ایک تالیف کی خرابی واقع ہوگی۔

قسم پیرامیٹر کے نام سے فوراً پہلے لکھی جاتی ہے:

class example (
  String $param1,
  Integer $param2,
  Array $param3,
  Hash $param4,
  Hash[String, String] $param5,
) {
  ...
}

کلاسز: کلاس کا نام بمقابلہ کلاس شامل کریں{'classname':}

ہر کلاس قسم کا ایک وسیلہ ہے۔ طبقے. کسی دوسرے قسم کے وسائل کی طرح، ایک ہی نوڈ پر ایک ہی کلاس کی دو مثالیں نہیں ہو سکتیں۔

اگر آپ ایک ہی نوڈ میں ایک کلاس کو دو بار استعمال کرنے کی کوشش کرتے ہیں۔ class { 'classname':} (کوئی فرق نہیں، مختلف یا ایک جیسے پیرامیٹرز کے ساتھ)، تالیف کی غلطی ہوگی۔ لیکن اگر آپ وسائل کے انداز میں کلاس استعمال کرتے ہیں، تو آپ فوری طور پر مینی فیسٹ میں اس کے تمام پیرامیٹرز کو واضح طور پر سیٹ کر سکتے ہیں۔

تاہم، اگر آپ استعمال کرتے ہیں include، پھر کلاس کو جتنی بار چاہیں شامل کیا جا سکتا ہے۔ حقیقت یہ ہے کہ include ایک idempotent فنکشن ہے جو چیک کرتا ہے کہ آیا ڈائرکٹری میں کلاس شامل کی گئی ہے۔ اگر کلاس ڈائرکٹری میں نہیں ہے تو، یہ اسے شامل کرتا ہے، اور اگر یہ پہلے سے موجود ہے، تو یہ کچھ نہیں کرتا. لیکن استعمال کرنے کی صورت میں include آپ کلاس ڈیکلریشن کے دوران کلاس کے پیرامیٹرز سیٹ نہیں کر سکتے ہیں - تمام مطلوبہ پیرامیٹرز کو ایک بیرونی ڈیٹا سورس - ہیرا یا ENC میں سیٹ کیا جانا چاہیے۔ ہم اگلے مضمون میں ان کے بارے میں بات کریں گے۔

تعریف کرتا ہے۔

جیسا کہ پچھلے بلاک میں کہا گیا تھا، ایک ہی کلاس نوڈ پر ایک سے زیادہ بار موجود نہیں ہو سکتی۔ تاہم، کچھ معاملات میں آپ کو ایک ہی نوڈ پر مختلف پیرامیٹرز کے ساتھ کوڈ کے ایک ہی بلاک کو استعمال کرنے کے قابل ہونے کی ضرورت ہے۔ دوسرے الفاظ میں، اس کے اپنے وسائل کی قسم کی ضرورت ہے.

مثال کے طور پر، پی ایچ پی ماڈیول کو انسٹال کرنے کے لیے، ہم Avito میں درج ذیل کام کرتے ہیں:

  1. اس ماڈیول کے ساتھ پیکج انسٹال کریں۔
  2. آئیے اس ماڈیول کے لیے ایک کنفیگریشن فائل بناتے ہیں۔
  3. ہم php-fpm کے لیے کنفیگریشن کے لیے ایک سملنک بناتے ہیں۔
  4. ہم php cli کے لیے تشکیل کے لیے ایک سملنک بناتے ہیں۔

اس طرح کے معاملات میں، ایک ڈیزائن جیسے وضاحت کریں (وضاحت، وضاحت شدہ قسم، وضاحت شدہ وسائل کی قسم)۔ ایک ڈیفائن کلاس کی طرح ہے، لیکن اس میں فرق ہیں: سب سے پہلے، ہر ڈیفائن ایک ریسورس کی قسم ہے، وسیلہ نہیں۔ دوم، ہر تعریف کا ایک مضمر پیرامیٹر ہوتا ہے۔ $title، جب وسائل کا نام اعلان کیا جاتا ہے تو وہ کہاں جاتا ہے۔ بالکل اسی طرح جیسے کلاسز کے معاملے میں، پہلے ایک تعریف بیان کی جانی چاہیے، جس کے بعد اسے استعمال کیا جا سکتا ہے۔

پی ایچ پی کے ماڈیول کے ساتھ ایک آسان مثال:

define php74::module (
  $php_module_name = $title,
  $php_package_name = "php7.4-${title}",
  $version = 'installed',
  $priority = '20',
  $data = "extension=${title}.son",
  $php_module_path = '/etc/php/7.4/mods-available',
) {
  package { $php_package_name:
    ensure          => $version,
    install_options => ['-o', 'DPkg::NoTriggers=true'],  # триггеры дебиановских php-пакетов сами создают симлинки и перезапускают сервис php-fpm - нам это не нужно, так как и симлинками, и сервисом мы управляем с помощью Puppet
  }
  -> file { "${php_module_path}/${php_module_name}.ini":
    ensure  => $ensure,
    content => $data,
  }
  file { "/etc/php/7.4/cli/conf.d/${priority}-${php_module_name}.ini":
    ensure  => link,
    target  => "${php_module_path}/${php_module_name}.ini",
  }
  file { "/etc/php/7.4/fpm/conf.d/${priority}-${php_module_name}.ini":
    ensure  => link,
    target  => "${php_module_path}/${php_module_name}.ini",
  }
}

node server3.testdomain {
  php74::module { 'sqlite3': }
  php74::module { 'amqp': php_package_name => 'php-amqp' }
  php74::module { 'msgpack': priority => '10' }
}

ڈپلیکیٹ ڈیکلریشن کی غلطی کو پکڑنے کا سب سے آسان طریقہ ڈیفائن میں ہے۔ ایسا ہوتا ہے اگر کسی تعریف میں مستقل نام کے ساتھ کوئی وسیلہ ہو، اور کسی نوڈ پر اس تعریف کی دو یا زیادہ مثالیں ہوں۔

اس سے اپنے آپ کو بچانا آسان ہے: تعریف کے اندر موجود تمام وسائل کا ایک نام ہونا ضروری ہے۔ $title. ایک متبادل وسائل کا غیرمعمولی اضافہ ہے؛ سب سے آسان صورت میں، یہ کافی ہے کہ تعریف کی تمام مثالوں میں مشترکہ وسائل کو ایک الگ کلاس میں منتقل کیا جائے اور اس کلاس کو تعریف میں شامل کیا جائے - فنکشن include کمزور

وسائل کو شامل کرتے وقت، یعنی فنکشنز کا استعمال کرتے ہوئے idempotency حاصل کرنے کے اور بھی طریقے ہیں۔ defined и ensure_resources، لیکن میں آپ کو اس کے بارے میں اگلی قسط میں بتاؤں گا۔

Зависимости и уведомления для классов и дефайнов

کلاسز اور تعریفیں انحصار اور اطلاعات سے نمٹنے کے لیے درج ذیل اصولوں کا اضافہ کرتی ہیں۔

  • کلاس/define پر انحصار کلاس/define کے تمام وسائل پر انحصار بڑھاتا ہے۔
  • ایک کلاس/تعریف انحصار تمام طبقے/تعریف وسائل میں انحصار کا اضافہ کرتا ہے۔
  • class/define نوٹیفکیشن کلاس/define کے تمام وسائل کو مطلع کرتا ہے۔
  • class/define سبسکرپشن کلاس/define کے تمام وسائل کو سبسکرائب کرتا ہے۔

مشروط بیانات اور سلیکٹرز

یہاں دستاویزی.

if

یہ یہاں آسان ہے:

if ВЫРАЖЕНИЕ1 {
  ...
} elsif ВЫРАЖЕНИЕ2 {
  ...
} else {
  ...
}

جب تک کہ

جب تک کہ ایک if ریورس میں نہ ہو: اگر اظہار غلط ہے تو کوڈ کے بلاک کو عمل میں لایا جائے گا۔

unless ВЫРАЖЕНИЕ {
  ...
}

کیس

یہاں بھی کوئی پیچیدہ چیز نہیں ہے۔ آپ ریگولر ویلیوز (سٹرنگز، نمبرز وغیرہ)، ریگولر ایکسپریشنز اور ڈیٹا کی اقسام کو بطور قدر استعمال کر سکتے ہیں۔

case ВЫРАЖЕНИЕ {
  ЗНАЧЕНИЕ1: { ... }
  ЗНАЧЕНИЕ2, ЗНАЧЕНИЕ3: { ... }
  default: { ... }
}

سلیکٹرز

سلیکٹر ایک زبان کی ساخت ہے جو اس سے ملتی جلتی ہے۔ case، لیکن کوڈ کے بلاک پر عمل کرنے کے بجائے، یہ ایک قدر لوٹاتا ہے۔

$var = $othervar ? { 'val1' => 1, 'val2' => 2, default => 3 }

ماڈیولز

جب کنفیگریشن چھوٹی ہو تو اسے آسانی سے ایک مینی فیسٹ میں رکھا جا سکتا ہے۔ لیکن جتنی زیادہ کنفیگریشنز ہم بیان کرتے ہیں، مینی فیسٹ میں جتنے زیادہ کلاسز اور نوڈس ہوتے ہیں، یہ بڑھتا ہے، اور اس کے ساتھ کام کرنے میں تکلیف ہوتی ہے۔

اس کے علاوہ، کوڈ کو دوبارہ استعمال کرنے کا مسئلہ ہے - جب تمام کوڈ ایک مینی فیسٹ میں ہوتے ہیں، تو اس کوڈ کو دوسروں کے ساتھ شیئر کرنا مشکل ہوتا ہے۔ ان دو مسائل کو حل کرنے کے لیے، کٹھ پتلی کے پاس ایک ہستی ہے جسے ماڈیول کہتے ہیں۔

ماڈیولز - یہ ایک الگ ڈائرکٹری میں رکھی گئی کلاسوں، تعریفوں اور دیگر کٹھ پتلی اداروں کے سیٹ ہیں۔ دوسرے الفاظ میں، ایک ماڈیول کٹھ پتلی منطق کا ایک آزاد ٹکڑا ہے۔ مثال کے طور پر، nginx کے ساتھ کام کرنے کے لیے ایک ماڈیول ہو سکتا ہے، اور اس میں وہی ہوگا جو nginx کے ساتھ کام کرنے کے لیے ضروری ہے، یا پی ایچ پی کے ساتھ کام کرنے کے لیے کوئی ماڈیول ہو سکتا ہے، وغیرہ۔

ماڈیولز کو ورژن بنایا گیا ہے، اور ایک دوسرے پر ماڈیولز کی انحصار بھی معاون ہے۔ ماڈیولز کا ایک کھلا ذخیرہ ہے - کٹھ پتلی فورج.

کٹھ پتلی سرور پر، ماڈیولز روٹ ڈائرکٹری کے ماڈیولز سب ڈائرکٹری میں واقع ہوتے ہیں۔ ہر ماڈیول کے اندر ایک معیاری ڈائریکٹری اسکیم ہوتی ہے - مینی فیسٹس، فائلز، ٹیمپلیٹس، lib وغیرہ۔

ماڈیول میں فائل کا ڈھانچہ

ماڈیول کی جڑ میں وضاحتی ناموں کے ساتھ درج ذیل ڈائریکٹریز شامل ہو سکتی ہیں۔

  • manifests - یہ منشور پر مشتمل ہے۔
  • files - اس میں فائلیں ہیں۔
  • templates - یہ ٹیمپلیٹس پر مشتمل ہے۔
  • lib - اس میں روبی کوڈ ہے۔

یہ ڈائریکٹریز اور فائلوں کی مکمل فہرست نہیں ہے، لیکن ابھی کے لیے اس مضمون کے لیے کافی ہے۔

ماڈیول میں وسائل کے نام اور فائلوں کے نام

یہاں دستاویزی.

ماڈیول میں وسائل (کلاسز، تعریفیں) کا نام آپ کی مرضی کے مطابق نہیں رکھا جا سکتا۔ اس کے علاوہ، وسائل کے نام اور فائل کے نام کے درمیان براہ راست خط و کتابت ہوتی ہے جس میں کٹھ پتلی اس وسائل کی تفصیل تلاش کرے گا۔ اگر آپ نام دینے کے اصولوں کی خلاف ورزی کرتے ہیں، تو Puppet کو وسائل کی تفصیل نہیں ملے گی، اور آپ کو تالیف کی غلطی ملے گی۔

اصول آسان ہیں:

  • ماڈیول کے تمام وسائل ماڈیول نام کی جگہ میں ہونے چاہئیں۔ اگر ماڈیول کہا جاتا ہے۔ foo، پھر اس میں موجود تمام وسائل کا نام ہونا چاہئے۔ foo::<anything>، یا صرف foo.
  • ماڈیول کے نام کا وسیلہ فائل میں ہونا چاہیے۔ init.pp.
  • دیگر وسائل کے لیے، فائل کے نام کی اسکیم درج ذیل ہے:
    • ماڈیول نام کے ساتھ سابقہ ​​رد کر دیا گیا ہے۔
    • تمام ڈبل کالون، اگر کوئی ہیں، کو سلیشوں سے بدل دیا جاتا ہے۔
    • توسیع شامل ہے .pp

میں ایک مثال کے ساتھ مظاہرہ کروں گا۔ ہم کہتے ہیں کہ میں ایک ماڈیول لکھ رہا ہوں۔ nginx. اس میں درج ذیل وسائل ہیں:

  • کلاس nginx منشور میں بیان کیا گیا ہے۔ init.pp;
  • کلاس nginx::service منشور میں بیان کیا گیا ہے۔ service.pp;
  • وضاحت کریں nginx::server منشور میں بیان کیا گیا ہے۔ server.pp;
  • وضاحت کریں nginx::server::location منشور میں بیان کیا گیا ہے۔ server/location.pp.

مراسلے

یقیناً آپ خود جانتے ہیں کہ ٹیمپلیٹس کیا ہیں؛ میں انہیں یہاں تفصیل سے بیان نہیں کروں گا۔ لیکن میں اسے صرف اس صورت میں چھوڑ دوں گا۔ ویکیپیڈیا سے لنک.

ٹیمپلیٹس کا استعمال کیسے کریں: فنکشن کا استعمال کرتے ہوئے ٹیمپلیٹ کے معنی کو بڑھایا جا سکتا ہے۔ template، جو ٹیمپلیٹ کے راستے سے گزر جاتا ہے۔ قسم کے وسائل کے لیے سنچکا پیرامیٹر کے ساتھ استعمال کیا جاتا ہے۔ content. مثال کے طور پر، اس طرح:

file { '/tmp/example': content => template('modulename/templatename.erb')

راستہ دیکھیں <modulename>/<filename> فائل کا مطلب ہے <rootdir>/modules/<modulename>/templates/<filename>.

اس کے علاوہ ، ایک فنکشن ہے۔ inline_template - یہ ٹیمپلیٹ کا متن بطور ان پٹ وصول کرتا ہے، فائل کا نام نہیں۔

ٹیمپلیٹس کے اندر، آپ موجودہ دائرہ کار میں تمام Puppet متغیرات استعمال کر سکتے ہیں۔

کٹھ پتلی ERB اور EPP فارمیٹ میں ٹیمپلیٹس کو سپورٹ کرتا ہے:

ERB کے بارے میں مختصراً

کنٹرول ڈھانچے:

  • <%= ВЫРАЖЕНИЕ %> - اظہار کی قدر داخل کریں۔
  • <% ВЫРАЖЕНИЕ %> - اظہار کی قدر کا حساب لگائیں (اسے داخل کیے بغیر)۔ مشروط بیانات (اگر) اور لوپس (ہر ایک) عام طور پر یہاں جاتے ہیں۔
  • <%# КОММЕНТАРИЙ %>

ERB میں اظہارات روبی میں لکھے گئے ہیں (ERB دراصل ایمبیڈڈ روبی ہے)۔

مینی فیسٹ سے متغیرات تک رسائی حاصل کرنے کے لیے، آپ کو شامل کرنے کی ضرورت ہے۔ @ متغیر کے نام پر۔ کنٹرول کنسٹرکٹ کے بعد ظاہر ہونے والے لائن بریک کو ہٹانے کے لیے، آپ کو کلوزنگ ٹیگ استعمال کرنے کی ضرورت ہے۔ -%>.

ٹیمپلیٹ استعمال کرنے کی مثال

ہم کہتے ہیں کہ میں ZooKeeper کو کنٹرول کرنے کے لیے ایک ماڈیول لکھ رہا ہوں۔ تشکیل بنانے کے لئے ذمہ دار کلاس کچھ اس طرح نظر آتی ہے:

class zookeeper::configure (
  Array[String] $nodes,
  Integer $port_client,
  Integer $port_quorum,
  Integer $port_leader,
  Hash[String, Any] $properties,
  String $datadir,
) {
  file { '/etc/zookeeper/conf/zoo.cfg':
    ensure  => present,
    content => template('zookeeper/zoo.cfg.erb'),
  }
}

اور متعلقہ ٹیمپلیٹ zoo.cfg.erb - تو:

<% if @nodes.length > 0 -%>
<% @nodes.each do |node, id| -%>
server.<%= id %>=<%= node %>:<%= @port_leader %>:<%= @port_quorum %>;<%= @port_client %>
<% end -%>
<% end -%>

dataDir=<%= @datadir %>

<% @properties.each do |k, v| -%>
<%= k %>=<%= v %>
<% end -%>

حقائق اور بلٹ ان متغیرات

اکثر ترتیب کا مخصوص حصہ اس بات پر منحصر ہوتا ہے کہ اس وقت نوڈ پر کیا ہو رہا ہے۔ مثال کے طور پر، اس بات پر منحصر ہے کہ ڈیبین ریلیز کیا ہے، آپ کو پیکیج کا ایک یا دوسرا ورژن انسٹال کرنے کی ضرورت ہے۔ آپ ان سب کی دستی طور پر نگرانی کر سکتے ہیں، نوڈس تبدیل ہونے پر دوبارہ لکھنا ظاہر ہوتا ہے۔ لیکن یہ کوئی سنجیدہ نقطہ نظر نہیں ہے؛ آٹومیشن بہت بہتر ہے۔

نوڈس کے بارے میں معلومات حاصل کرنے کے لیے، پپیٹ کا ایک طریقہ کار ہے جسے حقائق کہتے ہیں۔ حقائق - یہ نوڈ کے بارے میں معلومات ہے، جو عالمی نام کی جگہ میں عام متغیرات کی شکل میں مینی فیسٹ میں دستیاب ہے۔ مثال کے طور پر، میزبان کا نام، آپریٹنگ سسٹم کا ورژن، پروسیسر کا فن تعمیر، صارفین کی فہرست، نیٹ ورک انٹرفیس اور ان کے پتے کی فہرست، اور بہت کچھ۔ حقائق مینی فیسٹس اور ٹیمپلیٹس میں باقاعدہ متغیر کے طور پر دستیاب ہیں۔

حقائق کے ساتھ کام کرنے کی ایک مثال:

notify { "Running OS ${facts['os']['name']} version ${facts['os']['release']['full']}": }
# ресурс типа notify просто выводит сообщение в лог

رسمی طور پر، ایک حقیقت کا ایک نام (سٹرنگ) اور ایک قدر ہوتی ہے (مختلف اقسام دستیاب ہیں: تار، صفیں، لغات)۔ کھاؤ بلٹ ان حقائق کا مجموعہ. آپ خود بھی لکھ سکتے ہیں۔ حقائق جمع کرنے والے بیان کیے گئے ہیں۔ جیسے روبی میں افعالیا کیسے قابل عمل فائلیں. حقائق کو فارم میں بھی پیش کیا جا سکتا ہے۔ ڈیٹا کے ساتھ ٹیکسٹ فائلیں نوڈس پر.

آپریشن کے دوران، کٹھ پتلی ایجنٹ سب سے پہلے پیپیٹسرور سے نوڈ پر تمام دستیاب فیکٹ جمع کرنے والوں کو کاپی کرتا ہے، جس کے بعد وہ انہیں لانچ کرتا ہے اور جمع شدہ حقائق کو سرور کو بھیجتا ہے۔ اس کے بعد سرور کیٹلاگ کو مرتب کرنا شروع کر دیتا ہے۔

قابل عمل فائلوں کی شکل میں حقائق

اس طرح کے حقائق کو ڈائریکٹری میں ماڈیولز میں رکھا گیا ہے۔ facts.d. یقینا، فائلوں کو قابل عمل ہونا چاہئے۔ جب چلایا جائے، تو انہیں YAML یا key=value فارمیٹ میں معیاری آؤٹ پٹ میں معلومات کو آؤٹ پٹ کرنا چاہیے۔

یہ نہ بھولیں کہ حقائق ان تمام نوڈس پر لاگو ہوتے ہیں جو پاپیٹ سرور کے ذریعے کنٹرول ہوتے ہیں جس پر آپ کا ماڈیول لگایا جاتا ہے۔ اس لیے، اسکرپٹ میں، یہ چیک کرنے کا خیال رکھیں کہ سسٹم میں آپ کی حقیقت کے کام کرنے کے لیے ضروری تمام پروگرامز اور فائلیں موجود ہیں۔

#!/bin/sh
echo "testfact=success"
#!/bin/sh
echo '{"testyamlfact":"success"}'

روبی حقائق

اس طرح کے حقائق کو ڈائریکٹری میں ماڈیولز میں رکھا گیا ہے۔ lib/facter.

# всё начинается с вызова функции Facter.add с именем факта и блоком кода
Facter.add('ladvd') do
# в блоках confine описываются условия применимости факта — код внутри блока должен вернуть true, иначе значение факта не вычисляется и не возвращается
  confine do
    Facter::Core::Execution.which('ladvdc') # проверим, что в PATH есть такой исполняемый файл
  end
  confine do
    File.socket?('/var/run/ladvd.sock') # проверим, что есть такой UNIX-domain socket
  end
# в блоке setcode происходит собственно вычисление значения факта
  setcode do
    hash = {}
    if (out = Facter::Core::Execution.execute('ladvdc -b'))
      out.split.each do |l|
        line = l.split('=')
        next if line.length != 2
        name, value = line
        hash[name.strip.downcase.tr(' ', '_')] = value.strip.chomp(''').reverse.chomp(''').reverse
      end
    end
    hash  # значение последнего выражения в блоке setcode является значением факта
  end
end

متن حقائق

اس طرح کے حقائق ڈائریکٹری میں نوڈس پر رکھے جاتے ہیں۔ /etc/facter/facts.d پرانے کٹھ پتلی میں یا /etc/puppetlabs/facts.d نئی کٹھ پتلی میں.

examplefact=examplevalue
---
examplefact2: examplevalue2
anotherfact: anothervalue

حقائق تک پہنچنا

حقائق تک پہنچنے کے دو طریقے ہیں:

  • لغت کے ذریعے $facts: $facts['fqdn'];
  • متغیر نام کے طور پر حقیقت کا نام استعمال کرنا: $fqdn.

لغت کا استعمال کرنا بہتر ہے۔ $facts، یا اس سے بھی بہتر، عالمی نام کی جگہ کی نشاندہی کریں ($::facts).

یہاں دستاویزات کا متعلقہ سیکشن ہے۔

بلٹ ان متغیرات

حقائق کے علاوہ، یہ بھی ہے کچھ متغیرات، عالمی نام کی جگہ میں دستیاب ہے۔

  • قابل اعتماد حقائق - متغیرات جو کلائنٹ کے سرٹیفکیٹ سے لیے گئے ہیں (چونکہ سرٹیفکیٹ عام طور پر پاپیٹ سرور پر جاری کیا جاتا ہے، ایجنٹ صرف اس کا سرٹیفکیٹ نہیں لے سکتا اور اسے تبدیل نہیں کرسکتا، اس لیے متغیرات "قابل اعتماد" ہیں): سرٹیفکیٹ کا نام، نام میزبان اور ڈومین، سرٹیفکیٹ سے ایکسٹینشنز۔
  • سرور کے حقائق سرور کے بارے میں معلومات سے متعلق متغیرات - ورژن، نام، سرور IP ایڈریس، ماحول۔
  • ایجنٹ کے حقائق — متغیرات براہ راست کٹھ پتلی ایجنٹ کے ذریعے شامل کیے گئے ہیں، نہ کہ فیکٹر کے ذریعے — سرٹیفکیٹ کا نام، ایجنٹ کا ورژن، کٹھ پتلی ورژن۔
  • ماسٹر متغیرات - پیپیٹ ماسٹر متغیرات (sic!) یہ تقریباً ویسا ہی ہے جیسا کہ میں ہے۔ سرور کے حقائقکے علاوہ کنفیگریشن پیرامیٹر کی قدریں دستیاب ہیں۔
  • مرتب متغیرات - مرتب کرنے والے متغیرات جو ہر دائرہ کار میں مختلف ہوتے ہیں: موجودہ ماڈیول کا نام اور اس ماڈیول کا نام جس میں موجودہ آبجیکٹ تک رسائی حاصل کی گئی تھی۔ ان کو استعمال کیا جا سکتا ہے، مثال کے طور پر، یہ چیک کرنے کے لیے کہ آپ کی نجی کلاسیں دوسرے ماڈیولز سے براہ راست استعمال نہیں ہو رہی ہیں۔

اضافہ 1: یہ سب کیسے چلائیں اور ڈیبگ کریں؟

مضمون میں کٹھ پتلی کوڈ کی بہت سی مثالیں تھیں، لیکن ہمیں یہ نہیں بتایا کہ اس کوڈ کو کیسے چلایا جائے۔ ٹھیک ہے، میں خود کو درست کر رہا ہوں.

کٹھ پتلی چلانے کے لیے ایک ایجنٹ کافی ہے، لیکن زیادہ تر معاملات کے لیے آپ کو سرور کی بھی ضرورت ہوگی۔

ایجنٹ

کم از کم ورژن XNUMX کے بعد سے، کٹھ پتلی ایجنٹ پیکجز سے سرکاری Puppetlabs ذخیرہ تمام انحصار (روبی اور متعلقہ جواہرات) پر مشتمل ہے، اس لیے تنصیب میں کوئی دشواری نہیں ہے (میں ڈیبین پر مبنی تقسیم کے بارے میں بات کر رہا ہوں - ہم RPM پر مبنی تقسیم کا استعمال نہیں کرتے ہیں)۔

آسان ترین صورت میں، کٹھ پتلی ترتیب کو استعمال کرنے کے لیے، ایجنٹ کو سرور لیس موڈ میں لانچ کرنا کافی ہے: بشرطیکہ کٹھ پتلی کوڈ کو نوڈ پر کاپی کیا گیا ہو، لانچ puppet apply <путь к манифесту>:

atikhonov@atikhonov ~/puppet-test $ cat helloworld.pp 
node default {
    notify { 'Hello world!': }
}
atikhonov@atikhonov ~/puppet-test $ puppet apply helloworld.pp 
Notice: Compiled catalog for atikhonov.localdomain in environment production in 0.01 seconds
Notice: Hello world!
Notice: /Stage[main]/Main/Node[default]/Notify[Hello world!]/message: defined 'message' as 'Hello world!'
Notice: Applied catalog in 0.01 seconds

یقیناً یہ بہتر ہے کہ سرور کو سیٹ اپ کریں اور ڈیمون موڈ میں نوڈس پر ایجنٹوں کو چلائیں - پھر وہ ہر آدھے گھنٹے میں ایک بار سرور سے ڈاؤن لوڈ کی گئی ترتیب کو لاگو کریں گے۔

آپ کام کے پش ماڈل کی نقل کر سکتے ہیں - جس نوڈ میں آپ دلچسپی رکھتے ہیں اس پر جائیں اور شروع کریں۔ sudo puppet agent -t. چابی -t (--test) درحقیقت کئی آپشنز شامل ہیں جنہیں انفرادی طور پر فعال کیا جا سکتا ہے۔ ان اختیارات میں درج ذیل شامل ہیں:

  • ڈیمون موڈ میں نہ چلائیں (بطور ڈیفالٹ ایجنٹ ڈیمون موڈ میں شروع ہوتا ہے)؛
  • کیٹلاگ کو لاگو کرنے کے بعد بند کریں (بطور ڈیفالٹ، ایجنٹ کام کرتا رہے گا اور ہر آدھے گھنٹے میں ایک بار کنفیگریشن لاگو کرے گا)؛
  • ایک تفصیلی کام لاگ لکھیں؛
  • فائلوں میں تبدیلیاں دکھائیں۔

ایجنٹ کے پاس بغیر کسی تبدیلی کے آپریٹنگ موڈ ہوتا ہے - آپ اسے اس وقت استعمال کر سکتے ہیں جب آپ کو یقین نہ ہو کہ آپ نے درست کنفیگریشن لکھی ہے اور آپ یہ دیکھنا چاہتے ہیں کہ آپریشن کے دوران ایجنٹ میں کیا تبدیلی آئے گی۔ یہ موڈ پیرامیٹر کے ذریعہ فعال کیا گیا ہے۔ --noop کمانڈ لائن پر: sudo puppet agent -t --noop.

اس کے علاوہ، آپ کام کے ڈیبگنگ لاگ کو فعال کر سکتے ہیں - اس میں، کٹھ پتلی ان تمام کارروائیوں کے بارے میں لکھتا ہے جو وہ انجام دیتا ہے: اس وسیلہ کے بارے میں جس پر وہ اس وقت کارروائی کر رہا ہے، اس وسیلہ کے پیرامیٹرز کے بارے میں، اس کے بارے میں کہ یہ کون سے پروگرام شروع کرتا ہے۔ یقیناً یہ ایک پیرامیٹر ہے۔ --debug.

سرور

میں اس مضمون میں pappetserver کے مکمل سیٹ اپ اور اس میں کوڈ کی تعیناتی پر غور نہیں کروں گا؛ میں صرف اتنا کہوں گا کہ سرور کا ایک مکمل طور پر فعال ورژن موجود ہے جس کے ساتھ کام کرنے کے لیے اضافی کنفیگریشن کی ضرورت نہیں ہے۔ نوڈس کی تعداد (کہیں، سو تک)۔ نوڈس کی ایک بڑی تعداد کو ٹیوننگ کی ضرورت ہوگی - پہلے سے طے شدہ طور پر، کٹھ پتلی سرور چار سے زیادہ کارکنوں کو لانچ نہیں کرتا ہے، زیادہ کارکردگی کے لیے آپ کو ان کی تعداد بڑھانے کی ضرورت ہے اور میموری کی حد کو بڑھانا نہ بھولیں، بصورت دیگر سرور زیادہ تر وقت کوڑا کرکٹ جمع کرے گا۔

کوڈ کی تعیناتی - اگر آپ کو جلدی اور آسانی سے اس کی ضرورت ہو، تو دیکھیں (r10k پر)[https://github.com/puppetlabs/r10k]، چھوٹی تنصیبات کے لیے یہ کافی ہونا چاہیے۔

ضمیمہ 2: کوڈنگ کے رہنما خطوط

  1. تمام منطق کو کلاسوں اور تعریفوں میں رکھیں۔
  2. کلاسز اور تعریفیں ماڈیولز میں رکھیں، نہ کہ نوڈس کو بیان کرنے والے مینی فیسٹس میں۔
  3. حقائق کا استعمال کریں۔
  4. میزبان ناموں کی بنیاد پر ifs نہ بنائیں۔
  5. کلاسز اور تعریفوں کے لیے بلا جھجھک پیرامیٹرز شامل کریں - یہ کلاس/define کے باڈی میں چھپی ہوئی مضمر منطق سے بہتر ہے۔

میں وضاحت کروں گا کہ میں اگلے مضمون میں ایسا کرنے کی سفارش کیوں کرتا ہوں۔

حاصل يہ ہوا

آئیے تعارف کے ساتھ ختم کرتے ہیں۔ اگلے مضمون میں میں آپ کو Hiera، ENC اور PuppetDB کے بارے میں بتاؤں گا۔

سروے میں صرف رجسٹرڈ صارفین ہی حصہ لے سکتے ہیں۔ سائن ان، برائے مہربانی.

درحقیقت، بہت زیادہ مواد ہے - میں مندرجہ ذیل عنوانات پر مضامین لکھ سکتا ہوں، اس پر ووٹ دیں جس کے بارے میں آپ کو پڑھنے میں دلچسپی ہو گی:

  • 59,1٪اعلی درجے کی کٹھ پتلی تعمیرات - کچھ اگلے درجے کی گندگی: لوپس، میپنگ اور دیگر لیمبڈا اظہار، وسائل جمع کرنے والے، برآمد شدہ وسائل اور کٹھ پتلی، ٹیگز، فراہم کنندگان، خلاصہ ڈیٹا کی اقسام کے ذریعے بین میزبان مواصلات۔13
  • 31,8٪"میں اپنی ماں کا ایڈمن ہوں" یا ہم نے Avito میں مختلف ورژنز کے کئی پاپیٹ سرورز کے ساتھ دوستی کیسے کی، اور اصولی طور پر، پاپیٹ سرور کے انتظام کے بارے میں حصہ۔7
  • 81,8٪ہم کٹھ پتلی کوڈ کیسے لکھتے ہیں: آلہ سازی، دستاویزات، جانچ، CI/CD.18

22 صارفین نے ووٹ دیا۔ 9 صارفین غیر حاضر رہے۔

ماخذ: www.habr.com