Skip to main content

· 6 min read
Juraj Karadža

Gitops & Clickops

In the DevOps landscape, two paradigms have emerged: GitOps and ClickOps, each offering unique approaches to managing Kubernetes-based infrastructure. However, if you ask an experienced DevOps engineer, they might scoff at the idea of ClickOps as an alternative. While their reasoning may be valid, is ClickOps truly as unworthy as they might make it out to be?

In recent years, we have seen the rise of (Internal) Developer Platforms. An IDP can be anything from a couple of scripts to a complete GUI-based platform, but they all share the same goal of enabling self-service for developers when deploying applications and infrastructure. While some IDPs incorporate GitOps principles, this isn't always the case.

This post will explore these two popular methods for managing applications and infrastructure, their strengths, where they fall short, and how to get the best of both worlds.

Click by Click, Commit by Commit…

Support us 🙏

We know that Kubernetes can be difficult. That is why we created Cyclops, an open-source framework for building developer platforms on Kubernetes. Abstract the complexities of Kubernetes, and deploy and manage your applications through a customizable UI that you can fit to your needs.

We're developing Cyclops as an open-source project. If you're keen to give it a try, here's a quick start guide available on our repository. If you like what you see, consider showing your support by giving us a star ⭐

⭐ Star Cyclops on GitHub

Support us with Github stars

What is GitOps?

GitOps is a method in which the desired state of your application and infrastructure is stored in Git, and an automation tool ensures that those changes are applied to your Kubernetes cluster.

There are usually two approaches to GitOps: the push and the pull approach. The push approach relies on an external system that pushes the infrastructure code to the cluster, typically triggered by a pipeline or event. On the other hand, the pull approach involves a tool running within your cluster continuously pulling the infrastructure code from a Git repository and applying it to the cluster.

While GitOps is considered best practice amongst the DevOps community because of its automatization and version control, it depends on practitioners having a strong understanding of how to write infrastructure as code (be it YAML, Terraform, or others).

What is ClickOps?

ClickOps usually relies on a user-friendly UI through which individuals can click through forms, fields, and checkboxes and provision and deploy their infrastructure and software. With its visual, interactive experience, ClickOps makes managing complex systems easier and more approachable, no matter your skill level.

Professional DevOps might be turned off by the lack of a single source of truth that describes your whole infrastructure (like code stored in Git), but ClickOps shines when it comes to quick adjustments and enabling self-service for less infra-oriented people (like most developers). It is a core component in any Internal Developer Platform (read more about IDPs here).

Getting the Best of Both Worlds

Both approaches offer various benefits but also have their shortfalls. GitOps offers version control but is more complicated for developers since it relies on infrastructure as code (IaC), which can quickly become complex. It is great for stable environments where changes should be documented.

ClickOps enables quick changes and an interface that makes it easier to interact with Kubernetes but requires manual input (the clicks) and does not have a single source of truth you can point to. It is perfect for short-lived environments that serve as a playground for testing.

At Cyclops, we are committed to creating a framework for building internal developer platforms. Understanding the challenges of both GitOps and ClickOps, we wanted our tool to handle both sides of the DevOps coin. 🪙

GitOps & ClickOps with Cyclops

All applications in Cyclops are defined as custom Kubernetes resources called Modules. Each time a Module is created, the Cyclops controller picks it up, creates other Kubernetes resources from it, and applies them to the cluster. Because Modules are CRDs, you can define them via a YAML manifest. And since a Module can be defined through a manifest, it can be stored on a Git repo and included in your GitOps workflow!

Let’s take a look at an example of Module manifest:

apiVersion: cyclops-ui.com/v1alpha1
kind: Module
metadata:
name: module-in-action
namespace: cyclops
spec:
targetNamespace: default
template:
path: demo
repo: https://github.com/cyclops-ui/templates
sourceType: git
version: main
values:
image: nginx
name: demo-app
replicas: 1
service: true
version: 1.14.2

Modules, even in their YAML format, offer a much simpler interface for developers to interact with. The values section is the only important thing for developers if they are using the GitOps approach, and is defined and customized by their DevOps.

From the code above, template is actually a reference to a Helm chart. The Helm chart is hidden from developers and offers DevOps engineers all the flexibility Helm usually does. Applying the above manifest, Cyclops knows it needs to create a deployment of nginx with 1 pod and a Kubernetes service.

Cyclops offers a dashboard for developers to visualize what their application is made of. Here, they can perform basic actions. To name a few: restarting their application, editing the configuration and viewing the logs of their app.

module-in-action

Because you can edit the configuration through the Cyclops UI, it allows for much quicker changes. However, this clashes with the GitOps philosophy. That is why we introduced immutable fields. When a field is classified as immutable (in the Helm chart), it can only be configured through the GitOps workflow.

immutable-module

The image above shows the edit screen of a module. Fields for image and version cannot be updated through the UI and should be updated through the GitOps workflow. But, not all configuration values are created equal. In the above module, environment variables are not specified as immutable and can be changed through the UI (a ClickOps approach).

See it in Action!

If you want to see how a ClickOps and a GitOps workflow can supplement each other, check out this tutorial we made to get you started.

This is something we recently released and is just one of the possible ways to pair GitOps and ClickOps. We would love to hear what you think about this setup, so feel free to share it in the comments or in our Discord. Any new idea is more then welcome!

This was part of our first-ever Launch Week. If you are interested in what else we uncovered, check out a short recap here 👀 #cyclopslaunchweek

⭐ Star Cyclops on GitHub

· 5 min read
Juraj Karadža

launch-week-teaser

Cyclops is having its very first launch week, starting on November 25th!

For an entire week, we will be unveiling a feature a day - that's five features in total!

We don't want to spoil the surprise just yet, but if you're as impatient as we are, we invite you to join our Discord session that is happening on Monday, November 25th, at 6 pm CET! We will preview all of the features we plan to reveal throughout the week and host an Ask-Me-Anything session afterward.

To reserve your spot, visit the event in our Discord server and mark yourself as interested.

discord-event

Come back here each day to see what we launch, or follow us on X and LinkedIn to keep up to date and follow the hashtag #cyclopslaunchweek

#1 Helm Releases ⚡

With the release of this feature, Cyclops will pick up on any installed Helm releases in your cluster and showcase them in our new tab - Helm Releases.

Besides reviewing all of your installed Helm releases in a cluster, through this tab you can inspect them as well. You can view all the resources your Helm release is made up of, edit the releases through the UI, and delete them.

helm-releases

Although Cyclops Modules are a more powerful way of managing your applications in the cluster, the Helm releases manager offers a good starting point since it does not require you to change your current CI/CD pipelines or workflows. We also found them great for environments with short lifecycles - such as testing or staging clusters!

#2 GitOps 🦑

We know this was a highly requested feature, and we are happy to announce that Cyclops now supports a GitOps workflow!

