josug2014 openstack 4th birthday party in japan; the way of openstack api dragon

“the Way of the OpenStack API Dragon”

(2014/07/09, Shibuya GMO yours)

GMOインターネット株式会社

システム本部　第2サービス開発部

オープンコンピューティングチーム　郷古直仁　

openstack!Open source software to build public and private clouds.

OpenStack !4th Birthday party

“the Way of the OpenStack API Dragon”!~GMOアプリクラウドのAPI公開への道~


Atlanta Summitから話題の “Chuck Norris” もともとUSではもうすでに慣用句らしい (wikipedia: チャック・ノリス・ファクト)

なんで、the OpenStack API Dragon !??


名誉海兵隊員だったりチェーンソーを素手で受け止めたりするけど、最近では “炎のテキサスレンジャー” 有名な初期の出演作は “ドラゴンへの道”

なんで、the Way of the OpenStack API Dragon !??


ということで、OpenStackのAPIをPublic Network(the Internet)に公開して、セキュリティを設定して利用できるようにすることを、この場では “the OpenStack API Dragon” と設定します :)

なんで、the Way of the OpenStack API Dragon !??


Atlanta summitのops MeetupでAPI Endpointをどうやって守るって話題があったみたいです !

Atranta summit ops Meetup http://www.slideshare.net/inouetmko/josug20140619

the OpenStack API Dragon は

http://www.slideshare.net/inouetmko/josug20140619


API Endpointを守る(Layer 7) Examples) ops Meetupより - mod_security - nginx - NetScaler etc.

the OpenStack API Dragon は


弊社環境でも同じようにやっています !GMOアプリクラウドのOpenStack Havana環境ではこんな感じ !

API Endpointを守る(Layer 7) - nginx - HAProxy

API Endpointを守る(Layer 7)


今日のLT内容

きょうは、清楚かわいい座敷わらしが応援団長のVPSのConoHa(Grizzly)の話ではなく、


アザトかわいいといわれる座敷童が応援団長の「GMOアプリクラウド」がオンプレミスの仮想化から、　OpenStack Hava を採用して、OpenStack APIを使えるようにした”ドラゴンの道”のお話

今日のLT内容:GMOアプリクラウドOpenStack API公開について


1) 課金処理が量計式ではなく、コントロールパネル(web GUI)の処理に依存 (nova bootとか無理) 2) 裏の会員処理と紐付いたコントロールパネル用のWrapper API(RESTful)を作りこんでしまった (OpenStack APIとは形式違うw) 3) OpenStack自体にも手を入れすぎちゃった (HP Cloudの真壁さんのお話、参考になる)

では、なぜConoHaではOpenStack APIが公開できなかったの?


たとえば、2) コンパネ用API(RESTful) by ConoHaこんなかんじに、全く違うAPIでweb GUIが動き、その裏でOpenStack APIがcallされているのがConoHa


ConoHa コンパネとAPI proxy, OpenStack APIConoHaコンパネAPIのアクセスの関係はこんな感じ !できれば、今後は”コンパネAPI”と”公開API”の二重開発みたいなことは避けたい

コントロールパネル (IIS, .Net)

API Proxy (httpd, php Framework: fuel php)

Grizzly Nova API

会員システムAPI

Grizzly Quantum API

Grizzly Glance API

ConoHaコンパネAPI

会員DB

Grizzly Keystone API

OpenStack API


そして、OpenStack Havanaでの開発”GMOアプリクラウド”のOpenStack Havana化 !それまでの反省から、ほとんどの操作系をOpenStack APIのまま web GUIのコントロールパネルを開発することになった

=>> その代わり、API公開を前提に、OpenStack APIのValidation checkをコンパネのためにも作ることに


1) OpenStack API validation proxy for webGUIAPI公開前提でConoHaで作ったコンパネAPIではなく、OpenStack APIそのものにValidation checkを ”OpenStackの改変せずに” 実装する =>> API Proxy方式

web GUIでも、API公開でも間違った値では、APIに到達する前にエラーを返す(ex: 商品スペックにないストレージサイズとか) => API workerの負荷コスト削減


