Forem: Sergio Ocón-Cárdenas

Kubernetes cluster management with Monokle

Sergio Ocón-Cárdenas — Thu, 19 Jan 2023 18:18:27 +0000

If you like OpenLens you will love the new cluster mode in Monokle Desktop

Monokle is a suite of tools designed to help developers and platform engineers manage the application configuration lifecycle in Kubernetes. It includes an open-source Desktop application for Windows, Linux, and Mac, a cloud service integrated with GitHub, and an open-source command-line interface that can be used to validate Kubernetes configurations as part of existing workflows.

When we started working on Monokle in August 2021, our idea was to create the best configuration management system possible for Kubernetes, and we have been adding features for developers and Platform Engineers since then. We have been steadily releasing new versions every few weeks, and up to the current release we have added support for Helm and Kustomize, templates, opa policy visualization in real time, and lately cluster inspection capabilities. We saw ourselves as a complement to other tools, helping with the configuration, while they could focus on the cluster management itself. However, some recent changes in the Lens license and the OpenLens project made their users look for a viable alternative and when they discovered Monokle Desktop, they asked for improvements to what we already had.

We have heard that, and for that reason Monokle 1.13 introduced a new real time cluster mode that allows you to quickly get an overview of the resources and applications running in your clusters, reducing the cognitive load involved in deploying and maintaining your application in Kubernetes and providing full end to end configuration lifecycle management for your application.

So we are introducing new features that will allow Monokle Desktop to connect to your cluster and show the information required to manage your application, at a basic level, in addition to all the validations, templating and configuration that we already support. And we are using your existing kubectl configuration, so you can start using it as soon as you download it.

Cluster Dashboard with real time updates

Until now, you could use Monokle to get a snapshot of the list of resources in your clusters, allowing you to use that as the source for validation and compare to local configuration. Changes in the cluster were not reflected until you hit the refresh button and the management was quite limited. Monokle 1.13 now shows any updates happening to your resources in real-time - making sure you are always viewing the resources as they are actually deployed in your cluster. In addition to real time updates, Monokle has added summary and detailed information for your clusters and their resources, making it easy to assess if your application is behaving correctly or if your cluster has enough free resources to work correctly.

This new dashboard also gives you a direct view of the CPU, memory and Storage in use by the cluster and projects, including information about the Kubernetes version used by your cluster, the container runtime and the alerts generated in your cluster.

Logs and Terminal

Do you really need to understand how your application is working in your cluster? Is the pod behaving properly but the application is not behaving as expected. You can access the log directly in the tab available for your pods in the navigator.

And you have a dedicated link to the terminal, so you can access it directly from the application, without needing you to go to another place.

Resources and CRDs

Monokle Desktop 1.13 shows you a list of all resource types and the associated resources installed in your cluster, so you can quickly review what is installed in your cluster. If your cluster has been extended using a CRD, Monokle will understand and group resources as instances of the new “Kind”, so you can quickly identify which of them are active.

Have you installed CertManager or Istio and you want to make sure that the DestinationRule is working? Just select the DestinationRule section of the Navigator and visualize all your installed manifests

Do you need the IP addresses of your services, or the ports that are opened? Just select services in the Navigator and the list will include those details that are important for your development.

Monitoring Cluster Activity

How is your cluster behaving? Is there something you need to know about your cluster that can affect the way your application runs?

We have added an activity panel to the cluster dashboard in Monokle 1.13, so you can see if some event requires your attention. Right now it is read only but we plan to add additional interactions soon after this release.

Automatic Resource Validation

Monokle constantly validates your configuration against your Kubernetes schema, links, and different kinds of policies, so it is easy for you to identify if there is something wrong with your configuration or if your cluster policy prevents it from running.

Even if your manifest is already deployed, you can check the resources inside the cluster to make sure that the configuration is compliant to policies, or whether it will be valid in the next update of your cluster. For example, you can use it to be sure that you didn’t deploy a ReplicaSet that was unintentionally using the “latest” label against your best practices, or review that the APIs used in your cluster will still be valid when you upgrade your cluster to the next major version.

Details and state of Deployments / Pods

Monokle can now show you details of many of the resources installed on your cluster, including deployments and pods, with their reported state. You can also see incoming and outgoing links to your resources, so you can easily navigate through the components of your application.

Resource Comparison

One of the many utilities included in Monokle is the ability to compare configurations. It doesn’t matter if you want to compare overlays of your Kustomize deployment, the configuration stored in different git branches or commits, or any of the with the actual configuration deployed in your cluster

Not only that, but you can use Monokle to make local copies of the configuration deployed in your cluster, update them and push it back to your cluster directly or storing the configuration in git, or generating a pull request.

What’s next?

Cluster mode in Monokle is new and we have a lot of features in our roadmap that will make it better. Our next version, 2.0, will heavily improve the performance, along with a new interface that we think is better suited for interaction with configurations and clusters. Some of the things that you will be able to see in 2.0 and beyond will be:
Performance improvements for cluster with 1000+ resources
New resource focused UX, that will greatly improve the experience
Graph view to quickly understand the relationship between elements and layers
Additional improvements to the validations supported

And we plan to add new features in upcoming weeks like:

Easily identify the parts of the YAML that are not editable, to avoid introducing changes that will not be deployable in your cluster.
Better cluster information, including resource timelines when Prometheus is installed.
Identify parent/child relationships using ownerRefs to provide additional insight for resources that are managed by the same owner.

Next steps

We would love to have your input on all these things. We are actively talking to users to discuss use cases and problems that we can help to fix, and we are also establishing partnerships to make Monokle way more useful for your day to day work. You can contact us for a 30’ conversation or join our Discord channel, or you can directly open a new issue in GitHub to let us know what you think.

The Monokle Ecosystem

Monokle is an integrated set of tools for creating and maintaining high-quality Kubernetes configurations throughout the entire lifecycle of your applications.

