कठपुतली एक कन्फिगरेसन व्यवस्थापन प्रणाली हो। यो इच्छित राज्यमा होस्टहरू ल्याउन र यो राज्य कायम राख्न प्रयोग गरिन्छ।

म पपेटसँग पाँच वर्षभन्दा बढी समयदेखि काम गरिरहेको छु। यो पाठ अनिवार्य रूपमा आधिकारिक कागजातबाट मुख्य बुँदाहरूको अनुवादित र पुन: क्रमबद्ध संकलन हो, जसले शुरुआतीहरूलाई पपेटको सारलाई द्रुत रूपमा बुझ्न अनुमति दिनेछ।

आधारभूत जानकारी

पपेटको अपरेटिङ सिस्टम क्लाइन्ट-सर्भर हो, यद्यपि यसले सीमित कार्यक्षमताको साथ सर्भरलेस सञ्चालनलाई पनि समर्थन गर्दछ।

सञ्चालनको पुल मोडेल प्रयोग गरिन्छ: पूर्वनिर्धारित रूपमा, प्रत्येक आधा घण्टामा, ग्राहकहरूले कन्फिगरेसनको लागि सर्भरलाई सम्पर्क गर्छन् र यसलाई लागू गर्छन्। यदि तपाईंले Ansible सँग काम गर्नुभएको छ भने, तिनीहरूले फरक पुश मोडेल प्रयोग गर्छन्: प्रशासकले कन्फिगरेसन लागू गर्ने प्रक्रिया सुरु गर्दछ, ग्राहकहरूले आफैंले केहि पनि लागू गर्दैनन्।

सञ्जाल सञ्चारको समयमा, दुई-तर्फी TLS इन्क्रिप्सन प्रयोग गरिन्छ: सर्भर र ग्राहकको आफ्नै निजी कुञ्जीहरू र सम्बन्धित प्रमाणपत्रहरू छन्। सामान्यतया सर्भरले ग्राहकहरूको लागि प्रमाणपत्रहरू जारी गर्दछ, तर सिद्धान्तमा बाह्य CA प्रयोग गर्न सम्भव छ।

घोषणापत्रको परिचय

कठपुतली शब्दावलीमा कठपुतली सर्भरमा जोड्नुहोस् नोडहरू (नोड्स)। नोडहरूको लागि कन्फिगरेसन लेखिएको छ घोषणापत्रमा विशेष प्रोग्रामिङ भाषामा - कठपुतली DSL।

कठपुतली DSL एक घोषणात्मक भाषा हो। यसले व्यक्तिगत स्रोतहरूको घोषणाको रूपमा नोडको इच्छित अवस्था वर्णन गर्दछ, उदाहरणका लागि:

• फाइल अवस्थित छ र यसमा विशिष्ट सामग्री छ।
• प्याकेज स्थापना गरिएको छ।
• सेवा सुरु भएको छ ।

स्रोतहरू आपसमा जोड्न सकिन्छ:

• त्यहाँ निर्भरताहरू छन्, तिनीहरूले स्रोतहरू प्रयोग गर्ने क्रममा प्रभाव पार्छन्।
  उदाहरणका लागि, "पहिले प्याकेज स्थापना गर्नुहोस्, त्यसपछि कन्फिगरेसन फाइल सम्पादन गर्नुहोस्, त्यसपछि सेवा सुरु गर्नुहोस्।"
• त्यहाँ अधिसूचनाहरू छन् - यदि एक स्रोत परिवर्तन भएको छ भने, यसले यसको सदस्यता लिएका स्रोतहरूमा सूचनाहरू पठाउँछ।
  उदाहरणका लागि, यदि कन्फिगरेसन फाइल परिवर्तन भयो भने, तपाइँ स्वचालित रूपमा सेवा पुन: सुरु गर्न सक्नुहुन्छ।

थप रूपमा, कठपुतली DSL सँग कार्यहरू र चरहरू, साथै सशर्त कथनहरू र चयनकर्ताहरू छन्। विभिन्न टेम्प्लेटिंग संयन्त्रहरू पनि समर्थित छन् - EPP र ERB।

पपेट रुबीमा लेखिएको छ, त्यसैले धेरै निर्माण र सर्तहरू त्यहाँबाट लिइएको छ। रुबीले तपाईंलाई पपेट विस्तार गर्न अनुमति दिन्छ - जटिल तर्क, नयाँ प्रकारका स्रोतहरू, कार्यहरू थप्नुहोस्।

पपेट चलिरहेको बेला, सर्भरमा प्रत्येक विशिष्ट नोडका लागि प्रकटहरू डाइरेक्टरीमा कम्पाइल हुन्छन्। निर्देशिका कार्यहरू, चरहरू र सशर्त कथनहरूको विस्तारको मूल्य गणना गरेपछि स्रोतहरू र तिनीहरूको सम्बन्धहरूको सूची हो।

सिन्ट्याक्स र कोडस्टाइल

यहाँ आधिकारिक कागजातका खण्डहरू छन् जसले तपाईंलाई सिन्ट्याक्स बुझ्न मद्दत गर्दछ यदि प्रदान गरिएका उदाहरणहरू पर्याप्त छैनन् भने:

