VIRLとPyATSで実現するネットワークCI

VIRLとpyATSで実現するネットワークCI

© 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public
• サービスイン前に導入する機器でテストを実施
• サービスイン後に使えるテスト環境がない
• テストはサービスイン前に手動で実施
• システム変更した場合、同様のテストを実行するのが事実上難しい
ネットワークが塩漬けになる理由
VIRLでテスト環境を構築
pyATSでテストの自動化

• Continuous Integration
• 開発者が自分のコード変更を頻繁に（Git等の）共有リポジトリに
マージし、その都度、自動化されたビルドとテストを実行するソフ
トウェア開発の手法
• エクストリーム・プログラミング (XP) のプラクティスの一つ
継続的インテグレーション（CI）とは

• Extreme Programming
• 従来のウォーターフォール型開発の
問題点を克服するために、1990年
代後半にケント・ベックらによって
考案
• 5つの価値と19のプラクティス（実
践）を定義
• 5つの価値
• コミュニケーション、シンプル、フィー
ドバック、勇気、尊重
• 19のプラクティス（右図）
(参考) XP カテゴリプラクティス
共同のプラクティス
反復
共通の用語
オープンな作業空間
回顧（頻繁な振り返り）
開発のプラクティス
テスト駆動開発
ペアプログラミング
リファクタリング
ソースコードの共同所有
継続的インテグレーション
YAGNI
管理者のプラクティス
責任の受け入れ
援護
四半期ごとの見直し
ミラー
適切なペースの仕事
顧客のプラクティス
ストーリーの作成
リリース計画
受け入れテスト
短期リリース

ネットワークにおけるCI
ネットワークをコードとして管理
• トポロジ
• 構成情報
• テスト
Gitリポジトリへ
Push / Pull Request
CIツールが検知し、
CIジョブを実行
チャットツールで
テスト結果を通知
仮想テスト環境を
セットアップ
ネットワークの
テスト
構成管理ツールで
ネットワーク設定

• ネットワーク変更の履歴
• ネットワーク変更のレビュー
• テストが十分にカバーされていれば、安心して以下のことができる
• 機器の追加、リプレース
• 機能の追加、拡張
• サービスの追加、拡張
• リファクタリング（コンフィグの最適化）
ネットワークにおけるCI
期待される効果

VIRL

What is VIRL?
パワフルで、使いやすく、拡張可能なネットワークシミュレー
ション環境
 既存または計画されたネットワークの高精度モデルを構築
 Ciscoのネットワークオペレーティングシステムの正規バージョンを使用してネッ
トワークを設計、設定、および運用
 IOSv、IOSv Layer-2、IOS-XRv、NX-OSv、CSR1000v、ASAvなどの共通プ
ラットフォームを使用して構築
 サードパーティの仮想マシン、アプライアンス、VNF、およびサーバーを統合
 実ネットワークと仮想ネットワークを接続して、再現性の高い開発環境とテスト環
境を構築
 どこでもデザインやテストが可能 - VIRLはポータブル

CML vs. VIRL PE
CML(Cisco Modeling Lab)
コーポレートユース
マルチユーザー
TACサポート
300ノード（最大）
Ciscoパートナーから購入
インターネット接続不要
VIRL PE(Personal Edition)
個人ユース
シングルユーザー
コミュニティサポート
20ノード（最大）
Cisco Learning Network Storeから購入
要インターネット接続
（ライセンスチェックのため）

Keystone (Identity Services)
Glance (Image / Repository Services)
Nova
(Compute Services)
Neutron
(Networking Services)
Swift
(Object
Services)
Cinder
(Block
Storage
Services)
Horizon(Dashboard)
APIs/CLI
IaaS / cloud orchestration software – creates, manages, and deletes virtual
resources according to API- or CLI-based instructions
VIRL – Built on OpenStack

VM Maestro
• グラフィカルなトポロジ編
集ツール
• ネットワーク要素を定義
 ルータ
 接続
 コンフィグ
 サーバ
• 複雑なトポロジをサポート
• シミュレーションを管理

VIRL – ネットワークインターフェイス
VIRL
X
マネジメント
SNAT
FLAT
eth0
eth2
eth4
R
R
R
eth1
eth3
FLAT1
Cluster
Gateway
Router