Monokle Desktop is a unified visual tool for authoring, analysis and deployment of Kubernetes configurations, covering the entire configurations lifecycle, from creation to validation to deployment. 100% free and open source. [Kubernetes YAML manifests made easy | Monokle]
Monokle Cloud is a free browser-based tool to explore, validate and manage your Kubernetes configurations and GitOps repositories on GitHub. [Download Monokle Desktop]
Monokle CLI is a flexible and easy to use command-line tool for validating Kubernetes configurations as part of your existing pre-deployment workflows. 100% free and open source. [Monokle]

Announcing Monokle 1.13, now with cluster management

Sergio Ocón-Cárdenas — Tue, 13 Dec 2022 16:28:59 +0000

It’s a pleasure to share the latest release of our open source project, Monokle Desktop - a unified visual tool for authoring, analyzing, and deploying Kubernetes configurations, from pre-deployment to cluster.

The most exciting features of our v1.13 release include Cluster Mode for easy cluster management and an addition to our Compare & Sync feature that eliminates the stress of working on projects containing lots of subfolders.

Cluster Mode offers:

Real-time visibility of resources actively deployed in-cluster
Clear vision of cluster updates
In-cluster resource validation

Read about all new features in the announcement blog-post.

Monokle Desktop can be downloaded and used on Windows, Mac OS X, and Linux.

Feedback is of course appreciated - either here or on our Discord server.

Monokle, Kustomize & Quality Kubernetes Deployments

Sergio Ocón-Cárdenas — Thu, 24 Nov 2022 18:41:30 +0000

Monokle, Kustomize & Quality Kubernetes Deployments — Kubeshop

From the beginning, Kubernetes development has been complex. And as developers learned new tricks, split one manifest into many, tacked on configuration management or templating, and launched dozens or hundreds of new pods with a single run of kubectl, Kubernetes development got *really *complex.

In time, it was too much for a single person to understand, maintain, and optimize every resource and relationship required to deploy an application, whether between two locally-stored manifest files or two pods in a production cluster. New versions of existing Kubernetes API, like networking, were created and allowed new use cases, in many cases at the expense of additional complexity.

As a stopgap solution to this ballooning complexity, developers started “forking” manifests from vendors, using them as templates. Instead of writing a manifest for a reverse Nginx proxy again and again, why not download a manifest directly from the Nginx developers, add a few tweaks, and shortcut your time to deployment?

This model addressed one fundamental problem: that of deploying an application and the additional configuration elements required for it to work. Unfortunately, it didn’t take into account the full lifecycle of the application. When the vendor released a new version of their manifest (the configuration file) with added features or bug fixes, they had to re-fork and re-apply their customizations. This meticulous and manual workflow to stay synchronized with vendor releases was rigid and created more risk, slowing development.

There are many solutions in the Kubernetes space to address this problem, but one of them is built into kubectl: Kustomize—native configuration management designed for simplifying YAML without templates or forking.

How developers use Kustomize

Kustomize is an open-source project that “lets you customize raw, template-free YAML files for multiple purposes, leaving the original YAML untouched and usable as is.” It’s now the most popular tool for customizing Kubernetes manifests reasonably, and it’s even built directly into the Kubernetes CLI since K8s v1.14.

Kustomize lets developers preserve the base settings of their applications, Kubernetes resources, or components, and then apply “patches” that override said defaults. It allows you to add, remove and update configuration options, something that is useful in a whole variety of situations, like:

Defining environmental variables, like LOG_LEVEL, to help you debug issues
Deploy different versions of the database for development and production
Using Kubernetes secrets without committing them to Git by using a generator
Adding the same labels, namespaces and annotations to all Kubernetes resources
Editing the number of replicas created by a Kubernetes deployment, or the appropriate CPU and memory
Make all of the above dependent on the environment where you are deploying the application (Development, QA, Testing, Production)

Unfortunately, you will still need to create and use YAML files. Kubernetes simply won’t allow you to get rid of them because it uses manifests as the base that gets updated through customizations. So, Kustomize rescues us by allowing us to select an existing YAML manifest to customize before applying it in the server.

Let’s say that your application requires three configuration files (manifests) — a ConfigMap, a Deployment, and a Service — which are your “base” files, as Kustomize defines them. Your working directory would look like this:

your-app/
├── configmap.yaml
├── deployment.yaml
└── service.yaml

The easiest way to use Kustomize is to modify all files by adding a label kustomization.yaml file:

your-app/
├── configmap.yaml
├── deployment.yaml
├── service.yaml
└── kustomization.yaml

Once you have added Kustomization to the mix, create a single kustomization.yaml file into your working directory, and refer it to the previous files:

<table>
  <tr>
   <td><code>commonLabels:</code>
<p>
<code>  app: hello</code>
<p>
<code>resources: \
- configmap.yaml \
- deployment.yaml</code>
<p>
<code>- service.yaml</code>
   </td>
  </tr>
  <tr>
   <td>
   </td>
  </tr>
</table>

For more complex customizations, like those dependent on the deployment environment, Kustomize supports the concept of overlay and a base. The base declares things that the variants share in common (both resources and a common customization of those resources), and the overlays declare the differences.

You then create an overlay (or patch; patch.yaml) that contains the configurations you want to override, and then build your edited manifests, and deploy your Kubernetes cluster, with kubectl apply -k.

In the end, your source tree looks something like this:

your-app/
├── base/
│   ├── configmap.yaml
│   ├── deployment.yaml
│   ├── service.yaml 
│   └── kustomize.yaml 
└── overlays/
    ├── production/
        ├── deployment.yaml
    │   └── kustomize.yaml 
    └── testing/
        ├── deployment.yaml
        └── kustomize.yaml

Kustomize also has some advanced capabilities, like generators for ConfigMaps and Secrets, that allows you to create them from files or literals.

You can find more details about Kustomize in the Kubernetes documentation and the kustomize repo:

kubernetes-sigs/kustomize: Customization of kubernetes YAML configurations (github.com)

Kustomize | SIG CLI (kubernetes.io)

The challenges of using Kustomize

While Kustomize simplifies development workflows around creating patches for commonly-reused manifests and Kubernetes resources, it’s not without some of its own headaches.

