Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Ansible for SDN deployments: benefits and best practives

Ansible for SDN deployments: benefits and best practives
by

Szymon Święcki

on 17 April 2015

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Ansible for SDN deployments: benefits and best practives

and good practices
Ansible
!
CAUTION
automatization in progress...
__________
Ansible
Ansible Getting Started
benefits
for SDN deployments
benefits and best practices
AGENDA
1. Who we are.
2. Why automate?
3. Ansible vs other frameworks.
4. Ansible basics.
5. Good practices.
6. What next?
7. DEMO.
30 Point of Presence
Record ecological achievements
OVH in numbers
Twitter News
Why automate?
repetitive
scalability
easy testing
documentation
fast deploy
management
reduce costs
error prone
Ansible vs BASH
Ansible vs Chef / Puppet
push
agentless
easy
yaml
simple
pull
client/server
time consuming
ruby/dsl
complicated design
communicates over SSH
inventory file
checking connectivity
192.168.1.50
aserver.example.org
bserver.example.org
mail.example.com

[webservers]
foo.example.com
bar.example.com

[dbservers]
one.example.com
two.example.com
three.example.com
[atlanta]
host1
host2

[raleigh]
host2
host3

[southeast:children]
atlanta
raleigh

[southeast:vars]
some_server=foo.bar

[usa:children]
southeast
northeast
deafult auth by ssh key (--private-key)

--ask-pass
--ask-sudo-pass

$ ssh-agent bash
$ ssh-add ~/.ssh/id_rsa
Authorization
$ ansible all -m ping

# as bruce
$ ansible all -m ping -u bruce
# as bruce, sudoing to root
$ ansible all -m ping -u bruce --sudo
# as bruce, sudoing to batman
$ ansible all -m ping -u bruce --sudo --sudo-user batman

$ ansible all -a "/bin/echo OVH_RULES"
Connectivity
adhoc commands
#copy file to atlanta servers
$
ansible atlanta -m copy -a "src=/etc/hosts dest=/tmp/hosts"
#install acme package on all webservers
$
ansible webservers -m yum -a "name=acme state=present"
#add user on all servers
$
ansible all -m user -a "name=foo password=<crypted>"
#deploy webapp
$
ansible webservers -m git -a "repo=git://foo.example.org/repo.git dest=/srv/myapp version=HEAD"
#restart httpd on webservers
$
ansible webservers -m service -a "name=httpd state=restarted" --forks=1
Playbooks
---
- hosts: webservers
vars:
http_port: 80
max_clients: 200
remote_user: root
tasks:
- name: ensure apache is at the latest version
yum: pkg=httpd state=latest
- name: write the apache config file
template: src=/srv/httpd.j2 dest=/etc/httpd.conf
notify:
- restart apache
- name: ensure apache is running (and enable it at boot)
service: name=httpd state=started enabled=yes
handlers:
- name: restart apache
service: name=httpd state=restarted
#running playbook
$ ansible-playbook playbook.yml
Ansible directory structure
production # inventory file prd servers
stage # inventory file stg servers

group_vars/
group1 # assign variables to groups
group2 # ""
host_vars/
hostname1 #specific variables
hostname2 #

site.yml # master playbook
webservers.yml # playbook for webserver tier
dbservers.yml # playbook for dbserver tier

