20140404 vyatta users Group / REST API解説

VYATTA REST-API
Software-Based Networking and Security from Vyatta
1© 2012 Brocade Communications Systems, Inc. CONFIDENTIAL—For Internal Use Only© 2014 Brocade Communications Systems, Inc. Company Proprietary Information

話者紹介
• 菊池之裕（きくちゆきひろ）
• Twitter @yukihirokikuchi
• ISPにてルータ開発の後、IXにて監視アプリ開発、運用、その他一般
(NetNewsとかDNSとか）
• 2010/04より現職
• プリセールスSE兼OpenFlow,OpenStack,仮想化系一般担当
• Vyatta買収後にVyatta Users Group運営委員に
• ユーザとしての立場でのVyattaサポーター
• いまさっき VyOS Users GroupにSubscribeしました。
© 2013 Brocade Communications Systems, Inc. 2

Agenda
• なぜAPIが必要なのか
• RESTful/REST-APIとは？
• REST-APIのユースケース
• VyattaでのREST-API
• デモ
• まとめ
© 2014 Brocade Communications Systems, Inc. Company Proprietary Information 3

なぜAPIが必要なのか
4© 2014 Brocade Communications Systems, Inc. Company Proprietary Information

なぜAPIが必要なのか？
• 自動化
• 省力化
• 外部からのコントロール
• CLIでダメですか?/GUIでも自動化できますけど？

Cloudで自動化できました
• ではネットワーク設定に関しては？
• 動的にサブネットを追加するケース
• Routing設定が必要
• 使用するDCを増設するケース
• VPN設定が必要
• その他
• VMライフサイクル管理だけ自動化できても…
• Network configurationを自動化できる仕組みが必要
VMライフサイクル管理に関しては万全

CLIを模倣するツール
#!/usr/bin/expect
set host www.yahoo.co.jp
set path "/stocks/detail/?code=998407.O"
spawn telnet $host 80
expect “Escape“ #例えば、ここで”escape”と返されると、アドリブが効かず、刺さる
send "GET $path HTTP/1.1¥rHost: $host¥rConnection: close¥r¥r"
expect eof
その名の通りexpectする。Expectしたものが来ないと、Timeoutを待つ
Expectした応答が1字違っても期待通り動作しない
例：expect

APIはCLIとはどう違う？
要は人間相手か機械相手か
Web/CLIは人間相手/これらは機械相手には設計されていない
人間の動作機械の動作
あいまいさ許容する許容しない
画面の見栄え重要不要
データ配置の柔軟性高い極めて低い
エラー処理の柔軟性極めて高い低い
レイアウトの変更問題なし致命的
読めますよね?
機械が苦手とする例
CLI/Webは人間相手なので、そのままでは自動化しづらい
APIは機械相手－最初から自動化を意識している
感動的なexcel方眼紙
http://oku.edu.mie-u.ac.jp/~okumura/SSS2013.pdf

構造化されたtext
• Json
• JavaScript Object Notation
• RESTで標準的に使用される
• JavaScriptとあるが、言語に依存しない
• XML
• eXtemted Markup Langange
• SOAP/NetConfで標準的に使用される
• 言語依存なし
Structured text

エラー処理
• オペレーションは複数のコマンドを含む
• 都度、実行の成否を確認する必要がある
• 単独では用をなさない
• トランザクション実行
• 全部実行するか、まったく実行しないか
• 中途半端な設定投入は回避すべき
その重要性

CLIを模倣する手法の問題点
• CLIの返答はコマンドごとに違う
• Configモードへ移行する場合（応答：”[edit]”がエラーなし）
• 正常応答
• [edit]
• Discardコマンド（応答：最終行”[edit]”がエラーなし（という担保はな
い））
• 正常応答（その1）
• Changes have been discarded
• [edit]
• 正常応答（その2）
• No changes have been discarded
• [edit]
エラーなしのサインは統一されていない

CLIを模倣する手法の問題点（Contd.）
• エラーの例
• Configモードへ移行する場合
• エラーパターン（その1）
• vyatta@vyatta:~$ configuree
• Invalid command: [configuree]
• vyatta@vyatta:~$
• エラーパターン（その2）
• vyatta@vyatta:~$ con
• Ambiguous command: [con]
• Possible completions:
• configure Enter configure mode
• connect Establish a connection
エラーメッセージも千差万別
もちろん、こんなミス（スペルミス）
はscriptでは起きようがない。
ただし、CLI syntaxの変更は予告なく
行われている。
今日動くscriptが次のpatchで正常に動作
する保証はない。
人間ならエラーメッセージに応じて
対処可能なのだが。

APIを使用する場合
• RESTの場合
• HTTPスタータスコードを確認
• 200/201が成功/400だとエラー
• （メッセージがあれば）JSONで記載されている
• JSONは容易にparseできる（たいていのプログラム言語はライブラリが準備されている）
• SOAP over HTTPの場合
• HTTPステータスコードを確認
• 200/400などを確認
• 併せてSOAPエンベロープを確認
• エラーメッセージはSOAP（XML）をparseして確認する（たいていのプログラム言語はライブ
ラリが準備されている）
エラー処理は明確に定義されている

APIを使用する場合
• NetConf over httpの場合
• HTTPステータスコードを確認
• 200/400などを確認
• 併せてXML/YANGを確認
• エラーメッセージはXMLをparseして確認する（たいていのプログラム言語はライブラリが準
備されている）
エラー処理は明確に定義されている

APIの約束
• 下位互換性を基本的に担保
• 仕様は変更されうるが、影響を最小限に抑える形で変更される
• ライブラリ側で吸収できるような変更のみ
• エラーコードの変更は行われない
• ステータスコードを基準にしてエラー処理が可能
• メッセージは変更されうるが、これが変更されてもAPI経由の動作は影響を受けない
• Versioning
• Versionを明記することで下位互換性を保持
下位互換性

RESTful/REST-APIとは？

RESTfulとは？
• では、RESTとは？
（WikiPediaより抜粋）
• Representational State Transfer(REST) は、ウェブのような分散ハイパーメ
ディアシステムのためのソフトウェアアーキテクチャのスタイルのひとつ
である。この語は2000年に、HTTPプロトコル規格の主要著者の一人であ
るen:Roy Fieldingが、ウェブについて書いた博士論文で初めて現れ、ネッ
トワーキングコミュニティの中ですぐに広く使われることになった。
RESTは、初めはアーキテクチャの原則と制約の集まり(後述)を指していた
が、次第に、XMLやHTTPを使った簡易なウェブベースのインターフェイス
のうち、WebサービスのSOAPプロトコルのような MEP（Message
Exchange Pattern; SOAPノード相互のメッセージ交換のパターンを確立する
ための雛型）ベースの特別な抽象化をしないもののことを、大まかに意味
する用語として使われるようになった。
REST原則に従うシステム(WikiPediaより）

RESTとは（Contd.）
• 広義にはHTTP-GETで状態を確認できるWebサービス
• 種々のオペレーションを数種類のHTTPのメソッドにマッピング
• GET/POST/PUT/DELETE
• ステートレス
• 既存httpインフラとの親和性
• それぞれのオペレーションは一意なURIでマッピングされる
• URIにターゲットが含まれる
• POST rest/conf/67FA7AB2053C1FF2/show/interfaces/ethernet/eth0
• 容易な類推
極論覚悟でまとめると…

SOAP/Netconfとはどう違う？
• SOAP/Netconfはメッセージ転送プロトコルに依存しない
• http(s)/ssh,etc（機器の実装に依存）
• エラー確認はSOAP/YANGをフォーマットを解釈する必要あり
• 下位メッセージ転送レイヤでのエラーコードだけではエラーの確認はできない
• RESTはhttpに依存
• http(s)を利用
• httpステータスコード（400/200/etc.）で実行の可否を判別可能
• Error stringはHTTPbody（json）で提供
RESTのプロトコル構造
HTTP
REST(json)
HTTP ssh Etc.
SOAP Envelope
ssh Etc.
YANG
REST SOAP NetConf
HTTP

RESTfulとは（Contd.）
• curl/wgetのようなCLI-webブラウザで操作可能なAPI
• もちろんwebブラウザのプラグインでも操作可能
• Ex.)Firefox-requester/poster,etc.
• 容易な開発/デバッグそして理解
• 学習コストの低さ
• 各種ツールを利用可能
• ブラウザベース/各種言語のライブラリ
• エラーハンドリングの容易さ（HTTPステータスコードで判別して例外処理）
• HTTPとの親和性
• Proxy/firewallなどへの追加設定は不要
さらに突き詰めれば

VyattaでのAPI実装

Vyatta OS Architecture
Linux Kernel with Multi-Platform Virtualization Drivers
Routing Firewall NAT VPN QoS IPv6
Vyatta Data Model
CLI API GUI

Vyatta OS Architecture
Linux Kernel with Multi-Platform Virtualization Drivers
Routing Firewall NAT VPN QoS IPv6
Vyatta Data Model
CLI API GUI
ココ！

RESTFul-APIのユースケース
• アクション
• 仮想マシン群を新規の別サブネットに配備して、routerで接続する
（仮想マシンのサブネットは動的に決まるため、routerのconfigも追従する必
要がある）
• その手順（例）：
• Vattaの立ち上げ（ここまではHyperVisorの役割）
• VyattaのMgmt InterfaceにはIPが前もってアサインされている
• ここからRESTFulの出番
• Vyattaにconfigを投入する（IP Interfaceの作成、routingの設定など）
• 必要に応じてconfigを更新してsaveする
オーケストレーションレイヤとの連動（その1）

VyattaでのREST-API
• POST /rest/conf
• （ここでconf-id取得）
• 同等なCLI：$configure
• PUT /rest/conf/<conf-id>/set/<path>
• 同等なCLI：#set …
• POST /rest/conf/<conf-id>/<cmd>
• 同等なCLI：#commit,save,etc
• GET /rest/conf/<conf-id>/<path>
• 同等なCLI：#show
その流れ（configモード）

VyattaでのREST-API
• GET /rest/conf
• 同等なCLI：N/A
• （現在走っているセッションを確認）
• DELETE /rest/conf/<conf-id>
• 同等なCLI：exit
その流れ（configモード）:Contd.

デモ

クラウド環境でのデモ
• さくらのクラウド ⇔ Cloud(n) 間でVPN構築
• RESTでやってみます。

ネットワーク環境
• REST
10.1.0.1/24
OpenVPN
RESTで設定、クラウド間VPNを構築
10.0.0.1/24
10.0.0.100/24
153.149.38.46

実際のオペレーション
• Configモードへの移行
$ curl -k -s -i -u vyatta:vyatta -H "content-length:0" -H "Accept: application/json" -X
POST http://192.168.1.202/rest/conf
HTTP/1.1 201 Created
Content-Type: application/json
Location: rest/conf/45F76296CD266AFE <=これが<conf-id>
…後略
Curlの例
まず、conf-idを取得します。
以後、これを通してコンフィグレーションを行います

まとめ

まとめ
• REST-APIはユーザフレンドリ
• テスト/開発/デバッグ/デプロイが容易
• 外部から機器をコントロールするための標準手法
• 各言語のライブラリを使用可能(Python,Ruby,Perl,….)
• 他システムとの統合(OpenStack,CloudStack,etc..)
• 自製ツールへの組み込み
• 自動化による工数削減
• 統一されたエラーハンドリングによる開発効率の向上
• DevOps / Immutable Computing が可能に
REST-API

THANK YOU

20140404 vyatta users Group / REST API解説

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à 20140404 vyatta users Group / REST API解説

Similaire à 20140404 vyatta users Group / REST API解説 (20)

Plus de Yukihiro Kikuchi

Plus de Yukihiro Kikuchi (8)

20140404 vyatta users Group / REST API解説