1) OpenStack Havana API validation proxy for webGUIGMO Apps CloudのOpenStack APIのアクセスの関係はこんな感じ

コントロールパネル(httpd, php)

API wrapper proxy (httpd, php Framework: fuel php)

Havana Nova API


Havana Quantum API

Havana Glance API

OpenStack API for input validation

会員DB

Havana Keystone API

OpenStack API

Havana Cinder API

Havana Ceilometer API

=>> コンパネが公開後のOpenStack APIと同じものにアクセスする想定で構成


1) OpenStack Havana API validation proxy for API公開GMO Apps CloudのOpenStack APIのアクセスの関係はこんな感じ

コントロールパネル(httpd, php)

API wrapper proxy (httpd, php Framework: fuel php)

Havana Nova API


Havana Quantum API

Havana Glance API

OpenStack API for input validation

会員DB

Havana Keystone API

OpenStack API

Havana Cinder API

Havana Ceilometer API

=>> コンパネが公開後のOpenStack APIと同じものにアクセスする想定で構成

Endpoint L7:reverse proxy

Havana Swift Proxy


1) OpenStack Havana アプリクラウド公開APIというわけで、2014/07/08にbetaとしてまずは公開しました http://cloud.gmo.jp/docs !

コンパネから使えるOpenStack APIを公開した(client API)ので、少ないです API: 31個

http://cloud.gmo.jp/docs


1) OpenStack Havana アプリクラウド公開API


2) 公開API Endpointのセキュリティ対策

Endpoint L7:reverse proxy

そして、API Endpointの部分 => 公開なので、できればTCP 80 or 443で !!!SSL(https): reverse proxyにやらせる (SSL Termination) !=> https(443 port)にしただけで、かなり変なアクセスはなくなる


2) 公開API Endpoint: Reverse Proxyの選択Reverse proxyにはたくさん種類 - nginx (ver. 1.6.0) - HAProxy (ver. 1.5.0) 他:Varnish, apache mod_proxy, etc. その中でもこの２つをなぜ選んだ? !

=> 使い分け、適材適所、SSL可能


2) 公開API Endpoint: Reverse Proxy: nginxnginx (ver. 1.6.0) - lua, mrubyと組み合わせたりできる(要rebuild) - 標準buildでもそこそこL7のロジックが書ける (公式 rpm repositoryのbuild) !欠点: request自体をtemporary dirにキャッシュしてからバックエンドに転送処理する => Glance image upload, Swiftなどのdata streamには向かない (ex: 5GBのSwiftのupload: nginxのサーバ上に5GBのファイルが作成される)


2) 公開API Endpoint: Reverse Proxy: HAProxyHAProxy (ver. 1.5.0) - ver. 1.5.0からSSL可能 - OpenStackでの構成でもLBaaSでも使われるのでお馴染み - そこそこ、ルールが書ける - socket to socketで処理するので、nginxのようなtemporary fileを作らない => Glance image upload, Swiftなどに適用可能 !欠点: config fileはinclude機能がない、”-f”オプションで複数ファイル指定はできるみたいだけどまた、細かいロジックはnginxに負ける


2) 公開API Endpoint: Reverse Proxyの適用下記のように適用しています - nginx (ver. 1.6.0) - keystone: host filter, URI filter(API), SSL Termination, request limit filter (1MB, 3r/s) - nova: host filter, URI filter(API), SSL Termination - neutron: host filter, URI filter(API), SSL Termination - cinder: host filter, URI filter(API), SSL Termination - glance: host filter, URI filter(API: list images), SSL Termination - HAProxy (ver. 1.5.0) - Swift: host filter, URI filter, SSL Termination !!!!


2) 公開API Endpoint: Reverse Proxy: swiftHAProxy (ver. 1.5.0)適用 [root@ext-obj-reverse-proxy haproxy]# cat haproxy.cfg | grep -v '#' global log 127.0.0.1 local0 maxconn 131072 user haproxy group haproxy daemon stats socket /var/run/haproxy.sock mode 600 level admin stats timeout 2m tune.chksize 16384000 tune.bufsize 16384000 !!!!!!


