make container builders pluggable

[bacongobbler]

in #691 we introduced a new container builder integration for ACR Build. It would be great to split this out into a plugin or driver architecture:

1. so core remains less reliant on azure-specific libraries
2. we set an example for how other container builders (GCB, img, buildah) can integrate with Draft

UX to be determined/sussed out

[squillace]

I'm ad interested in local builds like img as I am with services. I'm also interested in getting a builder service in k8s, what you'd that take? For others, I mean. If they did it, what api should teeny expose to be plugged in and so on.

[bacongobbler]

We haven't worked out the integration points yet; just posting this up here as something we'd like to see in the future. Once we break out the acrbuild integration into a plugin, we should have a better idea what's needed to add new container image builders.

[squillace]

I'm all ears.

[AkihiroSuda]

https://github.com/Azure/draft/issues/773#issuecomment-395829770

closing as a duplicate of #700 so we can track one ticket

@AkihiroSuda can CBI run builds locally as well? A pluggable interface sounds nice, but at the same time we have users (me) who wants to use their local container builders to do the build and push steps as their machines are vastly quicker for processing power than what's available in the cloud. That said I wouldn't be opposed to allowing someone to add support for CBI once we have the infra in place to support image builder drivers. Might be a good discussion point to carry on in #700.

Yes, but as CBI is designed as Kubernetes CRD & controller, it requires Kubernetes on local. (e.g. Minikube, Docker for Mac/Win)
My idea is to keep both existing non-kube builders and CBI.