例: テストエージェント
新しいテストエージェントの作成とデプロイ
Paragon Active Assuranceで測定を実行するには、まずParagon Active Assuranceアカウントに1つ以上のテストエージェントを作成する必要があります。このセクションでは、REST API を使用して仮想テストエージェントを作成する方法について説明します。
以下に詳述する次の手順に進みます。
- 当初、アカウント「デモ」のインベントリにはテストエージェントがありません。
- 「vta1」と呼ばれるテストエージェントは、REST APIを介して作成されます。この段階では、実際のテストエージェントはまだ存在しません(つまり、まだ起動されていません)。
- テストエージェントがOpenStackにデプロイされます。(ここでは、そのプラットフォームへの展開を1つの可能性として選択しています。
- テストエージェントがコントロールセンターアカウントの「デモ」に接続し、使用できるようになりました。
ステップ1: 最初は、アカウント「demo」にテストエージェントはありません。コントロールセンターのウェブGUIから、以下のスクリーンショットを参照してください。
ステップ2: テストエージェントは、テストエージェントに対する REST API POST 操作を使用して、コントロールセンターで作成されます。
以下のPythonでこれを行います。Python コードを記述するには、REST API でテスト エージェントのすべての構成オプションを調べると便利です。
- に進みます
https://<Control Center host IP>/rest。 - [test_agent] で、 の
/accounts/{account}/test_agents/POST 操作を展開します。
- [説明] で [モデル] をクリックします。
以下では、eth0 が DHCP アドレスを持つ 3 つの物理インターフェイス "eth0"、"eth1"、および "eth2" を持つテストエージェントを作成します。NTP サーバーは eth0 に設定され、eth0 は管理インターフェイス (つまり、コントロールセンターに接続するインターフェイス) でもあります。
(以降の例では、以下のコードと異なる場合を除き、 import コマンドを省略しています。 parser コマンドは常に同じであるため、コマンドも省略されています。REST API トークンとその取得方法については、「 認証トークンの取得」セクションを参照してください。
import argparse
import json
import requests
parser = argparse.ArgumentParser(description='Example for')
parser.add_argument('--ncc-url', help='The URL where NCC is found, for example https://<hostname>/rest', required=True)
parser.add_argument('--token', help='The REST API token', required=True)
parser.add_argument('--account', help='The Netrounds account', required=True)
args = parser.parse_args()
# Request settings
url = '%s/accounts/%s/test_agents/' % (args.ncc_url, args.account)
# JSON content
json_data = json.dumps({
'description': 'Test agent description',
'interface_config': {
'eth0': {
'address': {
'type': 'dhcp_ip4',
},
'address6': {
'type': 'dhcp_ip6',
},
'description': 'eth0',
'mtu': 1500,
'speed': 'AUTO',
'type': 'physical'
},
'eth1': {
'address': {
'type': 'none_ip4'
},
'address6': {
'type': 'none_ip6'
},
'description': 'eth1',
'mtu': 1500,
'speed': 'AUTO',
'type': 'physical'
},
'eth2': {
'address': {
'type': 'none_ip4'
},
'address6': {
'type': 'none_ip6'
},
'description': 'eth2',
'mtu': 1500,
'speed': 'AUTO',
'type': 'physical'
}
},
'license': 'UNLIMITED',
'management_interface': 'eth0',
'name': 'Test Agent 2',
'ntp_config': {
'interface_name': 'eth0',
'server': 'time.google.com',
'enable_ipv6': False
},
'type': 'appliance'
})
# Create Test Agent
response = requests.post(url=url, data=json_data, headers={
'API-Token': args.token,
'Accept': 'application/json; indent=4',
'Content-Type': 'application/json',
})
print 'Status code: %s' % response.status_code
print json.dumps(response.json(), indent=4)
署名されたSSL証明書が存在しない場合は、「requests」コマンドに追加 verify=False する必要があります:以下を参照してください。ただし、これは運用環境では強くお勧めしません。暗号化された安全な接続を確保するために、適切な署名付きSSL証明書を取得する必要があります。インストールガイドの サービス設定の章のSSL証明書の設定に関するセクションも参照してください。
# Create Test Agent
response = requests.post(url=URL, data=json_data, headers={
'API-Token': TOKEN,
'Accept': 'application/json; indent=4',
'Content-Type': 'application/json'
},
verify=False
)
別のプログラミング言語を使用したほうがよいことを示すために、curlで同じことを実現する方法を次に示します。
curl -X POST "https://<Control Center host and port>/accounts/demo/test_agents/"
-H "accept: application/json" -H "content-type: application/json" -d "{ \"description\":
\"Created via REST API\", \"interface_config\": { \"eth0\": { \"address\": { \"type\":
\"dhcp_ip4\" }, \"address6\": { \"type\": \"dhcp_ip6\" }, \"description\": \"eth0\",
\"mtu\": \"1500\", \"speed\": \"AUTO\", \"type\": \"physical\" }, \"eth1\": { \"address\":
{ \"type\": \"none_ip4\" }, \"address6\": { \"type\": \"none_ip6\" }, \"description\":
\"eth1\", \"mtu\": \"1500\", \"speed\": \"AUTO\", \"type\": \"physical\" } }, \"license\":
\"UNLIMITED\", \"management_interface\": \"eth0\", \"name\": \"vta1\", \"ntp_config\":
{ \"interface_name\": \"eth0\", \"server\": \"time.google.com\" }, \"type\": \"appliance\" }"
署名されたSSL証明書がない場合は、ここにフラグを追加する --insecure 必要があります。
作成されたテストエージェントは、構成データベースとコントロールセンターに存在します。以下のテストエージェントインベントリのスクリーンショットで、テストエージェント「vta1」が表示されています。
ステップ3: ここで、テストエージェント「vta1」を導入します。
このガイドでは、OpenStackに仮想テストエージェントを導入します。ただし、他の仮想化環境での展開も同様に可能です。
OpenStackでは、テストエージェントはクラウド初期化のユーザーデータを使用して、コントロールセンターへの接続方法に関する情報を取得します。具体的には、ユーザー データ テキスト ファイルの内容は次のとおりです。
行と #cloud-config 行が存在し、残りの行 netrounds_test_agent はインデントされている必要があります。
#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
詳細については、 https://www.juniper.net/documentation/product/en_US/paragon-active-assurance から入手できるドキュメント「OpenStackに仮想テストエージェントをデプロイする方法」を参照してください。
テストエージェントがデプロイされ、コントロールセンターに接続されると、構成がコントロールセンターからテストエージェントにプッシュされます。
ステップ4: これで、テストエージェントがコントロールセンターでオンラインになり、設定が完了しました。これで、テストエージェントをテストおよび監視で使用できる状態になります。これらのセクションを参照してください。
- テストの作成と実行
- モニターの作成とモニターの開始と停止
Paragon Active Assuranceアカウント内のテストエージェントのリスト表示
以下は、Paragon Active Assuranceアカウントにテストエージェントを一覧表示するためのPythonコードの例です。
# Request settings
# NOTE: User is able to pass additional parameters as a query string ?limit=100&offset=111:
# limit: Changes number of elements returned from API
# offset: Changes element from which results will be returned
url = '%s/accounts/%s/test_agents/%s' % (args.ncc_url, args.account, args.query_params)
# Get list of Test Agents
response = requests.get(url=url, headers={'API-Token': args.token})
このコードを実行すると、次のような出力が得られます。
{
"count": 2,
"exclude_default": [
"interface_config",
"ntp_config",
"management_interface",
"interface_names",
"interface_states",
"uptime",
"memory",
"cpu",
"load_avg"
],
"items": [
{
"description": "Created via REST API",
"gps_lat": 22.222222,
"gps_long": -33.333333,
"id": 1,
"interface_names": [
"eth0",
"eth1"
],
"is_owner": true,
"license": "SW_LARG",
"name": "Test Agent A",
"online": true,
"type": "appliance",
"use_public_address": false,
"version": "3.3.0"
}
{
...
"name": "Test Agent B",
... (same items listed for this Test Agent)
}
],
"limit": 10,
"next": null,
"offset": 0,
"previous": null
}
テストエージェントの構成データとステータスの取得
個々のテストエージェントに GET 操作を適用することで、テストエージェントとそのインターフェイスの構成情報とステータス情報の両方を取得します。状態情報には、オンライン状態、稼働時間、CPU 負荷、およびメモリ使用量が含まれます。
# Request settings
url = '%s/accounts/%s/test_agents/%s/' % (args.ncc_url, args.account, args.test_agent_id)
# Get Test Agent
response = requests.get(url=url, headers={'API-Token': args.token})
出力は次のようになります。
{
"cpu": 0.8,
"description": "",
"gps_lat": 22.222222,
"gps_long": -33.333333,
"hidden": false,
"id": 5,
"interface_config": {
"eth0": {
"address": {
"type": "dhcp_ip4",
"vendor": null
},
"address6": {
"type": "none_ip6"
},
"description": "",
"mac": null,
"management": true,
"mtu": 8900,
"speed": "AUTO",
"tags": [],
"type": "physical"
},
"eth1": {
"address": {
"dhcpd": null,
"dns": [],
"ip": "10.1.1.66/24",
"routes": {},
"type": "static_ip4"
},
"address6": {
"dns": null,
"ip": "2001:0DB8::1/64",
"routes": {},
"type": "static_ip6"
},
"description": "",
"mac": null,
"management": false,
"mtu": 1500,
"speed": "AUTO",
"tags": [],
"type": "physical"
}
},
"interface_states": {
"eth0": {
"ip4_address": "192.168.100.4/24",
"ip6_address": [],
"mac_hw": "08:00:27:30:be:03"
},
"eth1": {
"ip4_address": "10.1.1.66/24",
"ip6_address": [
"2001:0DB8::1/64"
],
"mac_hw": "08:00:27:80:57:51"
}
},
"is_owner": true,
"license": "SW_MEDI",
"load_avg": [
0,
0.01,
0.05
],
"management_interface": "eth0",
"memory": 22.18,
"name": "VTA1",
"ntp_config": {
"interface_name": "eth0",
"server": "time.google.com"
},
"online": true,
"tags": [],
"type": "appliance",
"uptime": 47319,
"use_public_address": false,
"version": "2.23.0"
}
テストエージェントの構成の変更
テストエージェントの構成を変更するには、PUTコマンドを使用します。
PUTでは、新しいテストエージェント の作成とデプロイのセクションで説明したようにテストエージェントを作成する場合と同様に、JSONデータで設定全体を指定する必要があります。したがって、これを行うためのコードは、URLが特定の既存のテストエージェントを指す点を除いて、テストエージェントの作成の場合と同じです
# Request settings url = '%s/accounts/%s/test_agents/%s/' % (args.ncc_url, args.account, args.test_agent_id)
と PUT コマンド
# Update Test Agent
response = requests.put(url=url, data=json_data, headers={
'API-Token': args.token,
'Accept': 'application/json; indent=4',
'Content-Type': 'application/json',
})
は POST の代わりに使用されます。
テストエージェントソフトウェアのアップデート
REST APIは、すべてのテストエージェントまたは指定されたサブセットのテストエージェントソフトウェアを最新バージョンに更新するためのPOST操作を提供します。
以下は、テストエージェントのサブセットにソフトウェアアップデートを適用する方法の例です。
# Request settings
url = '%s/accounts/%s/test_agents/update/' % (args.ncc_url, args.account)
# JSON content: Subset of Test Agents on which to update software
# POST http://server/accounts/acount_name/test_agents/update
json_data = json.dumps({
'test_agent_ids': args.test_agent_ids.split(',')
})
# Update Test Agent version
response = requests.post(url=url, data=json_data, headers={
'API-Token': args.token,
'Accept': 'application/json; indent=4',
'Content-Type': 'application/json',
})
すべてのテストエージェントでソフトウェアをアップデートする場合は、空のまま json_data にしてスイッチをURLに追加します ?all 。
# Request settings url = '%s/accounts/%s/test_agents/update/?all' % (args.ncc_url, args.account)
テストエージェント: 高度な例
テストエージェント(またはREST API内の他のエンティティ)のすべての設定オプションを利用するには、REST API Swaggerスキーマに精通している必要があります。
前述のように、JSON 形式のスキーマへのリンクがページの上部に表示されます。これはかなり読みにくいです。コンテンツを解析しやすくするために、ファイルを次のページにコピーできます。
これにより、スキーマがより人間が読めるYAMLに変換されます。
以下の例では、スキーマの一部がアルファベット順に並べ替えられるのではなく、読みやすくするために再配置されていることに注意してください。
例えば、静的IPv4アドレスでテストエージェントを設定するとします。
これを行うには、HTTP POST リクエストの を解釈bodyします。
最終的な目標は、次の要求を作成することです。
{
"name": "Test Agent 1",
"description": "This is my Test Agent",
"interface_config": {
"eth0": {
"type": "physical",
"address": {
"type": "static_ip4",
"ip": "192.168.0.123/24"
}
}
}
}
問題は、これがフォーマットする方法であることをどうやって知るのかということです。
正しい構文を見つけるには、テストエージェントスキーマを参照する必要があります。実際、その拡張バージョンを確認する必要があります。 TestAgentExtendedSchema Swagger スキーマで以下を検索します。
TestAgentExtendedSchema:
properties:
...name:
type: stringmaxLength: 100minLength: 1...description:
type: stringmaxLength: 100
...
まず、このスキーマには および description as 属性がありますname。したがって、HTTP 要求bodyは次のように開始する必要があります。
{
"name": "Test Agent 1",
"description": "This is my Test Agent"
}
propertiesの一部は として定義されるread-only。これらはサーバーによって無視されるため、要求から除外できます。
次に、インターフェイス構成、より具体的にはIPアドレスについて説明しますが、これにはもう少し作業が必要です。
アドレスはプロパティ interface_config で指定され、以下に示すようにへの InterfaceConfigSchema 参照が含まれています。
TestAgentExtendedSchema:
type: objectproperties:
...interface_config:
type: objectadditionalProperties:
$ref: '#/definitions/InterfaceConfigSchema'
リクエストに追加することから始めることができます。
{
"name": "Test Agent 1",
"description": "This is my Test Agent",
"interface_config": {}
}
interface_configこれにより空の が追加されるため、interface_configJSONオブジェクトの構築方法を理解するには、InterfaceConfigSchemaスキーマの部分に移動する必要があります。
InterfaceConfigSchema:
type: objectrequired:
- typediscriminator: typeproperties:
description:
type: stringtype:
type: stringenum:
- physical
- vlan
- bridge
- bridged
- mobile
- wifi
スキーマには、必須の名前 type のプロパティがあります。これは、定義するインターフェイスのタイプを指定するために使用されます。これには type 有効な選択肢のリストがあり、スキーマ enumでは .
discriminatorスキーマの部分は、使用する必要がある特定の型を指すために使用されます。
オブジェクト指向プログラミング(OOP)に精通している人にとって、これへのアナロジーは「継承」、またはポリモーフィズムです。
には InterfaceConfigSchema 、で enum定義されているサブタイプのリストがあります。
この場合、「通常の」ネットワークインターフェイスが必要なので、として指定physicaltypeする必要があります。
これで、型のスキーマ physical を検索できます。
physical:
description: A representation of Physical Interface
allOf:
- $ref: '#/definitions/InterfaceConfigSchema'
- properties:
type: objectaddress:
$ref: '#/definitions/InterfaceIPv4AddressSchema'address6:
$ref: '#/definitions/InterfaceIPv6AddressSchema'...
ここで、属性は、インターフェイスタイプがからのすべてのプロパティInterfaceConfigSchemaとproperties、allOfリストされたインラインを持つことを示すphysicalために使用されます。
つまり、OOP用語ではfromInterfaceConfigSchemaを「継承」propertiesします。
だから私たちは構築を続けることができます HTTPPOSTリクエスト body。静的IPv4アドレスが必要なので、IPv6用ではなく指定しますaddressaddress6。
{
"name": "Test Agent 1",
"description": "This is my Test Agent",
"interface_config": {
"eth0": {
"type": "physical",
"address": {}
}
}
}
したがって、同じプロセスを使用して、次のように検索します InterfaceIPv4AddressSchema。
InterfaceIPv4AddressSchema:
type: objectrequired:
- typediscriminator: typeproperties:
type:
type: stringenum:
- none_ip4
- static_ip4
- dhcp_ip4
ここでも、type使用する特定のスキーマを識別するために使用される を指定します。私たちは、でenum見つかったようにしたいstatic_ip4:
{
"name": "Test Agent 1",
"description": "This is my Test Agent",
"interface_config": {
"eth0": {
"type": "physical",
"address": {
"type": "static_ip4"
}
}
}
}
次に、次のスキーマ static_ip4を検索します。
static_ip4:
description: IPv4 static addressallOf:
- $ref: '#/definitions/InterfaceIPv4AddressSchema'
- properties:
type: object...ip:
type: string...
ここでは、 ip プロパティを指定する必要があることがわかります。一般に、Netrounds では、IP アドレスは CIDR 表記を使用して入力されます。
ここでの他の properties すべてはオプションです。
これで、JSONを完成させることができます。
{
"name": "Test Agent 1",
"description": "This is my Test Agent",
"interface_config": {
"eth0": {
"type": "physical",
"address": {
"type": "static_ip4",
"ip": "192.168.0.123/24"
}
}
}
}
テストエージェントの削除
テストが完了したら、ユースケースによってはテストエージェントを削除することが関連する場合があります。
以下は、REST APIを介してこれを行うためのコードです。
# Request settings
url = '%s/accounts/%s/test_agents/%s/' % (args.ncc-url, args.account, args.test-agent-id)
# Delete Test Agent
response = requests.delete(url=url, headers={'API-Token': args.token})