Puppet document: module Basics

ArticleDirectory

• Module structure
• Writing module
• Best practices

Original article address:Module fundamentals

 

Puppet Module

The module is puppet self-containedCodeAnd data set. Most of the lists can be placed in the module. The only exception is that the main list site. PP contains site-level and node-level code.

Each puppet user must be able to write their own modules:

• After reading this document, you will be able to learn how to write and use your own puppet module.
• Use the "installation module" to learn how to install the module from puppet forge.
• Use the "Publish module" to learn how to publish your module to puppet forge.
• Use ins to learn how to organize plug-ins in a module (such as custom behaviors and custom resource types) and how to synchronize them to proxy nodes.

 

Modules

Puppet can automatically load classes and functions defined in the module. In the list or external node classifier (ENC), classes or functions can be defined by name:

#/Etc/puppetlabs/puppet/ Site. ppnode default {include Apache class { '  NTP  '  : Enable => False  ;} Apache: vhost {  '  Personal_site  '  : Port => 80  , Docroot => '  /Var/www/personal  ' , Options => '  Indexes Multiviews  '  ,}} 

 

Similarly, puppet can automatically load plug-ins defined in modules (such as custom behaviors and custom resource types ). Refer to "use plug-ins" for more details.

 

To write a module that can be used in puppet, you must put it in a directory configured in moudlepath.

The modulepath configuration is a series of directories connected by system path delimiters. In most cases:

• /Etc/puppetlabs/puppet/modules:/opt/puppet/share/puppet/modules(For puppet Enterprise Edition)
• /Etc/puppet/modules:/usr/share/puppet/modules(For the puppet open-source version)

UsePuppet config print modulepathCommand to view the current modulepath configuration.

When puppet. conf is used for configuration, if both the puppet server and the proxy need to be able to access the module, the modulepath configuration must appear in the [main] section. Modulepath can also set different configurations based on different environments.

 

UsePuppet ModuleCommand to install modules compiled by other users. Refer to the "installation module" for more details.

 

Module structure

On a disk, a module corresponds to a special directory structure:

• Module_name
  • Manifests
  • Files
  • Templates
  • Lib
  • Tests
  • Spec

 

For example, for a module named "my_module", its directory structure should be:

• My_module-top-level directory, corresponding to the module name.
  • Manifests/-list of all modules.
    • Init. Pp-class definition. The class name in this file must correspond to the module name.
    • Other_class.pp-class definition. The class name in this file must be my_module: other_class.
    • My_defined_type.pp-function definition. The function name in this file must be my_module: my_defined_type.
    • Implementation/-list subdirectory.
      • Foo. Pp-class definition. The class name in this file must be my_module: Implementation: Foo.
      • Bar. Pp-class definition. The category in this file must be my_module: Implementation: bar.
  • Files/-static file directory, which can be downloaded by proxy nodes.
    • Service. conf-the URL of this file is puppet: // modules/my_module/service. conf.
  • LIB/-plug-in directory, such as custom behaviors and custom resource types. Refer to "use plug-ins" for more details.
  • Template File directory used in the templates/-list. Refer to "template" for more details.
    • Component. ERP-you can use the template ('My _ module/component. ERP ') in the list.
  • Tests/-describes how to use some instances of classes and functions.
    • Init. PP
    • Other_class.pp-each class and function in the List Directory can have corresponding instances in the instance directory.
  • Spec/-describes how to use some plug-in instances.

 

Each listing file in the manifests directory can only define one class or function. The file name must correspond to the class or function name defined in the file.

Init. PP is a special configuration file that contains the same class name as the module name. The classes or functions contained in other configuration files must meet the following rules:

Module name	::	Other directories: (if any)	File Name (excluding suffix)
My_module	::		Other_class
My_module	::	Implementation ::	Foo

 

 

 

• My_module: other_class must be inMy_module/manifests/other_class.pp file.
• My_module: Implementation: Foo must be inMy_module/manifests/implementation/Foo. PP definition.

The double colon (:) In the middle of the class name is called the namespace separator).

 

The module name can only contain lowercase letters, numbers, and underscores, and must begin with a lowercase letter, that is, must meet the regular expression [A-Z] [a-z0-9 _] *. The class name must be the same and cannot contain the namespace separator. Some special names are not allowed, for example:

• Main
• Settings

 

All static files in the module can be accessed through the source attribute of the file resource type. Each static file can be mapped to a URL:

Protocol	Three slash characters	"Modules "/	Module name/	File Name
Puppet:	///	Modules/	My_module/	Service. conf

For example,Puppet: // The file corresponding to modules/my_module/service. conf isMy_module/files/service. conf.

 

Each ERB template file (see "template" for more information) can be output through the template function. The output content is a simple string, usually used as the content attribute of the file resource type, or saved to a variable.

The template function locates the template file as follows:

Template Function	('	Module name/	Template Name	')
Template	('	My_module/	Component. ERB	')

For example,The file corresponding to template ('My _ module/component. erb') isMy_module/templates/component. ERB.

 

Writing module

As described above, we should be able to write simple classes and functions.

• Classes: get more information about the class.
• Defined resource types: get more information about functions.

 

Best practices

Classes, functions, and plug-ins in a module can be associated with each other.

The list in one module should never reference files or modules in other modules.

if one class in a module uses another class in another module, this situation should be avoided as much as possible, which will make publishing of the module very difficult. To solve this problem, create a public module that contains many "super classes.