Starting from this EAP, configuration of issue trackers, versioned settings, custom charts, shared resources and third-party report tabs was moved from
<TeamCity Data Directory>/config/projects/<ProjectID>/pluginData/plugin-settings.xml to
<TeamCity Data Directory>/config/projects/<ProjectID>/project-config.xml file. The file now has the
<project-extensions> element which contains all of the above-mentioned project features.
Starting with this EAP, the TeamCity server can operate in two modes: main TeamCity server (default mode) , and build messages processor.
If a TeamCity server is started in the build messages processor mode, its functionality is reduced to only one feature - process real time data coming from the running builds.The The primary purpose of this mode is to provide the scalability option for really large installations , running several hundreds of agents on a single server now and planning on expanding their installation in the future.
When two servers working in different modes are connected, they appear as two nodes on the server Administration | Nodes Configuration page.
Several important notes about two-node configuration:
- at the moment the build messages processor node handles all of the data produced by running builds (build logs, artifacts, statistic values), pre-processes it and stores it in the database
- in a two-node installation, both the main TeamCity server and the build messages processor require access to the same data directory (which should must be shared somehow if the nodes are installed on separate machines) and to the same database
- the URL where the build messages processor operates should must be accessible by the agents and the main TeamCity server (occasionally the main TeamCity server also communicates with the build messages processor by HTTP)
- the main TeamCity server handles all other tasks: user interface, VCS related activity, management of agents, etc.
First of all, ensure that both machines where TeamCity software will be installed share the same TeamCity data directory. For large installations we recommend using NAS. It is possible to share directory using NFS, or windows Windows share, although the performance of such installation can be worse.
Once you have two machines, proceed with installing TeamCity software as usual: download a distribution package, unpack it or follow the installation wizard.
TEAMCITY_DATA_PATH environment variable on both machines, make sure it points to the shared data directory.
To start the main TeamCity server, follow our usual instructions.
Before starting a server in the build messages processor node, add additional arguments to TEAMCITY_SERVER_OPTS environment variable, for example:
TEAMCITY_SERVER_OPTS=-Dteamcity.server.mode=build-messages-processor -Dteamcity.server.rootURL=<processor url> <your regular options if you have them>
Where <processor Where
<processor url> is the URL where build messages processor will operate. This URL should must be accessible by both the agents and main server. If you do not have an HTTP proxy installed in front of TeamCity the eamCity servlet container and you did not change the port in the servlet container during the installation, then by default this URL will be:
http://<your host name>:8111/
To start the build messages processor, use our regular scripts:
Build The build messages processor uses the same approach to logging as the main server. You can check how the startup is going doing in the
teamcity-server.log file. You can also open
<processor URL> in your browser, there you should see regular TeamCity startup screens.
Build Messages Processor
If both - the main server and build messages processor are up and running, you should see the "Nodes configuration" page in the Administration area on the main TeamCity server:
By default, the build messages processor is disabled. And all traffic produced by running builds is still handled by the main server. Once you enable the build messages processor, all newly started builds will be routed to this node. Existing The existing running builds will continue their execution being executed on the main server.
And vice versa, if you decide to disable the messages processor, only the newly started builds will be switched to the main server, the builds that were already running on the messages processor will continue running there.
At any point of time you can see how many builds are currently assigned to each node. If everything is configured correctly (the node is accessible by agents) and there are no problems with processing builds on the messages node, eventually all of the running builds should be switched to the processor node once you enable it.
Build The build messages processor as well as the main TeamCity server can be stopped or restarted while builds are running there. If agents can't connect to the build messages processor for some time, they will re-route their data to the main server. If the main server is also unavailable, agents will keep their data and re-send it once servers re-appear.
Upgrade sequence should be the Both the main TeamCity server and the build messages processor must be of exactly the same version.
The upgrade sequence is the following:
- start upgrade on the main TeamCity server as usual
- at some point you will be warned that there is a build messages processor running and using the same database; you'll need to shutdown it first
- proceed with upgrade
- make sure everything is ok, agents are connecting etc. (since messages the messages processor is not available anymore, the agents will re-route date their data to the main server)
- upgrade software on the messages processor machine to the same version
- start messages processor and check that it is connected via Nodes configuration page on the main server
- Only one build messages processor can be configured for the main TeamCity server.
- At the moment the build messages processor node does not support plugins.
Team Foundation Work Items Tracking