ALBのHealth checkが原因とのこと
defaultでTimeout 5 seconds, Interval 30 secondsとなっているので、ELB Targets Groupsから、Health Checkの設定をそれぞれ、2秒、5秒に変更する

Developer Forum

Yes CodeDeploy depends on the ELB Health Check settings that you have configured your ELB with. After an instance is bound to the ELB, CodeDeploy wait for the status if the instance to be healthy ("inService") behind the load balancer. This health check is done by ELB and depends on the health check configuration you have set.

appspec.ymlにhttpd stop, start処理を入れる

– CodeDeployで、service httpd stop, service httpd startの処理を入れる

### shellの作成


isExistApp = `pgrep httpd`
if [[ -n $isExistApp ]]; then
	service httpd stop


chmod -R 777 /home/release/storage


service httpd start


version: 0.0
os: linux
  - source: /
    destination: /home/release
    - location: scripts/stop_server
      timout: 300
      runas: root
    - location: scripts/
      timeout: 300
      runas: root
    - location: scripts/start_server
      timout: 300
      runas: root

$ git add .
$ git commit -m “appspec.yml update”
$ git push -u origin master

# ec2 -> instance -> start
$ ssh ec2-user@${public_ip} -i ~/.ssh/***.pem
$ cd /home/release
$ ls
LICENSE appspec.yml index.html
// httpd serverをインストール
$ sudo yum update
$ sudo yum install httpd
$ sudo systemctl start httpd
$ sudo systemctl status httpd
$ sudo systemctl enable httpd
$ sudo systemctl is-enabled httpd

# CodeDeploy -> Applications -> create deployment -> commit idを入力
$ ls
LICENSE appspec.yml index.html scripts


BeforeInstall – 置き換えタスクセットが作成される前にタスクを実行
AfterInstall – 置き換えタスクセットが作成され、ターゲットグループの 1 つがそれに関連付けられた後、タスクを実行

Git pushでEC2にCodeDeploy

Git pushするとCodeDeployでEC2にDeployされる方法

## IAMユーザの作成
Add user: GitHub
Access type: Programmatic access
Policty: AWSCodeDeployFullAccess
Permission: CreatePolicy

Policy Name: CodeDeploy-Access


    "Version": "2020-03-07",
    "Statement": [
            "Effect": "Allow",
            "Action": "codedeploy:GetDeploymentConfig",
            "Resource": "arn:aws:codedeploy:ap-northeast-1:${account id}:deploymentconfig:*"
            "Effect": "Allow",
            "Action": "codedeploy:RegisterApplicationRevision",
            "Resource": "arn:aws:codedeploy:ap-northeast-1:${account id}:application:${application name}"
            "Effect": "Allow",
            "Action": "codedeploy:GetApplicationRevision",
            "Resource": "arn:aws:codedeploy:ap-northeast-1:${account id}:application:${application name}"
            "Effect": "Allow",
            "Action": "codedeploy:CreateDeployment",
            "Resource": "arn:aws:codedeploy:ap-northeast-1:${account id}:deploymentgroup:${application name}/${deploy_group}"

### GithubでCodeDeploy用のサービスを追加
– Deploy対象のレポジトリに移動
-> Settings->Integration & Services

Note: GitHub Services have been deprecated. Please contact your integrator for more information on how to migrate or replace a service with webhooks or GitHub Apps.



## 準備
### 1. IAMロール作成
– CodeDeploy
— Name: CodeDeploy
— Policy: CodeDeployRole
– ec2
— Name: s3readonly
— Policy: AmazonS3ReadOnlyAccess

### 2.VPC作成
– VPC, public subnet, InternetGateway, RouteTable作成
– SecurityGroup作成

## EC2
### 3.インスタンス作成
– Configure Instance DetailsのIAM roleで上記で作成したs3readonlyのroleを選択する
– VPC, public subnet, InternetGateway, RouteTable, SecurityGroupも作成したもの選択する
– SSHログイン

$ ssh ec2-user@****** -i  ~/.ssh/***.pem

### 4.EC2にCodeDeployAgentのインストール
$ sudo yum update
$ sudo yum install ruby
$ sudo yum install aws-cli
$ cd /home/ec2-user
$ aws s3 cp s3://aws-codedeploy-ap-northeast-1/latest/install . –region ap-northeast-1
$ chmod +x ./install
$ sudo ./install auto
$ sudo service codedeploy-agent status
The AWS CodeDeploy agent is running as PID 12399

## 5.Github repository

version: 0.0
os: linux
  - source: /
    destination: /home/release

### 6.CodeDeployのapplication作成
– ServicesのCodeDeployからCreate Application
— test

### 7. Deployment group
– Create deployment group押下
Deployment group name: testDeploy
Service role: codeDeploy
Deployment type: In place
Environment configuration: Amazon EC2 instances
Deployment settings: CodeDeployDefault.AllAtOnce

### 8.Create deployment
Deployment group: testDeply
Revision type: My application is stored in Github
GitHub token name: Githubのname
Repository name: ${githubname}/${repository name}
Commit ID: GithubのcommitのID

$ pwd
$ ls
LICENSE appspec.yml index.html

Processing flow of Code Deploy

The CodeDeploy agent for each instance polls CodeDeploy to decide what to retrieve from when specified Amazon S3 bucket or GitHub repository.

The CodeDeploy agent for each instance gets the target revision from the Amazon S3 bucket or GitHub repository and uses the appspec file procedure to deploy the content to the instance.

AWS CodeDeploy Error Handling

Can use the AWS CodeDeploy console, the AWS CLI, or the AWS CodeDeploy API to view details about deployment associated with an AWS account.


To view the deployment details using the AWS CLI, invoke the get-deployment command or the batch-get-deployments command to get a list of unique deploy IDs to use as input to the get-deployment and batch-get-deployments commands.

Is it better to acquire the execution log of codedeploy as devops thinking?

CodeDeploy Appspec.yml

AppSpec is the contents of the deployment process executed by AWS CodeDeploy. It is a file composed of YAML format that describes specific contents, what kind of things to handle in the deployment. In using CodeDeploy, it is very important to specify what are to be set in AppSpec.

The name of the AppSpec file must be appspec.yml and be placed in the root directory. If this requirement is not met, the deployment fails. Also, if there is an AppSpec file, you can make the deployment content including it into a compressed file in Zip.

file composition

version: 0.0
os: operating-system-name

start -> applicationstop -> downloadbundle -> beforeinstall -> install -> afterinstall -> applicationstart -> validateservice -> end

How to create Code deploy

CodeDeploy → Create role for EC2
Enable CodeDeploy to access the EC2
instance to be deployed, select “AWS service” and “CodeDeploy”

Open IAM Manager on the AWS console and select “role” link text below.

Search “CodeDeploy” with the role page and put checkbox.

Create role and review

create application

We can chose application type, in-place or green/blue.

AWS codedeploy

CodeDeploy is a managed service of AWS and can deploy source code and build artifacts for EC2 and on-premises servers and Lambda.

You can choose between in-place deployment and Blue / Green deployment to deploy to EC2 and on-premises servers.

You can select the source of the distribution from S3 and GitHub, but it will inevitably become s3 because the extension must be zip, tar, and tar.gz.

It is appsepec.yml that determines the rules for these deployment. Either type of appspeck.yml is required.

First of all, the content of the file being uploaded to s3 are as follows. Assume that sample.jar is already built and describes the command to start it.
├── appspec.yml
├── sample.jar

What is Blue / Green deployment?

Systems that take a method called Blue/Green deployment have increased.

In place: Reflect only the new revision application on the spot, leaving the instance intact.
Blue / Green: Build and replace a new instance for new revision applications.

And it can roughly classify the following three categories at the reflection speed with another axis different from the realization method.

All at once: Deploy all of them all at once with new revisions.
One by one: Deploy a new revision one by one.
Batch: Deploy a few new revisions(eg half)

There are people often thinking about Blue/Green deployment “only new instances of the revision are constructed by switching to the same number as it is now”, but this kind of deployment method is also called Red/Black deployment in recent years. This is just one way of “deployment at all at once in Blue/Green”

In place
– Merit
Since this method does not require additional instances at deployment, it is very effective in environments where it is not easy to create instances such as on-premises environments. Since it is enough to distribute only the application and restart or the like to the instance where hardware purchase, OS installation and various settings have already been completed, additional instance costs are not required at high speed.

– Demerit
One is tat remote operation is required. Remote operation is to operate on an instance that is running by way of ssh etc. In the case of using ssh, it is necessary to manage the key, so the construction of the instance becomes somewhat complicated, and the risk of opening a hole such as ssh etc. for the instance used in the production environment is reduced as much as possible from the very beginning it is safer to have it. Although we can alleviate this somewhat by using an agent type mechanism like AWS CodeDeploy, we do not change the risk of distributing files or executing arbitrary commands during operation.
Finally it is also difficult to roll back. Consistency is more likely to collapse when returning things that have changed once. “In Place”, there is the fact that you have to maintain two types of deployment, “deploy application” and “deploy under application”.

Blue/Green is not necessarily just switching before preparing the same scale in Blue/Green. The point is that it does not do anything for running, it creates a new revision on another instance and switches over the whole green/blue according to an arbitrary strategy.

– Merit
You can eliminate all the disadvantages of in place mentioned above. First of all, for remote operation, we do not make any changes to the running instance at deployment, so we do not need anything. Instances need not have any mechanisms related to deployment. This also simplifies the application development process.

Regarding consistency, if you create an instance image (Amazon Machine Image(AMI) for Amazon EC2) for each deployment as an extreme way of way of making it, you can guarantee that instances of the same revision are of exactly the same configuration. This is the method that Netflix is taking.

Rollback is very easy. Because Blue does not have any changes in deployment, you simply need to return traffic to Blue. Even after discarding Blue, restoration is also easy if you restart it from AMI of the past revision.

As described above, in Blue/Green deployment is carried out together with “deployment of application” with lower deployment, so for example, it is possible to realize OS updates and the like with exactly the same mechanism, the deployment process becomes one and maintenance also will be much easier.

– Demerit
For example, it is said that cost is high for making AMI for each deployment. Especially it takes time to rebuild from AMI when deploying minor fixes. This can be avoided to some extent by automating the creation of AMI and configuring a CI / CD pipeline that is already ready for deployment. Rather than creating an AMI for each deployemnt, you can keep the AMI of the basic configuration fixed so that you get the latest revision at instance startup, but in that case a breakdown of consistency similar to “In place” care should be taken as it can happen.

Also typically said is the cost of having to make extra instances. Although you wan to make a bit of modification you have to bother to set up an instance, trying all at once will double the cost temporarily, and that is certainly a waste.