The ansible-repository project

Hello everybody,

My company’s making the swtich from Puppet to Ansible ; i’m one of those pushing the change.

As such, i’m trying to create an internal coding standard and a set of common building blocks that each team member should use when writing ansible plays and playbooks.

An example of the standards i’m thinking of can be found here :
https://github.com/gaspaio/ansible-repository

This is a repository of “Parts” : playbook reusable components.

The conventions for writing each part are :

  1. 4 directories and 1+ example playbook(s), nothing new here.

  2. The tasks directory should contain a file called “setup.yml” : this installs and setups up the application the part is for.

  3. Other task files can exist, scripting common actions with the application

  4. Each task file should start with a header, describing the task, the variables, the dependencies, etc (cf. https://github.com/gaspaio/ansible-repository/blob/master/apache/tasks/setup.yml)

  5. A vars/main.yml should exist and contain all variable default values. It should be well commented.

  6. All local path files should use the global “repository_basedir” variable, defined in the playbook. Since local paths used in module “template” for example are relative to the playbook, this allows us to have a global system installation of the ansible repository and still have playbooks anywhere on our system.

  7. Tasks should be simple and non specific. They should perform a basic installation of the application only. Anything more should be done by forking the part to a particular playbook or use case.

Does this sound coherent with the ansible projet best practices and usage guidelines ?

Rodolfo

Hi Rodolfo,

The mailing list moderates first-time posters, so no problems in the
duplicate post.

I guess the great thing about ansible is it doesn't force you down any
particular structure. You can see some "best practices" playbooks we
have published here:

https://github.com/ansible/ansible-examples

We have plans on expanding these *VERY* rapidly for some rather
involved/useful use cases, largely around distributed systems as
opposed to single-shot-package-configuration.

You can also see some useful tips here:
http://ansible.cc/docs/bestpractices.html

Hope this helps. Obviously you can deviate if you find certain
things work for you or don't.

--Michael