പപ്പറ്റ് ഒരു കോൺഫിഗറേഷൻ മാനേജ്മെന്റ് സിസ്റ്റമാണ്. ഹോസ്റ്റുകളെ ആവശ്യമുള്ള അവസ്ഥയിലേക്ക് കൊണ്ടുവരാനും ഈ അവസ്ഥ നിലനിർത്താനും ഇത് ഉപയോഗിക്കുന്നു.

ഞാൻ ഇപ്പോൾ അഞ്ച് വർഷത്തിലേറെയായി പപ്പറ്റിനൊപ്പം പ്രവർത്തിക്കുന്നു. ഈ വാചകം അടിസ്ഥാനപരമായി ഔദ്യോഗിക ഡോക്യുമെന്റേഷനിൽ നിന്നുള്ള പ്രധാന പോയിന്റുകളുടെ വിവർത്തനം ചെയ്യുകയും പുനഃക്രമീകരിക്കുകയും ചെയ്ത സമാഹാരമാണ്, ഇത് തുടക്കക്കാർക്ക് പപ്പറ്റിന്റെ സാരാംശം വേഗത്തിൽ മനസ്സിലാക്കാൻ അനുവദിക്കും.

അടിസ്ഥാന വിവരങ്ങൾ

പപ്പറ്റിന്റെ ഓപ്പറേറ്റിംഗ് സിസ്റ്റം ക്ലയന്റ്-സെർവർ ആണ്, എന്നിരുന്നാലും ഇത് പരിമിതമായ പ്രവർത്തനക്ഷമതയുള്ള സെർവർലെസ് പ്രവർത്തനത്തെ പിന്തുണയ്ക്കുന്നു.

പ്രവർത്തനത്തിന്റെ ഒരു പുൾ മോഡൽ ഉപയോഗിക്കുന്നു: സ്ഥിരസ്ഥിതിയായി, ഓരോ അരമണിക്കൂറിലും ഒരിക്കൽ, ക്ലയന്റുകൾ ഒരു കോൺഫിഗറേഷനായി സെർവറുമായി ബന്ധപ്പെടുകയും അത് പ്രയോഗിക്കുകയും ചെയ്യുന്നു. നിങ്ങൾ അൻസിബിളിൽ പ്രവർത്തിച്ചിട്ടുണ്ടെങ്കിൽ, അവർ മറ്റൊരു പുഷ് മോഡൽ ഉപയോഗിക്കുന്നു: അഡ്മിനിസ്ട്രേറ്റർ കോൺഫിഗറേഷൻ പ്രയോഗിക്കുന്നതിനുള്ള പ്രക്രിയ ആരംഭിക്കുന്നു, ക്ലയന്റുകൾ സ്വയം ഒന്നും പ്രയോഗിക്കില്ല.

നെറ്റ്‌വർക്ക് ആശയവിനിമയ സമയത്ത്, ടു-വേ TLS എൻക്രിപ്ഷൻ ഉപയോഗിക്കുന്നു: സെർവറിനും ക്ലയന്റിനും അവരുടേതായ സ്വകാര്യ കീകളും അനുബന്ധ സർട്ടിഫിക്കറ്റുകളും ഉണ്ട്. സാധാരണയായി സെർവർ ക്ലയന്റുകൾക്ക് സർട്ടിഫിക്കറ്റുകൾ നൽകുന്നു, എന്നാൽ തത്വത്തിൽ ഒരു ബാഹ്യ CA ഉപയോഗിക്കാൻ കഴിയും.

മാനിഫെസ്റ്റോകളുടെ ആമുഖം

പപ്പറ്റ് ടെർമിനോളജിയിൽ പാവ സെർവറിലേക്ക് ബന്ധിപ്പിക്കുക നോഡുകൾ (നോഡുകൾ). നോഡുകൾക്കുള്ള കോൺഫിഗറേഷൻ എഴുതിയിരിക്കുന്നു പ്രകടനപത്രികകളിൽ ഒരു പ്രത്യേക പ്രോഗ്രാമിംഗ് ഭാഷയിൽ - പപ്പറ്റ് 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-ലെ ഫയലുകളുടെ സ്ഥാനം

കൂടുതൽ വിശദീകരണത്തിനായി, "റൂട്ട് ഡയറക്ടറി" എന്ന ആശയം ഞാൻ അവതരിപ്പിക്കും. ഒരു പ്രത്യേക നോഡിനുള്ള പപ്പറ്റ് കോൺഫിഗറേഷൻ അടങ്ങുന്ന ഡയറക്ടറിയാണ് റൂട്ട് ഡയറക്ടറി.

