DevFW-CICD/edp-doc
17
0
Fork 1
Code Issues Pull requests 2 Projects Releases Packages Wiki Activity Actions

Added edpbuilder.md

Browse source
This commit is contained in:
Richard Robert Reitz 2024-12-18 21:35:56 +01:00
parent ce7929af30
commit a4f56a5c06
1 changed files with 42 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

47
docs/userguide/edpbuilder.md
View file

@ -1,7 +1,44 @@
robert
What does the edfBuilder do?
# edpbuilder PoC - test bed for IDP instantiation and orchestration
Whats the structure
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.
Local install
osc install
## General approach
The edpbuilder is bootstrapped in three phases:
- edpbuilder.sh installs Crossplane and it's required providers and functions. The Crossplane edfbuilder composition is deployed.
- The edfbuilder 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).