forked from DevFW-CICD/edp-doc
Merge remote-tracking branch 'refs/remotes/origin/development' into development
This commit is contained in:
commit
13bd4343d9
10 changed files with 85 additions and 31 deletions
|
@ -6,13 +6,18 @@
|
|||
|
||||
## Main features
|
||||
|
||||
- **📝 Declarative Configuration Management**
|
||||
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.
|
||||
|
||||
- **☸️ Kubernetes-Native Integration**
|
||||
Designed specifically for Kubernetes, Argo CD integrates seamlessly within the Kubernetes ecosystem. It leverages Kubernetes’ native capabilities for managing deployments and cluster resources, aligning with GitOps principles to handle changes automatically based on the declarative configurations in Git.
|
||||
- **☸️ Kubernetes-Native Integration:**
|
||||
|
||||
Designed specifically for Kubernetes, Argo CD integrates seamlessly within the Kubernetes ecosystem. It leverages Kubernetes' native capabilities for managing deployments and cluster resources, aligning with GitOps principles to handle changes automatically based on the declarative configurations in Git.
|
||||
|
||||
- **♻️ Self-Healing and Automatic Rollbacks:**
|
||||
|
||||
- **♻️ Self-Healing and Automatic Rollbacks**
|
||||
Argo CD detects drift (when the actual state of a cluster deviates from the desired state) and automatically reconciles changes to restore the desired state. It also supports automatic rollbacks in the event of deployment failures, provided policies are defined in Git configurations.
|
||||
|
||||
---
|
||||
|
|
|
@ -6,19 +6,24 @@ Backstage is a Platform Portal for building and managing internal developer tool
|
|||
|
||||
## Main features of Backstage as a Platform Portal
|
||||
|
||||
- **🤝 Tool Integration**
|
||||
- **🤝 Tool Integration:**
|
||||
|
||||
Backstage allows for the integration of various tools used in the development process, such as CI/CD, version control systems, monitoring, and others, into a single interface.
|
||||
|
||||
- **🏗️ Service Management**
|
||||
- **🏗️ Service Management:**
|
||||
|
||||
It offers the ability to register and manage services and microservices, as well as monitor their status and performance.
|
||||
|
||||
- **📚 Documentation and Learning Materials**
|
||||
- **📚 Documentation and Learning Materials:**
|
||||
|
||||
Backstage includes capabilities for storing and organizing documentation, making it easier for developers to access information.
|
||||
|
||||
- **🌟 Golden Paths**
|
||||
- **🌟 Golden Paths:**
|
||||
|
||||
Backstage supports the concept of "Golden Paths," enabling teams to follow recommended practices for development and tool usage.
|
||||
|
||||
- **🧩 Modularity and Extensibility**
|
||||
- **🧩 Modularity and Extensibility:**
|
||||
|
||||
The platform allows for the creation of plugins, enabling users to customize and extend Backstage's functionality to fit their organization's needs.
|
||||
Backstage provides developers with centralized and convenient access to essential tools and resources, making it an effective solution for supporting Platform Engineering and developing an internal platform portal.
|
||||
|
||||
|
|
|
@ -17,21 +17,27 @@ Each time you push a new commit or open a pull request, a CI workflow is initiat
|
|||
The CI pipeline consists of several predefined steps designed to ensure quality and security before publishing the final image:
|
||||
|
||||
- **📥 Checkout:**
|
||||
|
||||
Retrieves the latest version of the repository to ensure the workflow is working with the most recent code.
|
||||
|
||||
- **📝 Linting (using [golangci-lint](https://github.com/golangci/golangci-lint):**
|
||||
- **📝 Linting (using [golangci-lint](https://github.com/golangci/golangci-lint)):**
|
||||
|
||||
Analyzes the code for potential issues, formatting errors, or stylistic inconsistencies.
|
||||
|
||||
- **🔑 Docker Login:**
|
||||
|
||||
Authenticates with your Docker registry so that the newly built image can be pushed securely.
|
||||
|
||||
- **🔧 Build Application & Image:**
|
||||
|
||||
Constructs the application and packages it into a Docker image.
|
||||
|
||||
- **🛡️ Vulnerability Scanning (using [trivy](https://github.com/aquasecurity/trivy)):**
|
||||
|
||||
Scans the final image for known security vulnerabilities, ensuring any issues are identified and addressed early on.
|
||||
|
||||
- **⬆️ Push Image to Registry:**
|
||||
|
||||
Uploads the successfully built image to the Forgejo registry, making it available for deployment.
|
||||
|
||||
### Monitoring Workflow Progress and Logs
|
||||
|
|
|
@ -7,18 +7,23 @@ Crossplane is an open-source Kubernetes add-on that extends Kubernetes' capabili
|
|||
## Main features and benefits
|
||||
|
||||
- **☁️ Cloud Agnostic:**
|
||||
|
||||
Crossplane can manage resources across various cloud providers, including AWS, Azure, GCP, and others.
|
||||
|
||||
- **🧩 Kubernetes Native:**
|
||||
|
||||
Crossplane leverages Kubernetes' API and control plane, making it easy to integrate with existing Kubernetes workflows and tools.
|
||||
|
||||
- **📜 Declarative Infrastructure:**
|
||||
|
||||
Crossplane uses Kubernetes manifests to define infrastructure resources, enabling version control and automated deployments.
|
||||
|
||||
- **🔧 Extensible:**
|
||||
|
||||
Crossplane can be extended with custom resource definitions (CRDs) to represent any external resource, providing flexibility and customization.
|
||||
|
||||
- **🏗️ Composable:**
|
||||
|
||||
Crossplane compositions allows users to compose complex infrastructure resources from simpler building blocks, promoting modularity and reusability.
|
||||
|
||||
---
|
||||
|
|
|
@ -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
|
||||
|
||||
|
|
|
@ -8,9 +8,17 @@ In our EDP, we utilize Forgejo for Git hosting, Forgejo Registry for container i
|
|||
|
||||
**Forgejo** is a Git server that provides version control for your code repositories. It offers:
|
||||
|
||||
- **💾 Code Hosting:** Store and manage your source code repositories.
|
||||
- **👥 Collaboration Tools:** Features like pull requests, issue tracking, and code reviews to enhance teamwork.
|
||||
- **✅ Git Actions:** Native support for CI/CD workflows using Forgejo Actions.
|
||||
- **💾 Code Hosting:**
|
||||
|
||||
Store and manage your source code repositories.
|
||||
|
||||
- **👥 Collaboration Tools:**
|
||||
|
||||
Features like pull requests, issue tracking, and code reviews to enhance teamwork.
|
||||
|
||||
- **✅ Git Actions:**
|
||||
|
||||
Native support for CI/CD workflows using Forgejo Actions.
|
||||
|
||||
Forgejo serves as the central hub for managing source code and related development activities.
|
||||
|
||||
|
@ -20,9 +28,17 @@ Forgejo serves as the central hub for managing source code and related developme
|
|||
|
||||
**Forgejo Registry** is a container image registry integrated with Forgejo. It allows you to:
|
||||
|
||||
- **🐳 Store Docker Images**: Save and manage container images for deployment.
|
||||
- **📜 Version Control**: Keep track of different versions of your container images.
|
||||
- **⚙️ Integration with CI Workflows**: Store images built by CI workflows for future deployment.
|
||||
- **🐳 Store Docker Images:**
|
||||
|
||||
Save and manage container images for deployment.
|
||||
|
||||
- **📜 Version Control:**
|
||||
|
||||
Keep track of different versions of your container images.
|
||||
|
||||
- **⚙️ Integration with CI Workflows:**
|
||||
|
||||
Store images built by CI workflows for future deployment.
|
||||
|
||||
The Forgejo Registry simplifies the process of managing container images and ensures they are readily available for deployment.
|
||||
|
||||
|
|
|
@ -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).
|
||||
|
|
|
@ -7,18 +7,23 @@ Keycloak is an open-source Identity and Access Management (IAM) solution that si
|
|||
## Main features
|
||||
|
||||
- **🔑 Single Sign-On (SSO):**
|
||||
|
||||
Enable users to access multiple applications and services with a single set of credentials, reducing login fatigue and improving the user experience.
|
||||
|
||||
- **👥 User Federation:**
|
||||
|
||||
Integrate your existing user stores—such as LDAP, Active Directory, or custom databases—without re-engineering your authentication layer.
|
||||
|
||||
- **🔒 Role-Based Access Control (RBAC):**
|
||||
|
||||
Assign fine-grained roles and permissions to users or groups, making it easier to manage security policies at scale.
|
||||
|
||||
- **🌐 Social Login & Identity Brokering:**
|
||||
|
||||
Offer seamless authentication through providers like Google, Facebook, or GitHub, saving time by not building these integrations yourself.
|
||||
|
||||
- **🛠️ Extensible & Customizable:**
|
||||
|
||||
Adjust Keycloak’s behavior using custom providers, themes, or authentication flows that match your project’s unique requirements.
|
||||
|
||||
---
|
||||
|
|
|
@ -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