In your examples, if the scripts decide to lower the minimum desired capacity when putting an instance into standby mode, I don't see it ever returning that minimum to the original value. Seems a like a problem that could come back to bite you long term, as your auto-scale group could get smaller and smaller.

Hi everyone,

I'm having a problem with my scripts, one of the uses the aws command to retrieve variables stored on SSM, something like this

aws ssm get-parameters-by-path \ --path "/keys" \ --with-decryption \ --query "Parameters[*].[Name,Value]" \ --output text

I have aws cli installed on my EC2 Ubuntu instance, and the script works just fine if run from the terminal, but not from codedeploy scripts.

What would be the correct approach to accomplish this?

Thanks

It appears to get stuck on a waiting for lifecycle action step.

It is almost as through transitioning the spot instance to standby causes a new ec2_instance_launching lifecycle transition and then it gets stuck waiting for another deployment hook

I have one instance where this works and another where it doesn't and ultimately the lifecycle hook times out the instance is terminated and a new instance is spun up.

Found more about this. Looks like a spot instance transitions through EC2_INSTANCE_LAUNCHING when moving from Standby to InService which causes all deployments targeting it to run again as though it was just created. Including the currently running deployment! It never finishes as you might imagine due to this recursion...

Dropping a spot instance to standby in the console and then putting it back in service works fine but unclear what console is doing...

Very weird...

I'm using this and I noticed that this code tends to change my desired and min values from 1 each to 0. If my code deploy fails, it never reverts those back and I run the risk of ASG spinning everything down and my site being down.
If I set my min and desired values, those should remain set as defined, not changed arbitrarily to pull an instance out. Are there really no commands to deregister a system specifically that it has to go through changing these values?

Hello, in #66 it is indicated that these scripts are not required for Blue/Green. However, I think they may be? In our situation we are doing a blue/green deployment, we initiate a codedeploy deployment and the new revision is installed onto the replacement instances (an autoscaling group) and reaches a ready state ready to reroute traffic.

After this, there is validation that takes place on the replacement instances outside of codedeploy. However, if there is a scaling event on this replacement autoscaling group, then the new instances that come up will not get a deployment (because there is no codedeploy lifecycle hook on this replacement asg). Once the complete / reroute action is initiated on CodeDeploy then traffic is rerouted to the instances that were present in the asg when the deployment began. The other instance that resulted from a scaling event will just sit in the ASG with no traffic routed to it.

There is a more destructive scenario, instead of a scaleout, a scalein occurs after the deployment is in a ready state. Now, the instance has been terminated but codedeploy doesn't know this yet in the deployment. Once a complete / reroute action is taken then the deployment fails when it tries to route traffic to the terminated instance.

One solution seems to be to turn off alarms at ApplicationStop and then turn them back on AfterAllowTraffic using these scripts. However, there is still a chance that a scaling event could occur between the AfterAllowTraffic <-> AfterBlockTraffic. What's the right way to handle this scenario?

Hi using the deregister_from_elb.sh script i notice when i run on an instance that is not part (this could happen for many reasons) of the ELB (already defined on common_functions.sh) the script checks 10 times every 30 seconds if the instance is not part of the ELB.

Why not if the instance is not part of the ELB just continue (exit the script)?

What do you think?

I have noticed that "Target Group" scripts has been added (ELB-V2). What is the difference between running CodeDeploy on a Target Group vs regular Load Balancers? I've been scratching my head on the exact benefits to a Target Group over a Load Balancer, and whether there is value in moving to V2.

I'm trying to solve unpredictable errors in the deregistering and registering of instances from a LB during a deployment - which have been occurring recently - following 3 months of continuous deployments with no hitch. Thanks in advance.

When I am trying deploy application code using aws codepipeline getting script failed error on the instance launched using autoscale group.Previously when I used only one instance it gave success.But now I added this asg instance for the deployment one at a time,

I have only aws cli version ie.latest 2.

