NOTE: Be sure that you change authorized_keys in ansible-mojo to contain the public key that you configured your ssh-agent to use for deployment as mentioned in Part I. I opted to have a single primary playbook ( main.yml) that does some initial node configuration then includes other playbooks for specific configuration changes like configuring users ( user-config.yml) and installing sysstat for SAR reporting ( sysstat-config.yml).īefore I go into details on each of the playbooks, let’s go ahead and do an initial playbook run against our Ubuntu Vagrant box so that we can issue further commands using our dedicated deployment user account “ansible” instead of the “vagrant” user. All playbook content is based on YAML-formatted text files that are easily understandable. The anisible-mojo repo contains several files: playbooks, a variables file, and a couple of shell environment files. management of users and sudoers content.

a dedicated user account “ansible” for deployment standardization,.Similar to recipes and cookbooks in Chef, Ansible’s plays and playbooks are the basis for a best-practice implementation of Ansible to manage your infrastructure in a consistent, flexible, and repeatable fashion.įor ansible-mojo, I wanted to create a set of simple playbooks that would be helpful in demonstrating how to configure nodes with some basic things like: However, it really shines once you start developing collections of commands, or “plays”, in the form of “playbooks” to manage nodes. Once Ansible is up and running, it is extremely useful for managing nodes using ad-hoc commands. Now, let’s take a closer look at using Ansible along with the details of my demo playbook collection ansible-mojo.

In Part I, I talked about why Ansible and how to configure your own installation using Vagrant, VirtualBox, and Ansible.

Bento ubuntu