Category: Cloud

This tutorial is adapted from the Web Age course Ansible Configuration and Administration.

1.1 Control and Managed Nodes

Control Node – It is a system where Ansible is installed. It is used to execute ansible commands.  One control node can configure many managed nodes.

Managed Node-  It is one of the systems being configured by Ansible. It must be accessible via SSH (secure shell).

1.2 Preparing the Control Node

• Install Ansible
• Create an Ansible project directory:

mkdir ansible-control

cd ansible-control

• Create setup files in directory:

cfg – Ansible Configuration

ini – Holds inventory (list of managed nodes)

• Ansible commands can now be run from the project directory

1.3 Installing Ansible

• Ansible runs under Linux/Mac OS
• Typical installation Instructions (for Ubuntu):

sudo apt update

sudo apt install software-properties-common

sudo add-apt-repository --yes --update ppa:ansible/ansible

sudo apt install ansible

• Ansible can also be installed with Python’s “pip” utility:

pip3 install ansible

• Verifying installation:

ansible –version

For more installation information/options see the official documenation here: https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html

 

1.4 Ansible on Windows

On Windows Ansible can be installed:

• Under CygWin
• Under the Windows Subsystem for Linux (WSSL)

1.5 ansible.cfg

• Ansible is configured in the following file which contains many commented out example settings with descriptions of their use:

\etc\ansible\ansible.cfg

• Placing an ansible.cfg file in the root of your Ansible project allows you to override existing configuration settings

~\ansible-project\ansible.cfg

• This common setting allows Ansible to get its inventory list from the named file:

[defaults]

inventory = hosts.ini

1.6 hosts.ini

• Hosts.ini (or just hosts) is a file that Ansible looks at to get a list of the hosts you are planning to manage.
• A global version of the hosts file exists at the following location:

\etc\ansible\hosts

• A project-local version of the file, that lists just the hows being managed by the project, is often created in the project root directory.

~\ansible-project\hosts.ini

• The ansible.cfg is then configured to point Ansible at the local version:

[defaults]

inventory = hosts.ini

1.7 Preparing Managed Nodes

• The purpose behind Ansible is to connect to and configure servers(hosts) remotely. To do this it needs to be able to connect to the remote server via ssh (secure shell).
• For each managed node:
  • Test for SSH access to the Managed Node from the Control Node

ssh user-name@{managed-node-id}

(verifies user/password access)

ssh {managed-node-id}

(verifies public/private key access)

• If needed – copy the control node’s public key to the managed node

 

1.8 Creating Control Node Public/Private Key

• Ansible uses SSH (secure shell) to access and manage hosts.
• SSH requires the Ansible control node (the machine where ansible commands will be run) to have a key-pair. The public key of the pair will need to be copied to the host you need to ssh into.
• The following command is executed to create the key-pair:

ssh-keygen -t rsa

• The command saves key files into the ~/.ssh directory:

is_rsa   - the private key

Id_rsa.pub   - the public key

 

1.9 Copying Control Node Public Key to Managed Node

• The public key is copied into the remote host (the one you want to ssh into) using a command like this:

ssh-copy-id vagrant@192.168.60.4

• During the copy, you will be prompted to provide the password for the user on the remote machine.
• Once this is done you will be able to:
  • SSH into the remote machine (i.e. ssh vagrant@192.168.60.4 )
  • Use Ansible to connect to and configure the remote machine

 

1.10 The “ansible” Command

• The ansible command is used to execute ad-hoc commands

ansible [pattern] -m [module] -a "[module options]"

• Given this as the hosts.ini file:

192.168.60.3

[app]

192.168.60.4

192.168.60.5

• [pattern] could be

192.168.60.4 – individual host

all – all hosts in the file

app – just the hosts under the ‘app’ group

 

1.11 Other Ad-Hoc Commands

• Ping the Managed Nodes:

ansible app -m ping -u vagrant

• Check Memory:

ansible multi -a "free -m"

• Get Server Details

ansible db -m setup

1.12 Modules and Options

• The ‘ansible’ command takes as parameters a module and options related to that module
• When no module is specified it defaults to the ‘command’ module, so the following are equivalent:

ansible all -a "hostname"

ansible all -m command -a "hostname"

• The -a options for the command module specify the command you wish to execute.

ansible all -a "date" - Executes the 'date' cmd

ansible all -a "pwd"  - Executes the 'pwd' cmd

• A list of Ansible modules can be found here:

https://docs.ansible.com/ansible/2.9/modules/list_of_all_modules.html

1.13 Modules