All applications within Cyclops are defined as CRs called Modules. Each time a Module is created, the Cyclops controller picks it up, creates other Kubernetes resources from it, and applies them to the cluster. Since Modules are CRDs, you can define them via the YAML manifest. Those manifests allow you to define everything you need for your application in a single place.

Since a Module can be defined through a manifest, it can be stored on a git repo and included in your GitOps workflow!

Through the Module manifest, you can also define which values you want to make editable through Cyclops and which values should be handled only with GitOps. For example, the image version should only be handled with GitOps, but you want to enable developers to scale the number of replicas through Cyclops.

We created a guide you can follow to get started, check it out here!

#3 Namespace Scoped Cyclops 🔬

We know this was a thorn in your side, but from now on, you can restrict Cyclops to a single namespace to limit the permissions needed for your Cyclops installation!

Firstly, we introduced three new environment variables WATCH_NAMESPACE, MODULE_TARGET_NAMESPACE and WATCH_NAMESPACE_HELM, which will help you configure your Cyclops instance to act only in specific namespaces.

...
- name: cyclops-ctrl
image: cyclopsui/cyclops-ctrl:v0.15.2
ports:
- containerPort: 8080
env:
- name: PORT
value: "8080"
- name: WATCH_NAMESPACE
value: "my-namespace"
- name: MODULE_TARGET_NAMESPACE
value: "my-namespace"
- name: WATCH_NAMESPACE_HELM
value: "my-namespace"
...

Secondly, we created a Helm chart that utilizes these env variables to create Roles and RoleBindings for Cyclops to be scoped to a single namespace of your choosing. And, of course, we made a guide on how to use these env variables and how to easily get set up - check it out here!

#4 Private Repositories 🔐

Most companies do not store their configurations & Helm charts in open repositories, so this feature was a MUST-have! However, accessing private repositories requires authentication.

We did not want to bloat Cyclops with a database, so we introduced a new custom resource called TemplateAuthRule! This resource defines which templates you want to authorize and points Cyclops to the authorization data that is stored securely in Kubernetes secrets.

tar_arch

Of course, we created a tutorial on how to enable Cyclops access to your private repos here.

#5 Streaming 🌊

If you've used Cyclops recently, you may have noticed a more responsive and smoother experience. This improvement comes from our latest enhancements: streaming resource status updates and real-time app logs.

You can now rest comfortably knowing that the resources are getting their status (health) updated live from the cluster!

REACT_APP_ENABLE_STREAMING: true

Of course, if your bandwidth is not allowing you to keep an SSE connection open (or you just don’t care about having the state streamed to the UI), we introduced a new environment variable in cyclops-ui that allows you to disable this feature ⬆️

If you've used Cyclops recently, you may have noticed a more responsive and smoother experience. This improvement comes from our latest enhancements: streaming resource status updates and real-time app logs.

Launch Week Wrap Up 🎁

This wraps up Cyclops Launch Week! We’re thrilled to have shared these five amazing features with you, each designed to make your Kubernetes experience more efficient, secure, and user-friendly.

Thank you for being a part of our journey! If you are interested in keeping up to date, be sure to join our Discord community where we always share the latest news! 👾

Looking forward to our next launch week 🚀

· 10 min read

Cloud Platforms

Whether you are a veteran or just started coding, chances are you stumbled upon Kubernetes. It's arguably the most popular platform for deploying applications as containers.

But should we use Kubernetes as just a container orchestrator, or is there more to it?

Kubernetes allows you to extend its mechanisms with your own custom resources and functionality. Its extensible API allows you to define resources outside of applications, such as cloud resources (an instance of MySQL in GCP or an S3 bucket in AWS).

This allows you to manage all of your system components through Kubernetes, from cloud resources to running applications. With Kubernetes, you can easily build your very own Internal Developer Platform that is tailored specifically for you and allows developers to manage and provision everything they need to ship products.

Through the blog, we will build exactly that - a friendly platform that will allow us to simply deploy our apps to K8s, as well as provision AWS resources. We will use the AWS S3 bucket operator to create buckets and Cyclops to get a super simple Kubernetes UI.

Any software engineer can now select a couple of fields, and behind the scenes, it unravels into a complex cloud setup tailored for your organization that can be easily managed.

Support us 🙏

We know that Kubernetes can be difficult. That is why we created Cyclops, a truly developer-oriented Kubernetes platform. Abstract the complexities of Kubernetes, and deploy and manage your applications through a customizable UI that you can fit to your needs.

We're developing Cyclops as an open-source project. If you're keen to give it a try, here's a quick start guide available on our repository. If you like what you see, consider showing your support by giving us a star ⭐

Support us with Github stars

What is a Kubernetes Operator

Kubernetes operators allow you to extend K8s functionality with custom resources and logic. Operators naturally follow Kubernetes’ philosophy of a control loop - bringing the state of your resources towards what was defined.

You can divide a Kubernetes operator into two parts:

  • custom resources - defined through Custom Resource Definitions (CRDs) that allow you to extend the Kubernetes API with new types and kinds. Using custom resources, we can define the desired state of our system.
  • controller - will implement the mentioned control loop to make sure the defined state from the CRD is, in fact, brought to reality. Controllers listen to changes in custom resources and react to them to make sure the system achieves the desired state.

For example, Kubernetes Deployments are resources that define how to deploy our application, and the controller manager implements the control loop to create Replica Sets and Pods to ensure our app is running.

Without changing the Kubernetes codebase, you can leverage the mechanisms from your clusters, like the API and the database. We made a blog post on CRDs and whether Kubernetes is just a glorified database. It explains how you can make the command below a valid kubectl command - check it out here!

kubectl get apples

NAME AGE
green-apple 6s

You are more than welcome to implement a Kubernetes operator yourself, but there are plenty of operators/controllers already out there you can just install into your cluster. There is a long list of well-known operators for different use cases you can check on https://operatorhub.io/

AWS controllers for Kubernetes

There is a family of controllers that allow you to manage your AWS cloud resources like S3 buckets, databases, and applications. AWS Controllers for Kubernetes is a project that implements a collection of controllers that each manage one AWS service.

For example, one controller defines a Kubernetes custom resource for an AWS S3 bucket and makes sure all the S3 buckets are created. The same goes for other AWS services, which each have their own dedicated controller.

If we take the mentioned S3 bucket controller, we can define an S3 bucket in our Kubernetes cluster with the following YAML:

apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: my-new-bucket
spec:
name: my-new-bucket
tagging:
tagSet:
- key: env
value: prod

In the spec, we can add all of the config we need for our S3 buckets, like permissions, object lifecycle, and website hosting… but this time through Kubernetes resources.

Once you apply the manifest from above into a Kubernetes cluster with a configured S3 controller, the controller will create an S3 bucket in your AWS account with all the configuration defined in the YAML.

Controllers with Cyclops

