ಪಪಿಟ್ ಪರಿಚಯ

ಪಪಿಟ್ ಒಂದು ಸಂರಚನಾ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಯಾಗಿದೆ. ಹೋಸ್ಟ್‌ಗಳನ್ನು ಬಯಸಿದ ಸ್ಥಿತಿಗೆ ತರಲು ಮತ್ತು ಈ ಸ್ಥಿತಿಯನ್ನು ನಿರ್ವಹಿಸಲು ಇದನ್ನು ಬಳಸಲಾಗುತ್ತದೆ.

ನಾನು ಈಗ ಐದು ವರ್ಷಗಳಿಂದ ಪಪಿಟ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೇನೆ. ಈ ಪಠ್ಯವು ಮೂಲಭೂತವಾಗಿ ಅಧಿಕೃತ ದಾಖಲಾತಿಯಿಂದ ಪ್ರಮುಖ ಅಂಶಗಳ ಅನುವಾದ ಮತ್ತು ಮರುಕ್ರಮಗೊಳಿಸಿದ ಸಂಕಲನವಾಗಿದೆ, ಇದು ಆರಂಭಿಕರಿಗೆ ಪಪಿಟ್‌ನ ಸಾರವನ್ನು ತ್ವರಿತವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.

ಪಪಿಟ್ ಪರಿಚಯ

ಮೂಲ ಮಾಹಿತಿ

ಪಪಿಟ್‌ನ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಕ್ಲೈಂಟ್-ಸರ್ವರ್ ಆಗಿದೆ, ಆದರೂ ಇದು ಸೀಮಿತ ಕಾರ್ಯನಿರ್ವಹಣೆಯೊಂದಿಗೆ ಸರ್ವರ್‌ಲೆಸ್ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ.

ಕಾರ್ಯಾಚರಣೆಯ ಪುಲ್ ಮಾದರಿಯನ್ನು ಬಳಸಲಾಗುತ್ತದೆ: ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, ಪ್ರತಿ ಅರ್ಧ ಗಂಟೆಗೊಮ್ಮೆ, ಗ್ರಾಹಕರು ಕಾನ್ಫಿಗರೇಶನ್ಗಾಗಿ ಸರ್ವರ್ ಅನ್ನು ಸಂಪರ್ಕಿಸಿ ಮತ್ತು ಅದನ್ನು ಅನ್ವಯಿಸುತ್ತಾರೆ. ನೀವು ಅನ್ಸಿಬಲ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಿದ್ದರೆ, ಅವರು ವಿಭಿನ್ನ ಪುಶ್ ಮಾದರಿಯನ್ನು ಬಳಸುತ್ತಾರೆ: ನಿರ್ವಾಹಕರು ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಅನ್ವಯಿಸುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ, ಗ್ರಾಹಕರು ಸ್ವತಃ ಏನನ್ನೂ ಅನ್ವಯಿಸುವುದಿಲ್ಲ.

ನೆಟ್‌ವರ್ಕ್ ಸಂವಹನದ ಸಮಯದಲ್ಲಿ, ಎರಡು-ಮಾರ್ಗ TLS ಎನ್‌ಕ್ರಿಪ್ಶನ್ ಅನ್ನು ಬಳಸಲಾಗುತ್ತದೆ: ಸರ್ವರ್ ಮತ್ತು ಕ್ಲೈಂಟ್ ತಮ್ಮದೇ ಆದ ಖಾಸಗಿ ಕೀಗಳು ಮತ್ತು ಅನುಗುಣವಾದ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ಹೊಂದಿವೆ. ಸಾಮಾನ್ಯವಾಗಿ ಸರ್ವರ್ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ನೀಡುತ್ತದೆ, ಆದರೆ ತಾತ್ವಿಕವಾಗಿ ಬಾಹ್ಯ CA ಅನ್ನು ಬಳಸಲು ಸಾಧ್ಯವಿದೆ.

ಪ್ರಣಾಳಿಕೆಗಳ ಪರಿಚಯ

ಪಪಿಟ್ ಪರಿಭಾಷೆಯಲ್ಲಿ ಬೊಂಬೆ ಸರ್ವರ್‌ಗೆ ಸಂಪರ್ಕ ನೋಡ್ಗಳು (ನೋಡ್ಗಳು). ನೋಡ್‌ಗಳ ಸಂರಚನೆಯನ್ನು ಬರೆಯಲಾಗಿದೆ ಪ್ರಣಾಳಿಕೆಗಳಲ್ಲಿ ವಿಶೇಷ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಯಲ್ಲಿ - ಪಪಿಟ್ ಡಿಎಸ್ಎಲ್.

