How to automatically authorize an agent

Hi,

We have TeamCity setup in the amazon cloud using RightScale.
We need to be able to authorize the agents as soon as they are operational without using the TeamCity feature for agents in the cloud.

Is there a way to do that via the rest api, possibly, or maybe something else?

thanks,

Isel

11 comments
Comment actions Permalink

Hello,

I checked a possibility to use RestAPI for that. Unfortunately, RestAPI does not provide such functionality.

The only way to do this is to write server-side plugin.

There are two possible ways to do it:
- simple way is to subscribe to server events and listen to BuildServerListener#agentRegistered method (Use jetbrains.buildServer.util.EventDispatcher<BuildServerListener>#addListener and extend BuildServerAdapter). In that event check if agent is matcing the rules and call SBuildAgent#setAuthorized method.
- another way is to implement new could provider for TeamCity. This would allow TeamCity to start/stop agents with respect to server load.

Please let me know if you like to get more information on any of those scenarios.

0
Comment actions Permalink

Eugene,

Thank you so much for your response. A provider to TeamCity to start/stop agents with respect to server load would be awesome, because we have them in the Cloud but not using AWS directly, but RightScale.
If you could send me more information on how to get started I would really appreciate it, it would solve authorizing and starting agents with just one solution.

Thank you!

Isel

0
Comment actions Permalink

Hello,

Could you please take a look to
http://confluence.jetbrains.net/display/TW/Implementing+Cloud+support

We have an opensource example of another cloud plugin for TeamCity
http://confluence.jetbrains.net/display/TW/Cloud-VMWare+plugin

Hope this would help to begin. Feel free to ask me more questions on that

0
Comment actions Permalink

thank you so much! will look at them and let you know when we get it working

Isel

0
Comment actions Permalink

Isel,

Can you please explain why you cannot/do not want to use TeamCity's cloud agent integration?

If it is possible, can you please describe what benefits RightScale provides for TeamCity deplyment comparing to "raw" EC2 use?

The reason for the questions are that we would want to know more on TeamCity usages as it can provide ground for future features or improvements in TeamCity.

0
Comment actions Permalink

Yegor,

RightScale (www.rightscale.com) lets us configure instances on the fly on top of the AMI. That said, they have scripts you can run when the instance boots so we don't have to modify the AMI manually everytime. That was the major selling point for us to use it, but they have a lot more stuff than that.
Also, for TeamCity, we have all instances (server, db and agents) grouped in what they call a "Deployment", that way we know exactly how many we have there and how much money they cost us.
And they are also multi-cloud, which is very convinient for us, since we will have to deal with that in the near future.
Moreover, they have a very good REST api, which we are using.

We are very happy with them since all these features are helping us a lot to manage the instances in the cloud more effectively.

If you would like to provide that feature in the future it would be great and then we will wait for it.

Cheers,

Isel

0
Comment actions Permalink

Isel,

Thank you for the description.

Do you add agents dinamically somehow (so you need to authorize them)? Or is this a one-time task when you start the TeamCity server + agents "deployment" ?

If the set of agents is always the same, agents should be recognized by the server as "the same" (provided the agents have the same authToken's (stored in buildAgent.properties file)).

0
Comment actions Permalink

Yegor,

Thank you so much for helping us.

Nope... right now we have a static set of agents in the Deployment that we have to start/stop manually based on demand. Everytime we need to terminate one of them, and launch it again (will get a new IP, because it is AWS), we then need to reauthorize it, which is really painful.
Ideally, when we need a new agent, we would look for stopped ones that match the requirements and start them, if there are none available, we will have to create a new "Server" in the Deployment based on the agent type, and launch it. When demand decreases we could stop the agent.
"same agents", i still dont have clear how to define that. It could be a name prefix in the deployment. They will share definetely the same "Server Template", which is what contains the scripts we run at boot time.

Quick question, is the authToken's (stored in buildAgent.properties file) the same for all agents? Can we set it at boot time so at least when they boot, they are already authorized?

Also, attached is a screenshot of our TeamCity deployment in RightScale.

Cheers,

Isel



Attachment(s):
TC deployment.png
0
Comment actions Permalink

TeamCity server generates unique auth token for every new build agent. TeamCity server updates token If there is an angent with non-unique auth tocken. This token is used to associate build agent with TeamCity server build agent's record. There is no way (now) to make TeamCity server know about some generated auth tokens before agent is registered.

TeamCity could subsystem solved agent authrization and naming tasks for you. As build agent is registered, TeamCity call's cloud plugin to generate a name for agent. As TeamCity agent is ready to work TeamCity will call cloud plugin to check if this agent matches to some running cloud instance. If matching is found, build agent is authrized and builds will start.
As build agent no longer needed, TeamCity will call plugin to stop an instance. As agent is unregistered, TeamCity will remove build agent and free ocupied agent license.

TeamCity cloud support monitors build queue to detect a possibility to start new build agent to make more builds running in a time (with respect to cloud profile constraints). To start new build agent TeamCity calls cloud plugin to run new instance.

TeamCity build agent contains embedded EC2 plugin that reports EC2 instance metadata as build agent properties. You may use those properties to make authorisation decisions on the server. You may find all build agent parameters through SBuildAgent insterface on server.

Hope, this made thing more clear. If not, please feed free to ask more.  

0
Comment actions Permalink

I have a similar use case to what's being discussed in this thread, automatic authorization of servers.

In my case, I'm not dynamically scaling (so writing a cloud plugin doesn't make sense) but I am running servers on a non-persistent filesystem.  So when I restart an agent (say due to hung build or whatever) the filesystem resets and the authenticationToken is forgotten.

It is possible to allocate persistent storage just for the configuration file but that is a surprising amount of work just to avoid clicking an "authorize" button.  If I was able to hardcode an authorizationToken in my image and use that from several agents that would be of great help.

0
Comment actions Permalink

It is not just about the amount of work to avoid clicking on an "authorize" button. The concept is bewildering from a standpoint of CICD and automation. Why do I have to do some meaningless action where I'm not providing any information to the system? In the spirit of automation, why is the tool I'm using to build my pipelines making me do a manual step in between the whole process? My agents should scale up and down automatically with the demand for builds, why would anyone stop this auto-scaling process to ask a human if the scaling was intentional? I like JetBrains, I love their IDEs but this is just one-of-those insufferable process designs.

4

Please sign in to leave a comment.