46 lines
3.1 KiB
Markdown
46 lines
3.1 KiB
Markdown
# edpbuilder PoC - test bed for IDP instantiation and orchestration
|
|
|
|
The edpbuilder is based on the [idpbuilder](https://github.com/cnoe-io/idpbuilder) of CNOE and is compatibile to the [CNOE stacks](https://github.com/cnoe-io/stacks).
|
|
|
|
It is the extract of the idpbuilder's core package and it's way of installing, furthermore enriched by platform orchestration functionality through the use of [Crossplane](crossplane.md).
|
|
|
|
It also implements a full GitOps approch by utilizing the [ArgoCD](argocd.md) app of apps pattern and has the ability to provision other clusters and clusters resources as well.
|
|
|
|
The user experiance is given by [Backstage](backstage.md) as the central entry point for developers and other team members.
|
|
|
|
---
|
|
|
|
## General approach
|
|
|
|
The edpbuilder is bootstrapped in three phases:
|
|
|
|
- edpbuilder.sh installs Crossplane and it's required providers and functions. The Crossplane edpbuilder composition is deployed.
|
|
- The edpbuilder composition then installs unmanaged the edpbuilder core applications including ArgoCD.
|
|
- ArgoCD then installs and manages all other applications from the edpbuilder stacks including ArgoCD itself and the other previosly deployed core applications.
|
|
|
|
The Crossplane edpbuilder composition can be extended by the provisioning of a new Kubernetes clusters in which the edpbuilder then get's deployed.
|
|
|
|
This allows for high flexibility and platform orchestration. New instances of an edpbuilder can be provisioned and deployed simply by adding new edpbuilder Kubernetes objects to the management cluster. By using Kubernetes objects and custom resource definitions for all resources, the full scale of deployments and deployment tasks are represented in a fully declaratively manner.
|
|
|
|
Adding, changing and removing applications from each stack and adding, changing and removing whole stacks is accomplished by pushing the desired changes of the Kubernetes manifests to git. ArgoCD will pick up the changes and deploys them automatically.
|
|
A pull request pipeline is intended to support management of the system as a whole.
|
|
|
|
---
|
|
|
|
## edpbuilder stacks
|
|
|
|
The edpbuilder only contains the deployment of the core applications and requests ArgoCD to deploy the [edpbuilder stacks](https://forgejo.edf-bootstrap.cx.fg1.ffm.osc.live/DevFW-CICD/stacks) repository. That repository contains a folder structure which groups related applications into stacks. The following stacks are implemented currently:
|
|
|
|
- core (Forgejo, ArgoCD and ingress-nginx)
|
|
- ref-implementation (Backstage, Keycloak, OpenBAO, Forgejo Runner)
|
|
- monitoring (Prometheus, Grafana, Loki)
|
|
- local-backup (Minio and Velero)
|
|
- second-cluster (Showcase for the deployment of an example application into a dynamicly provisioned cluster)
|
|
|
|
> Note: The core stack is first deployed unmanaged by Crossplane. ArgoCD then takes over and synchonizes with the already installed core stack. From that point on ArgoCD is responsible for managing all stacks and applications, including the core stack.
|
|
|
|
---
|
|
|
|
## Installation
|
|
|
|
The installation procedure is documented in the [edpbuilder repository](https://forgejo.edf-bootstrap.cx.fg1.ffm.osc.live/DevFW/edpbuilder).
|