പപ്പറ്റിന്റെ പതിപ്പും ഉപയോഗിക്കുന്ന പരിതസ്ഥിതികളും അനുസരിച്ച് റൂട്ട് ഡയറക്ടറി വ്യത്യാസപ്പെടുന്നു. പ്രത്യേക ഡയറക്ടറികളിൽ സംഭരിച്ചിരിക്കുന്ന കോൺഫിഗറേഷന്റെ സ്വതന്ത്ര സെറ്റുകളാണ് പരിസ്ഥിതികൾ. സാധാരണയായി git-മായി സംയോജിപ്പിച്ച് ഉപയോഗിക്കുന്നു, ഈ സാഹചര്യത്തിൽ git ശാഖകളിൽ നിന്ന് പരിസ്ഥിതികൾ സൃഷ്ടിക്കപ്പെടുന്നു. അതനുസരിച്ച്, ഓരോ നോഡും ഒരു പരിതസ്ഥിതിയിൽ അല്ലെങ്കിൽ മറ്റൊന്നിൽ സ്ഥിതിചെയ്യുന്നു. ഇത് നോഡിൽ തന്നെ അല്ലെങ്കിൽ 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 - സിംലിങ്ക്
• ഉള്ളടക്കം — ഫയൽ ഉള്ളടക്കങ്ങൾ (സാധാരണ ഫയലുകൾക്ക് മാത്രം അനുയോജ്യം, ഒരുമിച്ച് ഉപയോഗിക്കാൻ കഴിയില്ല ഉറവിടം അഥവാ ലക്ഷ്യം)
• ഉറവിടം — ഫയലിന്റെ ഉള്ളടക്കങ്ങൾ പകർത്താൻ നിങ്ങൾ ആഗ്രഹിക്കുന്ന പാതയിലേക്കുള്ള ഒരു ലിങ്ക് (കൂടെ ഉപയോഗിക്കാൻ കഴിയില്ല ഉള്ളടക്കം അഥവാ ലക്ഷ്യം). ഒരു സ്കീമുള്ള ഒരു URI ആയി വ്യക്തമാക്കാം 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 - നിർത്തി
• പ്രവർത്തനക്ഷമമാക്കുക - സേവനം ആരംഭിക്കാനുള്ള കഴിവ് നിയന്ത്രിക്കുന്നു:
  • true — ഓട്ടോറൺ പ്രവർത്തനക്ഷമമാക്കി (systemctl enable)
  • mask - വേഷംമാറി (systemctl mask)
  • false — ഓട്ടോറൺ പ്രവർത്തനരഹിതമാക്കി (systemctl disable)
• പുനരാരംഭിക്കുക - സേവനം പുനരാരംഭിക്കാനുള്ള കമാൻഡ്
• പദവി - സേവന നില പരിശോധിക്കുന്നതിനുള്ള കമാൻഡ്
• പുനരാരംഭിക്കുക — സർവീസ് initscript പുനരാരംഭിക്കുന്നതിനെ പിന്തുണയ്ക്കുന്നുണ്ടോ എന്ന് സൂചിപ്പിക്കുക. എങ്കിൽ false കൂടാതെ പരാമീറ്റർ വ്യക്തമാക്കിയിട്ടുണ്ട് പുനരാരംഭിക്കുക - ഈ പരാമീറ്ററിന്റെ മൂല്യം ഉപയോഗിക്കുന്നു. എങ്കിൽ false പരാമീറ്ററും പുനരാരംഭിക്കുക വ്യക്തമാക്കിയിട്ടില്ല - സേവനം നിർത്തി പുനരാരംഭിക്കാൻ തുടങ്ങി (എന്നാൽ systemd കമാൻഡ് ഉപയോഗിക്കുന്നു systemctl restart).
• പദവി — സർവീസ് initscript കമാൻഡിനെ പിന്തുണയ്ക്കുന്നുണ്ടോ എന്ന് സൂചിപ്പിക്കുക status. എങ്കിൽ false, തുടർന്ന് പാരാമീറ്റർ മൂല്യം ഉപയോഗിക്കുന്നു പദവി. സ്ഥിരസ്ഥിതി true.

exec

ബാഹ്യ കമാൻഡുകൾ പ്രവർത്തിപ്പിക്കുന്നു. നിങ്ങൾ പരാമീറ്ററുകൾ വ്യക്തമാക്കിയിട്ടില്ലെങ്കിൽ സൃഷ്ടിക്കുന്നു, എങ്കിൽ മാത്രം, അല്ലാതെ അഥവാ ഉന്മേഷദായകമായി, ഓരോ തവണയും പപ്പറ്റ് പ്രവർത്തിപ്പിക്കുമ്പോൾ കമാൻഡ് പ്രവർത്തിപ്പിക്കും. അറിയിപ്പുകൾ പ്രോസസ്സ് ചെയ്യാൻ കഴിയും - ഒരു കമാൻഡ് പ്രവർത്തിപ്പിക്കുന്നു.

പാരാമീറ്ററുകൾ:

• വിഭവ നാമം - എക്സിക്യൂട്ട് ചെയ്യേണ്ട കമാൻഡ് (ഓപ്ഷണൽ)
• കമാൻഡ് - എക്സിക്യൂട്ട് ചെയ്യേണ്ട കമാൻഡ് (അത് പേരിൽ വ്യക്തമാക്കിയിട്ടില്ലെങ്കിൽ)
• പാത — എക്സിക്യൂട്ടബിൾ ഫയലിനായി നോക്കേണ്ട പാതകൾ
• എങ്കിൽ മാത്രം — ഈ പരാമീറ്ററിൽ വ്യക്തമാക്കിയിട്ടുള്ള കമാൻഡ് പൂജ്യം റിട്ടേൺ കോഡ് ഉപയോഗിച്ച് പൂർത്തിയാക്കിയാൽ, പ്രധാന കമാൻഡ് എക്സിക്യൂട്ട് ചെയ്യപ്പെടും.
• അല്ലാതെ - ഈ പരാമീറ്ററിൽ വ്യക്തമാക്കിയ കമാൻഡ് പൂജ്യമല്ലാത്ത റിട്ടേൺ കോഡ് ഉപയോഗിച്ച് പൂർത്തിയാക്കിയാൽ, പ്രധാന കമാൻഡ് എക്സിക്യൂട്ട് ചെയ്യപ്പെടും.
• സൃഷ്ടിക്കുന്നു — ഈ പരാമീറ്ററിൽ വ്യക്തമാക്കിയ ഫയൽ നിലവിലില്ലെങ്കിൽ, പ്രധാന കമാൻഡ് എക്സിക്യൂട്ട് ചെയ്യപ്പെടും
• ഉന്മേഷദായകമായി - എങ്കിൽ true, പിന്നീട് ഈ എക്സിക്യൂട്ടീവിന് മറ്റ് ഉറവിടങ്ങളിൽ നിന്ന് അറിയിപ്പ് ലഭിക്കുമ്പോൾ മാത്രമേ കമാൻഡ് പ്രവർത്തിപ്പിക്കുകയുള്ളൂ
• 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 у exec, ഇത്യാദി.

