If I understand correctly, these additions add the ability to launch Concourse workers within proper Windows containers?
Yeah, this only enables Houdini-based Windows Workers (the default used by
concourse.exe worker on Windows). For that reason, I omitted many of the environment variables that didn’t appear necessary (baggageclaim, etc) and pretty much just added the worker key management. Conveniently, the bind mounts for those keys just works thanks to k8s.
Or is this actually adding a new backend within Concourse proper for Windows containers??
I wish it was proper nested containers! This just puts the worker in a container - which is still a big advantage over running the worker via a bosh-based job running on a bare VM, since you can use any container image you want, so long as you put
concourse.exe in there. All tasks will still omit an
image-resource and to customize the image, you’d have to redeploy your worker.
I am formerly of the Garden Windows team though . This greenhouse-org is just our fork org for OSS contributions. And I used AKS in the deployment scripts since at the moment, it’s the easiest public IaaS to test with but definitely we’ll be trying this out against PKS and other k8s with Windows offerings.