ಪಪಿಟ್ ಡಿಎಸ್ಎಲ್ ಒಂದು ಘೋಷಣಾ ಭಾಷೆಯಾಗಿದೆ. ಇದು ನೋಡ್‌ನ ಅಪೇಕ್ಷಿತ ಸ್ಥಿತಿಯನ್ನು ವೈಯಕ್ತಿಕ ಸಂಪನ್ಮೂಲಗಳ ಘೋಷಣೆಗಳ ರೂಪದಲ್ಲಿ ವಿವರಿಸುತ್ತದೆ, ಉದಾಹರಣೆಗೆ:

  • ಫೈಲ್ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ ಮತ್ತು ಇದು ನಿರ್ದಿಷ್ಟ ವಿಷಯವನ್ನು ಹೊಂದಿದೆ.
  • ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಸ್ಥಾಪಿಸಲಾಗಿದೆ.
  • ಸೇವೆ ಪ್ರಾರಂಭವಾಗಿದೆ.

ಸಂಪನ್ಮೂಲಗಳನ್ನು ಪರಸ್ಪರ ಸಂಪರ್ಕಿಸಬಹುದು:

  • ಅವಲಂಬನೆಗಳಿವೆ, ಅವು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಳಸುವ ಕ್ರಮದ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತವೆ.
    ಉದಾಹರಣೆಗೆ, "ಮೊದಲು ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಸ್ಥಾಪಿಸಿ, ನಂತರ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ ಅನ್ನು ಸಂಪಾದಿಸಿ, ನಂತರ ಸೇವೆಯನ್ನು ಪ್ರಾರಂಭಿಸಿ."
  • ಅಧಿಸೂಚನೆಗಳಿವೆ - ಸಂಪನ್ಮೂಲವು ಬದಲಾಗಿದ್ದರೆ, ಅದು ಚಂದಾದಾರರಾಗಿರುವ ಸಂಪನ್ಮೂಲಗಳಿಗೆ ಅಧಿಸೂಚನೆಗಳನ್ನು ಕಳುಹಿಸುತ್ತದೆ.
    ಉದಾಹರಣೆಗೆ, ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ ಬದಲಾದರೆ, ನೀವು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಸೇವೆಯನ್ನು ಮರುಪ್ರಾರಂಭಿಸಬಹುದು.

ಹೆಚ್ಚುವರಿಯಾಗಿ, ಪಪಿಟ್ ಡಿಎಸ್ಎಲ್ ಕಾರ್ಯಗಳು ಮತ್ತು ಅಸ್ಥಿರಗಳನ್ನು ಹೊಂದಿದೆ, ಜೊತೆಗೆ ಷರತ್ತುಬದ್ಧ ಹೇಳಿಕೆಗಳು ಮತ್ತು ಸೆಲೆಕ್ಟರ್‌ಗಳನ್ನು ಹೊಂದಿದೆ. ವಿವಿಧ ಟೆಂಪ್ಲೇಟಿಂಗ್ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಸಹ ಬೆಂಬಲಿಸಲಾಗುತ್ತದೆ - 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,
) {
  ...
}

ತರಗತಿಗಳು: ವರ್ಗದ ಹೆಸರು ಮತ್ತು ವರ್ಗ{'classname':} ಸೇರಿವೆ

ಪ್ರತಿಯೊಂದು ವರ್ಗವು ಒಂದು ರೀತಿಯ ಸಂಪನ್ಮೂಲವಾಗಿದೆ ವರ್ಗ. ಇತರ ಯಾವುದೇ ರೀತಿಯ ಸಂಪನ್ಮೂಲಗಳಂತೆ, ಒಂದೇ ನೋಡ್‌ನಲ್ಲಿ ಒಂದೇ ವರ್ಗದ ಎರಡು ನಿದರ್ಶನಗಳು ಇರುವಂತಿಲ್ಲ.

ನೀವು ಎರಡು ಬಾರಿ ಬಳಸಿ ಒಂದೇ ನೋಡ್‌ಗೆ ವರ್ಗವನ್ನು ಸೇರಿಸಲು ಪ್ರಯತ್ನಿಸಿದರೆ 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' }
}

