Arista: DevOps for Network Engineers

Conﬁdential. Copyright © Arista 2016. All rights reserved.
Ansible Integration!
[ a simple, elegant approach to conﬁguration management ]
1
+

Ansible Background
•  Goal: simplicity and ease of use
•  Playbooks written in easy-to-read YAML
•  Core code written in Python
•  Modules can be written in any language you like
•  Agent-less architecture (no client daemon)
•  Tower: Operationalize Ansible
•  Idempotency
•  Community-driven (1300 >> 1)

3
A New Solution...!
[ modules built right into Ansible 2.1 ]

Ansible Modules
500+ built-in modules including:
apt, yum, copy, command, cron, dns, docker,
easy_install, ec2 (amazon modules), file,
filesystem, find, git, known_hosts, mysql,
mongodb, nagios, npm, openstack, rax
(rackspace) pip, shell, snmp_facts…
New network modules in Ansible 2.1
•  eos_template
•  eos_command
•  eos_eapi
•  eos_config
Sample options for the yum module

eos_* Core Modules
[ New in Ansible 2.1+ ]
Advantages
●  No third-party libraries needed
●  No additional config or client running on the switch
●  Leverages eAPI/CLI(SSH) connection
●  Work directly with running-configuration
●  Easy to use/understand
●  Offline-mode (generate configuration lines)

6
Conﬁguration Management!
[ manage EOS conﬁguration with eos_template]

Ansible 101 - Identify Templates
leaf-bleaf-a
vlan
2

name
production

vlan
3

name
app

interface
Ethernet1

description
[BGP]Spine1

no
switchport

ip
address
10.1.1.1/31

interface
Ethernet2

description
[BGP]Spine2

no
switchport

ip
address
10.1.2.1/31

vlan
2

name
production

vlan
3

name
app

interface
Ethernet1

description
[BGP]Spine1

no
switchport

ip
address
10.1.1.3/31

interface
Ethernet2

description
[BGP]Spine2

no
switchport

ip
address
10.1.2.3/31

Vlan template
Ethernet
Interface
Template

Ansible 101 – Create a Data Model
leaf-a
vlan
2

name
production

vlan
3

name
app

interface
Ethernet1

description
[BGP]Spine1

no
switchport

ip
address
10.1.1.1/31

interface
Ethernet2

description
[BGP]Spine2

no
switchport

ip
address
10.1.2.1/31

vlan:

vlanid:
2

name:
production

interface:

name:
Ethernet1

description:
[BGP]Spine1

address:
10.1.1.1/31

Ansible 101 – Create Vlan Jinja Template
leaf-a
vlan
2

name
production

vlan
3

name
app

interface
Ethernet1

description
[BGP]Spine1

no
switchport

ip
address
10.1.1.1/31

interface
Ethernet2

description
[BGP]Spine2

no
switchport

ip
address
10.1.2.1/31

vlans:

-‐
vlanid:
2

name:
production

-‐
vlanid:
3

name:
app

{%
for
vlan
in
vlans
%}

vlan
{{
vlan.vlanid
}}

name
{{
vlan.name
}}

{%
endfor
%}

Jinja Template [ vlans.j2 ]

Ansible 101 – Create Eth Jinja Template
leaf-a
vlan
2

name
production

vlan
3

name
app

interface
Ethernet1

description
[BGP]Spine1

no
switchport

ip
address
10.1.1.1/31

interface
Ethernet2

description
[BGP]Spine2

no
switchport

ip
address
10.1.2.1/31

interfaces:

-‐
name:
Ethernet1

description:
[BGP]Spine1

address:
10.1.1.1/31

-‐
name:
Ethernet2

description:
[BGP]Spine2

address:
10.1.2.1/31

{%
for
intf
in
interfaces
%}

interface
{{
intf.name
}}

description
{{
intf.description
}}

no
switchport

ip
address
{{
intf.address
}}

{%
endfor
%}

Jinja Template [ intf.j2 ]

host_vars/leaf-b:
interfaces:

-‐
name:
Ethernet1

description:
[BGP]Spine1

address:
10.1.1.2/31

-‐
name:
Ethernet2

description:
[BGP]Spine2

address:
10.1.2.2/31

- hosts: pod1_leafs
tasks:
- name: Configure Arista Vlans
eos_template:
src=vlan.j2
- name: ConfigureArista Eth Interfaces
eos_template:
src=intf.j2
group_vars/pod1_leaf:
vlans:
- vlanid: 2
name: production
- vlanid: 3
name: app
hosts file:
[pod1_leafs]
leaf-a
leaf-b
1. Who runs the play?
4. Gather host vars
5. Run tasks
3. Any group vars?
2. Who’s in that group?
(Fork per player)
Ansible 101 – Running the playbook
host_vars/leaf-a:
interfaces:

-‐
name:
Ethernet1

description:
[BGP]Spine1

address:
10.1.1.1/31

-‐
name:
Ethernet2

description:
[BGP]Spine2

address:
10.1.2.1/31

Eos_Template: How it Works