• विभिन्न भाषा निर्माण को वाक्य रचना।
• स्रोत वाक्यविन्यास।
• नोडहरू वर्णन गर्नका लागि सिन्ट्याक्स।

म्यानिफेस्ट कस्तो देखिन्छ भन्ने उदाहरण यहाँ छ:

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

इन्डेन्टेसन र लाइन ब्रेकहरू manifest को आवश्यक भाग होइन, तर त्यहाँ सिफारिस गरिएको छ शैली गाइड। सारांश:

• दुई-स्पेस इन्डेन्टहरू, ट्याबहरू प्रयोग गरिएका छैनन्।
• घुमाउरो कोष्ठकहरू स्पेसद्वारा विभाजित हुन्छन्; कोलोनहरू स्पेसद्वारा विभाजित हुँदैनन्।
• अन्तिम सहित प्रत्येक प्यारामिटर पछि अल्पविराम। प्रत्येक प्यारामिटर एक अलग लाइन मा छ। मापदण्ड र एक प्यारामिटर बिना केसको लागि अपवाद बनाइएको छ: तपाइँ एक लाइनमा र अल्पविराम बिना लेख्न सक्नुहुन्छ (जस्तै। resource { 'title': } и resource { 'title': param => value }).
• प्यारामिटरहरूमा तीरहरू समान स्तरमा हुनुपर्छ।
• संसाधन सम्बन्ध तीरहरू तिनीहरूको अगाडि लेखिएका छन्।

प्यापेटसर्भरमा फाइलहरूको स्थान

थप व्याख्याको लागि, म "रूट डाइरेक्टरी" को अवधारणा प्रस्तुत गर्नेछु। रूट डाइरेक्टरी एउटा निर्दिष्ट नोडको लागि पपेट कन्फिगरेसन समावेश गर्ने निर्देशिका हो।

मूल डाइरेक्टरी पपेटको संस्करण र प्रयोग गरिएको वातावरणमा निर्भर गर्दछ। वातावरणहरू कन्फिगरेसनको स्वतन्त्र सेटहरू हुन् जुन छुट्टै डाइरेक्टरीहरूमा भण्डारण गरिन्छ। सामान्यतया 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 - symlink
• सामग्री - फाइल सामग्रीहरू (नियमित फाइलहरूको लागि मात्र उपयुक्त, सँगसँगै प्रयोग गर्न सकिँदैन स्रोत वा लक्ष्य)
• स्रोत — बाटोको लिङ्क जहाँबाट तपाईँले फाइलका सामग्रीहरू प्रतिलिपि गर्न चाहनुहुन्छ (सँगै प्रयोग गर्न सकिँदैन सामग्री वा लक्ष्य)। योजनाको साथ URI को रूपमा निर्दिष्ट गर्न सकिन्छ puppet: (त्यसपछि कठपुतली सर्भरबाट फाइलहरू प्रयोग गरिनेछ), र योजनाको साथ http: (मलाई आशा छ यो स्पष्ट छ कि यस अवस्थामा के हुनेछ), र रेखाचित्र संग पनि file: वा स्कीमा बिना निरपेक्ष मार्गको रूपमा (त्यसपछि नोडमा स्थानीय FS बाट फाइल प्रयोग गरिनेछ)
• लक्ष्य — जहाँ सिमलिङ्कले पोइन्ट गर्नुपर्छ (सँगै प्रयोग गर्न सकिँदैन सामग्री वा स्रोत)
• मालिक - प्रयोगकर्ता जसले फाइलको स्वामित्व लिनुपर्छ
• समूह - फाइल सम्बन्धित हुनु पर्ने समूह
• मोड - फाइल अनुमतिहरू (स्ट्रिङको रूपमा)
• पुनरावृत्ति - पुनरावर्ती डाइरेक्टरी प्रशोधन सक्षम गर्दछ
• शुद्ध - Puppet मा वर्णन नगरिएका फाइलहरू मेटाउन सक्षम गर्दछ
• शक्ति - पपेटमा वर्णन नगरिएका डाइरेक्टरीहरू मेटाउन सक्षम गर्दछ

प्याकेज

प्याकेजहरू स्थापना र हटाउँछ। सूचनाहरू ह्यान्डल गर्न सक्षम - यदि प्यारामिटर निर्दिष्ट गरिएको छ भने प्याकेज पुन: स्थापना गर्दछ 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 - autorun सक्षम छ (systemctl enable)
  • mask - भेषमा (systemctl mask)
  • false - autorun असक्षम छ (systemctl disable)
• फेरि शुरु गर्नु - सेवा पुन: सुरु गर्न आदेश
• स्थिति - सेवा स्थिति जाँच गर्न आदेश
• पुन: सुरु गर्नुहोस् - सेवा इनिटस्क्रिप्टले पुन: सुरु गर्न समर्थन गर्दछ कि भनेर संकेत गर्नुहोस्। यदि false र प्यारामिटर निर्दिष्ट गरिएको छ फेरि शुरु गर्नु - यो प्यारामिटर को मान प्रयोग गरिन्छ। यदि false र प्यारामिटर फेरि शुरु गर्नु निर्दिष्ट गरिएको छैन - सेवा रोकिएको छ र पुन: सुरु गर्न सुरु गरिएको छ (तर systemd ले आदेश प्रयोग गर्दछ systemctl restart).
• स्थिति — सेवा इनिटस्क्रिप्टले आदेशलाई समर्थन गर्छ कि गर्दैन भन्ने संकेत गर्नुहोस् status। यदि false, त्यसपछि प्यारामिटर मान प्रयोग गरिन्छ स्थिति। पूर्वनिर्धारित true.

