DevOps workflow for networking
ray at oneunified.net
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
> 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
> 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.
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
More information about the NANOG