In One-Click you can create a new project or manage existing ones. Each project will get a unique ID which will be used to identify the project inside the Kubernetes cluster. The project will also get a unique namespace in the Kubernetes cluster which has the same name as the project ID.

Create a new project

To create a new project, log in to the One-Click platform and click on the top right corner New Project button. Fill in the project name and description and select a blueprint to use for the project. Click on the Create project button to create the project.

You can also set some labels for the project. Labels are used to group projects together and can be used to filter projects in the project list.

Manage existing projects

Each project has it's own overview page where you can see the details of the project and it's resources.

There will be a Kubernetes namespace each One-Click project with certain labels:

Overview

In the project overview, you can see all the deployments in this project. You can also navigate to the Blueprints, create a new Deployment or make some project settings. In the listed deployments you can see it's status, the ID of the current rollout, the amount of running replicas in the cluster and the current image deployed.

Project settings

In the project settings, you can change the project name, avatar and labels. You can also delete the project from the project settings which will also delete the namespace in the Kubernetes cluster.

Overview

In the deployment overview, you can see the counts of: rollouts, instances, interfaces, volumes, envs and secrets. You can also see the current container image. There is also a cpu and memory usage graph for the project. (keep in mind this is a live usage view, for tracking usage please use something like the )

On the scale page you can configure the two scaling options horizontal and vertical. The horizontal scaling is the number of instances (replicas) and the vertical scaling is the CPU and memory request and limit.

Horizontal

You can define the number of minimum and maximum replicas. The target CPU defines the autoscaling behaviour. If the CPU usage is above the target CPU the replicas will get scaled up. To get the current CPU usage you can head over to the deployment overview page.

Vertical

The vertical scaling is the CPU and memory request and limit. The request is the minimum amount of CPU and memory the pod will get. The limit is the maximum amount of CPU and memory the pod will get. If the pod exceeds the limit it will get terminated. The request and limit are defined in millicores and mega bytes. The limit should be equal or higher than the request.

Make sure to know your application requirements to set the right values. If you don't know the requirements you can start with the default values and monitor the behaviour. If you see that the pod gets terminated because of the limit you can increase the limit.

One-Click can run inside or outside of a Kubernetes cluster.

You will need the following to run OneClick:

• Kubernetes cluster

• Docker daemon

• Node.js v18.16.0 or higher

• v9.5.1 or higher

Installation

1. Install the Operator Follow the installation instructions provided in the or in the

2. Install the UI & Backend Check out the folder and change the values for your environment. Then run the following commands:

3. Access the UI

4. Access Pocketbase on your URL or localhost:8080 with /_ as the path. Example:

Head over to the docs to get more information why we use pocketbase and how you can adminstrate it.

Helm

Blueprints are stored configurations of a One-Click CRD. With these blueprints you can easily bootstrap new projects with no effort. The use cases are for example to predifine some enhanced configurations in your rollout crd yaml file which then get automatically applied when creating a new project out of this blueprint.

Overview

After you are logged into your One-Click account you can see the Blueprints button. When you click on this button you will get navigated to the blueprints overview page.

On this overview page you see your blueprints and also the one's from your community. These are blueprints other users in the same One-Click instance shared with you through a link.

When you click on the 3 dots of a blueprint you can "edit", "share" or "delete" the selected blueprint.

Sharing blueprints

When clicking on "share" in the action menu of a certain blueprint you will get a custom link:

Another user will get the following action when visiting the link:

He can also "unsubscribe" the blueprint again:

The user who shared his blueprint sees now the Shared count increasing and when hovering over the number he sees the users which added his blueprint:

Creating / Editing blueprints

You can easily create new blueprints by clicking on the "New Blueprint" button.

Only the owner of the blueprint can edit it again:

For the network, you have a few options to configure. You can define as many services and ingress interfaces as you want. The services are the internal Kubernetes services and the ingress is the external access to your services. To create a new network interface you can click the New Interface button.

You can define the following options:

• name: the name of the interface, must be unique in the deployment

• port: the port of the interface (take your application port, defined in the Dockerfile)

The map feature in a deployment uses svelte-flow to graphically show the resources of the current rollout in the selected deployment. Everything gets updated in real time via a websocket endpoint described in the pocketbase docs: Pocketbase