Conceptually
- host_vars
- group_vars
- sql database
- cmdb
- git repo
- static config
- Ansible Tasks
- Ansible Roles
- Config Blocks
- Jinja Templates
Data
Execution Running
Config
[frequent changes]
[seldom changes]

14
Continuous Compliance!
[ verify EOS state with eos_command ]

Validating System Details
-‐
name:
Gather
Show
Version
From
EOS

eos_command:

commands:

-‐
‘show
version’

register:
showvers

-‐
name:
Check
EOS
System
Parameters

assert:

that:

-‐
“’4.16.6M’
==
showvers['stdout'][0]['version']”

-‐
“’DCS-‐7150S-‐24'
==
showvers['stdout'][0]['modelName’]”

Validating Ephemeral State
-‐
name:
Gather
MLAG
Status
from
EOS

eos_command:

commands:

-‐
‘show
mlag’

register:
showmlag

-‐
name:
Verify
MLAG
State

assert:

that:

-‐
"'active'
==
showmlag['stdout'][0]['state']"

-‐
"'connected'
==
showmlag['stdout'][0]['negStatus']"

-‐
"'up'
==
showmlag['stdout'][0]['peerLinkStatus']"

17
Revision Control!
[ use Git to manage changes ]

Authorize Changes via Pull Requests

Synchronize Changes in Tower
•  Tower syncs with Git repo
•  All playbooks
automatically imported
•  Single source of truth

20
Ansible Roles!
[ reusable, ﬂexible implementation via roles]

•  Package similar templates/tasks
•  Create flexible and dynamic templates/tasks
•  Create reusable code
•  Easily distribute and manage template/task changes
Use Ansible Roles to:

Sample Roles from Arista – Ansible Galaxy
[ Ansible Roles that built on top
of arista.eos ]

Example EOS Role - Varp
[ Abstract Virtual Router Configuration ]
host_vars/veos-‐3

virtual_mac_addr:
"00:1c:73:00:00:99"

varp_interfaces:

-‐
vlanid:
1001

name:
Varp_Vlan1001

interface_addr:
192.168.1.3/24

virtual_addrs:

-‐
192.168.1.1

-‐
vlanid:
1002

name:
Varp_Vlan1002

interface_addr:
192.168.2.3/24

virtual_addrs:

-‐
192.168.2.1

host_vars/veos-‐4

virtual_mac_addr:
"00:1c:73:00:00:99"

varp_interfaces:

-‐
vlanid:
1001

name:
Varp_Vlan1001

interface_addr:
192.168.1.4/24

virtual_addrs:

-‐
192.168.1.1

-‐
vlanid:
1002

name:
Varp_Vlan1002

interface_addr:
192.168.2.4/24

virtual_addrs:

-‐
192.168.2.1

#
Playbook

-‐
hosts:
leafs

roles:

-‐
arista.eos-‐virtual-‐router

#
Run

ansible-‐playbook
-‐i
hosts
play.yml

#
hosts
file

[leafs]

veos-‐3

veos-‐4

Using Roles - Site Configuration
[ Simply include roles ]
#
Run

ansible-‐playbook
-‐i
hosts
site.yml

#
hosts
file

[spine]

veos-‐1

veos-‐2

[leaf]

veos-‐3

veos-‐4

#
Playbook
site.yml

-‐
include:
spine.yaml

-‐
include:
leaf.yaml

#
Playbook
spine.yml

-‐
hosts:
spine

gather_facts:
no

roles:

-‐
arista.eos-‐system

-‐
arista.eos-‐interfaces

-‐
arista.eos-‐bridging

-‐
arista.eos-‐ipv4

-‐
arista.eos-‐route-‐control

-‐
arista.eos-‐bgp

#
Playbook
leaf.yml

-‐
hosts:
leaf

gather_facts:
no

roles:

-‐
arista.eos-‐system

-‐
arista.eos-‐interfaces

-‐
arista.eos-‐bridging

-‐
arista.eos-‐ipv4

-‐
arista.eos-‐route-‐control

-‐
arista.eos-‐bgp

-‐
arista.eos-‐mlag

-‐
arista.eos-‐virtual-‐router

Sample Demo
[ Zero Touch into Tower ]
https://youtu.be/VB29kjSOp7E
Setup
1.  Spine/leaf in bowtie
2.  All nodes in ZTP mode
3.  Nodes statically +
dynamically identified by
ZTPServer
4.  Nodes get base config:
a.  hostname
b.  mgmt ip
c.  eAPI enabled
5.  Nodes register themselves
with Tower
6.  Run Job Template in
Tower to provision nodes.

Getting Started
Main Ansible Documentation
Ask about our Ravello Blueprint
Arista + Ansible 2.1 Quickstart
YouTube Tutorials
Ask for Help - ansible-dev@arista.com

27
Thanks!

Arista: DevOps for Network Engineers

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Arista: DevOps for Network Engineers

Semelhante a Arista: DevOps for Network Engineers (20)

Último

Último (20)

Arista: DevOps for Network Engineers