問題タブ [google-compute-engine]

APP (個人用ではない) 資格情報を使用して、App Engine 自体から Google Compute Engine インスタンスを開始する方法はありますか? Cloud Storage と Cloud SQL にはアプリ固有のサービス アカウントを使用できますが、このサービス アカウントを Compute Engine にも使用できますか?

Compute Engine はサービスの下にリストされていません: https://developers.google.com/appengine/features/?hl=en#services

europe-west1-a ゾーンの Google コンピューティング エンジン インスタンスで、icecast2 サーバーを使用して、ウェブラジオ ステーションをホストしたいと考えています。このサービスは主に帯域幅が制限されているため、ドキュメントを検索して (サーバーからインターネットまで) 利用可能な帯域幅の見積もりを見つけましたが、見つかりませんでした.

帯域幅が 100 Mbps の単一のリモート サーバーで、curl プロセスを使用してリスナーをシミュレートすることにより、いくつかの予備テストを実行しました。私のテストは、500 リスナーで失敗し始めました。ストリームは 64kbps でエンコードされているため、サーバーは ~32Mbps を出力していました。テストの実行方法から、帯域幅が制限要因であると結論付けることはできませんが、同時に使用できるリスナーの数を見積もるために予想される帯域幅を知りたいです。

Google App Engine でいくつかの Web システムを開発しました。Google Compute Engine が利用できるようになった今、企業の情報戦略の観点から、次のうちどれが優れているのか疑問に思わずにはいられませんでした。

1. Google App Engine + webapp2 + ndb + Django テンプレート + Python

2. Google Compute Engine + Linux + Django + MySQL + Python

これが非常に多くの詳細な考えを含む大きな問題であることは承知していますが、人々がそれについてどのように考えているかを聞きたいと思っています. 1.はすでに経験ありますが、2.はベンダーロックインがないので魅力的です。

私の Google Compute Engine 仮想マシンは、us-central1-a にある永続ディスク上にあります。メンテナンスに数週間かかることを知らなかったので、メンテナンス前に移行しませんでした。そのため、VM を再び使用できるように、メンテナンスが終了するのを辛抱強く待っていました。

以前は、メンテナンスのためにゾーンがダウンしているという警告が表示されていました。しかし、今日私はこれを得ました：

これは一時的なものですか、それとも永続的なものですか? VM を再作成できるようにスクリプトをバックアップしましたが、アプリケーションを再構築するにはかなりの計算時間が必要です。待つか、再開するかを知る必要があります。

ありがとう。

GCE で新しいインスタンスを作成すると、問題なくその新しいインスタンスに ssh できます。gcutil は、キー (google_compute_engine) があるかどうかを確認し、ない場合はキーを作成します。次に、キーをインスタンスにプッシュし、5 分間一時停止して、キーがそこに配置されるようにします。繰り返しますが、これはすべて、作成した新しいインスタンスでスムーズに機能します。これは、私のsshが機能していることも示しています。

ただし、「gcutil --project= ssh」を使用して既に存在する別のインスタンスに接続しようとすると、「Permission Denied (publickey) が生成されます。キーを削除してコマンドを再実行すると、同じエラーが発生します。期待される結果は次のようになります。上記のように - つまり、キーを作成してインスタンスにプッシュしますが、これは起こりません。

ssh -vvv には有用な情報はありません。/var/log/auth.log には、試行された接続も表示されません。

GCE の世界/ssh の誰もが、gcutil が一方のインスタンスではスムーズに機能するのに、他方のインスタンスでは機能しない理由を知っていますか? これをデバッグするために何を確認する必要がありますか?

前もって感謝します。

VM インスタンスから Cloud SQL を使用しようとしています。VM インスタンスを作成するときに、Cloud SQL Option を有効にしました。Cloud SQL インスタンスは、Compute Engine プロジェクトにアクセスを許可します。

google_sql.sh最初は、Cloud SQL を有効にしていたので、VM にインストールされているようなツールがいくつかあると思っていましたが、そうではありませんでした :-/

Cloud SQL ドキュメントには、ローカル アクセス トークンを VM インスタンスにコピーする必要があると記載されています。私のローカル マシンは Mac OSX であるため、トークンは : に保存されます ~user/Library/Preferences/com.google.cloud.plist が、Linux VM では : に保存されます ~user/.java/.userPrefs/com/google/cloud/sqlservice/oauth2/prefs.xml。

を作成prefs.xmlして VM にコピーする必要がありますか? (しかし、XML スキーマは と の間com.google.cloud.plistで同じではないと思いprefs.xmlますか?)

誰かがテンプレートとして使用できる例を持っていますか(スキーマが私が疑うものperfs.xmlとまったく同じでない限り)?com.google.cloud.plist

ご協力ありがとうございます。

GCS を使用してファイルを保存/取得する GAE プロジェクトがあります。これらのファイルは、GCE で実行されるコードで読み取る必要もあります (C++ ライブラリが必要なため、GAE では実行されません)。

実際の G​​AE > GCS < GCE にデプロイされた本番環境では、このセットアップは正常に機能します。ただし、ローカルでのテストと開発は、私が理解しようとしている別の話です。

推奨どおり、GAE の dev_appserver を GoogleAppEngineCloudStorageClient で実行して、(シミュレートされた) GCS にアクセスしています。ファイルはローカルのブロブストアに配置されます。GAE のテストに最適です。

これらは VM をローカルで実行するための GCE SDK ではないため、ローカルの「GCE」を参照するときは常に、Linux を実行しているローカル開発マシンにすぎません。ローカル GCE 側では、デフォルトの boto ライブラリ ( https://developers.google.com/storage/docs/gspythonlibrary ) を Python 2.x ランタイムと共に使用して、C++ コードと連携し、GCS からファイルを取得しています。 . ただし、開発中は、これらのファイルは dev_appserver の blobstore に保存されているため、boto からアクセスできません。

ローカル GAE と GCE をローカル GCS に正しく接続する方法はありますか?

とりあえずローカルのGCS部分は諦めて本物のGCSを使ってみました。boto を使用した GCE 部分は簡単です。GCS 部分は、access_token を使用して実際の G​​CS を使用することもできるため、次の方法でローカル blobstore の代わりに実際の G​​CS を使用します。

ドキュメントによると：

そのトークンは限られた時間だけ機能するため、理想的ではありません。より永続的な access_token を設定する方法はありますか?