Introduction to Automated Deployments with Ansible

1 COMPANY CONFIDENTIAL – DO NOT DISTRIBUTE #Dynatrace

System Architects with DevOps / Security Group Meetup, Vienna

18th December 2014

Martin Etmajer, @metmajer, Technology Strategist @ Dynatrace

Introduction toAutomated Deployments with Ansible


• Automated Deployments in Continuous Delivery

• Agent-based vs. Agentless Solution Architectures

• Introduction to Ansible

Agenda


Automated Deploymentsin Continuous Delivery


feature cycle time time

Customer Users

Utmost Goal: Minimize Cycle Time



Customer Users


minimize



Customer


This is when youcreate value!

minimize



Customer


You

This is when youcreate value!

minimize


The definition of a deployment pipeline,

which is at the heart of Continuous Delivery:

“A deployment pipeline is, in essence, an automated implementation

of your application’s build, deploy, test and release process.”

Jez Humble & Dave Farley in Continuous Delivery

“Use machines for what they’re good at, use people for what they’re good at.”

Dave Farley at PIPELINE Conference 2014 @vimeo.com/96173993

The Role of Automation in Continuous Delivery

continuousdelivery.com

vimeo.com/96173993


Manual deployments:

• are slow and prone to human errors

• are neither repeatable nor reliable

• are not consistent across environments

• are done by a few experts: hinders collaboration

• require extensive documentation: often outdated

The Problem with Manual Deployments

We are just not good at it!


Agent-based vs. AgentlessSolution Architectures


Agent-Based Solutions


Agent-Based Deployments (Chef, Puppet)






» Can be used in client-server or client-only modes

» Client must be installed on each host to be provisioned

» Clients have dependencies

» Not laid out for server orchestration by design

(do something on server A, then on server B, etc.)

» Chef and Puppet are widely considered to have a large entrance

barrier and are complex to use



Agentless Solutions


Agentless Deployments (Ansible)








Ansible


» Written and extensible in Python

» Human- and machine-readable configuration (YAML)

» No boot-strapping required on deployment hosts (SSH)

» Statements are executed in the order they were specified

» Simple, easy to ramp up with (think of new employees!)

» Clear and concise documentation

Ansible


Ansible Concepts:Ad-hoc Commands


Ansible Concepts: Ad-hoc Commands

ansible [-i inventory] <host-pattern> [options]

Examples?

» ansible localhost -m copy –a ‘src=/usr/bin/a dest=/usr/bin/b’

» ansible webserver –a ‘/sbin/reboot’ –f 3

–u deploy ––sudo ––ask–sudo–pass

Module Arguments


Ansible Concepts: Ad-hoc Commands

ansible [-i inventory] <host-pattern> [options]

Examples?

» ansible localhost -m copy –a ‘src=/usr/bin/a dest=/usr/bin/b’

» ansible webserver –a ‘/sbin/reboot’ –f 3

–u deploy ––sudo ––ask–sudo–pass

Processes

User Use sudo

Ask password

interactively


Ansible Concepts:Inventories


Ansible Concepts: Inventories

» Ansible provisions groups of servers at once

» Groups and hosts are stored in inventory files

» An inventory file is expressed in the INI format


Ansible Concepts: Inventories

# production.ini

[web]

web[0-1].example.com

[frontends]

frontend.example.com

[backends]

backend.example.com

GroupHost


Ansible Concepts:Playbooks


Ansible Concepts: Playbooks

ansible-playbook [–i <inventory>] <playbook>

Playbooks

» describe policies your remote systems shall enforce

» consist of variables, tasks, handlers, files and roles

» are expressed in the YAML format


--- # webservers.yml

- hosts: web

vars_files:

- variables.yml

handlers:

- name: reload apache2

service: name=apache2 state=reloaded

tasks:

- name: Install Apache HTTP Server

apt: name=apache2 update_cache=yes

- name: Install Apache Modules

apache2_module: name={{ item }} state=present

with_items:

- proxy

- proxy_httpd

notify: reload apache2


Play

Module


...

- name: Install Apache Configuration

template: >

src=apache-config.conf.j2

dest={{ apache_conf_home }}/myapp

mode=0644

notify: reload apache2

remote_user: deploy

sudo: yes



--- # variables.yml

apache_conf_home: /etc/apache2/conf.d



--- # playbook.yml

- include: appservers.yml

- include: dbservers.yml

- include: webservers.yml


Includes multiple plays

into a single playbook



ansible-playbook –i production.ini webservers.yml

PLAY [web]

******************************************************

TASK: [Install Apache HTTP Server]

************************

changed: [web0.example.com]

changed: [web1.example.com]

...

PLAY RECAP

************************************************************************

web0.example.com : ok=3 changed=3 unreachable=0 failed=0

web1.example.com : ok=3 changed=3 unreachable=0 failed=0

Run!


Ansible Modules Library


Ansible Modules Library

» Cloud: AWS, Azure, DigitalOcean, Docker, Google, OpenStack,...

» Database: MySQL, Postgresql,...

» Packaging: apt, yum, easy_install, npm, homebrew, zypper,...

» Source Control: git, subversion, mercurial,...

» Web Infrastructure: apache2_module, jira,...

» System: mount, selinux, ufw, user,...


Ansible Concepts: Roles (Outlook)


Ansible Concepts: Playbooks » Roles

Roles

» Are the preferred means to organize and reuse related tasks

» Build on the idea of include files to form clean abstractions

» Can be shared and found on Ansible Galaxy

https://galaxy.ansible.com/


Ansible Concepts: Playbooks » Roles

Reusing Roles in a Play

--- # webservers.yml

- hosts: web

roles:

- { role: common }

- { role: apache2 }

remote_user: deploy

sudo: yes