• ５つのネットワークインターフェイス:
• eth0 – マネジメントアクセスに利用。IPアドレスはDHCP割り当て、もしくは、手
動で静的に設定
• eth1 (FLAT) – 外部からのL2接続（マネジメントアクセスもしくはデータプレーン
アクセス）に利用。デフォルトで172.16.1.254/24が割り当てられる
• eth2 (FLAT1) -外部からのL2接続（マネジメントアクセスもしくはデータプレーン
アクセス）に利用。デフォルトで172.16.2.254/24が割り当てられる
• eth3 – SNATによる外部L3接続（マネジメントアクセスおよびデータプレーンアク
セス）に利用。デフォルトで172.16.3.254/24が割り当てられる
• eth4 – OpenStackサービスとホスト間通信にシステム内部で利用（設定不可）。デ
フォルトで172.16.10.250/24が割り当てられる
VIRL – ネットワーク接続

• 1.6.55に同梱されるイメージ
VIRLイメージ

• 本家サイト
• http://virl.cisco.com/
• チュートリアル
• http://virl.cisco.com/tutorials.php
• Youtubeチャンネル
• https://www.youtube.com/c/ciscovirl
• コミュニティサポート
• https://learningnetwork.cisco.com/groups/virl
(参考) VIRLレファレンス

virlutils

• Cisco VIRLを便利に使うコマンドラインツール
• VagrantっぽいフィーリングでVIRLを操作できる（virl up, virl down, virl ssh, virl
console, etc.）
Virlutils
https://github.com/CiscoDevNet/virlutils

デモ①
virlutils

• VIRLシミュレーションを起動する
• topology.virlのあるディレクトリにて
• virl up
• もしくは、topology.virlを含むGithubプロジェクトを指定して
• virl up virlfiles/2-ios-router
virl up
$ virl up
Creating default environment from topology.virl

(参考) topology.virl の作成
VM Maestroのデザインパースペクティブから
編集して、「File」-> 「Export」からエクスポート
するのが手っ取り早い

• VIRLシミュレーションの状態を確認
virl ls
$ virl ls
Running Simulations
╒═══════════════════════════════════╤══════════╤════════════════════════════╤═══════════╕
│ Simulation │ Status │ Launched │ Expires │
╞═══════════════════════════════════╪══════════╪════════════════════════════╪═══════════╡
│ network-ci-handson_default_R1gGHs │ ACTIVE │ 2018-11-20T02:30:55.887350 │ │
╘═══════════════════════════════════╧══════════╧════════════════════════════╧═══════════╛

• VIRLノードの状態を確認
virl nodes
$ virl nodes
Here is a list of all the running nodes
╒═══════════╤══════════╤═════════╤═════════════╤════════════╤══════════════════════╤════════════════════╕
│ Node │ Type │ State │ Reachable │ Protocol │ Management Address │ External Address │
╞═══════════╪══════════╪═════════╪═════════════╪════════════╪══════════════════════╪════════════════════╡
│ iosv-2 │ IOSv │ ACTIVE │ REACHABLE │ telnet │ 172.16.30.61 │ N/A │
├───────────┼──────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤
│ iosv-1 │ IOSv │ ACTIVE │ REACHABLE │ telnet │ 172.16.30.60 │ N/A │
╘═══════════╧══════════╧═════════╧═════════════╧════════════╧══════════════════════╧════════════════════╛

• Ansibleインベントリファイル、pyATSテストベットファイル、NSOインベン
トリファイルを生成
virl generate
$ virl generate ansible
Placing iosv-2 into ansible group routers
Placing iosv-1 into ansible group routers
Writing default_inventory.yaml
all:
children:
routers:
hosts:
iosv-1:
ansible_host: 172.16.30.60
console_server: 10.10.20.160
console_port: 17000
iosv-2:
ansible_host: 172.16.30.61
console_server: 10.10.20.160
console_port: 17002
Ansibleインベントリファイルの生成生成されたAnsibleインベントリファイル

• 以下の方法でVIRL環境（IPアドレス、クレデンシャル情報）の設定
（優先順）
• ワーキングディレクトリの.virlrcファイル
• 環境変数
• ユーザーのホームディレクトリの.virlrcファイル
virlutils設定
VIRL_HOST=192.0.2.1
VIRL_USERNAME=guest
VIRL_PASSWORD=guest
$ export VIRL_HOST=192.0.2.1
$ export VIRL_USERNAME=guest
$ export VIRL_PASSWORD=guest
.virlrcの例環境変数の例