Primarily, Kustomize necessitates even more YAML files to create, edit, and maintain. You have not only your base files, which you might have developed yourself or “borrowed” from an open-source vendor/repository, but also at least one kustomization.yaml file and more than one `

` file. In the example above, you’ve gone from 3 YAML files that define everything to at least 5 YAML files, which are now intricately linked. You can’t fully understand your Kubernetes cluster unless you examine both the bases and the patches.

The complexity behind those relationships matters a lot when you’re debugging and validating the output of your manifests. If you try deploying and get an error in response, even a common Kubernetes error, it won’t be immediately clear whether said error comes from your base or a patch. You’ll have to spend time, and probably a few tweak-deploy-tweak-deploy cycles to get things right.

Furthermore, the Kustomization files need their own lifecycle. You need to store and manage them separately, as the underlying manifest files evolve with time, and you will need to create new versions to adapt your customization to new structures and values.

How does Monokle’s Manifest IDE help?

First off, let’s get clear on what Monokle and a Manifest IDE are. Monokle is an open source cross-platform desktop app for managing Kubernetes configuration files (like manifests) simplifying your everyday development tasks to help you deploy faster and safer. Monokle gives you a high-level view of your manifests, their resources, and their relationships, while abstracting away a ton of YAML’s inherent complexity and syntax issues.

But, when it comes to Kustomize, there’s even more.

Visualize the scope and relationships of your Kustomizations

The moment you add or select a folder containing one or more kustomization.yaml files, Monokle automatically highlights one of the files, visualizes all its “downstream” Kustomizations and resources in the Navigator, and shows the YAML of the Kustomization in the Editor.

With this three-panel view of your Kustomize files, you can quickly explore the scope of a Kustomization by viewing incoming/outgoing links, quickly jumping between interconnected resources, and editing YAML files directly based on your findings.

No more exploring through nests of patch/overlay folders and bringing up many files side-by-side (or in a grid of four boxes!) to understand how one tweak affects the rest of your deployment.

Preview and debug Kustomize resources

Monokle can perform a quick dry-run of your bases and patches to preview the generated resources, which helps you understand what would actually get installed on your Kubernetes cluster.

Hover over a Kustomization file to reveal the Preview button, which runs kustomize apply -k on that specific file to perform a dry-run and generate the possible output.

You can now explore all the generated resources and resource links, which streamlines the debugging process. If you edit the content of a previewed kustomization.yaml file, click the Reload button to recreate the preview for immediate visibility into how your latest tweak will get installed on your destination cluster.

No more applying your manifests with kubectl repeatedly trying to pin down the origin of a bug created by the obscured network of manifests that Kustomize generates.

Example: Kustomizing a vendor-supplied manifest

Let’s run through an example on how you might use Monokle’s manifest features at scale.

Imagine you want to deploy an off-the-shelf Kubernetes manifest from a trusted vendor, which will become your base file. You want to apply some modifications to it but you want to avoid forking too much from the original file and its subsequent versions. To get the result you want, you can put that file into a base/ folder, and create an overlay/ folder to hold the Kustomize files tailored for your target environments. Some simple kustomization.yaml files to define the base and the overlays, and the required patch.yaml files to override specific configurations of the vendor’s manifests. This is a lot of steps.

Monokle greatly simplifies the process and reduces the chance of errors helping you manage all the manifests you edit. By previewing them in real-time to debug your Kustomizations, you can rest assured that everything works before you try deploying to production.

If at a later stage you hear that your vendor has just released a new version of their manifest with some new features you’ve been eagerly waiting for, you can use Monokle to quickly update and otherwise breaking changes in your customizations to make them work again.

To roll out a new version of your existing manifest files, put Monokle into Preview mode to generate the resources and source code. This will reveal exactly where the breaking change impacts your Kustomization. Monokle’s editor will make it easy for you to edit your patch and use the preview to make sure that you have a successful dry run without needing to test it on your Kubernetes cluster.

You can even investigate a step further by running a Diff, which shows you exactly what changes will get pushed to your cluster’s deployments for one last validation before you hit Deploy.

Monokle simplifies the management of configuration files, including manifests, customizations and overlays, so you can focus on development and reduce the impact of changes on your dependencies.

Start Kustomizing with Monokle

To get started, hop on over to our downloads page to get Monokle for macOS, Windows, or Linux. In order to run the preview functionality, you’ll also need Kustomize installed locally (follow the instructions to do so in your operating system)

Join us on Discord! We’re happy to answer any questions about managing your Kustomizations through Monokle. We’re building our community, learning about your workflows, and imagining new features to make Kubernetes development simple again.

Let us know your feedback and ideas so we can make Monokle even more awesome and cover more of your use cases.

If you know nothing about Git, know this!

Sergio Ocón-Cárdenas — Thu, 24 Nov 2022 18:12:07 +0000

If you know nothing about git, just know this!

Have you heard about Git but you don’t want to read a 500 page long document about it? Are you happy with just enough knowledge about how it works or just need to refresh the core concepts? Have you gone through some books and tutorials and you are still confused about some basic concepts?

If the above describes you, then this article is perfect for you! This post is not intended to be a complete description of what Git is and how to use it, but rather a description of a few concepts that can be useful if you are new to Git. If you’re interested in gaining a deep understanding of Git, you should look at the official reference book and some of the many courses available about the topic: Git

There is also a free e-book recommended by Git called Pro Git Book

And of course, the Github docs are a great source for more details about forking a repo and using it in the Github workflow (where there is an introduction on PR). Although there are other methods, this one is quite common in Open Source.

Fork a repo — GitHub Docs

In our team, we use Conventional Commits

What is Git?

Git is a tool for software version management that is used by millions of developers both in the command line and using different GUI. It is also in the core of GitOps and other Git based infrastructure and configuration management workflows. Knowing Git is a key requirement for professional development, and as of late, for proficiency in environments using Infrastructure as Code.

