Compare commits
27 Commits
069ac897b2
...
documentor
| Author | SHA1 | Date | |
|---|---|---|---|
| fb65cda374 | |||
| 0527720ef5 | |||
| 823a05daf7 | |||
| 16e8a8cd36 | |||
| 4aa5c46eee | |||
| bab34ff3f8 | |||
| 73a01ffebb | |||
| 3577ca78cf | |||
| c05892070f | |||
| ea04340ef8 | |||
| 5d2e668c68 | |||
| 841a34877b | |||
| e4f1f8c9cb | |||
| 753a1fcb44 | |||
| 8483ca9768 | |||
| 040a26578d | |||
| a91b1fcf59 | |||
| b6af57adef | |||
| da4ea18d47 | |||
| 5d00f2af4c | |||
| 8179b94c8d | |||
| 27da605859 | |||
| 7529b38918 | |||
| 2d230146e7 | |||
| a47b057727 | |||
| 9f3fd7cd45 | |||
| 79ad2b2ed7 |
90
catalog/component/default/petclinic-demo-andrej4/README.md
Normal file
90
catalog/component/default/petclinic-demo-andrej4/README.md
Normal file
@@ -0,0 +1,90 @@
|
|||||||
|
---
|
||||||
|
title: "Petclinic Demo Application"
|
||||||
|
generated_by: documentor-agent
|
||||||
|
generated_at: "2026-05-28T09:07:15+00:00"
|
||||||
|
human_edited: false
|
||||||
|
source_entity: "Component/default/petclinic-demo-andrej4"
|
||||||
|
source_repo: "https://gitea.kyndemo.live/validate/petclinic-demo-andrej4"
|
||||||
|
---
|
||||||
|
|
||||||
|
## Overview
|
||||||
|
|
||||||
|
The **Petclinic Demo Application** is a deployment of the Spring PetClinic sample application, tailored for demonstration purposes. It showcases a modern Java-based microservice architecture, leveraging Spring Boot for rapid development and deployment. The application is deployed via ArgoCD into the `demo-apps` namespace and includes integrations for observability, load testing, and chaos engineering.
|
||||||
|
|
||||||
|
This service plays a critical role in demonstrating best practices for application lifecycle management, including CI/CD workflows, OpenTelemetry instrumentation, and Kubernetes-based deployments. It serves as a reference implementation for teams adopting similar technologies and workflows.
|
||||||
|
|
||||||
|
## Repository
|
||||||
|
|
||||||
|
| Property | Value |
|
||||||
|
|----------------|---------------------------------------------------------------------------------------------------------|
|
||||||
|
| **Source Repo**| [Petclinic Demo Repository](https://gitea.kyndemo.live/validate/petclinic-demo-andrej4) |
|
||||||
|
| **Branch** | `main` |
|
||||||
|
| **ArgoCD App** | [petclinic-demo-andrej4](https://argocd.kyndemo.live/applications/petclinic-demo-andrej4) |
|
||||||
|
| **Namespace** | `demo-apps` |
|
||||||
|
|
||||||
|
## Architecture
|
||||||
|
|
||||||
|
The Petclinic Demo Application is built on the Spring Boot framework and deployed as a containerized service in Kubernetes. Key architectural components include:
|
||||||
|
|
||||||
|
- **Spring Boot Application**: The core service, providing RESTful APIs and a web interface.
|
||||||
|
- **Database**: Configurable to use H2 (in-memory), MySQL, or PostgreSQL, depending on the active profile.
|
||||||
|
- **OpenTelemetry Integration**: Auto-instrumentation for tracing, metrics, and logs, exported to an OTel Collector.
|
||||||
|
- **ArgoCD**: Continuous deployment and synchronization from the `main` branch.
|
||||||
|
- **K6 Load Testing**: Configured for performance testing.
|
||||||
|
- **Chaos Mesh**: Enabled for chaos engineering experiments.
|
||||||
|
|
||||||
|
Data flows through the application from user interactions to backend services, with observability tools providing insights into performance and reliability.
|
||||||
|
|
||||||
|
## Configuration
|
||||||
|
|
||||||
|
| Configuration Item | Description |
|
||||||
|
|--------------------------|----------------------------------------------------------------------------------------------|
|
||||||
|
| `spring.profiles.active` | Sets the active profile (`default`, `mysql`, `postgres`). |
|
||||||
|
| `OTel Collector URL` | `http://otel-collector.monitoring.svc.cluster.local:4318` |
|
||||||
|
| `Database URL` | Configurable for H2, MySQL, or PostgreSQL. |
|
||||||
|
| `K6 ConfigMap` | `k6-test-petclinic-demo-andrej4` |
|
||||||
|
|
||||||
|
## Operations
|
||||||
|
|
||||||
|
### Deployment
|
||||||
|
|
||||||
|
1. Clone the repository:
|
||||||
|
```bash
|
||||||
|
git clone https://gitea.kyndemo.live/validate/petclinic-demo-andrej4.git
|
||||||
|
cd petclinic-demo-andrej4
|
||||||
|
```
|
||||||
|
2. Push changes to the `main` branch:
|
||||||
|
```bash
|
||||||
|
git add . && git commit -m "your change" && git push origin main
|
||||||
|
```
|
||||||
|
3. ArgoCD will automatically sync changes to the `demo-apps` namespace.
|
||||||
|
|
||||||
|
### Rollback
|
||||||
|
|
||||||
|
1. Open the [ArgoCD UI](https://argocd.kyndemo.live/applications/petclinic-demo-andrej4).
|
||||||
|
2. Click **History and Rollback**.
|
||||||
|
3. Select the desired revision and click **Rollback**.
|
||||||
|
|
||||||
|
Alternatively, revert the commit in Git and push — ArgoCD will auto-sync the rollback.
|
||||||
|
|
||||||
|
## Observability
|
||||||
|
|
||||||
|
This service is fully instrumented with OpenTelemetry. Observability data is visualized in Grafana.
|
||||||
|
|
||||||
|
- **Grafana Dashboard**: [View Dashboard](https://grafana.kyndemo.live/d/otel-app-observability-v2/opentelemetry-application-observability?orgId=1&var-app=petclinic-demo-andrej4)
|
||||||
|
- **Alerting**: Configured via Grafana with label selector `app.kubernetes.io/instance=petclinic-demo-andrej4`.
|
||||||
|
|
||||||
|
_Not configured — see platform observability docs for additional details._
|
||||||
|
|
||||||
|
## Dependencies
|
||||||
|
|
||||||
|
- `component:default/argocd-service`
|
||||||
|
- `resource:default/k6-operator`
|
||||||
|
- `resource:default/otel-collector`
|
||||||
|
|
||||||
|
## Links
|
||||||
|
|
||||||
|
- [Live Application](https://petclinic-demo-andrej4.kyndemo.live)
|
||||||
|
- [Repository](https://gitea.kyndemo.live/validate/petclinic-demo-andrej4)
|
||||||
|
- [ArgoCD App](https://argocd.kyndemo.live/applications/petclinic-demo-andrej4)
|
||||||
|
- [Grafana Dashboard](https://grafana.kyndemo.live/d/otel-app-observability-v2/opentelemetry-application-observability?orgId=1&var-app=petclinic-demo-andrej4)
|
||||||
12
catalog/component/default/petclinic-demo-andrej4/_meta.json
Normal file
12
catalog/component/default/petclinic-demo-andrej4/_meta.json
Normal file
@@ -0,0 +1,12 @@
|
|||||||
|
{
|
||||||
|
"sourceShas": {
|
||||||
|
"catalog-info.yaml": "7f8e08e4d71a45033f49d9190e35fd08ebbb7645",
|
||||||
|
"README.md": "ef9b745ac26efecf8340b75eea18b8151ba7a86e",
|
||||||
|
"docs/adr/index.md": "b9a0b93743cf579be35101bbc63b29356be2849f",
|
||||||
|
"docs/index.md": "f7bef9b17f650992e3a89fbecf37eb0ea948b8e0",
|
||||||
|
"docs/runbooks/index.md": "f9796c4d1a113b786df89cd74dee0f50d98d6025"
|
||||||
|
},
|
||||||
|
"promptVersion": "1.0",
|
||||||
|
"generatedAt": "2026-05-28T09:07:25+00:00",
|
||||||
|
"contentHash": "625799bc84a8ff7004d26604e1d76286e95b9a3617abf6c014146a04202ff719"
|
||||||
|
}
|
||||||
@@ -1,7 +1,7 @@
|
|||||||
---
|
---
|
||||||
title: "sonar-test-nest4"
|
title: "sonar-test-nest4"
|
||||||
generated_by: documentor-agent
|
generated_by: documentor-agent
|
||||||
generated_at: "2026-05-15T15:19:14+00:00"
|
generated_at: "2026-05-21T08:45:51+00:00"
|
||||||
human_edited: false
|
human_edited: false
|
||||||
source_entity: "Component/default/sonar-test-nest4"
|
source_entity: "Component/default/sonar-test-nest4"
|
||||||
source_repo: "https://gitea.kyndemo.live/validate/sonar-test-nest4"
|
source_repo: "https://gitea.kyndemo.live/validate/sonar-test-nest4"
|
||||||
@@ -9,34 +9,35 @@ source_repo: "https://gitea.kyndemo.live/validate/sonar-test-nest4"
|
|||||||
|
|
||||||
## Overview
|
## Overview
|
||||||
|
|
||||||
`sonar-test-nest4` is a stateless microservice built using the `typescript-nestjs` runtime. It was scaffolded from the **Create Microservice** golden-path template on the Kyndryl Platform. The service provides a RESTful API for managing items, including endpoints for CRUD operations. It is designed to be lightweight, scalable, and observable, with integrated OpenTelemetry instrumentation and Prometheus metrics.
|
`sonar-test-nest4` is a stateless microservice built using the `typescript-nestjs` runtime. It was scaffolded from the **Create Microservice** golden-path template on the Kyndryl Platform. The service provides a REST API for managing items, including endpoints for CRUD operations. It is designed to be lightweight, scalable, and observable, with integrated OpenTelemetry instrumentation and Prometheus metrics.
|
||||||
|
|
||||||
This service plays a key role in the demo-apps domain, serving as a foundational component for item management. It is deployed on Azure Kubernetes Service (AKS) via Humanitec, with container images stored in Azure Container Registry (ACR). The CI/CD pipeline is managed through Gitea Actions, ensuring automated builds, tests, and deployments across environments (`dev`, `staging`, `prod`).
|
This service plays a critical role in the demo-apps domain, serving as a testbed for platform capabilities such as CI/CD pipelines, observability, and load testing. It is managed via Humanitec and deployed to Azure Kubernetes Service (AKS) using Score-based configurations.
|
||||||
|
|
||||||
## Repository
|
## Repository
|
||||||
|
|
||||||
| Field | Value |
|
| Field | Value |
|
||||||
|----------------|-----------------------------------------------------------------------------------------------------------------|
|
|----------------|------------------------------------------------------------------------------------------------------------------------------------|
|
||||||
| Source Repo | [validate/sonar-test-nest4](https://gitea.kyndemo.live/validate/sonar-test-nest4) |
|
| Source Repo | [sonar-test-nest4](https://gitea.kyndemo.live/validate/sonar-test-nest4) |
|
||||||
| Branch | `dev` → `staging` → `prod` (→ `main` SoR) |
|
| Branch | `dev` |
|
||||||
| ArgoCD App | — |
|
| ArgoCD App | — |
|
||||||
| Namespace | `dev` |
|
| Namespace | `dev` |
|
||||||
|
|
||||||
## Architecture
|
## Architecture
|
||||||
|
|
||||||
`sonar-test-nest4` follows a stateless architecture, leveraging the `typescript-nestjs` framework. Key components include:
|
`sonar-test-nest4` follows a modern microservice architecture with the following components:
|
||||||
|
|
||||||
- **Runtime**: `typescript-nestjs`
|
- **Runtime**: `typescript-nestjs`
|
||||||
- **Container Port**: `3000`
|
- **Container Port**: `3000`
|
||||||
- **Health Check**: `/health`
|
- **Endpoints**:
|
||||||
- **Metrics Endpoint**: `/metrics` (Prometheus format)
|
- `/api/items` for CRUD operations
|
||||||
- **Image Registry**: Azure Container Registry (`bstagecjotdevacr`)
|
- `/health` for health checks
|
||||||
|
- `/metrics` for Prometheus metrics
|
||||||
The deployment flow is managed through Gitea Actions CI/CD workflows:
|
- **Deployment**:
|
||||||
1. **build-push.yml**: Builds and tests the application, then pushes the container image to ACR.
|
- Images are built and pushed to Azure Container Registry (ACR).
|
||||||
2. **deploy-humanitec.yml**: Deploys the service to AKS using Humanitec's API and Score configuration.
|
- Humanitec API triggers deployments to AKS using Score-based configurations.
|
||||||
|
- **CI/CD**:
|
||||||
Promotions between environments (`dev`, `staging`, `prod`) are triggered via PRs, with CI gates and approval requirements ensuring quality control.
|
- Gitea Actions workflows (`build-push.yml` and `deploy-humanitec.yml`) automate build, test, and deployment processes.
|
||||||
|
- Promotion between environments (`dev → staging → prod`) is gated by CI checks and manual approvals.
|
||||||
|
|
||||||
## Configuration
|
## Configuration
|
||||||
|
|
||||||
@@ -46,24 +47,26 @@ Promotions between environments (`dev`, `staging`, `prod`) are triggered via PRs
|
|||||||
| `health_path` | `/health` |
|
| `health_path` | `/health` |
|
||||||
| `container_port` | `3000` |
|
| `container_port` | `3000` |
|
||||||
|
|
||||||
|
Additional configuration options are managed via `.platform/config.yaml` and Humanitec score files.
|
||||||
|
|
||||||
## Operations
|
## Operations
|
||||||
|
|
||||||
### Deployment Steps
|
### Deployment Flow
|
||||||
1. Push changes to the `dev` branch for automatic deployment to the development environment.
|
|
||||||
2. Open a PR for promotion to `staging` or `prod`. Ensure CI tests pass and obtain one approval before merging.
|
1. Push changes to the `dev` branch to trigger automatic builds and deployments to the dev environment.
|
||||||
3. Use the Backstage CI/CD tab to trigger promotions between environments.
|
2. Promote changes to `staging` or `prod` via PRs, requiring CI checks and one approval.
|
||||||
|
3. Use Backstage's CI/CD tab to monitor and trigger promotions between environments.
|
||||||
|
|
||||||
### Runbook Notes
|
### Runbook Notes
|
||||||
- Monitor `/health` for service health status.
|
|
||||||
- Use `/metrics` for Prometheus-based observability.
|
- **Health Check**: Verify service health via `/health`.
|
||||||
- Refer to `.platform/config.yaml` for runtime-specific configurations.
|
- **Metrics**: Access Prometheus metrics at `/metrics`.
|
||||||
|
- **Load Testing**: K6 is enabled for load testing, with configurations stored in the `k6-test-sonar-test-nest4` ConfigMap.
|
||||||
|
|
||||||
## Observability
|
## Observability
|
||||||
|
|
||||||
- **Grafana Dashboard**: [Opentelemetry Application Observability](https://grafana.kyndemo.live/d/otel-app-observability-v2/opentelemetry-application-observability?orgId=1&var-app=sonar-test-nest4)
|
- **Grafana Dashboard**: [OpenTelemetry Application Observability](https://grafana.kyndemo.live/d/otel-app-observability-v2/opentelemetry-application-observability?orgId=1&var-app=sonar-test-nest4)
|
||||||
- **Prometheus Metrics**: Enabled (`/metrics` endpoint).
|
- **Prometheus Metrics**: Exposed at `/metrics` on port `3000`.
|
||||||
- **Chaos Mesh**: Enabled for resilience testing.
|
|
||||||
- **K6 Load Testing**: Configured via `k6-test-sonar-test-nest4` in the `dev` namespace.
|
|
||||||
|
|
||||||
## Dependencies
|
## Dependencies
|
||||||
|
|
||||||
|
|||||||
13
catalog/component/default/sonar-test-nest4/_meta.json
Normal file
13
catalog/component/default/sonar-test-nest4/_meta.json
Normal file
@@ -0,0 +1,13 @@
|
|||||||
|
{
|
||||||
|
"sourceShas": {
|
||||||
|
"catalog-info.yaml": "aa72b708c50b03b5dd454112e1f50ab88546e586",
|
||||||
|
".platform/initialized.md": "24a574f77ac17059b313a824398b9bb19263232e",
|
||||||
|
"README.md": "393357c07b620a60ef22f449987d9195d533dd10",
|
||||||
|
"docs/api.md": "86776bdd5e2fbe634709920102282ed589927c5b",
|
||||||
|
"docs/architecture.md": "00364872501f36d455a6597502481c8422368746",
|
||||||
|
"docs/index.md": "81f0ec2243665ad41daf93202c872cfc023eb21a"
|
||||||
|
},
|
||||||
|
"promptVersion": "1.0",
|
||||||
|
"generatedAt": "2026-05-21T08:46:06+00:00",
|
||||||
|
"contentHash": "a82efb2e2e92a9bcb63354c3faab85a4f8438528764c04da61699539d261fa17"
|
||||||
|
}
|
||||||
@@ -1,44 +1,33 @@
|
|||||||
```markdown
|
|
||||||
---
|
---
|
||||||
title: "Platform"
|
title: "Platform"
|
||||||
generated_by: documentor-agent
|
generated_by: documentor-agent
|
||||||
generated_at: "2026-05-05T10:06:41+00:00"
|
generated_at: "2026-05-28T11:56:08+00:00"
|
||||||
human_edited: false
|
human_edited: false
|
||||||
source_entity: "Domain/default/platform"
|
source_entity: "Domain/default/platform"
|
||||||
---
|
---
|
||||||
|
|
||||||
# Platform
|
|
||||||
|
|
||||||
> Platform domain for platform engineering capabilities and tooling.
|
|
||||||
|
|
||||||
## Overview
|
## Overview
|
||||||
|
|
||||||
The Platform domain serves as the central hub for platform engineering capabilities and tooling within the organization. It encompasses systems and tools that enable efficient development, deployment, and management of software across the organization. This domain is designed to provide foundational services and frameworks that support the broader engineering ecosystem.
|
The Platform domain encompasses platform engineering capabilities and tooling. It serves as the foundation for enabling teams to build, deploy, and manage applications efficiently. This domain focuses on providing shared services, infrastructure, and tools that streamline development workflows and enhance operational reliability.
|
||||||
|
|
||||||
The systems within this domain are critical for ensuring scalability, reliability, and developer productivity. By consolidating platform-related resources and expertise, the Platform domain helps streamline operations and fosters innovation.
|
By centralizing platform engineering efforts, this domain supports scalability, consistency, and innovation across the organization. It includes systems and tools that empower developers and operational teams to focus on delivering business value while reducing the complexity of managing underlying infrastructure.
|
||||||
|
|
||||||
## Ownership
|
## Ownership
|
||||||
|
|
||||||
| Field | Value |
|
| Owner | Namespace | Labels |
|
||||||
|---|---|
|
|--------------------------------|-----------|--------|
|
||||||
| Owner | group:default/platform-engineering |
|
| group:default/platform-engineering | default | — |
|
||||||
| Namespace | default |
|
|
||||||
| Labels | — |
|
## Systems
|
||||||
|
|
||||||
|
- `system:default/agentic-agents`
|
||||||
|
- `system:default/cjot-backstage`
|
||||||
|
- `system:default/platform-engineering`
|
||||||
|
|
||||||
## Relationships
|
## Relationships
|
||||||
|
|
||||||
The Platform domain includes the following systems:
|
<!-- TODO: FILL IN -->
|
||||||
|
|
||||||
- **Agentic Agents** (`system:default/agentic-agents`)
|
|
||||||
- **CJOT Backstage** (`system:default/cjot-backstage`)
|
|
||||||
- **Petclinic Demo Jonathan Scaf 2** (`system:default/petclinic-demo-jonathan-scaf-2`)
|
|
||||||
- **Platform Engineering** (`system:default/platform-engineering`)
|
|
||||||
|
|
||||||
## Links
|
## Links
|
||||||
|
|
||||||
_No links configured._
|
_No links configured._
|
||||||
|
|
||||||
## Notes
|
|
||||||
|
|
||||||
Platform domain for platform engineering capabilities and tooling.
|
|
||||||
```
|
|
||||||
Reference in New Issue
Block a user