Provisioning cloud resources through Kubernetes objects is (in my opinion) an awesome concept. Now, your Kubernetes cluster is not only running containers but is also controlling all of your system’s components, like networking policies and databases.

Defining stuff in Kubernetes has benefits but also some downsides. Which cloud resources should you use, and how should you configure them? Which fields do you need to populate, and what values are valid? And once everything is configured… how do you keep it running smoothly?

These are all valid questions, and this is what we will use Cyclops for 🔥

Cyclops allows you to hide all of the complexities of Kubernetes under a simple UI that anyone can customize to their specific needs. In the next chapter, we will combine an AWS controller for S3 buckets with Cyclops to get a simple UI that abstracts (somewhat) complex S3 bucket configuration.

Architecture

Install

Through the following section, you will install the S3 controller along with its Bucket Custom Resource Definition. You won't be deploying your buckets through kubectl like some savage; we will also install Cyclops, which comes with predefined templates for your Buckets.

And we will do all that with a single command 🔥

There are some prerequisites before we get to deploying:

  • AWS account to deploy S3 buckets to
  • AWS account credentials your S3 controller can use
  • running Kubernetes cluster
    • Even though you will be creating AWS resources, your cluster does not need to run in AWS. If you don't have a cluster, you can spin up one with minikube
  • kubectl and helm cli tools

If you have everything from the list above, install Cyclops and S3 bucket controller with a single command. Make sure you populate the region you want to deploy to and your access key and secret access key mentioned in the prerequisites.

helm install cyclops-aws oci://registry-1.docker.io/cyclopsui/cyclops-aws-s3 \
--version 0.3.0 \
--namespace cyclops \
--create-namespace \
--set s3-chart.aws.region=<aws region> \
--set aws.accessKeyId=<your access key> \
--set aws.secretAccessKey=<your secret access key>

You can check if all the pods we installed are up and running with

kubectl get pods -n cyclops

And you should get an output similar to this one:

NAME                                    READY   STATUS    RESTARTS   AGE
cyclops-aws-s3-chart-684cdd9b8c-cpfrz 1/1 Running 0 40s
cyclops-ctrl-5ddd9b8bc9-7b5pq 1/1 Running 0 40s
cyclops-ui-7d55d588cd-kdrgt 1/1 Running 0 40s

Once the pods are up, you can port forward your Cyclops instance to access with the following command:

kubectl port-forward svc/cyclops-ui 3000:3000 -n cyclops

And you can now access Cyclops on http://localhost:3000/

Cycops

Deploying an S3 bucket with Cyclops

To create a brand new S3 bucket, go to Add module in your Cyclops dashboard, and select the s3-bucket template.

Cycops Deploy S3

Cyclops templates are nothing more than Helm charts anybody can create and import into Cyclops through the templates tab. You can find this template here and use it to create your own UI 😄

Here, you can configure your bucket:

  • Bucket name override - by default, your AWS bucket will be called after the module, but this field allows you to name it differently from your module
  • Bucket use case - select the use case for your bucket
    • testing - all bucket objects will expire after 3 days which makes it great for testing and automatically removing objects after you are done with testing
    • production - will only expire older versions of your objects after 30 days. Last 3 newer versions of objects will be retained.
    • website - enable static website hosting

Cycops S3 bucket

Once you deploy the Module, you will see your shiny new S3 bucket custom resource in the Cyclops console. Also, you can check you AWS account to see a new bucket.

S3 bucket testing setting

Since the bucket above was created with the testing type, the bucket you created has a lifecycle rule for expiring objects like the one below.

S3 bucket production setting

You can now go back to your Cyclops console and edit the module you used to create your S3 bucket. Change the Bucket use case to production and check your buckets lifecycle rules. You can see that the rule is now called expire-prod and if you check its configuration, you will find it defines a completely different lifecycle which you never had to care about and somebody did for you.

Edit S3 bucket

Combining applications with Cloud resources

Since our cloud resources are defined the same way we would define an application running in Kubernetes, we can deploy them as a single unit!

Sure, some cloud resources (like VPCs or subnets) should not be deployed as part of an application, but if we are talking about storage or load balancers, it might be an awesome productivity boost for developers to ship their apps without thinking a lot about provisioning and infrastructure.

Let’s pretend we have an application that depends on an S3 bucket and you want to deploy and manage them together. The same way you created an S3 bucket earlier, you can now choose the app-with-s3-bucket template and configure your application and your S3 bucket in the same place.

App with S3 bucket

This template is also available here.

You can now play around with your app and your bucket config as much as you want, but the important thing is that you can manage it from a single place. Changes in your resources, whether they are cloud services or Kubernetes deployments, are now atomic, and you can ship your apps and their dependencies together 🔥

Custom cloud platform

Through the example above, you can see how flexible Kubernetes is. With Kubernetes and its countless operators, you can control any resource your system needs, whether it is a container or a cloud resource.

Using Cyclops with such a setup allows any engineer to have full power over their system at their fingertips with the right abstraction.

They can now ship whatever component they need in a couple of clicks while being sure what they are doing is not going to break anything - what Platform engineering is all about.

If you enjoyed this article, or got some ideas on how to implement something similar for yourself, remember to show us your support by starring our repo 🌟 🧡

· 6 min read
Juraj Karadža

5 IDPs

Gartner predicts that by 2026, 80% of software companies will have established platform engineering teams (source). As companies grow, so do the challenges of keeping things running smoothly, and developers want tools that make their work easier and more intuitive.

The main responsibility of platform engineering teams is to create and maintain internal developer platforms (or IDPs for short). In our last post, we gave a more in-depth look into platform engineering and IDPs, exploring how this new trend emerged and its benefits.

But when considering IDPs, you have two options: building one yourself or getting an off-the-shelf solution. Building one yourself is often too time-consuming and expensive for most companies, and that's why off-the-shelf platforms are an attractive alternative. There are a lot of such solutions available, and we will not cover all of them in this post, but let's look into five internal developer platforms you need to know about…

Cyclops logo

Cyclops

Developer-Friendly Kubernetes

Cyclops is an open-source tool that simplifies Kubernetes for development teams by hiding its complexity behind a customizable user interface.

Cyclops allows DevOps teams to quickly create custom UIs for their development teams and empowers them to create validations on developer actions to establish guardrails that reduce the risk of misconfigurations reaching production.

After a developer deploys their app, Cyclops provides an intuitive overview of the application running in your cluster. This allows developers to quickly spot and fix errors and easily access their app logs without ever having to onboard on Kubernetes.

Cyclops is cloud agnostic; as long as you are running a Kubernetes cluster, you can set it up with a single command from your terminal. It has a couple of predefined templates to showcase its customizability and enable you to quickly deploy your apps to K8s.

What makes it special: Cyclops' customizable UI allows DevOps teams to easily create user-friendly interfaces that match their organization's needs, giving developers the right level of abstraction over their underlying infrastructure. Because Cyclops dynamically creates UIs based on Helm charts, you can plug your existing Helm charts into it and have a fully functioning UI for your developers in minutes!

