問題タブ [managed-vm]

標準ランタイム (python27) を使用する Google App Engine マネージド VM の Dockerfile を変更したいと考えています。

HTTP 要求を実装するために呼び出す必要がある C++ ライブラリを追加するために、これを実行したいと考えています。このライブラリは、サンドボックス化された python27 ランタイムに必要な唯一の追加機能です。

ドキュメントは、これが可能であることを非常に明確にしています:

各標準ランタイムは、SDK によって提供されるデフォルトの Dockerfile を使用します。このファイルに新しい docker コマンドを追加することで、標準ランタイムを拡張および強化できます。

他の場所では、標準ランタイムのDockerfileがプロジェクト ディレクトリに生成されると述べています。

gcloud を使用して、標準ランタイム (この場合は Python27) に基づくマネージド VM アプリケーションを実行またはデプロイすると、SDK は標準ランタイムをベース イメージとして使用して最小限の Dockerfile を作成します。この Dockerfile はプロジェクト ディレクトリにあります...

これは、同じページに従って変更することになっているものです。

このチュートリアルの後半のステップでは、Dockerfile に命令を追加してランタイム環境の機能を拡張する方法を示します。

問題は、開発サーバーでアプリケーションを実行すると、Dockerfile がどこにも見つからないため、変更を加えることができないことです。

Google App Engine の標準ランタイム Dockerfile を変更できた人はいますか? どんな助けでも大歓迎です。

Google App Engine カスタム マネージド VM for Java から Google Cloud Datastore に接続できますか? 標準のマネージド VM からは可能だと思いますが、カスタムのマネージド VM からは可能ですか?

開発目的で Google Standard Managed VM for Java をローカルで実行することはできますか? dev_appserver.py、mvn gcloud:run、または gcloud preview app run は、単純な Hello World アプリケーションには適していますが、それよりも大きなものは機能しません... (シングル スレッド、タイムアウトなど)。

Google App Engine マネージド VM にデプロイしようとしている最小限の Django プロジェクトがあります。何が起こっているのか、何が何を提供しているのかを正確に理解するのに少し苦労しています。次のような app.yaml ファイルがあります。

そして、次のような dockerfile:

私の requirements.txt は次のようになります。

サイトは正常にデプロイされますが、静的ファイルが表示されません。そのため、サンドボックス化されたアプリ エンジン プロジェクトでは、app.yaml のハンドラーが静的コンテンツの提供を担当します。静的コンテンツを提供するために、dockerfile で nginx サーバーまたは同様のサーバーを構成する必要がありますか?

これを理解するために、gunicorn がアプリケーションを提供していない場合、App Engine はデフォルトでハンドラーを使用してそれを提供しませんか? つまり、持っていなかったらどうなりCMD gunicorn DjangoVM.wsgiますか? カスタム ランタイムは、アプリ エンジンがデフォルトでアプリケーションにサービスを提供せず、特定の WSGI サーバーを指定する必要があることを意味しますか? マネージド VM のドキュメントはまだ完全ではありません。質問が少し混乱しているように見える場合は申し訳ありませんが、それはこの件に関する私の現在の混乱も反映しています. 助けてくれてありがとう！

私は App Engine フレキシブル環境 (以前はマネージド VM と呼ばれていました) を使用しており、最近最新の gcloud SDK にアップグレードしました。いくつかの新しいエラーが含まれていました:

これらのエラーを修正し、再度公開できましたが、次のようなエラーが表示されるようになりました。

Google のテクノロジーを使用しても完全に解決できない問題があります。

SSL 経由で 500 を超える並列 WebSocket 接続を提供する必要があります。クライアントは理想的には wss://wss.mydomain.com に接続し、インスタンスによってサービスを受けます。

オプション 1 : 現在、カスタム ランタイム マネージド VM を使用して、SSL 対応 Websocket サーバーを実行する Dockerfile をデプロイしています。マネージド VM インスタンスをデプロイすると、1 つの GCE インスタンスになります。Google Cloud DNS を使用して、wss.mydomain.com を GCE インスタンスのこの 1 つの IP アドレスにポイントします。