മെറ്റാപാരാമീറ്ററുകൾ

ഓരോ റിസോഴ്സ് തരത്തിനും അതിന്റെ സ്വഭാവം പരിഗണിക്കാതെ തന്നെ ചില പ്രത്യേക പാരാമീറ്ററുകൾ ഉണ്ട്.

മെറ്റാ പാരാമീറ്ററുകളുടെ പൂർണ്ണ ലിസ്റ്റ് പപ്പറ്റ് ഡോക്യുമെന്റേഷനിൽ.

ഹ്രസ്വ പട്ടിക:

• ആവശ്യമുണ്ട് — ഈ പരാമീറ്റർ ഈ വിഭവം ആശ്രയിക്കുന്ന ഉറവിടങ്ങളെ സൂചിപ്പിക്കുന്നു.
• മുമ്പ് - ഈ പരാമീറ്റർ ഈ വിഭവത്തെ ആശ്രയിക്കുന്ന ഉറവിടങ്ങൾ വ്യക്തമാക്കുന്നു.
• സബ്സ്ക്രൈബുചെയ്യുന്നതിനും — ഏത് ഉറവിടങ്ങളിൽ നിന്നാണ് ഈ ഉറവിടത്തിന് അറിയിപ്പുകൾ ലഭിക്കുന്നതെന്ന് ഈ പരാമീറ്റർ വ്യക്തമാക്കുന്നു.
• അറിയിക്കുക — ഈ ഉറവിടത്തിൽ നിന്ന് അറിയിപ്പുകൾ സ്വീകരിക്കുന്ന ഉറവിടങ്ങൾ ഈ പരാമീറ്റർ വ്യക്തമാക്കുന്നു.

ലിസ്‌റ്റ് ചെയ്‌തിരിക്കുന്ന എല്ലാ മെറ്റാപാരാമീറ്ററുകളും ഒരൊറ്റ റിസോഴ്‌സ് ലിങ്ക് അല്ലെങ്കിൽ സ്‌ക്വയർ ബ്രാക്കറ്റിലുള്ള ലിങ്കുകളുടെ ഒരു നിര സ്വീകരിക്കുന്നു.

ഉറവിടങ്ങളിലേക്കുള്ള ലിങ്കുകൾ

റിസോഴ്‌സ് ലിങ്ക് എന്നത് റിസോഴ്‌സിന്റെ പരാമർശം മാത്രമാണ്. ആശ്രിതത്വം സൂചിപ്പിക്കാൻ അവ പ്രധാനമായും ഉപയോഗിക്കുന്നു. നിലവിലില്ലാത്ത ഒരു ഉറവിടം പരാമർശിക്കുന്നത് ഒരു സമാഹാര പിശകിന് കാരണമാകും.

ലിങ്കിന്റെ വാക്യഘടന ഇപ്രകാരമാണ്: ഒരു വലിയ അക്ഷരമുള്ള റിസോഴ്‌സ് തരം (തരം പേരിൽ ഇരട്ട കോളണുകൾ അടങ്ങിയിട്ടുണ്ടെങ്കിൽ, കോളണുകൾക്കിടയിലുള്ള പേരിന്റെ ഓരോ ഭാഗവും വലിയക്ഷരമാക്കിയിരിക്കുന്നു), തുടർന്ന് സ്ക്വയർ ബ്രാക്കറ്റുകളിലെ റിസോഴ്‌സ് നാമം (പേരിന്റെ കേസ് മാറില്ല!). സ്‌പെയ്‌സുകളൊന്നും ഉണ്ടാകരുത്; ടൈപ്പ് പേരിന് തൊട്ടുപിന്നാലെ ചതുര ബ്രാക്കറ്റുകൾ എഴുതപ്പെടും.

ഉദാഹരണം:

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

ആശ്രിതത്വങ്ങളും അറിയിപ്പുകളും

ഡോക്യുമെന്റേഷൻ ഇവിടെ.

നേരത്തെ പറഞ്ഞതുപോലെ, വിഭവങ്ങൾ തമ്മിലുള്ള ലളിതമായ ആശ്രിതത്വം ട്രാൻസിറ്റീവ് ആണ്. വഴിയിൽ, ഡിപൻഡൻസികൾ ചേർക്കുമ്പോൾ ശ്രദ്ധിക്കുക - നിങ്ങൾക്ക് ചാക്രിക ഡിപൻഡൻസികൾ സൃഷ്ടിക്കാൻ കഴിയും, ഇത് ഒരു സമാഹാര പിശകിന് കാരണമാകും.

ഡിപൻഡൻസികളിൽ നിന്ന് വ്യത്യസ്തമായി, അറിയിപ്പുകൾ ട്രാൻസിറ്റീവ് അല്ല. അറിയിപ്പുകൾക്ക് ഇനിപ്പറയുന്ന നിയമങ്ങൾ ബാധകമാണ്:

