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

@@ Line 1: / Line 1: @@
-=Notes=
+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 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==
-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 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
-Ansible is push-based, which means the workflow looks like this:
+==Directory Structure==
+The basic directory structure we'll use with Ansible is to create a <code>playbooks</code> directory to hold everything:
+<pre>
+playbooks/
+    hosts       <-- ansible inventory file
+    .vagrant/   <-- directory used by vagrant for keys/machines (if using vagrant)
+    playbook.yml
+</pre>
+See [[Ansible/Directory Layout]] for a much more detailed discussion.
+==Using Ansible==
-* You make a change to the playbook
+===Using Ansible Locally with Vagrant===
-* 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.
+{{Main|Ansible/Vagrant}}
-The push-based approach means you control when things happen to the server, making scaling easier.
+[[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).
-===Scaling Down, Too===
+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).
-Ansible obeys Alan Kay’s maxim: “Simple things should be simple; complex things should be possible.”
+See [[Ansible/Vagrant]] for coverage of both methods when using Vagrant.
-===Modules===
+See [[Ansible/Vagrant/Dynamic_Inventory]] for a dynamic inventory script with Vagrant.
-Ansible allows you to execute arbitrary shell commands.
+===Using Ansible with EC2===
-Ansible also offers more powerful feature: modules, which perform tasks like installing packages restarting services, or copying config files.
+{{Main|Ansible/EC2}}
-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"
+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.
-user: name=deploy group=web
-</pre>
+See [[Ansible/EC2]] for coverage of both methods (the static inventory script and the dynamic inventory script) when using Amazon EC2.
-Ansible is idempotent - meaning, if the user already exists, it will do nothing. This makes it safe to run the Ansible script multiple times.
+See [[Ansible/EC2/Dynamic Inventory]] for an example EC2 dynamic inventory script.
-===What You Should Know===
+==Ansible Features==
-List of things you should know how to do before getting started:
+===Playbooks===
-* connect to remote machine via SSH
+Playbooks are the central feature of Ansible, and are where you tell Ansible what to do on what machines.
-* 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/Playbooks]] - this is where Ansible becomes really powerful
+[[Ansible/Variables]] - defining and using variables to remove complexity
-==Directory Structure==
+===Hosts===
-The basic directory structure we'll use with Ansible is:
+Ansible host files tell Ansible how to work with host machines. Ansible can also interact programmatically with hosts.
-<pre>
+[[Ansible/Hosts]] - configuring machines to work with Ansible
-playbook/
-    hosts/
-        ...ansible inventory files...
-    ...ansible files...
+===Roles===
-    ...vagrant files in .vagrant directory...
+Roles can provide multiple "routes" through a playbook for different types of machines
-</pre>
-==Using Ansible Locally with Vagrant==
+[[Ansible/Roles]] - defining and using roles to make playbooks more powerful
-[[Vagrant]] allows you to set up virtual machines using VirtualBox, and manage/set them up using Ansible.
+===Vaults and Secrets===
-See [[Vagrant]] page for how to get a Vagrant box set up, running, and listening for SSH connections.
+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:
-From here, we can connect Ansible with Vagrant by telling Ansible about how to connect to the machines that Vagrant created.
+<pre>
+ansible-playbook site.yml --ask-vault-pass
+</pre>
-To do this, we create an inventory file in
+[[Ansible/Vaults]] - mechanism for encrypting and decrypting secrets
 =Flags=
-[[Category:Data Engineering]]
+{{AnsibleFlag}}
-[[Category:DevOps]]
-[[Category:Ansible]]
-[[Category:Infrastructure]]
-[[Category:AWS]]

Ansible: Difference between revisions

From charlesreid1