2
2

【CodePipeline・CodeDeploy】リモートブランチにpushするだけで、EC2に自動デプロイする(ハンズオン)

Last updated at Posted at 2024-02-24

概要

GitHubで管理しているブランチにpushするだけで、自動でサーバーにデプロイする方法をご紹介します。
ハンズオンなので、深く考えなくても構築できるはずです。

図解

完成図は↓のようなものです。
image.png

①ローカルのブランチをGitHubにpushする
②GitHubの対象のブランチの変更をトリガーとして、CodePipelineが走る
②対象のEC2インスタンスにデプロイする

自動デプロイが実現すれば、ファイルをいちいちサーバーにコピーしなくても、pushするだけでコードの変更が反映されるようになります。

作業の流れ

事前準備

デプロイ先のEC2インスタンスを立ち上げる

今回デプロイしたいEC2インスタンスを立ち上げておきます。
インスタンスの起動方法はこちらの記事をご参照ください。

CodeDeployの設定

CodeDeployにアタッチするIAMロールの作成

IAMロールの作成

IAM > ロール > ロールを作成 をクリックする
image (9).png

ユースケースCodeDeployを選択する
image (10).png

ポリシーにAWSCodeDeployRoleがあることを確認して「次へ」
image (11).png

適当にロール名をつける。これは後に使用するのでわかりやすいものにする。
image (12).png

ロールを作成したら信頼関係タブを開き、ポリシーを確認する

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
                "Service": [
                    "codedeploy.amazonaws.com"
                ]
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

これでOK。

アプリケーションの作成

アプリケーションの作成

AWSのCodeDeploy > アプリケーション > アプリケーションの作成をクリック
image.png

アプリケーション名を任意の名前でつける
コンピューティングプラットフォームは、今回はEC2にデプロイするのでEC2/オンプレミスを選択

image (7).png

デプロイグループの作成

デプロイグループの作成

先ほど作成したアプリケーションをクリックして、デプロイグループタグからデプロイグループの作成をクリック

image (8).png

デプロイグループ名はわかりやすいものにし、サービスロールに先ほど作成したIAMロールを選択する
image (13).png

デプロイタイプでは、今回はインプレースを選択する

環境設定では、対象のEC2にデプロイするのでAmazon EC2インスタンスを選択し、
キー : Name
値 : EC2インスタンスの名前(deploy-testで作成済み)
にする。

今回はインスタンス一つにデプロイするが、複数のインスタンスがある場合はここで全て選択する。image (14).png

Load balancerタグのロードバランシングを有効にすると、デプロイ中に対象インスタンスにトラフィックが行かないようにすることができる。
デプロイ中はファイルの変更が行われているので、アクセスするタイミングによってはエラーになることがある。
今回は気にしないのでチェックを外しておく
image.png

デプロイグループの作成をクリック

CodePipelineの設定

CodePipelineの設定

デベロッパー用ツール > CodePipeline > パイプライン でパイプラインを作成するをクリック
image (15).png

パイプラインの設定を選択する

わかりやすいパイプライン名をつける
パイプラインタイプはどちらでもいいです
機能や料金体系が異なります。参考
今回はv1を選択します。
image (16).png

サービスロール新しいサービスロールを選択します
image (17).png

ソースステージを追加する

パイプラインが走るトリガーとなるソースを設定します。
今回はGitHubのdeploy_testリポジトリのmainブランチの変更をトリガーにします。
ソースプロバイダーで**GitHub(バージョン2)**を選択し、GitHubに接続するをクリックします。
image (18).png

↓の画面が開き、接続名を適当なものにして、「GitHubに接続する」をクリックします
image (19).png

GitHubにAWSが接続することを許可します。
image (20).png

「新しいアプリをインストールする」をクリック
image (21).png

AWS Connector for Githubをインストールします
image (22).png

すると、接続したGitHubのリポジトリが選択できるので、今回使用する「deploy_test」の「main」ブランチを選択します。
image (23).png

ビルドステージを追加する

CodeBuildでは、ソースコードをコンパイルし、ユニットテストを実行したりできます。
今回はデプロイするだけなので、ビルドステージをスキップします。

デプロイステージを追加する

どこにデプロイするのかを設定します。
デプロイプロバイダーは、AWS CodeDeployを使用します。
アプリケーション名とデプロイグループには、先ほど作成したアプリケーションを選択します。
image (24).png

最後に設定内容を確認し、パイプラインを作成します。

EC2インスタンスの設定

