The Ultimate Guide to High Availability with MariaDB

Puppet Overview for MariaDB Users

You are viewing an old version of this article. View the current version here.

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

  1. Design Principles
  2. Concepts
  3. Architecture
    1. Agent-master Architecture
    2. Standalone Architecture
  4. References

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

Comments

Comments loading...
Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.