ホスティングパッケージでAPIを提供開始

カテゴリー: サービス情報, ホスティングパッケージ   パーマリンク
このエントリーをはてなブックマークに追加

IIJ GIOのパブリッククラウドサービスである「IIJ GIOホスティングパッケージサービス」にようやくAPI(Application Programming Interface)をお届けすることができました。既に2013年9月24日から提供が始まっていますので、ぜひご利用ください。利用方法やAPIの機能などについて詳しくはリファレンスマニュアルが用意されています。

How to play

さて、APIとは何か、APIを使うと何が便利なのか、と言った話はGIOろぐ読者には不要でしょうけれど、サンプルプログラムを動かすまでの手順をご覧にいれましょう。必要な作業は2つだけです。認証用のキーを生成することと、サンプルプログラムのキーを書き換えることです。

まず、IIJ GIOのサーバ管理と同じようにIIJサービスオンラインにログインしてください。そして、「サービスの設定と管理」画面からgpのサービスコードを選択してください。すると、画面右上に「APIの設定と管理(アクセスキー管理)」というリンクが追加されています(https://help.api.iij.jp/へ直接アクセスしても大丈夫です)。まずはここで「アクセスキーを追加する」をクリックしてください。これでアクセスキーとシークレットキーがペアで生成されます。

アクセスキー管理画面

アクセスキー管理画面
(クリックすると拡大表示します)

次にサンプルプログラムを展開して、動かしてみましょう。API Referenceの解説に従ってサンプルプログラムを入手して展開したら、下記のとおりに3つの環境変数を設定してください。IIJAPI_ACCESS_KEYとIIJAPI_SECRET_KEYには先ほど作成したアクセスキーとシークレットキーを設定します。

例: API呼び出しに使う環境変数の設定
$ export IIJAPI_ACCESS_KEY=’<アクセスキー>’
$ export IIJAPI_SECRET_KEY=’<シークレットキー>’
$ export IIJAPI_ENDPOINT=’https://gp.api.iij.jp/json’

では、いよいよAPIを呼び出してみましょう。まずは設定が正しいかどうかを確認するために、Echoスクリプトを下記のように実行してみてください。

$ ./Echo IIJGIO

すると、下記のようにJSON形式でレスポンスが表示され、Paramの値としてコマンドラインに指定した文字列が入っていることが確認できるはずです。もしこれが動かないようであれば、先の環境変数の設定が間違っているか、gp.api.iij.jpへネットワークの疎通がないか、ローカルマシンの時計が大幅に狂っているか、なんらかの問題がクライアント側にあるはずです。

{“EchoResponse”:{“RequestId”:”b971c3ee-cb79b562-f55a62fa-000009fa-8fd7668c”,”Param”:”IIJGIO”}}

さて、Echoさえ動けばあとは苦もなく他のスクリプトも動くはずです。今度は契約している仮想サーバなどの一覧を表示するGetServiceCodeListを実行してみましょう。

$ ./GetServiceCodeList
{“ErrorResponse”:{“RequestId”:”7670c3ee-c779b562-ae5862fa-000035bc-96d7668c”,”ErrorType”:”ParameterError”,”ErrorMessage”:”There are invalid parameters.”}}

おっと。エラーメッセージが表示されてしまいました。これは契約を表すgpで始まるサービスコードをパラメータに指定しなかったからです。次は正しくパラメータを指定して実行してみましょう。

$ ./GetServiceCodeList gp10693841
{“GetServiceCodeListResponse”:{“RequestId”:”7e74c3ee-c779b562-ae5862fa-000002bc-97d7668c”,”CustomerCode”:”SG4645283″,”GpServiceCode”:”gp10693841″,”GcServiceCodeList”:[“gc10694695″,”gc10745311″,”gc10748442″,”gc11713487″,”gc11893660″,”gc11969433″,”gc11969440″,”gc11969549″,”gc11969662″,”gc11969679″,”gc11969686″,”gc11969693″,”gc12305797″,”gc12305803″,”gc12319626″,”gc12539840″,”gc12539857″,”gc12539864″],”GnbServiceCodeList”:[“gnb11969709″],”GxServiceCodeList”:[“gx10694848″],”GlServiceCodeList”:[“gl12543809″],”GvmServiceCodeList”:[],”GvsServiceCodeList”:[],”GomServiceCodeList”:[“gom11893653”]}}

はい、今度はうまくいきました。なんだかゴチャゴチャしていますが、JSON形式でサービスコードの一覧を入手することができました。

以上でひとまずサンプルプログラムの使い方は終了ですが、最後に注意をひとつ。今実行したAPIの呼び出しには最初に取得したアクセスキーとシークレットキーが使われています。そして、このキーは発行に利用したマスターID(例:SA12345678)にリンクされており、操作できるIIJ GIOのリソース(仮想サーバやロードバランサなど)は該当するマスターIDで管理できるものに限られるのです。つまり、発行したキーがマスターIDの権限を引き継ぎ、管理できるリソースが制限されているというわけです。更に、仮想サーバを追加するような契約行為を伴うAPIを利用するには、サービスグループの管理権限を備えたマスターIDでキーを発行する必要があります。

SAアカウント

マスターIDとリソースの関係

Sakaguraプロジェクト

こうして遅ればせながらAPIをお届けすることができたわけですが、いたずらに時間をかけていたわけではありません。IIJが提供するあまたのサービスでAPIを提供できるように、更にはその先でも活用できるように、汎用的なAPIプラットフォームを独自に設計、実装してきたからです。そして、そのプラットフォームを利用する第一弾がIIJ GIOホスティングパッケージサービス向けAPIだったという背景があるのです。安定性が高く、スケーラビリティを備え、高性能で汎用的なプラットフォームを生み出すためにだいぶ遠回りをしてしまいましたが、おかげさまで自信を持って提供できるものができました。そのプラットフォームの名前はSakaguraといいます。

このAPIプラットフォームが今後様々なサービスで利用されていく予定ですが、まずは

などのサービスからAPI提供を進めていく計画です。IIJ GIOだけでなくこうしたサービスでもAPIの提供が始まると、例えばWebサーバを立ち上げ、ドメインを取得し、ゾーンを整え、CDNサービスを前段に備えた大規模コンテンツ配信サイトの構築がAPIだけで実現します。
と言いつつ、IIJ GIOのAPIを使って仮想サーバの追加はできても、その仮想サーバ上でWebサーバを構築することまではできないと思われる鋭い方もいることでしょう。確かにそのとおりなのですが、実は今回のAPI提供に合わせてCentOS 6のイメージにchefが標準で含まれるようになりました(/opt以下をご覧ください)。chefを使いこなすには少々の慣れは必要ですが、APIと合わせて使いこなせば大変強力なツールになります。更には、これらツールを統合してクラウドリソースをマネージメントするべくItamaeプロジェクトというものも準備中ですが、これについてはまた日を改めて。

それから、APIプラットフォームであるSakaguraとは何物か、どういった仕組みで構成されているのか、興味を持っていただけた方もいることでしょう。それについてはよりテクニカルに突っ込んだ話題がふさわしい場で、もう一度お話しさせていただく予定です。少しだけお待ちください。

(プロダクト開発部 田口)

コメントは受け付けていません。