introduction

Cet article est du 14 décembre 2016 dans NetOpsCoding Advent Calendar 2016.

CLI est souvent utilisé pour faire fonctionner les périphériques réseau, mais il est difficile à gérer à partir d'un programme avec CLI (-_-;)

Pour faciliter la manipulation depuis le programme, certains ingénieurs, principalement Spotify, ont créé une bibliothèque appelée «napalm». (Base de Paramiko) https://github.com/napalm-automation/napalm

Exemple réel

Cette fois, je vais essayer de charger la configuration depuis le Web avec la configuration de Junos + CGI + napalm. Si vous souhaitez lancer une commande à partir du Web (par exemple, ajouter une stratégie de pare-feu), préparez le HTML / CGI suivant.

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

Comme un point

--Convertissez l'argument reçu du formulaire Web en dict (= JSON = YAML), puis appliquez-le au modèle de configuration

Je me demande si ...

Pour plus d'information, voyez plus bas. http://qiita.com/taijijiji/items/a3f21c8b9e7a0d3afdc6 http://www.slideshare.net/JuniperJapan/interop-tokyo-2016junos-automation

Grâce aux merveilleux blogs des pionniers, c'est fini facilement ... (-o-;)

C'est un peu solitaire car cela finit très légèrement, donc j'aimerais considérer un exemple plus compliqué (-_-;)

Quel est le flux d'approbation?

Comme déjà écrit, lors de l'exécution de travaux de routine à partir du Web, le flux d'instructions utilisateur (en bref, les arguments) est indiqué ci-dessous.

Candidat (= travailleur) -> Application Web-> napalm

Cependant, dans ce flux

Une personne qui exploite un navigateur et décrit le contenu du travail (demandeur)
Les personnes qui effectuent réellement le travail (travailleurs)

Il y a une limitation qu'il ne peut pas être utilisé à moins qu'ils ne soient identiques, et cela devient un problème en fonctionnement réel.

Cela signifie que dans un environnement d'entreprise où les opérations informatiques sont auditées. Il existe une restriction selon laquelle les «candidats (fournisseurs de développement d'applications, etc.)» ne peuvent pas exploiter directement l'environnement de production.

Soi-disant Dev et Ops

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

Dans ce cas, l'approbateur approuve le contenu décrit par le demandeur, puis le travailleur exécute le travail. Avec les outils compatibles ITIL (généralement observés de manière intensive dans les audits), cela est corrigé sous forme d'écran et le travail est un fichier joint.

Rencontré avec des outils d'au moins deux fournisseurs, (-_-;)

Par conséquent, le flux réaliste dans ce cas est le suivant.

Candidat-> Instructions de travail (Excel, etc.) -> Outils ITIL-> (Workflow) -> Travailleurs
Travailleur-> Web App-> napalm

Dans ce cas, le demandeur rédige le bon de travail avec le plus de détails possible, Il y a une limite aux informations qui peuvent être expliquées en japonais ... En regardant l'écran d'Amazon, j'ai eu l'impression d'envoyer toutes les commandes par e-mail.

―― Où et quand allez-vous le livrer? ――Si vous pouvez le choisir en premier, sera-t-il expédié séparément? ―― Quelle est la méthode de paiement?

Pour être honnête, il est difficile de dire exactement d'un seul coup. plus loin,

――Combien de stocks avez-vous en premier lieu?

Etc., y compris la vérification du contenu qui ne peut être compris sans vérification avec le système, etc. Je pense qu'il est souhaitable que les candidats créent un formulaire de candidature basé sur une sorte d'application Web.

Donc, je pense que le flux idéal est le suivant.

Candidat-> Web App-> Exporter le contenu d'entrée au format JSON
Candidat-> ITIL Tool (JSON joint) -> (Workflow) -> Worker
Worker-> Web App (Importer JSON) -> napalm

Si cela peut être réalisé, il y a les avantages suivants.

Candidat (Dev): Vous pouvez créer un formulaire de demande tout en vérifiant si le contenu peut être travaillé par vous-même avec une application Web, réduisant ainsi l'interaction avec les travailleurs --Worker (Net, Ops): le travail est limité à l'importation JSON, pas besoin d'utiliser la machine réelle, moins d'interaction avec le candidat
Personnel de sécurité (Sec (provisoire)): Comme il est difficile d'approuver en dehors du flux, vous n'avez pas à vous soucier de la façon de laisser des preuves, vous n'avez pas à vous soucier de la façon de conserver les preuves (3 ans de stockage, etc.)

J'ai essayé de mettre en œuvre l'outil

En ce qui concerne les problèmes ci-dessus, j'ai essayé de mettre en œuvre les outils suivants tout en faisant le miso avant. https://github.com/tnaganawa/execjson

L'image d'écran de l'outil est la suivante.

Tout d'abord, le demandeur entre le contenu d'entrée dans le formulaire Web pour chaque travail à effectuer (dans l'exemple, l'ajout d'une politique de pare-feu). Cliquez sur `` exporter json '' lorsque vous avez terminé, et le JSON sera exporté, afin que vous puissiez le transmettre au processus d'approbation.

Le JSON créé est le suivant

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

Après cela, le worker qui a reçu le JSON doit à nouveau importer le JSON avec "load", appuyez sur "execjson", et le processus devrait commencer à se dérouler cette fois.

En fait, il y en a quelques autres, alors référez-vous au wiki (-_-;)

Résumé

J'espère que les outils ci-dessus vous permettront d'automatiser le travail des demandes des utilisateurs. (Je ne peux rien dire car cela dépend de l'environnement) En fait, le flux DevOps s'arrête généralement à la sécurité, mais avec un outil comme celui ci-dessus,

DevOps -> NetDevOps -> NetDevOpsSec <- New!

Je pense qu'il serait préférable d'élargir progressivement la portée des améliorations de l'ordre de.

[PYTHON] Comment accéder à NAPALM depuis le Web (solution réelle NetDevOpsSec)