ಡಿಫೈನ್‌ನಲ್ಲಿ ನಕಲಿ ಘೋಷಣೆ ದೋಷವನ್ನು ಹಿಡಿಯಲು ಸುಲಭವಾದ ಮಾರ್ಗವಾಗಿದೆ. ಒಂದು ವ್ಯಾಖ್ಯಾನವು ಸ್ಥಿರ ಹೆಸರಿನೊಂದಿಗೆ ಸಂಪನ್ಮೂಲವನ್ನು ಹೊಂದಿದ್ದರೆ ಇದು ಸಂಭವಿಸುತ್ತದೆ ಮತ್ತು ಕೆಲವು ನೋಡ್‌ನಲ್ಲಿ ಈ ವ್ಯಾಖ್ಯಾನದ ಎರಡು ಅಥವಾ ಹೆಚ್ಚಿನ ನಿದರ್ಶನಗಳಿವೆ.

ಇದರಿಂದ ನಿಮ್ಮನ್ನು ರಕ್ಷಿಸಿಕೊಳ್ಳುವುದು ಸುಲಭ: ವ್ಯಾಖ್ಯಾನದೊಳಗಿನ ಎಲ್ಲಾ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಅವಲಂಬಿಸಿ ಹೆಸರನ್ನು ಹೊಂದಿರಬೇಕು $title. ಪರ್ಯಾಯವೆಂದರೆ ಸಂಪನ್ಮೂಲಗಳ ಅಸಮರ್ಥ ಸೇರ್ಪಡೆ; ಸರಳವಾದ ಸಂದರ್ಭದಲ್ಲಿ, ವ್ಯಾಖ್ಯಾನದ ಎಲ್ಲಾ ನಿದರ್ಶನಗಳಿಗೆ ಸಾಮಾನ್ಯವಾದ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಪ್ರತ್ಯೇಕ ವರ್ಗಕ್ಕೆ ಸರಿಸಲು ಮತ್ತು ಈ ವರ್ಗವನ್ನು ವ್ಯಾಖ್ಯಾನ - ಕಾರ್ಯದಲ್ಲಿ ಸೇರಿಸಲು ಸಾಕು. include ಬುದ್ಧಿಹೀನ.

ಸಂಪನ್ಮೂಲಗಳನ್ನು ಸೇರಿಸುವಾಗ ಐಡೆಂಪೊಟೆನ್ಸಿಯನ್ನು ಸಾಧಿಸಲು ಇತರ ಮಾರ್ಗಗಳಿವೆ, ಅವುಗಳೆಂದರೆ ಕಾರ್ಯಗಳನ್ನು ಬಳಸುವುದು defined и ensure_resources, ಆದರೆ ಮುಂದಿನ ಸಂಚಿಕೆಯಲ್ಲಿ ನಾನು ಅದರ ಬಗ್ಗೆ ಹೇಳುತ್ತೇನೆ.

ವರ್ಗಗಳು ಮತ್ತು ವ್ಯಾಖ್ಯಾನಗಳಿಗಾಗಿ ಅವಲಂಬನೆಗಳು ಮತ್ತು ಅಧಿಸೂಚನೆಗಳು

ವರ್ಗಗಳು ಮತ್ತು ವ್ಯಾಖ್ಯಾನಗಳು ಅವಲಂಬನೆಗಳು ಮತ್ತು ಅಧಿಸೂಚನೆಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಕೆಳಗಿನ ನಿಯಮಗಳನ್ನು ಸೇರಿಸುತ್ತವೆ:

  • ವರ್ಗ/ವ್ಯಾಖ್ಯಾನದ ಮೇಲಿನ ಅವಲಂಬನೆಯು ವರ್ಗ/ವ್ಯಾಖ್ಯಾನದ ಎಲ್ಲಾ ಸಂಪನ್ಮೂಲಗಳ ಮೇಲೆ ಅವಲಂಬನೆಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ;
  • ಒಂದು ವರ್ಗ/ವ್ಯಾಖ್ಯಾನ ಅವಲಂಬನೆಯು ಎಲ್ಲಾ ವರ್ಗಗಳಿಗೆ ಅವಲಂಬನೆಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ/ಸಂಪನ್ಮೂಲಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ;
  • ವರ್ಗ/ವ್ಯಾಖ್ಯಾನ ಅಧಿಸೂಚನೆಯು ವರ್ಗದ ಎಲ್ಲಾ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಸೂಚಿಸುತ್ತದೆ/ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ;
  • ವರ್ಗ/ವ್ಯಾಖ್ಯಾನ ಚಂದಾದಾರಿಕೆ ವರ್ಗದ ಎಲ್ಲಾ ಸಂಪನ್ಮೂಲಗಳಿಗೆ ಚಂದಾದಾರಿಕೆ/ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ.