Humanitec logo

Humanitec

Build a Platform That Drives Change

Humanitec is a modular platform designed to help organizations build scalable, enterprise-grade internal developer platforms.

The product philosophy at Humanitec emphasizes flexibility and a code-first approach. Their tools are modular, ensuring there is no vendor lock-in while being enterprise-grade. This approach means there's no "black box" feeling.

Humanitec's product suite includes The Portal, which provides developers with an easy-to-use UI for configuring applications, checking container logs, and debugging errors. Additionally, Score allows developers to define their workload requirements in code, promoting consistency across teams.

The Platform Orchestrator is at the core of Humanitec's offerings. It is an engine that enables platform teams to define templates and establish golden paths for their developers. Resource Definitions serve as open-source building blocks that tell the Platform Orchestrator how to create/update infrastructure in a particular environment. ****

What makes it special: Humanitec's platform is highly modular, allowing organizations to build IDPs using its products as a whole or as building blocks in a larger platform. It easily integrates with existing infrastructure-as-code (IaC) setups, making Humanitec great for large teams looking to scale their operations efficiently.

Qovery logo

Qovery

DevOps on Autopilot

Qovery is a DevOps automation platform designed to eliminate the need for dedicated DevOps hires by providing a comprehensive self-service infrastructure for developers.

It streamlines the entire process of infrastructure provisioning, transforming what is usually a time-consuming and manual task into an automated workflow. It can provision infrastructure assets into ready-to-run environments, whether for development, QA, or anything else.

In addition to simplifying infrastructure management, Qovery is designed to help organizations optimize their cloud spending. The platform offers various strategies for cost reduction (like automatically shutting down unused environments) and detailed insight into resource usage.

Qovery is built to integrate with your existing toolset and cloud accounts. It supports integration with a wide range of monitoring, CI/CD pipelines, and security solutions, allowing teams to continue using their preferred tools while leveraging Qovery's automation and management capabilities.

What makes it special: With Qovery, teams can provision and maintain secure cloud infrastructure in hours, not months. It offers features such as environment provisioning, developer self-service tools and cost optimization.

Mia Platform logo

Mia Platform

The Leading Platform Builder for Cloud Native at Scale

Mia Platform is a comprehensive platform that aims to cover the full lifecycle of your applications on Kubernetes with smooth developer experiences.

Mia-Platform simplifies the development process with built-in CI/CD pipelines, eliminating the usual complexity of setup and automating processes to accelerate software delivery.

With a rich catalog of prebuilt microservices and built-in orchestrators for managing them, it speeds up development by allowing you to use the industry standard services out of the box and focus on developing your own product-specific ones.

Mia-Platform also provides clear API management, helping you with design, security, versioning, and retirement. With an API portal, you can simplify the process of establishing new partnerships by making APIs easily accessible.

With a built-in Developer Portal, your development teams have the entire lifecycle of their Kubernetes applications centralized in one place. The portal provides them with easy access to their app's health, resource usage, relevant documentation, etc.

What makes it special: Mia-Platform stands out by offering an all-in-one platform for managing the entire lifecycle of cloud-native applications. It simplifies development with a self-service Internal Developer Platform, built-in CI/CD pipelines, and a catalog of ready-to-use microservices.

Porter logo

Porter

Platform as a Service, Reimagined

Porter is a platform that deploys applications into your own cloud account with just a few clicks. It automates infrastructure provisioning on AWS, GCP, or Azure and makes it easy to deploy, manage, and scale applications on Kubernetes.

Porter simplifies infrastructure provisioning by connecting directly to your cloud account. With minimal effort, it spins up a Kubernetes cluster along with essential infrastructure like VPCs, load balancers, and image registries.

Deployment is equally straightforward - by linking your Git repository, Porter handles building your application using Dockerfiles or Cloud Native Buildpacks and setting up CI/CD via GitHub Actions, which can be customized later to fit your workflow.

Porter continuously monitors your Kubernetes cluster to ensure smooth performance and scalability, keeping track of both your application metrics and logs. If any critical issues arise, Porter will send alerts to notify your team.

What makes it special: Porter focuses on enabling startups and small teams to leverage production-ready Kubernetes infrastructure right out of the box, without needing deep DevOps knowledge.

Before You Go

Thanks for reading! I hope this overview helped you orient yourself in the developer platform landscape. While these are not the only players on the market, they are a great starting point for you to explore. If you enjoyed this article and are looking forward to more blogs on developer platforms, open-source and Kubernetes-related topics, remember to show your support by starring our repo ⭐🙏

· 5 min read
Juraj Karadža

Platform Engineering

Modern software engineering is becoming more and more complicated, especially in cloud-native environments like Kubernetes. There are countless moving parts and pieces and no two applications are built the same.

The larger the company, the more moving parts there are. With more moving parts, development cycles become stretched, onboarding developers takes longer, and the chances of mistakes increase. Because of this, companies stagnate and become slower to innovate and push new products and features.

The modern answer to this problem is Platform Engineering and, according to Gartner, 80% of software engineering organizations will establish platform teams by 2026.

In this blog we will discuss what platform engineering is and what can you do to stay ahead of the curve…

Support us 🙏

We know that Kubernetes can be difficult. That is why we created Cyclops, a truly developer-oriented Kubernetes platform. Abstract the complexities of Kubernetes, and deploy and manage your applications through a customizable UI that you can fit to your needs.

We're developing Cyclops as an open-source project. If you're keen to give it a try, here's a quick start guide available on our repository. If you like what you see, consider showing your support by giving us a star ⭐

Support us with Github stars

What is platform engineering?

Platform engineering acts like an internal product team, but instead of serving external customers, its primary users are the company's own developers and internal teams.

The job of platform engineers is designing and building toolsets, infrastructure, and workflows that make it easier for developers to build, test, deploy, and manage software. The goal is to create a unified platform, often called an Internal Developer Platform (IDP), which provides developers with self-service access to everything they need without depending on other teams, like operations or DevOps.

Why platform engineering?

“The goal of Platform Engineering is to allow as much speed as possible, with as much safety as possible” ~ Jason Warner, CEO @ poolside, former CTO @ GitHub (source)

Platform engineering creates an abstraction layer that simplifies infrastructure management for developers. Instead of dealing with the complexities of infrastructure, developers can focus on writing code, leading to quicker onboarding and faster time to market.

A good IDP enables separation of concerns. Most of the time your DevOps teams and Product teams do not need to talk to each other and they can move independently. It also provides guard-rails and ensure standard and secure practices across the organization.

Fun fact: when Spotify built its own Internal Developer Platform (now known as Backstage) they realized that their developers were 5% more likely to stay at the company one year later. Developer experience matters!

Internal Developer Platforms (IDPs)

