Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.
If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!
Deploying a Docker Image via Kubernetes with a yaml file
-
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.
-
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.yamlAdditional 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
-
Thank you for that information. I've yet to fully learn all the technology used in our lifecycle but that is what I'm trying to do more of with this project (in addition to a proposal). You've been me a little extra insight I haven't gotten internally yet. We do use Argo CD. I've actually used it to the see the status of Kubernetes but I didn't realize it talked directly to git. Being that I can't afford my own license for Argo CD and it isn't free I'll focus on seeing if I can come up with a plan to manage updating the yaml files and git with BuildMaster.
As far as my original post I think you have helped me post a more succinct question. Once I get my yaml file updating in a specific directory would I use the Kubernetes plugin to have it run the command to reload the yaml or would I need to do my own manual powershell call to do that?
-
Argo CD is free / open source and no license is required. You'd be better off learning that than trying to do Kubernetes another way. FYI there's also Kargo, which is a "wrapper" that sits on top of ArgoCD and has some kind of promotion workflow outside of typical GitOps (pull requests I guess?).
To be honest, I really don't know if the Kubernetes extension even works; it was originally intended for Otter, to create a "Desired state" and offer an alternative to Git-based approaches. But there's just no demand and GitOps is just the Kubeernetes standard. We haven't tested it in years.
We do not plan on migrating it to the next SDK version. It's just a light wrapper around
kubectrl, which has probably changed over the years. If you really wanna mess with Kubernetes outside of Argo CD I would just runkubectrl apply/replacedirectly.Good luck!!
