[195462] in North American Network Operators' Group
Re: DevOps workflow for networking
daemon@ATHENA.MIT.EDU (Raymond Burkholder)
Thu Aug 10 12:42:43 2017
X-Original-To: nanog@nanog.org
X-OneUnified-MailScanner-From: ray@oneunified.net
From: Raymond Burkholder <ray@oneunified.net>
In-Reply-To: <CALb2afN1Dh3O7OeFQt5ZteSi+T1JS_Bx_47=ve=vhAjmEjpf8w@mail.gmail.com>
Date: Thu, 10 Aug 2017 13:41:26 -0300
To: Kasper Adel <karim.adel@gmail.com>
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
some observations below:
> On 9 Aug 2017, at 21:52, Kasper Adel <karim.adel@gmail.com> wrote:
>=20
> 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 la=
yers of abstraction as knowledge and experience is gained.
>=20
> I am curious to ask what everyone is the community is doing? sorry for su=
ch
> a long and broad question.
the brief version: we are working towards integrating a SaltStack with Nap=
alm management and orchestration solution.
>=20
> 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 sim=
ply by knowing the mac address and then pxebooting the device. The operati=
ng system is installed, auto - reboote. It then automatically gets its tot=
al configuration applied , again automatically, from a Salt server.
Our operating environment uses Debian. And by incorporating the auto insta=
llation of Quagga/FRR, Openvswitch, KVM/Qemu, and LXC into the appropriate =
devices, it is possible to build a homogenous server/router/switch/virtuali=
zation solution with certain devices picking up varying weights of those ro=
les.
The people on this list who are running high bandwidth networks, may not se=
e this a much of a benefit, but for smaller operators, I thinks there is va=
lue.
But then again, when something like Napalm is incorporated into the mix, th=
en automation of the =E2=80=98big iron=E2=80=99 becomes part of the overall=
solution. I came across a CloudFlare slide deck which shows their perspec=
tive for management, implementation, and orchestration. https://ripe72.rip=
e.net/presentations/58-RIPE72-Network-Automation-with-Salt-and-NAPALM-Mirce=
a-Ulinic-CloudFlare.pdf
And SaltStack has a proxy minion, which enables it to talk to cli based dev=
ices.
>=20
> Wanted to ask and see what approaches the many different teams here are
> taking!
>=20
> We are going to start working from a GitLab based workflow.
Salt uses generic =E2=80=98state=E2=80=99 files which are completed with de=
vice specific settings from =E2=80=98pillar=E2=80=99 files. Both of which =
can be version controlled in git.
>=20
> Projects are created, issues entered and developed with a gitflow branchi=
ng
> strategy.
>=20
> GitLab CI pipelines run package loadings and run tests inside a lab.
I not affiliated with SaltStack, just a happy user. Having said that, vari=
ous dev/test/prod scenarios can be implemented. With orchestrated work flo=
ws and provisioning processes based upon the level of sophistication requir=
ed.
>=20
> 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 incorporat=
e Python as needed.
>=20
> For unit testing we typically use python libraries to open transactions to
> do the service modifications (along with functional tests) against physic=
al
> lab devices.
Napalm may get you that next level of sophistication where configs can be d=
iff=E2=80=99d before roll-out.
>=20
> For our prod deployment we leverage 'push on green' and gating to push
> package changes to prod devices.
Which can be orchestrated.
>=20
> Thanks
Raymond Burkholder
https://blog.raymond.burkholder.net
--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