When it comes to Internal Developer Platforms (IDPs), you typically have two options: build one yourself or buy an off-the-shelf solution.

Building your own may seem like the ideal choice. You can tailor it perfectly to your specific needs, ensuring it integrates with your existing tech stack, workflows, and infrastructure. However, building an IDP from scratch is both time-consuming and expensive, it’s essentially a full product in itself. For this reason, custom-built platforms are typically reserved for larger organizations with the resources to invest in such an undertaking.

On the other hand, off-the-shelf platforms offer a quicker, more affordable alternative. These platforms are designed to cater to a wide range of users and needs, which can be both a blessing and a drawback. You may end up with features you don’t need or find key functionality missing. In the latter case, you’re dependent on the vendor’s roadmap, which may not prioritize your needs. While they provide immediate value and are a solid starting point, you have to keep in mind that your organization will eventually outgrow them as your requirements evolve.

But, at Cyclops, we are building something in between…

Cyclops

Cyclops is an open-source tool that bridges the gap between fully custom-built Internal Developer Platforms (IDPs) and off-the-shelf solutions. It enables you to build IDPs for Kubernetes in hours instead of months, providing the flexibility to tailor the platform to your specific needs without the high cost and time investment of building from scratch.

Cyclops logo

Cyclops enables your Platform teams to build custom user interfaces for configuring and deploying applications and services to Kubernetes clusters. It leverages Helm charts (learn more here) to generate these UIs. You can easily import any of your existing Helm charts into Cyclops as templates and create a user-friendly interface tailored to your specific needs.

Define Module in Cyclops

The fields shown above are entirely customizable along with the validations. Cyclops allows you to define how much of configuration you want to expose to your developers, while the validations you put in place prevent them from making mistakes.

Module Overview in Cyclops

After a developer has configured the application, with a click of a button it is deployed to the cluster. Cyclops then displays all resources related to the application, offering easy access to relevant information, including logs, health checks, and status updates.

In a nutshell, Cyclops lets you provide the guard rails for your developers to safely deploy their application to Kubernetes and then overview the status of their apps.

Looking for more?

Thanks for reading! In future blogs you can expect us going more in depth on Cyclops and how you can create some pretty fun stuff with it. If you enjoyed this article and are looking forward to more, remember to show your support by starring our repo ⭐🙏

· 8 min read
Juraj Karadža

Civo x Cyclops

Whether you are new to Kubernetes or maybe you're part of a startup that's always short on time, this guide is for you. Kubernetes is an incredibly powerful tool for managing containerized applications, but it's also notorious for its complexity and steep learning curve.

And if you're running a startup, you probably don't have the luxury of spending days (or weeks) wrestling with configuration files and cloud infrastructure. Setting up a Kubernetes cluster can feel like a daunting task, but it doesn't have to be.

This article will show you how to quickly spin up a Kubernetes cluster in the cloud and deploy your applications in just minutes. And we're making it a speedrun! In less than 10 minutes, you'll have everything up and running, including your own software.

Start your timers! ⏳

Support us 🙏

We know that Kubernetes can be difficult. That is why we created Cyclops, a truly developer-oriented Kubernetes platform. Abstract the complexities of Kubernetes, and deploy and manage your applications through a customizable UI that you can fit to your needs.

We're developing Cyclops as an open-source project. If you're keen to give it a try, here's a quick start guide available on our repository. If you like what you see, consider showing your support by giving us a star ⭐

Support us with Github stars

What is Civo?