PyATS

• Python3ベースのテスト自動化フレームワーク
• Cisco社内のテストフレームワークとして長年培われてきたノウハウ
を凝縮
• DevNetを通じてユーザーに提供
• 製品開発時にCisco内部で使用されているのと同じテスト環境をあな
たの環境で利用できる！
pyATS
https://developer.cisco.com/site/pyats

Cisco pyATS テスト自動化ソリューション
• ネットワークOSに依存しない自動化ライブラリ
• イベントベースの自動化
Genie Library Framework
• トポロジ & テストケースの定義
• 実行 & レポート
pyATS Core Test Infrastructure
• 機能モデル実装
• トリガー、検証、パース、コネクタ等
Genie Libs
• キーワード駆動テスト自動化
• テストスクリプトを宣言的な記述
Robot

• フレームワークの第一の重要な特徴は、フレームワークに合わせて利用者が定義したメソッドが、
アプリケーションコードからは呼ばれず、フレームワークから呼び出されるという点だ
Ralph Johnson and Brian Foote
• フレームワークを呼び出すのではなく、フレームワークに呼び出されるのだ。この現象を「制御の
反転」と呼ぶ(ハリウッド原則とも呼ばれる、「私を呼ぶな。私から呼ぶ」)
Martin Fowler
フレームワークとは
制御の反転あるいはハリウッドの原則
from flask import Flask
app = Flask(__name__)
@app.route("/")
def hello():
return "Hello World!“
if __name__ == "__main__":
app.run(debug=True)

pyATSテストスクリプト構造
COMMON
SETUP
TESTCASE(S) COMMON
CLEANUP
Subsection 2
Setup
Test 1
Test 2
Cleanup
Subsection 1
Subsection 2
Subsection 1

pyATS
from ats import aetest
...
class Testcase_One(aetest.Testcase):
@aetest.setup
def setup(self, section):
log.info("%s testcase setup/preparation" % self.uid)
self.a = 1
self.b = 2
@aetest.test
def test_1(self, section):
log.info("test section: %s in testcase %s" % (section.uid, self.uid))
assert self.a == 1
@aetest.test
def test_2(self, section):
log.info("test section: %s in testcase %s" % (section.uid, self.uid))
assert self.b == 2
@aetest.cleanup
def cleanup(self):
log.info("%s testcase cleanup/teardown" % self.uid)
...
フレームワークのお作法にした
がって、クラスとメソッドを用意

pyATS
フレームワークが適切にメソッドを
呼び出してくれる

• 機能セントリックなオブジェクトモデルを提供
• オブジェクトはプラットフォーム、OSに依存しない
• テスト自動化を加速し単純化
Genie

• showコマンドを実行し、結果の文字列をPythonの
ディクショナリ形式にマッピング（便利！）
Genie
オペレーショナルデータを取得
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
Gateway of last resort is not set
2.0.0.0/32 is subnetted, 1 subnets
B 2.2.2.2 [200/0] via 192.168.12.2, 00:01:27
{'vrf': {
'default': {
'address_family': {
'ipv4 unicast': {
'ip': {
'2.2.2.2/32': {
'nexthop': {
'192.168.12.2': {
'protocol': {
'bgp': {
'metric': '0',
'preference': '200',
'uptime': '00:01:27‘
}
}
}
}
}
}
}
}
}
}
}

Genie 使い方
Genie単体での利用 pyATSでの利用
from genie.conf import Genie
from genie.libs.parser.iosxe.show_interface import ShowInterfaces
testbed = Genie.init('default_testbed.yaml')
ios1 = testbed.devices['iosv-1']
ios1.connect()
parsed = ShowInterfaces(ios1).parse()
# parsed にはディクショナリ形式のshow interfaceの結果
ios1.disconnect()
from ats.topology import loader
from genie.libs.parser.iosxe.show_interface import ShowInterfaces
testbed = loader.load("default_testbed.yaml")
ios1 = testbed.devices['iosv-1']
ios1.connect()
parsed = ShowInterfaces(ios1).parse()
# parsed にはディクショナリ形式のshow interfaceの結果
ios1.disconnect()

