Ansible: Difference between revisions
From charlesreid1
| Line 74: | Line 74: | ||
===Connect Ansible to Vagrant=== | ===Connect Ansible to Vagrant=== | ||
Use the hosts file to tell Ansible how to connect to the (Vagrant) hosts. | |||
Edit <code>playbooks/hosts</code> and include details about each vagrant host. | |||
Use the command <code>vagrant ssh-config</code> to get these details. | |||
Example: | |||
<pre> | <pre> | ||
| Line 85: | Line 87: | ||
myvagrantbox ansible_host=127.0.0.1 ansible_port=2222 ansible_user=vagrant ansible_private_key_file=.vagrant/machines/default/virtualbox/private_key | myvagrantbox ansible_host=127.0.0.1 ansible_port=2222 ansible_user=vagrant ansible_private_key_file=.vagrant/machines/default/virtualbox/private_key | ||
</pre> | </pre> | ||
'''Side note:''' once you are ready to run with an AWS EC2 node, you would specify the hostname of the EC2 node and the AWS .pem private key, like so: | '''Side note:''' once you are ready to run with an AWS EC2 node, you would specify the hostname of the EC2 node and the AWS .pem private key, like so: | ||
Revision as of 05:02, 10 November 2018
Ansible can be thought of as a for-loop over SSH scripts, but it's also much more than that.
Ansible is all about taking care of the heavy lifting involved in infrastructure automation.
Related:
- Ansible/Playbooks - this is where Ansible becomes really powerful
- Ansible/Hosts - configuring machines to work with Ansible
Basic Features
Summary:
- Ansible is Python-based
- Ansible uses playbooks, which are YAMl files, to configure remote machines
- Ansible is push-based, which means your workflow involves making changes to the playbook and pushing those changes to the server
- Ansible is idempotent, which means you can run the playbook multiple times and it will only carry out new tasks (it will not repeat tasks)
- Ansible allows executing arbitrary shell commands
- Ansible uses Jinja templates, in addition to YAML, to deploy files to machines
Directory Structure
The basic directory structure we'll use with Ansible is to create a playbooks directory to hold everything:
playbooks/
.vagrant/ <-- directory used by vagrant for keys/machines (if using vagrant)
hosts <-- ansible inventory file
Using Ansible Locally with Vagrant
Vagrant allows you to set up virtual machine(s) using VirtualBox, which can give you a way of testing Ansible scripts locally (without using the AWS or Google Cloud platforms). You can then connect Ansible with vagrant to manage and set up compute nodes using Ansible.
Before you begin: set up vagrant box
See the Basic Startup and Shutdown Procedure section of the Vagrant page for steps to set up a Vagrant box, and connect to it via SSH.
Briefly:
To initialize a vagrant box:
vagrant init ubuntu/xenial64
To bring it up:
vagrant up
For info about the ssh configuration of the box:
vagrant ssh-config
To ssh into the box:
vagrant ssh
To halt the machine:
vagrant halt
Connect Ansible to Vagrant
Use the hosts file to tell Ansible how to connect to the (Vagrant) hosts.
Edit playbooks/hosts and include details about each vagrant host.
Use the command vagrant ssh-config to get these details.
Example:
$ cat playbooks/hosts myvagrantbox ansible_host=127.0.0.1 ansible_port=2222 ansible_user=vagrant ansible_private_key_file=.vagrant/machines/default/virtualbox/private_key
Side note: once you are ready to run with an AWS EC2 node, you would specify the hostname of the EC2 node and the AWS .pem private key, like so:
$ cat playbooks/hosts myamazonbox ansible_host=ec2-203-0-113-120.compute-1.amazonaws.com ansible_user=ubuntu ansible_private_key_file=/path/to/keyfile.pem
Your vagrant boxes should be up and running with the vagrant up command.
Ping Vagrant box
Now connect to the machine and test that it is up. Pass the -i flag and the name of the inventory file, and -m and the name of the module you want to run. We'll run the ping module:
$ ansible myvagrantbox -i hosts -m ping
You should see some output like this:
myvagrantbox | success >> {
"changed": false,
"ping": "pong"
}
If it did not succeed, re-run with the -vvvv flag for max verbosity to help debug the issue.
This is a basic vagrant script (module) that just runs a ping test; if the server on the other end responds, it results in a pong. The "'changed': false" indicates that Ansible is not changing the state of the machine.
Use a config file
The inventory file (hosts) required lots of details, and if we have many nodes to deal with that is not going to scale well.
To make it easier to deal with, we can use the ansible.cfg file to set some defaults and variables.
Where to put ansible.cfg? Here is where Ansible looks:
ANSIBLE_CONFIGenv var (specifies the config file)/ansible.cfg(current directory)~/.ansible.cfg(.ansible.cfg in your home directory/etc/ansible/ansible.cfg
A good place for it is alongside the playbooks, in the current directory.
This dir structure allows you to place the config file, plus the playbooks, under version control in a single repo.
Example config file
To specify default values for SSH key, username, and inventory filename, use this config file:
ansible.cfg:
[defaults] inventory = hosts remote_user = vagrant private_key_file = .vagrant/machines/default/virtualbox/private_key host_key_checking = False
Now we can also simplify the hosts file:
playbooks/hosts:
myvagrantbox ansible_host=127.0.0.1 ansible_port=2222
Because the hosts file is already specified as the inventory file, we don't have to use the -i flag:
$ ansible myvagrantbox -m ping
Executing arbitrary commands
We have already seen the -m flag used with ansible to specify an ansible module. This is a command or set of commands or a script that is run on the vagrant machine(s) that we specify.
We can use the command module to run arbitrary commands on the vagrant machines that ansible is managing.
To run the uptime command on our vagrant box:
$ ansible myvagrantbox -m command -a uptime
Results in:
testserver | success | rc=0 >> 17:14:07 up 1:16, 1 user, load average: 0.16, 0.05, 0.04
Note that this is actually the default module!!! So we don't need to specify -m command, that is the default value:
$ ansible myvagrantbox -a uptime
If the command has spaces in it, use quotes:
$ ansible myvagrantbox -a "tail /var/log/dmesg"
Executing root commands
To run commands that require root access, pass the -b flag to BECOME the root user:
$ ansible myvagrantbox -b -a "tail /var/log/syslog"
Installing packages
The apt module is useful for installing packages. Here's how you would install nginx:
$ ansible myvagrantbox -b -m apt -a name=nginx
IMPORTANT: The first apt module command you give should also run the equivalent of apt-get update before the package is installed. To do that, change the name to name="nginx update_cache=yes".
Finally, restart Nginx as follows:
$ ansible myvagrantbox -b -m service -a "name=nginx state=restarted"