I have been using TeamCity for a few years now, primarily as a build tool for some of our platforms at work. However, because I like to have a sandbox in which to play, I have been hosting an instance of TeamCity at home for roughly the same amount of time.
At first, I went with a basic install on a local VM and put the database on my SQL Server, and spun up another VM (a GUI Windows Server instance) which acted as my build agent. I installed a full-blown copy of Visual Studio Community on the build agent, which provided me the ability to pretty much run any build I wanted.
As some of my work research turned me towards containers, I realized that this setup is probably a little to heavy, and running some of my support systems (TeamCity, Unifi, etc) in docker makes them much easier to manage and update.
I started small, with a Linux (Ubuntu) docker server running the Unifi Controller software and the TeamCity server containers. Then this blog, which is hosted on the same docker server. And then, as quickly as I had started, I quit containerizing. I left the VM with the build agent running, and it worked.
Then I got some updated hardware, specifically a new hypervisor. I was trying to consolidate VMs onto the new hypervisor, and for one reason or another, the build VM did not want to move nicely. Whether the image was corrupt or what, I don’t know, but it was stuck. So I took the opportunity to jump into Docker on Windows (or Windows Containers, or whatever you want to call it).
I was able to take the base docker image that JetBrains provides and add the MSBuild tools to it. That gave me an image that I could use to run as a TeamCity Build agent. You can see my Dockerfile and docker-compose.yml files in my infrastructure repository.