With the launch of GimletD, crafting a concise and elegant home page for Gimlet is not easy.
Since one of my driving thoughts for Gimlet is to be modular, there are many paths you can take to adopt Gimlet:
No need to adopt the full platform to benefit, unlike many PaaS out there.
But this also makes it difficult to capture the different usecases for Gimlet. This blog post is an exercise for me - the maker of Gimlet - to collect the different paths for adoption.
Maybe you get inspired with one of the paths and feel comfortable using Gimlet in your k8s deployment approach.
Let's do this, shall we?
Gimlet has three components today:
OneChart is a generic Helm chart that supports the typical web service deployment patterns.
Authoring a Kubernetes application manifest is reduced to setting the parts that are unique to the application itself. No more boilerplate.
Gimlet CLI is the glue between all Gimlet components, but it also warrants for existence on its own. There are workflows that can be only carried out with Gimlet CLI.
You typically use Gimlet CLI on your laptop, or in CI, but also it is the tool to drive many of GimletD's workflows.
GimletD is the gitops release manager. It builds on the concepts, conventions and workflows that Gimlet CLI introduced and extends it with a centralized approach for managing releases.
It allows for policy based deploys and advanced authorization settings. It also packs all release automation logic that used to be scattered in CI pipelines.
This case is simple. OneChart is a Helm chart like any other, and you can insert it in your existing Helm workflow.
While I wouldn't call this a true adoption of Gimlet, OneChart can stand on its own. It simplifies YAML authoring at your company. Go and use it, and thanks for doing so!
On this path you would use the generic Helm UI feature of Gimlet CLI to configure your existing Helm charts.
It would mean that Gimlet's Helm UI feature would really take off, something I want to happen regardless of the success of Gimlet as a whole.
Helm React UI was a true R&D at Gimlet and I'm hoping that one that you can use it for all the common charts out there.
It is certainly my priority to get through to Helm devs and make Helm UI an industry wide standard.
See the UI feature of Gimlet CLI in action:
Using OneChart and Gimlet CLI's UI to configure Helm charts can really speed up YAML authoring.
It also provides an easy way in for new Kubernetes users, plus you can distribute best practices at your company through OneChart.
We recently discussed OneChart on CNCF's Application Delivery SIG how to use it internally at a company to package all best practices:
This path means adopting one of the defining feature of Gimlet, the environment file.
Its power lies in its declarativeness. It captures all there is to be captured about an environment, versions, variables, etc. And the best thing is: it lives in the application source code repository, thus giving the control to devs for things that they can and should control.
The manifest combined with OneChart's best practices approach gives the core developer experience of Gimlet, and you can benefit from it even without adopting gitops, or the gimletd release manager.
You can stick to your existing CI pipelines and use
gimlet manifest template to render the Kubernetes manifests at deploy time,
then pipe into
kubectl apply. This way you can enjoy a standardized templating mechanism, and a more declarative approach than using Helm alone.
This path ups a notch from path four.
You are still using your proven CI pipelines, but instead of running
kubectl apply, you use
gimlet gitops write to write the gitops repository.
This is an easy path into gitops: you still control most of the things, but have a gitops indirection in your delivery workflow.
Read more about this approach in the Manage environments with Gimlet and gitops guide.
Once you gain confidence in the gitops controller, you are ready to jump to path six and remove a bunch of pipeline logic from your CI.
In path six, you take full advantage of Gimlet.
In this setup GimletD acts as a centralized release manager that adds policy based deploys and advanced authorization and security controls.
It both allows strict control over releases, and flexibility to rewire the release workflows for all your applications at once. And by capturing all release logic, it factors out a large amount of scripting work from CI pipelines into a standardized toolchain.
Read more about GimletD's concepts here.
Pick the one you feel the most comfortable with and let me know how it went.
I'm @laszlocph on Twitter.
Photo by Paweł Czerwiński on Unsplash