1

I'm setting up a TeamCity cluster, with an SVN server, in EC2, and want to user TeamCity's 'cloud' functionality to have it spin up new agents when needed.

My primary concern at this point is making sure that all communications between the three types of machines (TC Server, TC Agent(s), and SVN) user internal EC2 IP addresses to make the data transfers free (see the EC2 Pricing page, Availability Zone Data Transfer).

This is easy for the SVN server, I can put it's private IP address in to TeamCity Server configuration. However, for the TeamCity server URL, I believe I need to enter the external IP address so that users can access the server. The same IP address is sent to the newly spun agents so that they know where to talk to.

Therefore, communication from agents to server will be over the external IP, thus incurring data transfer costs. How do I avoid this?

EDIT

I ran 'dig' on one of my agents, giving it hte elastic IP address of the TC Server, and got this (note I obfuscated the external IP slightly). No internal IP address is in there.

[ec2-user@ip-10-166-9-94 ~]$ dig 54.243.x.y

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.25.amzn1 <<>> 54.243.x.y
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 60896
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;54.243.x.y.            IN  A

;; AUTHORITY SECTION:
.           10800   IN  SOA a.root-servers.net. nstld.verisign-grs.com. 2012111500 1800 900 604800 86400

;; Query time: 38 msec
;; SERVER: 172.16.0.23#53(172.16.0.23)
;; WHEN: Thu Nov 15 18:10:09 2012
;; MSG SIZE  rcvd: 106
sharakan
  • 115
  • 5
  • Can you use a domain name instead of an IP? AWS instance DNS names will resolve to internal/external IPs correctly depending on whether or not you're in the AWS network. – ceejayoz Nov 06 '12 at 15:15
  • Not on the server itself, although I do on the apache instance fronting it. Seems like not a good idea though to route all the agent-server traffic through Apache though. – sharakan Nov 06 '12 at 15:18
  • I take it your suggestion would involve using Route 53 to make a new domain (or subdomain in our case), and assign that subdomain to the TC server. Then make serverURL point to that subdomain. And then when the agents call http://teamcity.mydomain.com/teamcity EC2 would map that domain to internal IPs? – sharakan Nov 06 '12 at 15:21

1 Answers1

2

You don't need to setup a domain/DNS. If you assign Elastic IPs, you can use the Elastic IP Public DNS name, and it will resolve to the external IP if you query it externally, and resolve to the internal address if you query it from other EC2 instances.

So if I've got an Elastic IP of 54.254.54.54, the public hostname is ec2-54-254-54-54.us-west-2.compute.amazonaws.com. This will resolve to the internal IP if you query it internally.

You can CNAME your own hostname (foo.domain.com) to it, and it will function the same way.

Jason Floyd
  • 1,792
  • 1
  • 13
  • 18
  • OK, that would definitely resolve my problem. Is there anyway that I can confirm this is the case, perhaps with a command I can run from the shell or a chunk of code I can run? – sharakan Nov 07 '12 at 13:56
  • Sure, run a "dig yourpublichostnamehere" from an external host and compare the resulting IP to what you get running the same command from the ec2 instance. – Jason Floyd Nov 10 '12 at 05:31
  • Doesn't look like the external IP does resolve down. The result of running dig on a TC agent using the TC server external address doesn't refer to the internal EC2 IP address at all. – sharakan Nov 12 '12 at 20:05
  • When you say "TC server external address" are you using the IP or the DNS Name? Is your DNS name CNAME'd to the Elastic IP hostname or an A record pointing at the IP address? – Jason Floyd Nov 14 '12 at 06:12
  • In the dig query, I was using it's Elastic IP ip address, eg 54.243.x.y – sharakan Nov 15 '12 at 18:00
  • I've added the results of running dig to the question – sharakan Nov 15 '12 at 18:11
  • dig the hostname of the elastic IP instead, as it'll resolve differently. So instead of a 'dig 54.243.x.y' do (assuming you're in us-west-2) a 'dig ec2-54-243-x-y.us-west-2.compute.amazonaws.com'. this should resolve with either the elastic IP if you're outside the region or the Internal IP if you're on AWS. – Jason Floyd Nov 17 '12 at 07:18