pyATSとGenieを組み合わせる
class BgpTestcase(aetest.Testcase):
…
@aetest.test
def check_ip_route(self):
ios1 = self.parameters['ios1']
route = ShowIpRoute(ios1).parse(protocol='bgp', ip='ip')
assert '2.2.2.2/32' in route['vrf']['default']['address_family']['ipv4 unicast']['ip'], 'route missing...'
@aetest.test.loop(device=('ios1','ios2'), prefix=('2.2.2.2/32', '1.1.1.1/32'))
def check_ip_route_loop(self, device, prefix):
ios = self.parameters[device]
route = ShowIpRoute(ios).parse(protocol='bgp', ip='ip')
assert prefix in route['vrf']['default']['address_family']['ipv4 unicast']['ip'], 'route missing...‘
…
iosv-1で2.2.2.2/32の
BGP経路があることを確認
ループ処理も書ける

ネットワークCI

デモ③
ネットワークCI

ネットワークCIテスト
ネットワークをコードとして管理
• トポロジ（VIRL）
• 構成情報（Ansible）
• テスト（pyATS）
Gitリポジトリへ
Push
CIツールが検知し、
CIジョブを実行
仮想テスト環境を
セットアップ
ネットワークの
テスト
構成管理ツールで
ネットワーク設定

• その状態をデータベースに保
存するAPIを備えたWebアプ
リケーションであるGitLab
サーバの機能の一部
• プロジェクトの更新に応じて
CIパイプラインの実行
• CIパイプラインのスタータス
や結果のレポート
Gitlab CI/CD
• （ビルドやテスト等の）CIジョ
ブを実行するアプリケーション
• GitLabサーバと別サーバに配備
され、APIを介してGitLab
CI/CDと連携
• Shell、Dockerコンテナなど
様々なExecutor

実行結果（成功時）

実行結果（失敗時）

(参考) .gitlab-ci.yml
image: tetsusat/network-ci-demo
cache:
untracked: true
key: "$CI_PIPELINE_ID"
stages:
- setup
- deploy
- test
- cleanup
virl_setup:
stage: setup
script:
- virl up
- sleep 120
- virl generate ansible
- virl generate pyats
tags:
- network-ci
ansible:
stage: deploy
script:
- ansible-playbook -i ./default_inventory.yaml
playbooks/config_motd.yaml
- ansible-playbook -i ./default_inventory.yaml
playbooks/config_bgp.yaml
- sleep 60
tags:
- network-ci
pyats:
stage: test
script:
- python3 pyats/bgp.py --testbed=./default_testbed.yaml
tags:
- network-ci
virl_cleanup:
stage: cleanup
script:
- virl down
tags:
- network-ci
VIRLの
セットアップ
Ansibleによる
設定
pyATSによる
テスト
VIRLの
クリーンアップ
パイプライン毎に
キャッシュを有効化

• 「Settings」→「CI/CD」→「Runners settings」
(参考) GitLabプロジェクトとGitLab Runnerの連携
GitLabプロジェクト側の設定

(参考) GitLabプロジェクトとGitLab Runnerの連携
GitLab Runner側の設定
$ sudo gitlab-runner register
Runtime platform arch=amd64 os=linux pid=25942 revision=8af42251 version=11.4.0
Running in system-mode.
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
https://gitlab.example.com/
Please enter the gitlab-ci token for this runner:
********************
Please enter the gitlab-ci description for this runner:
[ubuntu]: network ci demo
Please enter the gitlab-ci tags for this runner (comma separated):
network-ci
Registering runner... succeeded runner=seR7B9LU
Please enter the executor: shell, ssh, virtualbox, docker-ssh+machine, kubernetes, docker, docker-ssh, parallels,
docker+machine:
docker
Please enter the default Docker image (e.g. ruby:2.1):
tetsusat/network-ci-demo
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically
reloaded!
gitlabのURL
Gitlab runnerのタグ
Executorのタイプ
CI Job実行するDockerイメージ
Registrationトークン

(参考) 環境変数の設定

VIRLとPyATSで実現するネットワークCI

VIRLとPyATSで実現するネットワークCI

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to VIRLとPyATSで実現するネットワークCI

Similar to VIRLとPyATSで実現するネットワークCI (20)

Recently uploaded

Recently uploaded (10)

VIRLとPyATSで実現するネットワークCI

Editor's Notes