• ഉറവിടത്തിന് ഒരു അറിയിപ്പ് ലഭിക്കുകയാണെങ്കിൽ, അത് അപ്ഡേറ്റ് ചെയ്യപ്പെടും. അപ്ഡേറ്റ് പ്രവർത്തനങ്ങൾ റിസോഴ്സ് തരത്തെ ആശ്രയിച്ചിരിക്കുന്നു - exec കമാൻഡ് പ്രവർത്തിപ്പിക്കുക, സേവനം സേവനം പുനരാരംഭിക്കുന്നു, പാക്കേജ് പാക്കേജ് വീണ്ടും ഇൻസ്റ്റാൾ ചെയ്യുന്നു. ഉറവിടത്തിന് ഒരു അപ്‌ഡേറ്റ് പ്രവർത്തനം നിർവചിച്ചിട്ടില്ലെങ്കിൽ, ഒന്നും സംഭവിക്കില്ല.
• പപ്പറ്റിന്റെ ഒരു ഓട്ടത്തിനിടയിൽ, റിസോഴ്‌സ് ഒന്നിലധികം തവണ അപ്‌ഡേറ്റ് ചെയ്യില്ല. അറിയിപ്പുകളിൽ ഡിപൻഡൻസികളും ഡിപൻഡൻസി ഗ്രാഫിൽ സൈക്കിളുകൾ അടങ്ങിയിട്ടില്ലാത്തതിനാലും ഇത് സാധ്യമാണ്.
• പപ്പറ്റ് ഒരു വിഭവത്തിന്റെ അവസ്ഥ മാറ്റുകയാണെങ്കിൽ, അത് സബ്‌സ്‌ക്രൈബുചെയ്‌ത എല്ലാ ഉറവിടങ്ങളിലേക്കും റിസോഴ്‌സ് അറിയിപ്പുകൾ അയയ്ക്കുന്നു.
• ഒരു ഉറവിടം അപ്‌ഡേറ്റ് ചെയ്‌താൽ, അത് സബ്‌സ്‌ക്രൈബുചെയ്‌ത എല്ലാ ഉറവിടങ്ങളിലേക്കും അത് അറിയിപ്പുകൾ അയയ്‌ക്കുന്നു.

വ്യക്തമാക്കാത്ത പാരാമീറ്ററുകൾ കൈകാര്യം ചെയ്യുന്നു

ചട്ടം പോലെ, ചില റിസോഴ്‌സ് പാരാമീറ്ററിന് സ്ഥിര മൂല്യം ഇല്ലെങ്കിൽ, ഈ പരാമീറ്റർ മാനിഫെസ്റ്റിൽ വ്യക്തമാക്കിയിട്ടില്ലെങ്കിൽ, നോഡിലെ അനുബന്ധ ഉറവിടത്തിനായി പപ്പറ്റ് ഈ പ്രോപ്പർട്ടി മാറ്റില്ല. ഉദാഹരണത്തിന്, തരത്തിലുള്ള ഒരു റിസോഴ്സ് ആണെങ്കിൽ ഫയല് പാരാമീറ്റർ വ്യക്തമാക്കിയിട്ടില്ല 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 ഉള്ള പാക്കേജിന്റെ പേരാണ് (ഡെബിയനിൽ, ഉദാഹരണത്തിന്, പാക്കേജുകളുണ്ട്. 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,
) {
  ...
}

ക്ലാസുകൾ: ക്ലാസ് നാമവും ക്ലാസ്{'ക്ലാസ്‌നെയിം':} ഉൾപ്പെടുന്നു

ഓരോ ക്ലാസും ഓരോ തരത്തിലുള്ള വിഭവമാണ് ക്ലാസ്. മറ്റേതൊരു തരത്തിലുള്ള റിസോഴ്സ് പോലെ, ഒരേ നോഡിൽ ഒരേ ക്ലാസിന്റെ രണ്ട് സന്ദർഭങ്ങൾ ഉണ്ടാകരുത്.

ഒരേ നോഡിലേക്ക് രണ്ട് തവണ ഉപയോഗിച്ച് ഒരു ക്ലാസ് ചേർക്കാൻ നിങ്ങൾ ശ്രമിക്കുകയാണെങ്കിൽ class { 'classname':} (വ്യത്യാസമില്ല, വ്യത്യസ്തമോ സമാനമോ ആയ പരാമീറ്ററുകളോടെ), ഒരു കംപൈലേഷൻ പിശക് ഉണ്ടാകും. എന്നാൽ നിങ്ങൾ റിസോഴ്സ് ശൈലിയിൽ ഒരു ക്ലാസ് ഉപയോഗിക്കുകയാണെങ്കിൽ, നിങ്ങൾക്ക് ഉടൻ തന്നെ അതിന്റെ എല്ലാ പാരാമീറ്ററുകളും മാനിഫെസ്റ്റിൽ വ്യക്തമായി സജ്ജമാക്കാൻ കഴിയും.

എന്നിരുന്നാലും, നിങ്ങൾ ഉപയോഗിക്കുകയാണെങ്കിൽ include, അപ്പോൾ ക്ലാസ് എത്ര തവണ വേണമെങ്കിലും ചേർക്കാം. എന്നതാണ് വസ്തുത include ഡയറക്‌ടറിയിലേക്ക് ഒരു ക്ലാസ് ചേർത്തിട്ടുണ്ടോ എന്ന് പരിശോധിക്കുന്ന ഒരു idempotent ഫംഗ്‌ഷൻ ആണ്. ക്ലാസ് ഡയറക്ടറിയിൽ ഇല്ലെങ്കിൽ, അത് ചേർക്കുന്നു, അത് ഇതിനകം നിലവിലുണ്ടെങ്കിൽ, അത് ഒന്നും ചെയ്യുന്നില്ല. എന്നാൽ ഉപയോഗിക്കുന്ന കാര്യത്തിൽ include ക്ലാസ് ഡിക്ലറേഷൻ സമയത്ത് നിങ്ങൾക്ക് ക്ലാസ് പാരാമീറ്ററുകൾ സജ്ജമാക്കാൻ കഴിയില്ല - ആവശ്യമായ എല്ലാ പാരാമീറ്ററുകളും ഒരു ബാഹ്യ ഡാറ്റ ഉറവിടത്തിൽ സജ്ജീകരിച്ചിരിക്കണം - Hiera അല്ലെങ്കിൽ ENC. അടുത്ത ലേഖനത്തിൽ നാം അവരെക്കുറിച്ച് സംസാരിക്കും.

നിർവചിക്കുന്നു