In Monokle, we have identified a market need for better tools that can leverage Git to support configuration version management. We asked around and discovered that some people on our team, who were not developers, did not know enough about it. Not only that, Kubernetes is used and managed for non-developers, like operators that are not familiar with software version management, TDD, BDD, and other similar topics that make it easier to work with software artefacts

So, I decided to write a small article about the most basic concepts needed to understand what Git is and how it works, without going into the details of the really hard things, like conflict management.

I hope you like it!

Getting started with Git

Git is used for distributed software version control meaning it is a system that records changes to files or sets of files so you can recall a specific version later. It can store changes in any kind of files, although it will normally be used for software source code. (Be careful, as binary files are not easy to compare and diff and they usually occupy a lot of space).

In the past, it was normal to have source version control systems where one server stored the data. You simply connected to download and upload the version you were working with. But recently, that has been abandoned in favor of distributed systems. What distributed means is that any time you make a copy of the files to another server, you are creating a full mirror of everything, a full copy and not just a subset. Any “clone” is thus a full backup and can work with different workflows, with or without other masters, and even serve as a new master file if you need it to.

For instance, you could have different versions of your design documents, or a full version of all the different rewritings of your latest novel.

‍

Git repositories

Git works with repositories, that are the basic elements that get updated and synchronised as you work. Repositories are folders with files inside containing some metadata. It is possible to tell Git to ignore some of the files included if you don’t want to share them (i.e. binary files, secrets, OS specific files, and anything that is specific to you and not to the source code).

There are two ways to obtain a Git repository:

You can turn a local directory into a Git repository (git init)
You can clone an existing repository that is stored in another place. This will create a local copy with all the metadata already in place.

In both cases, you end up with a folder containing files and some amount of metadata inside a .git subdirectory at the base of your folder. That subdirectory stores information about every file and modification done to it. It is efficient because it mostly stores the differences (which is why binaries are not a good fit for this).

There is a catch: files are NOT automatically added to a repository when you create it You need to manually add them so they are tracked. And, in addition to that, files are not automatically updated in the Git metadata so you have to manually trigger a sync.

Recording changes to files

Files need to be tracked and updated. You can actually work on a file without Git storing the changes in the metadata (compare that with Google Docs where every change is stored automatically as a new version every few seconds), so you know in each moment the state of your files:

You can know the state of any file and folder in a repository using Git status

Files follow a flow inside Git and can be in different states:

By default any file in the repo is Untracked and Git won’t store any information about it. The output of Git status will show as Untracked files.
You can add files and folders to be tracked by Git, putting them in the staging area. When you stage a file, you store a snapshot of the information in Git but you are still not following the history of those changes.
If you add a file several times, and you edit and stage it again, you will stage only the last snapshot. Adds a snapshot of every file in the directory: git add .

Adds a snapshot of the file or folder: git add

In order to be able to store and manage versions of a file, you must commit a new version.
Committing will create a new version in the history of every file that is staged and identify that version with a hash.
At that moment, the stage and commit files will be equivalent. git commit -m <commit message>
git commit will ask for the commit message

You can edit a file at any moment:

If the file is Untracked, it will continue to be so.
If the file is Staged, Git will identify it as Modified (and will keep a snapshot).
If the file is Committed, Git will identify it as Modified.
A file can be in all of these stages at the same time:
Modified: the filesystem version is not the same as the staged one.
Staged: the staged version has not been committed.
Committed: there is a version that has been included in a commit.
You always commit the stage version, even if a modified version exists, so you don’t forget to add it before committing.

It is possible to work with the different versions:

You can copy a modified version to stage and from stage to the working version.
You can commit a staged version as part of a commit and you can copy a committed version to stage.
You can ignore a file so it does not appear in your status (this comes in handy to avoid .DS_Store files or binary outputs to be committed so as not to occupy space).

Files are ignored using a .gitignore file in the folder that tells Git to ignore some patterns (like *.a) or track a file even if you are ignoring it with another pattern (!mylib.a).

It is even possible to get a report on every change in and out of stage and commit. git diff - Will report on addition and subtraction to all files

Commits and branches

Commits are stored in the history of Git and can be identified with a unique identifier (SHA-1 checksum) that works as a history line. A commit stores the changes from a previous commit.

Commits can be seen using the log command, which will show a list of all the commits in reverse chronological order starting with the most recent commits first. ‍ git log

Commits are great to compare different versions. You can compare at any time, any commit with another commit and see the difference between commits, too.

git diff 0be526a 161bec8

If you want to go back to a previous version, you can fix a commit using Git revert which will create a new commit that reverts the changes made by other commits. This won’t change your history, because the history will add a new commit that will undo the changes, but the previous commits will still be there.

If there were no mistakes and you always knew exactly what was the next step, this would be a great way of knowing what you have done and go back to it. Basically, you never lose any change committed and you can work on top of any version stored. A single history line, however, can be too limited if you want to explore or fix things without breaking the code.

Sometimes, you want to be able to store different parallel versions of the same docs. For instance, you are working on the new version of the application while you are working on the existing version, and thus, you need to be able to switch from the different versions of your application. In Git, these actions are called branches.

Each commit stores the version of the files that exists in the staging area, some information about the user, and other metadata, with a pointer to the content (blobs) and the directory (tree), and a pointer to the commits that come before.

A branch is then a movable pointer to one of those commits. The default branch is main (although it used to be master so you can find some repos that still use that name), but it makes no difference what branch you use as the basic branch, they are all the same. Each branch is just a history of commits, some of them shared between branches.

When you create a new branch, a new pointer is created (dev), but now you have to choose between two different branches that share commits. So, we need to know exactly what story we are reviewing: that is what HEAD does for us, it points to one of the branches.

Creates a new branch called dev: git branch dev
Changes head to the new branch: git checkout dev
Changes back to main: git checkout main

From the moment we take the snapshot, whatever branch we are in will be the branch. Everything we have done so far will continue working.

For instance, we will be able to have two separated histories in each branch that evolve differently, with the same workflows (staged, modified, committed).

