Many of us have struggle with concept of L1, and L2 support and maintenance which can be very expensive and transitioning is a living hell. What we wish is the ability for both of them to work together and make a smooth transition. So I have started to think it would be cool to make this happen for a organization which runs 1200+ servers and have teams to support product and infra both. The Idea was to start with collaboration between teams which can be extended to request and support basis. To extend it further we discovered that product team works for 24x7 and infra team is 18x7. Now it is important to design it in a way that product team can manage it 24x7 with minimum and no help from infra team(L2). Solution: Solution was to use a collaboration tool which supports API for our tools to maintain alert level. For that please refer my previous blog describing configuration of Icinga and Hipchat. Next logical step is to configure hipchat to support robot system which can
With the dramatically increasing demand for container orchestration specifically Kubernetes, demand to template K8S manifests(Json/Yaml) also came to light. To handle increasing manifests, new CRDs(Custom resource definition), etc… it became obvious that we need a package manager somewhat like yum, apt, etc… However, the nature of Kubernetes manifest is very different than what one used to have with Yum and Apt. These manifests required a lot of templates which is now supported by Helm, a tool written in GoLang with custom helm functions and pipelines. Neutral background on templating Templating has been a driver for configuration management for a long time. While it may seem trivial for users coming from Ansible, Chef, Puppet, Salt, etc…, it is not. Once one moves to Kubernetes, the very first realization is hard declarative approach that Kubernetes follows. It is difficult to make generic templating with declarative form since each application may have some unique feature and r