An introduction to Automated Deployments and their relevance in Continuous Delivery. Explains the most important concepts of the Ansible Deployment Automation tool using simple examples.
Developer Data Modeling Mistakes: From Postgres to NoSQL
Introduction to Automated Deployments with Ansible
1. 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 to
Automated Deployments with Ansible
2. 2 COMPANY CONFIDENTIAL – DO NOT DISTRIBUTE #Dynatrace
• Automated Deployments in Continuous Delivery
• Agent-based vs. Agentless Solution Architectures
• Introduction to Ansible
Agenda
3. 3 COMPANY CONFIDENTIAL – DO NOT DISTRIBUTE #Dynatrace
Automated Deployments
in Continuous Delivery
4. 4 COMPANY CONFIDENTIAL – DO NOT DISTRIBUTE #Dynatrace
feature cycle time time
Customer Users
Utmost Goal: Minimize Cycle Time
5. 5 COMPANY CONFIDENTIAL – DO NOT DISTRIBUTE #Dynatrace
feature cycle time time
Customer Users
Utmost Goal: Minimize Cycle Time
minimize
6. 6 COMPANY CONFIDENTIAL – DO NOT DISTRIBUTE #Dynatrace
feature cycle time time
Customer
Utmost Goal: Minimize Cycle Time
This is when you
create value!
minimize
7. 7 COMPANY CONFIDENTIAL – DO NOT DISTRIBUTE #Dynatrace
feature cycle time time
Customer
Utmost Goal: Minimize Cycle Time
You
This is when you
create value!
minimize
8. 8 COMPANY CONFIDENTIAL – DO NOT DISTRIBUTE #Dynatrace
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
9. 9 COMPANY CONFIDENTIAL – DO NOT DISTRIBUTE #Dynatrace
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!
10. 10 COMPANY CONFIDENTIAL – DO NOT DISTRIBUTE #Dynatrace
Agent-based vs. Agentless
Solution Architectures
12. 12 COMPANY CONFIDENTIAL – DO NOT DISTRIBUTE #Dynatrace
Agent-Based Deployments (Chef, Puppet)
13. 13 COMPANY CONFIDENTIAL – DO NOT DISTRIBUTE #Dynatrace
Agent-Based Deployments (Chef, Puppet)
14. 14 COMPANY CONFIDENTIAL – DO NOT DISTRIBUTE #Dynatrace
Agent-Based Deployments (Chef, Puppet)
15. 15 COMPANY CONFIDENTIAL – DO NOT DISTRIBUTE #Dynatrace
» 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
Agent-Based Deployments (Chef, Puppet)
22. 22 COMPANY CONFIDENTIAL – DO NOT DISTRIBUTE #Dynatrace
» 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
27. 27 COMPANY CONFIDENTIAL – DO NOT DISTRIBUTE #Dynatrace
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
28. 28 COMPANY CONFIDENTIAL – DO NOT DISTRIBUTE #Dynatrace
Ansible Concepts: Inventories
# production.ini
[web]
web[0-1].example.com
[frontends]
frontend.example.com
[backends]
backend.example.com
Group
Host
30. 30 COMPANY CONFIDENTIAL – DO NOT DISTRIBUTE #Dynatrace
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
31. 31 COMPANY CONFIDENTIAL – DO NOT DISTRIBUTE #Dynatrace
--- # 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
Ansible Concepts: Playbooks
Play
Module
33. 33 COMPANY CONFIDENTIAL – DO NOT DISTRIBUTE #Dynatrace
--- # variables.yml
apache_conf_home: /etc/apache2/conf.d
Ansible Concepts: Playbooks
34. 34 COMPANY CONFIDENTIAL – DO NOT DISTRIBUTE #Dynatrace
--- # playbook.yml
- include: appservers.yml
- include: dbservers.yml
- include: webservers.yml
Ansible Concepts: Playbooks
Includes multiple plays
into a single playbook
35. 35 COMPANY CONFIDENTIAL – DO NOT DISTRIBUTE #Dynatrace
Ansible Concepts: Playbooks
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!
39. 39 COMPANY CONFIDENTIAL – DO NOT DISTRIBUTE #Dynatrace
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
40. 40 COMPANY CONFIDENTIAL – DO NOT DISTRIBUTE #Dynatrace
Ansible Concepts: Playbooks » Roles
Reusing Roles in a Play
--- # webservers.yml
- hosts: web
roles:
- { role: common }
- { role: apache2 }
remote_user: deploy
sudo: yes
Cycle time is the most relevant metric in the software delivery process.
“How long would it take your organization to deploy a change that involves just one single line of code?” Mary Poppendieck
Cycle time is the most relevant metric in the software delivery process.
“How long would it take your organization to deploy a change that involves just one single line of code?” Mary Poppendieck
Cycle time is the most relevant metric in the software delivery process.
“How long would it take your organization to deploy a change that involves just one single line of code?” Mary Poppendieck
Cycle time is the most relevant metric in the software delivery process.
“How long would it take your organization to deploy a change that involves just one single line of code?” Mary Poppendieck
Doubtlessly, automation if of high relevance in Continuous Delivery...
Speaking of deployments...
Note: terms “agent” and “client” are used interchangeably
Note: terms “agent” and “client” are used interchangeably
Note: terms “agent” and “client” are used interchangeably
Ad-hoc commands are a great way to test commands on the command line, however, for real server orchestration, there’s a much more powerful concept: Ansible Playbooks.
Ad-hoc commands are a great way to test commands on the command line, however, for real server orchestration, there’s a much more powerful concept: Ansible Playbooks.
ad “-i inventory”: if not specified, will assume an inventory file in /etc/ansible/hosts
Everything you see here is executed in order.
ad “play”: A play maps a group of hosts to a set of tasks. By composing a playbook of multiple plays, it is possible to orchestrate multi-server deployments: run certain tasks on the group of webservers, then some tasks on the group of dbservers, then some more commands back on the webservers group, etc.