Einführung

Dieser Artikel ist vom 14. Dezember 2016 in NetOpsCoding Adventskalender 2016.

CLI wird häufig zum Betreiben von Netzwerkgeräten verwendet, ist jedoch mit einem Programm mit CLI (-_-;) nur schwer zu handhaben.

Einige Ingenieure, hauptsächlich Spotify, haben eine Bibliothek namens "Napalm" erstellt, um die Handhabung des Programms zu vereinfachen. (Paramiko Basis) https://github.com/napalm-automation/napalm

Aktuelles Beispiel

Dieses Mal werde ich versuchen, die Konfiguration mit der Konfiguration von Junos + CGI + Napalm aus dem Web zu laden. Wenn Sie einen Befehl aus dem Web ausführen möchten (z. B. eine Firewall-Richtlinie hinzufügen), bereiten Sie das folgende HTML / CGI vor.

`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()

Als Punkt

--Konvertieren Sie das vom Webformular empfangene Argument in dict (= JSON = YAML) und wenden Sie es dann auf die Konfigurationsvorlage an

Ich frage mich, ob ...

Weitere Informationen finden Sie unten. http://qiita.com/taijijiji/items/a3f21c8b9e7a0d3afdc6 http://www.slideshare.net/JuniperJapan/interop-tokyo-2016junos-automation

Dank der wunderbaren Blogs der Pioniere ist es leicht vorbei ... (-o-;)

Dies ist ein wenig einsam, weil es sehr leicht endet, daher möchte ich ein komplizierteres Beispiel betrachten (-_-;)

Was ist der Genehmigungsablauf?

Wie bereits geschrieben, wird bei Routinearbeiten im Web der Ablauf von Benutzeranweisungen (kurz Argumente) unten dargestellt.

Antragsteller (= Arbeitnehmer) -> Webanwendung-> Napalm

In diesem Fluss jedoch

Eine Person, die einen Browser bedient und den Arbeitsinhalt beschreibt (Antragsteller)
Personen, die die Arbeit tatsächlich ausführen (Arbeiter)

Es gibt eine Einschränkung, dass es nur verwendet werden kann, wenn sie identisch sind, und dies wird zu einem Problem im tatsächlichen Betrieb.

Dies bedeutet, dass in einer Unternehmensumgebung, in der IT-Vorgänge überwacht werden. Es gibt eine Einschränkung, dass "Antragsteller (Anbieter von Anwendungsentwicklungen usw.)" Die Produktionsumgebung nicht direkt betreiben können.

Sogenannte Dev and Ops

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

In diesem Fall genehmigt der Genehmigende den vom Antragsteller beschriebenen Inhalt, und dann führt der Arbeitnehmer die Arbeit aus. Bei ITIL-fähigen Tools (normalerweise intensiv bei Audits) wird dies als Bildschirm festgelegt und die Arbeit ist eine angehängte Datei.

Begegnung mit Tools von mindestens zwei Anbietern, (-_-;)

Daher ist der realistische Fluss in diesem Fall wie folgt.

Bewerber-> Arbeitsanweisungen (Excel usw.) -> ITIL-Tools-> (Workflow) -> Arbeitnehmer
Worker-> Web App-> Napalm

In diesem Fall schreibt der Antragsteller den Arbeitsauftrag so detailliert wie möglich. Es gibt eine Grenze für die Informationen, die auf Japanisch erklärt werden können ... Beim Betrachten des Amazon-Bildschirms hatte ich das Gefühl, alle Bestellungen per E-Mail zu senden.

――Wo und wann liefern Sie es aus? ――Wenn Sie es zuerst auswählen können, wird es separat versendet? ――Was ist die Zahlungsmethode?

Um ehrlich zu sein, ist es schwierig, genau auf einen Schlag zu sagen. des Weiteren,

――Wie viele Aktien haben Sie überhaupt?

Usw., einschließlich der Überprüfung der Inhalte, die ohne Überprüfung mit dem System nicht verstanden werden können, usw. Ich halte es für wünschenswert, dass Bewerber ein Bewerbungsformular erstellen, das auf einer Art Webanwendung basiert.

Ich denke also, dass der ideale Fluss wie folgt ist.

Antragsteller-> Webanwendung-> Eingabeinhalt als JSON exportieren
Antragsteller-> ITIL-Tool (JSON beigefügt) -> (Workflow) -> Worker
Worker-> Web App (JSON importieren) -> Napalm

Wenn dies erreicht werden kann, gibt es die folgenden Vorteile.

--Applicant (Dev): Sie können ein Anforderungsformular erstellen, während Sie prüfen, ob der Inhalt selbst mit einer Webanwendung bearbeitet werden kann, wodurch die Interaktion mit den Mitarbeitern verringert wird --Worker (Net, Ops): Die Arbeit beschränkt sich auf den JSON-Import, es ist nicht erforderlich, die eigentliche Maschine zu bedienen, weniger Interaktion mit dem Antragsteller

Sicherheitspersonal (Sec (vorläufig)): Da es schwierig ist, außerhalb des Flusses zu genehmigen, müssen Sie sich keine Gedanken darüber machen, wie Beweise hinterlassen werden, Sie müssen sich nicht darum kümmern, wie Beweise aufbewahrt werden (3 Jahre Lagerung usw.).

Ich habe versucht, das Tool zu implementieren

In Bezug auf die oben genannten Probleme habe ich versucht, die folgenden Tools zu implementieren, während ich das Front-Miso gemacht habe. https://github.com/tnaganawa/execjson

Das Bildschirmbild des Werkzeugs sieht wie folgt aus.

Zunächst gibt der Antragsteller die eingegebenen Inhalte für jede auszuführende Arbeit in das Webformular ein (im Beispiel Hinzufügen einer Firewall-Richtlinie). Klicken Sie auf "Exportieren", wenn Sie fertig sind, und der JSON wird exportiert, damit Sie ihn durch den Genehmigungsablauf leiten können.

Der erstellte JSON lautet wie folgt

`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": ""
        }
    ]
}

Danach sollte der Worker, der den JSON erhalten hat, den JSON erneut mit 'load' importieren, 'execjson' drücken und der Prozess sollte diesmal beginnen zu fließen.

Eigentlich gibt es noch ein paar mehr, siehe das Wiki (-_-;)

Zusammenfassung

Ich hoffe, dass die oben genannten Tools Ihnen einen Einstieg in die Automatisierung der Benutzeranforderungsarbeit ermöglichen. (Ich kann nichts sagen, weil es von der Umgebung abhängt) Tatsächlich stoppt der DevOps-Fluss normalerweise bei der Sicherheit, aber mit einem Tool wie dem oben genannten

DevOps -> NetDevOps -> NetDevOpsSec <- New!

Ich denke, es wäre besser, den Umfang der Verbesserungen schrittweise in der Reihenfolge von zu erweitern.

[PYTHON] Wie man NAPALM aus dem Web erreicht (NetDevOpsSec echte Lösung)