മുമ്പത്തെ ബ്ലോക്കിൽ പറഞ്ഞതുപോലെ, ഒരേ ക്ലാസ് ഒന്നിലധികം തവണ ഒരു നോഡിൽ ഉണ്ടാകാൻ കഴിയില്ല. എന്നിരുന്നാലും, ചില സന്ദർഭങ്ങളിൽ ഒരേ നോഡിൽ വ്യത്യസ്ത പാരാമീറ്ററുകളുള്ള ഒരേ ബ്ലോക്ക് കോഡ് ഉപയോഗിക്കാൻ നിങ്ങൾക്ക് കഴിയേണ്ടതുണ്ട്. മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, സ്വന്തമായി ഒരു റിസോഴ്സ് തരം ആവശ്യമാണ്.

ഉദാഹരണത്തിന്, PHP മൊഡ്യൂൾ ഇൻസ്റ്റാൾ ചെയ്യുന്നതിനായി, Avito-യിൽ ഞങ്ങൾ ഇനിപ്പറയുന്നവ ചെയ്യുന്നു:

1. ഈ മൊഡ്യൂൾ ഉപയോഗിച്ച് പാക്കേജ് ഇൻസ്റ്റാൾ ചെയ്യുക.
2. ഈ മൊഡ്യൂളിനായി നമുക്ക് ഒരു കോൺഫിഗറേഷൻ ഫയൽ ഉണ്ടാക്കാം.
3. php-fpm-നുള്ള കോൺഫിഗറിലേക്ക് ഞങ്ങൾ ഒരു സിംലിങ്ക് സൃഷ്ടിക്കുന്നു.
4. php cli-നുള്ള കോൺഫിഗറിലേക്ക് ഞങ്ങൾ ഒരു സിംലിങ്ക് സൃഷ്ടിക്കുന്നു.

അത്തരം സന്ദർഭങ്ങളിൽ, ഒരു ഡിസൈൻ നിർവ്വചിക്കുക (നിർവചിക്കുക, നിർവചിച്ച തരം, നിർവചിക്കപ്പെട്ട വിഭവ തരം). ഒരു നിർവ്വചനം ഒരു ക്ലാസിന് സമാനമാണ്, എന്നാൽ വ്യത്യാസങ്ങളുണ്ട്: ആദ്യം, ഓരോ നിർവ്വചിക്കലും ഒരു റിസോഴ്സ് തരമാണ്, ഒരു വിഭവമല്ല; രണ്ടാമതായി, ഓരോ നിർവചനത്തിനും ഒരു പരാമീറ്റർ ഉണ്ട് $title, റിസോഴ്സ് നാമം പ്രഖ്യാപിക്കുമ്പോൾ എവിടെ പോകുന്നു. ക്ലാസുകളുടെ കാര്യത്തിലെന്നപോലെ, ഒരു നിർവചനം ആദ്യം വിവരിക്കണം, അതിനുശേഷം അത് ഉപയോഗിക്കാം.

PHP-യ്‌ക്കായുള്ള ഒരു മൊഡ്യൂൾ ഉള്ള ഒരു ലളിതമായ ഉദാഹരണം:

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' }
}

ഡ്യൂപ്ലിക്കേറ്റ് ഡിക്ലറേഷൻ പിശക് പിടിക്കാനുള്ള എളുപ്പവഴി Define ആണ്. ഒരു നിർവചനത്തിന് സ്ഥിരമായ പേരുള്ള ഒരു റിസോഴ്‌സ് ഉണ്ടെങ്കിൽ, ചില നോഡിൽ ഈ നിർവചനത്തിന്റെ രണ്ടോ അതിലധികമോ സന്ദർഭങ്ങൾ ഉണ്ടെങ്കിൽ ഇത് സംഭവിക്കുന്നു.

ഇതിൽ നിന്ന് സ്വയം പരിരക്ഷിക്കുന്നത് എളുപ്പമാണ്: നിർവചനത്തിനുള്ളിലെ എല്ലാ ഉറവിടങ്ങളും അനുസരിച്ച് ഒരു പേര് ഉണ്ടായിരിക്കണം $title. ഒരു ബദലായി, ഉറവിടങ്ങൾ അസമമായി ചേർക്കുക; ഏറ്റവും ലളിതമായ സാഹചര്യത്തിൽ, നിർവചനത്തിന്റെ എല്ലാ സന്ദർഭങ്ങൾക്കും പൊതുവായുള്ള ഉറവിടങ്ങൾ ഒരു പ്രത്യേക ക്ലാസിലേക്ക് നീക്കുകയും ഈ ക്ലാസ് നിർവചനം - ഫംഗ്ഷനിൽ ഉൾപ്പെടുത്തുകയും ചെയ്താൽ മതിയാകും. include ബുദ്ധിശൂന്യൻ.

റിസോഴ്‌സുകൾ ചേർക്കുമ്പോൾ, ഫംഗ്‌ഷനുകൾ ഉപയോഗിച്ച് ഐഡമ്പറ്റൻസി നേടാൻ മറ്റ് വഴികളുണ്ട് defined и ensure_resources, എന്നാൽ ഞാൻ അതിനെ കുറിച്ച് അടുത്ത എപ്പിസോഡിൽ പറയാം.

ക്ലാസുകൾക്കും നിർവചനങ്ങൾക്കുമുള്ള ആശ്രിതത്വങ്ങളും അറിയിപ്പുകളും

ക്ലാസുകളും നിർവചനങ്ങളും ഡിപൻഡൻസികളും അറിയിപ്പുകളും കൈകാര്യം ചെയ്യുന്നതിന് ഇനിപ്പറയുന്ന നിയമങ്ങൾ ചേർക്കുന്നു:

• ഒരു ക്ലാസ്സിലെ ആശ്രിതത്വം/ നിർവചിക്കുന്നത് ക്ലാസ്സിന്റെ/ നിർവചിക്കുന്ന എല്ലാ വിഭവങ്ങളിലും ആശ്രിതത്വം ചേർക്കുന്നു;
• ഒരു ക്ലാസ്/നിർവ്വചിക്കുന്ന ആശ്രിതത്വം എല്ലാ ക്ലാസുകളിലേക്കും ഡിപൻഡൻസികൾ ചേർക്കുന്നു/വിഭവങ്ങളെ നിർവചിക്കുന്നു;
• ക്ലാസ്/നിർവചിക്കൽ അറിയിപ്പ് ക്ലാസിന്റെ എല്ലാ ഉറവിടങ്ങളും അറിയിക്കുന്നു/നിർവചിക്കുന്നു;
• class/define subscription ക്ലാസ്സിന്റെ എല്ലാ ഉറവിടങ്ങളിലേക്കും സബ്‌സ്‌ക്രൈബുചെയ്യുന്നു/നിർവചിക്കുന്നു.

സോപാധിക പ്രസ്താവനകളും സെലക്ടർമാരും

ഡോക്യുമെന്റേഷൻ ഇവിടെ.

if

ഇത് ഇവിടെ ലളിതമാണ്:

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

അല്ലാതെ

ഒരു if in reverse ആണെങ്കിൽ: എക്സ്പ്രഷൻ തെറ്റാണെങ്കിൽ കോഡിന്റെ ബ്ലോക്ക് എക്സിക്യൂട്ട് ചെയ്യും.

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

കേസ്

ഇവിടെയും സങ്കീർണ്ണമായ ഒന്നും തന്നെയില്ല. നിങ്ങൾക്ക് സാധാരണ മൂല്യങ്ങൾ (സ്ട്രിംഗുകൾ, നമ്പറുകൾ മുതലായവ), സാധാരണ എക്സ്പ്രഷനുകൾ, ഡാറ്റ തരങ്ങൾ എന്നിവ മൂല്യങ്ങളായി ഉപയോഗിക്കാം.

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

സെലക്ടർമാർ

ഒരു സെലക്ടർ എന്നത് സമാനമായ ഒരു ഭാഷാ നിർമ്മാണമാണ് case, എന്നാൽ ഒരു ബ്ലോക്ക് കോഡ് എക്സിക്യൂട്ട് ചെയ്യുന്നതിനുപകരം, അത് ഒരു മൂല്യം നൽകുന്നു.

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

മൊഡ്യൂളുകൾ

കോൺഫിഗറേഷൻ ചെറുതായിരിക്കുമ്പോൾ, അത് ഒരു മാനിഫെസ്റ്റിൽ എളുപ്പത്തിൽ സൂക്ഷിക്കാനാകും. എന്നാൽ ഞങ്ങൾ വിവരിക്കുന്ന കൂടുതൽ കോൺഫിഗറേഷനുകൾ, മാനിഫെസ്റ്റിൽ കൂടുതൽ ക്ലാസുകളും നോഡുകളും ഉണ്ട്, അത് വളരുന്നു, ഒപ്പം പ്രവർത്തിക്കാൻ ഇത് അസൗകര്യമാകും.

കൂടാതെ, കോഡ് പുനരുപയോഗത്തിന്റെ പ്രശ്നമുണ്ട് - എല്ലാ കോഡുകളും ഒരു മാനിഫെസ്റ്റിൽ ആയിരിക്കുമ്പോൾ, ഈ കോഡ് മറ്റുള്ളവരുമായി പങ്കിടുന്നത് ബുദ്ധിമുട്ടാണ്. ഈ രണ്ട് പ്രശ്‌നങ്ങൾ പരിഹരിക്കുന്നതിന്, പപ്പറ്റിന് മൊഡ്യൂളുകൾ എന്നൊരു സ്ഥാപനമുണ്ട്.

മൊഡ്യൂളുകൾ - ഇവ ഒരു പ്രത്യേക ഡയറക്ടറിയിൽ സ്ഥാപിച്ചിരിക്കുന്ന ക്ലാസുകളുടെയും നിർവചനങ്ങളുടെയും മറ്റ് പപ്പറ്റ് എന്റിറ്റികളുടെയും സെറ്റുകളാണ്. മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, ഒരു മൊഡ്യൂൾ പപ്പറ്റ് ലോജിക്കിന്റെ ഒരു സ്വതന്ത്ര ഭാഗമാണ്. ഉദാഹരണത്തിന്, nginx-മായി പ്രവർത്തിക്കുന്നതിന് ഒരു മൊഡ്യൂൾ ഉണ്ടായിരിക്കാം, അതിൽ nginx-നൊപ്പം പ്രവർത്തിക്കാൻ ആവശ്യമായതും മാത്രം അടങ്ങിയിരിക്കും, അല്ലെങ്കിൽ PHP-യിൽ പ്രവർത്തിക്കുന്നതിന് ഒരു മൊഡ്യൂൾ ഉണ്ടായിരിക്കാം, മുതലായവ.

മൊഡ്യൂളുകൾ പതിപ്പാണ്, കൂടാതെ മൊഡ്യൂളുകളുടെ പരസ്പര ആശ്രയത്വവും പിന്തുണയ്ക്കുന്നു. മൊഡ്യൂളുകളുടെ ഒരു തുറന്ന ശേഖരം ഉണ്ട് - പപ്പറ്റ് ഫോർജ്.

പപ്പറ്റ് സെർവറിൽ, റൂട്ട് ഡയറക്ടറിയുടെ മൊഡ്യൂളുകളുടെ ഉപഡയറക്‌ടറിയിലാണ് മൊഡ്യൂളുകൾ സ്ഥിതി ചെയ്യുന്നത്. ഓരോ മൊഡ്യൂളിനുള്ളിലും ഒരു സാധാരണ ഡയറക്ടറി സ്കീം ഉണ്ട് - മാനിഫെസ്റ്റുകൾ, ഫയലുകൾ, ടെംപ്ലേറ്റുകൾ, ലിബ് തുടങ്ങിയവ.

