Easy TeamCity Continuous Integration Installation with Docker
Join the DZone community and get the full member experience.Join For Free
teamcity from jetbrains is an easy-to-use and powerful continuous integration system. it is a commercial product, but there is a special zero-cost license for small projects and foss applications. while installing teamcity is relatively easy, its setup is further simplified via the use of docker .
like many other state-of-art continuous integration systems, teamcity adopts the concept of build server and build agent. the server is responsible for the adminstration and build configurations. the actual build itself (compilation, packaging, deployment, etc) is carried out by one or more build agents. with this approach, it is also easy to provision the agent automatically so that the entire setup requires very little manual tweaks.
teamcity server only requires java. the installation is rather straightforward. with docker, this is even easier. i have prepared a special container for this, ariya/centos6-teamcity-server . the base system for the container is ariya/centos6-oracle-jre7 , a centos 6.5 system running the official oracle java 7 (to be more precise, jre 1.7.0_65-b17 at the time of this writing).
assuming you have a system (vps such as linode or digitalocean, amazon ec2 instance, a virtual machine, a real box) that already has docker installed, setting up a teamcity server is as easy as running the following commands. note that if you are on os x, use boot2docker if you just want to experiment with this setup (see my previous blog post docker on os x for more details).
docker run -dt -name teamcity_server -p 8111:8111 ariya/centos6-teamcity-server
give it a few minutes or so, now open the box’s address at port 8111
to start the web configuration of teamcity server (read the official
for more details), as shown in the following screenshot. if your host
system is using iptables, make sure to accept connections on port 8111.
note that teamcity data will be stored in the special location
. this is a standard
, it is useful to allow easy mounting, back-up, or future upgrade.
once the server is configured, it is time assign a build agent to this server (otherwise, nothing can be built). again, we will spawn a build agent easily using docker by running the container named ariya/centos6-teamcity-agent . for the agent to work, we need to specify the server. here is how you would run it:
docker run -e teamcity_server=http://buildserver:8111 \ -dt -p 9090:9090 ariya/centos6-teamcity-agent
if you run this in the same host which is running the server container, you need to link them together:
docker run -e teamcity_server=http://teamcity_server:8111 \ --link teamcity_server:teamcity_server -dt ariya/centos6-teamcity-agent
the environment variable
it needs to point to the location of the instance of teamcity server you
started in the previous step. once you run the container, it will
contact the specified server, download the agent
and set it up. wait a few minutes since the build agent usually updates
itself after the first contact to the server. if everything works
correctly, you should see a new agent appearing on the
tab on your teamcity server web interface. authorize the agent and now it should be ready to take any build job!
if there is a problem launching the agent (
) does not show the container running, try to run it again but this time with the option
(interactive terminal) instead of
. this will dump some additional debugging message which can be helpful to assist troubleshooting.
note that this agent container is also based on centos 6 with java 7. usually this is not enough as you may need other dependencies (different sdks, compilers, libraries, etc). ideally those dependencies should be resolved automatically, either by basing the container on a different system or by setting up the right automatic provisiniong. refer to my previous blog post build agent: template vs provisioning for a more detailed overview.
still have an excuse not to do continuous integration? i don’t think so!
Published at DZone with permission of Ariya Hidayat, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Demystifying SPF Record Limitations
Scaling Site Reliability Engineering (SRE) Teams the Right Way
What Is Istio Service Mesh?
Microservices: Quarkus vs Spring Boot