final styling
This commit is contained in:
parent
7d562ec04c
commit
534e6b4592
5 changed files with 29 additions and 15 deletions
|
@ -6,6 +6,8 @@
|
|||
|
||||
## Main features
|
||||
|
||||
Here’s an overview of Argo CD’s main features that streamline application delivery, ensure consistency, and promote stability in Kubernetes environments:
|
||||
|
||||
- **📝 Declarative Configuration Management**
|
||||
Argo CD uses declarative YAML or JSON files stored in Git repositories to manage application infrastructure. These files define the desired state, ensuring that applications are consistently deployed to Kubernetes clusters with every deployment.
|
||||
|
||||
|
|
|
@ -1,11 +1,14 @@
|
|||
# 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.
|
||||
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
|
||||
|
||||
|
@ -15,17 +18,15 @@ The edpbuilder is bootstrapped in three phases:
|
|||
- 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.
|
||||
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.
|
||||
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.
|
||||
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:
|
||||
|
@ -36,8 +37,9 @@ The edpbuilder only contains the deployment of the core applications and request
|
|||
- 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.
|
||||
> 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
|
||||
|
||||
|
|
|
@ -2,6 +2,8 @@
|
|||
|
||||
Various telemetry tools are included in the technology stack of this repository.
|
||||
|
||||
---
|
||||
|
||||
## kube-prometheus-stack: prometheus, grafana, dashboards
|
||||
|
||||
Kube-prometheus-stack contains Kubernetes manifests, Prometheus and Grafana, including preconfigured dashboards.
|
||||
|
@ -23,6 +25,8 @@ It is possible to add your own dashboards by putting them into the same folder.
|
|||
|
||||
Currently the preconfigured dashboards include several examples for Loki and Nginx-Ingress metrics.
|
||||
|
||||
---
|
||||
|
||||
## Loki
|
||||
|
||||
Grafana Loki is a scalable open-source log aggregation system.
|
||||
|
@ -32,6 +36,8 @@ Grafana Loki is a scalable open-source log aggregation system.
|
|||
Loki is started in microservices mode and contains the components ingester, distributor, querier, and query-frontend.
|
||||
It can be configured by it's helm values file.
|
||||
|
||||
---
|
||||
|
||||
## promtail
|
||||
|
||||
Grafana Promtail is an agent that ships logs to a Grafan Loki instance (log-shipper).
|
||||
|
|
|
@ -23,6 +23,8 @@ OpenBao's Secret Engines include:
|
|||
|
||||
- **Kubernetes Secrets** for seamless integration with containerized applications
|
||||
|
||||
---
|
||||
|
||||
## 🔨 How to get it to run
|
||||
|
||||
*Hint: To be able to use OpenBao it has to be unsealed first. This happens automatically. While unsealing an initial token is being created. To access this token just run the **./getpassword.sh** script.*
|
||||
|
|
|
@ -10,6 +10,8 @@ code, builds and deploys it. This demonstrates a golden path to set up an
|
|||
entire development and deployment pipeline of an example or starter
|
||||
application.
|
||||
|
||||
---
|
||||
|
||||
## Instance Creation
|
||||
|
||||
To instantiate a new PetClinic instance, create a new project from the
|
||||
|
|
Loading…
Reference in a new issue