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より）


http://ja.wikipedia.org/wiki/World_Wide_Web

http://ja.wikipedia.org/wiki/%E3%83%8F%E3%82%A4%E3%83%91%E3%83%BC%E3%83%A1%E3%83%87%E3%82%A3%E3%82%A2

http://ja.wikipedia.org/wiki/%E3%83%8F%E3%82%A4%E3%83%91%E3%83%BC%E3%83%A1%E3%83%87%E3%82%A3%E3%82%A2

http://ja.wikipedia.org/wiki/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81%E3%83%A3

http://ja.wikipedia.org/wiki/Hypertext_Transfer_Protocol

http://en.wikipedia.org/wiki/Roy_Fielding



http://ja.wikipedia.org/wiki/Extensible_Markup_Language

http://ja.wikipedia.org/wiki/Web%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9

http://ja.wikipedia.org/wiki/Web%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9

http://ja.wikipedia.org/wiki/Simple_Object_Access_Protocol

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


Internet

20140404 vyatta users Group / REST API解説