TeamCity integration with cloud (IAAS) solutions allows TeamCity to provision virtual machines running TeamCity agents on-demand based on the build queue state.
This page covers general information about the configuration of integration. For the list of currently supported solutions, refer to Available Integrations.
On this page:
In a large TeamCity setup with many projects, it can be difficult to predict the load on build agents, and the number of agents we need to be running. With the cloud agent integration configured, TeamCity will leverage clouds elasticity to provision additional build agents on-demand.
For each queued build TeamCity first tries to start it on one of the regular, non-cloud agents. If there are no usual agents available, TeamCity finds a matching cloud image with a compatible agent and starts a new instance for the image. TeamCity ensures that number of running cloud instances limit is not exceeded.
The integration requires:
Once a cloud profile is configured in TeamCity with one or several images, TeamCity does a test start of one instance for all the newly added images to learn about the agents configured on them. When the agents are connected, TeamCity stores their parameters to be able to correctly process build configurations-to-agents compatibility. An agent connected from a cloud instance started by TeamCity is automatically authorized, provided there are available agent licenses: the number of cloud agents is limited by the total number of agent licenses you have in TeamCity. After that the agent is processed as a regular agent.
Depending on the profile settings, when TeamCity realizes it needs more agents, it can either
The disconnected agent will be removed from the authorized agents list and deleted from the system to free up TeamCity build agent licenses.
Integration with cloud solutions is implemented as plugins. The platform-specific details are covered on the following pages:
For integration with other cloud solutions, see Implementing Cloud support.
This section describes general steps required for cloud integration.
The requirements for a virtual machine/image to be used for TeamCity cloud integration:
buildAgent.propertiesfile can be left "as is". The
authorizationTokenproperties can be left empty or set to any value, they are ignored when TeamCity starts the instance unless otherwise specifically stated in the platform-specific documentation.
Provided these requirements are met, the usual TeamCity agent installation and cloud-provider image bundling procedures are applicable.
If you need the connection between the server and the agent machine to be secure, you will need to set up the agent machine to establish a secure tunnel (e.g. VPN) to the server on boot so that the TeamCity agent receives data via the secure channel. Please keep in mind that communication between TeamCity agent and server is bi-directional and requires an open port on the agent as well as on the server.
buildAgent.propertiesfile — this is optional if TeamCity will be configured to launch the image, but it is useful to test the agent is configured correctly.
conf/buildAgent.propertiesto use a non-system drive (e.g.
Ddrive under Windows)
If you want TeamCity to start an existing virtual machine and stop it after the build is finished or an idle timeout elapses, the setup above is all you need. If you want to TeamCity to create and start virtual machines from an image and terminate the machine after use, the image should be captured from the virtual machine that was created.
Do the following:
tempdirectories in the agent home
<Agent Home>/conf/directory from platform-specific files
buildAgent.propertiesfile to remove the
authorizationTokenproperties unless otherwise specifically stated in the platform-specific documentation.
TeamCity agent auto-upgrades whenever distribution of agent (e.g. after TeamCity upgrade) or agent plugins on the server changes. If you want to reduce the agent startup time, you might want to capture a new virtual machine image after the agent distribution or plugins have been updated.
Agent Cloud Profiles are configured in the Server Administration UI, on the Administration | Agent Cloud.
The cloud provider pricing applies. Please note that the charges can depend on the specific configuration implemented to deploy TeamCity. We advise you to check your configuration and the cloud account data regularly in order to discover and prevent unexpected charges as early as possible.
Please note that traffic volumes and necessary server and agent machines characteristics depend a big deal on the TeamCity setup and nature of the builds run.
Here are some points to help you estimate TeamCity-related traffic:
If the TeamCity server is not located within the same region or affinity group as the agent, the traffic between the server and agent is subject to usual external traffic charges imposed by your provider.
When estimating traffic, please remember that there are many types of traffic related to TeamCity (see the non-complete list below).
External connections originated by server:
Internal connections originated by server:
External connections originated by agent:
Internal connections originated by agent:
Usual connections used by the server
Cloud providers calculate costs based on the virtual machine uptime, so it is recommended to adjust the timeout setting according to your usual builds length. This reduces the amount of time a virtual machine is running.
It is also highly recommended to set an execution timeout for all your builds so that a build hanging does not cause prolonged instance running with no payload.