• Ansible modules are used in playbooks and ad-hoc commands.
• Some module examples include:
  • ping – pings the host
  • yum, apt – install packages via yum or apt
  • user – create and manage users
  • service – start/stop services on a managed node(s)
  • copy – copy files to/from host
  • setup – get host variables/settings
  • …
• For more on how modules work see:

https://docs.ansible.com/ansible/latest/user_guide/modules_intro.html

1.14 Playbooks

Playbooks group the tasks required to install and configure applications into a single executable script.

• Example:

# playbook01.yml

- hosts: web

  become: 'yes'

  tasks:

    - name: Update the package cache

      apt:

        update_cache: true

    - name: Install the nginx package

      apt:

        name: nginx

        state: present

 

• The playbook is executed with the ansible-playbook command:

ansible-playbook playbook01.yml

Summary

In this tutorial,  we covered:

• Control and Managed Nodes
• Preparing the Control Node
• Installing Ansible
• cfg
• ini
• Preparing Managed Nodes
• Public/Private Key Access
• Ad-Hoc commands
• Modules
• Playbooks

This tutorial is adapted from the Web Age course  Automation with Terraform and AWS Elastic Kubernetes Service Training.

What is Terraform?

Terraform is an agnostic provisioner, written in GO by Hashicorp to provision, change, and version infrastructure resources and objects on a variety of platforms. It is designed for repeatable, automated templated provisioning by teams. It works with popular service providers such as AWS, Azure, Google Cloud Platform and so much more.  It can do low-level components like Virtual Machines or high-level components like SaaS features. It is extended via Providers which can be official or they can be community created. It works well as a builder of infrastructure but needs other tools for sophisticated Configuration Management (like Ansible) or for Image Management (like Packer). 

Key Features of Terraform

• Infrastructure as Code via Templates
• Automation via single command execution
• Extensibility via Providers
• State Consistency via local or remote state files
• Reusability via Modules
• Preview Changes before they are executed
• Idempotency
• Parallelization of Operations
• Dependency Management

A Sample Terraform Workflow

1. Write a Terraform file (.tf) that “declares” your desired infrastructure
2. terraform init in order to have Terraform scan your local directory, and download your Providers (like AWS or Azure)

3. terraform plan to have Terraform show you what it is going to do

4. terraform apply to have Terraform execute and launch resources based on what it showed you in the planning stages

5. terraform destroy to have Terraform destroy and move any infrastructure once you are done. 

A Sample Terraform ec2.tf file

provider “aws” {

        region = “us-east-2”

}

resource “aws_instance” “example” {

  ami           = “ami-0c55b159cbfafe1f0”

  instance_type = “t2.micro”

}

What are Providers?

Providers are plugins that Terraform uses to manage platforms like AWS, Azure, GCP, etc. The AWS Provider allows us to call the AWS API via Terraform and create AWS objects like EC2 instances and Load Balancers.  Providers (the code itself) is downloaded when we run terraform init  in a directory the first time.  Subsequent “init” commands will update the plugin, but only if it the provider version is not pinned and there is an update. Provider code is separate from main Terraform and is maintained separately and deployed independently.

What Providers are currently supported?

• https://registry.terraform.io/ for the full list
• plus you can run your own private registry!

Some considerations when comparing other IaC Tools

• Configuration management versus image management versus provisioning
• Mutable infrastructure versus immutable infrastructure (Arch Model)
• Procedural language versus declarative language (Language)
• Centralized server versus decentralized servers (Centralization)
• Agent’ed (local client) versus agentless (no local client) – (Management)
• Large community versus small community (Adoption)
• Time when first released (Maturity)
• Integration with other tools (Interoperability)

The IaC Tools Communities as of May 2019

How does Terraform compare with other IaC tools?

 

Maturity of IaC Tools

 

Most Common IaC Tools and their use

Installing Terraform – The typical process

Set up or create your Provider account and/or authentication

• Example – AWS IAM user, AWS CLI profile, or EC2 assigned role
• Example – Artifactory Account with API Key

Install Terraform

• homebrew, chocolatey, apt, yum, dnf, snap, etc
• manually via downloads page at https://www.terraform.io/downloads.html
  1. Written in Go; it runs pretty much anywhere it is compiled for
  2. Windows, MacOS, Linux, Solaris, BSD
  3. make sure to check permissions on any Linux/Unix
  4. make sure it is in your PATH
• terraform version  to verify installation
• Move on to creating files, init, plan, and apply

Summary

In this tutorial, we learnt about the fundamentals of Terraform.