roles/
common/ # this hierarchy represents a "role"
tasks/ #
main.yml # <-- tasks file can include smaller files
handlers/ #
main.yml # <-- handlers file
templates/ # <-- files for use with the template resource
ntp.conf.j2 # <------- templates end in .j2
files/ #
bar.txt # <-- files for use with the copy resource
foo.sh # <-- script files for use with the "script"
vars/ #
main.yml # <-- variables associated with this role
defaults/ #
main.yml # <-- default lower priority variables
meta/ #
main.yml # <-- role dependencies
Good practies
- use vagrant!
- do not reinvent the wheel - use modules
- Keep It Simple Stupid
- Avoid “changed” and “skipping” tasks
- use "hosts" groups in playbook
- local_action and run_once
- use loops!
- use apt-cache
Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
config.vm.box = "ubuntu"
config.vm.provision "ansible" do |ansible|
ansible.playbook = "setup.yml"
ansible.inventory_path = "vagrant-inventory"
ansible.host_key_checking = "false"
end
end
VagrantFile
- name: alter grub file
lineinfile:
dest: /etc/default/grub
regexp: "^GRUB_DEFAULT="
line: 'GRUB_DEFAULT="rootdelay=10"'
- name: alter grub file
shell:
sed -i 's/^GRUB_DEFAULT/..rootdelay=10/' /etc/defaut/grub
BAD
GOOD
- name: ensure postgresql hstore extension is created
sudo: yes
sudo_user: postgres
shell: "psql my_database -c 'CREATE EXTENSION IF NOT EXISTS hstore;'"
- name: ensure postgresql hstore extension is created
sudo: yes
sudo_user: postgres
shell: "psql my_database -c 'CREATE EXTENSION hstore;'"
register:
psql_result

failed_when
: >
psql_result.rc != 0 and ("already exists" not in psql_result.stderr)

changed_when
: "psql_result.rc == 0"
BETTER
Good enough
- authorized_key: user=charlie
key="{{ lookup('file', '/home/
charlie/.ssh/id_rsa.pub') }}"
GOOD
- shell: cat ~/.ssh/id_rsa.pub >>
/home/charlie/.ssh/authorized_keys
BAD
- name: Set up authorized_keys for the deploy user
authorized_key: user=deploy key="{{
item
}}"

with_file:
- public_keys/doe-jane
- public_keys/doe-john
- name: Set up authorized_keys for the jane user
authorized_key: user=deploy key=doe-jane

- name: Set up authorized_keys for the john user
authorized_key: user=deploy key=doe-john
Good enough
Better
- name: Install FastPath requirements
apt: name={{ item }} state=present
update_cache=yes cache_valid_time=3600
with_items:
- ebtables
- libevent-2.0-5
- libnl-3-200

- name: add several package
apt: name={{ item
.name
}} state={{ item
.state
}}
with_items:
- {
name
: 'apache',
state
: 'latest' }
- { name: 'bind9', state: 'absent' }
- { name: 'htop', state: 'present' }
Better
- name: add apache package
apt: name=apache state=latest
- name: remove bind9 package
apt: name=bind9 state=absent
- name: add htop package
apt: name=htop state=present
Good enough
QUESTIONS??
SHOWTIME!
What next?
WHOAMI
---
name:
Szymon Święcki
job: Cloud Administrator at OVH
experience:
- sysadmin
- chef
- ansible
- AWS

- testing via ServerSpec


- continuous integration
Faster
- name: Install FastPath requirements
apt: name={{ item }} state=present
with_items:
- ebtables
- libevent-2.0-5
- libnl-3-200
Good enough
require 'spec_helper'

describe 'quagga process' do
describe service('quagga') do
it { should be_enabled }
it { should be_running }
end

processes = [ 'zebra', 'bgpd', 'watchquagga' ]
processes.each do |p|
describe process("zebra") do
it { should be_running }
end
end

describe 'Linux kernel parameters' do
context linux_kernel_parameter('net.ipv4.conf.all.forwarding') do
its(:value) { should eq 1 }
end
end


quagga process
Service "quagga"
should be enabled
should be running
Package "quagga"

should be installed
Process "zebra"

should be running
Process "zebra"

should be running
Process "zebra"

should be running
Command "/usr/bin/vtysh -c "show daemons""


stdout
should match /zebra bgpd/

Linux kernel parameters
Linux kernel parameter "net.ipv4.conf.all.forwarding"
value

should eq 1

Finished in
0.5637 seconds
(files took 0.25657 seconds to load)
12 examples, 0 failures
Full transcript