DevOps workflow for networking

Thu Aug 10 16:41:26 UTC 2017

some observations below:

> On 9 Aug 2017, at 21:52, Kasper Adel <karim.adel at gmail.com> wrote:
> 
> We are pretty new to those new-age network orchestrators and automation,

There are definitely many options out there.  With a considerable amount of sophisticated.  But fortunately, it is possible to start simple and add layers of abstraction as knowledge and experience is gained.

> 
> I am curious to ask what everyone is the community is doing? sorry for such
> a long and broad question.

the brief version:  we are working towards integrating a SaltStack with Napalm management and orchestration solution.

> 
> What is your workflow? What tools are your teams using? What is working
> what is not? What do you really like and what do you need to improve? How
> mature do you think your process is? etc etc

Things are getting started.  I am able to automate the build of servers simply by knowing the mac address and then pxebooting the device.  The operating system is installed, auto - reboote.  It then automatically gets its total configuration applied , again automatically, from a Salt server.

Our operating environment uses Debian.  And by incorporating the auto installation of Quagga/FRR, Openvswitch, KVM/Qemu, and LXC into the appropriate devices, it is possible to build a homogenous server/router/switch/virtualization solution with certain devices picking up varying weights of those roles.

The people on this list who are running high bandwidth networks, may not see this a much of a benefit, but for smaller operators, I thinks there is value.

But then again, when something like Napalm is incorporated into the mix, then automation of the ‘big iron’ becomes part of the overall solution.  I came across a CloudFlare slide deck which shows their perspective for management, implementation, and orchestration.  https://ripe72.ripe.net/presentations/58-RIPE72-Network-Automation-with-Salt-and-NAPALM-Mircea-Ulinic-CloudFlare.pdf

And SaltStack has a proxy minion, which enables it to talk to cli based devices.

> 
> Wanted to ask and see what approaches the many different teams here are
> taking!
> 
> We are going to start working from a GitLab based workflow.

Salt uses generic ‘state’ files which are completed with device specific settings from ‘pillar’ files.  Both of which can be version controlled in git.

> 
> Projects are created, issues entered and developed with a gitflow branching
> strategy.
> 
> GitLab CI pipelines run package loadings and run tests inside a lab.

I not affiliated with SaltStack, just a happy user.  Having said that, various dev/test/prod scenarios can be implemented.  With orchestrated work flows and provisioning processes based upon the level of sophistication required.

> 
> Tests are usually python unit tests that are run to do both functional and
> service creation, modification and removal tests.

Rather than re-inventing the wheel, take a look at SaltStack or Ansible and/or Napalm.  All are python based and could probably get you to your target faster than when using Python natively.  When it is necessary to go native python on a hairy integration problem, then it is no problem to incorporate Python as needed.

> 
> For unit testing we typically use python libraries to open transactions to
> do the service modifications (along with functional tests) against physical
> lab devices.

Napalm may get you that next level of sophistication where configs can be diff’d before roll-out.

> 
> For our prod deployment we leverage 'push on green' and gating to push
> package changes to prod devices.

Which can be orchestrated.

> 
> Thanks

Raymond Burkholder
https://blog.raymond.burkholder.net

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.