6

At the moment I have an AutoScaling Group (ASG) of GoCD build agents without any scaling policies. I have created some custom metrics that indicate how many build agents are currently idle and I'd like to scale based off of that. My concern is that when scaling down, the ASG may terminate instances that are in the middle of a build. This may result in failed builds and delayed builds.

How can I scale down an ASG without terminating instances that are in use?

Improve this question
2
  • Did you try to scale down? If true, what was the outcome?
    – 030
    Commented Oct 29, 2017 at 12:43
  • I have not. I can't risk terminating real builds in production, and I unfortunately don't have a good environment to test with. However, I know that the ASG will randomly pick instances to terminate (how would it know which instances are running builds?) so I'm quite confident that this is a real issue. I place a lot of emphasis on not risking terminating builds because to me, build/release speed is one of the most important things to our engineering department.
    – user2640621
    Commented Oct 29, 2017 at 22:52

3 Answers 3

Reset to default
3

Auto Scaling groups have a useful feature for this, named lifecycle hooks.

Worflow taken from the documentation above:

Lifecycle workflow

As you can notice there's a Scale in step, triggering a Terminating:Wait for the autoscaling group and notifying the instance to be terminated, the instance has now to do it's work and once done signal it is ok to be terminated.

If the task can take longer than the autoscaling group HeartbeatTimeout parameter you can reset the timeout with (quoting still from the same page):

Restart the timeout period by recording a heartbeat, using the record-lifecycle-action-heartbeat command or the RecordLifecycleActionHeartbeat operation. This increments the heartbeat timeout by the timeout value specified when you created the lifecycle hook. For example, if the timeout value is 1 hour, and you call this command after 30 minutes, the instance remains in a wait state for an additional hour, or a total of 90 minutes.

So for your case, the lifecycle notification should startup a kind of script/program which will:

  • prevent this builder to receive new builds
  • loop periodically to check if the ongoing builds are done
  • if there's build still in progress and the timeout is near, reset the timer
  • if there's no more builds in progress, signal to proceed to termination
Improve this answer
2

My concern is that when scaling down, the ASG may terminate instances that are in the middle of a build.

It the builds are running then one should prevent down scaling. When the build has been completed then one could down scale as the resources will not be required anymore.

Improve this answer
1
  • Can you elaborate on >one should prevent down scaling ? Are you suggesting that I should disable scaling while builds are running on any agents? This would result in quite a lot of idle agents at 4:00pm when only a few builds are running. What mechanism would I use to trigger the disabling of scaling? Also, GoCD agents run one build per VM with a fairly long spin up time, so I prefer to have at least a small buffer of idle instances.
    – user2640621
    Commented Oct 29, 2017 at 22:55
0

I think we have an answer here. Using GOCD API it can be managed. https://amaysim.engineering/auto-scaling-build-agents-for-gocdtags-a10f12d5b77c

Improve this answer
1
  • 2
    Welcome DevOps! Please note that link-only answers are considered very low quality (the links can go dead). Adding a short summary or a quote of the relevant info from the referenced content in the post itself is highly recommended.
    – Dan Cornilescu
    Commented May 28, 2018 at 14:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.