forked from DevFW-CICD/edp-doc
66 lines
3 KiB
Markdown
66 lines
3 KiB
Markdown
# 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
|
|
of the framework. It consists of a simple, old-school Java webapp and a
|
|
PostgreSQL relational database for persistence.
|
|
|
|
Within the IDP the PetClinic backstage template creates a copy of the PetClinic
|
|
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
|
|
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
|
|
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
|
|
push a container image into Forgejo's internal container registry.
|
|
|
|
At the same time, ArgoCD starts deploying the newly created instance of the
|
|
PetClinic based on the kubernetes manifests located in the git repo. However,
|
|
as the application is built from source, the webapp only becomes available as
|
|
soon as the container image of the Java app is pushed into the container
|
|
registry.
|
|
|
|
Eventually, the new PetClinic will go live on a subdomain corresponding to the
|
|
chosen name in the template, e.g.
|
|
[mypetclinic.cnoe.localtest.me](https://mypetclinic.cnoe.localtest.me).
|
|
|
|
### Build Customizations
|
|
|
|
The existing GitHub Actions workflows in the upstream PetClinic are overwritten
|
|
by the app template as they are not 100% compatible with Forgejo Actions. This
|
|
affects predominantly the coordinates of actions as Forgejo can download
|
|
actions from other platforms and defaults to actions hosted on
|
|
`code.forgejo.org`. Thus, actions from GitHub have to be marked as such
|
|
specifically to be found.
|
|
|
|
Furthermore, the current runner setup does not support nested containerization,
|
|
yet. Consequently, all container image builds and interactions avoid the need
|
|
for a container engine and opt for alternative tooling such as Google Jib or
|
|
evaluating tarballs of image layers.
|
|
|
|
### Deployment
|
|
|
|
ArgoCD creates a synchronized deployment from the resources in the git
|
|
repository into a dedicated namespace. It contains the deployment of a
|
|
PostgreSQL database and the PetClinic Java app, as well as Ingress and
|
|
monitoring definitions.
|
|
|
|
The Prometheus instance included in the IDP stack is instructed to scrape data
|
|
from exposed monitoring endpoints on the Java application. The gathered data
|
|
can be analyzed in Grafana. Fitting dashboards are currently not part of the
|
|
deployment but can be easily imported from Grafana Cloud, board
|
|
[4701](https://grafana.com/grafana/dashboards/4701-jvm-micrometer/) is quite
|
|
capable of displaying JVM stats provided by Spring Boot's default monitoring.
|