forked from DevFW-CICD/edp-doc
docs(petclinic): some adjustments to the petclinic doc
This commit is contained in:
parent
559cff4d28
commit
5450db4d3d
1 changed files with 21 additions and 13 deletions
|
@ -19,7 +19,7 @@ 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.
|
||||
1. Create a new deployment in ArgoCD.
|
||||
|
||||
|
||||
After the code is pushed into Forgejo the configured workflows in the git
|
||||
|
@ -32,26 +32,34 @@ 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. [https://mypetclinic.cnoe.localtest.me].
|
||||
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
|
||||
### 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 on `code.forgejo.org`.
|
||||
Thus, actions from GitHub have to be marked as such specifically.
|
||||
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 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.
|
||||
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 instances included in the IDP stack is
|
||||
instructed to scrape data from exposed monitoring endpoints on the Java
|
||||
application.
|
||||
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.
|
||||
|
|
Loading…
Reference in a new issue