Deploying a Docker Image via Kubernetes with a yaml file

[brandon_owensby_2976]

I'm trying to get a deployment going using Docker and Kubernetes. I have very little experience with those 2 technologies and even less when doing so with BuildMaster. So far I have successfully created an image and posted it to the image store in Pro Get. I've also got a yaml file which loads the image via Kubernetes. My next step is to have a build step that does that for me instead of having to update the yaml file manually. I have the Kubernetes extension installed but I only see 2 commands and I haven't been able to find documentation even with the ? icon on one of the commands. I was hoping someone could help me connect the dots. I'm assuming it might involve a step of me updating the yaml file from a script before running the Kubernetes command but I'm not sure.

[atripp]

Hi @brandon_owensby_2976,

I'm afraid we don't have a lot of great documentation / information on how to deploy Kubernetes using BuildMaster. The existing extension is quite old and reflects a pre-Helm approach where Kubernetes resources were deployed directly via raw manifests.

These days, Helm charts are the standard way to package Kubernetes applications. A chart contains templated manifests along with default configuration (values.yaml) that can be overridden per environment.

Once you have a chart, you typically deploy it with a command like:

helm upgrade --install myapp corp/app -f values.yaml

Additional overrides (like your override.yaml) can be layered in as needed. In theory, that's where a BuildMaster configuration file would come in, and BuildMaster would also run the upgrade commands.

However... Helm isn't really run outside of development environments. Instead, most teams use a GitOps-based tool (i.e. Argo CD or Flux), which in turn use Helm to continuously "sync" whatever's in Git with what's running in the cluster.

The idea is that the "deployment state" is maintained in Git and doesn't need to be triggered from an external release system. In other words, a production "deployment" is done by issuing a commit.

Because of this, pipeline-driven deployment tools BuildMaster just popular for Kubernetes workflows. We've seen competitive tools try, but they get a lot of pushback from the end-users (i.e. Kubernetes engineers) and as a result don't see much adoption.

In my opinion, this is like 7 layers of unnecessary complexity (let alone error-prone) and a basic Docker deployment covers like 99% of use cases... but that's not where the market is.

Hope that helps clarify things a bit, let us know what you find.

Cheers,

Alana