You can move the components with your mouse, zoom in and out and dig into its configurations / logs / events when click on a component.

Component Details

When clicking on a component you can see its current applied manifest in-cluster configurations. This will give you some more information about the component itself.

When selecting a pod you can also see it's logs directly streamed:

Also for the pod you can see the events which happen inside the cluster. This will also help you to troubleshoot your rollouts.

Deleting a pod

You also have the ability to delete a selected pod by clicking on the red trash icon.

Under images you can manage the image of the deployment. You can configure the registry (e.g. ghcr.io, docker.io), your username and password if it's private and also the repository/image. Last but not least you can define the image tag. If you need to debug something you can copy the current rollout ID to search the components inside the Kubernetes cluster.

Auto update

If you don't want to manually update your image tag each time you push a new version of your image to the registry you can activate the Auto Update feature. There you can specify an interval (1m, 5m, 10m), a pattern and policy how the image registry should get checked and the image should get updated.

• Interval: the cron ticker defined in the environment variable will check the modulo of the minutes and checks the registry in this interval. So it's crucial to let the cron tick interval at 1m as it is default.

• Pattern: a regex pattern which parses the image tag. The default is the default semver notation x.x.x

• Policy: the policy (semver or timestamp) defines the sorting. For timestamp it will only work if the image tag is a unix timestamp.

The behaviour and consept is similar to the one of fluxcd:

Examples

Each time you edit and change something in a deployment a new rollout will get created. This is like a snapshot of your configuration. This gives you the power to undo any changes you did to your deployment configuration like changing the port of an interface or updating your image tag. You can see every rollout in the rollouts table. Through the frontend you won't be able to delete a rollout, you can just hide it. This is due to get some statistics about you rollouts. If you need to delete a rollout completely you need to go to the pocketbase backend and delete the record in the "rollouts" collection.

Rollback diff

When selecting a previous rollout you can click on "rollback" and then a diff shows up which diffs the CRD files and show you exactly what will change:

On the envs & secrets page you can configure the environment variables and secrets for your application. The environment variables are key-value pairs that are injected into the container. The secrets are sensitive data that are stored as Kubernetes secrets. The secrets are base64 encoded and can be used as environment variables or mounted as files. You can simply copy and paste the content of your .env file or secret file into the text area.

Both the environment variables and secrets are available in the container as environment variables.

The following diagram shows how and what the One-Click operator manages.

In red you see everything responsible for the frontend / pocketbase backend. In blue you see everything which handles Kubernetes natively. In green you see what the One-Click operator manages and controls.

Every Kubernetes resource will get created and managed within a Kubernetes namespace named with the project ID

The architecture of the solution is designed to operate within a Kubernetes ecosystem, focusing on simplicity and manageability for deploying containers. Here is a high-level view of its main components:

• Frontend Component: Developed with Svelte, the frontend provides the user interface. Its primary role is to facilitate user interaction and input, which it relays to the backend for processing.

• Backend System: The backend, powered by Pocketbase, acts as the central processing unit. It interprets requests from the frontend, managing the necessary API calls and interactions within the Kubernetes environment.

• Kubernetes Cluster Interaction: The backend is responsible for orchestrating various elements within the Kubernetes cluster. A key function includes the creation and management of namespaces, segregating projects to maintain orderly and isolated operational environments.

• Custom Resource Management (Rollouts): Rollouts, defined as Custom Resource Definitions (CRDs) within Kubernetes, are managed by the backend. These are central to the deployment and operational processes, serving as bespoke objects tailored to the system's requirements.

• One-Click Kubernetes Operator: This component simplifies interactions with Kubernetes. It automates the handling of several Kubernetes native objects and processes, including deployments, scaling, and resource allocation. The operator is crucial for streamlining complex tasks and ensuring efficient system operations.

• System Scalability: The architecture is designed with scalability in mind, using Kubernetes' capabilities to handle a range of workloads and adapting as necessary for different project sizes and requirements.

This architecture aims to streamline the deployment process for OSS containers, offering an efficient and manageable system that leverages the strengths of , , and .

