Secondary server URLs and other challenges

Answered

Hi there,

So I'm currently working out how we're going to deploy TeamCity in Kubernetes.

I've got to the point whereby I can stand up a primary and `n` number of secondaries, and things seem to be working using a NFS shared data-dir.

However the challenge I've just spotted is around this comment in the docs:

<node url> is the secondary node root URL. Make sure this URL is accessible from the main server and agents.

So does that mean that if I have 3 secondary servers, then I need to have a public URL for each of those servers that differs from the primary server URL?

Also, we want to add Elastic APM monitoring to all of our TeamCity server instances. This worked fine on the primary server, however the secondary servers are throwing errors such as: 
2020-11-25 12:10:14,760 [elastic-apm-server-reporter] ERROR co.elastic.apm.agent.report.IntakeV2ReportingEventHandler - Failed to handle event of type TRANSACTION with this error: Connection to "97009f384c2848f88c6aabb8bf83ce35.apm.us-central1.gcp.cloud.es.io" is prohibited by TeamCity node restrictions

Which looks pretty similar to https://youtrack.jetbrains.com/issue/TW-65810. Are there any workarounds for that?

Thanks in advance.
Gavin

1 comment
Comment actions Permalink

Hi Gavin,

 

While we are discussing some of your questions internally, and as far as I am aware there are some other issues as well with your organization that will be discussed privately, I'll try to provide a quick piece of feedback on the questions here:

-Public URLs: It is not strictly mandatory but it is going to be very likely required, yes. Secondary nodes can offer the UI to users, and can receive connections from agents, depending on their responsibilities. For those instances, the URLs will need to be public, not just to be used by the users/agents but also internally to be able to serve the responses. To be clear, this does not need to be a fully public URL, but as the message implies, it needs to be accessible from the main server at the very least, and from the agents if the server is going to hold agent-related responsibilities.

Additionally, we are reworking the way agents connect to the servers to better support a full HA system. This effort is being tracked here: TW-66859 . At the same time, we are working on providing our own approach to HA via an included reverse proxy, which will mask all the different nodes under the same URL, so that would also probably remove this need.

 

-With regards to monitoring, it was already answered in the ticket, indeed there is no current way to allow for incoming connections to secondary nodes. We are discussing possible approaches and solutions but this is still on the early stages so there is not really much information we can share about it.

 

Hope this helps.

0

Please sign in to leave a comment.