Hacker News new | ask | show | jobs
by eicnix 3429 days ago
Openshift is essentially Kubernetes + Redhat Extensions + Redhat Support

I use Gitlab CI and helm[1] for deploying. The last step of the ci process checks out the helm chart which is just another git repo and executes a helm install/upgrade CHART-NAME. Making things accessible is done through kubernetes ingress with nginx[2](which includes getting let's encrypt automatically for all external endpoints) so when I want to deploy a new staging version of the app I can do helm install app --set host=my-stage.domain.com .

There still a few gotchas like the pods won't update when a configmap was changed which is important because I keep the container configuration maps as configmaps. A crude workarround for this is [3] which triggers a configuration reload of the application running inside the container.

This solution has no licensing cost unlike Openshift(Tectonic[4] is another enterprise Kubernetes distribution which is free for 10 nodes) and the cost are based on the amount of time to set this up. But after you got into helm and more complex kubernetes deployments it should be easy.

[1] https://github.com/kubernetes/helm

[2] https://github.com/jetstack/kube-lego

[3] https://github.com/jimmidyson/configmap-reload

[4] https://coreos.com/tectonic/

2 comments

OpenShift Origin is the open source project. There's no licensing costs unless you want Red Hat support.
Hi, nice, this is a lot similar to our initial approach. Glad to see that! To make this flow a bit more easier, we've created a tool [1] (apologies for the plug) that is on top of Helm. What it does, is taking a diff between a bunch of Chart references with values (the desired state) and what's currently in Kubernetes (the actual state), and perform a few create/updates/deletes. So for instance you don't have to add an explicit helm delete if you remove a component, instead just remove it from the desired state. In our day to day work we add and update tons of components through this system, only updating .yaml files, checking them into Git and have the CI/CD do all the work. Also our tool has a dry-run mode, which acts like a test stage for pull requests.

[1]: https://github.com/Eneco/landscaper

Hi rollulus,

thanks for the info. As far as I understand it you configure the state of the helm release + configured values in a file and apply it to a kube cluster. Depending on your cluster setup this is really helpful. Do you have a solution for triggering a rolling update of pods if a configmap has changed? In your examples I didn't see any configmaps.

Good point, eicnix. No, we don't have a solution for that, but hadn't the need so far either. Sorry.