K9s is a terminal-based Vim-like Kubernetes UI.
Everyone is used to Web and desktop dashboards. Kubernetes users are divided between those who prefer performing operations through UIs or through a terminal. How about combining the two modes of operations? K9s is giving us just that. It provides a terminal-based Vim-like UI for operating and observing k8s clusters.
Release frequency keeps increasing and, with it, the need to get away from static environments like staging, integration, and other permanent setups. Dynamic environments based on pull requests are probably the best example of a need for a much higher level of dynamism. Kubernetes allows us to easily create whatever we need, and destroy what is not in use. There is no need for anything, especially not environments to be permanent, except for production. We can get far in that direction by combining GitOps practices and Argo CD in a way that each pull request (PR) creates a new environment that is destroyed when a PR is closed. By doing that, we can improve efficiency while, at the same time, reducing the costs.
After many failed attempts to find a Kubernetes dashboard that is actually useful (even a little bit), I finally stumbled upon Kubevious. There is finally a Kubernetes UI I can recommend.
Octant is all the rage. It's supposed to be the best Kubernetes dashboard on the market. Yet, I failed to see a reason why anyone would use it. Am I wrong? What am I missing?
Argo CD is a declarative GitOps deployment tool for Kubernetes.
It is one of the best, if not the best tool we have today to deploy applications inside Kubernetes clusters. It is based on GitOps principles, and it is a perfect fit to be a part of continuous delivery pipelines. It provides all the building blocks we might need if we would like to adopt GitOps principles for deployments and inject them inside the process of application lifecycle management.
Argo CD is a tool that helps us forget the existence of kubectl apply, helm install, and similar commands. It is a mechanism that allows us to focus on defining the desired state of our environments and pushing definitions to Git. It is up to Argo CD to figure out how to converge our desires into reality.
Since the increase in popularity of continuous delivery (CD), there was an increase in the number of tools marketed as CD solutions. That's normal. It is only natural for software vendors to ride the waves. They need to sell, and there's nothing better to sell than whatever is popular at a given moment. Continuous delivery is one of those "popular" waves.
A video version of the same post is available in The DevOps Toolkit Series YouTube channel.
On the surface, there is nothing wrong with buying tools that solve problems. You have a problem, a vendor has a solution, you buy it, they earn money, and you have a good return on investment. Everybody wins, except when the tool does not do what it's supposed to do. That's when we run into issues.
GitOps is nothing new. Or, to be more precise, the principles of GitOps existed long before the term was invented. But hey, that's the pattern in our industry. It is the fate of all good practices to be misunderstood, so we need to come up with new names to get people back on track. That is not to say that we are in a constant loop. Instead, I tend to think of it as a periodic reset trying to eliminate misinterpretations. GitOps is one of those resets. It fosters the practices and the ideas that existed for a while now and builds on top of them.
This text was taken from the book and a Udemy course The DevOps Toolkit: Catalog, Patterns, And Blueprints
All the commands from this article are in the [04-03-knative.sh](Gist with the commands: https://gist.github.com/dc4ba562328c1d088047884026371f1f) Gist.
Before we dive into the actual usage of Knative, let's see which components we got and how they interact with each other. We'll approach the subject by trying to figure out the flow of a request. It starts with a user.
This text was taken from the book and a Udemy course The DevOps Toolkit: Catalog, Patterns, And Blueprints
Should we use managed Containers as a Service (CaaS)? That must be the most crucial question we should try to answer. Unfortunately, it is hard to provide a universal answer since the solutions differ significantly from one provider to another. Currently (July 2020), CaaS can be described as wild west with solutions ranging from amazing to useless.
This text was taken from the book and a Udemy course The DevOps Toolkit: Catalog, Patterns, And Blueprints
Help us choose the next subject for the course by filling in a survey at https://www.devopsparadox.com/survey
Azure Container Instances are a way to deploy containers in the Cloud. Based on that, you might think that ACI is not much different from other Containers as a Service solutions. But it is. It does not have horizontal scaling, nor any other features often associated with schedulers like Kubernetes. It is limited to the ability to run a single container in isolation. It is very similar to using Docker, except that it is in Azure, and that it saves us from worrying about the infrastructure needed to run containers.
So, if Azure Container Instances are very similar to Docker, why not use docker instead of az CLI? Fortunately, folks at Docker asked themselves the same question and released Docker Desktop that supports ACI. It is available since version 2.3.3+.