exec

बाह्य आदेशहरू चलाउँछ। यदि तपाइँ प्यारामिटरहरू निर्दिष्ट गर्नुहुन्न भने सिर्जना, मात्र यदि, नभएसम्म वा ताजा रूपमा, कमाण्ड प्रत्येक पटक पपेट चलाउँदा चलाइनेछ। सूचनाहरू प्रशोधन गर्न सक्षम - आदेश चलाउँछ।

Параметры:

• स्रोत नाम - कार्यान्वयन गर्न आदेश (वैकल्पिक)
• आदेश - कार्यान्वयन गर्न आदेश (यदि यो नाम मा निर्दिष्ट छैन)
• बाटो - निष्पादन योग्य फाइल खोज्ने मार्गहरू
• मात्र यदि - यदि यो प्यारामिटरमा निर्दिष्ट आदेश शून्य रिटर्न कोडको साथ पूरा भयो भने, मुख्य आदेश कार्यान्वयन गरिनेछ।
• नभएसम्म - यदि यो प्यारामिटरमा निर्दिष्ट आदेश गैर-शून्य रिटर्न कोडको साथ पूरा भयो भने, मुख्य आदेश कार्यान्वयन गरिनेछ।
• सिर्जना यदि यो प्यारामिटरमा निर्दिष्ट गरिएको फाइल अवस्थित छैन भने, मुख्य आदेश कार्यान्वयन गरिनेछ
• ताजा रूपमा - यदि true, तब आदेश मात्र चलाइनेछ जब यो exec ले अन्य स्रोतहरूबाट सूचना प्राप्त गर्दछ
• cwd - आदेश चलाउन को लागी डाइरेक्टरी
• प्रयोगकर्ता - प्रयोगकर्ता जसबाट आदेश चलाउने
• प्रदायक - आदेश कसरी चलाउने:
  • positix - एक बाल प्रक्रिया सरल रूपमा सिर्जना गरिएको छ, निर्दिष्ट गर्न निश्चित हुनुहोस् बाटो
  • खोल - कमाण्ड शेल मा सुरु भएको छ /bin/sh, निर्दिष्ट नहुन सक्छ बाटो, तपाईं globbing, पाइप र अन्य खोल सुविधाहरू प्रयोग गर्न सक्नुहुन्छ। यदि कुनै विशेष वर्णहरू छन् भने सामान्यतया स्वचालित रूपमा पत्ता लगाइन्छ (|, ;, &&, || आदि)।

cron

क्रोनजबहरू नियन्त्रण गर्दछ।

Параметры:

• स्रोत नाम - केवल केहि प्रकारको पहिचानकर्ता
• पक्का गर्नु - क्राउनजब राज्य:
  • present - यदि अवस्थित छैन भने सिर्जना गर्नुहोस्
  • absent - यदि अवस्थित छ भने मेटाउनुहोस्
• आदेश - कुन आदेश चलाउन
• वातावरण - कुन वातावरणमा आदेश चलाउने (वातावरण चरहरूको सूची र तिनीहरूका मानहरू मार्फत =)
• प्रयोगकर्ता - कुन प्रयोगकर्ताबाट आदेश चलाउन
• मिनेट, घण्टा, हप्ताका, महिना, महिना दिन - क्रोन कहिले चलाउने। यदि यी मध्ये कुनै पनि विशेषताहरू निर्दिष्ट गरिएको छैन भने, क्रोनट्याबमा यसको मान हुनेछ *.

पपेट 6.0 मा cron मानौं बक्सबाट हटाइयो puppetserver मा, त्यसैले त्यहाँ सामान्य साइट मा कुनै कागजात छैन। तर ऊ बक्समा छ कठपुतली-एजेन्टमा, त्यसैले यसलाई छुट्टै स्थापना गर्न आवश्यक छैन। तपाईं यसको लागि कागजात हेर्न सक्नुहुन्छ पपेटको पाँचौं संस्करणको लागि दस्तावेजमा, वा GitHub मा.

सामान्य रूपमा स्रोतहरूको बारेमा

स्रोतको विशिष्टताका लागि आवश्यकताहरू

हामीले सामना गर्ने सबैभन्दा सामान्य गल्ती हो डुप्लिकेट घोषणा। निर्देशिकामा एउटै नामको एउटै प्रकारका दुई वा बढी स्रोतहरू देखा पर्दा यो त्रुटि हुन्छ।

त्यसैले, म फेरि लेख्छु: एउटै नोडका लागि manifests मा समान शीर्षकको साथ समान प्रकारका स्रोतहरू समावेश हुनु हुँदैन!

