5

I am trying to set up auto-deployment from GitHub to AWS, using EC2 behind an ELB.

After following the Tutorial: Use AWS CodeDeploy to Deploy an Application from GitHub, my deployment fails at the BlockTraffic event, after trying for an hour (1h 2min last time) with error code ScriptFailed. I'm not sure how to troubleshoot the issue/where to look.

The ELB target group target health status: healthy

Health Check configuration:

Healthy threshold: 2 Unhealthy threshold: 2 Timeout: 5 Interval: 10 Success codes: 200

Improve this question
2
  • Did you find the solution for this issue? I am having the same problem. Commented Jun 16, 2020 at 7:26
  • @DynamicScope Yes. I can't remember what it was exactly, but I think I was missing an AppSpec file, or an ApplicationStart.sh. I had to learn about systemd and daemons Commented Jun 17, 2020 at 6:29

5 Answers 5

Reset to default
2

The issue I ran into is that for an ELB if the port was not the expected port, code deploy's BlockTraffic would not know how to deregister the instance from the target group.

In my example I had my HTTPS ELB communicate via HTTP to port 3000 on each of my target groups. I found the specific root cause by using this guide: https://aws.amazon.com/premiumsupport/knowledge-center/codedeploy-failed-ec2-deployment/

It gave the following output which identified the instance of me using port 3000 instead of the expected port 80.

During BlockTraffic, Codedeploy service invoke the Loadbalancer to de-register the instance from the target group before start installing the application revision DeregisterTargets API call can be noticed in cloudtrail logs during BlockTraffic lifecycle hook Currently Codedeploy does not support the case when the target group have a different port than the port used to register the instance. ** DeregisterTargets API will not be able to deregister the instance if the port configured in the Target group is different You need to make sure that both the target group and the instance are configured to use the same port. BlockTraffic depends mainly on the de-registration delay on the target group or connection draining on Classic LB. To speed up this step, the de-registration delay /connection draining value can be reduced to a reasonable value.
Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

0

Make sure your Code Deploy role has sufficient access to register and de-register instance if it is behind ELB.

Below permissions may required. 

"elasticloadbalancing:DescribeLoadBalancers", "elasticloadbalancing:DescribeInstanceHealth", "elasticloadbalancing:RegisterInstancesWithLoadBalancer", "elasticloadbalancing:DeregisterInstancesFromLoadBalancer", "elasticloadbalancing:DescribeTargetGroups", "elasticloadbalancing:DescribeTargetHealth", "elasticloadbalancing:RegisterTargets", "elasticloadbalancing:DeregisterTargets"
Improve this answer

Comments

0

There is an AWSCodeDeployRole policy, makes it very easy to cover the permissions you need to use codedeploy

Improve this answer

1 Comment

Is this an answer or a comment
0

I had the same issue and I realised that in the deployment group, I didn't tag the instance id of the target group, upon which I was doing health checks to find whether the target group was healthy or not. Hence deployment group knew the target group, it has to deal traffic with.

Improve this answer

Comments

-1

don't enable Load Balancer on Code Deploy deployment group for Pipeline and you will get rid off that BlockTraffic and AllowTraffic steps.

Screenshot

Improve this answer

2 Comments

Please explain further on how your answer addresses the question
just disable Load Balancer and BlockTraffic step will be removed, and problem is solved.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.