Hasta la vista, Puppet – part 1

After years using shell script to automate my sysadmin tasks, I’ve decided to migrate my little monsters to the mighty Ansible. The reason that made Ansible awesome can be described in one word, IDEMPOTENCY.

It means that you can run an Ansible task one or one thousand times, that the result will be the same every time. For the ones that like shell script like me, this is perfect because we don’t need anymore to expect and threat conditions in ours scripts.

But with great powers comes great responsibility, remember that with one wrong move you can stairway to heaven or highway to hell.

Before start using our new powers, let’s learn about them a little. We need to gain concepts about Ansible features and there’s a lot of them.

# What is it?

Ansible is an open source agent-less configuration management tool. It can configure systems, deploy software, and orchestrate advanced tasks such as continuous deployments or zero downtime rolling updates. It manages nodes over SSH protocol and requires python 2.4 or later.

# How to install?

Ansible by default manages machines over the SSH protocol, once Ansible is installed, it will not add a database, and there will be no daemons to start or keep running.

  • Control Machine requirements

Ansible core can be run from any machine with Python 2.6 or 2.7 installed, this includes Red Hat, Debian, CentOS, OS X, and any of the BSDs.

Latest Releases Via Apt (Ubuntu): To configure the PPA on your machine and install Ansible run these commands:

$ sudo apt-get install software-properties-common
$ sudo apt-add-repository ppa:ansible/ansible
$ sudo apt-get update
$ sudo apt-get install ansible
  • Managed Node requirements

On the managed nodes, you need Python 2.4 or later.

If you are running less than Python 2.5 on the remotes, you will also need to install python-simplejon.

$ sudo apt-get install python-simplejson

(Check this link for more information about how to install Ansible.)

# How to use it?

Ansible can be used in two different modes.

  • Ad Hoc commands: An ad-hoc command is something that you might type in to do something really quick, but don’t want to save for later, like execute a single command on a group of nodes.
  • Playbooks: Playbooks are Ansible’s configuration, deployment, and orchestration language. They can describe a policy you want your remote systems to enforce, or a set of steps in a general IT process.

Before start using Ansible via command line, we need to exchange our Master SSH key to our Blaster, Let’s rock Bartertown.

(Check this link to read more about SSH/OpenSSH/Keys.)

 

  • SSH – Generating RSA Key on Master.

Please use a strong passphrase for better security.

$ mkdir ~/.ssh
$ chmod 700 ~/.ssh
$ ssh-keygen -t rsa -b 4096
  • SSH – Transfer Pub SSH Key to Blaster.

Remember to change the values <username> and <host> to fit your environment.

$ ssh-copy-id -i ~/.ssh/id_rsa.pub <username>@<host>
  • SSH – Avoid SSH from prompting key passphrase for password less login.

The ssh-agent can be used to store your passphrase so that you do not have to enter it each time you make a ssh or scp connection.

Add the above shell function to your shell profile to automate the adding of all of yours SSH keys in your ssh-agent process. Just copy and paste the above code in your terminal, the magic Here Documents will work fine.

cat <<EOF>> ~/.bashrc
# ssh-agent configuration
SSH_ENV="$HOME/.ssh/environment"

function start_agent {
 echo "Initialising new SSH agent..."
 /usr/bin/ssh-agent | sed 's/^echo/#echo/' > "${SSH_ENV}"
 echo succeeded
 chmod 600 "${SSH_ENV}"
 . "${SSH_ENV}" > /dev/null
 ls ~/.ssh/id_[d,r]* | egrep -v 'pub$' | while read -r line ; do ssh-add $line ; done
}

# source SSH settings, if applicable
if [ -f "${SSH_ENV}" ]; then
 . "${SSH_ENV}" > /dev/null
 #ps ${SSH_AGENT_PID} doesn't work under cywgin
 ps -ef | grep ${SSH_AGENT_PID} | grep ssh-agent$ > /dev/null || {
 start_agent;
 }
else
 start_agent;
fi
EOF

Let’s configure one more thing in our SSH Master, the above trick is called sshd_config, pay attention because this is a global configuration.

cat <<EOF>> ~/.ssh/config
Host *
 User root
 ForwardAgent no
 ForwardX11 no
 PasswordAuthentication no
 HostBasedAuthentication no
 ServerAliveInterval 15
 TCPKeepAlive yes
 BatchMode yes
 CheckHostIP no
 ConnectTimeout 5
 LogLevel ERROR
 UserKnownHostsFile /dev/null
 StrictHostKeyChecking no
 GSSAPIAuthentication no
 GSSAPIDelegateCredentials no
EOF

Now with this Blaster! Twenty men enter, only him leave!

  • Ansible – Configuration and Inventory files.

Certain settings in Ansible are adjustable via a configuration file. The stock configuration should be sufficient for most users, but there may be reasons you would want to change them.

Changes can be made and used in a configuration file which will be processed in the following order:

* ANSIBLE_CONFIG (an environment variable)
* ansible.cfg (in the current directory)
* .ansible.cfg (in the home directory)
* /etc/ansible/ansible.cfg

Ansible works against multiple systems in your infrastructure at the same time. It does this by selecting portions of systems listed in Ansible’s inventory file, which defaults to being saved in the location /etc/ansible/hosts. You can specify a different inventory file using the -i <path> option on the command line.

The format for /etc/ansible/hosts is an INI-like format and looks like this:

[webservers]
vader.example.com
yoda.example.com

[dbservers]
luke.example.com
obi-wan.example.com
chewbacca.example.com

 

It is ok to put systems in more than one group, for instance a server could be both a webserver and a dbserver

If you have hosts that run on non-standard SSH ports you can put the port number after the hostname with a colon. Ports listed in your SSH config file won’t be used with the paramiko connection but will be used with the openssh connection.

leia.example.com:2222
  • Ansible – Ad Hoc Commands.

The following example show how to use /usr/bin/ansible for running an ad hoc tasks to check the SSH access to all hosts and execute shell commands in the remote server.

$ ansible -m ping all
$ ansible -m shell 'uname -n ; uptime' dbservers
$ ansible -m raw 'uname -n ; uptime' webservers

For now, you discovered important things about your powers and you can use them for good. In the next article you be able to understand in deep your powers, and learn about playbooks, that is the state of art when used in roles.

 

Advertisements

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s