私の問題は、異なるGCPプロジェクトを使用してdev、stage、prodの環境を作成したいということです。複数のプロジェクトに1つのアプリケーションエンジンアプリをデプロイする方法
基本的に同じコードを実行しており、別々の独立した環境で実行しています。
私は現在、コマンドラインでgcloud app deployを使ってアプリケーションを展開しています。
アプリを効率的に別のプロジェクトに配備するにはどうすればよいですか？
デフォルトのプロジェクトの設定を毎回変更するには、gcloud initを実行する必要がありますか？
いくつかのより良い方法が必要です。
また、dev ...環境をアプリエンジンのコンテキストで設定する方法がありますか？
ありがとうございました。
Pythonアプリケーションの場合、app.yamlファイルでアプリケーションを設定できます。これにより、プロジェクトごとに異なるデータを使用することができます。これは、appcfg.pyコマンドを使用してデプロイするときです。あなたはプロジェクトごとに、このファイル内のアプリケーションの値を変更したくない場合は、以下を実行することができます
application: myproject
version: alpha-001
runtime: python27
api_version: 1
threadsafe: true
handlers:
- url:/
script: home.app
：
appcfg.py -A <YOUR_PROJECT_ID> -V v1 update myapp/
https://cloud.google.com/appengine/docs/python/config/appref
を指定しない場合ファイル内のアプリケーションは、デプロイ時にappcfgコマンドで--applicationオプションを使用します。この要素は、gcloud app deployコマンドを使用してデプロイすると無視されます。
ありがとう、ジェフ！これはとても便利です。しかし、私は現在、柔軟なアプリエンジンを使用しています。 'app.yaml'ドキュメントにこの' application'フィールドがありませんでした。試してみるだけで、標準のアプリエンジンのように動作するかどうかを確認してください。 –
私は 'gcloud beta app deploy --project project-name'を使用して、同じコードを別の独立したプロジェクトにデプロイすることができました。 –
"標準的な"アプローチは、バージョンを使用することです。
qa.myApp.appspot.com
バージョンが次のステップの準備ができたら、別のバージョンIDで展開します。
複数のプロジェクトを使用する際の1つの問題は、プロジェクトごとに異なるデータセットを維持する必要があることです。
私はバージョンがジョブを実行できることを理解しています。しかし、そのようにすることで、基礎となるすべてのデータストアがすべて混在します（例：Datastore NoSQL）。これは孤立した環境の目的に反するものではないでしょうか？ –
必要に応じて、名前空間を使用してデータストア内のデータを分離できます。それはあなたのデータがどのように編成されているかによって異なります。一部のプロジェクトでは、テスト用のユーザーアカウントしか持っていません。テスト用のユーザーアカウントは、テストにのみ使用され、「ライブ」ユーザーと混同されません。 1つのプロジェクトでは、テスト用の「組織」がありました。これは、他の組織と同じように、各組織が独自のデータにしかアクセスできず、他の組織も見えなかったためです。 –
あなたのご意見ありがとうございます。私は個人的にはより孤立したenvを作成したいので、より細かい制御のために別のプロジェクトにすることにしました。 –
私の好みは、コードと同じバージョン管理によって管理異なる環境を持つことである - 支店を経由して推進し環境ごとに1つの支店、完全にコードの変更の自然な流れに合わせ展開を維持するには、マージ：dev - >stage - >production。
人的ミスのリスクを最小限に抑えるため、できるだけデプロイメント設定をコード自体に保存してください（つまり、ファイルからアプリケーションID、バージョンなどを取得し、配備に渡さないようにしてくださいargsとしてのcmd）。デプロイされたcmds自体はチートシートファイル（この時点で本格的なスクリプトを保証するにはあまりにも簡単です）で管理され、gitによって制御されます。この回答のイラスト：https://stackoverflow.com/a/34111170/4495081
デプロイメントは、個別の専用のワークスペース（対応するgitブランチに基づいて各環境に1つずつ）から実行されます（これらのワークスペースでブランチを切り替えることはありません）。必要な環境に対応するワークスペースを必要なバージョンに更新し、ワークスペースのチートシートから展開cmdをコピー＆ペーストします。
このモデルはIMHO CI/CD対応であり、簡単に完全自動化することができます。
代わりの、コンフィギュレーションごとに変更するgcloud initを使用して、より高速な複数のプロジェクトを展開するために、このコードを使用します。
gcloud app deploy -q --project [YOUR_PROJECT_ID]
プロジェクトは、同様のIDを持っている場合、のは言わせて：test1、test2、test3、test4、 1つのコマンドで4つのプロジェクトに展開できます。このコードを使用してください：
マルチ処理を利用するデプロイメントスクリプトを作成します。 – marcadian