Closed scottrobertson closed 3 years ago
One horrible hacky way would be to tag latest
too and just have that in the deployment.yaml
as the image, so when i run kubectl apply
it does not change which image is deployed.
@scottrobertson You're just in time with this question. We just released v0.2.0
and it supports such workflows.
You can set
manifests:
path: k8s
in your Remote Spec and when you push to the remote now, all kubernetes yaml files in k8s
directory of your git repo will be kubectl apply
-ed.
So, if you want to update a deployment, make the change, commit and push and gitkube will take care of building and setting the right image.
You can find more details about manifests
in the docs.
To update the existing gitkube installation to v0.2.0
:
kubectl -n kube-system set image deployment/gitkubed sshd=hasura/gitkubed:v0.2.0
kubectl -n kube-system set image deployment/gitkube-controller controller=hasura/gitkube-controller:v0.2.0
That looks awesome thanks! It will work really nicely for most of my projects 👍
However, for some projects it wont work (specifically open source projects that i do not want to push Kubernetes configs to). I will have to try and think of a way around this without having to copy the image every time i want to update things.
k8s conf is kept separate from code and you need to update the conf, right?
A kubectl apply
flag that can ignore certain fields (image
) would have been awesome.
@scottrobertson Another way to solve this issue is to make the controller watch all the deployments that it is responsible for and when the image
key changes (say from a kubectl apply
), it goes and patch the deployment with latest build tag.
Now, controller will need to track that latest build tag, which can be done by adding a new key to the Remote's status.
Hey
Just wondering what the best workflow is for when i need to update a deployment without wiping out the image? Right now i need to call:
Copy the whole
image
into into my deployment.yaml file, and then i can dokubectl apply
Basically my question is: is there a better way to handle all of this, and to make it play nice with gitkube?