How does Octopus handle new tentacles registering to environments and roles?
I’m planning on dynamically installing tentacles when I spin up new servers. Ideally this will be in an autoscaling situation, so I am hoping that when a tentacle registers it then automatically pulls down and installs the latest version of apps. If this does not already happen, is it possible to make it happen?
Hi James,
This doesn’t automatically happen at the moment, though it’s a feature that we could potentially add since we have all the data needed to model it. For now the easiest way to do it would be to add a new environment, add your batch of auto-scaled machines to that environment, and then deploy an existing release to that environment.
Paul
Hi Paul,
It would be great is this could be a feature. I take it the way you are suggesting would require some form of manual intervention, or there command line tools that could do all of it?
James
Hi James,
You could do it using the Tentacle automatic registration feature along with Octo.exe to push the deployment out. Both of these features work over the Octopus HTTP API if you wanted to build it into your own auto-scaling solution.
Paul
Hi Paul,
I’ll give this a go and see how I get on. As mentioned earlier, it would be great if this was a feature of Octopus.
James
Hi James.
Did you manage to make your deploy work under an autoscaling scenario? I wonder if you would share how you did it?
Thanks in advance.
Hi Michael,
In the end I didn’t get round to making it work. When I was digging around I realised it wouldn’t be an appropriate solution to create a new environment.
As far as I know, there are two main features missing that mean Octopus Deploy doesn’t work well with AWS auto scaling groups. Firstly, the problem outlined here that servers should automatically have their applications installed when they register themselves with appropriate roles, this for me is a must. Secondly, I want the ability to deploy to say half a set of servers in a role and then the other half. The scenario here is so that servers don’t drop out the load balancer because the site is warming up. Right now I have to have two separate roles and two steps to achieve this. I don’t want to randomly be deciding on the auto created server which role to assign. Add to that, AWS scaling groups will randomly decide which server to destroy when it decides to scale down meaning that I could have all my servers in one role, not distributed across both.
The lack of these two features means that when I revisit scaling very soon, I might have to look for other solutions to this problem.
Sorry I couldn’t help more
James
Hi James. Thanks for the reply.
The strategy I’m planning to follow is to make new servers register themselves at startup and force a redeploy to their environments/roles using octo.exe. Since Octopus won’t deploy again to servers that already have the latest version of the application, I think it would work.
There’s one thing I believe will happen and I don’t know how to solve yet: as AWS auto scaling system creates and drops machines, the Octopus dashboard will become a mess. It would be nice if tentacle.exe had an unregister command that I could use at server shutdown.
All in all, I agree with you that it would be really, really great if Octopus had a built-in solution to autoscaling scenarios. I’m looking forward to seeing what version 2.0 will do about it.
Regards.
Just in case anyone else needs it, I’ve published the bootstrap script I’m using to automatically register a new Tentacle with Octopus and deploy a release to it. Here it is: https://gist.github.com/mbenford/5658613
Regards.
Thanks Michael, very useful!