ಷರತ್ತುಬದ್ಧ ಹೇಳಿಕೆಗಳು ಮತ್ತು ಆಯ್ಕೆದಾರರು

ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ಇಲ್ಲಿ.

if

ಇದು ಇಲ್ಲಿ ಸರಳವಾಗಿದೆ:

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

ಹೊರತು

ಒಂದು ವೇಳೆ ರಿವರ್ಸ್‌ನಲ್ಲದಿದ್ದರೆ: ಅಭಿವ್ಯಕ್ತಿ ತಪ್ಪಾಗಿದ್ದರೆ ಕೋಡ್‌ನ ಬ್ಲಾಕ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ.

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 ಬಗ್ಗೆ ಸಂಕ್ಷಿಪ್ತವಾಗಿ

ನಿಯಂತ್ರಣ ರಚನೆಗಳು:

  • <%= ВЫРАЖЕНИЕ %> - ಅಭಿವ್ಯಕ್ತಿಯ ಮೌಲ್ಯವನ್ನು ಸೇರಿಸಿ
  • <% ВЫРАЖЕНИЕ %> - ಅಭಿವ್ಯಕ್ತಿಯ ಮೌಲ್ಯವನ್ನು ಲೆಕ್ಕಹಾಕಿ (ಅದನ್ನು ಸೇರಿಸದೆಯೇ). ಷರತ್ತುಬದ್ಧ ಹೇಳಿಕೆಗಳು (ಒಂದು ವೇಳೆ) ಮತ್ತು ಲೂಪ್‌ಗಳು (ಪ್ರತಿಯೊಂದೂ) ಸಾಮಾನ್ಯವಾಗಿ ಇಲ್ಲಿಗೆ ಹೋಗುತ್ತವೆ.
  • <%# КОММЕНТАРИЙ %>

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 ಅಥವಾ ಕೀ=ಮೌಲ್ಯ ಸ್ವರೂಪದಲ್ಲಿ ಪ್ರಮಾಣಿತ ಔಟ್‌ಪುಟ್‌ಗೆ ಮಾಹಿತಿಯನ್ನು ಔಟ್‌ಪುಟ್ ಮಾಡಬೇಕು.

ನಿಮ್ಮ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ನಿಯೋಜಿಸಲಾಗಿರುವ ಪಾಪೆಟ್ ಸರ್ವರ್‌ನಿಂದ ನಿಯಂತ್ರಿಸಲ್ಪಡುವ ಎಲ್ಲಾ ನೋಡ್‌ಗಳಿಗೆ ಸತ್ಯಗಳು ಅನ್ವಯಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ಮರೆಯಬೇಡಿ. ಆದ್ದರಿಂದ, ಸ್ಕ್ರಿಪ್ಟ್‌ನಲ್ಲಿ, ನಿಮ್ಮ ವಾಸ್ತವವಾಗಿ ಕೆಲಸ ಮಾಡಲು ಅಗತ್ಯವಿರುವ ಎಲ್ಲಾ ಪ್ರೋಗ್ರಾಂಗಳು ಮತ್ತು ಫೈಲ್‌ಗಳನ್ನು ಸಿಸ್ಟಮ್ ಹೊಂದಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಲು ಕಾಳಜಿ ವಹಿಸಿ.

