|
|
| (32 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. | | 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== |
|
| |
|
| Ansible config management scripts (playbooks) are in YAML. This is like executable documentation - kind of like a readme containing all the commands you would otherwise be running, all typed out, except instructions won't go out of date because they're actually being executed. | | {{Main|Ansible/Basics}} |
|
| |
|
| Ansible servers require SSH and Python.
| | Summary: |
| | |
| ===Push Based===
| |
| | |
| Ansible is push-based, which means the workflow looks like this:
| |
| | |
| * You make a change to the playbook
| |
| * You run the new playbook
| |
| * Ansible connects to servers and executes modules, changing the server state
| |
| | |
| The <code>ansible-playbook</code> command is the gateway to connecting to the remote server.
| |
| | |
| The push-based approach means you control when things happen to the server, making scaling easier.
| |
| | |
| ===Scaling Down, Too===
| |
| | |
| Ansible obeys Alan Kay’s maxim: “Simple things should be simple; complex things should be possible.”
| |
| | |
| ===Modules===
| |
| | |
| Ansible allows you to execute arbitrary shell commands.
| |
| | |
| Ansible also offers more powerful feature: modules, which perform tasks like installing packages restarting services, or copying config files.
| |
| | |
| Modules are declarative: describe/declare the state you want the server to be in. Example: invoke the user module to ensure there is an account named "deploy" that is in the group "web"
| |
| | |
| <pre>
| |
| user: name=deploy group=web
| |
| </pre>
| |
| | |
| Ansible is idempotent - meaning, if the user already exists, it will do nothing. This makes it safe to run the Ansible script multiple times.
| |
| | |
| ===What You Should Know===
| |
| | |
| List of things you should know how to do before getting started:
| |
| | |
| * connect to remote machine via SSH
| |
| * interact with bash command line shell (pipes and redirects)
| |
| * install packages
| |
| * use sudo command
| |
| * check and set file permissions
| |
| * start/stop services
| |
| * set env vars
| |
| * write scripts (any language)
| |
| | |
| Ansible also uses uses YAML and Jinja and is Python-based.
| |
|
| |
|
| | * 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== | | ==Directory Structure== |
| Line 61: |
Line 22: |
| <pre> | | <pre> |
| playbooks/ | | playbooks/ |
| .vagrant/ <-- directory used by vagrant for keys/machines
| |
| hosts <-- ansible inventory file | | hosts <-- ansible inventory file |
| | .vagrant/ <-- directory used by vagrant for keys/machines (if using vagrant) |
| | 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). You can then connect Ansible with vagrant to manage and set up compute nodes using Ansible.
| | ==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, connect to it via SSH, and (when we're done) shut down the box.
| | {{Main|Ansible/Vagrant}} |
|
| |
|
| ===Connect Ansible to 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). |
|
| |
|
| Once we start up a Vagrant box, we can get Ansible working with the Vagrant boxes by telling Ansible about how to connect to the machines that Vagrant created.
| | 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). |
|
| |
|
| To do this, we create an inventory file in <code>playbooks/hosts</code>. Recall from the [[Vagrant]] page that Vagrant started a Ubuntu server, which was available via IP address 127.0.0.1 on port 2222 (see output of <code>vagrant ssh-config</code> from [https://charlesreid1.com/wiki/Vagrant#Connect_to_Vagrant_Machine Connect to Vagrant Machine] section). We were able to SSH to the machine both using the <code>vagrant ssh</code> command, and a plain <code>ssh</code> command that used the private key in the .vagrant directory.
| | See [[Ansible/Vagrant]] for coverage of both methods when using Vagrant. |
|
| |
|
| These details should all be passed to Ansible via the inventory file:
| | See [[Ansible/Vagrant/Dynamic_Inventory]] for a dynamic inventory script with Vagrant. |
|
| |
|
| <pre>
| | ===Using Ansible with EC2=== |
| $ 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
| | {{Main|Ansible/EC2}} |
| </pre>
| |
|
| |
|
| (Note that the private key file is shown when you run <code>vagrant ssh-config</code> with the vagrant box running.)
| | When using Ansible with Amazon AWS EC2, AWS manages the compute nodes. |
| | |
| '''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
| | 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. |
| </pre>
| |
|
| |
|
| Your vagrant boxes should be up and running with the <code>vagrant up</code> command.
| | See [[Ansible/EC2]] for coverage of both methods (the static inventory script and the dynamic inventory script) when using Amazon EC2. |
|
| |
|
| ===Ping Vagrant box===
| | See [[Ansible/EC2/Dynamic Inventory]] for an example EC2 dynamic inventory script. |
|
| |
|
| 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 Features== |
|
| |
|
| <pre>
| | ===Playbooks=== |
| $ ansible myvagrantbox -i hosts -m ping
| |
| </pre>
| |
|
| |
|
| You should see some output like this:
| | Playbooks are the central feature of Ansible, and are where you tell Ansible what to do on what machines. |
|
| |
|
| <pre>
| | [[Ansible/Playbooks]] - this is where Ansible becomes really powerful |
| 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.
| | [[Ansible/Variables]] - defining and using variables to remove complexity |
|
| |
|
| 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.
| | ===Hosts=== |
|
| |
|
| ===Use a config file===
| | Ansible host files tell Ansible how to work with host machines. Ansible can also interact programmatically with hosts. |
|
| |
|
| The inventory file (hosts) required lots of details, and if we have many nodes to deal with that is not going to scale well.
| | [[Ansible/Hosts]] - configuring machines to work with Ansible |
|
| |
|
| To make it easier to deal with, we can use the <code>ansible.cfg</code> file to set some defaults and variables.
| | ===Roles=== |
|
| |
|
| Where to put ansible.cfg? Here is where Ansible looks:
| | Roles can provide multiple "routes" through a playbook for different types of machines |
|
| |
|
| * <code>ANSIBLE_CONFIG</code> env var (specifies the config file)
| | [[Ansible/Roles]] - defining and using roles to make playbooks more powerful |
| * <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.
| | ===Vaults and Secrets=== |
|
| |
|
| This dir structure allows you to place the config file, plus the playbooks, under version control in a single repo.
| | 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: |
| | |
| ===Example config file===
| |
| | |
| To specify default values for SSH key, username, and inventory filename, use this config file:
| |
| | |
| '''<code>ansible.cfg</code>:'''
| |
|
| |
|
| <pre> | | <pre> |
| [defaults]
| | ansible-playbook site.yml --ask-vault-pass |
| inventory = hosts
| |
| remote_user = vagrant
| |
| private_key_file = .vagrant/machines/default/virtualbox/private_key
| |
| host_key_checking = False
| |
| </pre> | | </pre> |
|
| |
|
| Now we can also simplify the hosts file:
| | [[Ansible/Vaults]] - mechanism for encrypting and decrypting secrets |
| | |
| '''<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. 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 <code>command</code> module to run arbitrary commands on the vagrant machines that ansible is managing.
| |
| | |
| To run the uptime command on our vagrant box:
| |
| | |
| <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>
| |
| | |
| Note that '''this 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 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>.
| |
| | |
| Finally, restart Nginx as follows:
| |
| | |
| <pre>
| |
| $ ansible myvagrantbox -b -m service -a "name=nginx state=restarted"
| |
| </pre>
| |
|
| |
|
| =Flags= | | =Flags= |
|
| |
|
| | | {{AnsibleFlag}} |
| [[Category:Web Server]]
| |
| [[Category:Nginx]]
| |
| [[Category:Ansible]]
| |
| [[Category:Infrastructure]]
| |
| [[Category:Python]]
| |
| [[Category:HTTPS]]
| |
| [[Category:SSL]]
| |
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/BasicsSummary:
- 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
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/EC2When 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