कहिलेकाहीँ एउटै नामका प्याकेजहरू स्थापना गर्न आवश्यक छ, तर फरक प्याकेज प्रबन्धकहरूसँग। यस अवस्थामा, तपाइँ प्यारामिटर प्रयोग गर्न आवश्यक छ 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 आदेश चलाउँछ, सेवा सेवा पुन: सुरु गर्छ, प्याकेज प्याकेज पुन: स्थापना गर्दछ। यदि स्रोतसँग अद्यावधिक कार्य परिभाषित छैन भने, त्यसपछि केही हुँदैन।
• कठपुतलीको एक दौडको समयमा, संसाधन एक पटक भन्दा बढि अपडेट हुँदैन। यो सम्भव छ किनभने सूचनाहरूले निर्भरताहरू समावेश गर्दछ र निर्भरता ग्राफमा चक्रहरू समावेश गर्दैन।
• यदि कठपुतलीले स्रोतको अवस्था परिवर्तन गर्छ भने, स्रोतले यसमा सदस्यता लिएका सबै स्रोतहरूमा सूचनाहरू पठाउँछ।
• यदि कुनै स्रोत अद्यावधिक गरिएको छ भने, यसले सदस्यता लिएका सबै स्रोतहरूमा सूचनाहरू पठाउँछ।

अनिर्दिष्ट प्यारामिटरहरू ह्यान्डल गर्दै

नियमको रूपमा, यदि केही स्रोत प्यारामिटरमा पूर्वनिर्धारित मान छैन र यो प्यारामिटर manifest मा निर्दिष्ट गरिएको छैन भने, पपेटले नोडमा सम्बन्धित स्रोतको लागि यो गुण परिवर्तन गर्दैन। उदाहरण को लागी, यदि प्रकार को एक स्रोत फाइल प्यारामिटर निर्दिष्ट गरिएको छैन owner, त्यसपछि Puppet ले सम्बन्धित फाइलको मालिक परिवर्तन गर्दैन।

कक्षाहरू, चरहरू र परिभाषाहरूको परिचय

मानौं कि हामीसँग कन्फिगरेसनको एउटै भाग भएका धेरै नोडहरू छन्, तर त्यहाँ भिन्नताहरू पनि छन् - अन्यथा हामी सबैलाई एउटै ब्लकमा वर्णन गर्न सक्छौं। node {}। अवश्य पनि, तपाइँ केवल कन्फिगरेसनको समान भागहरू प्रतिलिपि गर्न सक्नुहुन्छ, तर सामान्यतया यो एक खराब समाधान हो - कन्फिगरेसन बढ्छ, र यदि तपाइँ कन्फिगरेसनको सामान्य भाग परिवर्तन गर्नुहुन्छ भने, तपाइँले धेरै ठाउँहरूमा एउटै कुरा सम्पादन गर्नुपर्नेछ। एकै समयमा, गल्ती गर्न सजिलो छ, र सामान्यतया, DRY (आफैलाई दोहोर्याउनुहोस्) सिद्धान्त एक कारणको लागि आविष्कार गरिएको थियो।

यो समस्या समाधान गर्न को लागी यस्तो डिजाइन छ वर्ग.

कक्षा

Класс पपेट कोडको नाम गरिएको ब्लक हो। कोड पुन: प्रयोग गर्न कक्षाहरू आवश्यक छन्।

पहिले कक्षाको वर्णन गर्न आवश्यक छ। वर्णन आफैले कहिँ पनि कुनै स्रोतहरू थप्दैन। वर्ग manifests मा वर्णन गरिएको छ:

# Описание класса начинается с ключевого слова 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}"

कठपुतली छ नेमस्पेसहरू, र चर, तदनुसार, छ दृश्यता क्षेत्र: एउटै नामको चर विभिन्न नेमस्पेसहरूमा परिभाषित गर्न सकिन्छ। चरको मान समाधान गर्दा, चर हालको नेमस्पेसमा खोजिन्छ, त्यसपछि संलग्न नामस्थानमा, र यस्तै।

नेमस्पेस उदाहरणहरू:

• विश्वव्यापी - कक्षा वा नोड विवरण बाहिर चरहरू त्यहाँ जान्छन्;
• नोड विवरणमा नोड नेमस्पेस;
• कक्षाको विवरणमा class namespace।

चर पहुँच गर्दा अस्पष्टताबाट बच्नको लागि, तपाईंले चर नाममा नेमस्पेस निर्दिष्ट गर्न सक्नुहुन्छ:

# переменная без пространства имён
$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',   # задаём параметры класса точно так же, как параметры для других ресурсов
  }
}

Puppet मा, चरहरू टाइप गरिन्छ। खानुहोस् धेरै डाटा प्रकार। डेटा प्रकारहरू सामान्यतया वर्ग र परिभाषाहरूमा पास गरिएका प्यारामिटर मानहरू मान्य गर्न प्रयोग गरिन्छ। यदि पास गरिएको प्यारामिटर निर्दिष्ट प्रकारसँग मेल खाँदैन भने, एक संकलन त्रुटि देखा पर्नेछ।

प्रकार प्यारामिटर नाम अघि तुरुन्तै लेखिएको छ:

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

कक्षाहरू: क्लासनाम बनाम कक्षा{'classname':} समावेश गर्नुहोस्

प्रत्येक वर्ग प्रकारको स्रोत हो वर्ग। कुनै पनि अन्य प्रकारको स्रोतको रूपमा, एउटै नोडमा एउटै कक्षाको दुईवटा उदाहरणहरू हुन सक्दैन।