The main reason to create a new branch is either to maintain a completely separated codebase (i.e. version 1 and 2 of our application), or to work in a feature without affecting the work of others, maintaining a working shared history (the main branch).

When you want to add changes in one branch to another, the way to do that is to merge one branch into another.

Go to the main branch: git checkout main
Apply the new commits from dev into main: git merge dev

So, if I want to merge a branch into another to create a new history that includes the commits from those two branches, there are three scenarios to keep in mind:

The dev branch is basically a set of commits ahead of the main branch. After merging, the main branch is fast forwarded to the same commit that was in dev. Dev remains the same. Main now is equivalent to dev.
The main branch has more commits, but they are not conflicting with the ones in the dev branch. After the merge, the commits in both branches are added to main. Dev remains the same. Main now includes all the commits from dev (and perhaps some others) and the originals.
The main branch has different commits that modify the same files that dev, and thus there is a conflict. Git won’t know what to do (you can define a merge strategy so it can guess), so sometimes it will ask you to fix the problem by showing you the conflicts and asking for your inputs for resolution. Dev remains the same. Main will have the commits from main and dev, and another to fix the problems found.

Merging a branch ahead of main is only a fast forward of the pointer.

Merging a branch with a different history creates a new commit.

Remotes

So far, the developer (or designer) is working on a single computer. How can we share the code between developers if they are not working on the same computer? What happens when the code is stored in some other server (like GitHub or GitLab)? There must be a process to make sure that you have the code that is up to date with other versions of the same code and that you can publish your history to share with others. In Git, that means cloning a repository and fetching or pulling from it and pushing changes.

You can create a local copy cloning a remote repo that will create a copy of all the information in there except from webhooks and other server related configurations. It will be your copy and you can work with it as it is yours. [ We will be using Github but you can use Gitlab or any other Git server ].

git clone https://github.com/kubeshop/monokle

That creates a pointer to a remote repo that by default will be named _origin _so you can compare your copy with the one stored. You can see the remotes configured and even havemore than one to work with.

git remote
git remote -v

You can use Git remote to add and delete remotes and you can have more than one remote for the same repo. This will become important afterwards when you want to do a pull request.

Getting additional information is easy. Simply fetch the new data from the remote repo.

git fetch origin

Taking this step will create new local branches for the remote branches as origin/main, origin/dev, etc. It won’t change your local history, rather it will create new copies of the remotes in your local repo so you can decide what next step you’d like to take.

At that moment you can do whatever you want with the branches including merging them into your local branch.

Get the branches from origin: git fetch origin
Change HEAD to the main branch so next actions happen there: git checkout main
Merge the remote history into our current branch: git merge origin/main
Depending on your strategy for branches, it is quite possible that merging your main branch will be a fast forward (more lately).

Even if everything is fine this is not a nice workflow, you need to change branches. If you are developing in your own branch, you will have to copy unstaged changes before changing branches, download the new changes, merge them, and go back to your working branch, and do that every time you are synchronizing your state with that of the server. Fortunately, there is a shortcut that will fetch the data from the server and try to merge into your current code in one go:

git pull origin

So now you have worked locally and fetched the new data merging it into your branch. You should have run your tests and everything is working. Now, you are ready to share your work with the world. In Git, you push your history to the remote server for a specific branch:

git push <remote> <branch>

Rules for pushing to different places are complicated. To get started, you will only be able to push your code if you can actually fast forward the remote to yours.

Pull requests

Now, this is becoming more exciting! You have a working branch with your new code or fix and you want to make sure that everybody will work with that version. There are lots of ways of doing that, but at least in Open Source, and GitOps, you achieve the goal through pull requests.

In a pull request, you ask another developer to merge a branch into the shared repo. The main thing to keep in mind here is that before merging the PR, somebody will have the chance to review the code, discuss with the author how it has been implemented, ask for changes, or sometimes even alter it. In many cases, automatic testing and policies are applied to help with the discussion (i.e. to make sure that the code is following the proper format agreed by the team that all tests are passing, that there is no component that is introducing a security risk, etc), and sometimes more than one reviewer needs to give its ok to the new code.

Moreover, because pull requests work from one branch into a different fork of the code, you don’t have (and you don’t need) access to the original repo. You can accept changes from third parties, friends and family, or anybody wanting to improve the code in a truly open source way. You do that by forking the code, creating a full copy that is not a distributed copy of the original code but your own version of it. You can do it directly in the command line cloning a repo or in the Github interface. There is a button to create a fork in your profile or in any group that you have the proper access to.

You then can create a PR to ask for that merge from your branch in your fork into one branch in the forked repo (mostly main but again, branches are the same for git, it can be any).

Conclusion

Git is a very powerful tool that is underpinning DevOps and GitOps in Kubernetes. Although used by many, the concepts are sometimes not fully understood and it is always good to have a quick refreshment of the key points to ensure best practices.

This article only describes the happy path of a Git workflow so you can start talking about it. In Monokle, we are working to create tools that allow GitOps and DevOps on Git in Kubernetes and we would love to hear your view on it.

Visit us to learn more about how to simplify your Kubernetes deployment configuration or join the conversation in our Discord server.

We also invite you to collaborate with us to improve our code in our Github repo.

Originally published at https://monokle.io.

Advance Git - Git For GitOps

Sergio Ocón-Cárdenas — Thu, 24 Nov 2022 17:59:49 +0000

Advance Git — Git to Work with GitOps

Soon after you master the basics of Git — creating a repository, committing changes, pushing to remotes, and creating pull requests — you’re bound to quickly run into situations where you need to run more than git add . and git push origin main.

At the same time, if you jump straight into the reference documentation, you’ll quickly find yourself lost in every complex nook and cranny of Git, like stashing, cherry-picking patches, adding submodules, and more. Those things are useful but are not really needed on a day to day basis.

This piece is for every developer and DevOps admin who’s in-between. You’re certainly not a beginner, but not an expert (yet) either, and you just want to master new problems and streamline the processes you’ve already embarked on. And we’ll get you exactly the information you need to be even more productive and elaborate with your version control tactics without sacrificing your development velocity.

