Skip to content

Blog

How We Build Concourse

Building on some of our previous posts on the Concourse team mechanics1, I wanted to spend some time going over how we actually build Concourse.

Distributed Garbage Collection

Before diving into the weeds of Concourse architecture, let’s briefly take a look at container and volume lifecycles in Concourse. Going forward in this post I will refer to container and volume together as a “worker resource”. In the current architecture, there are multiple ways for worker resource creation to be triggered; like when jobs are started in pipelines or checking for a newer version of a resource. The ATC is responsible for managing worker resource lifecycle like creating, transitioning and destroying them. Workers are designed to be dumb and follow the orders issued by ATC. Removal of worker resource on worker and its reference (in ATC) is done as part of Garbage collection (GC) process in ATC.

My first month on Concourse

I have been working as Software Engineer with Pivotal for about 3 years now, during which much of my contributions were primarily within Cloud Foundry teams, such as MySQL service, Routing, and UAA. Early this year I rotated onto Concourse team in Toronto and I would like to share my thoughts on why Concourse team does things differently and why they work.

Oh, Auth

As most of you know we’ve been working hard on introducing Users into Concourse. Today, I’m excited to share with you some of the changes we’ve made for an upcoming release of Concourse.