#!/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 ವಿಳಾಸ, ಪರಿಸರದ ಬಗ್ಗೆ ಮಾಹಿತಿಗೆ ಸಂಬಂಧಿಸಿದ ಅಸ್ಥಿರ.
  • ಏಜೆಂಟ್ ಸಂಗತಿಗಳು — ವೇರಿಯೇಬಲ್‌ಗಳನ್ನು ನೇರವಾಗಿ ಬೊಂಬೆ-ಏಜೆಂಟ್‌ನಿಂದ ಸೇರಿಸಲಾಗಿದೆ, ಮತ್ತು ಅಂಶದಿಂದ ಅಲ್ಲ - ಪ್ರಮಾಣಪತ್ರದ ಹೆಸರು, ಏಜೆಂಟ್ ಆವೃತ್ತಿ, ಬೊಂಬೆ ಆವೃತ್ತಿ.
  • ಮಾಸ್ಟರ್ ಅಸ್ಥಿರ - Pappetmaster ವೇರಿಯೇಬಲ್ಸ್ (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. ತರಗತಿಗಳು ಮತ್ತು ವ್ಯಾಖ್ಯಾನಗಳಿಗೆ ನಿಯತಾಂಕಗಳನ್ನು ಸೇರಿಸಲು ಹಿಂಜರಿಯಬೇಡಿ - ಇದು ವರ್ಗ/ವ್ಯಾಖ್ಯಾನದ ದೇಹದಲ್ಲಿ ಅಡಗಿರುವ ಸೂಚ್ಯ ತರ್ಕಕ್ಕಿಂತ ಉತ್ತಮವಾಗಿದೆ.

ಮುಂದಿನ ಲೇಖನದಲ್ಲಿ ಇದನ್ನು ಮಾಡಲು ನಾನು ಏಕೆ ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ ಎಂದು ನಾನು ವಿವರಿಸುತ್ತೇನೆ.

ತೀರ್ಮಾನಕ್ಕೆ

ಪರಿಚಯದೊಂದಿಗೆ ಮುಗಿಸೋಣ. ಮುಂದಿನ ಲೇಖನದಲ್ಲಿ ನಾನು ಹೈರಾ, ಇಎನ್‌ಸಿ ಮತ್ತು ಪಪಿಟ್‌ಡಿಬಿ ಬಗ್ಗೆ ಹೇಳುತ್ತೇನೆ.

ನೋಂದಾಯಿತ ಬಳಕೆದಾರರು ಮಾತ್ರ ಸಮೀಕ್ಷೆಯಲ್ಲಿ ಭಾಗವಹಿಸಬಹುದು. ಸೈನ್ ಇನ್ ಮಾಡಿ, ದಯವಿಟ್ಟು.

ವಾಸ್ತವವಾಗಿ, ಹೆಚ್ಚಿನ ವಿಷಯಗಳಿವೆ - ನಾನು ಈ ಕೆಳಗಿನ ವಿಷಯಗಳ ಕುರಿತು ಲೇಖನಗಳನ್ನು ಬರೆಯಬಹುದು, ನೀವು ಓದಲು ಆಸಕ್ತಿ ಹೊಂದಿರುವ ಬಗ್ಗೆ ಮತ ಚಲಾಯಿಸಿ:

  • 59,1%ಸುಧಾರಿತ ಬೊಂಬೆ ರಚನೆಗಳು - ಕೆಲವು ಮುಂದಿನ ಹಂತದ ಶಿಟ್: ಲೂಪ್‌ಗಳು, ಮ್ಯಾಪಿಂಗ್ ಮತ್ತು ಇತರ ಲ್ಯಾಂಬ್ಡಾ ಅಭಿವ್ಯಕ್ತಿಗಳು, ಸಂಪನ್ಮೂಲ ಸಂಗ್ರಾಹಕರು, ರಫ್ತು ಮಾಡಲಾದ ಸಂಪನ್ಮೂಲಗಳು ಮತ್ತು ಪಪಿಟ್, ಟ್ಯಾಗ್‌ಗಳು, ಪೂರೈಕೆದಾರರು, ಅಮೂರ್ತ ಡೇಟಾ ಪ್ರಕಾರಗಳ ಮೂಲಕ ಅಂತರ-ಹೋಸ್ಟ್ ಸಂವಹನ.13
  • 31,8%"ನಾನು ನನ್ನ ತಾಯಿಯ ನಿರ್ವಾಹಕ" ಅಥವಾ ನಾವು Avito ನಲ್ಲಿ ವಿವಿಧ ಆವೃತ್ತಿಗಳ ಹಲವಾರು ಪಾಪೆಟ್ ಸರ್ವರ್‌ಗಳೊಂದಿಗೆ ಹೇಗೆ ಸ್ನೇಹಿತರಾಗಿದ್ದೇವೆ ಮತ್ತು ತಾತ್ವಿಕವಾಗಿ, ಪಾಪೆಟ್ ಸರ್ವರ್ ಅನ್ನು ನಿರ್ವಹಿಸುವ ಭಾಗ.7
  • 81,8%ನಾವು ಪಪಿಟ್ ಕೋಡ್ ಅನ್ನು ಹೇಗೆ ಬರೆಯುತ್ತೇವೆ: ಉಪಕರಣ, ದಾಖಲಾತಿ, ಪರೀಕ್ಷೆ, CI/CD.18

22 ಬಳಕೆದಾರರು ಮತ ಹಾಕಿದ್ದಾರೆ. 9 ಬಳಕೆದಾರರು ದೂರ ಉಳಿದಿದ್ದಾರೆ.

ಮೂಲ: www.habr.com