0

Elastic Beanstalk に 1 つの prod 環境と 1 つの dev 環境があるとします。コードを dev にデプロイすると問題なく動作しますが、本番環境にデプロイするとエラーが発生します (デプロイ中にインスタンスが破損したり、apache が壊れたりすることがあるため、これが発生する可能性があることに注意してください)。このソリューションの長所と短所は何ですか:

  1. デプロイごとに切り替える 2 つの本番環境がある
  2. 使用されていないものにデプロイする
  3. デプロイが機能する場合は、yourdomain.com を新しいプロダクションに向けます。そうでない場合は、古いプロダクションは安全です

さて、SEO は懸念事項ですか? 2 つのエラスティック Beanstalk 環境間でドメインを切り替えた場合、SEO は損なわれますか?

4

1 に答える 1

3

次のソリューションは、問題なく何度も使用したソリューションですが、本番環境で使用する前に常にソリューションをテストすることを忘れないでください.

このソリューションでは、内部 DNS 名にマップする必要がある次の環境名を使用します。

PROD01 .elasticbeanstalk.com > www.example.com
PROD02 .elasticbeanstalk.com
DEV01 .elasticbeanstalk.com > dev-www.example.com

通常、アプリケーションをローカルで開発およびテストした後、アプリケーションを AWS Elastic Beanstalk 環境DEV01にデプロイします。この時点で、アプリケーションは URL dev-www.example.com で公開されます。

アプリケーションのテストが完了したので、アプリケーションの編集、再デプロイ、および結果の確認を簡単に行うことができます。

アプリケーションに加えた変更に満足したら、それをPROD02 .elasticbeanstalk.com 本番環境にデプロイできます。[アプリケーション バージョン] ページを使用して、 DEV01で実行されているコードをPROD02にプロモートします。ホスト ファイルを使用して、すべてが正常であることを確認してから、URL スワップを実行します。

これにより、 PROD01 .elasticbeanstalk.com とPROD02 .elasticbeanstalk.com の環境 URL が、アプリケーションのダウンタイムなしでシームレスに切り替わります。

すべてのトラフィックが切り替えられたことを確認したら、同じ方法に従って元の本番環境を更新し、元の運用環境に切り替えてPROD01 .elasticbeanstalk.com を削除して、余​​分なコストを回避できます (または、気にしない場合はそのままにしておくことができます)。 $$の支出）。

于 2014-10-28T08:15:43.710 に答える