Hello there, In this blog we are going to make a custom template for Cyclops. So, that we can easily is full power of cyclops.
What is Cyclops?
Cyclops is an innovative web-based tool designed to simplify the management of distributed systems, specifically focusing on the widely used Kubernetes platform. By providing a user-friendly interface, Cyclops abstracts complex Kubernetes configuration files into intuitive web forms, making it easier for developers to deploy applications and manage Kubernetes environments. It offers predefined fields and graphical representations of deployments, enhancing visibility and reducing the learning curve associated with Kubernetes. Cyclops aims to empower IT operations teams, DevOps teams, developers and business owners, enabling them to streamline processes, increase productivity, and achieve cost savings in managing Kubernetes clusters. (Read More)
Now Let's install Cyclops locally to work with.
To run Cyclops locally we need following installed in our PC:
- Docker
- Minikube
- Kubernetes
- WSL (for windows)
If you have installed setup the environment then let's dive in running Cyclops instance.
-
Start Docker Service as per your OS.
-
Start minikube. Run the command given below in your terminal (for windows open WSL).
- Install Cyclops cluster (more info).
It will create a namespace callled Cyclops
and deploy everything you need for your Cyclops instance to run.
- Expose Cyclops Server outside the cluster.
Now you can open http://localhost:3000
in your browser to access Cyclops Dashboard.
How to Deploy servic
You can deploy any service by clicking to Add module
button and selecting your desire service in just few clicks.
How to create custom template
If you worked with Helm you will have great time using Cyclops because Cyclops is a wrapper on top of Helm.
You can create your custom template just like you create a template of Helm only thing you had to do is creating values.schema.json
. This file is important for cyclops to render UI related to configuration of the template.
Let's create template
We are going to create a simple template for MinIO. MinIO is a high-performance, S3 compatible object store.
- Create a folder to keep your files and create some files like this tree.
mino-io
│ Chart.yaml
│ values.schema.json
│ values.yaml
│
└───templates
deployment.yaml
pvc.yaml
secret.yaml
service.yaml
_helpers.tpl
Understand the structure
If you are from Helm background structure should be familiar to you. If not don't worry let's break it down.
Chart.yaml
This file will have the metadata like name, description and version of the template like
values.yaml
This file is very important because it contain the default values for a chart. These values may be overridden as Cyclops UI configuration changes. For our template it looks like
replicas: 1
username: minioadmin
password: minioadmin
storage:
size: 1Gi
service:
port: 9000
resources:
requests:
cpu: 100m
memory: 256Mi
limits:
cpu: 1000m
memory: 2Gi
We have value of replicas default to 1. default username and password, storage size, port and resources.
We can change these values from cyclops UI when we deploy the template. For that we need to create a file values.schema.json
values.schema.json
This file is a necessary component in your templates. This file is usually used to impose a structure on the values.yaml
file, but it is also crucial for rendering the GUI in Cyclops. The schema is represented as a JSON Schema
For our template it looks like this:
This file is self explanatory. We populated properties
of type object
and added required fields for More info.
Now Let's see inside /templates
folder.
deployment.yaml
This YAML configuration defines a Kubernetes Deployment
for a MinIO server using Helm templates. Let's break down each part of the configuration:
apiVersion and kind
apiVersion: apps/v1
: Specifies the API version used for theDeployment
resource.kind: Deployment
: Indicates that this configuration is for aDeployment
.
metadata
metadata
: Metadata about theDeployment
.name
: The name of the deployment is dynamically set using Helm templating, where{{ .Release.Name }}
refers to the release name provided in theChart.yaml
file, appended with-minio
.
spec
spec
: Specifies the desired state of the deployment.replicas
: The number of pod replicas to run, which is dynamically set using filevalues.yaml
, defaulting to 1 if not specified.selector
: Defines how the deployment finds which pods to manage, using labels. Here, it matches pods labeled withapp: minio
.
template
template.metadata
metadata
: Metadata for the pod template.labels
: Labels to identify the pods, hereapp: minio
.annotations
: Additional information for the pod, using a checksum of the contents ofsecret.yaml
to ensure that pods are redeployed when the secret changes.
template.spec
spec
: Specification for the pod.containers
: List of containers to run in the pod.name
: Name of the container,minio
.image
: The container image to use,quay.io/minio/minio:latest
.command
andargs
: Command and arguments to run inside the container. Here, it runs the MinIO server with the console accessible at port 9090.ports
: Container port exposed,9000
.volumeMounts
: Mounts a volume to the container, withminio-data
mounted at/data
.env
: Environment variables for the container.MINIO_ROOT_USER
andMINIO_ROOT_PASSWORD
: Set from aConfigMap
specified byname: {{ .Release.Name }}-minio-config
.
template.spec.volumes
volumes
: Volumes to attach to the pod.name
: Name of the volume,minio-data
.persistentVolumeClaim
: References a PVC (Persistent Volume Claim) to use for storage, with the claim name set dynamically using{{ .Release.Name }}-minio-pvc
.
service.yaml
This file is used for creating a service endpoint for your deployment. For our template it is written as:
The service targets pods labeled with app: minio, forwards traffic from port 80 (or any other specified port) to port 9000 on the pods, and defaults to a ClusterIP type unless overridden by the provided values.
pvc.yaml
This file is used to create PersistentVolumeClaim
(PVC) resource for the MinIO deployment, allowing it to request persistent storage. This file is optional for the template we are using because we need managed persistent storage. Let's break down each part of the configuration:
This YAML configuration defines a Kubernetes PersistentVolumeClaim
(PVC) resource for the MinIO deployment, allowing it to request persistent storage. Let's break down each part of the configuration:
apiVersion: v1
: Specifies the API version used for thePersistentVolumeClaim
resource.kind: PersistentVolumeClaim
: Indicates that this configuration is for aPersistentVolumeClaim
.metadata
: Metadata about thePersistentVolumeClaim
.name
: The name of the PVC is dynamically set using Helm templating, where{{ .Release.Name }}
refers to the release name provided during the Helm chart installation, appended with-minio-pvc
.spec
: Specifies the desired state of the PVC.accessModes
: Defines the access mode for the PVC.ReadWriteOnce
: The volume can be mounted as read-write by a single node. This is suitable for scenarios where the volume does not need to be shared across multiple nodes.
resources
: Specifies the resource requirements for the PVC.requests
: Requests specific resources for the PVC.storage
: The amount of storage requested for the PVC. This is dynamically set, where{{ .Values.storage.size }}
refers to a value provided invalues.yaml
.
secret.yaml
This file will have the environment variables for secrets for service like API key, username, password. This file is very simple as:
Here inside data
we created to variables for MINIO_ROOT_USER
and MINIO_ROOT_PASSWORD
. values will get from GUI or default values we put thin values.yaml
.
At last We need a helper file to restart the service if these secrets change to reflect in deployment for that we will create _helpers.tpl
_helper.tpl
This file is completely optional for special condition like our template need to restart when values change. We need this file it includes:
It defines the function configmap-checksum
inside that calculates the SHA-256 checksum of the content of a file named secret.yaml
. The checksum is useful for tracking changes in the ConfigMap, allowing you to use it in annotations or labels to trigger pod redeployments when the ConfigMap content changes.
See in deployment.yaml
In annotations
. We are checking checksum/config for any changes if there is any change the it will restart the service automatically.
That's all we need to create a template we have successfully created our custom template. Check out GitHub repository of same template.
Now let's deploy with Cyclops for that there are ways of storing template. Cyclops can access charts stored in three different ways:
- GitHub Repository
- Helm Chart Repository
- OCI Repository
We are going to use GitHub Repository. Let's initialize our project with git
open terminal in your working directory where you stored your template and run
It will initialize your folder with git then run
To add all the files then commit with any message
Then push the code to GitHub
Remember you need to add origin to your repository More Info
Add template in Cyclops
To add template in cyclops go to Cyclops dashboard in templates tab.
click the Add template reference. A modal will appear asking you for a pointer to your template Read More.
Give Name to template in Name
.
Put GitHub repository URL in Repository URL
.
Enter the Path
where files are in our case it is /min-io
.
Enter the Version
which can be left empty / branch name / tag / commit hash.
Now Save, And goto Modules
Tab and click on the Add module button in the top right corner. Under Module template you will find your custom template with the name with which you saved it.
This was about how to create a custom template for Cyclops and deploy it.
Thanks Priyanshu Verma