Pull request #17 broke the ELB retrieval functionality for instances which are not part of an Auto Scaling group.

I am referring to function "get_elb_list()" in file "load-balancing/elb/common_functions.sh", broken by commits 7f9cdd2 and 5ab0577 from 04.09.2015. This function now displays the “list index out of range” error message for the aforementioned type on instances.

As described here by me (and the original poster) https://forums.aws.amazon.com/thread.jspa?messageID=639390

It seems there is some downtime while deploying. It may not be the fault of code deploy but I still figured it may be an issue since the claim in the blog post here: https://blogs.aws.amazon.com/application-management/post/Tx39X8HM93NXU47/Use-AWS-CodeDeploy-to-Deploy-to-Amazon-EC2-Instances-Behind-an-Elastic-Load-Bala is that the deploy IS one without downtime. I suspect it may be more an ELB issue than code deploy though.

Hi im using the deregister_from_elb.sh, but im getting this error when i make a new deployment. Is something wrong with common_functions.sh?

[stderr]sleep: missing operand
[stderr]Try 'sleep --help' for more information.
[stderr]Checking status of instance 'i-XXX' in load balancer 'my-elb-name'
[stderr]Instance 'i-XXX' not part of ELB 'my-elb-name'
[stderr]Instance is currently in state:
[stderr]/opt/codedeploy-agent/deployment-root/4aec7209-f088-4d9c-9dd9-8265a50873f5/d-DZ6G2VNKC/deployment-archive/scripts/common_functions.sh: line 285: [: 1737: unary operator expected
[stderr]sleep: missing operand
[stderr]Try 'sleep --help' for more information.
[stderr]Checking status of instance 'i-XXX' in load balancer 'my-elb-name'
[stderr]Instance 'i-XXX' not part of ELB 'my-elb-name'
[stderr]Instance is currently in state:
[stderr]/opt/codedeploy-agent/deployment-root/4aec7209-f088-4d9c-9dd9-8265a50873f5/d-DZ6G2VNKC/deployment-archive/scripts/common_functions.sh: line 285: [: 1738: unary operator expected
[stderr]sleep: missing operand

I think this happens when i deregister my instance from the elb. Maybe add a if condition and if the instance is not part of the ELB just continue/exit the function.

I've noticed that shellcheck picks up numerous real issues with the scripts in this repo. For example this is a commit fixing only the issue of local not propagating the return value from assignment (which means the $? checks after it will never fail) viraptor@9d55660
There are a few others as well.

It looks like the scripts could use a cleanup beyond a single PR.

Hello,

The documentation doesn't indicate whether these scripts are exclusively for Linux instances, or whether they can be used on Windows.

I notice that the appspec file contains 'linux' and I'm not sure if the register/deregister scripts are suitable for execution on Windows.

Please can you advise on this and whether there is an equivalent way to register/deregister instances from an ELB using CodeDeploy and Windows instances.

Thank you,

Luke

Hello,
I tryed to use the state ApplicationStop to deregister the insance from the ELB,
but it don't works.
Whilst if I use the state BeforeInstall all works fine.
Do you are agree with me?

please specify in comments that ELB_LIST elements must be separated with whitespace!

[When I start to build pipeline it gets this error]

My appspec.yml file is
version: 0.0
os: Linux
files:

• source: /
  destination: /mw
  hooks:
  BeforeInstall:
  • location: scripts/stop.sh
    timeout: 300
    runas: ubuntu
    AfterInstall:
  • location: scripts/start.sh
    timeout: 300
    runas: ubuntu

start.sh script is
#!/bin/bash
pm2 start mw-file-upload-cicd

stop.sh script is
#!/bin/bash
pm2 stop mw-file-upload-cicd

When I launch a new ASG instance, I have "user data" in the Launch Configuration that, among other things, runs to ensure yum is updated on the new server. My issue is that this user data custom bash script does not finish before the CodeDeploy lifecycle scripts run, so I end up having race conditions that prevent the new instance from deploying properly. For example, if I download and install the latest AWS tools from S3 during the user data script, those tools are needed to register and de-register from the ELB, but if the AWS CLI tools aren't available yet, the deploy fails when it tries to re-register.

Any help is greatly appreciated!

I'm at a loss here trying to get this to work.

I can ssh in and run the scripts manually with no problem, but codedeploy always errors out with the following:

Message: 
Script at specified location: /elb-scripts/deregister_from_elb.sh failed with exit code 127

Log Tail:
[stderr]/opt/codedeploy-agent/deployment-root/STUFF/deployment-archive/elb-scripts/deregister_from_elb.sh: line 23: error_exit: command not found
[stderr]/opt/codedeploy-agent/deployment-root/STUFF/deployment-archive/elb-scripts/deregister_from_elb.sh: line 27: msg: command not found
[stderr]/opt/codedeploy-agent/deployment-root/STUFF/deployment-archive/elb-scripts/deregister_from_elb.sh: line 30: msg: command not found
[stderr]/opt/codedeploy-agent/deployment-root/STUFF/deployment-archive/elb-scripts/deregister_from_elb.sh: line 31: autoscaling_group_name: command not found
[stderr]/opt/codedeploy-agent/deployment-root/STUFF/deployment-archive/elb-scripts/deregister_from_elb.sh: line 51: msg: command not found
[stderr]/opt/codedeploy-agent/deployment-root/STUFF/deployment-archive/elb-scripts/deregister_from_elb.sh: line 53: msg: command not found
[stderr]/opt/codedeploy-agent/deployment-root/STUFF/deployment-archive/elb-scripts/deregister_from_elb.sh: line 55: error_exit: command not found
[stderr]/opt/codedeploy-agent/deployment-root/STUFF/deployment-archive/elb-scripts/deregister_from_elb.sh: line 76: msg: command not found
[stderr]/opt/codedeploy-agent/deployment-root/STUFF/deployment-archive/elb-scripts/deregister_from_elb.sh: line 84: msg: command not found
[stderr]/opt/codedeploy-agent/deployment-root/STUFF/deployment-archive/elb-scripts/deregister_from_elb.sh: line 89: msg: command not found

This file references the "CodeDepoyDefault.OneAtATime" but it should be "CodeDeployDefault.OneAtATime" (missing the L in Deploy).

[stderr]Running AWS CLI with region: us-west-2
[stderr]Started deregister_from_elb.sh at 2016-08-17 18:11:31
[stderr]Checking if instance i-eba9fd36 is part of an AutoScaling group
[stderr]Found AutoScaling group for instance i-eba9fd36: FrontEndASG
[stderr]Checking that installed CLI version is at least at version required for AutoScaling Standby
[stderr]Checking minimum required CLI version (1.3.25) against installed version (1.9.15)
[stderr]Attempting to put instance into Standby
[stderr]Checking if this instance has already been moved in the Standby state
[stderr]Checking to see if ASG FrontEndASG will let us decrease desired capacity
[stderr]Putting instance i-eba9fd36 into Standby
[stderr]
[stderr]A client error (ValidationError) occurred when calling the EnterStandby operation: The instance i-eba9fd36 is not in InService.
[stderr]Failed to put instance i-eba9fd36 into Standby for ASG FrontEndASG.
[stderr][FATAL] Failed to move instance into standby

Due to exit 0 in deregister_from_elb.sh script(line 47) does not wait or try to de-register from target groups if an instances is also part of an Auto Scaling group

Hi everyone, i'm setting up the Github Action, AWS EC2, CodeDeploy. All the configuration seems working well. But excepts one thing. I can not understand and how can i solve it. If someone have experiences about this please help me.

I'm using:

• EC2 Rhel 8
• Node project (VueJs framework)

This is my cicd.yml file

on:
  push:
    branches:
    - paymentV2
    
name: Deploy VueJS to Amazon ECS
#on: [push]

jobs:
  deploy:
    name: Deploy
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: ['12.x']
        appname: ['staging-aws-codedeploy']
        deploy-group: ['staging']
        repo: ['project/MyProject']

    steps:
      - uses: actions/checkout@v2

      # Configure AWS credentials
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ap-southeast-1

      # Deploy to AWS
      - name: Deploy to AWS
        run: |
          aws deploy create-deployment \
          --application-name ${{ matrix.appname }} \
          --deployment-config-name CodeDeployDefault.OneAtATime \
          --deployment-group-name ${{ matrix.deploy-group }} \
          --file-exists-behavior OVERWRITE \
          --description "GitHub Deployment for the ${{ matrix.appname }}-${{ github.sha }}" \
          --github-location repository=${{ matrix.repo }},commitId=${{ github.sha }}

This is my appspec.yml

version: 0.0
os: linux
files:
  - source: /
    destination: /var/www/MyProject
hooks:
  ApplicationStart:
    - location: scripts/application_start.sh
      timeout: 300
      runas: root
  #scripts/application_start.sh
  #cd /var/www/MyProject
  #npm run build

This is the log from Github action & CodeDeploy AWS

I've tried editing the Vision.vue file and created the pull request on Github. Everything was working well. But one thing i'm confusing is why the modified file is existed. Please refer the image below

=> What am i expected is the modified file shouldn't have existed. I thought that Github should be automatically run git pull to get all new source code.
I've some more researched and found --file-exists-behavior with OVERWRITE but it seems not working as i want.
https://docs.aws.amazon.com/cli/latest/reference/deploy/create-deployment.html

==> Once again, i have no experience about CD by Github action & CodeDeploy. Everyone please help me and advice me the right thing. Thank you so much.

I've had the elb-v2 working brilliantly in production for months, and all of a sudden this week deploys no longer succeed.

They fail on Application Stop with the following logs:

...
[stderr]Instance is currently in state: EnteringStandby
[stderr]Instance is currently in state: EnteringStandby
[stderr]Instance is currently in state: EnteringStandby
[stderr]Instance failed to reach state, Standby within 60 seconds

During the deregister scripts, if the host is a part of an ASG and min size matches desired size, the ASG min size setting gets decremented so that ASG does not spin up a new instance, and when the host goes back into service, the ASG min size gets incremented. However, if the deployment fails, the script will never increase the capacity, leaving the ASG with one less min size. Since putting a host into standby reduces the desired capacity, an ASG could have its min size reduced by multiple hosts during a deployment, and it will never be increased back to where it was.

When the min size gets decremented, a flag gets set in a temporary file that's around for the life of the deployment, but will not be viewed by any subsequent deployments. One option might be to set the flag in a permanent location to track the state mutations.

Issue #57 is an example of this.

Supported Solution

If CodeDeploy customers are not aware, CodeDeploy has direct support for some ELB situations. As of 5/1/17, CodeDeploy started supporting classic ELB via the service, which handles all of the registering and deregistering from the load balancer and allows additional lifecycle events, and it solves many of the limitations in these scripts. If your use case is not currently supported (i.e. you use application ELB), check in occasionally here to see if CodeDeploy has added support.

If you onboard with CodeDeploy ELB support, you should no longer need to use these load balancer scripts.

Noticed that currently register_from_elb is placed in the hook ApplicationStart while it would make more sense to put it at ValidateService?
If Validate fails, you do not want to register it again to the ELB

In the ELB common_function.sh you could set the ELB_LIST='all' and that would prevent the need to hard code ELB values. Im wondering if there is a way to do this for an ALB in elb_v2/ for TARGET_GROUP_LIST.

I have different TG for dev, staging, and prod and would have to manually change the script for every region, in addition the way our setup works it auto generates a TG name so if anything needed to change we would need to modify the script again as the TG name would have changed.

i intermittently get the following error with codedeploy which is under an ASG/ELB
More often than not it fails. I made the script skip the checks for now, but would like it to work, so i'm aware of cli requirements.

[stderr]Checking minimum required CLI version (1.3.25) against installed version (1.2.9)
[stderr][FATAL] CLI must be at least version .. to work with AutoScaling Standby

actual verison is 1.7.43:
aws --version
aws-cli/1.7.43 Python/2.7.6 Linux/3.13.0-61-generic

For customers who turn off IMDSv1 the helper scripts will fail:

Consider retrieving the IMDSv2 token before making calls like the one above.

I have 3 env Dev Staging and Prod, then in ELB_LIST I have to give all 3 ELB names if I want to use same branch to deploy on all 3 env?

Bit confuse how this can be done without env dependency

The docs note:

WARNING: If you are using [processes suspend] functionality you should only use CodeDepoyDefault.OneAtATime deployment configuration to ensure a serial execution of the scripts. Concurrent runs are not supported.

To support concurrent runs, we use an alternative approach: suspend/resume around the entire deploy via a deployment group trigger. Here's the code that our lambda function uses; feel free to link it in the docs: https://gist.github.com/simon-weber/285cadb567c11268a15db1b97fe2cbc5.

From sample it's not entirely clear what is handling or managing httpd.conf or virtual host to point to the /var/www/html/salt/index.html

magic? 🌈

I've been having some issues with the ELB register & deregister scripts timing out too quickly and causing a failed build.

I tracked it down to my ELB HealthCheck settings:

Healthy Threshold: 2
Unhealthy Threshold: 5
Interval: 30 seconds

In load-balancing/elb/common_functions.sh it uses the HealthyThreshold (in reset_waiter_timeout) to determine when to give up waiting for the state to change before throwing a fatal error (therefore causing the deploy to fail).

IMO it should be using the UnhealthyThreshold so that the build fails if the instance fulfils the unhealthy threshold limits.

We just started using CodeDeploy with ASG and ELB, and we achieve zero downtime when we use register_with_elb.sh and deregister_from_elb.sh. Today I simulated a situation where a deploy step before deregister_from_elb.sh fails. In that case, the server instance in ASG stays in Standby mode and the capacity of ASG is decreased by one because deregister_from_elb.sh is never executed.

Currently, I have to manually increase the ASG capacity back to normal and move the server instance out of Standby. This isn't acceptable. Is there a way to do proper cleanup automatically after a failed deploy?

The only way that came to my mind is to add error handling logic to every deploy script I run between register_with_elb.sh and deregister_from_elb.sh scripts.

You don't need to edit ELB_LIST anymore. There is a method in common_functions.sh that populates it for you.

package "codedeploy-agent" fails to create the init.d file.

Running yum install manually creates the init.d file successfully?

Any idea how to fix this?

Hello,

Per the important-notice-about-handling-autoscaling-processes, I'm curious if we need to use the scripts in common_functions.sh and the HANDLE_PROCS configurations when using blue/green deployments with ASGs instead of in-place deployments with ASGs. It seems like since blue/green has native support for autoscaling groups, that it would handle enable/disabling autoscaling events behind the scenes?

Thanks in advance!

The ELB example has been updated to suspend/resume ASG processes. The ELBv2 examples should include these as well.

There is a typo in the readme for the requirements. It should be:

elasticloadbalancing:DeregisterTargets

instead of

elasticloadbalancing:DeregisterTagets

Its missing an "r" in Targets

Thanks!

@geisbruch @Jmcfar @mpantelimon

There is an undesirable edge case that occurs when a Code Deploy revision is deployed to an ASG where there is only 1 "In-Service" server:

aws-codedeploy-samples/load-balancing/elb/common_functions.sh autoscaling_enter_standby() will cause the ASG minimum and desired number of servers to drop from 1 to 0 while the new revision is being deployed. This will cause the ASG to terminate the instance after the deployment is completed. You will then be left with no servers "In-Service" for your application.

For a "no-loss-time" deployment, the desired and minimum servers for the ASG should be incremented if the ASG maximum is high enough before taking a server offline to deploy a new revision.

Hello,
I'm trying to use the scripts into elb-v2 folder for a solution with codedeploy and and ALB.
But i receive a timeout to the BeforeInstall event with this output:

Error Code
ScriptTimedOut
Script Name
scripts/deregister_from_elb.sh
Message
Script at specified location: scripts/deregister_from_elb.sh failed to complete in 360 seconds
Log Tail

[stderr]aws --region eu-central-1 autoscaling describe-auto-scaling-instances --instance-ids i-0004630d2544ec616 --output text --query AutoScalingInstances[0].AutoScalingGroupName
[stderr] * 4 failure(s), retrying in 29 second(s)
[stderr]/opt/codedeploy-agent/deployment-root/385c8c99-acfe-4642-b6f4-45bc2db579cb/d-MWAP9TGMQ/deployment-archive/scripts/common_functions.sh: line 96: aws: command not found
[stderr]aws --region eu-central-1 autoscaling describe-auto-scaling-instances --instance-ids i-0004630d2544ec616 --output text --query AutoScalingInstances[0].AutoScalingGroupName
[stderr] * 5 failure(s), retrying in 63 second(s)
[stderr]/opt/codedeploy-agent/deployment-root/385c8c99-acfe-4642-b6f4-45bc2db579cb/d-MWAP9TGMQ/deployment-archive/scripts/common_functions.sh: line 96: aws: command not found
[stderr]aws --region eu-central-1 autoscaling describe-auto-scaling-instances --instance-ids i-0004630d2544ec616 --output text --query AutoScalingInstances[0].AutoScalingGroupName
[stderr] * 6 failure(s), retrying in 120 second(s)
[stderr]/opt/codedeploy-agent/deployment-root/385c8c99-acfe-4642-b6f4-45bc2db579cb/d-MWAP9TGMQ/deployment-archive/scripts/common_functions.sh: line 96: aws: command not found
[stderr]aws --region eu-central-1 autoscaling describe-auto-scaling-instances --instance-ids i-0004630d2544ec616 --output text --query AutoScalingInstances[0].AutoScalingGroupName
[stderr] * 7 failure(s), retrying in 120 second(s)
[stderr]/opt/codedeploy-agent/deployment-root/385c8c99-acfe-4642-b6f4-45bc2db579cb/d-MWAP9TGMQ/deployment-archive/scripts/common_functions.sh: line 96: aws: command not found
[stderr]aws --region eu-central-1 autoscaling describe-auto-scaling-instances --instance-ids i-0004630d2544ec616 --output text --query AutoScalingInstances[0].AutoScalingGroupName
[stderr] * 8 failure(s), retrying in 120 second(s)

What I mistake?
Thanks

We have an issue where the ASG will rebalance across AZs while we're in the middle of a deploy. For example, we have four instances...
1 in a, 1 in b, and 2 in c.

If the deploy starts with the instance in a, then the ASG will immediately start trying to rebalance across AZs. This causes an instance to come up with an old version of code since the new version has not yet successfully deployed.

Both deregister_from_elb.sh and register_with_elb.sh reference . $(dirname $0)/application_vars.sh but that script doesn't exist.

Seems like the vars are in common_functions.sh so those lines could simply be removed?

According to this one:

https://stackoverflow.com/questions/21059124/is-it-yaml-or-yml/21059164

.yaml is the preferred extension to .yml

I think it does make sense that appspec could be appspec.yml AND appspec.yaml. A current codeDeploy task with appspec.yaml instead of appspec.yml fails with:

The CodeDeploy agent did not find an AppSpec file within the unpacked revision directory at revision-relative path "appspec.yml". The revision was unpacked to directory .... ... ...

The proper approach should be to allow for the deprecated .yml format but also to allow for .yaml file as that's the recommended extension.

We currently use these scripts during deployment to deregister our instances from an ASG during deployment. However, we've discovered what appears to be a race condition when using HalfAtATime deployment in CodeDeploy and using more than 2 EC2 instances in the ASG.

For example, if you have 4 EC2 instances behind an ASG and run a HalfAtATime deployment on them from CodeDeploy, it will run the deployment scripts against 2 of the 4 at the same time. From there, one of them will instantly fail citing:

[stderr]An error occurred (ValidationError) when calling the EnterStandby operation: AutoScalingGroup [DeploymentGroup] has min-size=3, max-size=70, and desired-size=3. To place into standby 1 instances, please update the AutoScalingGroup sizes appropriately.

I believe this is because both EC2 instances are running autoscaling_enter_standby() at the same time. So they both scale the ASG min and desired down to 3 at the same time and then attempt to move into standby, however only one gets in. When the other makes the attempt, it fails because by that time there are 3 in the ASG and you can't take another one away.

Is there any way to adjust the script to account for this issue? Without that, HalfAtATime deployment is pretty useless given that you're limited to just 2 instances in the ASG at a time.

Hello there, hope you can help me or guide in the right direction.

A couple of weeks ago I configured the scripts mentioned the elb load balancing section but they made the deployment very, very slow. Taking up to 9 minutes per machine (my deployment group have 7 machines).

One day, I decided to stop using those scripts and removed the instructions from appspec.yml and now every deployment gets stuck in:

LifecycleEvent - ApplicationStop
Script - scripts/deregister_from_elb.sh
[stderr]Running AWS CLI with region: us-east-1
[stderr]Started deregister_from_elb.sh at 2017-09-04 15:54:46
[stderr]Checking if instance i-0796eb8c749eb254c is part of an AutoScaling group
[stderr]Instance is not part of an ASG, trying with ELB...
[stderr][FATAL] ELB_LIST is empty. Must have at least one load balancer to deregister from, or "_all_", "_any_" values.

It always fails in the same machine.

1. I've removed the scripts (common_functions, deregister_from and register_to) from the source code folder
   1.1. common_functions file have the ELB_LIST with any value
2. appspec.yml does not reference those scripts anymore
3. Deactivated the option in CodeDeploy to stop sending traffic to on-deployment machines
4. Had to edit appspec.yml in server (appspec.yml file in the server where it is failing had the scripts reference)
5. I've restarted code deploy agent, rebooted the machine

I'm really, really stuck with this. Thinking about launching new machines, one by one, to see if it helps but I'd like to know what's really going on.

I am using the elb scripts from https://github.com/awslabs/aws-codedeploy-samples/tree/master/load-balancing/elb to remove my ec2 instances from the load balancer before I do my code updates.

I need to define the load balancer in the ELB_LIST variable of the common_functions.sh bash script. This load balancer will be different for each environment (or deployment group).

Is there a way I can set this variable based on which deployment group I am deploying too from within this bash script?

The application artifacts will be the same, but deployed to different environments or groups and hence, different load balancers.

Full question posted here as well: http://stackoverflow.com/questions/30650673/determine-deployment-group-from-appspec-yml

Thanks!

while i am detaching instance from classic elb , i get the instance id ,region and elb name from the meta data so in that case there is no need to give elb name ,same script executes and detaches from any instance .
how can i do this for elbv2?

Is there a windows version of these scripts? If so, where?

autoscaling_exit_standby() is unable to move fresh ASG instances out of Pending:Wait into InService. The function expects the instance to be in Standby, but they are fresh instances that were never InService or moved from InService to Standby.

Reference logs in:

https://forums.aws.amazon.com/thread.jspa?messageID=589491&#589491

I thought I could fix this by checking for the Pending:Wait status and calling complete-lifecycle-action, but I don't have any way to get --lifecycle-action-token.

Please Help!! I can't use Code Deploy without Auto Scale Groups!!!