forked from DevFW-CICD/edp-doc
Merge remote-tracking branch 'origin/development' into development
This commit is contained in:
Stephan Lo
commit
7d562ec04c
10 changed files with 106 additions and 68 deletions
|
|
@ -22,7 +22,7 @@ Telekom MMS & T-Systems, December 2024
|
|||
|
||||
## 📖 About the Product
|
||||
|
||||
**edpbuilder** is a tool to quickly instantiate and manage **I**nternal **D**eveloper **P**latform's (**IDP**s).
|
||||
**edpbuilder** is a tool to quickly instantiate and manage **I**nternal **D**evelopment **P**latform's (**IDP**s).
|
||||
The **E**dge **D**evelopment **P**latform Builder(**edp**builder) can easily setup a Kubenetes cluster (local kind cluster or OSC instance) and deploy tools to manage the Kubernetes resources and the software lifecicle of an application.
|
||||
One usecase to demonstrate the capabilities of our tool is the PetClinic Application. (LINK)
|
||||
|
||||
|
|
@ -52,7 +52,7 @@ Our documentation can be easily accessed through a Backstage instance hosted on
|
|||
### In a local kind cluster
|
||||
|
||||
Using the edpbuilder, you can set up a local IDP that comes with a Backstage instance containing the documentation.
|
||||
*[How to set up a local IDP on a kind cluster](docs/userguide/edpbuilder.md)*
|
||||
*[How to set up a local IDP on a kind cluster](docs/userguide/edpbuilder.md)*
|
||||
|
||||
### In the Forgejo repository
|
||||
|
||||
|
|
|
|||
|
|
@ -2,16 +2,24 @@
|
|||
|
||||
[Argo CD](https://argoproj.github.io/cd/) is an open-source **continuous delivery platform** that automates the deployment of applications to Kubernetes clusters. It ensures consistent deployments by minimizing human errors and increasing efficiency through **declarative** configuration management, using **Git repositories as the single source of truth** for defining application infrastructure states.
|
||||
|
||||
---
|
||||
|
||||
## Main features
|
||||
|
||||
**1. 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.
|
||||
- **📝 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.
|
||||
|
||||
**2. 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.
|
||||
|
||||
**3. 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.
|
||||
- **♻️ 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.
|
||||
|
||||
---
|
||||
|
||||
We use ArgoCD exactly as intended by the Argo Project. For more information, please visit the [official ArgoCD documentation](https://argo-cd.readthedocs.io/en/stable/).
|
||||
|
||||
---
|
||||
|
||||
## 🔗 References
|
||||
|
||||
|
|
|
|||
|
|
@ -4,52 +4,43 @@ Backstage is a Platform Portal for building and managing internal developer tool
|
|||
|
||||
---
|
||||
|
||||
## Key features of Backstage as a Platform Portal
|
||||
## 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.
|
||||
|
||||
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**
|
||||
It offers the ability to register and manage services and microservices, as well as monitor their status and performance.
|
||||
|
||||
### 🏗️ Service Management
|
||||
- **📚 Documentation and Learning Materials**
|
||||
Backstage includes capabilities for storing and organizing documentation, making it easier for developers to access information.
|
||||
|
||||
It offers the ability to register and manage services and microservices, as well as monitor their status and performance.
|
||||
- **🌟 Golden Paths**
|
||||
Backstage supports the concept of "Golden Paths," enabling teams to follow recommended practices for development and tool usage.
|
||||
|
||||
### 📚 Documentation and Learning Materials
|
||||
|
||||
Backstage includes capabilities for storing and organizing documentation, making it easier for developers to access information.
|
||||
|
||||
### 🌟 Golden Paths
|
||||
|
||||
Backstage supports the concept of "Golden Paths," enabling teams to follow recommended practices for development and tool usage.
|
||||
|
||||
### 🧩 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.
|
||||
- **🧩 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.
|
||||
|
||||
---
|
||||
|
||||
## How to use Backstage templates (Golden Paths) in EDP
|
||||
|
||||
1. **Open the Backstage**
|
||||
LINK
|
||||
<https://edf-cc1.cx.fg1.ffm.osc.live/home>
|
||||
|
||||
2. **Navigate to "Create"**
|
||||
|
||||
In the left-hand menu, click on the "Create" option. This will open a page with available component templates.
|
||||
|
||||
|
||||
3. **Select a template**
|
||||
|
||||
Choose the template that suits your needs. For example, the "Spring PetClinic Template" may be shown in screenshots.
|
||||
|
||||
4. **Fill out the required fields**
|
||||
|
||||
Enter the necessary information that the template requires to create the component.
|
||||
|
||||
|
||||
5. **Monitor the template execution**
|
||||
|
||||
After submission, you will be redirected to a page showing the status of each step. If all steps are completed successfully, your component is ready for use.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -17,22 +17,22 @@ 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.
|
||||
Retrieves the latest version of the repository to ensure the workflow is working with the most recent code.
|
||||
|
||||
- **📝 Linting (using xxx):**
|
||||
Analyzes the code for potential issues, formatting errors, or stylistic inconsistencies.
|
||||
- **📝 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.
|
||||
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.
|
||||
Constructs the application and packages it into a Docker image.
|
||||
|
||||
- **🛡️ Vulnerability Scanning (using xxx):**
|
||||
Scans the final image for known security vulnerabilities, ensuring any issues are identified and addressed early on.
|
||||
- **🛡️ 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.
|
||||
Uploads the successfully built image to the Forgejo registry, making it available for deployment.
|
||||
|
||||
### Monitoring Workflow Progress and Logs
|
||||
|
||||
|
|
|
|||
|
|
@ -4,18 +4,22 @@ Crossplane is an open-source Kubernetes add-on that extends Kubernetes' capabili
|
|||
|
||||
---
|
||||
|
||||
## Key features and benefits
|
||||
## Main features and benefits
|
||||
|
||||
- **☁️ Cloud Agnostic:**
|
||||
Crossplane can manage resources across various cloud providers, including AWS, Azure, GCP, and others.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
Crossplane compositions allows users to compose complex infrastructure resources from simpler building blocks, promoting modularity and reusability.
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ In our EDP, we utilize Forgejo for Git hosting, Forgejo Registry for container i
|
|||
|
||||
---
|
||||
|
||||
## Features
|
||||
## Main features
|
||||
|
||||
**Forgejo** is a Git server that provides version control for your code repositories. It offers:
|
||||
|
||||
|
|
@ -32,9 +32,14 @@ The Forgejo Registry simplifies the process of managing container images and ens
|
|||
|
||||
**Forgejo Runner** is a tool used to execute CI/CD workflows defined in Forgejo Actions. It provides:
|
||||
|
||||
- **▶️ Pipeline Execution**: Runs automated tasks such as building, testing, and deploying code.
|
||||
- **⚙️ Integration with Forgejo**: Seamless execution of workflows hosted on the Forgejo Git server.
|
||||
- **⚒️ Image Building**: Builds Docker images and pushes them to the Forgejo Registry.
|
||||
- **▶️ Pipeline Execution:**
|
||||
Runs automated tasks such as building, testing, and deploying code.
|
||||
|
||||
- **⚙️ Integration with Forgejo:**
|
||||
Seamless execution of workflows hosted on the Forgejo Git server.
|
||||
|
||||
- **⚒️ Image Building:**
|
||||
Builds Docker images and pushes them to the Forgejo Registry.
|
||||
|
||||
Forgejo Runner ensures that your CI/CD processes run smoothly and consistently.
|
||||
|
||||
|
|
|
|||
|
|
@ -7,10 +7,12 @@ Various telemetry tools are included in the technology stack of this repository.
|
|||
Kube-prometheus-stack contains Kubernetes manifests, Prometheus and Grafana, including preconfigured dashboards.
|
||||
|
||||
### Kube-prometheus-stack Overview
|
||||
|
||||
Grafana is an open-source monitoring solution that enables viusalization of metrics and logs.
|
||||
Prometheus is an open-source monitoring and alerting system which collects metrics from services and allows the metrics to be shown in Grafana.
|
||||
|
||||
### Adding your own dashboards
|
||||
|
||||
Examples for additional preconfigured dashboards can be found in the folder [dashboards](https://forgejo.edf-bootstrap.cx.fg1.ffm.osc.live/DevFW-CICD/stacks/src/branch/development/template/stacks/monitoring/kube-prometheus/dashboards).
|
||||
|
||||
It is possible to add your own dashboards by putting them into the same folder.
|
||||
|
|
@ -22,14 +24,17 @@ 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.
|
||||
|
||||
### Loki Overview
|
||||
|
||||
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).
|
||||
|
||||
The application Grafana Promtail is started in edfbuilder/kind/stacks/core/promtail.yaml.
|
||||
The application Grafana Promtail is started in edfbuilder/kind/stacks/core/promtail.yaml.
|
||||
It can also be configured by it's helm values file.
|
||||
|
|
|
|||
|
|
@ -4,13 +4,22 @@ Keycloak is an open-source Identity and Access Management (IAM) solution that si
|
|||
|
||||
---
|
||||
|
||||
## Key Features
|
||||
## 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.
|
||||
- **🔑 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.
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -1,17 +1,30 @@
|
|||
# OpenBao
|
||||
|
||||
[OpenBao](https://openbao.org/) is a fork of [HashiCorp Vault](https://developer.hashicorp.com/vault) which is a centralized solution for managing and securing sensitive data like authentication credentials, usernames, API tokens, and database credentials.
|
||||
Beyond static secrets, OpenBao supports dynamic secrets, allowing applications to generate ephemeral credentials for enhanced security.
|
||||
|
||||
OpenBao's _Encrypt as a Service_ feature makes it simple to implement data encryption across your systems.
|
||||
|
||||
---
|
||||
|
||||
## Main features
|
||||
|
||||
OpenBao's Secret Engines include:
|
||||
1. **Key-Value Store**
|
||||
2. **PKI** (Public Key Infrastructure) for certificate management
|
||||
3. **SSH** for managing SSH credentials
|
||||
4. **Transit Engine** for encrypting data without storing it
|
||||
5. **Time-based One-Time Passwords** (TOTP) for two-factor authentication
|
||||
6. **Kubernetes Secrets** for seamless integration with containerized applications
|
||||
|
||||
- **Key-Value Store**
|
||||
|
||||
- **PKI** (Public Key Infrastructure) for certificate management
|
||||
|
||||
- **SSH** for managing SSH credentials
|
||||
|
||||
- **Transit Engine** for encrypting data without storing it
|
||||
|
||||
- **Time-based One-Time Passwords** (TOTP) for two-factor authentication
|
||||
|
||||
- **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.*
|
||||
|
||||
The External Secrets Operator needs a kubernetes secret containing the **OpenBao's initial token** (see above) to access its secrets. You can create it with:
|
||||
|
|
@ -31,7 +44,9 @@ And to add your first secret just run:
|
|||
`kubectl exec -ti openbao-0 -n openbao -- vault kv put data/postgres POSTGRES_USER=admin POSTGRES_PASSWORD=123456`
|
||||
|
||||
To fetch it as a kubernetes secret you'll need to create an **external-secrets.yaml** file and apply it to the cluster with `kubectl apply -f external-secrets.yaml`
|
||||
```
|
||||
|
||||
```yaml
|
||||
|
||||
# external-secret.yaml
|
||||
apiVersion: external-secrets.io/v1beta1
|
||||
kind: ExternalSecret
|
||||
|
|
@ -59,6 +74,8 @@ spec:
|
|||
|
||||
After that just run `kubectl get externalsecrets -A` to check that there are no problems with synchronization. And to access the secret on your cluster run: `kubectl get secrets -n openbao`
|
||||
|
||||
---
|
||||
|
||||
## 🔗 References
|
||||
|
||||
* https://openbao.org/docs/platform/k8s/helm/run/#initialize-and-unseal-openbao
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
## Spring's PetClinic
|
||||
# Spring's PetClinic
|
||||
|
||||
The [PetClinic](https://github.com/spring-projects/spring-petclinic) has been
|
||||
Spring's example project for years and is being updated with each new version
|
||||
|
|
@ -10,17 +10,16 @@ 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
|
||||
## Instance Creation
|
||||
|
||||
To instantiate a new PetClinic instance, create a new project from the
|
||||
PetClinic template in [Backstage](https://cnoe.localtest.me/create). The
|
||||
template executes the following steps:
|
||||
|
||||
1. Download the app source code from the given code repository
|
||||
1. Apply overrides for compatibility with Forgejo Actions.
|
||||
1. Create a new git repository in Forgejo and push the merged code.
|
||||
1. Create a new deployment in ArgoCD.
|
||||
|
||||
2. Apply overrides for compatibility with Forgejo Actions.
|
||||
3. Create a new git repository in Forgejo and push the merged code.
|
||||
4. Create a new deployment in ArgoCD.
|
||||
|
||||
After the code is pushed into Forgejo the configured workflows in the git
|
||||
repository are triggered. They compile, test and scan the project and finally
|
||||
|
|
|
|||
Loading…
Reference in a new issue