渡辺です。 CodeDeployでは、リビジョン(デプロイするパッケージ)を作成するプロセスと、リビジョンを各サーバにデプロイするプロセスは独立しています。 したがって、リビジョン作成は開発チームさん、デプロイは運用チームさんと役割を分担できるようになっています。 また、デプロイプロセスが分離していることで、過去のバージョンへの再デプロイ(切り戻し)なども容易なのです。 とはいえ、本番環境や検証環境と異なり、開発環境では最新版をゴリゴリとデプロイできた方が便利ですね。 自動化するんよ というわけで、AWSCLIを利用してリビジョン作成とデプロイを連動させてみました。 BUILD_DIR=. REGION=ap-northeast-1 APP_NAME=app_development DEPLOYMENT_GROUP=development_server DEPLOYMENT_CONFIG=
AWSのPULL型デプロイサービスCodeDeployはデプロイの各ライフサイクルイベントに処理をフックすることができます。 デプロイは アプリケーションの停止 アプリケーションファイルのダウンロード アプリケーションファイルのインストール アプリケーションの起動 という順で実行され、 次のデプロイライフサイクル図において、オレンジ背景の箇所が実際にフック処理を割り込めるイベントです。 イベント名から各イベントで何をやっているか想像はつきますが、ApplicationStopイベントだけは注意が必要なため、補足します。 ApplicationStop イベントフックはどう実行される? ライフサイクルイベントのフローを見ればわかるように、ApplicationStop イベントは DownloadBundle イベントよりも前に存在します。 そのため、ApplicationStop イベント
permissions: - object: object-specification pattern: pattern-specification except: exception-specification owner: owner-account-name group: group-name mode: mode-specification acls: - acls-specification context: user: user-specification type: type-specification range: range-specification type: - object-type手順は次のとおりです。 object – 必須。これは、インスタンスへのファイルシステムオブジェクトのコピー後に、指定されたアクセス権限を適用する一連のファイルシステムオブジェクト (
はじめに オフィスの休憩室にあるNintendo Switchのマリオカートで遊ぶのが楽しすぎて、自宅にも欲しくなってきました。佐々木です。 最近自分のプロジェクトでCircle CIとAWS CodeDeployを連携させて、デプロイを自動化したので、その時の手順について紹介します。 構成/要件 今回は以下のような構成と条件でセットアップを行いました。 ソースコードはGithub上に存在する AWS CodeDeployを使って、AutoScalingGroup配下のEC2インスタンスへデプロイする Circle CIでユニットテストを実行して、成功した時のみデプロイする デプロイはビルドがdevelopブランチに対して実行された時のみ行う やること AWS CodeDeploy上にデプロイメントグループを作成する デプロイ用のS3バケットを作成する デプロイ用のIAMユーザーを作成して
AWS CodeDeployでは、デプロイするアプリケーションをリビジョンと呼ばれるアーカイブとしてS3やCodeCommitにアップロードします。 リビジョンはS3やCodeCommitのバージョニングすることも可能です。 しかし、運用面では各リビジョンにバージョン情報が付与されている方が解りやすくなります。 今回は、S3にアップロードする時にバージョン情報を付与する手順を紹介します。 リビジョンのバージョン情報 リビジョンをS3にアップロードする場合は、aws deploy pushコマンドを利用するのが便利です。 この時、アップロード先のS3ロケーション(バケット名+キー)を指定します。 aws deploy push --region $REGION --application-name $APP_NAME --s3-location s3://$S3_BUCKET/$S3_KEY
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 CodeDeploy を使用してデプロイを再デプロイしてロールバックする CodeDeploy は、以前にデプロイされたアプリケーションのリビジョンを新しいデプロイとして再デプロイすることにより、デプロイを以前のバージョンに戻します。これらのロールバックされたデプロイは、前のデプロイのバージョンを復元するのではなく、新しいデプロイ ID を使用する技術的に新しいデプロイです。 デプロイは、自動または手動でロールバックできます。 自動ロールバック デプロイが失敗した場合、または指定した監視しきい値に達した場合、自動的にロールバックするように、デプロイグループまたはデプロイを設定できます。この場合、アプリケーションリビジョンの最後の既知の正常なバージョンがデプロイされま
渡辺です。 CodeDeployでは、デプロイ時に任意のスクリプトを実行できます。 また、スクリプトの実行ポイントは複数あり、細かく制御可能です。 しかしながら、スクリプトが実行されないでハマることがあります。 フックスクリプト実行の仕組みを正しく理解し、ベストプラクティスを知ることで不要なトラブルを回避してください。 フックスクリプトはアプリケーションにバンドルする フックスクリプトはアプリケーションのアーカイブ(zip)にバンドルし、S3やCodeCommitにアップロードします。 通常、アプリケーションにhooksディレクトリやScripsディレクトリを作成し、実行権を付与したスクリプトファイルを配置します。 スクリプトファイルはシェルスクリプトだけでなく、実行可能であればPythonやRubyのスクリプトでも構いません。 . ├── appspec.yml ├── app └──
AppSpec AppSpec は AWS CodeDeploy (以下、CodeDeploy) で実行するデプロイ処理の内容です。デプロイでどのようなことを処理させるか、具体的な内容を記述していく YAML フォーマットで構成されたファイルです。 CodeDeploy を利用する上で、AppSpec でどのような設定を記述するかがとても重要になってきます。 ということで、本記事ではこちらのドキュメントを意訳していきたいと思います。 はじめに Application Specification File (AppSpec file) は、CodeDeploy があなたの EC2 インスタンスに対して、Amazon S3 または GitHub にあるアプリケーションのリビジョンをどのようにインストールするか決定する、YAML フォーマットのファイルです。また同様に、デプロイの様々なライフサイ
CodeDeployとは CodeDeployはEC2/AutoScalingのみに特化したデプロイ系サービス 似たものではElasticBeanstalk、OpsWorksなどがある ローテーションやCIツールとの連携などの細やかなデプロイが可能なサービス 費用はかからずEC2インスタンス利用料のみ 東京、オレゴン、シンガポールの3リージョンで実行したかったがシンガポールが未対応。 今後の対応に期待してシンガポールではなくアイルランドかフランクフルトを選択することにする。 Supported Regions 米国東部 (バージニア北部) 米国西部 (オレゴン) EU (アイルランド) EU (フランクフルト) アジアパシフィック (シドニー) アジアパシフィック (東京)既存のインスタンスで使うにはCodeDeploy Agentを入れる必要がある。 環境としてはCentOS6に色々入っ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く