Repository provides content to support Ansible meetup run in London in July 2019 to talk about Ansible, Continuous Integration & Deployment
CI/CD approach has been built with a gitlab stack as it is an easy solution to deploy on premise. Gitlab server stack is available to use with docker-compose
. If required a more complete repository is available on github
Even if all configuration management use eos_config
role from ansible, idea is not to detail how it works in detail. If you want more information, you can find some how-tos (original github) and on ansible documentation
To support demo, following network topology is used by Ansible
- Management network:
10.255.0.0/24
- Underlay network block:
172.16.0.0/24
(with/31
point to point connection) - Customer Vlans: vid
100
/10.100.0.0/24
- vid200
/10.200.0.0/24
Repository comes with a set of playbooks:
pb.configure.init.yml
: Playbook to load initial configuration on all EOS devicespb.configure.fabric.yml
: Create configuration files to deploy using eitherpb.configure.deploy.yml
orpb.configure.deploy.intended.yml
pb.configure.deploy.intended.yml
: Playbook to deploy intended configuration to devices using intended method.pb.configure.deploy.yml
: Playbook to deploy intended configuration to devices. Use a add/remove approach.pb.status.bgp.yml
: Playbook to check if all BGP peers are UP.pb.status.ldp.yml
: Playbook to collect LLDP neighbors.
As running in inteneded way, new elements are added and non expected configurations are removed.
Inventory is a static one using ini
format listing all devices and credentials to connect:
[spine]
spine01 ansible_host=10.255.0.100
spine02 ansible_host=10.255.0.101
[leaf]
leaf01 ansible_host=10.255.0.102
leaf02 ansible_host=10.255.0.103
[all:vars]
ansible_user='ansible'
ansible_ssh_pass='ansible'
Data for every devices are stored in a JSON
file per host under host_vars. In this demo, we are not using high level abastraction to represent topology and we focus on ansible and CI/CD implementation.
Below is a JSON snippet from leaf01
:
{
"hostname": "leaf01",
"interfaces": {
"physical": {
"ethernet 1": {
"key": "ethernet 1",
"ip_address": {
"v4": {
"address": "172.16.0.1",
"netmask": 31
}
},
"description": "to spine01 -- et1",
"role": "ip_address",
"mtu": 9200,
"speed": "auto",
"state": "enable"
}
}
}
}
All configuration are managed in some roles and use JINJA2 templates with more or less complexity.
Continuous Integration process is based on [gitlab-ci] as it is a good option to house your own git server with a complete set of features.
Workflow implements a multi-stages approach :
checks
: Stage to validate ansible code qualitybuild
: Create configuration files shared across all other stagesstaging
: Make pre-flight tests. In this demo, it is mainly to collect diff against production and batfish validation. But can also be used to spin-up a lab environment to validatedeploy
: Apply configuration to network topology.post_deployment
: Run post-flight tests to ensure network is running as expecting.
All this stages run at different time in the workflow. Below is result of a merge request into master:
- An introduction to CI/CD best practices
- Continuous Integration using Jenkins
- Experience with Network Automation at Dyn / NANOG 67
- Ansible modules for EOS
- How-to documents and lab for Ansible with EOS
- CI/CD use cases by Michael Kashin
- How to use Ansible & Gitlab-CI to create IaC
Project is published under BSD License.
Please open an issue on Github this is the fastest way to get an answer.
Contributing pull requests are gladly welcomed for this repository. If you are planning a big change, please start a discussion first to make sure we’ll be able to merge it.