Puppet Overview for MariaDB Users
Puppet is a tool to automate servers configuration management. It is produced by Puppet Inc, and released under the terms of the Apache License, version 2.
It is entirely possible to use Ansible to automate MariaDB deployments and configuration. This page contains generic information for MariaDB users who want to learn, or evaluate, Puppet.
Contents
Design Principles
With Puppet, you write manifests that describe the resources you need to run on certain servers and their attributes.
Therefore manifests are declarative. You don't write the steps to achieve the desired result. Instead, you describe the desired result. When Puppet detects differences between your description and the current state of a servers, it decides what to do to fix those differences.
Manifests are also idempotent. You don't need to worry about the effects of applying a manifest twice. This may happen (see Architecture below) but it won't have any side effects.
Here's an example of how to describe a resource in a manifest:
file { '/etc/motd': content => '', ensure => present, }
This block describes a resource. The resource type is file
, while the resource itself is /etc/motd
. The description consists of a set of attributes. The most important is ensure
, which in this case states that the file must exist. It is also common to use this resource to indicate that a file (probably created by a previous version of the manifest) doesn't exist.
These classes of resource types exist:
- Built-in resources, or Puppet core resources: Resources that are part of Puppet, maintained by the Puppet team.
- Defined resources: Resources that are defined as a combination of other resources. They are written in the Puppet domain-specific language.
- Custom resources: Resources that are written by users, in Ruby language.
To obtain information about resources:
# list existing resource types puppet resource --types # print information about the file resource type puppet describe file
To group several resources in a reusable class:
class ssh_server { file { '/etc/motd': content => '', ensure => present, } file { '/etc/issue.net': content => '', ensure => present, } }
There are several ways to include a class. For example:
include Class['ssh_server']
Concepts
The most important Puppet concepts are the following:
- Target: A host whose configuration is managed via Puppet.
- Group: A logical group of targets. For example there may be a
mariadb
group, and several targets may be part of this group. - Facts: Information collected from the targets, like the system name or system version.
- Manifest: A description that can be applied to a target.
- Catalog: A compiled manifest.
- Apply: Modifying the state of a target so that it reflects its description in a manifest.
- Module: A set of manifests.
- Resource: A minimal piece of description. A manifest consists of a piece of resources, which describe components of a system, like a file or a service.
- Resource type: Determines the class of a resource. For example there is a
file
resource type, and a manifest can contain any number of resources of this type, which describe different files. - Attribute: It's a characteristic of a resource, like a file owner, or its mode.
- Class: A group of resources that can be reused in several manifests.
Architecture
Depending on how the user decides to deploy changes, Puppet can use two different architectures:
- An Agent-master architecture. This is the preferred way to use Puppet.
- A standalone architecture, that is similar to Ansible architecture.
Agent-master Architecture
A Puppet master stores a catalog for each target. There may be more than one Puppet master, for redundancy.
Each target runs a Puppet agent in background. Each Puppet agent periodically connects to the Puppet master, sending its facts. The Puppet master compiles the relevant manifest using the facts it receives, and send back a catalog.
Once the Puppet agent receives the up to date catalog, it checks all resources and compares them with its current state. It applies the necessary changes to make sure that its state reflects the resources present in the catalog.
Standalone Architecture
References
Content initially contributed by Vettabase Ltd.