4 ms·

I look upon this and despair. How are average folks supposed to trust and use these things? It feels like NPM all over again. I keep seeing these kinds of thing

I look upon this and despair. How are average folks supposed to trust and use these things? It feels like NPM all over again. I keep seeing these kinds of things across modern tech stacks/languages and wonder why some brainiac has not looked at this in a more general sense of a trusted supply chain and audit/update process approach to fix this or come up with some transformational approach that at a conceptual level can be applied across languages and tech stacks.

gotem 6y ago
What is NPM? Nuclear Protocol Magisty?
- jrockway 6y ago
  NPM is a popular node.js package manager and package repository. https://www.npmjs.com/ https://www.npmjs.com/
- classified 6y ago
  Super secret expert tip: The internet can also be used to find information.
jrockway 6y ago
I think that kube-prometheus specifically tries to do too much, turning the simple problem of running a few services into its own brand-new problem. It attacks the problem of "it's hard to write a manifest to run a docker container", which isn't that hard, and it replaces it with its own configuration language, integrations that don't exist upstream, etc. The general answer is to avoid helm charts that run more than one piece of software. If you want Prometheus, install Prometheus. If you want Grafana, install Grafana (and accept that you have twice as much work, because you are running twice as much software). Helm has a culture of bundling all components into one chart, which makes it easy to make a mess. You should reject this culture and install the components that you need, and accept that it's going to be extra effort -- running other people's software is hard! (My full-time job is running our company's open source project in the cloud for people that can't get it installed themselves. It is a multi-person full-time job. It is not yet trivial to run other people's software, even if you talk to those people all day and have commit access to the repository.) Here is a slightly off-topic rant. When I first started using Kubernetes, I installed the Prometheus Helm chart. It contains a config file that searches for objects in Kubernetes that have a "prometheus.io/scrape" annotation to control scraping. I didn't know that at the time, and searched in vain for a way to scrape multiple containers in the same pod. Everything on the Internet said that was impossible, and indeed... it is impossible with the random configuration that the Helm chart supplied. I wrote my own Prometheus configuration and got exactly what I wanted. The abstraction layer that showed up without any documentation in the Helm chart caused me infinite trouble, whereas if I had to write the scrape configurations from the start by myself, this would have never been a problem. I wouldn't have gotten started in 1 minute, but I would have understood the software I was responsible for operating. It's dangerous to explode random configuration and code into your Kubernetes cluster. Helm is a tool that explodes random configuration and code into your Kubernetes cluster. Tread carefully! To answer your original question, "How are average folks supposed to trust and use these things?", when I first came to the Kubernetes world I saw Helm and immediately thought "this doesn't seem like a very good idea to me", and haven't used it much. I suspect that most reasonable people will come to the same conclusion, but the allure of "get this tedious task done in 15 minutes" will snare a few more victims along the way.

gotem 6y ago

What is NPM? Nuclear Protocol Magisty?

jrockway 6y ago
NPM is a popular node.js package manager and package repository. https://www.npmjs.com/ https://www.npmjs.com/
classified 6y ago
Super secret expert tip: The internet can also be used to find information.

jrockway 6y ago

I think that kube-prometheus specifically tries to do too much, turning the simple problem of running a few services into its own brand-new problem. It attacks the problem of "it's hard to write a manifest to run a docker container", which isn't that hard, and it replaces it with its own configuration language, integrations that don't exist upstream, etc. The general answer is to avoid helm charts that run more than one piece of software. If you want Prometheus, install Prometheus. If you want Grafana, install Grafana (and accept that you have twice as much work, because you are running twice as much software). Helm has a culture of bundling all components into one chart, which makes it easy to make a mess. You should reject this culture and install the components that you need, and accept that it's going to be extra effort -- running other people's software is hard! (My full-time job is running our company's open source project in the cloud for people that can't get it installed themselves. It is a multi-person full-time job. It is not yet trivial to run other people's software, even if you talk to those people all day and have commit access to the repository.) Here is a slightly off-topic rant. When I first started using Kubernetes, I installed the Prometheus Helm chart. It contains a config file that searches for objects in Kubernetes that have a "prometheus.io/scrape" annotation to control scraping. I didn't know that at the time, and searched in vain for a way to scrape multiple containers in the same pod. Everything on the Internet said that was impossible, and indeed... it is impossible with the random configuration that the Helm chart supplied. I wrote my own Prometheus configuration and got exactly what I wanted. The abstraction layer that showed up without any documentation in the Helm chart caused me infinite trouble, whereas if I had to write the scrape configurations from the start by myself, this would have never been a problem. I wouldn't have gotten started in 1 minute, but I would have understood the software I was responsible for operating. It's dangerous to explode random configuration and code into your Kubernetes cluster. Helm is a tool that explodes random configuration and code into your Kubernetes cluster. Tread carefully! To answer your original question, "How are average folks supposed to trust and use these things?", when I first came to the Kubernetes world I saw Helm and immediately thought "this doesn't seem like a very good idea to me", and haven't used it much. I suspect that most reasonable people will come to the same conclusion, but the allure of "get this tedious task done in 15 minutes" will snare a few more victims along the way.