Merge (or rebase!) your code

The standard way of working on features, specially when more than one developer collaborates, is to create a new branch in Git with the intention of merging your code back into your primary development branch, which, these days, is most often called main. There are many strategies for this (from git flows to truck based development) that we won’t be covering here.

If everything goes to plan on your new branch, the process looks something like this:

Make changes to your code
Stage your changes with git add
Commit your changes
Push your changes to your remote
Merge your new branch withmainand repeat the cycle

But you need to be prepared when things don’t go to plan.

Amend

Let’s say you just hit Enter on your most recent commit and realized you did something wrong. You can change your last commit by replacing it with a new commit, which also creates a new commit hash, or ref. that substitutes the previous one.

You can use it to update your commit message:

git commit --amend -m "Your updated commit message"

Or, if you forgot to stage a file:

git add your-file.txt

git commit --amend --no-edit

As this changes history, it is bad practice to do it if you have pushed your changes into a remote server, as other people can be working on a different version of the history. You will have to –force your new history to push it to a remote server.

Unstage

If you already staged a file using git add, Git doesn’t force you to commit it. When you are sharing your history with other people, sometimes it can be useful to make your history reflect the way you work, and commit the files in different commits instead of in one big step. What happens when you commit a file that you want to add to your history to a later stage? Well, you can unstage these files, which prevents them from being committed, but retains the changes you’ve already made.

If you have a single file you want to unstage, use git restore:

git restore --staged <your-file>

Alternatively, you can unstage all your changes with a single command and get back to the original content before your changes:

`git reset <your-file>`

Unmodify

If you’ve modified a file but haven’t yet staged or committed it, you can use the same technique:

`git reset <your-file>`

Merge

If you’re using a platform like GitHub for code collaboration, you probably won’t be doing much manual merging of branches, but it’s still an important process you should be familiar with.

It’s also important to recognize that, behind the scenes, Git merges your code every time you run git pull to incorporate changes from your remote.

Let’s run through the most common example of manual merges: Combining the work you’ve completed on two local branches before you push to your remote and engage in any code collaboration via GitHub or another platform. You currently have your main branch checked out and want to merge in your changes from new-feature.

git merge new-feature

Git will replay the commits you made on the new-feature branch on top of what’s changed in the main branch, creating one more commit that combines the latest state.

‍

If there are conflicts, you’ll have to deal with them manually.

Rebase

When you merge branches, you write new commits into your repository’s historical record and move on from there, as you see in commit Z from the diagram above. A rebase solves the same problem as a merge — you integrate changes from one branch into another — but when you rebase, it’s more like *rewriting and cleaning up *history.

You’re most likely to rebase when you’ve worked in a development branch for a while, but your main branch has also progressed in parallel. You want to include these new changes into your branch—perhaps you could benefit from a recently-merged bugfix or UI improvement—but you don’t want to create a new and possibly messy merge commit. Instead, rebasing allows you to replay your changes on top of the latest state of main, integrating not only their code, but also their histories.

Let’s assume your Git history looks like this:

From your new-feature branch, you run the following on the branch new-feature:

`git rebase main`

Your Git history ends up looking like this:

From Git’s perspective, you’ve now changed the beginning of your branch from commit T to commit V, allowing you to continue developing from the most up-to-date history. The two big benefits of rebasing is that your branch’s history is cleaner, as though you started working from the latest main from the get-go, and you get a cleaner merge when you’re ready to integrate the branches.

Now a git merge will consist of a fast forward of main to the latest commit.

Resolve conflicts

Whether you’re merging or rebasing, you’ll encounter situations where Git’s merging algorithm can’t reliably handle without potentially breaking your code. You need to resolve these conflicts, telling Git which version of your code is more up-to-date or “correct” before you can push to your remote.

Git informs you of the conflicting file(s), at which point you need to open them, find the line(s) of code that are affected, delete the outdated code, and retain the version that’s more up-to-date or “correct.” Once you’ve resolved a conflict, you can save the file(s), stage with git add, and then continue the process with one of the two commands:

`git merge --continue`

`git rebase --continue`

You may have to resolve conflicts multiple times — particularly when rebasing — but keep cycling through the process until you’ve fully integrated your branches!

Find branches that have been merged with the current

After you’ve been developing for a while, creating many new branches and eventually merging them into main, you’ll inevitably start to clutter up your repository with obsolete or outdated branches. When you run git branch, or attempt to use your terminal’s autocomplete feature to checkout a branch, it inundates you with irrelevant options.

` example-101

  exciting-new-feature

* main

  refactor

  strange-bug

  strange-bug-2

  …`

Because your local branches might contain code you want to keep and merge later, you don’t want to start deleting branches without taking some precautionary steps first.

If you want to see which branches you’ve merged into the latest commit on main:

`git branch --merged main`

Once you know your code is safely inmain, you can delete branches with git branch -d <branch-name>.

Tag important points in your Git history

Now that you’re developing, committing, merging, and rebasing with more confidence, with the knowledge to circumvent any mistakes you might make, you’re getting to the point where you should start to create more organization around your project’s history.

Git might be a version control system, but it doesn’t automatically create the kind of versions we’re more used to seeing, downloading, and interacting with — think milestones like v1.0, v4.0.8, v183.22.8, and more. These version numbers, whether you follow the semantic versioning scheme or any other, help you, collaborators, and end users understand the state of the software they’re creating or using.

Note: Git tags aren’t limited to version numbers alone — you can tag a commit with any string you’d like.

We recommend creating an annotated tag to include metadata, like your Git username, email, date, and a short message. To create a tag based on the current HEAD:

`git tag -a v1.2.0`

Once you’ve created one or more tags, you can list them with git tag.

Another important note is that tags aren’t pushed to your remotes by default, which means you need to do so explicitly:

`git push origin v1.2.0`

The benefit of pushing your tags to your remote is that others can check them out explicitly without having to know a specific ref:

`git checkout v1.2.0`

Fix errors by rolling back history