यदि तपाइँ एउटै नोडमा दुई पटक प्रयोग गरेर कक्षा थप्न प्रयास गर्नुहुन्छ class { 'classname':} (कुनै फरक छैन, फरक वा समान प्यारामिटरहरूसँग), त्यहाँ एक संकलन त्रुटि हुनेछ। तर यदि तपाइँ स्रोत शैलीमा एक वर्ग प्रयोग गर्नुहुन्छ भने, तपाइँ तुरुन्तै स्पष्ट रूपमा यसको सबै प्यारामिटरहरू manifest मा सेट गर्न सक्नुहुन्छ।

यद्यपि, यदि तपाइँ प्रयोग गर्नुहुन्छ 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 {
  ...
}

नभएसम्म

जबसम्म एक if उल्टो छ: यदि अभिव्यक्ति गलत छ भने कोडको ब्लक कार्यान्वयन हुनेछ।

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

मामला

यहाँ पनि केहि जटिल छैन। तपाईले नियमित मानहरू (स्ट्रिङहरू, संख्याहरू, आदि), नियमित अभिव्यक्तिहरू, र डेटा प्रकारहरूलाई मानहरूको रूपमा प्रयोग गर्न सक्नुहुन्छ।

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

चयनकर्ताहरू

चयनकर्ता एक समान भाषा निर्माण हो case, तर कोडको ब्लक कार्यान्वयन गर्नुको सट्टा, यसले मान फर्काउँछ।

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

मोड्युलहरू

जब कन्फिगरेसन सानो हुन्छ, यसलाई सजिलैसँग एक प्रकटीकरणमा राख्न सकिन्छ। तर हामीले जति धेरै कन्फिगरेसनहरू वर्णन गर्छौं, म्यानिफेस्टमा त्यहाँ धेरै वर्गहरू र नोडहरू छन्, यो बढ्छ, र यो काम गर्न असुविधाजनक हुन्छ।

थप रूपमा, त्यहाँ कोड पुन: प्रयोगको समस्या छ - जब सबै कोडहरू एउटै म्यानिफेस्टमा हुन्छन्, यो कोड अरूसँग साझेदारी गर्न गाह्रो हुन्छ। यी दुई समस्याहरू समाधान गर्न, कठपुतलीसँग मोड्युल भनिने एक संस्था छ।

मोड्युलहरू - यी छुट्टै डाइरेक्टरीमा राखिएका कक्षाहरू, परिभाषाहरू र अन्य कठपुतली निकायहरूको सेटहरू हुन्। अर्को शब्दमा, एक मोड्युल कठपुतली तर्क को एक स्वतन्त्र टुक्रा हो। उदाहरण को लागी, nginx संग काम गर्न को लागी एक मोड्युल हुन सक्छ, र यसमा nginx संग काम गर्न को लागी के र मात्र आवश्यक छ, वा PHP संग काम को लागी एक मोड्युल हुन सक्छ, र यस्तै।

मोड्युलहरू संस्करण गरिएका छन्, र एकअर्कामा मोड्युलहरूको निर्भरताहरू पनि समर्थित छन्। त्यहाँ मोड्युलहरूको खुला भण्डार छ - कठपुतली फोर्ज.

कठपुतली सर्भरमा, मोड्युलहरू रूट डाइरेक्टरीको मोड्युल उपनिर्देशिकामा अवस्थित छन्। प्रत्येक मोड्युल भित्र एक मानक निर्देशिका योजना छ - manifests, फाइलहरू, टेम्प्लेटहरू, lib, र यति।

मोड्युलमा फाइल संरचना

मोड्युलको रूटले वर्णनात्मक नामहरू सहित निम्न डाइरेक्टरीहरू समावेश गर्न सक्छ:

• 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.

टेम्प्लेट

निश्चित रूपमा तपाई आफैलाई थाहा छ कि टेम्प्लेटहरू के हुन्; म तिनीहरूलाई यहाँ विस्तारमा वर्णन गर्ने छैन। तर म यसलाई मात्र अवस्थामा छोड्छु Wikipedia को लिङ्क.

टेम्प्लेटहरू कसरी प्रयोग गर्ने: टेम्प्लेटको अर्थ प्रकार्य प्रयोग गरेर विस्तार गर्न सकिन्छ template, जुन टेम्प्लेटको बाटो पास गरिएको छ। प्रकार को स्रोत को लागी फाइल प्यारामिटर संग सँगै प्रयोग content। उदाहरण को लागी, यो जस्तै:

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

बाटो हेर्नुहोस् <modulename>/<filename> फाइल बुझाउँछ <rootdir>/modules/<modulename>/templates/<filename>.

यसको अतिरिक्त, त्यहाँ एक प्रकार्य छ inline_template - यसले टेम्प्लेट पाठ इनपुटको रूपमा प्राप्त गर्दछ, फाइल नाम होइन।

टेम्प्लेटहरू भित्र, तपाइँ हालको दायरामा सबै पपेट चरहरू प्रयोग गर्न सक्नुहुन्छ।

पपेटले ERB र EPP ढाँचामा टेम्प्लेटहरूलाई समर्थन गर्दछ:

• EPP कागजात।
• ERB कागजात।

ERB को बारेमा छोटकरीमा

नियन्त्रण संरचना:

• <%= ВЫРАЖЕНИЕ %> - अभिव्यक्तिको मान घुसाउनुहोस्
• <% ВЫРАЖЕНИЕ %> - अभिव्यक्तिको मान गणना गर्नुहोस् (यसलाई सम्मिलित नगरी)। सशर्त कथनहरू (यदि) र लूपहरू (प्रत्येक) सामान्यतया यहाँ जान्छन्।
• <%# КОММЕНТАРИЙ %>

ERB मा अभिव्यक्तिहरू रुबीमा लेखिएका छन् (ERB वास्तवमा एम्बेडेड रुबी हो)।

manifest बाट चर पहुँच गर्न, तपाईंले थप्न आवश्यक छ @ चर नाममा। नियन्त्रण निर्माण पछि देखा पर्ने लाइन ब्रेक हटाउनको लागि, तपाईंले बन्द गर्ने ट्याग प्रयोग गर्न आवश्यक छ -%>.

टेम्प्लेट प्रयोग गर्ने उदाहरण

मानौं म 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 -%>

तथ्य र बिल्ट-इन चरहरू

प्राय: कन्फिगरेसनको विशिष्ट भाग नोडमा हाल के भइरहेको छ भन्नेमा निर्भर गर्दछ। उदाहरण को लागी, डेबियन रिलीज के हो मा निर्भर गर्दछ, तपाइँ प्याकेज को एक वा अर्को संस्करण स्थापना गर्न आवश्यक छ। तपाईंले यो सबै म्यानुअल रूपमा निगरानी गर्न सक्नुहुन्छ, यदि नोडहरू परिवर्तन भएमा पुन: लेखन प्रकट हुन्छ। तर यो गम्भीर दृष्टिकोण होइन; स्वचालन धेरै राम्रो छ।

नोडहरूको बारेमा जानकारी प्राप्त गर्न, कठपुतलीसँग तथ्य भनिने मेकानिजम हुन्छ। तथ्यहरु - यो नोडको बारेमा जानकारी हो, ग्लोबल नेमस्पेसमा सामान्य चरहरूको रूपमा प्रकटहरूमा उपलब्ध छ। उदाहरणका लागि, होस्ट नाम, अपरेटिङ सिस्टम संस्करण, प्रोसेसर आर्किटेक्चर, प्रयोगकर्ताहरूको सूची, नेटवर्क इन्टरफेस र तिनीहरूको ठेगानाहरूको सूची, र धेरै, धेरै। तथ्यहरू manifests र टेम्प्लेटहरूमा नियमित चरको रूपमा उपलब्ध छन्।

तथ्यहरु संग काम को एक उदाहरण:

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

औपचारिक रूपमा भन्नुपर्दा, तथ्यमा नाम (स्ट्रिङ) र मान हुन्छ (विभिन्न प्रकारहरू उपलब्ध छन्: स्ट्रिङहरू, एरेहरू, शब्दकोशहरू)। खानुहोस् निर्मित तथ्यहरूको सेट। तपाईं पनि आफ्नो लेख्न सक्नुहुन्छ। तथ्य सङ्कलनकर्ताहरू वर्णन गरिएका छन् रुबी मा कार्यहरू जस्तैवा कसरी कार्यान्वयनयोग्य फाइलहरू। तथ्यहरू फारममा पनि प्रस्तुत गर्न सकिन्छ डाटा संग पाठ फाइलहरू नोडहरूमा।

अपरेशनको क्रममा, कठपुतली एजेन्टले पहिले प्यापेटसर्भरबाट नोडमा सबै उपलब्ध तथ्य सङ्कलनहरू प्रतिलिपि गर्दछ, त्यसपछि यसले तिनीहरूलाई सुरू गर्छ र सङ्कलन गरिएका तथ्यहरूलाई सर्भरमा पठाउँछ; यस पछि, सर्भरले क्याटलग संकलन गर्न थाल्छ।

निष्पादन योग्य फाइलहरूको रूपमा तथ्यहरू

त्यस्ता तथ्यहरू डाइरेक्टरीमा मोड्युलहरूमा राखिएका छन् facts.d। अवश्य पनि, फाइलहरू कार्यान्वयन योग्य हुनुपर्छ। चलाउँदा, तिनीहरूले YAML वा key=value ढाँचामा मानक आउटपुटमा जानकारी आउटपुट गर्नुपर्छ।

नबिर्सनुहोस् कि तथ्यहरू सबै नोडहरूमा लागू हुन्छन् जुन पपेट सर्भरद्वारा नियन्त्रित हुन्छ जसमा तपाइँको मोड्युल तैनात गरिएको छ। त्यसकारण, स्क्रिप्टमा, तपाइँको तथ्यलाई काम गर्नको लागि प्रणालीमा आवश्यक सबै प्रोग्रामहरू र फाइलहरू छन् भनेर जाँच गर्न ख्याल राख्नुहोस्।

#!/bin/sh
echo "testfact=success"

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

रुबी तथ्यहरू

त्यस्ता तथ्यहरू डाइरेक्टरीमा मोड्युलहरूमा राखिएका छन् lib/facter.

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

पाठ तथ्यहरू

त्यस्ता तथ्यहरू डाइरेक्टरीमा नोडहरूमा राखिएका छन् /etc/facter/facts.d पुरानो कठपुतली मा वा /etc/puppetlabs/facts.d नयाँ कठपुतली मा।

