How to automatically authorize an agent

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.

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

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

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

Isel

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.

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

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)).

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

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.  

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.

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 value to the system? In the spirit of automation, why is the tool I'm using to build my pipelines making me take a manual step somewhere inside 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.

Bump in 2024. We need to authorize new agents that are really containers being spun up by a build triggering.

Hi Nathan Pierce, and welcome to the forums. 

The best option for containers spun up by build triggering is a Kubernetes Cloud profile. There are also third-party plugins for using Docker (without Kubernetes) as an agent cloud. Cloud profiles allow TeamCity to spin up agents upon starting builds, authorize them automatically, and take them down after the build finishes.

Alternatively, you should be able to authorize an agent via REST API using a POST request to a URL like /app/rest/agents/id:<agent_id>/authorizedInfo. Related documentation: https://www.jetbrains.com/help/teamcity/rest/authorizedinfo.html
 

Hey Anatoly Cherenkov , we use Cloud profiles for our custom plugin to spin up macOS VMs. It doesn't seem to be the case that they are automatically authorized. Is there some documentation you can point me to that could help diagnose why this isn't the case?

Nathan Pierce, that is either a misconfiguration or a bug. Which TeamCity version is this? What is the cloud profile type?

Any way to communicate outside of this thread? Maybe a slack channel or email?

Regardless:

TeamCity Professional 2024.07.2 (build 160695)
The plugin is https://github.com/veertuinc/teamcity-anka-cloud/tree/release/v1.9.0 and it's a type of “Anka Build Cloud”. This plugin is very old and I recently started working on updating it for our customers. 

It's likely it's doing things the old way, but I don't see any documentation or examples for what I should be doing for a modern Cloud Profile. I found https://www.jetbrains.com/help/teamcity/teamcity-integration-with-cloud-solutions.html#Available+Integrations but the link for “see Implementing Cloud support.” points to a private confluence that I do not have access to. 

Thank you soooo much.

The plugin might need adjustments. Please raise a support request (CONTACT SUPPORT button at the top of this page).

For anyone interested, I finally figured it out: The trick for Cloud Profile plugins/agents is to add "teamcity.agent.startingInstanceId" to the buildAgent.properties on your VM. You can get it from CloudInstanceUserData.

Teamcity will update their docs to make this clear and it was not documented.