Sometimes, despite your best intentions, you let errors or bugs make their way into the current commit of yourmain branch. And sometimes, you can’t afford to spend time with a formal process of troubleshooting, fixing, testing, and deploying a bugfix branch—for example, if you use CI/CD to deploy the latest commit to production automatically.

In these cases, your best bet might be to roll back the state of your repository to a previous commit you know works.

Finding a previous commit

First, you need to find the old commit. Either of the following commands will display your repository’s commit history, all the way back to its origin, along with the associated commit message. The first command also displays the author, date, and refs involved in a merge, if applicable. The second command displays only the ref and the commit message, allowing you to traverse history a little faster.

`git log`

`git log --oneline`

Once you find the previous commit, take note of its ref, whether the shortened or long version.

Rolling back to your chosen commit

Before we talk about *how *to do this, it’s important to clarify some of Git’s terminology around these processes, as they’re quite important:

A reset is like going back in time to a specific commit, effectively undoing and removing all the commits between the two and altering the project’s commit history.
A revert is pulling out a specific commit and leaving a revert commit in its place, then continuing development from there.

In the following diagram, you remove commit D and C, rolling back the history to commit B, and then continue your development with E. With a reset, the history is rewritten, while revert will create a new commit that modifies the changes so that the new commit is the same as B (but a new one)

‍

Based on how you want to handle your commit history, and whether you need to preserve the work you completed in those intermediate commits in the process, you can take one of two actions:

Reset:

`git reset --hard B`

Revert:

git revert B

As we said before, reset is a dangerous command if you have shared your code with others, because it will create inconsistencies between copies of the code, as the histories will be different.

Code collaboration on GitHub

GitHub might not be the only place where code collaboration happens, but it’s the most popular platform to do so. Most open source projects host their projects and work with contributors there. GitHub adds some flows to these basic git flows, so it’s important to know where Git’s features end and GitHub’s begin.

Fork a repository

Forking has a long history in open source, but in the context of GitHub, it refers to the process of duplicating a repository under your GitHub account. For example, you find a project at github.com/sandra/projectA, but then create a duplicate at github.com/your-username/projectA. They share the same project name, but they’re managed and maintained by different people—the original creator, and yourself. You are the owner of your copy, so you can modify it and maintain it in the way that you want.

Forking is necessary when you don’t have write access to the original repository and its remotes and branches, which is almost always the case when collaborating on an open source project. Even when working on an internal project, such as refining the Kubernetes manifests your team uses to deploy your application to production, you might be required to work with a fork of the repository rather than writing directly, so you can do some checks and follow some procedures before committing new code.

Pull requests and merges

On GitHub, code collaboration occurs primarily through pull requests, which are your way of informing others about the work you’ve completed and asking them to review and merge your code. Pull requests are completely asynchronous, which is a boom for organizations who work remotely and across multiple time zones and blocks of working hours. When you open a pull request on GitHub, your peers and collaborators can comment on your work, review it, make suggestions and comments. Eventually, your code will be ready and somebody will approve your request, and your changes will be merged into your destination branch — most often, that’s going to be main, although there are different strategies for branch management.

Aside from creating an asynchronous conversation around your proposed changes, pull requests also act as an important check on code quality. Your organization likely requires one or more approvals from your peers to merge any of your pull requests, preventing any developer or engineer from unilaterally merging code.

Pull requests also trigger CI/CD pipelines, which can trigger even more robust quality checks — we’ll cover those in a moment.

One important part of the Pull Request process is the code review. We will see later how you can add automation to the workflow, introducing compliance tests that show information about the code, so the review process can be done easier and quicker (i.e. giving you information about whether the commit will still pass the integration tests, or more).

GitHub Actions

Continuous integration and continuous delivery (CI/CD) pipelines have been around for a long time, but mostly as third-party platforms. GitHub now offers its own CI/CD pipeline, GitHub Actions, which lets you define how you build, test, and deploy your code.

You first define, in your repository, which events — pushes, new issues, pull requests, and more — should trigger CI/CD pipelines, and what actions you want GitHub to take on your behalf. You can automatically test your code for compliance with style, security, or testing requirements, which we’ll cover in the next section.

Making your code compliant

Stylize your code with a linter

A linter is a static analysis tool for improving the quality of your code by fixing errors, pointing out stylistic mistakes, or warning you about suspicious patterns. There are linters for every major programming language and tools that care more about code formatting, like Prettier. These tools look for configuration files, which you store directly in your repository to apply standards across your codebase. Having a well defined linter means that your lines of code are written in the same style as others, making the code easier to understand and review. It is like your automatic coding style guide, and it is so useful for collaboration that modern languages include their own code formatter and linter (like rust, elixir or go)

While some of these tools can run directly in your IDE/code editor, creating flags and warnings as you write your code, another powerful way to stylize and correct your code is with a Git pre-commit hook: Every time you run git commit ..., Git runs your tool (linter or formatter) of choice, and stops the commit if that tool returns any errors or warnings, like a failed revision of your PR. It outputs some helpful information about the violation, along with the filename and line number to help you resolve it quickly.

Run tests automatically

Continuous integration (CI) is an automated process that builds and tests the code you’ve just committed to prevent bugs and errors from being merged into your main branch. The more often you commit, the more often these tests run, encouraging and enforcing higher quality while keeping your velocity high.

CI tests can include the linters mentioned above and code coverage, which reveals what percentage of coude you’re currently testing vs. how much you will test if you merge your branch into main. You can’t use CI directly with Git, but code collaboration platforms like GitHub make it trivial with GitHub Actions. You can also opt for an independent CI/CD platform, like Jenkins, CircleCI, ArgoCD, or dozens of others.

In many cases, you can define your CI practices directly in your repository and keep them version-controlled alongside the rest of your project, smoothing your onramp into more sophisticated DevOps practices, like GitOps.

Integrate security into your workflow

Linters and code coverage tests help ensure the quality of your code, but they can’t prevent you from deploying inherently insecure code. That’s where security-focused CI/CD pipelines come into play, giving you the power to automatically:

Scan your source code for potential vulnerabilities (static application security testing)
Discover which dependencies introduce major security flaws (source composition attacks)
Verify that all user inputs are not vulnerable to injection attacks
Ensure no secrets, like passwords or keys, are publicly visible
Tighten access controls on changes to your production infrastructure as code (IaC)

Dependency management

The application you’re building in your Git repository inevitably requires dependencies — open source projects, tools, and protocols — to function correctly. Every framework and language defines and stores dependencies differently, but most can be saved and version-controlled in Git.

Take, for example, managing dependencies in NodeJS. You create apackage.json file, which defines which packages you need to build and run your application. NodeJS/NPM then creates a package-lock.json/yarn.lock file, which defines your dependencies' dependencies, and stores the packages themselves in the node_modules/ folder. Once you tell Git to ignore that folder by adding it to `.gitignore, you can manage dependencies directly in your repository,

Conclusion

This piece on advanced Git techniques might seem like a lot if you are new to Git, but we have left a few ones behind that you will be using only in very limited situations. However, it is more and more clear that Git is the right choice to store the history of your application and infrastructure configuration to achieve full auditability and automation. Stay tuned for even more workflows and optimizations that come with a deep understanding of all things Git!

And in the meantime, we encourage you to check out Monokle, a desktop application that helps DevOps engineers and developers better leverage Git when managing and optimizing their Kubernetes deployments adding a lot of fundamental features to analyze and create your optimal desired state.

We’re fully open-source and would love to hear about your Git, DevOps, and GitOps journeys on Discord!

Originally published at https://monokle.io.

What I Learned at KubeCon North America with Monokle

Sergio Ocón-Cárdenas — Thu, 24 Nov 2022 17:27:56 +0000

A few days have gone by after Kubecon NA in Detroit and a lot of things have happened during it and after. I spent most of my time in the Monokle booth talking to users, and I learned a lot in the process.

‍

Monokle logo in the startup slide of Kubecon keynote

Changes in a web page can derail your SEO

We changed the web page from monokle.kubeshop.io to monokle.io, and our SEO in Google has gone down like crazy. I’ve been told that it will go back to normal in three weeks, once Google discovers that all the content from the webpage and blog has moved to the new URL and reindex all of that.

I really wasn’t expecting such a hit when there is a redirect from the old pages to the new ones, but it does seem to be the case. Let’s see if we can get quickly back to normal.

Kubernetes is hard and there are not so many experts out there

We had many meaningful conversations about requirements and how to improve the experience for Monokle users, and we were surprised by the fact that many of the attendees to Kubecon were hard experts, but they were looking for a way of making their teams work better with it.

There was a number that we heard a lot: "I have 10x more developers that do not understand K8s than I have experts. So we are looking for ways of making those productive."

I believe many people are taking a shortcut: “we can make your team more productive by creating an abstraction layer on top of Kubernetes that will make their work easy”, but actually that only works when things are going well because you still have a team or non-experts when they need to dig deeper on the problems you're facing to fix your application when is down.

The other approach is to create a platform, so developers don’t need to think too much: they get guardrails and a service catalog, and they are free to use it. There are great solutions with this approach, but I still feel it is really hard to maintain a catalog that balances appropriately the need for new things and the need for those things to be secure.

Our approach (Monokle) is different: we are working with K8s artifacts and making them easier to use in three ways:

Using templates and snippets, and adding documentation in place so we reduce the cognitive workload
Validating in place in real-time, so you know if you are making a mistake with your schema, or you are not following a best practice of policy, and you can learn why and fix it on the spot
Keeping the matter in focus. Yes, we provide forms, but you can have the original YAML file in place at the same time because we are not trying to hide what you actually are doing, but reducing the mistakes you make when doing it

We don’t know more than you do, so we research more

We got so much feedback in a few days and we learned so much about what we were trying to do that it is clear that we need to keep our respect high and act accordingly.

Yes, we got confirmation about many of the things we were trying to do. There is a need for a lot of the features we have, and there is a need for more to make it really really good for your work, but also we learned that there are assumptions we were making that were wrong (like the fact that everybody knows K8s if they are working on the space, that proved to be wrong).

It is sooo good to talk to real users, face to face (and masks), and get the conversation going.

Face-to-face is awesome!
Don’t you think that your meetings were missing something more than what you expected?

I’ve interviewed a lot of people since I joined Kubeshop, and the feedback was great, but the conversation was always straight to the point. There was even a moment, after months of isolation due to the pandemic, when I felt I was losing the capability to do small talk. On video, all conversations seem to be straight to business. Sounds productive, but it is really not so.

There is a ton of good information in the context, and we take it for granted over video conference. Yes, I have this problem, but I am also working with a team that has different issues. No, I don’t need that, but I know five people that do. Oh, I see what you have done, and that reminds me of something I was discussing with a friend the other day.

We want that conversation, and as humans, we thrill on it. Going straight to the point is good when you are dealing with machines.

Engineers need to know what is going on in the cluster, but not everybody needs full cluster management capabilities

In our conversations we found a couple of different personas, the seasoned Gitops / DevOps / platform engineer that would be so comfortable using the command line that any tool, and the developers that need basic information about the state of their deployment.

We know is hard to fulfill the requirements of the first group (and we are working on a CLI for validations that will do exactly that), but we discovered we already have a lot of the features required by the second one (like terminal and log access, cluster inventory management, comparisons, etc).

We will be doubling down on our efforts to get value out of the things we do with clusters and adding some additional functionality to better help with it.

What’s next?

KubeCon North America may be over, but there’s still so much work to do. We need to follow up with many users that had amazing ideas on what we need to do next, and we have a lot of partnership opportunities that we need to materialise into something useful for all.

There is so many things I would love to be doing that prioritization is going to be hard.

Next stop: launching Monokle 2.0 and prepare for KubeCon Europe!

You can learn more about our work in Monokle by going to https://monokle.io and you can try the cloud version at https://app.monokle.com. Monokle is an open source application, so you can find us at http://github.com/kubeshop/monokle/ and on our Discord channel.