examplefact=examplevalue

---
examplefact2: examplevalue2
anotherfact: anothervalue

तथ्यमा पुग्न

त्यहाँ तथ्यहरू पुग्न दुई तरिकाहरू छन्:

• शब्दकोश मार्फत $facts: $facts['fqdn'];
• चर नामको रूपमा तथ्य नाम प्रयोग गर्दै: $fqdn.

यो एक शब्दकोश प्रयोग गर्न सबै भन्दा राम्रो छ $facts, वा अझ राम्रो, विश्वव्यापी नेमस्पेस संकेत गर्नुहोस् ($::facts).

यहाँ कागजात को सान्दर्भिक खण्ड छ।

बिल्ट-इन चरहरू

तथ्यहरू बाहेक, त्यहाँ पनि छ केही चरहरू, विश्वव्यापी नेमस्पेसमा उपलब्ध छ।

• विश्वसनीय तथ्यहरू — चरहरू जुन ग्राहकको प्रमाणपत्रबाट लिइन्छ (प्रमाणपत्र सामान्यतया पपेट सर्भरमा जारी गरिएको हुनाले, एजेन्टले यसको प्रमाणपत्र लिन र परिवर्तन गर्न सक्दैन, त्यसैले चरहरू "विश्वसनीय" हुन्छन्): प्रमाणपत्रको नाम, नाम होस्ट र डोमेन, प्रमाणपत्रबाट विस्तारहरू।
• सर्भर तथ्यहरू सर्भरको बारेमा जानकारीसँग सम्बन्धित चरहरू - संस्करण, नाम, सर्भर आईपी ठेगाना, वातावरण।
• एजेन्ट तथ्य — चरहरू सीधा कठपुतली-एजेन्टद्वारा थपिएका, र कारकद्वारा होइन — प्रमाणपत्र नाम, एजेन्ट संस्करण, कठपुतली संस्करण।
• मास्टर चर - Pappetmaster चर (sic!)। यो मा जस्तै छ सर्भर तथ्यहरू, प्लस कन्फिगरेसन प्यारामिटर मानहरू उपलब्ध छन्।
• कम्पाइलर चर — कम्पाइलर चरहरू जुन प्रत्येक दायरामा भिन्न हुन्छन्: हालको मोड्युलको नाम र हालको वस्तु पहुँच गरिएको मोड्युलको नाम। तिनीहरू प्रयोग गर्न सकिन्छ, उदाहरणका लागि, तपाईंको निजी कक्षाहरू अन्य मोड्युलहरूबाट सीधै प्रयोग भइरहेको छैन भनेर जाँच गर्न।

थप १: यो सबै कसरी चलाउने र डिबग गर्ने?

लेखमा कठपुतली कोडका धेरै उदाहरणहरू समावेश छन्, तर यो कोड कसरी चलाउने भनेर हामीलाई बताइएन। खैर, म आफैलाई सच्याइरहेको छु।

पपेट चलाउनको लागि एजेन्ट पर्याप्त छ, तर धेरै जसो केसहरूको लागि तपाईलाई सर्भर पनि चाहिन्छ।

एजेन्ट

कम्तिमा संस्करण XNUMX देखि, कठपुतली-एजेन्ट प्याकेजहरूबाट आधिकारिक Puppetlabs भण्डार सबै निर्भरताहरू समावेश गर्दछ (रुबी र सम्बन्धित रत्नहरू), त्यसैले त्यहाँ कुनै स्थापना कठिनाइहरू छैनन् (म डेबियन-आधारित वितरणको बारेमा कुरा गर्दैछु - हामी RPM-आधारित वितरणहरू प्रयोग गर्दैनौं)।

सरल अवस्थामा, कठपुतली कन्फिगरेसन प्रयोग गर्न, सर्भरलेस मोडमा एजेन्ट सुरू गर्न पर्याप्त छ: प्रदान गरिएको छ कि कठपुतली कोड नोडमा प्रतिलिपि गरिएको छ, सुरुवात गर्नुहोस्। puppet apply <путь к манифесту>:

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

निस्सन्देह, सर्भर सेटअप गर्न र डेमन मोडमा नोडहरूमा एजेन्टहरू चलाउनु राम्रो छ - त्यसपछि प्रत्येक आधा घण्टामा तिनीहरूले सर्भरबाट डाउनलोड गरिएको कन्फिगरेसन लागू गर्नेछन्।

तपाईं कामको पुश मोडेलको नक्कल गर्न सक्नुहुन्छ - नोडमा जानुहोस् जुन तपाईंलाई रुचि छ र सुरु गर्नुहोस् sudo puppet agent -t। कुञ्जी -t (--test) वास्तवमा धेरै विकल्पहरू समावेश गर्दछ जुन व्यक्तिगत रूपमा सक्षम गर्न सकिन्छ। यी विकल्पहरू निम्न समावेश छन्:

• डेमन मोडमा नचल्नुहोस् (पूर्वनिर्धारित रूपमा एजेन्ट डेमन मोडमा सुरु हुन्छ);
• क्याटलग लागू गरेपछि बन्द गर्नुहोस् (पूर्वनिर्धारित रूपमा, एजेन्टले काम गर्न जारी राख्नेछ र प्रत्येक आधा घण्टामा एक पटक कन्फिगरेसन लागू गर्नेछ);
• विस्तृत कार्य लग लेख्नुहोस्;
• फाइलहरूमा परिवर्तनहरू देखाउनुहोस्।

