ansible a tool for dev ops
TRANSCRIPT
ANSIBLEA TOOL FOR DEV/OPS
SESSION OBJECTIVESObjectives
Present Ansible, a popular tool used in Dev/Ops contextThe needs to automate tasks across distributed systemsTypical needsAnsible use cases for managing Openstack
WHAT IS ANSIBLE
WHAT IS ANSIBLEAnsible is a free software platform for configuring and managingcomputers.The platform was created by Michael DeHaan, he is the Cobbler authoras well.
THE NEED FOR AUTOMATION
TYPICAL NEEDSAs a developer/tester: during dev and test phase.
Safely Do repetitive configurations tasks on a set of VMs implementing a multi-tier clusterProvision ssh public keys of team members on N freshly deployed nodes during dev phaseAutomate a documented complex installation sequence – BTW why writing such a document ? etc
As a Sysadmin/SysopsAutomate remote scripting of many day to day tasksCheck and maintain configuration on systems, can be coupled with a revision management tool
As a Service Delivery team: efficiencyEfficient deployment of complex solutions with easily injecting customers or deal specific configuration parametersAvoid restarting from start when you hit an errorDo it faster and cheaper and at scale
As <anyone>Be efficient in front of the explosion of the # of entities (servers, VMs, ...) to ‘manage’
THE AVAILABLE TOOLSAND KEY PROPERTIES
The ‘old ways’ we all experimented: is goneDocument the pre-requisites, document the sequence of actions.Keeping the doc up to date and tested is time consuming. Doc is subject to interpretation, ...Shell scriptingHandling errors correctly is hard. Designing them to avoid restart from scratch is even harder
The current way: Configuration management and automation frameworks.Puppet, Chef, Salt, All promote idempotency
Ansible addresses most of the issues at low costEasy to learn and debugOpen source software (with commercial support available)Leaves no “fingerprints” or residue on target systemsPredictable execution / Repeatable / Idempotent Mostly / Parallel operations
Ansible
ANSIBLE BASICS AND KEY CONCEPTS
ANSIBLE ARCHITECTURE AND WORKING MODELAn ‘orchestration engine’ where Ansible SWis installed.No agent required. leverage ssh as defaultsecure transport.Execute playbooks.Predictable – in order executionDesigned to work in push mode to all targethosts in parallel.hosts can be many things:
Any Linux/*Nix systemsnetworking gears running sshdWindows hosts by leverging WinRM and PowerShell(hence no ssh in that case)And more...
THE INVENTORYWHERE THE HOSTS ARE REGISTERED
ABOUT INVENTORIES
Static inventory:A file containing a set of hosts and groups of hosts.Can also contain some host specific settings.Common practice is to name groups per intendedfunction.
Dynamic inventory – hosts and groups fromexternal source via inventory plugin.
From a CMDBFrom a cloud provider (e.g: AWS EC2/Eucalyptus,Rackspace Cloud. OpenStack nova, gce, digital ocean ...)Useful when hosts names are hard to predict or whenmany hosts
More than one inventory and mix of staticand dynamic inventory sources is possible:
One for development, one for staging, one for productionOne for public cloud one for private cloud
EXAMPLE OF A SIMPLE STATIC INVENTORY – NO DB NEEDED
# This is a comment
# localhost refers to the ansible control node
localhost
[webservers]
www1.example.com
www2.example.com
www[10:50].example.com
[dbservers]
db1.example.com
db[a:f].example.com
10.0.1.9 ansible_ssh_port=2222 ansible_ssh_user=admin
[LinuxVMs]
localhost
db1.example.com
www21.example.com
ANSIBLE PLAYBOOKS - THE PLAYSA LIST OF PLAYS TO RUN ON TARGET HOSTS
Playbooks are yaml text files containing a listof plays and run via the ansible-playbook cliPlaybooks can be hierarchical and usestructured directory and file layout.A play maps a set of hosts with “what toexecute” on them
Has a name: descriptive textStart with a section specifying the set of target hosts withthe parameters to access them.May contain variables declaration sectionsContains sections specifying “what to run” on them
A play optionally ‘gather Facts’ and makesthem available as variables. Facts are all theinformation Ansible discovers about a host.Each play is run in sequence and may specifythe account (remote_user) to be used toconnect to the remote hosts, if sudo isneeded, etc
PLAYBOOK EXTRACT – THE FIRST SECTION OF A PLAY
name: This is the PLAY1 title
hosts: webservers # this can be host, groups or complex expr
gather_facts: True # trigger facts discovery about targets
remote_user tester # connect as 'tester' account
sudo: False # whether to run as sudo or not
[...skipped part...] # what to run on the targets – skipped
name: This is the PLAY2 Title
hosts: dbservers:!db1.example.com # exclude a host
gather_facts: False
remote_user: admin # connect as 'admin' account
sudo: True
[...skipped part...] # what to run on the targets – skipped
ANSIBLE PLAYBOOKS – THE TASKSWHAT TO RUN ON TARGET HOSTS
The tasks section describes the list of actionsyou want to execute on the target hostsThe tasks are run in order, one at a time,against all the target hosts in parallel, beforemoving to the next.A task:
Has a name : descriptive textExecutes a module with specific parameters.Reports status [ok, changed, failed, skipping] at runtime
Handlers are tasks triggered at the end ofthe play if a change was madeA is a small program, generallyidempotent and that can be written in anylanguage *.There are modules for many things, see themodule index. You can write your own.Variables and templates leverage jinja2templating engine
module
THE NTP SIMPLE EXAMPLE
name: Setup ntp client
hosts: linuxVMs:!localhost # target hosts
remote_user: tester # connect as ‘tester’ account
sudo: True # and need sudo capability
vars:
time_sources: [ntp2.austin.hp.com, gpsclock0.sdd.hp.com, ntp1.eds.com]
ntp_rpm: ntp
tasks:
name: Install the required time service package
yum: name={{ ntp_rpm }} state=installed
name: Instantiate the ntp.conf from template file
template: src=ntp.conf.j2 dest=/etc/ntp.conf
notify:
restart time server daemon
name: The os are we running on
debug: msg=“this is a {{ ansible_distribution }} {{ ansible_distribution_version }}”
handlers:
name: restart time server daemon
service: name=ntpd state=restarted enabled=yes
ANSIBLE ROLESPARAMETERIZED TASKS FOR SHARING AND REUSE
Rapidly you will need to reuse some tasks, orabstract some consecutive tasks and give ita name.A role is materialized as a set of structuredfiles and may have:
A set of defaults (aka default values)A tasks listhandlersTemplates filesfilesmetavars
This works like an clever include directiveHint: browse the rolesrepository and use the ansible-galaxy cli toget them.Openstack playbooks :
Ansible Galaxy
https://github.com/openstack/openstack-ansible
THE NTP SIMPLE EXAMPLE
name: Setup ntp client
hosts: linuxVMs
# target hosts
remote_user: tester # connect as ‘tester’ account
sudo: True # and need sudo
vars:
other_clocks: [ntp1aus2.hp.net, gpsclock0.sdd.hp.com, ntp1.eds.com]
roles:
{role: ntpclient, time_sources: “{{ other_clocks }}”, }
tasks:
name: The os are we running on
debug: msg=“this is a {{ansible_distribution}} {{ansible_distribution_version }}”
the roles/ntplient sub directory content
roles/ntpclient
├── defaults
│
└── main.yml > content is vars section on previous slide
├── handlers
│
└── main.yml > content is the handler section on previous slide
├── tasks
│
└── main.yml > content is the tasks section on previous slide
ANSIBLE - A LOT MORE TO DISCOVERWE JUST SCRATCHED THE SURFACE
Ansible conditionalsAnsible loopsAnsible-VaultFactsJinja2 filters...
SIMPLE LIVE EXAMPLES
THANK YOUBased on original presentation from :
Philippe Eveque <[email protected]>Adaptation to openstack by :
Jérome Justet <[email protected]>René Ribaud <[email protected]>