Google Compute Engine を軽く使ってみた感想
はじめに
こんにちは、 yosida95 です。 2ヶ月ぶりのブログエントリです。 生存しています。
Google Compute Engine
現在開催中の Google I/O で Google の IaaS 、 Google Compute Engine の Preview 版の一般公開が発表されました。 関連記事:Google、IaaSの「Google Compute Engine」プレビュー版を一般公開
Amazon Web Services の EC2 の対抗馬として騒がれているので、どんなものか学校の試験期間中の暇な時間を活かして軽く触ってみました。
Web コンソール
Google Compute Engine には Web コンソールが用意されていて、インスタンスの作成などの操作はこの Web コンソール上で行う事ができます。 しかし、この Web コンソールは必要最小限の説明や機能しかありません。 従って、 Amazon Web Services の EC2 の使い勝手に慣れていると、随分と見劣りします。
また、プルダウンメニューがページのスクロールと干渉して、目的のメニューを選ぶことが難しいく、使い勝手悪いです。
まぁ、「 REST API を用意したから開発者ならこれを使えや」という事なのでしょう。 ぼくにとってはそれで十分なので、特に文句ないです。
REST API
インスタンスの作り方
REST API 操作の例として、インスタンスの作成方法を紹介します。 REST API 操作例としてインスタンスの作成方法を紹介出来れば良いのですが、それを書くにはブログはあまりにも狭すぎるので、ある Zone(データセンター) で稼働中のインスタンスの一覧を取得してみます。
OAuth 2.0
詳しくは Google のドキュメントを読んで下さい。
Google の各種 API は、認可プロトコルとして OAuth 2.0 が採用されており、 Google Compute Engine も例外ではありません。
まずは、前準備として Google API Console から、 Google Compute Engine 用の ClientID と ClientSecret を取得してきます。
次に、 Google アカウントにログインした状態で、以下のルールで組み立てた認可用 URI を踏み、アクセスを許可して Verifier を入手します。
https://accounts.google.com/o/oauth2/auth?client_id=${ClientID}&scope=https://www.googleapis.com/auth/compute&response_type=code&redirect_uri=${RedirectURI}
次の POST リクエストをしてアクセストークンを取得します。 (例として curl からリクエストしています。 )
$ curl -d client_id=${ClientID} -d client_secret=${ClientSecret} -d redirect_uri=${RedirectURI} -d grant_type=authorization_code -d code=${Verifier} https://accounts.google.com/o/oauth2/token
成功すると、 JSON で access_token が返ってくるので、これを保存します。
インスタンスの一覧を取得する
curl -G -H "Authorization: OAuth ${access_token}" https://www.googleapis.com/compute/v1beta14/projects/{$ProjectID}/zones/${Zone}/instances
というように、 https://www.googleapis.com/compute/v1beta14/projects/{$ProjectID}/zones/${Zone}/instances に Authorization ヘッダ付きで GET することで、指定した Zone で稼働中の、指定したプロジェクト用のインスタンスの一覧が JSON で取得出来ます。
ここまでに書いた事柄のより詳しい内容は、 Google Compute Engine の REST API ドキュメントを見ればわかります。
gcutil
ここまで、苦労して REST API の操作方法を書いて来ましたが、なんと Google Compute Enigne には Google 謹製の REST API クライアントがあります。 これは、 Python 製のコマンドラインツールで、 REST API を使った操作の全て(多分) を行えます。
プログラムで仮想マシンを操作する必要がないのであれば、この gcutil を使えばよいと思います。
思ったことなど
- OS の選択肢が少ない
- 現状選択可能な OS は CentOS と Debian Linux
- Ubuntu Server は以前は使えた痕跡が有ったが、削除されていた
- 個人的に Debian Linux は好きなので別に文句とかは無い
- Amazon Web Services の EC2 に見劣りする
- 現状選択可能な OS は CentOS と Debian Linux
- 初めてのインスタンスを作ってから SSH 接続するまでが長い
- gcutil を使って ssh 接続をすると、認証用の鍵ペアの作成に始まり、(どうやら)インスタンス上に gcutil の実行ユーザーと同名のユーザーを作って、 ~/.ssh/authorization_keys に作った鍵を追加している
- Amazon Web Services の EC2 ではまず認証用の鍵ペアを生成して、その鍵がすでに ~/.ssh/authorization_keys に追加された状態でインスタンスが立ち上がってくる
- でも、 EC2 の場合は、ユーザー名が固定されているから、普段使っている愛着のある名前のユーザーをつくる手間が省けるのは良いかも
- gcutil を使って ssh 接続をすると、認証用の鍵ペアの作成に始まり、(どうやら)インスタンス上に gcutil の実行ユーザーと同名のユーザーを作って、 ~/.ssh/authorization_keys に作った鍵を追加している
- よりハードウェアっぽい
- IaaS として VCPU の数やメモリの量が選べるのは当然のことだが、 Google Compute Engine では、小さなプランを選ぶと、 "Shares physical core" などと出て、ホストマシン上でインスタンスがどのように動くかの情報が分かるので、仮想化ボーイとしては面白い
- でも、 EC2 の方がちゃんと抽象化できている、とも言える。
- IaaS として VCPU の数やメモリの量が選べるのは当然のことだが、 Google Compute Engine では、小さなプランを選ぶと、 "Shares physical core" などと出て、ホストマシン上でインスタンスがどのように動くかの情報が分かるので、仮想化ボーイとしては面白い
- まだまだベータ
- つくれるインスタンスの量(というか、 VCPU の数)が制限されている
- 今後正式版がローンチされる事が楽しみ
- だけど、ぼくはゆとり開発者なのでこのままの Google Compute Engine なら、 Amazon Web Services の EC2 に甘やかされ続けたい。
以上です
REST API の使い方説明しようと思ったら、分量の大半を OAuth 2.0 の認可ステップに費やされた。。。