問題タブ [aws-code-deploy]

負荷が高くなったときにインフラストラクチャを自動スケーリングしたい。でインフラストラクチャを実行していますAWS。Github発生時にアプリケーション コードをプルする必要があるという要件がありますautoscaling。コードは頻繁に変更されるため、 を取得しAMIてその からインスタンスを起動することはできませんAMI。だから私はから最新のコードを引っ張りたいrepositories。AWS は というサービスを開始しましたAWS CodeDeploy。このサービスを使用して、インスタンスの開始時にコードをプルするプロセスを自動化するにはどうすればよいですか?

PS を作成して、その IP を異なるセキュリティ グループinit scriptに自動的にアタッチし、インスタンスの起動時にEIPインスタンスを の下に置き、インスタンスload-balancerが自動スケーリングで終了したときにすべてを取り消します。

Amazon Linux に AWS Codedeploy Agent ファイルをダウンロードしようとしています。Amazon Linux のhttp://docs.aws.amazon.com/codedeploy/latest/userguide/how-to-run-agent.htmlに記載されている指示に従い、適切なインスタンス プロファイル、サービス ロールなどを作成しました。最新 (Amazon Linux、CLI パッケージ、これは真新しいインスタンスであり、少なくとも 3 つの真新しいインスタンスでこれを試しましたが、同じ結果が得られました)。すべてのインスタンスには、完全なアウトバウンド インターネット アクセスがあります。

ただし、S3 からインストールをダウンロードするための次のステートメントは常に失敗します。

aws s3 cp s3://aws-codedeploy-us-east-1/latest/install . --region us-east-1

エラーあり、HeadObject 操作の呼び出し時にクライアント エラー (403) が発生しました: Forbidden Completed 1 part(s) with ... file(s) left

誰でもこのエラーで私を助けることができますか?

アプリの新しいバージョンが公開されたら、CodeShip を使用してアプリを AWS EC2 インスタンスにデプロイします。CodeShip は最初にアプリを .zip にパッケージ化し、S3 に配置します。各展開パッケージは、異なるファイル名で生成されています。CodeShip でデプロイすると、 CodeDeployで新しいリビジョンが作成され、現在のすべてのインスタンスにデプロイされます。

一方向では、新しいバージョンをデプロイするたびに、すでに稼働しているすべてのインスタンスにデプロイされますが、アプリの最新リビジョンを CodeDeploy から新しく生まれたインスタンスにデプロイするにはどうすればよいですか? これを達成するために aws-sdk (Ruby または cli) を使用する方法はありますか?

OpsWorks を使用してインスタンスを維持し、カスタム Chef クックブックを使用して環境を構築しています。

ありがとう

AWS CodeDeploy でデプロイを適用する場合、ApplicationStop スクリプトフェーズ中に Amazon CloudWatch をシャットダウンし、ApplicationStart 中にデプロイ後に再起動する必要がありますか?

CodeDeploy AWS デプロイ システムを使用してCodeshipを介して Amazon Web Serviceに自動的にデプロイされる Node.js アプリケーションがあります。

展開プロセス中に、現在実行中の Web アプリケーションを停止するようにappspec.ymlに設定しました。デプロイが完了したら、Web アプリケーションを再度起動したいと考えています。

ただし、展開中にこれらのスクリプトのいずれかを appspec.yml ファイルから正常に呼び出すことができませんでした。

AWS 展開エージェント ログに表示されている現在のエラーは次のとおりです。

これは、これらのスクリプトを別の場所で実行しようとしていた古いバージョンの appspec.yml ファイルを参照しているようです。デプロイされたパッケージの appspec.yml ファイルの内容を変更しましたが、このエラー メッセージはデプロイごとに同じままです。

上記の appspec.yml ファイルに加えて、次の変更も試みました。

• 各フックのrunasパラメーターをリストしない
• デプロイされたディレクトリ内のスクリプトを参照する
• デプロイされたディレクトリ外のスクリプトを参照する
• バージョンパラメータを最初に0.0に設定する

