Merge pull request #16 from janlauber/14-create-update-delete-rollouts

The big implementation.

README.md

@@ -1,2 +1,3 @@
 # one-click
+
 One-Click Deployment interface for a curated catalogue of applications.

docs/decisions/0009-demo-app-streamlit copy.md

@@ -0,0 +1,24 @@
+# Project Management
+
+Date: 16.12.2023
+
+## Status
+
+Accepted
+
+## Context
+
+We try to build a demo app on a certain framework to show the capabilities of one-click. We need to decide which framework we will use:
+
+- [Reflex.dev](https://reflex.dev/)
+- [Streamlit](https://streamlit.io/)
+- [Gradio](https://gradio.app/)
+
+## Decision
+
+I've tried all three frameworks and I think Streamlit is the best choice for our demo app. It is easy to use and has a lot of features. It is also easy to deploy and has a lot of integrations.
+Also the build process of the Docker image is very easy. The demo app will be a reporting tool which we will use in our company.
+
+## Consequences
+
+Now we can start to build the demo app on Streamlit. We can also start to build the Docker image for the demo app.

docs/decisions/0010-no-mockups.md

@@ -0,0 +1,20 @@
+# Project Management
+
+Date: 16.12.2023
+
+## Status
+
+Accepted
+
+## Context
+
+We need to get the prototype ready for the end of the project. We don't have a lot of time to design mockups in figma.
+
+## Decision
+
+We won't use mockups to build the whole frontend of the prototype.
+
+## Consequences
+
+We will build the prototype without mockups to save time and prevent us from getting stuck in the design process.
+In the following up bachelor thesis we will get some feedback from users and improve the design and UX of the prototype.

docs/decisions/index.md

@@ -13,3 +13,5 @@ This directory contains the decisions made by me for this project. The decisions
 - [0006 Applications Exclusion](0006-applications-exclusion.md)
 - [0007 Kubernetes Operator](0007-kubernetes-operator.md)
 - [0008 Project Management](0008-project-management.md)
+- [0009 Demo App Streamlit](0009-demo-app-streamlit.md)
+- [0010 No Mockups](0010-no-mockups.md)

docs/docs/backend.md

@@ -1 +1,35 @@
 # Backend
+
+## Pocketbase
+
+<https://pocketbase.io/>
+
+We utilized PocketBase as our primary backend tool and expanded its capabilities to interact with Kubernetes. This integration aimed at leveraging the simplicity and agility of PocketBase with the robust, scalable infrastructure provided by Kubernetes.
+
+### What is Pocketbase?
+
+PocketBase is a simple yet powerful backend solution, offering an easy-to-use database and real-time APIs. It stands out for its lightweight nature and flexibility, making it an excellent choice for projects requiring quick development and deployment.
+
+### Hooks
+
+PocketBase offers a set of hooks that can be used to execute custom code before or after certain events. We used these hooks to interact with Kubernetes and deploy our applications.
+
+<https://pocketbase.io/docs/go-overview/>
+
+**Kubernetes Integration via Hooks**: We extended PocketBase's functionality by creating custom hooks. These hooks are designed to communicate with the Kubernetes API, allowing us to deploy and manage Custom Resource Definitions (CRDs) from the [Kubernetes Operator](kubernetes-operator.md) directly from PocketBase. This integration enables seamless synchronization between our data management in PocketBase and the scalable deployment capabilities of Kubernetes.
+
+### Collection Schema
+
+![Database schema](../assets/images/erd/pb_diagram_final.png)
+
+<https://pocketbase-uml.github.io/>
+
+*The schema image should illustrate the layout and relationships of the data collections used in PocketBase, showing how they are structured to facilitate the integration with Kubernetes.*
+
+### Build
+
+The pocketbase-backend will also serve the static html, css and js files from the [Frontend](frontend.md) of the project. The build process of this whole stack is done in a Dockerfile and automatically triggered via a GitHub Action on Release. The Dockerfile is located in the `ui` directory.
+
+### Deployment
+
+The deployment of this whole stack is done via a simple statefulset inside Kubernetes. Make sure the service account has the correct permissions to deploy applications to Kubernetes. The deployment files are located in the `deployment` directory.

docs/docs/frontend.md

@@ -13,16 +13,33 @@ For the mockups we used Figma, which is a tool for creating mockups and prototyp
     You can find the mockups here:  
     [Figma Design File](https://www.figma.com/file/Bi4OKCqGSgPXN1tvFzVV6Q/Untitled?type=design&mode=design&t=Sv1KYLH6X63M3oaV-1)
 
-### Mockups
+## Sveltekit
 
-#### Login Page
+We used Sveltekit to create the frontend of the application. Sveltekit is a framework for creating web applications. It is based on Svelte, which is a compiler for creating web applications. Sveltekit is still in beta and will be released in the next few months.
 
-![Login Page](../assets/images/mockups/login.png)
+!!! note "Sveltekit"
+    You can find the Sveltekit documentation here:  
+    [Sveltekit Documentation](https://kit.svelte.dev/docs)
 
-#### Overview Page
+### Pages
 
-#### Project Page
+The frontend of the application consists of the following pages:
 
-#### Profile Page
+- Login
+- Overview
+- Projects
+  - Overview
+  - Environment Variables
+  - Builds
+  - Instances
+  - Logs
+  - Networking
+  - Rollouts
+  - Scale
+  - Settings
+  - Volumes
+- Profile
 
-#### Settings Page
+### Authentication
+
+The authentication is done via static Pocketbase account. This means that you can only login with the credentials that are stored in the [backend](backend.md). The authentication is done via the [Pocketbase JS-SDK](https://github.com/pocketbase/js-sdk).

docs/docs/index.md

@@ -2,6 +2,7 @@
 
 This section contains the technical documentation for the project. It is divided into the following sub-sections:
 
-- [Frontend](frontend.md)
-- [Backend](backend.md)
-- [Infrastructure](infrastructure.md)
+- [Architecture](architecture.md): The architecture of the project.
+- [Backend](backend.md): The backend of the project.
+- [Frontend](frontend.md): The frontend of the project.
+- [Kubernetes Operator](kubernetes-operator.md): The Kubernetes operator of the project.

docs/docs/kubernetes-operator.md

@@ -1 +1,109 @@
 # Kubernetes Operator
+
+The Kubernetes operator is a Kubernetes controller that manages the lifecycle of the project's custom resources. It is written in Go and uses the [Operator SDK](https://sdk.operatorframework.io/docs/building-operators/golang/) to generate the boilerplate code.
+
+## Custom Resources
+
+The Kubernetes operator manages the following custom resource:
+
+```yaml
+apiVersion: one-click.io/v1alpha1
+kind: Rollout
+metadata:
+  name: <Rollout Name>
+  namespace: <Rollout Namespace>
+spec:
+  image:
+    registry: <Image Registry>
+    repository: <Image Repository>
+    tag: <Image Tag>
+  horizontalScale:
+    minReplicas: <Minimum Number of Replicas> # 1 for minimum
+    maxReplicas: <Maximum Number of Replicas> # n for maximum
+    targetCPUUtilizationPercentage: <Target CPU Utilization Percentage> # 0-100
+  resources:
+    requests:
+      cpu: <CPU Request> # 0.1 for 100m
+      memory: <Memory Request> # 256Mi for 256Mi
+    limits:
+      cpu: <CPU Limit> # 0.1 for 100m
+      memory: <Memory Limit> # 256Mi for 256Mi
+  env:
+    - name: <Environment Variable Name> # e.g. DB_HOST
+      value: <Environment Variable Value> # e.g. db
+  secrets:
+    - name: <Secret Name> # e.g. DB_PASSWORD
+      value: <Secret Value> # e.g. password
+  volumes:
+    - name: <Volume Name> # e.g. data
+      mountPath: <Volume Mount Path> # e.g. /data
+      size: <Volume Size> # e.g. 1Gi
+      storageClass: <Volume Storage Class> # e.g. standard
+  interfaces:
+    - name: <Interface Name> # e.g. http
+      port: <Interface Port> # e.g. 80
+      ingress: # optional ingress configuration
+        ingressClass: <Ingress Class> # e.g. nginx
+        annotations: # optional ingress annotations
+          nginx.ingress.kubernetes.io/rewrite-target: / # optional
+          nginx.ingress.kubernetes.io/ssl-redirect: "false" # optional
+        rules:
+          - host: <Ingress Host> # e.g. example.com
+            path: <Ingress Path> # e.g. /
+            tls: <Enable TLS> # e.g. true -> cert-manager will create a certificate (must be installed in the cluster)
+  serviceAccountName: <Service Account Name> # e.g. default
+```
+
+## Purpose
+
+This Kubernetes operator is an abstraction layer on top of the Kubernetes API. When you want to easily deploy a single container application to Kubernetes you need to create a deployment, a service, an ingress, a horizontal pod autoscaler, a service account, and optionally a certificate. This Kubernetes operator does all of that for you. You just need to create a custom resource and the Kubernetes operator will create all of the Kubernetes resources for you. So the benefit of this Kubernetes operator is to simplify the deployment of single container applications to Kubernetes and the [Backend](backend.md) of the project will use this simplified deployment process to deploy applications to Kubernetes.
+
+## Development
+
+The Kubernetes operator code is located in the `operator` directory. The following sections describe how to build and run the Kubernetes operator.
+
+### Prerequisites
+
+- [Docker](https://docs.docker.com/get-docker/)
+- [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/)
+- [Go](https://golang.org/doc/install)
+- [kustomize](https://kubectl.docs.kubernetes.io/installation/kustomize/)
+- [minikube](https://minikube.sigs.k8s.io/docs/start/)
+- [operator-sdk](https://sdk.operatorframework.io/docs/installation/install-operator-sdk/)
+- [yq](https://mikefarah.gitbook.io/yq/)
+
+### Build
+
+```bash
+make build
+```
+
+### Run
+
+```bash
+make install run # also runs the operator locally
+```
+
+### Deploy
+
+```bash
+make deploy
+```
+
+### Uninstall
+
+```bash
+make uninstall
+```
+
+### Clean
+
+```bash
+make uninstall
+make undeploy
+```
+
+## References
+
+- [Kubernetes Operator](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/)
+- [Operator SDK](https://sdk.operatorframework.io/docs/building-operators/golang/)

docs/meetings/2023-12-06.md

@@ -0,0 +1,42 @@
+# Meeting Notes - 2023-12-06
+
+## Participants
+
+- Jan Lauber
+- Erik Graf
+
+## Topics
+
+- Current state of the project
+- Analyse the ease of use of <https://bonsai.io>
+- Great Feedback from Erik
+- Make the user interface more easy to use and more intuitive
+- Presentation / Documentation of the project
+- What are the worries of the customers?
+  - Is it scalable? -> Kubernetes
+  - Is it secure? -> GDPR
+  - Are all solutions tested and reliable? -> Open Source and Change Log of the project
+
+## Results
+
+- We will redesign the application and introduce new types of projects / Blueprints
+  - `Reflex`
+  - `Streamlit`
+  - `Node-RED`
+  - `Custom Container`
+- Plans
+  - `Nano`
+  - `Small`
+  - `Medium`
+  - `Large`
+- For the presentation I will create 6-7 slides and a demo
+- The documentation will be a mix of this documentation in one document.
+
+## Action Items
+
+- [x] `Research`; Get the questions answered.
+- [x] `Research`; Is there need for a solutions and for which OSS?
+- [x] `Research`; Define a Price Model which balances the needs of the customers and the company.
+- [ ] `Research`; What are the worries of the customers?
+- [ ] `Research`; Analyse the ease of use of <https://bonsai.io>
+- [ ] `Prototype`; Create a prototype of the new design.

docs/meetings/index.md

@@ -5,3 +5,4 @@ This directory contains the notes from the meetings I have with my supervisor.
 ## Index
 
 - [2023-10-23](2023-10-23.md)
+- [2023-12-06](2023-12-06.md)

docs/research/competitive-analysis.md

@@ -8,4 +8,5 @@ We will use the concept of Strengths, Weaknesses, Opportunities, and Threats (`S
 - [Plural.sh](./competitive-analysis/plural.md)
 - [Streamlit Cloud Hosting](./competitive-analysis/streamlit-cloud.md)
 - [Reflex Hosting](./competitive-analysis/reflex-hosting.md)
-- [Kaa Node-RED Hosting](./competitive-analysis/kaa-node-red.md)
+- [Kaa Node-RED Hosting](./competitive-analysis/kaa-node-red-hosting.md)
+- [Bonsai Hosting](./competitive-analysis/bonsai-hosting.md)

docs/research/competitive-analysis/bonsai-hosting.md

@@ -0,0 +1,37 @@
+# Competitive Analysis: Bonsai Hosting Solution
+
+## Overview
+
+### What is it?
+
+Bonsai.io is a managed platform for Elasticsearch, OpenSearch, and SolrCloud. It provides search engine support and expertise, aiming to optimize search performance, reduce latency, and enhance search relevance. The platform is designed for companies of all sizes, from startups to large enterprises, and is used by various professionals including software engineers, data scientists, and search engineers [Bonsai.io Reviews & Ratings 2023](https://www.trustradius.com/products/bonsai-io/reviews).
+
+### How does it work?
+
+Bonsai.io specializes in deploying search clusters within users' AWS or GCP accounts. It offers expert engineering support and real-time insights into search performance, assisting users in developing innovative search features and optimizing their search experience [Bonsai.io Reviews & Ratings 2023](https://www.trustradius.com/products/bonsai-io/reviews).
+
+## Strengths
+
+1. **Expert Engineering Support**: Provides guidance from experienced search engineers for Elasticsearch, OpenSearch, and SolrCloud platforms [Bonsai.io Reviews & Ratings 2023](https://www.trustradius.com/products/bonsai-io/reviews).
+2. **Insightful Analytics**: Offers instant insights into search performance, including latency and response codes, enabling data-driven optimization [Bonsai.io Reviews & Ratings 2023](https://www.trustradius.com/products/bonsai-io/reviews).
+3. **Flexibility in Deployment**: Allows deployment in users' own cloud accounts (AWS, GCP), offering control over search infrastructure [Bonsai.io Reviews & Ratings 2023](https://www.trustradius.com/products/bonsai-io/reviews).
+4. **Scalability**: Supports reliable and scalable search clusters, ensuring rapid and accurate search results [Bonsai.io Reviews & Ratings 2023](https://www.trustradius.com/products/bonsai-io/reviews).
+
+## Weaknesses
+
+1. **Limited to Specific Technologies**: Primarily designed for Elasticsearch, OpenSearch, and SolrCloud, which may limit its appeal to users not familiar with these technologies.
+2. **Connection Management Overhead**: The platform requires multiple steps for setup and managing connections, which could be optimized [Bonsai.io Connection Management Overhead](https://help.bonsai.io/hc/en-us/articles/13929083435668-Improving-Throughput-and-Performance).
+
+## Opportunities
+
+1. **Growing Demand for Search Solutions**: With the increasing need for sophisticated search solutions in various industries, there's a significant opportunity for Bonsai.io to expand its market.
+2. **Integration with Emerging Technologies**: Potential to integrate with newer technologies and platforms, enhancing its offerings and appeal.
+
+## Threats
+
+1. **Competitive Market**: The search engine market is highly competitive, with several well-established players.
+2. **Technological Evolution**: Rapid advancements in search technologies and platforms may require continuous updates and innovation from Bonsai.io to stay relevant.
+
+## Comparative Analysis
+
+- **Comparison with One-Click Deployment**: Bonsai.io's focus on search engine optimization and support for Elasticsearch, OpenSearch, and SolrCloud differentiates it from a generalist approach like One-Click Deployment. However, One-Click Deployment could capitalize on offering a broader range of services beyond search optimization, catering to a wider audience with varying technology needs. Providing more comprehensive support and a simplified setup process could be key differentiators for One-Click Deployment compared to Bonsai.io's more specialized offering.

frameworks/custom-container/settings.json

@@ -0,0 +1,13 @@
+{
+  "overview": true,
+  "rollouts": true,
+  "builds": true,
+  "image": true,
+  "scale": true,
+  "network": true,
+  "volumes": true,
+  "instances": true,
+  "envs": true,
+  "settings": true,
+  "logs": false
+}