Civo is a cloud service provider that allows you to quickly spin up Kubernetes clusters - it takes about 90 seconds to get it up and running! If you have ever tried spinning up a cluster on other cloud service providers (AWS, I'm looking at you 👈), it will be a refreshing experience to see how easy and fast it is with Civo.

Although Kubernetes is not Civo's only service, this article will mainly focus on it as it is the fastest setup I've encountered (apart from local setups).

How to spin up a Kubernetes cluster with Civo?

The first step is to create an account on Civo (obviously 🫴). If it's your first time trying out Civo, they will provide you with $250 worth of credits! You can follow along for free and work with a real Kubernetes cluster running in the cloud. Even if you do not have the credits anymore, Civo will tell you the monthly cost of running your cluster, so you do not have to dread receiving the bill at the end of the month 😅

Once you have created your account, you should be greeted with the Civo dashboard. To set up your cluster, click the "Launch a new cluster" button or go to the Kubernetes tab, where you will find a similar button.

You will be taken to a screen that lets you customize the specifics of your cluster. Here, you can choose how many nodes you want, what sort of nodes (Standard, Performance, CPU Optimized, or RAM Optimized), firewall configuration, cluster type…

In the spirit of a speedrun, I'll leave it all on the default values (except the name, which I wanted to fit the theme 😁).

Configure the Civo Kubernetes cluster

But before launching your cluster, let's stop at the Civo Marketplace (on the same screen). The Marketplace has lots of tools that can help you in various ways, and they will be deployed to the cluster upon its creation so you can use them instantly.

Under the Management tab, you can find Cyclops UI. Cyclops will allow you to deploy your apps to the cluster without any extra configuration. It only requires you to have a docker image of your apps. And Cyclops is open-source, so it won't impact your Civo bill!

You can select to install Cyclops just by clicking on it, and it should have the blue checkmark as it does on the image below.

Cyclops on the Civo Marketplace

Now that we have configured our cluster and included Cyclops, let's launch it! Click the "Create cluster" button on the bottom of the screen, and let's go!

How to access your Kubernetes cluster?

After less than 2 minutes ⏳ (you can see the countdown when the cluster is being created), you will have your cluster up and running. You will talk to the Kubernetes API in that cluster to access it. For this, we will be using the terminal, but only a couple of commands will be needed before we can start deploying our applications.

The first thing is to install kubectl (you can find how to install it here). kubectl is the Kubernetes command-line tool used to interact with your cluster.

Once you installed kubectl, download the Kubeconfig file of your cluster. You can find it in the Cluster Information section.

Download Kubeconfig

Once downloaded, which takes about a second or two ⏳, go to your terminal and type in the following command:

export KUBECONFIG=<insert-path-to-the-downloaded-kubeconfig-file>

To check if we set the Kubeconfig correctly, run any kubectl command and see if it's interacting with the right cluster. For example:

kubectl get pods

NAME READY STATUS RESTARTS AGE
install-traefik2-nodeport-ku-4b5zn 0/1 Completed 0 1m
install-cyclops-kubernetes-s-md5mz 0/1 Completed 0 1m

Our Kubernetes cluster is up and running, but now we want to use it and deploy our applications to it, and for that, we will be using Cyclops.

What is Cyclops?

Cyclops is an open-source tool that allows you to deploy your applications through a UI, hiding all of the complexity of Kubernetes.

The UI is highly customizable and is generated from Helm charts (read more about it here). You can use any of your existing Helm charts, import them into Cyclops as templates, and get a UI made for your specific use.

For now, we will be using the default templates that all Cyclops instances get out of the box (it is a speedrun, after all ⏳)

Deploying Applications to Kubernetes

We selected Cyclops in the Marketplace when creating the cluster, so it should already be installed. To access it, run the following command from the same terminal as before:

kubectl port-forward svc/cyclops-ui 3000:3000 -n cyclops

⚠️ It is important to run this command from the same terminal as before because, with the first command, we set the context of the terminal to be able to access our Kubernetes cluster in the Civo cloud.⚠️

If you have configured the Kubenconfig correctly, the port-forward command will allow us to access Cyclops's UI from our browser.

To access it, go to https://localhost:3000, and you will be greeted with an empty dashboard. To deploy your application to the cluster, click the "Add module" button in the top right corner. You should be taken to a screen where the first step is to choose a template.

Feel free to use the existing templates or you can import your own (read more about it here). I will use the demo template for this guide as it is the simplest. I name my new module (in the theme of the article) and use the default values for the rest of them. If you want to deploy your own application, use your docker image (with the correct version underneath) in the image field.

Download Kubeconfig

To deploy your application, click "Save"!

Cyclops will use the values you specified on the previous screen and, based on the template you used, will create all the necessary resources your application needs. You never had to even look at configuration files! After a couple of seconds ⏳ (depending on the docker image you used in the image field), your application should be up and running.

Download Kubeconfig

Now you can access your app with a port-forward command (in a similar way that we access Cyclops), and that’s it ⌛

kubectl port-forward svc/speedrun 3001:80

Time’s Up ⌛

If you followed along, you should have been able to deploy your application to a Kubernetes cluster running in the Civo cloud - in under 10 minutes!

We used the default setup for Civo and for Cyclops. This setup can be vastly improved by using more powerful nodes or adding more of them - all of this can be configured when creating the cluster in the Civo dashboard!

And the demo template that I used in Cyclops is just a simple example of what it can do for you. Play around with other templates and try to make your own. Cyclops was made to quickly and easily create developer platforms that hide the complexities of Kubernetes from developers. It brings the developer experience of big tech to companies of any size.

If you enjoyed this guide, show us your support by starring our repo

· 5 min read
Juraj Karadža

how-we-manage-secrets-cover

For the past few days, we at Cyclops have been walking between the whiteboard and our laptops, trying to figure out how to design one important part of our project: the authentication of Cyclops to different services. To be more precise, we wanted to allow users to access their private GitHub repos through Cyclops.

Why was this an issue? In the beginning, we were torn between solutions that either bloated the codebase by adding a database that Cyclops would not use apart for the authentication or made the onboarding process overly complicated and scare away potential new users.

After some brainstorming, we found a solution that checked all of our requirements. In this article, I will showcase how Cyclops manages your secrets, the Kubernetes way…

Why did we need to manage secrets?

A short background about Cyclops so the rest of the article is easier to follow:

Cyclops is a developer-oriented Kubernetes platform. Instead of making your devs learn Helm, Kustomize, or some other Kubernetes configuration manager, Cyclops provides a user interface where they can easily fill in the values to generate needed Kubernetes manifests.

We say it's a platform because you can easily create custom UIs for your Kubernetes workloads (read more about it here). You would store these UIs as templates. You can store templates in several ways, like Helm charts or OCI repositories, but the most popular is probably GitHub repositories.

Cyclops can access templates stored in public repos without issues; provide a repo + path + version, and BAM, you got it. But we wanted to enable Cyclops users to access the templates they stored on their private GitHub repositories (because you rarely make your infra code public).

We knew we could use GitHub tokens as a form of authentication, but how do we securely handle them?

By the way…

Cyclops is open-source, we would greatly appreciate it if you could support us by giving us a star on our repo ⭐ 🙏

github-stars

Kubernetes Secrets

The first issue was storing the GitHub access tokens. Cyclops does not have a database of its own, so implementing one just for storing GitHub tokens seemed like a bad idea. So, we opted to use Kubernetes secrets.

A Secret is an object that contains a small amount of sensitive data, such as a password, a token, or a key.“ ~ Kubernetes docs

Kubernetes secrets are a great way of storing sensitive data (like tokens) without exposing it in the pod definition or configuration files, so they seemed like a great fit.

However, the second issue was how to use these secrets securely.

Kubernetes Custom Resources (CRDs)

Let’s quickly discuss custom resource definitions and then we can go on to how we implemented access to private repos.

In Kubernetes, Custom Resource Definitions (CRDs) let you create your own resource types, adding to the default ones Kubernetes provides (pods, deployments, …).

You can define a schema for your custom object with a YAML file and inform Kubernetes. From then on, you can use your custom resource as any other native Kubernetes resource.

Check out our previous blog, where we explore CRDs and use kubectl to gather apples!🍏

kubectl get apples

NAME AGE
green-apple 6s

How we manage secrets, the Kubernetes way

Cyclops has a CRD called TemplateAuthRule that allows you to define authorization for specific repositories. The CRD defines which templates you want to authorize and points Cyclops to the authorization data needed for those templates (Kubernetes secrets).

Each time the Cyclops controller fetches a template, it retrieves all TemplateAuthRules from the cluster and tries to match the templates repository to any of the TemplateAuthRules repositories (in the picture below spec.repo). If it does, it will fetch the referenced Kubernetes secrets and apply username and password to authenticate.

tar_arch.png

In the image above, the Cyclops controller fetches all TemplateAuthRules and tries to match the template repository to spec.repo from a TemplateAuthRule. If it matches, it will fetch the username and password from the referenced secret. In this case, both username and password reference the same secret my-cyclops-secret (spec.username.name and spec.password.name).

To fetch the username secret value, the Cyclops controller will fetch the referenced secret and use the key provided in spec.username.key to get the value from the fetched secret. The same goes for the password.

Since TemplateAuthRulesdoes not store secrets directly, you can still integrate your cluster with the External Secret Operator or other secrets management solutions!

Find a more detailed view into TemplateAuthRules and a tutorial on how to allow access to your own private repos here or by using our CLI here

Any questions?

Hope I managed to explain how Cyclops manages your GitHub tokens and maybe even given you an idea of how to manage secrets in your own projects.

If you are interested in being a part of the Cyclops community, to contribute with code, content, or even critique, be sure to join our Discord community and leave a star on the repo ⭐ 🙏

· 7 min read
Juraj Karadža

what-the-helm-cover

Kubernetes applications rarely (if ever) consist of a single resource. In a basic example, you have a deployment running your app and a service to expose its functionality. This requires you to either have one manifest containing the definitions of both the deployment and service or two separate manifests (one for each resource).

Now, imagine you have multiple apps that require multiple manifests to run. To make managing them easier, you will want to group them together in logical units (or packages).

Further, when running microservices, many of these manifests will look very similar, often differing only by a couple of values or lines. As you can imagine, this can quickly become cumbersome to manage.

This is where Helm steps in. While Helm is not new to the scene, in this article, I will show you its benefits and how to improve the Kubernetes experience even further with something a bit newer…

Support us 🙏

We know that Kubernetes can be difficult. That is why we created Cyclops, a truly developer-oriented Kubernetes platform. Abstract the complexities of Kubernetes, and deploy and manage your applications through a UI. Because of its platform nature, the UI itself is highly customizable - you can change it to fit your needs.

We're developing Cyclops as an open-source project. If you're keen to give it a try, here's a quick start guide available on our repository 🔗. If you like what you see, consider showing your support by giving us a star ⭐

github-stars

What the Helm ?!

Helm helps you manage Kubernetes applications — Helm Charts help you define, install, and upgrade even the most complex Kubernetes application.

This is a quote directly from the Helm website 🔗, let’s “unpack” what it means…

Package manager

Helm is often called the package manager for Kubernetes because it allows you to group multiple connected manifests that create an application into a Chart (package), making them easier to maintain.

A chart’s structure looks something like this:

my-chart
├── Chart.yaml
├── values.yaml
├── values.schema.json
└── templates
├── deployment.yaml
└── service.yaml

A chart can contain additional files, but these are the essential ones (for example, a README.md perfectly aligns with Helm's definition of a chart).

The Chart.yaml file could be considered “metadata” of the package, containing some basic information like name, version, maintainers…

In the /templates directory, you will find all the resources that make up your application. All the manifests are grouped here (in this example, it's just a deployment and service).

Instead of using kubectl and applying these resources separately, charts allow you to package them together and install them into your cluster with a single command.

One of the big things that made Helm so popular was the public charts repositories(like ArtifactHub 🔗 or Bitnami 🔗). This allowed people to use complex configurations others made. Many companies publish and maintain helm charts of their own software so people can easily install them in their clusters.

Templating engine

The second big feature of Helm is the templating engine. In the structure above, you probably noticed the values.yaml file. To understand why it's here, let’s actually look at our deployment.yaml. It can look something like this:

apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: {{ .Values.image }}
name: {{ .Values.name }}
spec:
replicas: {{ .Values.replicas }}
selector:
matchLabels:
app: {{ .Values.name }}
template:
metadata:
labels:
app: {{ .Values.name }}
spec:
containers:
- image: {{ .Values.image -}}:{{ .Values.version }}
name: {{ .Values.name }}
ports:
- containerPort: 80
name: http

You will notice it looks a bit different than your normal deployment manifest (like the one you can find on the Kubernetes documentation 🔗).

This is actually a blueprint. Helm allows you to create blueprints with placeholders - {{.Values.image}}. The values for these placeholders are defined in the values.yaml file.

For example, values.yaml might contain:

name: my-app
image: nginx
version: 1.14.2
replicas: 1
service: true

Imagine you have multiple microservices that all use *almost*** the same YAML manifest, apart from a couple of lines or values. For example, they differ only in the image. Helms' templating engine allows you to use the same blueprint for all your microservices and customize the specific details using the values.yaml file.

So, if you have several microservices, you don’t need to write separate YAML files for each one. Just create a template and adjust the values.yaml for each microservice as needed.

The Developer Experience

While packages and blueprints help when dealing with large manifest files, changing values in such a structure can still be an issue for inexperienced developers. If you look again at the values.yaml file from above, you can easily see how someone can mistakenly type the string “true” instead of boolean true, or even integer 1. It's an honest mistake, but it can cost you hours and hours of debugging time.

That is where values.schema.json comes into play. In this file, Helm lets you define the type of values and their limitations - essentially providing validations for the values.yaml. This makes it harder for developers to make mistakes similar to the ones mentioned above.

But the values.yaml from above is a pretty simple example. You will usually find much larger files with many more values (finding your way here 🔗 will take some time 😅).

And this is where Cyclops 🔗 lets you take the developer experience even further. Cyclops lets you define a UI that hides the complexities of large templates and allows you to define which fields your developers are exposed to.

cyclops

The screenshot shows the Helm chart I used as an example before but now rendered in Cyclops. You can mold this screen to fit your needs, with many more (or fewer 😊) fields, allowing inexperienced devs to feel confident when deploying their applications in Kubernetes.

And the validations haven’t been lost with Cyclops, far from it → now they are shown instantly.

The great thing about Cyclops is that if you are already familiar with Helm, creating a UI for your use case is quick and simple because Cyclops renders the UI based on the values.schema.json.

To clarify, you can import your own (already existing) Helm charts to be rendered in Cyclops! If you are storing your charts on a private repo, check the documentation 🔗 to see how to connect it securely.

Cyclops is open-source, so give it a go!

Open Source Fiesta

Helm is one of the most popular ways of handling Kubernetes configurations. It is a graduated project in the CNCF 🔗, maintained by the Helm community 🔗. The project is open-source, and its GitHub repo 🔗 has more than 26K stars and around 670 contributors - a testament to the size of the community around it. e

While Cyclops is a relatively new project compared to Helm, it is following in its footsteps. Cyclops has already been accepted into the CNCF landscape and has a fast-growing community around it.

Hope it helps 🙌

Thanks for reading the article. I hope you found it useful. If you wish to be a part of the Cyclops community, to contribute with code, content, or even critique, be sure to join our Discord community 🔗 and leave a star on the repo 🔗

· 4 min read
Juraj Karadža

why-are-clis-important-cover

Command Line Interfaces (CLIs) seem old-fashioned in the age of graphical user interfaces (GUIs) and touchscreens, but they remain essential tools for developers. You may not realize it, but they are used far more often than you might think. For example, if you use git commands over the terminal, you're likely engaging with a CLI on a daily basis.

To give you some background, I work on Cyclops, a tool that provides a graphical user interface for developers to configure and deploy their applications in Kubernetes. Given my employment, why would I, of all people, emphasize the importance of command-line interfaces?

Support us 🙏

We know that Kubernetes can be difficult. That is why we created Cyclops, a truly developer-oriented Kubernetes platform. Abstract the complexities of Kubernetes, and deploy and manage your applications through a UI. Because of its platform nature, the UI itself is highly customizable - you can change it to fit your needs.

We're developing Cyclops as an open-source project. If you're keen to give it a try, here's a quick start guide available on our repository. If you like what you see, consider showing your support by giving us a star ⭐

github-stars

Why CLIs 🤔

Command-line interfaces (CLIs) are incredibly fast for getting things done. They let you perform actions with simple, direct commands, which is especially useful for repetitive tasks. For example, you can search for files or oversee the various programs and services running on your computer with just a few commands. However, this speed is only accessible to those who know the necessary commands.

CLIs also enable fast remote access to machines and servers. Using tools like SSH, you can connect to remote systems from anywhere, allowing you to maintain servers that aren’t physically nearby. Plus, because CLIs are lightweight, they use minimal bandwidth, making remote operations more efficient and reliable.

These are great benefits of having a CLI, but why would Cyclops be interested in developing one? The answer is automation.

Automation and CI/CD ⚙️

When I talk about automation, I mean writing scripts to handle repetitive tasks, ensuring they are done the same way every time, saving a lot of time. You can automate everything from simple file operations to complex deployments. Automations boost efficiency and reduce the chance of human error since the scripts perform tasks consistently every time they run.

Automation is a standard practice in the software development lifecycle (just think of GitHub actions). If Cyclops had a CLI, it would allow it to integrate into larger systems for deploying applications, like CI/CD pipelines.

You could use Cyclops’s UI to make it easier for developers to configure and deploy their applications in Kubernetes clusters, and a CLI would allow you to automate any part of that process.

For example, once you create a template and publish it on GitHub, GitHub actions could automatically connect the template to your Cyclops instance using our CLI. This would allow your developers instant access to each new template or even any update the template receives. More on automation in future blog posts… 😉

Cyclops CLI - cyctl 🔅

We didn't want to miss out on the advantages of a CLI, but initially, we struggled to find the time to develop it. However, our community has grown significantly over the past few months, and since we are an open-source project, we began opening issues to kickstart the development of our CLI.

Thanks to our amazing community, we realized that our CLI was closer to realization than we had thought. And just a couple of days ago, Homebrew received a new package - our very own cyctl!

cyctl

Open Source Magic ✨

We are very proud to say that cyctl is a community-driven project. While the Cyclops team has been overseeing every change and reviewing every PR, most of the features have been developed by our contributors!

If you're excited about making Kubernetes easier for developers and want to contribute to our CLI or any other part of our project, we’d love to have you on board. Come join us on Discord to connect, collaborate, and be a part of something great!

And if you enjoyed this post, we would be grateful if you could star our repo ⭐ 😊

· 6 min read
Juraj Karadža

k8s-easy-start-cover

They say the first step is always the hardest. And when that step is in the direction of Kubernetes, it can feel even more intimidating. You can sometimes feel "paralyzed" by the sheer number of things you don't understand. Or better said, you don’t understand yet.

But once the first step is conquered, the rest feels more attainable. So, let’s take the first step together. Oh, and we'll be using a couple of tools to help us out. After all, we are trying to make this as simple as possible 😉

Support us 🙏

We know that Kubernetes can be difficult. That is why we created Cyclops, a truly developer-oriented Kubernetes platform. Abstract the complexities of Kubernetes, and deploy and manage your applications through a UI. Because of its platform nature, the UI itself is highly customizable - you can change it to fit your needs.

We're developing Cyclops as an open-source project. If you're keen to give it a try, here's a quick start guide available on our repository. If you like what you see, consider showing your support by giving us a star ⭐

github-stars

A Cluster 🌐

The first thing you need to get started with Kubernetes is a cluster. Typically, a cluster represents the pool of servers on which you run your apps. But for now, you don’t need a pool of servers. Let’s start with something simple: a local playground that will help us get the hang of it.

One of the easiest ways to quickly get a cluster running is with Minikube. Minikube is a tool that sets up a local Kubernetes cluster on your computer. It’s perfect for development and testing purposes. To get started, you need to:

  1. Install Docker: docker will allow us to run Minikube in an isolated environment, you can find out how to download it here
  2. Install Minikube: Follow the instructions on the Minikube site to install it on your machine.
  3. Start Minikube: Once installed, you can start your local cluster with the command:
minikube start

This will set up a single-node (single-server) Kubernetes cluster on your machine.

The Configuration 🗄️

This is usually the trickiest part of working with Kubernetes. For Kubernetes to run your application, you must create a configuration file that tells Kubernetes how to handle your application. These files are traditionally written in YAML and follow their own syntax and rules.

But here’s the good news: Cyclops lets you skip this process entirely.Cyclops is an open-source tool that provides a user-friendly interface for configuring your applications to run in Kubernetes.

The UI that Cyclops provides is highly customizable when it comes to defining your configurations through its templates feature. It also comes with a couple of predefined templates to get you started on your journey.

Cyclops is simple to set up and requires just two commands:

kubectl apply -f https://raw.githubusercontent.com/cyclops-ui/cyclops/v0.6.2/install/cyclops-install.yaml &&
kubectl apply -f https://raw.githubusercontent.com/cyclops-ui/cyclops/v0.6.2/install/demo-templates.yaml

and secondly:

kubectl port-forward svc/cyclops-ui 3000:3000 -n cyclops

Just wait a few seconds between these commands to let your Kubernetes cluster start Cyclops.

Now, head over to localhost:3000, and you should be all set!

cyclops-modules-screen

Running your App inside the Cluster 🏃

Once inside Cyclops, you’ll be greeted with a screen that says “No Modules Found.” Modules are Cyclops’s way of saying applications. The next step is running your application (module) in the Kubernetes cluster, or in Kubernetes terms, “deploying your application.”

Start by clicking on the Add module button at the top right. This will take you to a new screen where the configuration file from the last step will be generated.

Cyclops uses templates to generate the configuration file (find more about it here). You can create your own, but Cyclops comes with a few predefined templates that are perfect for getting started.

At the top of the screen, choose the demo-template. You’ll notice the screen changes, and new fields appear! Switching to another template will change the fields on the screen, but let’s stick to the demo-template for now.

You can leave the inputs in the fields as they are or change them to your liking, but you must give your module a name!

If you have a Docker image of an application that you created and want to run in Kubernetes, you can do that too! Just put the name of your image in the image field and its version in the version field.

cyclops-config-screen

Once you’re satisfied with these fields, click Save at the bottom, and voilà, your application is deployed!

Anatomy of an App 🫀

One of the challenges with Kubernetes is the variety of resources it uses. However, Cyclops makes it easy by displaying all the resources your modules have created. This visual representation really helps you understand the anatomy of your applications.

With our demo-template and the inputs we entered, we created a simple Kubernetes configuration consisting of a service and deployment, as shown on the screen. These are the two most common resources you will encounter and are a good entry point into the whole system.

cyclops-module-overview

The Cyclops interface displays all these components in a clear, organized manner, making it easy to understand how your application is structured and how the different pieces fit together.

For instance, you can see that the application named "my-app" is running on Minikube, with one replica of the Nginx container (version 1.14.2). You can view logs or modify settings right from this interface.

This visual approach helps bridge the gap between developers and Kubernetes' underlying infrastructure, making it easier to manage and understand your applications.

Next steps 👣

Now that you’ve broken the ice, Kubernetes feels a lot less scary. I suggest you play around with the other templates Cyclops provides and see how different templates create different resources.

The journey to mastering Kubernetes is long and can be tedious. However, you don’t have to walk that path alone! Join our Discord community and connect with others who can help you if you ever feel lost!

If you enjoyed this post, remember to support us by giving us a star on our repo