62

開発サーバーと本番サーバーを適切に構成したら、Google App Engineでステージング環境をセットアップして、新しい開発バージョンを本番環境にデプロイする前にライブでテストできるようにしたいと思います。

私は2つの異なるアプローチを知っています：

A.最初のオプションは、app.yaml バージョンパラメーターを変更することです。

version: app-staging

このアプローチが気に入らないのは、ステージングテストで本番データが汚染されていることです（間違っている場合は修正してください）。

  1. ステージングバージョンと本番バージョンは同じデータストアを共有します
  2. ステージングバージョンと本番バージョンは同じログを共有します

最初の点に関しては、新しい名前空間pythonAPIを使用して「修正」できるかどうかわかりません。

B. 2番目のオプションは、app.yaml アプリケーションパラメーターを変更することです。

application: foonamestaging

このアプローチでは、本番バージョンから完全に独立した2番目のアプリケーションを作成します。
私が目にする唯一の欠点は、2番目のアプリケーション（管理者が設定）を構成しなければならないことです。Gaebar
のようなバックアップ/復元ツールを使用すると、このソリューションもうまく機能します。

Webアプリケーションのステージング環境をセットアップするためにどのようなアプローチを使用していますか？
また、デプロイする前にyamlを変更するための自動スクリプトはありますか？

4

7 に答える 7

17

別のデータストアが必要な場合、オプションBは次の理由でよりクリーンなソリューションに見えます。

  1. 本番アプリケーションの実際のバージョン管理のためにバージョン機能を保持できます。
  2. トラフィック分割のバージョン機能を維持できます。
  3. マルチテナンシーの名前空間機能を維持できます。
  4. あるアプリから別のアプリにエンティティを簡単にコピーできます。名前空間間はそれほど簡単ではありません。
  5. 名前空間をサポートしていないAPIはまだほとんどありません。
  6. 複数の開発者がいるチームの場合、1人の本番環境へのアップロードを許可できます。
于 2012-04-23T11:47:55.250 に答える
14

セットアップで2番目のオプションを選択したのは、これが最も迅速なソリューションであり、展開時にアプリケーションパラメーターを変更するスクリプトをまだ作成していなかったためです。

しかし、私が今見ているように、オプションAはよりクリーンなソリューションです。数行のコード行で、バージョンに基づいてデータストアの名前空間を切り替えることができます。これは、http ：//code.google.com/appengine/docs/python/runtime.htmlに記載されているように、環境変数CURRENT_VERSION_IDから動的に取得できます。 #The_Environment

于 2010-09-27T15:26:38.807 に答える
6

オプションBを選択しました。プロジェクトを完全に分離するので、一般的にはより良いと思います。したがって、たとえば、ステージングサーバーの構成の一部を試してみても、セキュリティに影響を与えたり、セキュリティを危険にさらしたり、実稼働環境で他のバタフライ効果を引き起こしたりすることはありません。

デプロイスクリプトに関しては、app.yamlに任意のアプリケーション名を含めることができます。いくつかのダミー/開発者名とデプロイするときは、-Aパラメータを使用するだけです。

appcfg.py -A your-app-name update .

これにより、デプロイスクリプトが大幅に簡素化され、app.yamlで文字列の置換などを行う必要がなくなります。

于 2015-10-20T12:25:38.693 に答える
4

オプションBを使用します。

アプリケーションレベルでdevをprodから分離することの利点に関するZygmantasの提案に加えて、パフォーマンスをテストするためにdevアプリケーションも使用します。

通常、devインスタンスは、リソースをあまり利用できない状態で実行されます。これは、アプリケーションがどこで「遅い」と感じるかを確認するのに役立ちます。次に、パフォーマンス設定を個別に微調整して、何が違いを生むかを確認することもできます（フロントエンドインスタンスクラスなど）。

もちろん、時には弾丸を噛み、ライブで微調整して見る必要があります。しかし、他のアプリケーションで遊ぶのはいいことです。

まだ名前空間とバージョンを使用してください、ただdevは汚くて実験的です。

于 2012-10-13T11:51:30.817 に答える
0

別のプロジェクトを作成する必要はありません。dispatch.yamlを使用して、ステージングURLを同じプロジェクト内の別のサービス（ステージング）にルーティングできます。

  1. カスタムドメインstaging.yourdomain.comを作成します

  2. ステージングサービスを指定する別のapp-staging.yamlを作成します。

    ...サービス：ステージング..。

  3. 次のようなものを含むdistpatch.yamlを作成します

    ..。

    • url： "* staging.mydomain.com/"サービス：ステージング

    • url： "* mydomain.com/"サービス：デフォルト..。

  4. gloud app deploy app-staging.yaml dispatch.yaml
于 2020-04-29T02:24:09.747 に答える
0

Googleのドキュメントには次のように書かれています。

一般的な推奨事項は、環境ごとにアプリケーションごとに1つのプロジェクトを用意することです。たとえば、「app1」と「app2」の2つのアプリケーションがあり、それぞれに開発環境と本番環境がある場合、app1-dev、app1-prod、app2-dev、app2-prodの4つのプロジェクトがあります。これにより、環境が相互に分離されるため、開発プロジェクトへの変更が誤って本番環境に影響を与えることはなく、たとえば、すべての開発者に開発プロジェクトへのアクセスを許可し、CI / CDへの本番環境へのアクセスを制限できるため、アクセス制御が向上します。パイプライン

これを念頭に置いてdispatch.yaml、ルートディレクトリにファイルを追加し、単一のサービスを表し、そのサービスを含む各ディレクトリまたはリポジトリに、app.yamlここ​​で説明するように、関連するソースコードとともにファイルを追加します：AppEngineでのWebサービスの構造化

編集し、Pythonを使用している場合は、Pythonセクションの同等のリンクを確認してください。

于 2021-04-15T04:49:51.097 に答える
0

app.yamlでの使用はapplicationシャットダウンされました。

代わりにGoogleがお勧めします gcloud app deploy --project [YOUR_PROJECT_ID]

https://cloud.google.com/appengine/docs/standard/python/config/apprefをご覧ください

于 2021-10-15T04:41:28.830 に答える