IAMロールの作成 EC2インスタンスに適切なIAMロールをアタッチしないとデプロイできないので、指定されたIAMポリシーを持つIAMロールを作成する。

IAMポリシーの作成

IAM > ポリシー からIAMポリシーを作成する
image (25).png

「アクセス許可を指定」ページでJSONを選択し、

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "s3:Get*",
                "s3:List*"
            ],
            "Effect": "Allow",
            "Resource": "*"
        }
    ]
}

とする

image (26).png

わかりやすい名前をつけて保存する。
image (27).png

IAMロールの作成

先ほど作成したIAMポリシーからIAMロールを作成する。
IAM > ロール > ロールを作成
image (28).png

ユースケースはEC2を選択
image (29).png

許可を追加で、先ほど作成したCodeDeployDemo-EC2-Permissionsを選択
image (30).png

適当に命名して保存する
image (31).png

EC2の設定

EC2にIAMロールをアタッチする

先ほど作成したIAMロールを対象のEC2インスタンスにアタッチする
EC2のコンソール画面で対象のインスタンスを選択し、アクション > セキュリティ > IAMロールを変更 をクリック
image (32).png

IAMロールを変更で、先ほど作成したIAMロールを選択してIAMロールの更新をする
image (33).png

CodeDeployエージェントをインスタンスにインストールする

EC2にsshして、CodeDeployエージェントをインストールする

sudo yum update
sudo yum install ruby
sudo yum install wget

ホームディレクトリに移動する

cd /home/ec2-user

CodeDeploy エージェントのインストーラをダウンロードする

# リージョンごとに変わる
wget https://bucket-name.s3.region-identifier.amazonaws.com/latest/install

東京リージョンの場合

wget https://aws-codedeploy-ap-northeast-1.s3.ap-northeast-1.amazonaws.com/latest/install

install ファイルに実行権限を設定する。

chmod +x ./install

CodeDeploy エージェントの最新バージョンをインストールする

sudo ./install auto

サービスが実行されているかどうかを確認する

systemctl status codedeploy-agent

Active: active (running)となっていたらOK

なっていなかったら

systemctl start codedeploy-agent

とする

appspec.ymlの作成

デプロイの処理について記述する、appspec.ymlというファイルを作成する
最低限デプロイに必要なのは↓

version: 0.0

os: linux 

files:
  - source: /
    destination: /home/ec2-user/

このappspec.ymlというファイルを、ルートディレクトリ直下に作成する

filessourceに、どのファイルをデプロイするかを指定する。
/とすれば、すべてのファイルがデプロイの対象になる。
index.htmlだけをデプロイ対象にしたい場合は、/index.htmlとする

destinationに、インスタンスのどのディレクトリにデプロイするかを指定する。
今回は /home/ec2-user/ にファイル群を保存することにする

詳細はこちら

実際にデプロイしてみる

これで準備は完了です。
では早速mainブランチをpushしてみましょう。
mainブランチに変更が加えられたので、それがトリガーになり設定したパイプラインが走ります。

image.png

この状態でしばらく待つと

image.png
無事デプロイが成功していることが確認できました!!

サーバーにsshして確認すると、指定したディレクトリにローカルで作成したファイル群が置かれていることが確認できました!
image.png

今回遭遇したエラー

数分待った後にデプロイが失敗する

デプロイが失敗し、↓のようなメッセージが表示されます。
image.png

The overall deployment failed because too many individual instances failed deployment, too few healthy instances are available for deployment, or some instances in your deployment group are experiencing problems.

View eventsからエラーメッセージを確認すると

CodeDeploy agent was not able to receive the lifecycle event. Check the CodeDeploy agent logs on your host and make sure the agent is running and can connect to the CodeDeploy server.

とあります。

image.png

CodeDeployエージェントをインストールして起動させているはずなのに、「起動しているか確認してね」というメッセージが出ているのです。

また、CodeDeployのエラーログを確認すると

tail -100 /var/log/aws/codedeploy-agent/codedeploy-agent.log

# ↓結果
2024-02-23T07:29:45 ERROR [codedeploy-agent(26422)]: InstanceAgent::Plugins::CodeDeployPlugin::CommandPoller: Missing credentials - please check if this instance was started with an IAM instance profile

とあります。

これは、CodeDeployエージェントをインストールした後に、EC2のIAMロールを更新したことが原因です。

なのでインスタンスにsshして、再度エージェントを起動させましょう。

sudo systemctl restart codedeploy-agent.service
2
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
2