残念ながら、appspec.yml のトラブルシューティングに関しては、 AWS のドキュメントを除いて、オンラインにはほとんどありません。

私が間違っている非常に明白なことは何ですか？

appspec.yml ファイルでパーミッションを設定しようとしていますが、デプロイを実行するとパーミッション設定の重複に関するエラーが発生し続けます

/data/html/httpdocs/artisan の重複する権限設定手順

これは、このスレッドの推奨に従って、現在 (リスト形式を除いて) appspec.yml で許可オブジェクトがどのように構成されているかです。実際には複数のファイルに異なるアクセス許可が必要ですが、1 つのファイルだけでは機能しないようです。正しい方法は何ですか？

一部の構成 (DB 資格情報、API キーなど) に環境変数を使用する Web アプリケーションがあります。現在、デプロイに Elastic Beanstalk を使用しており、AWS 内からこれらを簡単に設定できます。これは、コード ベースにこのような機密データがないため、非常に便利です。

ただし、Elastic Beanstalk からの切り替えを検討しているので、Web インスタンスでもう少し柔軟性を活用できます。当然のことながら、CodeDeploy を使用して (Codeship CI セットアップから) デプロイすることも検討しています。CodeDeploy は非常に簡単で、Codeship とうまく統合できましたが、Elastic Beanstalk のように CodeDeploy で環境変数を設定する組み込み機能がないことに気付きました。このプロセスのベストプラクティスはありますか?

アマゾン ウェブ サービスは、ニーズに応じて、Elastic Beanstalk、OpsWorks、Cloud Formation、Code Deploy などの継続的なデプロイおよび管理ツールを多数提供しています。基本的な考え方は、ダウンタイムなしでコードの展開とアップグレードを容易にすることです。また、AWS リソースを使用してベスト アーキテクチャ プラクティスを管理するのにも役立ちます。

簡単にするために、2 つのティア構造を持つ基本的なアーキテクチャを想定します。ロード バランサーの背後にあるアプリケーション サーバーのコレクションと、マルチゾーン RDS DB を使用した永続レイヤー。

インスタンス (アプリ サーバー) のフリート全体での実際のコード アップグレードは、理解しやすいものです。非常に単純化した概要として、AWS のサービスは各ノードを順番にアップグレードし、接続を引き渡すため、問題のインスタンスは使用されません。

しかし、DB のアップグレードがどのように管理されているのか理解できません。アプリケーションのバージョンを 1.0.0 から 2.0.0 に移行しようとしており、DB 構造を変更する必要があるとします。通常は、スクリプトまたは Flyway などのライブラリを使用してアップグレードを実行します。ただし、アップグレードするサーバーのフリートがある場合、フリート全体に 1.0.0 と 2.0.0 の両方のアプリケーションが存在し、それぞれが異なる DB 構造を必要とするポイントがあります。

DB移行を実行する最良の方法/時間は何かを知るために、これが実際にどのように達成されるか(高レベル)を理解する必要があります。彼らがこれを達成する方法はいくつかあると思いますが、どうすればそれを実現し、1.0.0 と 2.0.0 の両方でデータを失うことなく永続化できるようにするのか、私は苦労しています。

最初のアプリ ノードのアップグレードで DB 構造を移行し、同時に 1.0.0 のキャッシュ バージョンを作成するとします。1.0.0 アプリに接続しているユーザーはキャッシュされたバージョンの DB を使用して維持され、2.0.0 アプリに接続しているユーザーは新しく移行された DB に維持されます。すべてのアプリ ノードが移行されると、キャッシュされたデータが DB にマージされます。

マージはかなり複雑になるため、これを実行できる可能性は低いようですが、別の方法がわかりません。ポインタ/ヘルプをいただければ幸いです。

CodeDeploy を GitHub や S3 ではなく一般的な Git サーバーで動作させることが可能かどうかは誰にもわかりませんか?