For persistent storage, you can define volumes. The volumes are the persistent storage for your application. You can define as many volumes as you want. To create a new volume you can click the New Volume button.

You can define the following options:

• name: the name of the volume, must be unique in the deployment

• mount path: the mount path of the volume (e.g. /data, /var/lib/mysql)

• size: the size of the volume in GiB (gibibyte)

• storage class: the storage class of the volume (the dropdown will show you the available storage classes inside the Kubernetes cluster)

One-Click uses the open source backend to achieve things like authentication and storing data. It also serves the frontend of One-Click. In the release process the pocketbase and frontend code will get compiled and put into a single container image and pushed to the Github container registry.

Pocketbase offers the ability to extend it with our own golang code. You can listen on certain events and then execute code. We use that to make the Kubernetes api calls and manage the Kubernetes resources created via the frontend interface.

You can find the code under the following link:

Authentication

Pocketbase uses JWT tokens for authentication. The frontend sends a request to the pocketbase backend with the user credentials. The backend then checks if the user exists and if the password is correct. If everything is correct, the backend will return a JWT token. The frontend will then store this token in the local storage and use it for every request to the backend.

For installing the One-Click operator in your Kubernetes cluster head to config directory inside the one-click-operator repository: https://github.com/janlauber/one-click-operator/tree/main/config

The development of the Kubernetes operator, housed in the "one-click-operator" repository, involves multiple key components and processes. Central to this is the rollout_types.go file, where the structures for the Rollout Custom Resource Definition (CRD) are defined. These structures are crucial because they dictate the configuration and capabilities of the Rollout CRD. The operator-sdk, known for its user-friendliness, is then used to generate corresponding YAML files. These files are stored in the "config" folder, signifying their role in configuring the operator.

The operator is designed with a specific domain, "one-click.dev", and uses the API CRD version "v1alpha1". This versioning indicates that the operator is in its early stages of development and is not yet considered production-ready—a common practice in the Kubernetes community. For guidance on best practices in developing Kubernetes operators using the operator-sdk, resources are available at https://sdk.operatorframework.io/docs/best-practices/best-practices/.

Following the CRD definition, the next step involves the implementation of the operator's logic. This is where the concept of abstraction becomes pivotal. The operator aims to simplify the management and creation of various Kubernetes objects by consolidating them into a single CRD— the Rollout CRD. This abstraction is particularly beneficial for the backend of the One-Click platform, as it reduces the complexity of managing multiple Kubernetes resources. Instead, the platform can focus on managing just the Rollout CRD.

The Kubernetes objects included in this abstraction are:

• Deployment

  • Environment Variables

  • Volumes

  • Image Pull Secret

• Horizontal Pod Autoscaler

• Secret

• Persistent Volume Claims

• Services

• Ingresses

• CronJobs

• Service Account

Each of these components plays a vital role in the Kubernetes ecosystem, contributing to aspects like deployment management, security, scaling, and connectivity.

In the "controllers" folder, you'll find the rollout_controller.go file, which is integral to the operator's functionality. This file contains the Reconcile() function, a critical component that interacts with the Kubernetes API. The Reconcile function acts as the heart of the operator, responding to changes and ensuring that the desired state of the Kubernetes objects is maintained. For each Kubernetes object listed above, separate Go files are created. These files encapsulate the specific logic required to manage each object, thereby modularizing the code and making it more manageable and maintainable.

To further elaborate on the Kubernetes operator development, let's delve deeper into the Reconcile() function and the concept of the owner functionality.

CI

Each CI/CD pipeline has its own syntax and configuration. Below are examples for GitHub Actions and Gitlab Pipelines.

Github Actions

Gitlab Pipelines

Dockerfiles

There are many ways to write a Dockerfile. Below are examples for Streamlit, Golang and Remix.js

Streamlit

Golang

Remix.js

Node-Red

Node-RED is a programming tool for wiring together hardware devices, APIs and online services in new and interesting ways.

Pocketbase

Pocketbase is an open-source, self-hosted firebase alternative.

Ghost

Ghost is a professional publishing platform. In production, you should use a mysql database. This is an example of a multi-deployment setup with MySQL and Ghost.

MySQL

Ghost