A user-friendly dashboard for developers to leverage existing Kubernetes frameworks to deploy and manage applications.
When it comes to deploying applications to Kubernetes, the division of responsibilities between developers and infrastructure teams at various organizations is always an interesting (or contentious) topic. Some teams prefer their developers to fully buy into the DevOps ethos and own the entire stack. In this model, developers are expected to not only write their application code, but also the necessary Kubernetes components to run their applications. On the other end of the spectrum, I’ve also seen teams with embedded DevOps or SREs who take on this burden of writing Helm charts and owning everything after code has been merged into their main branch.
Obviously, the “best” option in dividing these responsibilities will depend on the makeup of your team, especially along their familiarity with Kubernetes concepts and/or their willingness to learn. The latter point is especially important as I’ve seen some developers simply refuse to touch anything YAML. The learning curve going from Docker to Kubernetes has always been a huge challenge.
The community has not been ignoring this problem either. In fact, there’s been many attempts to address this tension. Some tools have really focused on the templating and generation of Kubernetes manifests that developers can leverage. Others have focused more on developer environments to promote remote development and execution, and thereby having the developers interact with Kubernetes earlier in the development lifecycle. I’m also sure there are tons of internal tools that address some aspect of this problem in very opinionated means (as I can attest with lots of tools I’ve written in the past).
This brings me to an interesting new open-source project called Cyclops that takes yet another crack at this problem. I was able to speak with Petar Cvitanovic, who is one of the main contributors, and decided to give it a try.
What is Cyclops
Cyclops is a web-based tool that focuses on making Kubernetes deployment and configuration into a more developer-friendly experience. Instead of reinventing the wheel, Cyclops decided to adopt Helm charts that have been the de facto standard for packaging and supporting templatization. Cyclops takes in pre-built Helm charts and translates all those fields into a form that developers can easily adjust.
Instead of having developers override variables in YAML or via command line arguments, Cyclops exposes all those fields into a form that is easier to grok for developers. For most applications, developers simply have to change a few things: container image, service ports, configuration files, and secrets. Cyclops is targeting those use cases to streamline that process, although it can handle more complex applications as well.
Installing Cyclops
To give Cyclops a try, I spun up a minikube cluster and installed Cyclops using the following commands:
minikube start
kubectl apply -f https://raw.githubusercontent.com/cyclops-ui/cyclops/v0.0.1-alpha.5/install/cyclops-install.yaml
By default, Cyclops components are installed into cyclops namespace: cyclops-ctrl and cyclops-ui. The backend pod cyclops-ctrl takes a bit to come up so wait for the pod to be healthy. Then expose both the backend and the frontend locally (the frontend expects the backend to be available on localhost:8080).
kubectl port-forward svc/cyclops-ui 3000:3000 -n cyclops
kubectl port-forward svc/cyclops-ctrl 8080:8080 -n cyclops
Adding a Module
Cyclops groups Kubernetes deployments into what it calls as modules. Click the Add module button on localhost:3000 to create one.
Cyclops team has some templates that we can leverage on https://github.com/cyclops-ui/templates . We’ll load the demo from those templates and fill out the module details with a simple nginx container.
After clicking save, Cyclops will interpret those details and deploy those pods accordingly:
Note that any Helm chart is supported, but in order for Cyclops to work, you’ll need to provide a values.schema.json file in the following format: https://cyclops-ui.com/docs/templates/ .
Thoughts
Cyclops is an early stage Kubernetes tooling project with a limited set of features currently. However, that limited focus may actually be a benefit to some teams. Some of the more mature tools, by necessity, grow into a bloated tool to satisfy security, compliance, and various feature requests. But if you are looking for a lightweight tool for developers to quickly override templates in a familiar form format, Cyclops could be a better alternative.
It is important to note that Cyclops does make some assumptions about how you think of division of responsibilities. In order to use Cyclops effectiveness, some teams must first create the Helm charts and the schema file. If your team is more in the camp of “you write it then you own it”, then having developers buy into GitOps tooling might be sufficient. On the other hand, Cyclops caters to DevOps and infrastructure teams who want to expose a more curated experience for developers to interact with. You can control what fields the devs can override then they can use the Cyclops UI to view the basic status and logs.
I can see Cyclops being part of a good building block for teams looking to create an internal development platform. There are lots of commercial or large OSS projects dealing with cluster management, CI/CD, etc, but those may be overkill for local development setup or smaller developer platforms. Once Cyclops supports more templates (e.g., sample schemas that work with popular Helm charts like various databases or monitoring tools), it’ll be even more useful.
If you’re interested, check out Cyclops on Github: https://github.com/cyclops-ui/cyclops. The team is also very responsive to feedback, so create issues/comments for the team if you are looking to adopt Cyclops!
Top comments (1)
Cyclops looks really promising! In which stage is it today, what's next on the roadmap?