What often is the hardest part of learning something new “just because” is what to do with it after you have accomplished Hello World.
Ever wanted to play with Ansible? Use it at home. Why? Because its dead simple to get started and who likes doing things twice or taking build notes to follow by hand if you can find them?
And if you do any one-board computers like Raspberry Pi, Odroid etc that live on a sd card, you will end up with it getting corrupted and rebuilding it. Using config management makes things much less sigh inducing when that happens and you don’t have to keep making a golden image after every update if thats your idea of saving your work.
Yes you can setup a Puppet or Chef server, or distribute the modules/cookbooks aound and run either one without a server. Or I can put some stuff in a github repo, pass out ssh keys, learn a bit about something new, and not feel like your at work when your home-gaming.
How I did it, an overview:
Git
I could make myself a git repo inside a bittorrent sync share to keep history and keep it safe, but since GitHub changed its pricing and account model and I have private repos far as the eye can see I just use that.
Skip this step or use another way to track your code, but track it somehow so we iterate not recreate.
Ansible Install
On Mac if you use Homebrew (why aren’t you?) its the usual dance:
$ brew install ansible
Use whatever package management makes sense for your OS of course.
SSH Keys
To get to all your hosts to manage Ansible uses ssh by default. Drop a pub ssh key onto the host for the root user, use a passphrase and ssh-agent.
Playbooks
There are only two files you need to get started, one to hold the info on the hosts you want to manage and one for the playbook, which is a YAML file with what needs to be done on the hosts.
Example hosts file:
[server1] 192.168.10.101
Example base playbook, everything has a “name” which you can use to self document and is displayed in the ansible run:
---
- hosts: server1
gather_facts: no
remote_user: root
tasks:
- name: install screen
apt: name=screen state=latest
- name: root .bashrc
copy: src=files/root.bashrc dest=/root/.bashrc owner=root mode=0644
- name: create /opt/local/bin
file: path=/opt/local/bin state=directory mode=755
This is all you need to get started, assuming all is lined up right with ssh, make it go:
$ ansible-playbook -i hosts base_playbook.yml PLAY [server1] ***************************************************************** TASK [install screen] ********************************************************** ok: [192.168.10.101] TASK [root .bashrc] ************************************************************ changed: [192.168.10.101] TASK [create /opt/local/bin] *************************************************** changed: [192.168.10.101] PLAY RECAP ********************************************************************* 192.168.10.101 : ok=3 changed=2 unreachable=0 failed=0
Above you see screen was already installed so “ok”, it updated the .bashrc with one at the local path specified in the playbook, and made the /opt/local/bin dir. Its that simple.
You can include a base playbook into a role playbook, and get all complicated to do all sorts of things, but this will get you going and on your way to learning something new and keeping that effort around you put into building that server for reuse.
Many projects you find on this site will include Ansible as part of the writeup. Below are some good starting points if you want to follow along.
Scheme?
You can find some best practices for directory layout for managing your Ansible stuff here, but there is no specific need for anything to be anywhere special that I’ve found. So to get started I simply made a new github repo and made the host file and the playbook yml files right in the root. I then got to the point where things were a tad messy and made a ‘files’ directory as you can see referenced above because it was similar to what i’m used to in Chef and it hid most of the misc stuff away.
The point being, do what your comfortable with and it can evolve or not. At home things don’t change often so keeping things very simple helps when you show up after not touching things for weeks or months.
What really got me going with this subject and then to Ansible was as mentioned above, building something on a one-board computer using sd card to boot and dealing with the fragility of the FS getting corrupted from power interruptions. Whether its the one in my truck or the one I set out when we are on a trip with security camera stuff on it, I didn’t want to have to re-build the thing and remember all the steps I took to get it setup. Taking notes? Why not just put it in config management and be able to re-create and evolve? So thats what I did. I’ve got notes that actually implement the system it describes, all I have to do is have ssh access and I can clone the repo and make changes, and I can worry less (and share!).
So there is no big story to tell about how to configure and manage Ansible as a service from here as there is with Chef/Puppet/CFEngine etc. Just focus on the task at hand and become familiar with new tech!