Introduction

This article is from December 14, 2016 in NetOpsCoding Advent Calendar 2016.

CLI is often used to operate network devices, but it is difficult to handle with CLI program (-_-;)

To make it easier to programmatically, some engineers around Spotify have created a library called'napalm'. (Paramiko base) https://github.com/napalm-automation/napalm

Actual example

This time, I will try to load the config from the Web with the configuration of Junos + CGI + napalm. If you want to hit a command from the Web (for example, add a firewall policy), prepare the following HTML / CGI.

`firewall-policy.html`


<!DOCTYPE html>
<html lang="ja">
<head>
    <meta charset="UTF-8">
    <title></title>
</head>
<body>
<form action="cgi-bin/firewall-policy.py" method="post">
    srcaddress:<input type="text" name="srcaddress">
    srcnetmask:<input type="text" name="srcnetmask">
    destaddress:<input type="text" name="destaddress">
    destnetmask:<input type="text" name="destnetmask">
    applicationname:<input type="text" name="applicationname">
    policy_then:<input type="text" name="policy_then">
    <input type="submit" value="Go">
</form>
</body>
</html>

`firewall-policy.py`


#!/usr/bin/python


##
(srxipaddr, srxuser, srxpasswd)=('192.168.xx.xx', 'xx', 'xx')
##

import cgi
from napalm import get_network_driver

fs = cgi.FieldStorage()

js={}
for key in fs.keys():
  js[key]=fs[key].value

##
# do import stuff
##
candidate_config_template="""
security policies from-zone untrust to-zone untrust policy automation-policy {{
   match {{
       source-address automation-policy-src;
       destination-address automation-policy-dest;
       application {applicationname};
       }}
       then {{
           {policy_then};
   }}
}}
security zones security-zone untrust address-book {{
   address automation-policy-src {srcaddress}/{srcnetmask};
   address automation-policy-dest {destaddress}/{destnetmask};
}}
"""
candidate_config=candidate_config_template.format(**js)

driver = get_network_driver('junos')
device = driver(srxipaddr, srxuser,  srxpasswd)
device.open()
print (candidate_config)
device.load_merge_candidate(config=candidate_config)
print (device.compare_config())
device.commit_config()
device.close()

As a point

--Convert the argument received from the web form to dict (= JSON = YAML) and then apply it to the config template

I wonder if ...

For more information, see below. http://qiita.com/taijijiji/items/a3f21c8b9e7a0d3afdc6 http://www.slideshare.net/JuniperJapan/interop-tokyo-2016junos-automation

Thanks to the wonderful blogs of the pioneers, it ended easily ... (-o-;)

This is a little lonely because it ends up really lightly, so I'd like to consider a more complicated example (-_-;)

What is the approval flow?

As already written, when performing routine work from the Web, the flow of user instructions (in short, arguments) is shown below.

Applicant (= worker)-> Web application-> napalm

However, in this flow

--A person who operates a browser and describes the work contents (applicant) --People who actually perform the work (workers)

There is a restriction that it can not be used unless they are the same, and this becomes a problem in actual operation.

What this means is that in an Enterprise environment where IT operations are audited. There is a restriction that'applicants (application development vendors, etc.)'cannot directly operate the production environment.

So-called Dev and Ops

(reference) http://forza.cocolog-nifty.com/blog/2015/02/itdevops-691f.html http://blogs.itmedia.co.jp/infra/2013/09/devops1devops-7abb.html

In this case, the approver approves the content described by the applicant, and then the worker carries out the work. With ITIL-enabled tools (usually this is the focus of audits), this is fixed as a screen and the work is an attachment.

Encountered with tools from at least two vendors, (-_-;)

Therefore, the realistic flow in this case is as follows.

Applicant-> Work Instructions (Excel, etc.)-> ITIL Tools-> (Workflow)-> Workers
Worker-> Web App-> napalm

In this case, the applicant writes the work order in as much detail as possible, There is a limit to the information that can be explained in Japanese ... While looking at the Amazon screen, I felt like I would send all orders by email.

――Where and when will you deliver it? ――If you can pick it first, will it be shipped separately? ――What is the payment method?

To be honest, it is difficult to tell accurately in one shot. further,

――How many stocks do you have in the first place?

Etc., including checking the contents that cannot be understood without checking with the system, etc. I think it is desirable for applicants to create an application form based on some kind of web application.

So, I think the ideal flow is as follows.

Applicant-> Web application-> Export input contents as JSON
Applicant-> ITIL Tool (JSON attached)-> (Workflow)-> Worker
Worker-> Web App (Import JSON)-> napalm

If this can be achieved, there are the following merits.

--Applicant (Dev): You can create a request form while checking whether the content can be worked by yourself with a web application, reducing the interaction with workers --Worker (Net, Ops): Work is limited to JSON import, no need to operate the actual machine, less interaction with the applicant --Security personnel (Sec (provisional)): Since it is difficult to approve outside the flow, there is no need to worry about how to leave evidence, how to retain evidence (3 years storage, etc.)

I tried to implement the tool

Regarding the above issues, I tried to implement the following tools while making miso in the foreground. https://github.com/tnaganawa/execjson

The screen image of the tool is as follows.

First, the applicant enters the input contents in the Web form for each work to be performed (in the example, adding a firewall policy). Click'export json'when you're done, and the JSON will be exported, which you can pass through the approval flow.

The JSON created is as follows

`sample.json`


{
    "jobapplcode": "", 
    "jobenvcode": "Prod", 
    "joblist": [
        {
            "args": [
                {
                    "applicationname": "junos-vnc", 
                    "destaddress": "192.168.12.11", 
                    "destnetmask": "32", 
                    "policy_then": "permit", 
                    "srcaddress": "192.168.11.11", 
                    "srcnetmask": "32"
                }
            ], 
            "id": "1", 
            "iffail": "stop", 
            "name": "addfirewallpolicy", 
            "time": ""
        }
    ]
}

After that, the worker who received the JSON should import the JSON again with'load'and press'execjson', and this time the process will start to flow.

Actually, there are a few more, so refer to the wiki (-_-;)

Summary

I hope the above tools will give you a start on automating user request work. (I can't say anything because it depends on the environment) In fact, the DevOps flow usually stops at security, but with a tool like the one above,

DevOps -> NetDevOps -> NetDevOpsSec <- New!

I think it would be better to gradually expand the scope of improvement in the order of.

How to hit NAPALM from the Web (NetDevOpsSec reality solution)