Our Hidden Gems of 2019: a Small, Helpful Tool Pick
We know, it's probably too late to call this an “End-of-Year"-list, but while talking about the little things that make our life easier, we decided to write a blog about our favourite Hidden Gem Tools of 2019 and share them with you! Who knows, maybe they will make your life easier in 2020, too.
We all asked ourselves what tool our hidden gem of 2019 was, with the ground rules as follows:
Tool: In the broadest sense.
Hidden: Try to pick something that probably most people have not heard of yet.
Gem: Do not pick the larger-than-life tools, but focus on the small.
2019: You must have really used it substantially throughout the previous year.
Vincent: Who let the dogs out?
https://www.youtube.com/watch?v=Qkuu0Lwb5EM
When I first started working with Kubernetes, I went through an exciting period of getting to know all the possibilities it has to offer, almost feeling like an explorer setting foot in unexplored lands, being stunned by their unseen beauties.
I quickly started using Kubernetes on a daily basis and even though there are not that many kubectl commands to remember, I quickly became bored by the small repetitive sequence of commands I had to perform for the basic things, such as “get the name of the pod and get a shell to that pod” or “get the name of the pod and tail its logs”,… see what I mean?
Thanks to the aliases and the auto-completion brought by the kubectl plugin for zsh, my productivity and efficiency got a clear boost, not to mention my morale! But it still wasn’t the panacea, as some of pains remain present, especially when doing a lot of (kube-)context switching.
And then we discovered, k9s, written by Fernand Galiana… Hallelujah! That tool is a real game changer for people working a lot with Kubernetes via the command-line - at least it was for me. Listing the resources of all types (even the CRD’s!), sorting, filtering, editing, checking the logs, working in different contexts in different tabs … all at your fingertips.
If I have to try and find a flaw in that tool, I’d mention copy-pasting. When copying content spread over multiple lines, the surrounding pipes get copied as well - making it less readable when pasting it. But that is such a minor inconvenience in comparison to the benefits you get out of this tool. 5* rating!
Niels: Mister Clean
https://www.youtube.com/watch?v=HNqX3Ju4q6A
When you’re working with containers and Kubernetes, the following philosophy might sound familiar:
Treat your clusters like cattle, not pets.
In this way of working, we have lots of short lived clusters, sometimes disappearing in a matter of hours. I won’t go into discussions about pros or cons about this approach, but I’d like to focus on a very practical problem this causes: a very, very dirty kubeconfig file. We love small tools like kubectx to streamline our day to day work, but they are rendered worthless by a kubeconfig filled with no-longer-existing cluster entries.
If only a tool existed to automatically clean up those entries...
Enter kubectl-config-cleaner, a kubectl plugin that does exactly that! Setting it up is quite easy, as installation is handled by the krew plugin manager.
Don’t have krew yet? Follow these simple instruction guidelines.
Now use krew to install the plugin: kubectl krew install config-cleanup and you’re good to go!
Dry-run everything using kubectl config-cleanup and save the result using kubectl config-cleanup --raw > ./kubeconfig-clean.yaml.
For ease of use, I created a little alias in ZSH to run it whenever my cluster list gets too long.
alias kcl="kubectl config-cleanup --raw > ./kubeconfig-clean.yaml; mv ./kubeconfig-clean.yaml ~/.kube/config"Run it on a schedule using cron, add some backup config just to be safe, … make it fit your workflow. It has helped mine considerably!
Kevin: Hello from the other side
https://www.youtube.com/watch?v=YQHsXMglC9A
Enough nerdy talk so far. Communication is one of the main drivers for the efficiency of our team. We need to discuss technical stuff, sales opportunities, new marketing ideas, etc. As the geographical spread of kuori is rather large and we are living in 2020 nowadays, we try to avoid unnecessary daily commute by doing online meetings.
We all know Skype, Teams, Zoom, etc. But over the years me and my friends of kuori have fallen in love with the simplicity of Jitsi Meet. This online video conferencing tool has never let us down. It’s easy to meet with a group of people, share multiple screens from multiple participants, and invite others by just sharing a link. Moreover it’s browser-based, so it works seamlessly cross-platform: Linux, Max, Windows. Not to mention when I’m at a customer where stringent network security policies may be in place. Jitsi has always come through. If, like me, you’re one of those people who tend to forget to add an online conference alternative when scheduling meetings you should definitely give it a try.
Carlo: The Power
https://www.youtube.com/watch?v=j1BNcSBApOU
As the only one in the team still using Windows on my main development PC and laptop (yeah, I know), I run into my fair share of problems when it comes to local quick development before pushing stuff into our automated pipelines. Helm, terraform, ansible, golang, yaml (CRLF hell),… you name it, and I probably have had some issues with it.
But 2019 has been blissfully peaceful when it comes to Windows problems. The solution, and my favourite ‘tool’: Docker Images!
No, hold on, it’s not what you think. Let me explain.
I’m not talking about using docker for windows to do everything, because it’s not really going to help you with helm, ansible, terraform and the plethora of other stuff. I’m talking full on Inception, yeah baby.
We embraced gitops, devops, dataops and pretty much every -ops on the planet, and that means we use CI/CD build pipelines (last year we’ve used Gitlab CI/CD, CircleCI and our current one; Bitbucket Pipelines). As we run many production environments for our customers we have to be able to exactly specify all the ALM requirements (helm version, terraform version, azure cli version, …). So, we made our own build images.
Note that we have a baseline image, and add cloud provider specific stuff if needed (you see the examples for Azure and GCP in the screenshot). You can also see there is a ‘powertools’ expansion. This uses the same base image (so always consistent with the versions we use for deployment), and adds some useful tools (such as k9s - Vincent’s pick).
Here it is in action:
Still using some Windows tools? No problem, as I’ve mounted a persistent volume so I can edit in windows, but ‘locally’ run e.g. a helm template that will catch everything it need to catch.
So, not a ‘tool’ you can download and use, but something you can easily make and use yourself (even if you’re not on a Windows, it still has benefits), especially if you are serious about maintaining production clusters in a <buzzword>ops way.
Happy happy joy joy
There you have it. Hopefully these little gems will bring you the joy they brought us. We’d love to hear your experiences in the comments and maybe share your own little gem with us?