ഒരു മൊഡ്യൂളിലെ ഫയൽ ഘടന

മൊഡ്യൂളിന്റെ റൂട്ടിൽ വിവരണാത്മക പേരുകളുള്ള ഇനിപ്പറയുന്ന ഡയറക്‌ടറികൾ അടങ്ങിയിരിക്കാം:

• manifests - അതിൽ മാനിഫെസ്റ്റോകൾ അടങ്ങിയിരിക്കുന്നു
• files - അതിൽ ഫയലുകൾ അടങ്ങിയിരിക്കുന്നു
• templates - അതിൽ ടെംപ്ലേറ്റുകൾ അടങ്ങിയിരിക്കുന്നു
• lib - അതിൽ റൂബി കോഡ് അടങ്ങിയിരിക്കുന്നു

ഇത് ഡയറക്‌ടറികളുടെയും ഫയലുകളുടെയും പൂർണ്ണമായ പട്ടികയല്ല, എന്നാൽ ഈ ലേഖനത്തിന് ഇപ്പോൾ ഇത് മതിയാകും.

മൊഡ്യൂളിലെ വിഭവങ്ങളുടെ പേരുകളും ഫയലുകളുടെ പേരുകളും

ഡോക്യുമെന്റേഷൻ ഇവിടെ.

ഒരു മൊഡ്യൂളിലെ വിഭവങ്ങൾ (ക്ലാസ്സുകൾ, നിർവചനങ്ങൾ) നിങ്ങൾക്ക് ഇഷ്ടമുള്ളത് പേരിടാൻ കഴിയില്ല. കൂടാതെ, ഒരു റിസോഴ്സിന്റെ പേരും പപ്പറ്റ് ആ വിഭവത്തിന്റെ വിവരണത്തിനായി തിരയുന്ന ഫയലിന്റെ പേരും തമ്മിൽ നേരിട്ടുള്ള കത്തിടപാടുകൾ ഉണ്ട്. നിങ്ങൾ പേരിടൽ നിയമങ്ങൾ ലംഘിക്കുകയാണെങ്കിൽ, പപ്പറ്റ് റിസോഴ്സ് വിവരണം കണ്ടെത്തുകയില്ല, കൂടാതെ നിങ്ങൾക്ക് ഒരു സമാഹാര പിശക് ലഭിക്കും.

നിയമങ്ങൾ ലളിതമാണ്:

• ഒരു മൊഡ്യൂളിലെ എല്ലാ ഉറവിടങ്ങളും മൊഡ്യൂൾ നെയിംസ്പേസിൽ ആയിരിക്കണം. മൊഡ്യൂൾ വിളിച്ചാൽ 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 — ഇത് ടെംപ്ലേറ്റ് ടെക്സ്റ്റ് ഇൻപുട്ടായി സ്വീകരിക്കുന്നു, ഫയലിന്റെ പേരല്ല.

ടെംപ്ലേറ്റുകൾക്കുള്ളിൽ, നിലവിലെ സ്കോപ്പിലുള്ള എല്ലാ പപ്പറ്റ് വേരിയബിളുകളും നിങ്ങൾക്ക് ഉപയോഗിക്കാം.

ERB, EPP ഫോർമാറ്റിലുള്ള ടെംപ്ലേറ്റുകളെ പപ്പറ്റ് പിന്തുണയ്ക്കുന്നു:

• EPP ഡോക്യുമെന്റേഷൻ.
• 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 അല്ലെങ്കിൽ കീ=മൂല്യം ഫോർമാറ്റിൽ സ്റ്റാൻഡേർഡ് ഔട്ട്പുട്ടിലേക്ക് വിവരങ്ങൾ ഔട്ട്പുട്ട് ചെയ്യണം.

നിങ്ങളുടെ മൊഡ്യൂൾ വിന്യസിച്ചിരിക്കുന്ന പോപ്പറ്റ് സെർവർ നിയന്ത്രിക്കുന്ന എല്ലാ നോഡുകൾക്കും വസ്തുതകൾ ബാധകമാണെന്ന കാര്യം മറക്കരുത്. അതിനാൽ, സ്ക്രിപ്റ്റിൽ, നിങ്ങളുടെ വസ്തുത പ്രവർത്തിക്കുന്നതിന് ആവശ്യമായ എല്ലാ പ്രോഗ്രാമുകളും ഫയലുകളും സിസ്റ്റത്തിൽ ഉണ്ടെന്ന് പരിശോധിക്കാൻ ശ്രദ്ധിക്കുക.

#!/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 മുതൽ, പപ്പറ്റ്-ഏജന്റ് പാക്കേജുകൾ ഔദ്യോഗിക പപ്പറ്റ്ലാബ്സ് ശേഖരം എല്ലാ ഡിപൻഡൻസികളും (റൂബിയും അനുബന്ധ രത്നങ്ങളും) അടങ്ങിയിരിക്കുന്നു, അതിനാൽ ഇൻസ്റ്റാളേഷൻ ബുദ്ധിമുട്ടുകൾ ഇല്ല (ഞാൻ ഡെബിയൻ അധിഷ്‌ഠിത വിതരണങ്ങളെക്കുറിച്ചാണ് സംസാരിക്കുന്നത് - ഞങ്ങൾ 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.

സെർവർ

