Ansible: Difference between revisions

From charlesreid1
No edit summary
 
(15 intermediate revisions by the same user not shown)
Line 1: Line 1:
Ansible can be thought of as a for-loop over SSH scripts, but it's also much more than that.
https://charlesreid1-docker.github.io/charlesreid1-ansible/
 
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


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.


==Basic Features==
==Basic Features==
Line 28: Line 22:
<pre>
<pre>
playbooks/
playbooks/
    hosts      <-- ansible inventory file
     .vagrant/  <-- directory used by vagrant for keys/machines (if using vagrant)
     .vagrant/  <-- directory used by vagrant for keys/machines (if using vagrant)
     hosts      <-- ansible inventory file
     playbook.yml
</pre>
</pre>


==Using Ansible Locally with Vagrant==
See [[Ansible/Directory Layout]] for a much more detailed discussion.
 
[[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.
==Using Ansible==


===Before you begin: set up vagrant box===
===Using Ansible Locally with Vagrant===


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.
{{Main|Ansible/Vagrant}}


Briefly:
[[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).  
 
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===
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).


Use the hosts file to tell Ansible how to connect to the (Vagrant) hosts.
See [[Ansible/Vagrant]] for coverage of both methods when using Vagrant.


====Managing hosts file by hand====
See [[Ansible/Vagrant/Dynamic_Inventory]] for a dynamic inventory script with Vagrant.


Edit <code>playbooks/hosts</code> and include details about each vagrant host.
===Using Ansible with EC2===


Use the command <code>vagrant ssh-config</code> to get these details.
{{Main|Ansible/EC2}}


Example:
When using Ansible with Amazon AWS EC2, AWS manages the compute nodes.


<pre>
Like with Vagrant, Ansible uses the hosts file to connect to the EC2 nodes. The hosts file can either be maintained by hand using the information from AWS, or a dynamic inventory script can be used to call the AWS API and get information about computational resources to give to Ansible.
$ 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
See [[Ansible/EC2]] for coverage of both methods (the static inventory script and the dynamic inventory script) when using Amazon EC2.
</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:
See [[Ansible/EC2/Dynamic Inventory]] for an example EC2 dynamic inventory script.


<pre>
==Ansible Features==
$ 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
===Playbooks===
</pre>


Your vagrant boxes should be up and running with the <code>vagrant up</code> command.
Playbooks are the central feature of Ansible, and are where you tell Ansible what to do on what machines.


====Managing hosts dynamically====
[[Ansible/Playbooks]] - this is where Ansible becomes really powerful


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
[[Ansible/Variables]] - defining and using variables to remove complexity


This can be used by specifying the path to the executable dynamic inventory script using the -i flag when running ansible:
===Hosts===


<pre>
Ansible host files tell Ansible how to work with host machines. Ansible can also interact programmatically with hosts.
ansible -i dynamic_vagrant.py ...
</pre>


===Ping Vagrant box===
[[Ansible/Hosts]] - configuring machines to work with Ansible


To ping the Vagrant machine (that Ansible is managing), use Ansible's ping module.
===Roles===


Call Ansible and the name of the machine (must be listed in the hosts file).
Roles can provide multiple "routes" through a playbook for different types of machines


Pass it the inventory file name with the -i flag, and the ping module with the -m flag:
[[Ansible/Roles]] - defining and using roles to make playbooks more powerful


<pre>
===Vaults and Secrets===
ansible myvagrantbox -i hosts -m ping
</pre>


or if you're using a dynamic inventory file,
Ansible uses vaults to encrypt and store keys and secrets. You can include a vault in <code>playbooks/group_vars</code> and have ansible ask for a password on the command line:


<pre>
<pre>
ansible myvagrantbox -i hosts -m ping
ansible-playbook site.yml --ask-vault-pass
</pre>
</pre>


You should see some output like this:
[[Ansible/Vaults]] - mechanism for encrypting and decrypting secrets
 
<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>


=Flags=
=Flags=


 
{{AnsibleFlag}}
[[Category:Web Server]]
[[Category:Nginx]]
[[Category:Ansible]]
[[Category:Infrastructure]]
[[Category:Python]]
[[Category:HTTPS]]
[[Category:SSL]]

Latest revision as of 02:25, 29 March 2019

https://charlesreid1-docker.github.io/charlesreid1-ansible/

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.

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

See Ansible/Directory Layout for a much more detailed discussion.

Using Ansible

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.

See Ansible/Vagrant/Dynamic_Inventory for a dynamic inventory script with Vagrant.

Using Ansible with EC2

Main article: Ansible/EC2

When using Ansible with Amazon AWS EC2, AWS manages the compute nodes.

Like with Vagrant, Ansible uses the hosts file to connect to the EC2 nodes. The hosts file can either be maintained by hand using the information from AWS, or a dynamic inventory script can be used to call the AWS API and get information about computational resources to give to Ansible.

See Ansible/EC2 for coverage of both methods (the static inventory script and the dynamic inventory script) when using Amazon EC2.

See Ansible/EC2/Dynamic Inventory for an example EC2 dynamic inventory script.

Ansible Features

Playbooks

Playbooks are the central feature of Ansible, and are where you tell Ansible what to do on what machines.

Ansible/Playbooks - this is where Ansible becomes really powerful

Ansible/Variables - defining and using variables to remove complexity

Hosts

Ansible host files tell Ansible how to work with host machines. Ansible can also interact programmatically with hosts.

Ansible/Hosts - configuring machines to work with Ansible

Roles

Roles can provide multiple "routes" through a playbook for different types of machines

Ansible/Roles - defining and using roles to make playbooks more powerful

Vaults and Secrets

Ansible uses vaults to encrypt and store keys and secrets. You can include a vault in playbooks/group_vars and have ansible ask for a password on the command line: 

ansible-playbook site.yml --ask-vault-pass

Ansible/Vaults - mechanism for encrypting and decrypting secrets

Flags


Defcon.png
Ansible
Ansible is a Python library for managing IT and compute infrastructure.

Ansible  · Category:Ansible


Ansible Configuration

Config file: Ansible/Configuration

Secrets and Sensitive Info: Ansible/Security  · Ansible/Vaults


Ansible Playbooks

Basics: Ansible/Playbooks

Examples: Ansible/Nginx Playbook (simple)  · Ansible/Full Stack Playbook (advanced)


Ansible Hosts and Inventory Control

All topics in Ansible Hosts: Ansible/Hosts

Splitting large host files into subfiles: Ansible/Splitting Hosts File

Automatically naming hosts: Ansible/Host Naming

Grouping Hosts: Ansible/Groups

Assigning Variables to Groups: Ansible/Group Variables

Roles: Ansible/Roles


Ansible and Vagrant (Local)

Ansible/Vagrant  · Ansible/Vagrant/Static Inventory  · Ansible/Vagrant/Dynamic Inventory


Ansible and EC2 (Cloud)

Ansible/EC2  · Ansible/EC2/Static Inventory  · Ansible/EC2/Dynamic Inventory


Best Practices

Ansible/Directory Layout  · Ansible/Directory Layout/Details

Ansible/Separate Playbooks by Role

Ansible/Tag Inventory with Environment

Ansible/Group by Distribution

Ansible/Variables and Vaults


Ansible Galaxy

Ansible/Galaxy


Flags  · Template:AnsibleFlag  · e



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