Beispiele: Testagenten
Übersicht über die Testagent-Orchestrierung
Testagenten in Paragon Active Assurance werden im Kontext der Orchestrierung als "Konfiguration" betrachtet. Dies bedeutet, dass das Erstellen, Steuern und Löschen von Testagenten über den Orchestrator und NETCONF und nicht über die Paragon Active Assurance-GUI erfolgen sollte.
Wenn ein Testagent von einem Techniker installiert und im Control Center registriert wird, ohne zuvor über die NETCONF & YANG-API erstellt worden zu sein, ist der Testagent nicht in der Konfigurationsdatenbank vorhanden, und das System ist nicht mehr synchron. Damit ConfD in diesem Fall auf den Testagenten aufmerksam wird, muss eine neue Synchronisierung mit dem Control Center durchgeführt werden, wie im Abschnitt Synchronisieren der Konfigurationsdatenbank mit dem Control Center beschrieben.
Die Orchestrierung von Virtual Test Agents (vTAs) sollte daher eher in den folgenden Schritten erfolgen:
- Erstellen Sie den Virtual Test Agent, einschließlich seiner Schnittstellenkonfiguration, mithilfe der NETCONF & YANG-Schnittstelle zum Control Center. Der Name des Test-Agents ist sein eindeutiger Schlüssel.
- Stellen Sie die vTA auf einer Virtualisierungsplattform bereit. Folgen Sie den Anweisungen in der Online-Hilfe unter Testagenten > Installation. Die grundlegende Schnittstellenkonfiguration, mit der der vTA eine Verbindung zum Control Center herstellen kann, sowie die Anmeldeinformationen für die Authentifizierung werden in der vTA mithilfe von cloud-init-Benutzerdaten bereitgestellt. Sobald der vTA hochgefahren ist, verbindet er sich automatisch über eine verschlüsselte OpenVPN-Verbindung mit dem Control Center. Es wird eine NETCONF-Benachrichtigung gesendet, da der Wert des Parameters test-agent-status-change der vTA jetzt auf "online" geändert wurde.
Hinweis:
Da der Name der vTA ihre Kennung in Control Center ist, muss dieser Name mit dem Namen identisch sein, der in Control Center in Schritt 1 definiert wurde.
- Sobald der vTA eine Verbindung zum Control Center hergestellt und authentifiziert hat, wird die Schnittstellenkonfiguration an den vTA übertragen. Dies ist die Schnittstellenkonfiguration, die in Schritt 1 bereitgestellt wurde, als die vTA im Control Center erstellt wurde.
- Nachdem die vTA ihren Zweck erfüllt hat, löschen Sie die vTA.
Erstellen und Bereitstellen eines neuen Test-Agents
Zuerst müssen wir einen Testagenten erstellen, indem wir die NETCONF & YANG-Schnittstelle zum Control Center verwenden. Wenn ein Testagent auf diese Weise erstellt wird, ist keine Synchronisierung mit dem Control Center erforderlich.
Das YANG-Modell für einen Testagenten ist wie unten dargestellt. Sie wird als Ausgabe des Befehls
pyang -f tree netrounds-ncc.yang
Das vollständige YANG-Modell finden Sie im Anhang: Baumstruktur des vollständigen YANG-Modells, der auch eine Legende enthält, die die Konventionen erläutert, die in dieser und anderen YANG-Modellabbildungen in diesem Dokument verwendet werden.
+--rw test-agents | +--rw test-agent* [name] | +--rw name string | +--rw description? string | +--rw tags | | +--rw tag* [name] | | +--rw name -> ../../../../../tags/tag/name | +--ro state | | +--ro status? test-agent-status-t | | +--ro version? string | | +--ro uptime? int64 | | +--ro memory-usage? percent-t | | +--ro load-average | | +--ro last-1-minute? decimal64 | | +--ro last-5-minutes? decimal64 | | +--ro last-15-minutes? decimal64 | +--rw ntp | | +--rw interface? string | | +--rw servers* [address] | | | +--rw address union | | +--rw enable-ipv6? boolean | +--rw management | | +--rw interface? string | | +--rw use-public-address? boolean | +--rw interfaces | | +--rw interface* [name] | | +--rw name string | | +--rw description? string | | +--rw interface-type? interface-type-t | | +--rw mac? yang:mac-address | | +--rw mtu? uint16 | | +--rw speed? speed-t | | +--rw bridge | | | +--rw members | | | +--rw member* [interface] | | | +--rw interface -> ../../../../../interface/name | | +--rw vlan | | | +--rw id vlan-id-t | | | +--rw parent -> ../../../interface/name | | +--rw wifi | | | +--rw ssid? string | | | +--rw bssid? yang:mac-address | | | +--rw country? string | | | +--rw ht boolean | | | +--rw ht40 boolean | | | +--rw vht boolean | | | +--rw sgi boolean | | | +--rw ldpc boolean | | | +--rw ht-mcs? string | | | +--rw vht-max-mcs uint8 | | | +--rw vht-max-mimo uint8 | | | +--rw freq-2-4 boolean | | | +--rw freq-5 boolean | | | +--rw auth | | | +--rw (auth-type)? | | | +--:(personal) | | | | +--rw personal! | | | | +--rw cipher cipher-auth-t | | | | +--rw password? string | | | +--:(eap-tls) | | | | +--rw eap-tls! | | | | +--rw cipher cipher-auth-t | | | | +--rw ca-cert? string | | | | +--rw client-cert? string | | | | +--rw identity? string | | | | +--rw private-key? string | | | +--:(eap-ttls) | | | | +--rw eap-ttls! | | | | +--rw cipher cipher-auth-t | | | | +--rw ca-cert? string | | | | +--rw identity? string | | | | +--rw anonymous-identity? string | | | | +--rw password? string | | | +--:(peap) | | | +--rw peap! | | | +--rw cipher cipher-auth-t | | | +--rw ca-cert? string | | | +--rw identity? string | | | +--rw anonymous-identity? string | | | +--rw password? string | | +--rw mobile | | | +--rw apn? string | | | +--rw pdp_type string | | | +--rw rat_band mobile-rat-band-t | | | +--rw rat_mode mobile-rat-mode-t | | +--rw interface-config | | +--rw ipv4-address | | | +--rw (address-type)? | | | +--:(static) | | | | +--rw static! | | | | +--rw address tailf:ipv4-address-and-prefix-length | | | | +--rw routes* [network] | | | | | +--rw network tailf:ipv4-address-and-prefix-length | | | | | +--rw gateway inet:ipv4-address | | | | +--rw dns-servers* inet:ipv4-address | | | +--:(dhcp) | | | +--rw dhcp! | | | +--rw vendor-id? string | | +--rw ipv6-address | | +--rw (address-type)? | | +--:(static) | | | +--rw static! | | | +--rw address tailf:ipv6-address-and-prefix-length | | | +--rw routes* [network] | | | | +--rw network tailf:ipv6-address-and-prefix-length | | | | +--rw gateway inet:ipv6-address | | | +--rw dns-servers* inet:ipv6-address | | +--:(dhcp) | | | +--rw dhcp! | | | +--rw vendor-id? string | | +--:(slaac) | | +--rw slaac! | | +--rw dns-servers* inet:ipv6-address | +--rw ssh-keys | +--rw ssh-key* [name] | +--rw name string | +--rw ssh-key-value string | +--ro test-agent? -> /accounts/account/test-agents/test-agent/name
Wir gehen dabei in folgenden Schritten vor, die im Folgenden detailliert beschrieben werden:
- Zu Beginn hat der "Demo"-Account von Paragon Active Assurance keine Testagenten in seinem Bestand.
- Ein Testagent mit dem Namen "vta1" wird mit ncclient erstellt. Zu diesem Zeitpunkt ist noch kein echter Test-Agent vorhanden (d. h., er wurde noch nicht gestartet).
- Der Testagent wird in OpenStack bereitgestellt. (Die Bereitstellung auf dieser Plattform wird hier als eine Möglichkeit unter anderen ausgewählt.)
- Der Testagent verbindet sich mit dem Control Center-Konto "Demo" und ist nun einsatzbereit.
Schritt 1: Zu Beginn gibt es keine Testagenten im Konto "Demo". Sehen Sie sich den folgenden Screenshot von der GUI des Control Centers an.
Schritt 2: Ein Testagent wird im Control Center mit dem Python NETCONF-Client "ncclient" erstellt. Im Folgenden finden Sie ncclient-Code zum Erstellen eines Testagenten mit einer physischen Schnittstelle mit einer DHCP-Adresse:
import argparse
from ncclient import manager
parser = argparse.ArgumentParser(description='Test creating Test Agent')
parser.add_argument('--host', help='The hostname where ConfD is found', required=True)
parser.add_argument('--port', help='The port to connect to ConfD', required=True)
parser.add_argument('--username', help='The username to connect to ConfD', required=True)
parser.add_argument('--password', help='Password to the ConfD account', required=True)
parser.add_argument('--netrounds-account', help='The NCC account short name', required=True)
parser.add_argument('--test-agent-name', help='Name of Test Agent', required=True)
args = parser.parse_args()
with manager.connect(host=args.host, port=args.port, username=args.username,
password=args.password, hostkey_verify=False) as m:
# Create Test Agent in Control Center
xml = """<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<accounts xmlns="http://ncc.netrounds.com">
<account>
<name>demo</name>
<test-agents>
<test-agent>
<name>vta1</name>
<description/>
<ntp>
<interface>eth0</interface>
<server>time.google.com</server>
</ntp>
<management>
<interface>eth0</interface>
</management>
<interfaces>
<interface>
<name>eth0</name>
<description/>
<interface-type>physical</interface-type>
<mac>fa:16:3e:ec:b3:a8</mac>
<mtu>1400</mtu>
<speed>auto</speed>
<interface-config>
<ipv4-address>
<dhcp/>
</ipv4-address>
<ipv6-address></ipv6-address>
</interface-config>
</interface>
</interfaces>
<tags>
<tag>
<name>Tag 1</name>
</tag>
</tags>
</test-agent>
</test-agents>
</account>
</accounts>
</config>
""".format(
account=args.netrounds_account,
testagent=args.test_agent_name
)
print m.edit_config(target='running', config=xml)
Der vorhergehende with manager.connect(...) Code wird in den nachfolgenden Beispielcodeausschnitten weggelassen.
Ein NTP-Server wird auf eth0 konfiguriert, und eth0 ist auch die Verwaltungsschnittstelle (d. h. die Schnittstelle, die eine Verbindung zum Control Center herstellt).
Eine Test-Agent-Anwendung erlaubt derzeit keine Konfiguration von Schnittstellen. Aus diesem Grund ist es ab Version 2.34.0 möglich, die Schnittstellenkonfiguration im YANG-Schema wegzulassen. Das entsprechende XML wird in diesem Fall also radikal vereinfacht:
# Create Test Agent Application in Control Center
xml = """<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<accounts xmlns="http://ncc.netrounds.com">
<account>
<name>demo</name>
<test-agents>
<test-agent>
<name>vta2</name>
<description/>
<tags>
<tag>
<name>Tag 2</name>
</tag>
</tags>
</test-agent>
</test-agents>
</account>
</accounts>
</config>"""
Nachdem der Testagent erstellt wurde, ist er in der Konfigurationsdatenbank und im Control Center vorhanden. Sehen Sie sich den folgenden Screenshot des Test-Agent-Inventars an, der den Test-Agent "vta1" zeigt:
Schritt 3: Nun ist es an der Zeit, den Testagenten "vta1" in OpenStack bereitzustellen.
Der Testagent verwendet cloud-init-Benutzerdaten, um die Informationen zum Herstellen einer Verbindung mit dem Control Center abzurufen. Insbesondere hat die Textdatei für Benutzerdaten den folgenden Inhalt (Beachten Sie, dass die Zeilen und vorhanden sein müssen und netrounds_test_agent dass die #cloud-config verbleibenden Zeilen eingerückt sein müssen):
#cloud-config
netrounds_test_agent:
name: MyvTA # Name of vTA to appear in Control Center inventory
email: john.doe@example.com # Email you use when logging in to the system
password: secret # Login password
account: theaccount # Account name
server: <login-server>:<port> # Control Center host and port (default == SaaS)
# Note: With an IPv6 server address the whole string
# including port must be in double quotes
Weitere Informationen finden Sie im Dokument [DEPRECATED] How to Deploy Virtual Test Agents in OpenStack.
Sobald der Testagent bereitgestellt und mit dem Control Center verbunden wurde, wird die Konfiguration vom Control Center auf den Test-Agent übertragen.
Schritt 4: Der Testagent ist jetzt online im Control Center und hat seine Konfiguration erhalten. Der Testagent ist bereit für den Einsatz in Tests und Überwachung. Weitere Informationen finden Sie in den folgenden Abschnitten:
Auflistung der Testagenten in Ihrem Paragon Active Assurance-Konto
Im Folgenden finden Sie ein Beispiel für ncclient-Python-Code zum Auflisten der Testagenten in einem Paragon Active Assurance-Konto:
import argparse
from ncclient import manager
from ncclient.xml_ import to_ele, to_xml
# (server and account details omitted)
with manager.connect(host=args.host, port=args.port, username=args.username, password=args.password, hostkey_verify=False) as m:
# Get config subtree
# Get Test Agents from account
filter = """<accounts xmlns="http://ncc.netrounds.com">
<account>
<name>{account}</name>
<test-agents></test-agents>
</account>
</accounts>""".format(account=args.netrounds_account)
ele = to_ele(m.get_config(source='running', filter=('subtree', xml)).data_xml)
print to_xml(ele, encoding='UTF-8', pretty_print=True)
Wenn Sie diesen Code ausführen, erhalten Sie eine Ausgabe wie die folgende:
<?xml version="1.0" ?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<accounts xmlns="http://ncc.netrounds.com">
<account>
<name xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">demo</name>
<test-agents>
<test-agent>
<name>vta1</name>
<description/>
<ntp>
<interface>eth0</interface>
<server>time.google.com</server>
</ntp>
<management>
<interface>eth0</interface>
</management>
<interfaces>
<interface>
<name>eth0</name>
<description/>
<interface-type>physical</interface-type>
<mac>fa:16:3e:ec:b3:a8</mac>
<mtu>1400</mtu>
<speed>auto</speed>
<interface-config>
<ipv4-address>
<dhcp/>
</ipv4-address>
<ipv6-address></ipv6-address>
</interface-config>
</interface>
</interfaces>
</test-agent>
</test-agents>
</account>
</accounts>
</data>
Löschen eines Testagenten
Nach Abschluss eines Tests kann es in einigen Anwendungsfällen sinnvoll sein, den Test-Agenten zu löschen.
Unten sehen Sie ein Code-Snippet, das zeigt, wie Sie dies mit ncclient tun können:
with manager.connect(host=args.host, port=args.port, username=args.username, password=args.password,
hostkey_verify=False) as m:
# Get config subtree
# Delete Test Agent from account
xml = """<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<accounts xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="http://ncc.netrounds.com">
<account>
<name>demo</name>
<test-agents>
<test-agent nc:operation="delete">
<name>{test_agent}</name>
</test-agent>
</test-agents>
</account>
</accounts>
</config>""".format(test_agent="vta2")
test_agents = m.edit_config(target='running', config=xml)
NETCONF-Benachrichtigungen
Im Folgenden stellen wir ein einfaches Beispielskript zum Abhören aller eingehenden NETCONF-Benachrichtigungen aus dem Control Center vor. Diese Benachrichtigungen werden immer dann gesendet, wenn bestimmte Ereignisse eintreten, z. B. wenn ein Test-Agent offline geht oder ein vom Benutzer initiierter Test abgeschlossen wird. Basierend auf den in den Benachrichtigungen enthaltenen Informationen können Benutzer automatisierte Folgeaktionen im Orchestrator zuweisen.
with manager.connect(host=args.host, port=args.port, username=args.username, password=args.password,
hostkey_verify=False) as m:
data = m.create_subscription(stream_name='ncc')
# This will put ncclient in a state where it listens for notifications,
# triggered for instance by a Test Agent being unplugged.
# The example code below simply reads one notification. What to do with it is left
# to the creativity of the user.
while True:
notification = m.take_notification()
print notification._raw
Wenn das obige Skript ausgeführt wird, zeigt ncclient die empfangene Benachrichtigung in strukturiertem XML an. Sehen Sie sich die folgende Beispielausgabe an, die zeigt, wie ein Test-Agent unerwartet offline geht.
<ncclient.operations.notify.Notification object at 0x7f30242b6f10> <?xml version="1.0" encoding="UTF-8"?> <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"><eventTime> 2017-02-03T15:09:55.939156+00:00</eventTime> <test-agent-status-change xmlns='http://ncc.netrounds.com'> <account>demo</account> <test-agent>HW1</test-agent> <status>offline</status> </test-agent-status-change> </notification>