Ansible: Difference between revisions

From charlesreid1
Line 34: Line 34:


==Using Ansible Locally with Vagrant==
==Using Ansible Locally with Vagrant==
{{Main|Ansible/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).  
[[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).  


Details of how to connect to vagrant boxes can be added to the Ansible hosts file, or machines can be managed using a dynamic inventory script (see [[Ansible/Hosts/Dynamic Inventory]] for an example Vagrant dynamic inventory script). This will allow Ansible to connect to the remote machines and execute commands.
Ansible uses the hosts file to connect to Vagrant. You can either manage the hosts file by hand (for a small number of machines), or you can use a dynamic inventory script (for an arbitrary number of machines).
 
===Before you begin: set up vagrant box===
 
See the [https://charlesreid1.com/wiki/Vagrant#Basic_Startup_Shutdown_Procedure 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:
 
<pre>
vagrant init ubuntu/xenial64
</pre>
 
To bring it up:
 
<pre>
vagrant up
</pre>
 
For info about the ssh configuration of the box:
 
<pre>
vagrant ssh-config
</pre>
 
To ssh into the box:
 
<pre>
vagrant ssh
</pre>
 
To halt the machine:
 
<pre>
vagrant halt
</pre>
 
Note: for multiple vagrant boxes, see the guide on the [https://charlesreid1.com/wiki/Ansible/Full_Stack_Playbook#Vagrant_multi-machine_setup Ansible/Full Stack Playbook] page.
 
===Connect Ansible to Vagrant===
 
Use the hosts file to tell Ansible how to connect to the (Vagrant) hosts.
 
====Managing hosts file by hand====
 
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>
$ 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
</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:
 
<pre>
$ 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
</pre>
 
Your vagrant boxes should be up and running with the <code>vagrant up</code> command.
 
====Managing hosts dynamically====
 
There is a dynamic inventory management script that interacts with vagrant to provide Ansible with machine details: https://charlesreid1.com/wiki/Ansible/Hosts/Dynamic_Inventory#Putting_it_all_together
 
This can be used by specifying the path to the executable dynamic inventory script using the -i flag when running ansible:
 
<pre>
ansible -i dynamic_vagrant.py ...
</pre>
 
===Ping Vagrant box===
 
To ping the Vagrant machine (that Ansible is managing), use Ansible's ping module.
 
Call Ansible and the name of the machine (must be listed in the hosts file).
 
Pass it the inventory file name with the -i flag, and the ping module with the -m flag:
 
<pre>
ansible myvagrantbox -i hosts -m ping
</pre>
 
or if you're using a dynamic inventory file,
 
<pre>
ansible myvagrantbox -i hosts -m ping
</pre>
 
You should see some output like this:
 
<pre>
myvagrantbox | success >> {
    "changed": false,
    "ping": "pong"
}
</pre>
 
If it did not succeed, re-run with the <code>-vvvv</code> flag for max verbosity to help debug the issue.
 
This is a basic module that runs a ping test; the server should respond with a pong on the other end.
 
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 <code>ansible.cfg</code> file to set some defaults and variables.
 
Where to put ansible.cfg? Here is where Ansible looks:
 
* <code>ANSIBLE_CONFIG</code> env var (specifies the config file)
* <code>/ansible.cfg</code> (current directory)
* <code>~/.ansible.cfg</code> (.ansible.cfg in your home directory
* <code>/etc/ansible/ansible.cfg</code>
 
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:
 
'''<code>ansible.cfg</code>:'''
 
<pre>
[defaults]
inventory = hosts
remote_user = vagrant
private_key_file = .vagrant/machines/default/virtualbox/private_key
host_key_checking = False
</pre>
 
Now we can also simplify the hosts file:
 
'''<code>playbooks/hosts</code>:'''
 
<pre>
myvagrantbox ansible_host=127.0.0.1 ansible_port=2222
</pre>
 
Because the hosts file is already specified as the inventory file, we don't have to use the -i flag:
 
<pre>
$ ansible myvagrantbox -m ping
</pre>
 
===Executing arbitrary commands===
 
We have already seen the <code>-m</code> flag used with ansible to specify an ansible module.
 
We can use the <code>command</code> module to run arbitrary commands on the vagrant machines that ansible is managing.
 
To run a command on the remote machine via ansible:
 
<pre>
ansible myvagrantbox -m command -a <the command to run>
</pre>
 
For example, to run the uptime command:
 
<pre>
ansible myvagrantbox -m command -a uptime
</pre>
 
Results in:
 
<pre>
testserver | success | rc=0 >>
17:14:07 up  1:16,  1 user,  load average: 0.16, 0.05, 0.04
</pre>
 
====Important Note====
 
The command module '''is actually the default module'''!!! So we don't need to specify <code>-m command</code>, that is the default value:
 
<pre>
ansible myvagrantbox -a <the command to run>
</pre>
 
For example:
 
<pre>
ansible myvagrantbox -a uptime
</pre>
 
If the command has spaces in it, use quotes:
 
<pre>
ansible myvagrantbox -a "tail /var/log/dmesg"
</pre>
 
===Executing root commands===
 
To run commands that require root access, pass the <code>-b</code> flag to BECOME the root user:
 
<pre>
$ ansible myvagrantbox -b -a "tail /var/log/syslog"
</pre>
 
===Installing packages===
 
The apt module is useful for installing packages. Here's how you would install nginx:
 
<pre>
ansible myvagrantbox -b -m apt -a name=nginx
</pre>
 
'''IMPORTANT:''' The first apt module command you give should also run the equivalent of <code>apt-get update</code> before the package is installed. To do that, change the name to <code>name="nginx update_cache=yes"</code>:
 
<pre>
ansible myvagrantbox -b -m apt -a name="nginx update_cache=yes"
</pre>
 
===Starting services===
 
Once nginx is installed, the service can be started using the service module:
 
<pre>
ansible myvagrantbox -b -m service -a "name=nginx state=restarted"
</pre>


equivalent of running <code>sudo service nginx restart</code>
See [[Ansible/Vagrant]] for coverage of both methods when using Vagrant.


=Flags=
=Flags=

Revision as of 01:29, 11 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:


Basic Features

Main article: Ansible/Basics

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/
    hosts       <-- ansible inventory file
    .vagrant/   <-- directory used by vagrant for keys/machines (if using vagrant)
    playbook.yml

Using Ansible Locally with Vagrant

Main article: Ansible/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).

Ansible uses the hosts file to connect to Vagrant. You can either manage the hosts file by hand (for a small number of machines), or you can use a dynamic inventory script (for an arbitrary number of machines).

See Ansible/Vagrant for coverage of both methods when using Vagrant.

Flags

Retrieved from "https://charlesreid1.com/w/index.php?title=Ansible&oldid=25351"