एजेन्टसँग कुनै परिवर्तन बिना अपरेटिङ मोड छ - तपाईंले सही कन्फिगरेसन लेख्नुभएको छ भन्ने निश्चित नभएको र सञ्चालनको क्रममा एजेन्टले के परिवर्तन गर्छ भनी जाँच्न चाहनुहुन्छ भने तपाईंले यसलाई प्रयोग गर्न सक्नुहुन्छ। यो मोड प्यारामिटर द्वारा सक्षम छ --noop आदेश रेखा मा: sudo puppet agent -t --noop.

थप रूपमा, तपाईंले कामको डिबगिङ लग सक्षम गर्न सक्नुहुन्छ - यसमा, कठपुतलीले यसले गर्ने सबै कार्यहरूको बारेमा लेख्छ: यो हाल प्रशोधन गरिरहेको स्रोतको बारेमा, यो स्रोतको प्यारामिटरहरू बारे, यसले कुन कार्यक्रमहरू सुरु गर्छ भन्ने बारे। निस्सन्देह यो एक प्यारामिटर हो --debug.

सर्भर

म यस लेखमा प्यापेटसर्भरको पूर्ण सेटअप र यसमा कोड डिप्लोइ गर्ने कुरालाई विचार गर्दिन; म मात्र भन्छु कि बाकसको बाहिर सर्भरको पूर्ण कार्यात्मक संस्करण छ जसलाई थोरै संख्यामा काम गर्न थप कन्फिगरेसन आवश्यक पर्दैन। नोड्स (भन्नुहोस्, एक सय सम्म)। नोडहरूको ठूलो संख्यालाई ट्युनिङ आवश्यक पर्दछ - पूर्वनिर्धारित रूपमा, कठपुतली सर्भरले चार भन्दा बढी कामदारहरू सुरू गर्दैन, अधिक प्रदर्शनको लागि तपाईंले तिनीहरूको संख्या बढाउन आवश्यक छ र मेमोरी सीमा बढाउन नबिर्सनुहोस्, अन्यथा सर्भरले अधिकांश समय फोहोर जम्मा गर्नेछ।

कोड डिप्लोइमेन्ट - यदि तपाईंलाई छिटो र सजिलै चाहिन्छ भने, त्यसपछि हेर्नुहोस् (r10k मा)[https://github.com/puppetlabs/r10k], साना स्थापनाहरूको लागि यो पर्याप्त हुनुपर्छ।

परिशिष्ट २: कोडिङ दिशानिर्देशहरू

1. कक्षा र परिभाषाहरूमा सबै तर्कहरू राख्नुहोस्।
2. कक्षाहरू र परिभाषाहरू मोड्युलहरूमा राख्नुहोस्, नोडहरू वर्णन गर्ने manifests मा होइन।
3. तथ्यहरू प्रयोग गर्नुहोस्।
4. होस्टनामहरूमा आधारित ifs नबनाउनुहोस्।
5. वर्ग र परिभाषाहरूको लागि प्यारामिटरहरू थप्न स्वतन्त्र महसुस गर्नुहोस् - यो वर्ग/परिभाषितको मुख्य भागमा लुकेको निहित तर्क भन्दा राम्रो छ।

म अर्को लेखमा किन यो गर्न सिफारिस गर्छु भनेर वर्णन गर्नेछु।

निष्कर्षमा

परिचयको साथ समाप्त गरौं। अर्को लेखमा म तपाईंलाई Hiera, ENC र PuppetDB बारे बताउनेछु।

दर्ता भएका प्रयोगकर्ताहरूले मात्र सर्वेक्षणमा भाग लिन सक्छन्। साइन इन गर्नुहोस्कृपया

वास्तवमा, त्यहाँ धेरै सामग्रीहरू छन् - म निम्न शीर्षकहरूमा लेखहरू लेख्न सक्छु, तपाईलाई के पढ्न रुचि छ भनेर मतदान गर्नुहोस्:

• 59,1%उन्नत कठपुतली निर्माणहरू - केही अर्को-स्तरको बकवास: लूपहरू, म्यापिङ र अन्य ल्याम्ब्डा अभिव्यक्तिहरू, स्रोत सङ्कलनहरू, निर्यात गरिएका स्रोतहरू र पपेट, ट्यागहरू, प्रदायकहरू, अमूर्त डेटा प्रकारहरू मार्फत अन्तर-होस्ट संचार।13
• 31,8%"म मेरी आमाको प्रशासक हुँ" वा कसरी हामीले Avito मा विभिन्न संस्करणका धेरै पपेट सर्भरहरूसँग साथी बनायौं, र सिद्धान्तमा, पपेट सर्भरको व्यवस्थापन गर्ने भाग।7
• 81,8%हामी कसरी कठपुतली कोड लेख्छौं: उपकरण, कागजात, परीक्षण, CI/CD.18

22 प्रयोगकर्ताहरूले मतदान गरे। 9 प्रयोगकर्ताहरू रोकिए।

स्रोत: www.habr.com