ഈ ലേഖനത്തിൽ പാപ്പറ്റ്സെർവറിന്റെ പൂർണ്ണമായ സജ്ജീകരണവും കോഡ് വിന്യസിക്കുന്നതും ഞാൻ പരിഗണിക്കില്ല; ഒരു ചെറിയ സംഖ്യയിൽ പ്രവർത്തിക്കാൻ അധിക കോൺഫിഗറേഷൻ ആവശ്യമില്ലാത്ത സെർവറിന്റെ പൂർണ്ണമായ പ്രവർത്തനക്ഷമമായ ഒരു പതിപ്പ് ബോക്സിന് പുറത്ത് ഉണ്ടെന്ന് മാത്രമേ ഞാൻ പറയൂ. നോഡുകൾ (പറയുക, നൂറ് വരെ). ധാരാളം നോഡുകൾക്ക് ട്യൂണിംഗ് ആവശ്യമാണ് - സ്ഥിരസ്ഥിതിയായി, പപ്പറ്റ്സെർവർ നാല് തൊഴിലാളികളിൽ കൂടുതൽ ലോഞ്ച് ചെയ്യില്ല, മികച്ച പ്രകടനത്തിന് നിങ്ങൾ അവരുടെ എണ്ണം വർദ്ധിപ്പിക്കേണ്ടതുണ്ട്, കൂടാതെ മെമ്മറി പരിധി വർദ്ധിപ്പിക്കാൻ മറക്കരുത്, അല്ലാത്തപക്ഷം സെർവർ മിക്ക സമയത്തും മാലിന്യങ്ങൾ ശേഖരിക്കും.

കോഡ് വിന്യാസം - നിങ്ങൾക്കത് വേഗത്തിലും എളുപ്പത്തിലും വേണമെങ്കിൽ, നോക്കൂ (r10k)[https://github.com/puppetlabs/r10k], ചെറിയ ഇൻസ്റ്റാളേഷനുകൾക്ക് ഇത് മതിയാകും.

അനുബന്ധം 2: കോഡിംഗ് മാർഗ്ഗനിർദ്ദേശങ്ങൾ

1. ക്ലാസുകളിലും നിർവചനങ്ങളിലും എല്ലാ യുക്തികളും സ്ഥാപിക്കുക.
2. ക്ലാസുകളും നിർവചനങ്ങളും മൊഡ്യൂളുകളിൽ സൂക്ഷിക്കുക, നോഡുകൾ വിവരിക്കുന്ന മാനിഫെസ്റ്റുകളിലല്ല.
3. വസ്തുതകൾ ഉപയോഗിക്കുക.
4. ഹോസ്റ്റ്നാമങ്ങൾ അടിസ്ഥാനമാക്കി ifs ഉണ്ടാക്കരുത്.
5. ക്ലാസുകൾക്കും നിർവചനങ്ങൾക്കുമായി പാരാമീറ്ററുകൾ ചേർക്കാൻ മടിക്കേണ്ടതില്ല - ഇത് ക്ലാസിന്റെ/നിർവചിക്കുന്ന ബോഡിയിൽ മറഞ്ഞിരിക്കുന്ന അവ്യക്തമായ യുക്തിയേക്കാൾ മികച്ചതാണ്.

എന്തുകൊണ്ടാണ് ഇത് ചെയ്യാൻ ഞാൻ ശുപാർശ ചെയ്യുന്നതെന്ന് അടുത്ത ലേഖനത്തിൽ ഞാൻ വിശദീകരിക്കും.

തീരുമാനം

ആമുഖത്തോടെ അവസാനിപ്പിക്കാം. അടുത്ത ലേഖനത്തിൽ Hiera, ENC, PuppetDB എന്നിവയെക്കുറിച്ച് ഞാൻ നിങ്ങളോട് പറയും.

രജിസ്റ്റർ ചെയ്ത ഉപയോക്താക്കൾക്ക് മാത്രമേ സർവേയിൽ പങ്കെടുക്കാൻ കഴിയൂ. സൈൻ ഇൻദയവായി.

വാസ്തവത്തിൽ, കൂടുതൽ മെറ്റീരിയലുകൾ ഉണ്ട് - ഇനിപ്പറയുന്ന വിഷയങ്ങളിൽ എനിക്ക് ലേഖനങ്ങൾ എഴുതാൻ കഴിയും, നിങ്ങൾക്ക് വായിക്കാൻ താൽപ്പര്യമുള്ള കാര്യങ്ങളിൽ വോട്ടുചെയ്യുക:

• 59,1%വിപുലമായ പപ്പറ്റ് നിർമ്മാണങ്ങൾ - ചില അടുത്ത ലെവൽ ഷിറ്റ്: ലൂപ്പുകൾ, മാപ്പിംഗ്, മറ്റ് ലാംഡ എക്‌സ്‌പ്രഷനുകൾ, റിസോഴ്‌സ് കളക്ടറുകൾ, എക്‌സ്‌പോർട്ട് ചെയ്ത റിസോഴ്‌സുകൾ, പപ്പറ്റ്, ടാഗുകൾ, ദാതാക്കൾ, അമൂർത്ത ഡാറ്റ തരങ്ങൾ എന്നിവ വഴിയുള്ള ഇന്റർ-ഹോസ്റ്റ് ആശയവിനിമയം.13
• 31,8%"ഞാൻ എന്റെ അമ്മയുടെ അഡ്മിൻ ആണ്" അല്ലെങ്കിൽ Avito യിൽ ഞങ്ങൾ എങ്ങനെ വ്യത്യസ്ത പതിപ്പുകളുടെ നിരവധി പോപ്പറ്റ് സെർവറുകളുമായി ചങ്ങാത്തം സ്ഥാപിച്ചു, കൂടാതെ, തത്വത്തിൽ, പോപ്പറ്റ് സെർവർ നിയന്ത്രിക്കുന്നതിനെക്കുറിച്ചുള്ള ഭാഗം.7
• 81,8%ഞങ്ങൾ പപ്പറ്റ് കോഡ് എങ്ങനെ എഴുതുന്നു: ഇൻസ്ട്രുമെന്റേഷൻ, ഡോക്യുമെന്റേഷൻ, ടെസ്റ്റിംഗ്, CI/CD.18

22 ഉപയോക്താക്കൾ വോട്ട് ചെയ്തു. 9 ഉപയോക്താക്കൾ വിട്ടുനിന്നു.

അവലംബം: www.habr.com