CloudGarageのAPIを使ってみた!
この記事は#CloudGarage Advent Calendar 2018 22日目の記事です。
こんにちは。犬飼大貴(@kanna_1go)という人です。どこにでもいるような学生です。
かなり寒くなってきましたね。私は2か月くらい体調を崩してしまっているので、無理せず行きたいと思います。
<del>Zabbixでサーバ監視してないで、自分にエージェント入れて監視してもらえってね...えぇ...</del>
6日目の記事でCloudGarage開発チームから、APIの提供を開始したことがアナウンスされました。
せっかくなので、ちょっと触って気づいたことを記事にしたいと思います。
API利用に必要なAPIKeyとTokenの発行
API機能のほとんどでTokenを使った認証を必要としています。
TokenはAPIKeyで認証して発行します。
API リファレンス等でも触れられていなかった気がするのですが、Tokenの有効期限は発行してから12時間です。
一度発行したら、再発行するまで使いまわせるものではないです。
PythonでAPIにリクエストするプログラムを書いてみているのですが、実行時に毎回Tokenを再発行する処理を書くことで、手動でTokenを書き換えるといったことをしないようにしています。
再発行すると過去のTokenは失効してしまうので、curl等でリクエストして検証しつつ、再発行を自動化したプログラムでも実行といったことをしているとかなり不便かもしれません。
個人的には、APIKeyを発行してさらに期限付きのTokenを発行して利用というのは使いにくいなと思いました。
CloudGarage Public API リファレンス
これから改善されていくと思いますが、全体的に説明不足な印象を受けました。
例えば、APIを利用してインスタンスのパワーオン・オフ等を実行したいとします。
API リファレンスで該当する機能はこちらになります。
serversのキー説明を見てみると、serversキーはUUIDでインスタンスを指定できることがわかります。なるほど。
では、自分のインスタンスのUUIDをAPIから調べてみようと思います。
該当機能はこちらです。
Responsesの例を見てみます。
うーむ、どれでしょう...idと含まれているのが2つありますね...contract_idが契約IDであることは別の機能でわかるので、idがUUIDっぽいですかね...といった感じに推測する必要があります。
あとは、リファレンスというよりはAPI自体の仕様だと思いますが、同じ意味を持ったキーでも機能ごとにキー名にばらつきがあると思いました。
UUIDで見てみるとこうなります。
| HTTPメソッド | URL | 説明 | キー |
|---|---|---|---|
| GET | /servers | インスタンスの一覧情報取得 | id |
| POST | /servers | インスタンス作成 | resource_id |
| POST | /servers/operate | インスタンス操作 | servers,resource_id |
| GET | /servers/{resourceId} | インスタンスの詳細情報取得 | resourceId,id |
| DELETE | /servers/{resourceId} | インスタンス削除 | resourceId |
| GET | /servers/{resourceId}/autoBackup | 自動バックアップの設定情報取得 | resourceId |
| GET | /servers/{resourceId}/security | インスタンスの接続許可設定情報取得 | resourceId |
全体的にはresourceIdが多いですがidやserversもあります。
もちろん触ってみればUUIDだということはわかりますが、id=UUIDといった解説がリファレンスに盛り込まれるとわかりやすくなるかなと思いました。
最後に
実際に触ってみて、一括でサーバを制御したり、構築したりできるのはかなり便利でした。
機能拡充も含め、これからのアップデートが楽しみです。
そういえば、Dev Assist Program(DAP)のバナーがあるのですが、
CloudGarageロゴのシャツ来てる人私なので、使ってもらえると喜びます！
記事書くとき等にぜひご活用くださいー。
現場からは以上です。
※中の人でもなければインターンでもないです！
