(詳細はこちらを参照: ESG Lab White Paper "Price Comparison: Google Cloud Platform vs. Amazon Web Service

この分析では、私達がずっと主張し続けてきた TCO における優位性のほか、ESG が新たに着眼した複数の点でその正当性が実証されました。

正直なところ検証結果を見てひと安心しました。 聡明で探求心のある人に成果物をチェックしてもらい、太鼓判を押してもらうのはいつだってうれしいことです。

ESG の調査資料は明確でわかりやすい上に情報がたくさん詰まっています。クラウドの複雑な TCO の理解に苦労している方はお読みいただくことをお勧めします。皆さまのご意見のほか、他にどんな比較や評価が意思決定のプロセスに役立っているか、体験談もぜひお知らせください!


-Miles Ward, Global Head of Solutions, Google Cloud Platform

Google Cloud Storage Nearline の目標は、単純、低コストで反応が早く、バックアップ、検索、データアクセスが素早いストレージサービスを企業や組織に提供することです。(過去の Nearline に関する記事を参照)

ユーザーが作り出すデータの量が増えていることを考えると、企業、組織がデータを死蔵するようになってきていることは意外なことではありません。企業はもうデータを捨てることなど許されないのです。実際、集めたデータを分析して市場についての知識を獲得し、競争力を維持することは、企業にとってきわめて重要になっています。

初めてリリースされた頃、Google Cloud Storage Nearline は、コールドストレージの概念が不要になるようなストレージソリューションと広く考えられてきましたが、私たちはそんなところには留まりませんでした。

ユーザーエクスペリエンスを向上させるために、99% の稼働時間を誇る SLA、オンデマンド I/Oライフサイクル管理を追加し、パートナー エコシステムを大幅に拡大した上で、Cloud Storage NearlineCloud Storage Transfer Service が今日ついに一般公開されます。

さらに、Google が用意した Switch and Save プログラムを使えば、Google Cloud Storage Nearline への移行がスムースに行えますし、費用も低く抑えられます。

オンデマンド I/O の導入

格納されているデータ 1TB あたり 4MB /秒というプロビジョニングされたスループットよりも高速に、Google Cloud Storage Nearline バケットからデータを取得しなければならないときに I/O の能力を増強できるオンデマンド I/O  を導入します。オンデマンド I/O は、必要なときに限りスループットを増強することができるだけでなく、料金は使った分だけしか発生しません。データリカバリを確実なものとして計算に入れつつ、数秒でデータにアクセスできるようになります。一般リリース後 3 か月間は、追加料金なしでオンデマンド I/O を使えます。

Cloud Storage Transfer Service を公開

また、 Cloud Storage Transfer Service(従来は Online Cloud Import と呼ばれていたもの)がすべての企業、組織に対して公開されます。Amazon S3(Amazon Simple Storage)などの HTTP/HTTPS 上の位置から Google Cloud Storage に大量のオンラインデータを簡単にインポートできるようになり、効果的にコストを削減できるようになります。反復されるデータ転送をスケジューリングするだけでなく、1 度限りのデータマイグレーションも設定できるようになります。Cloud Storage Transfer Service を使えば、ライフサイクル管理も実現できます。Cloud Storage Nearline への自動アーカイブ、削除のスケジューリングなど、オブジェクトのライフサイクル管理を単純化する機能が提供されます。

Switch and Save プログラムを開始

さらに、Cloud Storage Nearline で 6 か月以内の期間、100PB の無料ストレージを手に入れられる Switch and Save プログラムも今日からスタートします。ほかのクラウドサービスプロバイダやオンプレミス インフラストラクチャから移行するために、新規利用者として Google Cloud Platform を契約すると、ストレージのコストを大幅に削減できるのです。Amazon Web Services と比べて、Google Cloud Storage Nearline ならどれくらいのコスト節減効果があるのかを推計するための TCO 計算ページも用意してあります。
ストレージのプラットフォームとプロセスを乗り換えるのは容易なことではありません。強力なパート ナーエコシステムがない限り、Cloud Storage Nearline をスムースに採用することは覚束ないでしょう。お客様がデータストレージのためにまったく新しいアプローチを取れるようにするために、Cloud Storage Nearline パートナーを一気にベータテスト時の倍以上にしたのはそのためです。従来の Veritas/SymantecNetAppIron MountainGeminare に加えて、新たに次の 5 社がパートナーになりました。


Google Cloud Platform プレミア パートナー

Actifio は、企業のデータ回復、機動的データ操作のあらゆるユースケースで、今までにないスピード、効率、単純さでアプリケーションデータをキャプチャ、管理、利用できるようにする製品を提供しています。

Actifio の賞を受けている企業データコピー仮想化プラットフォームを使えば、企業データを Google Cloud Storage Nealine に格納する作業は驚くほど単純になります。
Pixit Media は、特別なハードウェア機器を必要とすることなく、Google Cloud にホスティングされた映像リソースのユーザーをオンプレミスストレージに接続します。

さらに、Pixit Media PixStor ユーザーは、Pixit のオブジェクトプラグインを使って「よりコールドな」データの、バックアップ、アーカイブ用に Google Cloud Storage を使うことができます。

バックアップ、アーカイブに必要な時間を数日から数分に短縮するという Pixtor のポリシーに従い、データは記録的な速さで保護、マイグレーションされます。

Unitrends Free™ for Google Cloud Platform は、VMware vSphere や Microsoft Hiper-V 環境の仮想アプライアンスとしてすばやくデプロイできる無料のバックアップソフトウェアです。

Unitrends Free for Google Cloud は、ローカルにデータをバックアップし、Google Cloud Storage や Google Cloud Storage Nearline とシームレスに統合され、クラウドにバックアップのコピーを作ります。



Google Cloud プラットフォーム パートナー

CloudBerry Backup は、Google Cloud Storage Nearline を活用するクラウドバックアップソリューションです。

CloudBerry は、リアルタイム/スケジュールによるローカルディスクイメージの暗号化されたバックアップと未初期化システムへ のリストアを提供するほか、効率を最大限に引き上げるブロックレベルのバックアップを採用し、バックアップ、リストアプランをリモートに監視するアラート機能を提供しています。

Filepicker は、6 万種を越えるアプリケーションが簡単、単純にクラウドドライブと統合されるように支援します。

Filepicker を使うアプリケーションは、自動的に Google Cloud Storage Nearline に統合され、コスト削減とライフサイクル管理のメリットを享受するようになります。


今挙げたパートナー以外にも、Google Cloud Strage を統合し、Google Cloud Storage Nearline サポートを追加して、ユーザーが障害からの回復、バックアップを最適化できるようにしているグローバルなストレージベンダーのエコシステムは拡大しています。

Commvault の Simpana プラットフォームは、ver.10サービスパック11のリリース以来、Google Cloud Storage Nearline の単純でシームレスなネーティブサポートを提供しています。

Commvaultというひとつのプラットフォームのもとで、ユーザーは Cloud Storage Nearline をデータバックアップやアーカイブのリポジトリとして利用することができます。しかも、社内全体で使っているさまざまなストレージプラットフォームを通じて、内容をきちんと把握することができます。

EMC NetWorker 8.2 with CloudBoost と EMC Avamar 7.1 with CloudBoost は、Google Cloud Storage Nearline を使ってバックアップデータの効率的で安全な長期保存を実現し、テープを不要にするとともに、設備投資にかかるコストを削減します。 EMC CloudArray は、クラウドストレージを NAS や SAN のような外観、使用感に変えるもので、あまり使われないデータをオンラインでアクセスできるようにしておきたいと考えている企業にとってはコスト的に魅力的なソリューションです。

CloudBoost と CloudArray は、Standard、DRA、Nearline という Google Cloud Storage の 3 つのティアをすべてサポートします。

Egnyte は、一元的な管理、統一的な視野、セキュリティの担保されたアクセスのもとでファイル共有環境を統合するもので、Google Cloud Storage Nearline、Google Cloud サービスを統合しています。

エンドユーザーは、どのアプリケーション、デバイスを使っても最適化され統一された操作をすることができます。

今すぐ始めよう

Cloud Storage Nearline を試したい場合には、Nearline サイトドキュメントを参照して下さい。Google Cloud Platform を初めて使われるお客様は、最長で 6 か月に渡って Cloud Storage Nearline の 100PB の無料ストレージを手に入れられる Switch and Save プログラムをご利用ください。また、Cloud Storage Nearline パートナーのページでも、Google プラットフォームを統合してその機能や射程を拡大し、サービスを早く使いこなせるようにするソリューションを提供しているパートナーが見つかるかもしれません。


- Posted by Avtandil Garakanidze, Product Manager


Google のウェビナー「Google Cloud Platform を始めよう」が、世界中の開発者に向けて 3 つのタイム ゾーンで実施されます。段階的なデモンストレーション形式で実施されるコンテンツとなっていますので、ぜひご参加ください。

面倒なインフラストラクチャ周りの作業に手間をかけずに、自分のアイデアをできるだけすばやく開発し、形あるものにしたい。ソフトウェア エンジニアであれば、誰もがそう考えるに違いありません。そういった開発者達のために Google Cloud Platform は、 Google の持つ極めてスケーラブルでかつ信頼性の高いインフラストラクチャを土台にして、アプリケーションを構築、テスト、デプロイできるよう設計されています。

Google は、試用の申し込み、仮想マシンの作成、アプリケーションのローンチといったタスクを、簡単に、かつ素早く実行できるようにするべきだと考えています。そこで私達はデベロッパー アドボケイトを結集し、利用頻度の高く一般的なタスクや、  Google Cloud Platform の利用を検討しているユーザーからよく聞かれる質問をまとめたハウツーガイドを作成しました。

ウェビナー:Google Cloud Platform を始めよう
所要時間:30 分
トピック
  1. Google Cloud Platform のアカウント設定
  2. Cloud Launcher によるすばやい WordPress のデプロイ
  3. 料金計算ツールよる料金の見積もり
  4. ファイアーウォールとネットワークの構成
  5. カスタム スタックの設定方法
  6. バックアップ、ディスク容量の増加、サーバーのアップグレード
  7. まとめ

下記のタイム ゾーンで同じウェビナーが実施されます。

南北アメリカ

2015 年 7 月 28 日 (火) 午前 10 時〜 (米国西海岸時間; 太平洋時間)
2015 年 7 月 29 日 (水) 午後 3 時〜(日本時間)
  [申し込みはこちらから]

ヨーロッパ、中東、アフリカ

2015 年 7 月 29 日(水)
  午前 10 時〜(イギリス)
  午前 11 時〜(フランス)
  午後 12 時〜(イスラエル)
   [申し込みはこちらから]

アジア太平洋

2015 年 7 月 30 日(木)
  午前 10 時 30 分〜(インド)
  午後 1 時〜(シンガポール/香港)
  午後 3 時〜(シドニー、 オーストラリア東部夏時間)
  午後 2 時〜(日本時間)
   [申し込みはこちらから]

Google Cloud Platform アカウントの無料トライアルもぜひお試しください。トライアルではクレジットカードに料金が請求されることはありません。


Google では皆様のご意見を歓迎しています。こちらのページ右上にある「フィードバックを送信」からご感想をお寄せください。


-posted by Syne Mitchell, Google Cloud Platform Technical Writer



2LO、3LO、サービス アカウントなど、認証のコンセプトについてご存知でない場合は、こちらの解説が役立つでしょう。ADC は複雑さを完全に排除し、API 呼び出しを 1 回のみにします。これは以下のような点を活用することによって可能になっています。

  • 2-legged(2LO)OAuth VS 3-legged(3LO) OAuth: OAuth2 は、ユーザー、API プロバイダー、アプリケーション開発者が認証のプロセスで関与する必要がある、ユーザー所有のデータに対応しています。大半のクラウド API はユーザー所有のデータを処理しないため、API プロバイダーとアプリケーション開発者間だけのより単純なフローを使用できます。
  • gcloud CLI : クラウド リソースの検討や管理を行う際に、アプリケーションの開発やデバッグでコマンドライン ツールの gcloud を使用した経験はないでしょうか。ADC では gcloud でアプリケーションに認証フローを使用できるため、認証情報の設定は一度だけです。
  • サービス アカウント: App Engine または Google Compute Engine で実行されるアプリケーションでは、安全な「サービス アカウント」へのアクセスが自動的に確保されるため、API 呼び出しは必ず確かな呼び出し元から行われることになります。API プロバイダーがこれを信用できることは、アプリケーションにとって有益です。

Google Application Default Credentials の詳細については、こちらからご確認いただけます。Java、Python、Node.js、Ruby、Go に対応しているほか、PHP と .Net のライブラリも開発中です。


- Posted by Vijay Subramani, Technical Program Manager, Google Cloud Platform

 

* この投稿は、米国時間 7 月 22 日、Google Cloud Platform, Product Manager の Srikanth Belwadi によって投稿されたものの抄訳です。

動画コンテンツへの消費者の爆発的な需要によって、 2020 年までに世界的なインターネットのトラフィックはオンライン動画が 80 % を占めると予測されています。現時点でさえも、デスクトップとモバイルで消費されている動画はコンテンツ全体の半分を優に上回っています。


こうした状況の中ユーザーは、HD 品質の優れたコンテンツを最小限のラグで、オンデマンドかつ端末を選ばずに視聴することをますます期待しています。また、リアルタイムでのライブ ストリーミングへの需要も拡大しています。

しかし動画と音声の高品質で確実なストリーミングを可能にするメディア サーバーの調達、構成、デプロイは、高額で複雑になる場合があります。そこで Google は Wowza Media Systems と連携し、クリックするだけで Google のインフラストラクチャにデプロイできるストリーミング ソリューションである Wowza Streaming Engine の提供を開始しました。

Google Cloud Platform で Wowza Streaming Engine を実行することで、Google の信頼できるネットワークから世界中のあらゆる場所にいるユーザーに向けて、高品質なオンデマンドのライブ コンテンツをストリーミングできます。

このクラウド ネイティブの設定では、VM の高速なプロビジョニングやグローバル ロード バランシングを自動的に活用できる Google の高パフォーマンスの仮想マシンが利用されます。そのため、分単位での課金や自動的に適用される継続使用割引など、コスト面のメリットもあります。

Wowza Streaming Engine の持つ業界最先端の機能はすべて利用することができます。例えば、リアルタイム トランスコーディングを無制限に実行できる Wowza Transcoderは、エンドユーザーのさまざまなデバイスやネットワークの状況に対応するアダプティブ ストリーミングが可能です。

Google Compute Engine は信頼できるクラウド プラットフォームというだけでなく、極めて優れたネットワーク パフォーマンスも期待通りに実現します」とWowza Media Systems の共同創設者であり CTO を務めるチャーリー グッド氏は述べています。

Google Compute Engine の Click to Deploy から Wowza Streaming Engine を提供できることを光栄に思っています。すばやいデプロイとストリーミングを希望される Wowza のお客様にとって、オンデマンドのライブ動画をあらゆるデバイスを対象に一貫してグローバルにストリーミングする Google Compute Engine は、最適な選択肢でしょう」

33 か国に 70 か所以上存在する Google のグローバル ネットワーク フットプリントによって、世界中のオーディエンスにすばやく、かつてないほどの規模でリーチできます。

クラウドベースのコンテンツのストリーミングは、ユーザーに優れたコンテンツを提供する最もシンプルでコスト効率の高い方法です。Click to Deploy を活用することで、わずか数分であらゆるデバイスを対象にコンテンツをストリーミングできる新しいメディア サーバーを作成することができます。


Wowza と Google 両社ゲストによるウェビナーも開催!

Google Compute Engine の Click to Deploy で Wowza Streaming Engine を活用し、 すばやいデプロイとストリーミングを
日程:2015 年 7 月 29 日(水)
時間:午前 11 時(太平洋時間)| 午後 2 時(東部標準時)| 午後 6 時(グリニッジ標準時)

こちらから今すぐ登録



- Posted by Srikanth Belwadi, Product Manager, Google Cloud Platform
Share on Twitter Share on Facebook


システムがホストされている場所や活用されている一連の技術、使用される言語にかかわらず、災害によってサービスが中断され、企業の顧客がシステムを利用できなくなる可能性はゼロではありません。優れたシステムに不可欠なディザスタ リカバリ計画(以下 DR 計画)は災害発生時のランブックとなり、システムをできるだけ速やかに復旧することに役立ちます。

災害復旧を支援する Google Cloud Platform では DR 計画の実装に伴うコストと労力を大幅に削減できますが、だからといって万能なソリューションは存在するわけではありません。

そこで、Google は企業のビジネスや特定のユース ケースに合ったコスト効率の高いソリューションの特定に役立つ DR 計画ガイド手順書をリリースしました。

計画の作成時に考慮すべき事項が詳細に解説される DR 計画ガイドでは、リカバリの目標に合わせた計画の作成からインスタンスの開始に使用する構成が RTO(recovery time objective)に与える影響まで、さまざまなトピックが網羅されています。Google Cloud Platform についてよくご存知でない場合も、DR 計画で一般的に利用されている製品のリストを確認することができます。

DR 計画ガイドを補完する手順書では、Google Cloud Platform を活用したさまざまな DR 計画の実装に関するガイダンスが提供されています。

例えば階層型ストレージ ソリューションの実装を検討しているものの、コストが原因で実現していない場合にコストを抑えながらそれに対処するシナリオが紹介されています。

また、オンプレミスの本番アプリケーションをクラウドにフェイルオーバーする方法も解説されています。これらはほんの一例であり、他にも多くのシナリオが網羅されています。これらのシナリオは、オンプレミスで導入する場合でも、Google Cloud Platform や他のクラウド プロバイダーを利用する場合でも活用できます。

Google Cloud Platform を活用されていなくても、お客様のユースケースに合った DR 計画の実装に DR 計画ガイド手順書をぜひご活用ください。


-Posted by Grace Mollison, Solutions Architect 
Share on Twitter Share on Facebook


Kubernetes は 400 人のコントリビュータからの 14,000 コミットにより v1 に到達

今年2月、Kubernetes のコントリビュータたちはサンフランシスコに集まり、機能、信頼性、サポート対応力という観点から 1.0 に求められる内容について合意に達しましたが、今日、その目標を達成しました。Kubernetes は、すばらしい機能セットを備え、本番稼働使用に耐えられるものになりました。


アプリケーション サービス、ネットワーク、ストレージ 



クラスタ管理



パフォーマンスと安定性




Kubernetes は、わずか 1 年でもっとも多くの人々から支持され、成功を収めたオープンソースプロジェクトのひとつになりました。Red Hat、CoreOS、IBM、Intel、Microsoft、VMware を始めとする多くの一流企業のデベロッパを含む 400 人のコントリビュータが 14,000 回を越えるコミットをしています。


顧客企業各社は、すでに Kubernetes 上で本番インフラの一部を実行しています。
「Box は、コラボレーションを促進し、情報を安全に保つシステムとして信頼されています。Kubernetes の導入により、アプリケーションの移植性と運用の機動性という点で新しい可能性が開けました。Kubernetes の技術的な品質の高さと完成度にはいつも感心しており、Kubernetes は弊社のインフラストラクチャのコア コンポーネントになると考えています」
- Sam Ghods, Box 技術担当 VP
「eBay は、世界でもっとも大規模なオープンプライベート クラウドのひとつを構築、運用し、この分野のイノベーションをリードしてきました。コンテナとデータセンター OS が新しい地平を切り開いたことにより、クラウドファースト アプリケーションをシームレスに提供したいインフラストラクチャ プロバイダやデベロッパには、比類ないチャンスが到来しています。私たちは Kubernetes ファウンデーションに参加し、コミュニティ主導のオープンなプロジェクトをリードして、イノベーションのペースを加速し、Kubernetes の普及をお手伝いできることを楽しみにしています」
- Debashis Saha, eBay クラウドサービス担当 VP
「コンテナにパッケージされ、動的にスケジューリングされるマイクロサービス指向のアプリケーションを作れるようにするという Google のビジョンには、RedHat も共感しています共有するものです。そして、弊社の Kubernetes と Docker への投資は、デベロッパ エクスペリエンスの向上、運用の単純化、効率の向上、アプリケーション全体の機動性とメンテナンス性の向上という形ですでに顧客のために大きな成果を生んでいます」
- Lars Herrmann, Red Hat 統合ソリューションビジネスユニット及びコンテナ戦略担当本部長

「私たちはプライベート インフラストラクチャからパブリッククラウドまでの多様なグローバル インフラストラクチャのもとで複雑なアプリケーション エコシステムを運用しています。Kubernetes は、弊社のようなエンタープライズ インフラストラクチャのもとでアプリケーションを開発、デプロイ、運用、マイグレートするときの不協和音を大幅に緩和できる基幹テクノロジだと思っています」
- Richard Kaufmann, Samsung SDS Research America アーキテクチャ担当 VP
「Shippable では、弊社のプラットフォームのコンテナ、クラスタ管理を Kubernetes にコンバートしました。現在では、毎月百万以上のコンテナを Kubernetes 上で実行しています。弊社は非常に早い時期に Docker を採用したので、ほぼ 2 年間はコンテナのデプロイ、実行に関して do-it-yourself の状態でした。そのため、弊社は産みの苦しみを味わってきました。しかし、Kubernetes のおかげで、アプリケーションとインフラの管理は単純で信頼できるものに変わりました。Kubernetes 導入以前は、デベロッパたちは週に平均 120 時間も運用がらみの仕事をしていましたが、今では 2、3 時間になっています。これはかなり控え目な数字です。不満は、2 年前に Kubernetes があったらということだけですよ」  
- Avi Cavale, Shippable CEO
「Kubernetes はアーキテクチャ的な基礎が正しく、Google のシステム運用の経験が詰まっており、レベルが高く熱心で多様なコミュニティに支えられたオープンソースプロジェクトでもあることから、弊社は当初から非常に注目していました。すでに本番システムで Kubernetes を実行してしばらくたちますが、成熟のペースの速さとコントリビュータたちのコードの品質の高さには感心しています」
- Steve Reed, Zulily コアエンジニアリング部プリンシパル エンジニア


CNCF(Cloud Native Computing Foundation): Google、Linux Foundation、一流パートナー企業がコンテナベース コンピューティングの未来を切り開くために結集

コンテナは、アプリケーションのデプロイ、管理の方法を変えようとしていますが、クラウドネーティブなマイクロサービスベース アプリケーションはまだ生まれたばかりです。弊社は、Linux Foundation、及び Docker、IBM、VMware、Intel、Cisco、Joyent、CoreOS、Mesosphere、Univa、Red Hat などの錚々たるパートナー企業各社とともに、コンテナベースコンピューティングを容易にする CNCF(Cloud Native Computing Foundation)を設立します。

第1歩として、Kubernetes を CNCF に移管することを計画しています。CNCF は、今後の Kubernetes のオープンソース開発を管理し、パブリッククラウド、プライベートクラウド、ベアメタルのいずれのインフラストラクチャのもとでも快適に動作し続けるようにします。

しかし、Kubernetes はまだ始まったばかりです。CNCF の方向性は、技術委員会によって与えられます。技術委員会は、オープンソースやパートナーコミュニティを指揮してコンテナツールセット全体をより堅牢にする新しいソフトウェアを開発します。また、技術委員会は、CNCF で担当すべき新たなプロジェクトの評価も行い、ツールセットを全体として快適に動作させるようにしていきます。

CNCF の運営方針、参加方法などの詳細は、ウェブサイトを御覧ください。


Kubernetes パートナー企業の発表

今日、ポートランドで開催されている OSCON では、Kubernetes エコシステムの メンバー企業各社も優れた製品を次々に発表します。



今すぐ 始めよう

Kubernetes はパブリック クラウドプロバイダからプライベート インフラストラクチャまで、あらゆるプラットフォームで動作します。是非、 パートナー企業の製品をご覧になってください。また、Google のマネージド Kubernetes サービス、、Google Container Engine も試してみてください。さらに詳細な情報については、こちらの OSCON のサイトにて Kubernetes 1.0 発表のライブストリーミングをご覧ください。


- Posted by Craig Mcluckie, Product Manager
Share on Twitter Share on Facebook

 script: thecron.app
 login: admin_only


App Engine Cron Service では、スケジュールされているタスクが使用する URL へのアクセスを管理者アカウントのみに制限することが推奨されています。これは  login: admin_only の設定で実行されます。

お客様は管理者以外のユーザーによる、これらの URL へのアクセスがブロックされるかどうか確認しようとしました。

そこでまず、cron ハンドラ  thecron.py にプレース ホルダを実装しました。


import webapp2
import time


class TestCronHandler(webapp2.RequestHandler):
   def get(self):
       self.response.headers['Content-Type'] = 'text/plain'
       self.response.write('Cron: {}'.format(time.time()))


app = webapp2.WSGIApplication([
   ('/crontask/test', TestCronHandler),
], debug=True)


次にユニット テスト  ut.py が書き込まれました。
(注:下記のテスト コードでは  mock モジュールが使用されています。ローカルの Python 2.7 のインストールで  mock モジュールを使用できるようにするには、 pip install mock  を実行します。)


import sys


# configure unit testing for the case
# where the App Engine SDK is installed in
# /usr/local/google_appengine
sdk_path = '/usr/local/google_appengine'
sys.path.insert(0, sdk_path)
import dev_appserver
dev_appserver.fix_sys_path()


import mock
import unittest


import webapp2
from google.appengine.ext import testbed


import thecron


class CronTestCase(unittest.TestCase):


 def setUp(self):
     self.testbed = testbed.Testbed()
     self.testbed.activate()
     self.testbed.init_user_stub()


 def _aux(self, is_admin):
     self.testbed.setup_env(
         USER_EMAIL = '[email protected]',
         USER_ID = '123',
         USER_IS_ADMIN = str(int(bool(is_admin))),
         overwrite = True)
     request = webapp2.Request.blank('/crontask/test')
     with mock.patch.object(thecron.time,
                            'time', return_value=12345678):
         response = request.get_response(thecron.app)
     return response


 def testAdminWorks(self):
     response = self._aux(True)
     self.assertEqual(response.status_int, 200)
     self.assertEqual(response.body, 'Cron: 12345678')


if __name__ == '__main__':
   unittest.main()


最初のテスト  testAdminWorks は問題なく通過したため、2 つめのテストが追加されました。



 def testNonAdminFails(self):
     response = self._aux(False)


     self.assertEqual(response.status_int, 401)


ところが、ステータスは想定された 401(forbidden)ではなく 200(success)となり、このテストは通過しませんでした。

ここでの問題はユニット テストが  app.yaml  まで遡っておらず、ユニット テストのスタブではなく、サービスを呼び出すアプリケーションの場合のように、完全なルーティングとログイン制限がテストの対象になっていないことでした。つまり、対象となっていたのはログイン制限が課されていない  thecron.py  の二次的なルーティングだったのです。そのため、 app.yaml  のルーティングのほか、MIME タイプやログインなどのその他諸々は、ユニット テストのスタブではなくサービスを呼び出すテストだけの対象となっていました。

そこで、管理者の権限をチェックするデコレータ  needs_admin を  thecron.py に追加しました。


def needs_admin(func):
   def inner(self, *args, **kwargs):
       if users.get_current_user():
           if not users.is_current_user_admin():
               webapp2.abort(401)
           return func(self, *args, **kwargs)
       return self.redirect(users.create_login_url(request.url))


   return inner


さらに、これを  CronHandler.get でデコレートしました。


class CronHandler(webapp2.RequestHandler):
   @needs_admin


   def get(self):  # etc, as before


これで cron サービスのスタブを呼び出すローカルのユニット テストは機能しますが、実際の App Engine Cron Service の機能を使ったエンドツーエンドのテストはステータス 401で失敗となります。なぜでしょうか。

簡単に言うと、App Engine Cron Service は指定された URL にアクセスするどのユーザーもログインさせません。そのため、ハンドラでは  users.get_current_user() から  None が返されます。

これを解消するのは、特別なリクエスト ヘッダ  X-AppEngine-Cron: true の設定です。App Engine では外部リクエストで設定されたヘッダが除外されるため、このヘッダはアプリケーション コードが完全に信頼できるヘッダとなります。

つまり、ユニット テスト、エンドツーエンド テスト、ローカル開発のアプリケーション、デプロイされたアプリケーションを機能させるために必要だったのは、デコレータ  needs_admin のわずかな修正だけだったのです。


def needs_admin(func):
  def inner(self, *args, **kwargs):
       if self.request.headers.get('X-AppEngine-Cron') == 'true':
           return func(self, *args, **kwargs)
       if users.get_current_user():
           if not users.is_current_user_admin():
               webapp2.abort(401)
           return func(self, *args, **kwargs)
       return self.redirect(users.create_login_url(request.url))


   return inner


新しい  if  の記述はモック化されているかどうかにかかわらず、cron ジョブを処理します。2 つめの  if  の記述は、これまで通り管理者以外の(またはログインしていない)ユーザーを確実にブロックします。

コードの品質はユニット テストに時間と注意を注ぐことで継続的に維持できます。こうしたテストの作成と実行は、App Engine の Local Unit Testing ツールのほか、NoseGAE といったオープンソースのアドオンを活用することによって単純化することが可能です。


- Posted By Alex Martelli, Cloud Technical Support

Share on Twitter Share on Facebook