3. ∗ In the past, IT administrators followed some set of instructions had
to manually deploy and configure on one server and repeat the
same process for multiple servers in a infrastructure . So, this
approach works when you have a minimum number of servers to
manage.
∗ In a large setup having more than hundreds of machines it'll be
difficult to deploy & manage infrastructure/applications.
Why we need to go for Automation Tool??
4. ∗ many applications X many environment = Time X Effort
∗ Over the years, smart system admins looked at the task list and
figured out a way to write scripts that would handle the
repetitive tasks. They built their own junior robot system admin
to do the work for them.
∗ Such robot systems have evolved over period of time as different
configuration management tools.
Why we need to go for Automation Tool??
6. ∗ Automation Tool
∗ Configuration Management Tool
∗ Agentless system
∗ It uses YAML content for defining the automation task. So,
eliminating the need to know any programming languages.
∗ It can manage all the cross platforms in your infrastructure.
∗ It uses openssh for transactions. So, it is secure.
ANSIBLE - INTRODUCTION
8. ∗ Add the ansible repo in the source list,
sudo apt-add-repository ppa:ansible/ansible
∗ Then update the apt repositories, So that we can install a latest
ansible packages.
sudo apt-get update
∗ Install the ansible packages by,
sudo apt-get install ansible
INSTALLATION - Ubuntu
9. ∗ Copy the content of public key of Ansible server and paste it
into your manageable servers authorized_key file.
∗ Secondly, add the remote host details like ipaddress, sshuser
name to the inventory files under some group or single host.
CONFIGURATION
10. ∗ INVENTORY :
Ansible can work multiple system across your infrastructure.
All those machine details (IP address or DNS names )are saved in a
file. That is called as inventory file. Basically, the default path of
the file is /etc/ansible/hosts.
EX: A collection of hosts belonging to the 'webservers' group
[webservers]
alpha.example.org
beta.example.org
TERMS & DEFINITIONS
11. Ex 1: Ungrouped hosts, specify before any group headers.
## 192.168.100.1
## 192.168.100.10
Ex 2: A collection of database servers in the 'dbservers' group
[dbservers]
## db01.intranet.mydomain.net
## db02.intranet.mydomain.net
SAMPLE INVENTORY SNIPPET
12. ∗ AD-HOC COMMANDS :
It’s something that you want to do quickly, instead of saving
that for later use.
EX: ansible -m shell -a "echo hi" all
Here,
m -> Module name
a -> Argument that passed to that module.
all -> It represent to run the command to all hosts which are
placed in hosts file.
Commands
13. Facts are used to describing the variables about the system. This will
help us in conditional checking while execution of tasks. If you want
to see the system variables collected by facts then use,
ansible -m setup all -> This will show all hosts system variables.
Instead of all, you may use which host you want to see.
Facts
14. Set of steps that you want to enforce your remote system.
From playbook, you can deploy complicated applications into
smoothly, instead of using ad-hoc commands.
When we run the same playbook again and again the
infrastructure doesn’t change any state unless changes are need.
This called as idempotent fashion.
Playbook
15. It can control the system resources, services, files, and
packages. There are 1000 more modules are available. We can create
our own custom modules.
Eg:
Service Module -> To handle service stop, start,enable, and
restart Operations.
Git Module -> To checkout the repositories from GIT.
Copy Module -> To copy the file from ansible host to remote host.
Modules
16. Roles
Defaults
Main.yml -> The variables are defined here have the lower
Priority. This variables can easily overwrite.
Vars
Main.yml -> The variables are defined here have high priority.
PLAYBOOK COMPONENTS
17. Files ->List of files that will be pushed to remote hosts.
Handlers
Main.yml -> Definition of ‘notify’ tasks.
Meta
Main.yml -> Metadata about playbook like Author name,
Supported platform, Dependencies required.
PLAYBOOK COMPONENTS
18. Tasks
Main.yml -> What are the steps we need to define in order to
achieve the desired state of the remote hosts. All
those addressed here.
Templates -> It’s like files but configurable. It uses jinga2 language
to obtain all those functions. This component are
mainly used in configuration part of the services.
PLAYBOOK COMPONENTS
19. 1)Install the mysql-server on remote host.
2)Change the Bind-ip address as 0.0.0.0
3)Restart the mysql service.
4)Create the root user and set some password.
5)Create a database DevOps and grant all the permission to
that database to DevOps user.
6)Restore the Backup file from s3 Bucket.
DEMO