Although a test cluster can be deployed on any hardware or virtual machine (VM), for the purposes of this book, a combination of Vagrant and VirtualBox will be used. This will allow rapid provisioning of the VMs and ensure a consistent environment.

VirtualBox is a free and open source type 2 (hosted) hypervisor currently being developed by Oracle. Performance and features may be lacking compared with high-end hypervisors, but its lightweight approach, and multi-OS support lends itself to be a prime candidate for testing.

Vagrant helps allow an environment that may comprise many machines to be created quickly and efficiently. It works with the concepts of boxes, which are predefined templates for use with hypervisors and its Vagrantfile, which defines the environment to be built. It supports multiple hypervisors and allows a Vagrantfile to be portable across...

One solution to making the installation and management of Ceph easier is to use an orchestration tool. There are several tools available, such as Puppet, Chef, Salt, and Ansible, all of which have Ceph modules available. If you are already using an orchestration tool in your environment, then it would be recommended that you stick to using that tool. For the purposes of this book, Ansible will be used; this is for a number of reasons:

• It's the favored deployment method of Red Hat, who are the owners of both the Ceph and Ansible projects
• It has a well-developed and mature set of Ceph roles and playbooks
• Ansible tends to be easier to learn if you have never used an orchestration tool before
• It doesn't require a central server to be set up, which means demonstrations are more focused on using the tool rather than installing it

All tools follow the same principle of where you provide them with...

As mentioned, Ansible will be the orchestration tool of choice for this book, let's look at it in a bit more detail.

Ansible is an agentless orchestration tool written in Python, which uses SSH to carry out configuration tasks on remote nodes. It was first released in 2012 and has gained widespread adoption, and it is known for its ease of adoption and low learning curve. Red Hat purchased the commercial company Ansible, Inc. in 2015 and so has a very well-developed and close-knit integration for deploying Ceph.

Files named playbooks are used in Ansible to describe a list of commands, actions, and configurations to carry out on specified hosts or groups of hosts and are stored in a YAML file format. Instead of having large unmanageable playbooks, Ansible roles can be created that allow a playbook to contain a single task, which may then carry out a number of tasks associated with the role.

The use of...

To demonstrate how playbooks work, the following example will show a small playbook that also makes use of the variables we configured earlier:

- hosts: mon1 osd1
tasks:
- name: Echo Variables
debug: msg="I am a {{ a_variable }}"

Now run the playbook. Note the command to run a playbook that differs from running ad hoc Ansible commands:

    $ ansible-playbook /etc/ansible/playbook.yml

The preceding command gives the following output:

The output shows the playbook being executed on both mon1 and osd1 as they are in groups, which are children of the parent group ceph. Also, note how the output is different between the two servers as they are picking up the variables that you set earlier in the group_vars directory.

Finally, the last couple of lines show the overall run status of the playbook run. You can now destroy your Vagrant environment again, ready for the next section:

    vagrant...

We can use git to clone the Ceph Ansible repository:

    git clone https://github.com/ceph/ceph-ansible.git

    sudo cp -a ceph-ansible/* /etc/ansible/

The preceding commands gives the following output:

Let's also explore some of the key folders in the git repository:

• group_vars: We've already covered what lives in here and will explore the possible configuration options in more detail later.
• infrastructure-playbooks: This directory contains prewritten playbooks to carry out some standard tasks, such as deploying cluster or adding OSDs to an existing one. The comments at the top of the playbooks give a good idea of what they do.
• roles: This directory contains all the roles that make up the Ceph Ansible modules. You will see that there is a role for each Ceph component, these are what are called via the playbooks to install, configure and maintain Ceph.

In order to be...

If you deploy your infrastructure with an orchestration tool such as Ansible, managing the Ansible playbooks becomes important. As we have seen Ansible allows you to rapidly deploy both the initial Ceph cluster but also configuration updates further down the line. It must be appreciated that this power can also have devastating effects if incorrect configuration or operations are deployed. By implementing some form of configuration management, Ceph administrators will clearly be able to see what changes have been made to the Ansible playbooks before running them.

A recommended approach would be to store your Ceph Ansible configuration in a git repository, this will allow you to track changes and gives the ability to implement some form of change control either by monitoring git commits or by forcing people to submit merge requests into the master branch.

In this chapter you will have learnt about the various deployment methods of Ceph that are available and the differences between them. You will now also have a basic understanding of how Ansible works and how to deploy a Ceph cluster with it. It would be advisable at this point to continue investigating and practicing deployment and configuration of Ceph with Ansible, so that you are confident to use it in production environments. The rest of this book will also make several assumptions that you have fully understood the contents of this chapter in order to manipulate the configuration of Ceph.