<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Helm on The Blog of Boban Acimovic</title><link>https://acim.net/tags/helm/</link><description>Recent content in Helm on The Blog of Boban Acimovic</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><copyright>The Blog of Boban Acimovic &amp;copy; 2026</copyright><lastBuildDate>Sun, 21 Feb 2021 00:00:00 +0000</lastBuildDate><atom:link href="https://acim.net/tags/helm/index.xml" rel="self" type="application/rss+xml"/><item><title>Go vanity imports</title><link>https://acim.net/blog/go-vanity-imports/</link><pubDate>Sun, 21 Feb 2021 00:00:00 +0000</pubDate><guid>https://acim.net/blog/go-vanity-imports/</guid><description>&lt;p&gt;If you have just started learning Go or already developing in Go for quite some time, you may noticed that most of the Go packages are imported directly from their respective VCS repositories, but there are some packages imported from URL&amp;rsquo;s like &lt;a href="https://golang.org/x/text" target="_blank" rel="noopener"&gt;golang.org/x/text&lt;/a&gt;
 or &lt;a href="https://go.uber.org/zap" target="_blank" rel="noopener"&gt;go.uber.org/zap&lt;/a&gt;
. If you try to visit such URL&amp;rsquo;s, you may see different results like being redirected to documentation or just some dummy page. This is completely different from packages hosted on GitHub, for example &lt;a href="https://github.com/pkg/errors" target="_blank" rel="noopener"&gt;github.com/pkg/errors&lt;/a&gt;
 where you can see the real source code. This feature of Go is called vanity imports.&lt;/p&gt;</description></item><item><title>Install cert-manager using helmfile</title><link>https://acim.net/blog/install-cert-manager-using-helmfile/</link><pubDate>Tue, 28 Jul 2020 00:00:00 +0000</pubDate><guid>https://acim.net/blog/install-cert-manager-using-helmfile/</guid><description>&lt;p&gt;You may wonder what the heck is &lt;a href="https://github.com/roboll/helmfile" target="_blank" rel="noopener"&gt;helmfile&lt;/a&gt;
? Well, I would say what is &lt;em&gt;docker-compose&lt;/em&gt; to &lt;em&gt;Docker&lt;/em&gt;, this is &lt;em&gt;helmfile&lt;/em&gt; to &lt;em&gt;&lt;a href="https://helm.sh/" target="_blank" rel="noopener"&gt;Helm&lt;/a&gt;
&lt;/em&gt;. Basically, it allows us to install the whole stack of applications to our Kubernetes cluster in a declarative way.&lt;/p&gt;</description></item><item><title>Complete your Kubernetes resources as code using helmfile and raw Helm chart</title><link>https://acim.net/blog/complete-your-kubernetes-resources-as-code-using-helmfile-and-raw-chart/</link><pubDate>Sat, 11 May 2019 00:00:00 +0000</pubDate><guid>https://acim.net/blog/complete-your-kubernetes-resources-as-code-using-helmfile-and-raw-chart/</guid><description>&lt;p&gt;&lt;a href="https://helm.sh/" target="_blank" rel="noopener"&gt;Helm&lt;/a&gt;
 is a great tool to deploy popular services and applications to your Kubernetes cluster, but from the moment I started using it I had a feeling that something is missing. You could easily configure and install whatever, but each chart that you use is a separate unit and there is no code containing all resources. This practically means in case of disaster it was still not easy to recreate the cluster, at least not in a quick time frame. Another contra is that in order to pin exact image versions, you would have to edit each values file every time you want to upgrade something.&lt;/p&gt;</description></item></channel></rss>