Infrastructure as Code and DevOps for Network Engineers

Transcript

1. Infrastructure as Code and DevOps for Network Engineers Chris Gascoigne cgascoig@cisco.com
3. • Systems/automation teams look at network teams and think “we could do that better” Networking is being disrupted "Ugh, can't anybody in this town take the law into their own hands?" (and in some ways, they’re right!)
4. • Applying the same tools, processes and workflows across application management, server management, network management “Network Programmability” isn’t (just) about programming "So mono means one, and rail means rail ...and that concludes our intensive three week course."
5. • Today • Canonical configuration on individual devices • Many touch points for configuration changes • Difficult rollback • Configuration Management • Centrally define desired state/configuration of all devices or subsets of devices Configuration Management
6. Configuration Management Tools
7. Reporting GUI Workflows Admin & Security Compute Node DISTRIBUTED AGENTS CENTRALISED MANAGEMENT SERVER CLOUD-BASED REPOSITORY OF PRE-BUILT SOLUTIONS Puppet Forge Puppet Master Agent 3RD PARTY INTEGRATION Monitoring Cisco Switch/Router Agent Puppet Overview
8. Puppet Agent on Open NX-OS 8 Puppet Master Server Native Linux Service /etc/init.d/puppet.d NX-OS Cisco Puppet Agent NX-API Cisco Puppet Module(Incl Utility GEMs) Linux Software Repository Server Yum/RPM install puppet.rpm • Cisco Puppet Agent RPM package on Puppetforge and source on GitHub • Install Cisco Puppet Module on Puppet Master • Yum install Puppet Agent RPM on switches • Switch Agent periodically will poll Puppet Master for updated catalog and attempt to converge switch to desired state
9. Demo
10. • Originally developed by Linus Torvalds • Fast • Distributed Version Control System • Repositories • Multiple repositories (e.g. each developer’s laptop, central/shared) • Push/pull changes between repositories Git
11. • Manage workflows • Access Control • Discuss proposed changes Code Review
12. Demo
13. • Software development practice to automatically run unit and integration tests many times per day • Use source code management • Automate builds • Make builds self testing • Keep builds fast • Test in a clone of production • Publicise test results Continuous Integration
14. Continuous Delivery
15. Example Workflow 1. Create local branch 2. Update local copy of Puppet manifest(s) 3. Commit to local git repository (“git commit”) 3. “git push” 4. New branch on GitLab 5. Trigger GitLab CI new commit workflow 6. Automated tests e.g. puppet- lint 7. Results attached to branch 9. Reviews changes and test results, accept merge request 9. Trigger GitLab CI merged workflow 11. GitLab CI workflow deploys new manifest to puppet master 12. At next check in infrastructure updates config GitLab CI 8. Create Merge Request in GitLab