問題: Websocket 接続 (SSL 経由) がマネージド VM インスタンスに転送されないため、wss.mydomain.com (my-mvm.appspot.com にも接続できません) に接続できません。問題を提起しましたが、私に役立つ応答はありませんでした。また、他の人はこことここでこの結論に達します。

マネージド VM が答えではない場合、Google Cloud アーキテクチャ内のどこで見つけることができますか?

オプション 2 : managedVM は GCE のシュガー コーティングのように見えるので、GCE インスタンスを既に提供している現在のセットアップを維持し、自分で負荷分散を追加することはできますか?

オプション 2a : HTTP(S) 負荷分散は websocket トラフィックを許可しないため、いずれかがoutになります。

オプション 2b : ネットワーク負荷分散が機能する可能性があります。それを機能させるには、インスタンスをターゲット プールに割り当てる必要があります。新しく作成されたマネージド VM インスタンスをターゲット プールに自動的に割り当てて、負荷分散に参加させることはできますか? もしそうなら、これは問題の完全な解決策になりますか?

オプション 3 : セットアップに Dockerfile を引き続き使用したい。だから私はコンテナエンジンを見ています。ここではまったく経験がありません。

別の地雷原に手を出す前に、問題の解決策を提供する可能性が最も高いオプションはどれですか? おそらく、私が考えていなかった別のオプションがあります。

Cloud Debugger now available for Python を使用した Production Troubleshooting で本日発表されたように、Python Debugger を使用できるようになりました。

GCE イメージで AppEngine マネージド VM を実行しているため、Compute Engine での Python の設定に関するガイドに従っています。Dockerfile を変更して追加しpip install google-python-cloud-debuggerました (sys.path に含まれている app/lib にライブラリを直接インストールしようとしました):

そして、main.py を変更してデバッガーを有効にしました。

残念ながら、コードをコミットして実行gcloud preview app gen-repo-info-fileし、プッシュすると、デバッガーを使用できません。https://console.developers.google.com/debugに移動すると、右側に github リポジトリが読み込まれますが、左側のナビゲーション エリアにエラー メッセージが表示されます。

デバッグは利用できません。App Engine または Compute Engine で実行されている Java アプリケーションをデバッグできます

何がうまくいかないのか、またはデバッガーをデバッグする方法はありますか?

デフォルトの GAE サンドボックスの代わりにマネージド VM を使用する新しいApp Engine モジュールを追加しようとしています。その目的は、ユーザー向けのモジュールから呼び出すことができる新しいバージョンの SciPy と NumPy を実行できるモジュールを提供することです。Docker イメージ/コンテナーをローカルで正常にビルドして実行しましたが、Google サーバー上のカスタム バージョンにデプロイしようとすると、多くの問題が発生しました。

以下は、マネージド VM モジュール インスタンスのシリアル コンソール出力からのものです。このインスタンスは、制御できないと思われる問題が原因で再起動を続けています。

他の誰かがこれらに遭遇しましたか? 構成/展開プロセス中に何かを見逃しましたか?

FWIW: 私は数年間 GAE を使用しており、Google での勤務中にも GAE に貢献しました。モジュールや Docker の使用経験もあります。マネージド VM に関するドキュメントとツールは、現時点では非常に未熟であるように思われます。私は助けが必要です。

編集: shutdown.log からの追加情報は以下のとおりです。このdocker logsコマンドは、私のコードまたは Dockerfile のいずれでも実行されていません。Google が最後にコマンドを使用する方法にバグがあると思います。

サンドボックス環境でマネージド VM の使用を開始し、アプリケーションの複数のインスタンスが実行されていても、プラットフォームがそれらをロールアウトしないことrollingを経験したため、デプロイ中に定期的に 503 にヒットしました。

健康診断などで何か不足していませんか？