2) 公開API Endpoint: Reverse Proxy: swiftHAProxy (ver. 1.5.0)適用 defaults log global mode http option log-separate-errors log-format [%pid]\ [%Ts.%ms]\ %ac/%fc/%bc/%bq/%sc/%sq/%rc\ %Tq/%Tw/%Tc/%Tr/%Tt\ %tsc\ %ci:%cp\ %fi:%fp\ %si:%sp\ %ft\ %sslc\ %sslv\ %{+Q}r\ %ST\ %b:%s\ "%CC"\ "%hr"\"%CS"\ "%hs"\ req_size=%U\ resp_size=%B option dontlognull retries 3 option redispatch maxconn 2000 contimeout 5000 clitimeout 50000 srvtimeout 50000 option forwardfor !


2) 公開API Endpoint: Reverse Proxy: swiftHAProxy (ver. 1.5.0)適用 listen hastats *:10080 mode http maxconn 64 stats enable stats uri /hastats stats realm Haproxy\ statistics stats auth system:hogehogepass stats refresh 10s !frontend https_frontend bind *:443 ssl crt /etc/ssl/certs/ast.app-sys.jp/ast.app-sys.jp-haproxy.pem mode http acl is_v1_api url_beg /v1 acl host_s3 hdr(host) -i swift3-r1nd1001.app-sys.jp acl host_swift hdr(host) -i objectstore-r1nd1001.app-sys.jp acl host_ote_s3 hdr(host) -i ote-swift3-r1nd1001.app-sys.jp acl host_ote_swift hdr(host) -i ote-objectstore-r1nd1001.app-sys.jp reqadd X-Forwarded-Proto:\ https


2) 公開API Endpoint: Reverse Proxy: swiftHAProxy (ver. 1.5.0)適用 use_backend swift_proxy_server if is_v1_api use_backend swift_proxy_server if host_s3 use_backend swift_proxy_server if host_swift use_backend repos_server if host_repos default_backend null_server !backend swift_proxy_server mode http balance leastconn option httpchk HEAD /healthcheck HTTP/1.0 option forwardfor server s1 10.199.199.91:8080 weight 10 check inter 2000 server s2 10.199.199.92:8080 weight 10 check inter 2000 !backend null_server mode http option httpchk HEAD / HTTP/1.0 option forwardfor server n1 127.0.0.1:18080 check inter 2000


2) 公開API Endpoint: Reverse Proxy: swiftHAProxy (ver. 1.5.0)適用 !

こんな感じ !


3) API versionの固定, JSONAPI versionでURI filterで固定して通しています。 !また、APIのrequest/responseフォーマットをJSON(Default)で固定しちゃいました => XMLの処理を今は作ってない => http://developer.openstack.org/api-ref.html でもXML見掛けなくなった !!!

Format Accept Header Query Extension ある場合

Default

JSON application/json .json Yes

XML application/xml .xml No

http://developer.openstack.org/api-ref.html


3) JSONのみだとマ…マズイ…(Ｔ～;Ｔ)Swift: << keystoneアクセスがXMLで実装されたクライアントソフトが意外に多い (ex: CloudBerry Explorer) !- S3 API module: swift3と同時に使われる場合があるのでXML必要な場合 - S3 clientとして先に作っていたclientのOpenStackへのportingの場合、XMLのみの実装になっていることも !!


API公開での “the Way of the OpenStack API Dragon”はbetaなんで… と言いつつも、動かないものがあったりとか !ex) python-cinderclient version違いで動いたり… version. 1.0.7) 動く version. 1.0.9) 動かない(Icehouse client) => endpoint のparseがうまく行ってない? !API Proxyでのパラメータ変換? JSONの構成が違うのかな


API公開での “the Way of the OpenStack API Dragon”はということで - Validation check - L7:Reverse Proxy(Private Cloudでも利用可能) でAPI Endpointを防御して、運用しています

!“the Way of the OpenStack API Dragon” !!俺達の戦いはこれからだ


API公開での “the Way of the OpenStack API Dragon”は

終劇