Migrate all repos into monorepo context folders
Bahn: aisupport, Analyse-O2C-C2S, awesome-bahn-mcp-servers, beam-mcp,
Confluence_Bot, db-planet-mcp-server, O2C-Harness, project-audit,
Projekt-KIQ-HP, teamlandkarte-mcp
Dhive: Jury-Voting
Privat: CV, NoteGraph (NOTE: NoteGraph needs complete redo after consolidation)
Shared: AI-Orchestrator, OrgMyLife, power_skills_and_more
Shared/references: symphony (read-only)
Bahn repos remain available as independent remotes - this monorepo
pulls them in via subtree, the originals are untouched.
This commit is contained in:
+9
@@ -0,0 +1,9 @@
|
||||
# camunda-events
|
||||
|
||||
> Quelle: https://git.tech.rz.db.de/bestellsystem1/apis/camunda-events
|
||||
|
||||
== Camunda-Events
|
||||
|
||||
Projekt zur Spezifikation des Publizierungsformats für Camunda-Ereignisse zur Verwendung im Camunda Point-in-Time-Recovery.
|
||||
|
||||
|
||||
@@ -0,0 +1,59 @@
|
||||
# kundenAdmin
|
||||
|
||||
> Quelle: https://git.tech.rz.db.de/bestellsystem1/apis/kundenAdmin
|
||||
|
||||
# kundenAdmin
|
||||
|
||||
|
||||
|
||||
## Getting started
|
||||
|
||||
To make it easy for you to get started with GitLab, here's a list of recommended next steps.
|
||||
|
||||
Already a pro? Just edit this README.md and make it your own. Want to make it easy? [Use the template at the bottom](#editing-this-readme)!
|
||||
|
||||
## Add your files
|
||||
|
||||
- [ ] [Create](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#create-a-file) or [upload](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#upload-a-file) files
|
||||
- [ ] [Add files using the command line](https://docs.gitlab.com/ee/gitlab-basics/add-file.html#add-a-file-using-the-command-line) or push an existing Git repository with the following command:
|
||||
|
||||
```
|
||||
cd existing_repo
|
||||
git remote add origin https://git.tech.rz.db.de/bestellsystem1/apis/kundenAdmin.git
|
||||
git branch -M main
|
||||
git push -uf origin main
|
||||
```
|
||||
|
||||
## Integrate with your tools
|
||||
|
||||
- [ ] [Set up project integrations](https://git.tech.rz.db.de/bestellsystem1/apis/kundenAdmin/-/settings/integrations)
|
||||
|
||||
## Collaborate with your team
|
||||
|
||||
- [ ] [Invite team members and collaborators](https://docs.gitlab.com/ee/user/project/members/)
|
||||
- [ ] [Create a new merge request](https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html)
|
||||
- [ ] [Automatically close issues from merge requests](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically)
|
||||
- [ ] [Enable merge request approvals](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/)
|
||||
- [ ] [Set auto-merge](https://docs.gitlab.com/ee/user/project/merge_requests/merge_when_pipeline_succeeds.html)
|
||||
|
||||
## Test and Deploy
|
||||
|
||||
Use the built-in continuous integration in GitLab.
|
||||
|
||||
- [ ] [Get started with GitLab CI/CD](https://docs.gitlab.com/ee/ci/quick_start/index.html)
|
||||
- [ ] [Analyze your code for known vulnerabilities with Static Application Security Testing (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/)
|
||||
- [ ] [Deploy to Kubernetes, Amazon EC2, or Amazon ECS using Auto Deploy](https://docs.gitlab.com/ee/topics/autodevops/requirements.html)
|
||||
- [ ] [Use pull-based deployments for improved Kubernetes management](https://docs.gitlab.com/ee/user/clusters/agent/)
|
||||
- [ ] [Set up protected environments](https://docs.gitlab.com/ee/ci/environments/protected_environments.html)
|
||||
|
||||
***
|
||||
|
||||
# Editing this README
|
||||
|
||||
When you're ready to make this README your own, just edit this file and use the handy template below (or feel free to structure it however you want - this is just a starting point!). Thanks to [makeareadme.com](https://www.makeareadme.com/) for this template.
|
||||
|
||||
## Suggestions for a good README
|
||||
|
||||
Every project is different, so consider which of these sections apply to yours. The sections used in the template are suggestions for most open source projects. Also keep in mind that while a README can be too long and detailed, too long is better than too short. If you think your README is too long, consider utilizing another form of documentation rather than cutting out inf
|
||||
|
||||
... (gekuerzt)
|
||||
@@ -0,0 +1,61 @@
|
||||
# nurPMW
|
||||
|
||||
> Quelle: https://git.tech.rz.db.de/bestellsystem1/apis/nurPMW
|
||||
|
||||
# nurPMW
|
||||
|
||||
|
||||
|
||||
## Getting started
|
||||
|
||||
To make it easy for you to get started with GitLab, here's a list of recommended next steps.
|
||||
|
||||
Already a pro? Just edit this README.md and make it your own. Want to make it easy? [Use the template at the bottom](#editing-this-readme)!
|
||||
|
||||
## Add your files
|
||||
|
||||
- [ ] [Create](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#create-a-file) or [upload](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#upload-a-file) files
|
||||
- [ ] [Add files using the command line](https://docs.gitlab.com/ee/gitlab-basics/add-file.html#add-a-file-using-the-command-line) or push an existing Git repository with the following command:
|
||||
|
||||
```
|
||||
cd existing_repo
|
||||
git remote add origin https://git.tech.rz.db.de/bestellsystem1/apis/nurPMW.git
|
||||
git branch -M main
|
||||
git push -uf origin main
|
||||
```
|
||||
|
||||
## Integrate with your tools
|
||||
|
||||
- [ ] [Set up project integrations](https://git.tech.rz.db.de/bestellsystem1/apis/nurPMW/-/settings/integrations)
|
||||
|
||||
## Collaborate with your team
|
||||
|
||||
- [ ] [Invite team members and collaborators](https://docs.gitlab.com/ee/user/project/members/)
|
||||
- [ ] [Create a new merge request](https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html)
|
||||
- [ ] [Automatically close issues from merge requests](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically)
|
||||
- [ ] [Enable merge request approvals](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/)
|
||||
- [ ] [Set auto-merge](https://docs.gitlab.com/ee/user/project/merge_requests/merge_when_pipeline_succeeds.html)
|
||||
|
||||
## Test and Deploy
|
||||
|
||||
Use the built-in continuous integration in GitLab.
|
||||
|
||||
- [ ] [Get started with GitLab CI/CD](https://docs.gitlab.com/ee/ci/quick_start/index.html)
|
||||
- [ ] [Analyze your code for known vulnerabilities with Static Application Security Testing (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/)
|
||||
- [ ] [Deploy to Kubernetes, Amazon EC2, or Amazon ECS using Auto Deploy](https://docs.gitlab.com/ee/topics/autodevops/requirements.html)
|
||||
- [ ] [Use pull-based deployments for improved Kubernetes management](https://docs.gitlab.com/ee/user/clusters/agent/)
|
||||
- [ ] [Set up protected environments](https://docs.gitlab.com/ee/ci/environments/protected_environments.html)
|
||||
|
||||
***
|
||||
|
||||
# Editing this README
|
||||
|
||||
When you're ready to make this README your own, just edit this file and use the handy template below (or feel free to structure it however you want - this is just a starting point!). Thanks to [makeareadme.com](https://www.makeareadme.com/) for this template.
|
||||
|
||||
## Suggestions for a good README
|
||||
|
||||
Every project is different, so consider which of these sections apply to yours. The sections used in the template are suggestions for most open source projects. Also keep in mind that while a README can be too long and detailed, too long is better than too short. If you think your README is too long, consider utilizing another form of documentation rather than cutting out information.
|
||||
|
||||
## N
|
||||
|
||||
... (gekuerzt)
|
||||
+59
@@ -0,0 +1,59 @@
|
||||
# partnerverwaltungAdmin
|
||||
|
||||
> Quelle: https://git.tech.rz.db.de/bestellsystem1/apis/partnerverwaltungAdmin
|
||||
|
||||
# partnerverwaltungAdmin
|
||||
|
||||
|
||||
|
||||
## Getting started
|
||||
|
||||
To make it easy for you to get started with GitLab, here's a list of recommended next steps.
|
||||
|
||||
Already a pro? Just edit this README.md and make it your own. Want to make it easy? [Use the template at the bottom](#editing-this-readme)!
|
||||
|
||||
## Add your files
|
||||
|
||||
- [ ] [Create](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#create-a-file) or [upload](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#upload-a-file) files
|
||||
- [ ] [Add files using the command line](https://docs.gitlab.com/ee/gitlab-basics/add-file.html#add-a-file-using-the-command-line) or push an existing Git repository with the following command:
|
||||
|
||||
```
|
||||
cd existing_repo
|
||||
git remote add origin https://git.tech.rz.db.de/bestellsystem1/apis/partnerverwaltungAdmin.git
|
||||
git branch -M main
|
||||
git push -uf origin main
|
||||
```
|
||||
|
||||
## Integrate with your tools
|
||||
|
||||
- [ ] [Set up project integrations](https://git.tech.rz.db.de/bestellsystem1/apis/partnerverwaltungAdmin/-/settings/integrations)
|
||||
|
||||
## Collaborate with your team
|
||||
|
||||
- [ ] [Invite team members and collaborators](https://docs.gitlab.com/ee/user/project/members/)
|
||||
- [ ] [Create a new merge request](https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html)
|
||||
- [ ] [Automatically close issues from merge requests](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically)
|
||||
- [ ] [Enable merge request approvals](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/)
|
||||
- [ ] [Set auto-merge](https://docs.gitlab.com/ee/user/project/merge_requests/merge_when_pipeline_succeeds.html)
|
||||
|
||||
## Test and Deploy
|
||||
|
||||
Use the built-in continuous integration in GitLab.
|
||||
|
||||
- [ ] [Get started with GitLab CI/CD](https://docs.gitlab.com/ee/ci/quick_start/index.html)
|
||||
- [ ] [Analyze your code for known vulnerabilities with Static Application Security Testing (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/)
|
||||
- [ ] [Deploy to Kubernetes, Amazon EC2, or Amazon ECS using Auto Deploy](https://docs.gitlab.com/ee/topics/autodevops/requirements.html)
|
||||
- [ ] [Use pull-based deployments for improved Kubernetes management](https://docs.gitlab.com/ee/user/clusters/agent/)
|
||||
- [ ] [Set up protected environments](https://docs.gitlab.com/ee/ci/environments/protected_environments.html)
|
||||
|
||||
***
|
||||
|
||||
# Editing this README
|
||||
|
||||
When you're ready to make this README your own, just edit this file and use the handy template below (or feel free to structure it however you want - this is just a starting point!). Thanks to [makeareadme.com](https://www.makeareadme.com/) for this template.
|
||||
|
||||
## Suggestions for a good README
|
||||
|
||||
Every project is different, so consider which of these sections apply to yours. The sections used in the template are suggestions for most open source projects. Also keep in mind that while a README can be too long and detailed, too long is better than too short. If you think your README is too long, consider utilizing another form of document
|
||||
|
||||
... (gekuerzt)
|
||||
+93
@@ -0,0 +1,93 @@
|
||||
# produktionsauftrag
|
||||
|
||||
> Quelle: https://git.tech.rz.db.de/bestellsystem1/apis/produktionsauftrag
|
||||
|
||||
== Produktionsauftrag-OpenApi
|
||||
|
||||
OpenAPI-Repo
|
||||
https://git.tech.rz.db.de/bestellsystem1/docs/dokumentation/-/blob/master/doc/architecture/decisions/0037-api-publication.adoc[ADR 37]
|
||||
|
||||
Beinhaltet die OpenApi-Yaml Files für die Produktionsauftrag-OpenApi sowie eine Build-Pipeline zur Generierung von Dokumentationen
|
||||
und Server/Client Codes.
|
||||
|
||||
=== Produktionsauftrag als Maven-Dependency
|
||||
|
||||
Die TDM OpenApi-Yaml Files, welche auch bei der Produktionsauftrag-OpenApi verwendet werden, werden aus dem Maven-Artefakt zur Build-Zeit
|
||||
geladen.
|
||||
|
||||
[source]
|
||||
----
|
||||
<dependency>
|
||||
<groupId>com.dbnetz.bestellsystem</groupId>
|
||||
<artifactId>produktionsauftrag</artifactId>
|
||||
<version><!-- Version --></version>
|
||||
<dependency>
|
||||
----
|
||||
|
||||
=== Linter
|
||||
** https://stoplight.io/open-source/spectral/[spectral]
|
||||
|
||||
=== Pipeline Übersicht
|
||||
|
||||
[plantuml]
|
||||
----
|
||||
database "GitLab Group bestellsystem1/api-repositories/" as repo {
|
||||
folder "produktionsauftag" as apispec
|
||||
folder "kundendaten" as apispec2
|
||||
folder "..." as etc
|
||||
apispec -[hidden]> apispec2
|
||||
apispec2 -[hidden]> etc
|
||||
}
|
||||
|
||||
database Artifactory {
|
||||
folder "Maven repo" as maven_pkg {
|
||||
file ".jar" as file_jar
|
||||
file ".pom" as file_pom
|
||||
}
|
||||
folder "generic repo" as generic_pkg {
|
||||
file ".yaml" as file_yaml
|
||||
file ".json" as file_json
|
||||
file ".html" as file_html
|
||||
' only layout:
|
||||
file_yaml -[hidden]> file_json
|
||||
}
|
||||
}
|
||||
|
||||
rectangle "Build & Publish Pipeline" {
|
||||
node "pom_version" as inject_version
|
||||
node build_application
|
||||
node "pages" as publish_docs
|
||||
node lint_openapi_spectral
|
||||
node publish_artifactory_java
|
||||
node publish_artifactory_generic
|
||||
}
|
||||
|
||||
rectangle "GitLab-Page\n(zusätzliche Formate zum Testen, nicht-versioniert, nicht-persistent)" as gitlab_page {
|
||||
file plantuml
|
||||
file adoc
|
||||
file jmeter
|
||||
file "Lint Report"
|
||||
file "Typescript Client"
|
||||
file "OpenAPI JSON" as json
|
||||
file "OpenAPI YAML" as yaml
|
||||
file "HTML Documentation" as html
|
||||
}
|
||||
|
||||
apispec --> inject_version
|
||||
inject_version --> build_application : pom.xml
|
||||
|
||||
build_application --> lint_openapi_spectral : .yaml
|
||||
build_application --> publish_artifactory_java : .jar
|
||||
publish_artifactory_java --> maven_pkg : mvn deploy
|
||||
|
||||
build_application --> publish_artifactory_generic : other files
|
||||
publish_artifactory_generic --> generic_pkg : upload\nYAML/JSON spec,\nand HTML doc
|
||||
|
||||
build_application --> publish_docs : other files
|
||||
publish_docs ---> gitlab_page : copy all
|
||||
----
|
||||
|
||||
== GitLab-Page
|
||||
|
||||
https://git.tech.rz.db.de/bestellsystem1/apis/produktionsauftrag
|
||||
|
||||
@@ -0,0 +1,59 @@
|
||||
# pzp
|
||||
|
||||
> Quelle: https://git.tech.rz.db.de/bestellsystem1/apis/pzp
|
||||
|
||||
# pzp
|
||||
|
||||
|
||||
|
||||
## Getting started
|
||||
|
||||
To make it easy for you to get started with GitLab, here's a list of recommended next steps.
|
||||
|
||||
Already a pro? Just edit this README.md and make it your own. Want to make it easy? [Use the template at the bottom](#editing-this-readme)!
|
||||
|
||||
## Add your files
|
||||
|
||||
- [ ] [Create](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#create-a-file) or [upload](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#upload-a-file) files
|
||||
- [ ] [Add files using the command line](https://docs.gitlab.com/ee/gitlab-basics/add-file.html#add-a-file-using-the-command-line) or push an existing Git repository with the following command:
|
||||
|
||||
```
|
||||
cd existing_repo
|
||||
git remote add origin https://git.tech.rz.db.de/bestellsystem1/apis/pzp.git
|
||||
git branch -M main
|
||||
git push -uf origin main
|
||||
```
|
||||
|
||||
## Integrate with your tools
|
||||
|
||||
- [ ] [Set up project integrations](https://git.tech.rz.db.de/bestellsystem1/apis/pzp/-/settings/integrations)
|
||||
- [ ] [Set up project integrations](https://git.tech.rz.db.de/bestellsystem1/apis/pzp/-/settings/integrations)
|
||||
|
||||
## Collaborate with your team
|
||||
|
||||
- [ ] [Invite team members and collaborators](https://docs.gitlab.com/ee/user/project/members/)
|
||||
- [ ] [Create a new merge request](https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html)
|
||||
- [ ] [Automatically close issues from merge requests](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically)
|
||||
- [ ] [Enable merge request approvals](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/)
|
||||
- [ ] [Automatically merge when pipeline succeeds](https://docs.gitlab.com/ee/user/project/merge_requests/merge_when_pipeline_succeeds.html)
|
||||
|
||||
## Test and Deploy
|
||||
|
||||
Use the built-in continuous integration in GitLab.
|
||||
|
||||
- [ ] [Get started with GitLab CI/CD](https://docs.gitlab.com/ee/ci/quick_start/index.html)
|
||||
- [ ] [Analyze your code for known vulnerabilities with Static Application Security Testing(SAST)](https://docs.gitlab.com/ee/user/application_security/sast/)
|
||||
- [ ] [Deploy to Kubernetes, Amazon EC2, or Amazon ECS using Auto Deploy](https://docs.gitlab.com/ee/topics/autodevops/requirements.html)
|
||||
- [ ] [Use pull-based deployments for improved Kubernetes management](https://docs.gitlab.com/ee/user/clusters/agent/)
|
||||
- [ ] [Set up protected environments](https://docs.gitlab.com/ee/ci/environments/protected_environments.html)
|
||||
|
||||
***
|
||||
|
||||
# Editing this README
|
||||
|
||||
When you're ready to make this README your own, just edit this file and use the handy template below (or feel free to structure it however you want - this is just a starting point!). Thank you to [makeareadme.com](https://www.makeareadme.com/) for this template.
|
||||
|
||||
## Suggestions for a good README
|
||||
Every project is different, so consider which of these sections apply to yours. The sections used in the template are suggestions for most open source projects. Also keep in mind that while a README can be too long and detailed, too long is better than too short
|
||||
|
||||
... (gekuerzt)
|
||||
+7
@@ -0,0 +1,7 @@
|
||||
# tadef-connector
|
||||
|
||||
> Quelle: https://git.tech.rz.db.de/bestellsystem1/apis/tadef-connector
|
||||
|
||||
== TaDeF-Connector API
|
||||
|
||||
Projekt zur Spezifikation der API für den Zugriff von TaDeF auf CommonInterface-TafTap-Nachrichten.
|
||||
+9
@@ -0,0 +1,9 @@
|
||||
# kiro-steering
|
||||
|
||||
> Quelle: https://git.tech.rz.db.de/bestellsystem1/docs/kiro-steering
|
||||
|
||||
# kiro-steering
|
||||
|
||||
|
||||
Hier landen verschiedene Steering-Dateien, welche uns in PathOS das Leben einfacher machen sollen.
|
||||
|
||||
+34
@@ -0,0 +1,34 @@
|
||||
# msk-topic-permissions
|
||||
|
||||
> Quelle: https://git.tech.rz.db.de/bestellsystem1/docs/msk-topic-permissions
|
||||
|
||||
# msk-topic-permissions
|
||||
|
||||
Page URL: **https://bestellsystem1.gitpages.tech.rz.db.de/docs/msk-topic-permissions/**
|
||||
|
||||
HTML-Report bzw. GitLab-Page mit Übersicht von MSK-Topics und zugehörigen IAM-Roles für Producer/Consumer-Zugriff.
|
||||
|
||||
Ein Klon-Projekt von https://git.tech.rz.db.de/bestellsystem1/docs/installierte-versionen, nutzt dasselbe Image für Python, Jinja2 usw.
|
||||
|
||||
## Einschränkung
|
||||
|
||||
Die Daten werden nur aus der CNP API gelesen. In dieser API definieren wir keine Topics, sondern nur die Role-Policies. => Das heißt dieses Tool zeigt by design nie welche Topics vorhanden/angelegt sind (dafür bräuchten wir zusätzlich einen Kafka-Client zum Nachsehen).
|
||||
Dieses Tool zeigt nur (!) für welche Topics wir eingeschränkte Rechte einräumen, sowie in einer zweiten Tabelle welche Admin-Roles (`general-access`) per Cluster vorhanden sind.
|
||||
|
||||
## ABN und Prod: Lokale Ausführung
|
||||
|
||||
Weil wir bei CNP keinen Tech-User haben können wir in der Pipeline keine Werte für ABN oder Prod auslesen.
|
||||
|
||||
Um eine ABN-Übersicht zu bekommen kann man das Tool manuell ausführen, das erfordert ein installiertes Python mit mit jinja2-Library (detailliertere Anleitung in [infra/installierte-versionen-image](https://git.tech.rz.db.de/bestellsystem1/infra/installierte-versionen-image#user-content-lokales-testen), hier sollte ein `pip install jinja2` reichen).
|
||||
|
||||
Kommandos sind dann:
|
||||
```shell
|
||||
cnp_api_abn
|
||||
kubectl get consumers.kafka.cnp.comp.db.de,producers.kafka.cnp.comp.db.de,rolepolicyattachments.iam.cnp.comp.db.de -o json > data.json
|
||||
python3 ./compile_report.py -f data.json
|
||||
```
|
||||
|
||||
Damit wird die public/index.html mit allen wesentlichen Daten geschrieben.
|
||||
|
||||
Um die Tabelle wie in der GitLab-Page sortier und durchsuchbar zu machen, kann man aus dem letzten `pages`-Job noch alle Artefakt-Dateien als .zip herunterladen und mit nach public/ schreiben.
|
||||
|
||||
+35
@@ -0,0 +1,35 @@
|
||||
# appmesh-proxy
|
||||
|
||||
> Quelle: https://git.tech.rz.db.de/bestellsystem1/infra/appmesh-proxy
|
||||
|
||||
# appmesh-proxy
|
||||
|
||||
  
|
||||
|
||||
Helm chart to deploy appmesh-proxy which based on [envoy](https://www.envoyproxy.io/).
|
||||
|
||||
This is a mirror of upstream helm chart [envoy](https://github.com/slamdev/helm-charts/tree/master/charts/envoy), which we use to build our own modified helm chart and push it at the end in the Artifactory.
|
||||
|
||||
## Usage
|
||||
|
||||
The appmesh-proxy will be used for microservices (who are deployed into AppMesh) to make external http/https communication possible to external addresses (like EVUs).
|
||||
Technically the proxy acts as "CONNECT proxy", who create initially a tunnel and forward all traffic (tcp based) to the webproxy of Deutsche Bahn. It was necessary because external traffic out of AppMesh was not possible, see for more details ticket [O2CSYS-780](https://arija.jaas.service.deutschebahn.com/browse/O2CSYS-780) and the implemention ticket [O2CSYS-785](https://arija.jaas.service.deutschebahn.com/browse/O2CSYS-785).
|
||||
|
||||
## Maintainers
|
||||
|
||||
| Name | Email | Url |
|
||||
| ---- | ------ | --- |
|
||||
| Team Steam | O2C.TeamSTeam-dbnetz@deutschebahn.com | |
|
||||
| Michael Jahn | michael.mh.jahn-extern@deutschebahn.com | |
|
||||
| slamdev | <valentin.fedoskin@gmail.com> | |
|
||||
|
||||
## Values
|
||||
|
||||
| Key | Type | Default | Description |
|
||||
|-----|------|---------|-------------|
|
||||
| additionalResources | list | `[]` | list of additional resources to create (are processed via `tpl` function) |
|
||||
| affinity | object | `{}` | affinity for scheduler pod assignment |
|
||||
| args | list | `[]` | extra args to pass to container |
|
||||
| configYaml | string | `"admin:\n access_log_path: /tmp/admin_access.log\n address:\n socket_address:\n protocol: TCP\n address: 0.0.0.0\n port_value: 9901\nstatic_resources:\n listeners:\n - name: listener_0\n address:\n socket_address:\n protocol: TCP\n address: 0.0.0.0\n port_value: 10000\n filter_chains:\n - filters:\n - name: envoy.filters.network.http_connection_manager\n typed_config:\n \"@type\": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager\n stat_prefix: ingress_http\n access_log:\n - name: envoy.access_loggers.file\n typed_config:\n \"@type\": type.googleapis.com/envoy.extensions.access_loggers.file.v3.FileAccessLog\n # For the demo config in the Docker container we use:\n # - system logs -> `/dev/stderr`\n # - (listener) access_logs -> `/dev/stdout`\n path: /dev/stdout\n route_config:\n name: local_route\n virtual_hosts:\n - name: local_service\n domains: [\"*\"]\n routes:\n
|
||||
|
||||
... (gekuerzt)
|
||||
+88
@@ -0,0 +1,88 @@
|
||||
# camunda-backup-restore
|
||||
|
||||
> Quelle: https://git.tech.rz.db.de/bestellsystem1/infra/camunda-backup-restore
|
||||
|
||||
# Backup und Restore für Camunda 8 und OpenSearch
|
||||
|
||||
## Backup and Restore implementation steps
|
||||
|
||||
** Opensearch Repo anlegen
|
||||
|
||||
* <https://cnp.gitpages.tech.rz.db.de/core/docs/cnp/latest/cnp-portfolio/opensearch/usage.html#backup>
|
||||
|
||||
** OpenSearch Dashbaord anpassen
|
||||
|
||||
* BackendRolle Mapping
|
||||
* <https://vpc-bsz-dev-bsz-demo-3-jgxjwpbunideo4qzu2eoifffaa.eu-central-1.es.amazonaws.com/_dashboards/app/security-dashboards-plugin#/roles/view/manage_snapshots>
|
||||
|
||||
** Bestellsystem-Deployment anpassen
|
||||
|
||||
* Zeebe Config
|
||||
* <https://git.tech.rz.db.de/bestellsystem1/infra/bestellsystem-deployment/-/merge_requests/1872/diffs#6d7038132e7c39b16160ad4c9cc7d875cf2e5dac>
|
||||
* <https://git.tech.rz.db.de/bestellsystem1/infra/bestellsystem-deployment/-/merge_requests/1872/diffs#c95299785aac640dca3f5206316f4f135d49e1ca>
|
||||
* Operate Config
|
||||
* <https://git.tech.rz.db.de/bestellsystem1/infra/bestellsystem-deployment/-/merge_requests/1872/diffs#970c25ca67b665a2318c9ce9112faa22629facaa>
|
||||
* Tasklist Config
|
||||
* <https://git.tech.rz.db.de/bestellsystem1/infra/bestellsystem-deployment/-/merge_requests/1872/diffs#fc08b99dcf79633c4814cc111c8011da6264e9c7>
|
||||
|
||||
* Limitation/Manual Schritt
|
||||
|
||||
* Keine Backup des S3 Bucket über CNP API aktuell möglich
|
||||
* OpenSearchBackend Rolle mapping geht nicht als CNP API
|
||||
* Snapshot Repository (s3 Bucket) registrien geht nich als CNP API
|
||||
* OpenSearch Snapshot Repository muss manuell angelegt werden
|
||||
|
||||
## Backup-Prozess mit Curl und REST-API
|
||||
|
||||
Der Backup-Prozess umfasst die Sicherung von OpenSearch-Daten und Camunda 8-Komponenten.
|
||||
Die Sicherung erfolgt über Kubernetes-Jobs, die in regelmäßigen Abständen durch einen CronJob
|
||||
ausgelöst werden.
|
||||
|
||||
### Schritte für das Backup
|
||||
|
||||
1. **Export-Pause für Zeebe**:
|
||||
|
||||
* Der Export von Zeebe-Daten wird pausiert, um eine konsistente Sicherung zu
|
||||
gewährleisten.
|
||||
|
||||
2. **OpenSearch-Backup**:
|
||||
|
||||
* Ein Snapshot der OpenSearch-Daten wird erstellt.
|
||||
* <https://cnp.gitpages.tech.rz.db.de/core/docs/cnp/latest/cnp-portfolio/opensearch/usage.html>
|
||||
|
||||
3. **Zeebe-Backup**:
|
||||
|
||||
* Die Zeebe-Daten werden gesichert.
|
||||
|
||||
4. **Export-Wiederaufnahme für Zeebe**:
|
||||
|
||||
* Nach Abschluss der Sicherung wird der Export wieder aufgenommen.
|
||||
|
||||
### Schritte für die Wiederherstellung
|
||||
|
||||
1. **Skalierung der Komponenten**:
|
||||
|
||||
* Vor der Wiederherstellung werden die Komponenten skaliert.
|
||||
|
||||
2. **Löschen von OpenSearch-Indizes**:
|
||||
|
||||
* Alle nicht-systemrelevanten Indizes werden gelöscht.
|
||||
|
||||
3. **Wiederherstellung von OpenSearch-Daten**:
|
||||
|
||||
* Die OpenSearch-Daten werden wiederhergestellt.
|
||||
* <https://cnp.gitpages.tech.rz.db.de/core/docs/cnp/latest/cnp-portfolio/opensearch/usage.html>
|
||||
|
||||
4. **Wiederherstellung von Zeebe-Daten**:
|
||||
|
||||
* Die Zeebe-Daten werden aus dem Backup wiederhergestellt.
|
||||
* <https://docs.camunda.io/docs/self-managed/operational-guides/backup-restore/backup-and-restore/>
|
||||
|
||||
5. **Skalierung der Komponenten**:
|
||||
|
||||
* Nach Abschluss der Wiederherstellung werden die Komponenten skaliert.
|
||||
|
||||
* OpenSearch Backup und Restore:
|
||||
<https://cnp.gitpages.tech.rz.db.de/cor
|
||||
|
||||
... (gekuerzt)
|
||||
+37
@@ -0,0 +1,37 @@
|
||||
# conventional-changelog-builder
|
||||
|
||||
> Quelle: https://git.tech.rz.db.de/bestellsystem1/infra/conventional-changelog-builder
|
||||
|
||||
# conventional-changelog-builder
|
||||
|
||||
> [!warning] Dieses Repo ist Deprecated
|
||||
> Das erzeugen des Changelog erfolgt ab Version [5.13.0](https://git.tech.rz.db.de/bestellsystem1/infra/ci-files/-/releases/5.13.0) mittels `git-cliff` im CI-Job [git_create_changelog](https://git.tech.rz.db.de/bestellsystem1/infra/ci-files/-/blob/master/dist/git/job-release-sharedcode.yaml?ref_type=heads#L50).
|
||||
|
||||
[](https://git.tech.rz.db.de/bestellsystem1/conventional-changelog-builder/commits/master)
|
||||
|
||||
Repository beinhaltet alle nötigen Tools zur Erzeugung von Change Logs
|
||||
innerhalb der CI/CD Pipeline.
|
||||
|
||||
## Changelog erzeugen
|
||||
|
||||
Die Datei `.gitlab-ci.yml` um das folgende Snippet erweitern
|
||||
|
||||
```yaml
|
||||
git_create_changelog:
|
||||
stage: post_build_image
|
||||
image: bestellsystem-docker-prod-local.bahnhub.tech.rz.db.de/conventional-changelog-builder:latest
|
||||
tags:
|
||||
- build
|
||||
only:
|
||||
refs:
|
||||
- master
|
||||
script:
|
||||
- generate_changelog_nocommit
|
||||
```
|
||||
|
||||
## customconfig.js
|
||||
|
||||
Mit unserer Config-Datei erweitern wir den Parser, so dass er nicht mehr conventional commits, sondern unser Bestellsystem-Format mit Jira-ID liest.
|
||||
|
||||
_Achtung: Es werden nur die Einträge in das Changelog mit übernommen, die dem Bestellsystem-Format entsprechen und deren Conventional Commit Type vom Angular-Preset nicht ignoriert wird._
|
||||
|
||||
+66
@@ -0,0 +1,66 @@
|
||||
# infrastruktur-basis-container
|
||||
|
||||
> Quelle: https://git.tech.rz.db.de/bestellsystem1/infra/infrastruktur-basis-container
|
||||
|
||||
# infrastruktur-basis-container
|
||||
|
||||
Enthält die Definition des Basis Containers für die Durchführung von Operating Tasks,
|
||||
sowohl in GitLab-Jobs als auch für manuelles Testen/Debuggen.
|
||||
|
||||
Basiert auf dem Image [db-cd-lib/aws-cli](https://git.tech.rz.db.de/db-cd-lib/aws-cli) das wir hier nur um unser Toolset ergänzen.
|
||||
|
||||
Vorher haben wir die [db-cd-lib/ultimate-cloud-cli](https://git.tech.rz.db.de/db-cd-lib/ultimate-cloud-cli) als Basis benutzt, mit fast 1,5 Gb war uns das dann zu groß.
|
||||
|
||||
|
||||
Enthaltene Tools:
|
||||
|
||||
- schon in aws-cli
|
||||
- bash
|
||||
- curl
|
||||
- git
|
||||
- [jq](https://stedolan.github.io/jq/)
|
||||
- aws-cli
|
||||
- zip und unzip
|
||||
- von uns ergänzt
|
||||
- PostgreSQL client
|
||||
- [sops](https://github.com/mozilla/sops) (sowie GPG und age)
|
||||
- [yq](https://github.com/mikefarah/yq/)
|
||||
- kubectl
|
||||
- [Helm](https://helm.sh/)
|
||||
- diff plugin
|
||||
- secrets plugin
|
||||
- GNU Coreutils (für unsere Cleanup-Jobs in [infra/infrastruktur-scripte](https://git.tech.rz.db.de/bestellsystem1/infra/infrastruktur-scripte/-/jobs/77339980))
|
||||
- uuidgen (zur Zeit für den Deployment-Job `generate_env_json`)
|
||||
- Python3 und [PyYAML](https://pyyaml.org/) (für ?)
|
||||
|
||||
## Layer
|
||||
|
||||
Dieses Image ist abgeleitet von
|
||||
|
||||
1. Alpine-Linux
|
||||
2. https://git.tech.rz.db.de/db-cd-lib/aws-cli
|
||||
|
||||
|
||||
```plantuml
|
||||
rectangle "Linux-Distribution: Alpine" as base
|
||||
rectangle "aws-cli" as aws
|
||||
rectangle "Bestellsystem-Anpassung" as bsz
|
||||
|
||||
base <-- aws : FROM
|
||||
aws <-- bsz : FROM
|
||||
```
|
||||
|
||||
## Security Fixes
|
||||
|
||||
Unser upstream Image [db-cd-lib/aws-cli](https://git.tech.rz.db.de/db-cd-lib/aws-cli) hat leider keinen strengen Security-Checks, deshalb brauchen wir viele eigene Anpassungen um den trivy-Scan zu bestehen.
|
||||
|
||||
Einige Tools, die wir im Bestellsystem nicht benutzen, entfernen wir einfach aus dem Image.
|
||||
Für einige andere schreiben wir explizite Versions-Updates ins `Dockerfile`.
|
||||
Eine sehr hilfreiche Website dafür ist die [Alpine Package Suche](https://pkgs.alpinelinux.org/packages?name=&branch=v3.16&repo=&arch=x86_64&maintainer=).
|
||||
|
||||
## Tests
|
||||
|
||||
In der Build-Pipeline haben wir den Job `run_system_test`, in dem wir einfache Tests der installierten Tools einbauen können. Bisher prüfen wir nur die Existenz und zeigen die Versionsnummer an.
|
||||
|
||||
Idealerweise sollten alle anderen Projekte, die dieses Image benutzen eigene Tests für ihren Use-Case implementieren. Damit sollten bei renovate-Merge-Requests dann breaking changes erkannt und der Merge verhindert werden.
|
||||
|
||||
+25
@@ -0,0 +1,25 @@
|
||||
# infrastruktur-kafka-container
|
||||
|
||||
> Quelle: https://git.tech.rz.db.de/bestellsystem1/infra/infrastruktur-kafka-container
|
||||
|
||||
# infrastruktur-kafka-container
|
||||
|
||||
Enthält die Definition des Kafka Containers für die Durchführung von Operating Tasks im bezug auf Kafka.
|
||||
|
||||
Basiert auf dem Image [bitnami/kafka](https://hub.docker.com/r/bitnami/kafka) das wir hier nur um unser Toolset ergänzen.
|
||||
|
||||
Enthaltene Tools:
|
||||
|
||||
- schon in Kafka Image
|
||||
- von uns ergänzt
|
||||
- [yq](https://github.com/mikefarah/yq/)
|
||||
- [aws-msk-iam-auth](https://github.com/aws/aws-msk-iam-auth)
|
||||
- [jq](https://github.com/jqlang/jq)
|
||||
|
||||
## Layer
|
||||
|
||||
Dieses Image ist abgeleitet von
|
||||
|
||||
1. https://hub.docker.com/r/bitnami/kafka
|
||||
|
||||
|
||||
+62
@@ -0,0 +1,62 @@
|
||||
# Kafka Topic Setup
|
||||
|
||||
> Quelle: https://git.tech.rz.db.de/bestellsystem1/infra/kafka-topic-setup
|
||||
|
||||
# Kafka Topic Setup
|
||||
|
||||
|
||||
|
||||
## Getting started
|
||||
|
||||
To make it easy for you to get started with GitLab, here's a list of recommended next steps.
|
||||
|
||||
Already a pro? Just edit this README.md and make it your own. Want to make it easy? [Use the template at the bottom](#editing-this-readme)!
|
||||
|
||||
## Add your files
|
||||
|
||||
- [ ] [Create](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#create-a-file) or [upload](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#upload-a-file) files
|
||||
- [ ] [Add files using the command line](https://docs.gitlab.com/topics/git/add_files/#add-files-to-a-git-repository) or push an existing Git repository with the following command:
|
||||
|
||||
```
|
||||
cd existing_repo
|
||||
git remote add origin https://git.tech.rz.db.de/bestellsystem1/infra/kafka-topic-setup.git
|
||||
git branch -M main
|
||||
git push -uf origin main
|
||||
```
|
||||
|
||||
## Integrate with your tools
|
||||
|
||||
- [ ] [Set up project integrations](https://git.tech.rz.db.de/bestellsystem1/infra/kafka-topic-setup/-/settings/integrations)
|
||||
|
||||
## Collaborate with your team
|
||||
|
||||
- [ ] [Invite team members and collaborators](https://docs.gitlab.com/ee/user/project/members/)
|
||||
- [ ] [Create a new merge request](https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html)
|
||||
- [ ] [Automatically close issues from merge requests](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically)
|
||||
- [ ] [Enable merge request approvals](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/)
|
||||
- [ ] [Set auto-merge](https://docs.gitlab.com/user/project/merge_requests/auto_merge/)
|
||||
|
||||
## Test and Deploy
|
||||
|
||||
Use the built-in continuous integration in GitLab.
|
||||
|
||||
- [ ] [Get started with GitLab CI/CD](https://docs.gitlab.com/ee/ci/quick_start/)
|
||||
- [ ] [Analyze your code for known vulnerabilities with Static Application Security Testing (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/)
|
||||
- [ ] [Deploy to Kubernetes, Amazon EC2, or Amazon ECS using Auto Deploy](https://docs.gitlab.com/ee/topics/autodevops/requirements.html)
|
||||
- [ ] [Use pull-based deployments for improved Kubernetes management](https://docs.gitlab.com/ee/user/clusters/agent/)
|
||||
- [ ] [Set up protected environments](https://docs.gitlab.com/ee/ci/environments/protected_environments.html)
|
||||
|
||||
***
|
||||
|
||||
# Editing this README
|
||||
|
||||
When you're ready to make this README your own, just edit this file and use the handy template below (or feel free to structure it however you want - this is just a starting point!). Thanks to [makeareadme.com](https://www.makeareadme.com/) for this template.
|
||||
|
||||
## Suggestions for a good README
|
||||
|
||||
Every project is different, so consider which of these sections apply to yours. The sections used in the template are suggestions for most open source projects. Also keep in mind that while a README can be too long and detailed, too long is better than too short. If you think your README is too long, consider utilizing another form of documentation rather than cutting out information.
|
||||
|
||||
## Name
|
||||
Choose a
|
||||
|
||||
... (gekuerzt)
|
||||
+21
@@ -0,0 +1,21 @@
|
||||
# renovate-exec
|
||||
|
||||
> Quelle: https://git.tech.rz.db.de/bestellsystem1/infra/renovate-exec
|
||||
|
||||
# RenovateBot: Dependency Updater
|
||||
|
||||
## Quickstart
|
||||
|
||||
This is not a specialized container image from the library.
|
||||
Instead it updates the dependencies for all repositories in the library.
|
||||
|
||||
You must configure two variables:
|
||||
|
||||
1. RENOVATE_GITLAB_GROUP_ID - All children projects of this group id are going to be **renovated**
|
||||
1. RENOVATE_GITLAB_TOKEN - Gitlab Token which is permitted to create MR's on these projects
|
||||
|
||||
The GitLab CI pipeline in this repository will use renovate to check your project dependencies
|
||||
(Docker Images, NPM packages, ...) for available updates.
|
||||
If one is found, it will be presented to the repository as a merge request
|
||||
For more information how to configure this see the [renovate documentation](https://docs.renovatebot.com/).
|
||||
|
||||
+54
@@ -0,0 +1,54 @@
|
||||
# umgebungs-konfiguration
|
||||
|
||||
> Quelle: https://git.tech.rz.db.de/bestellsystem1/infra/umgebungs-konfiguration
|
||||
|
||||
# umgebungs-konfiguration
|
||||
|
||||
Enthält die Konfiguration der Kubernetes-Namespaces für alle Artefakte des Projekts "Bestellsystem".
|
||||
|
||||
## Wichtige Hinweise
|
||||
|
||||
**Achtung! Bitte keine unverschlüsselten Credentials in diesem Repository hinterlegen. Alle `Secrets`-Dateien dürfen nur verschlüsselt ins Git-Repo hinzugefügt werden.
|
||||
Details zum Umgang mit Zugangsdaten finden sich [im Dokumentations-Repo](
|
||||
https://git.tech.rz.db.de/bestellsystem1/docs/dokumentation/-/wikis/Umgebungskonfiguration)**
|
||||
|
||||
Außerdem haben wir keinen Automatismus, um bei Änderungen der ConfigMaps/Secrets auch ein neues Einlesen oder einen Neustart der betroffenen Dienste zu triggern ([vgl. Dokumentations-Repo](https://git.tech.rz.db.de/bestellsystem1/docs/dokumentation/-/wikis/Umgebungskonfiguration#user-content-verhalten-bei-%C3%A4nderungen)). Das muss man selbst machen (üblicherweise per OpenShift-Console).
|
||||
|
||||
## Anleitung zur Nutzung
|
||||
|
||||
Die CI Pipeline pusht alle ConfigMap- und Secret-Daten in die passenden OpenShift-Namespaces.
|
||||
|
||||
Entscheidend für die Zuordnung ist der richtige Verzeichnisname auf erster Ebene,
|
||||
d.h. alles in `bestellsystem-test/` wird in den Namespace (bzw. OpenShift-Projekt)
|
||||
`bestellsystem-test` gesendet.
|
||||
|
||||
Tiefere Verzeichnisebenen sind optional, ebenso sind die Dateinamen egal solange
|
||||
sie auf `.yml` oder `.yaml` enden. Alle YAML-Dateien werden geparst und nur die
|
||||
`ConfigMap`-Elemente werden weiterverarbeitet.
|
||||
|
||||
Empfehlung/Konvention: wir nutzen Unterverzeichnisse um nach Services zu
|
||||
gruppieren und die YAML-Dateien heißen so wie die `ConfigMap`-Elemente,
|
||||
die sie beinhalten.
|
||||
|
||||
Die Pipeline läuft im _master_-Branch automatisch durch.
|
||||
In Feature-Branches wird das `helm install` nicht gestartet und nichts ins Cluster geschrieben.
|
||||
|
||||
### Git-Orga und Datei-Kopien
|
||||
|
||||
Weil die meisten Dateien verschlüsselt sind ist die Arbeit damit etwas umständlich.
|
||||
Seit März 2025 haben wir in jedem Unterverzeichnis bzw. Namespace unterschiedliche Masterkeys, deshalb gibt es auch keine Abkürzung mehr.
|
||||
|
||||
## Bootstrap-Secrets
|
||||
|
||||
Dieses Repository enthält auch grundlegende Bootstrap-Informationen wie die `bsz-masterkeys` und die Artifactory-Credentials, weil wir sie auf diesem Wege sicher speichern können.
|
||||
|
||||
Es ist nicht möglich oder beabsichtigt einen völlig leeren Namespace automatisch zu konfigurieren. Zumindest die Artifactory-Credentials (um eigene Tool-Container zu starten), die `bsz-masterkeys` (um Dateien dieses Repos zu entschlüsseln), und alle notwendigen Daten für die GitLab-Runner müssen manuell angelegt werden.
|
||||
|
||||
Die Anleitung dazu findet sich [im Entwicklungshandbuch unter CNP Bootstrap](https://git.tech.rz.db.de/bestellsystem1/docs/dokumentation/-/wikis/cloud-native-platform#user-content-bootstrap).
|
||||
|
||||
|
||||
## Wildcard Subdomain und statischer Ingress
|
||||
|
||||
ExternalDnsController läuft häufig ins Rate-Limit(Siehe [O2CSYS-864](https://arija.jaas.service.deutschebahn.com/browse/O2CSYS-864)). Um die Nutzung von ExternalDNSController zu vermeiden, haben wir im Repo [Bestellsystem-Ops](https://git.tech.rz.db.de
|
||||
|
||||
... (gekuerzt)
|
||||
+62
@@ -0,0 +1,62 @@
|
||||
# core-pm-sql
|
||||
|
||||
> Quelle: https://git.tech.rz.db.de/bestellsystem1/libraries/core-pm-sql
|
||||
|
||||
# core-pm-sql
|
||||
|
||||
|
||||
|
||||
## Getting started
|
||||
|
||||
To make it easy for you to get started with GitLab, here's a list of recommended next steps.
|
||||
|
||||
Already a pro? Just edit this README.md and make it your own. Want to make it easy? [Use the template at the bottom](#editing-this-readme)!
|
||||
|
||||
## Add your files
|
||||
|
||||
- [ ] [Create](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#create-a-file) or [upload](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#upload-a-file) files
|
||||
- [ ] [Add files using the command line](https://docs.gitlab.com/topics/git/add_files/#add-files-to-a-git-repository) or push an existing Git repository with the following command:
|
||||
|
||||
```
|
||||
cd existing_repo
|
||||
git remote add origin https://git.tech.rz.db.de/bestellsystem1/libraries/core-pm-sql.git
|
||||
git branch -M main
|
||||
git push -uf origin main
|
||||
```
|
||||
|
||||
## Integrate with your tools
|
||||
|
||||
- [ ] [Set up project integrations](https://git.tech.rz.db.de/bestellsystem1/libraries/core-pm-sql/-/settings/integrations)
|
||||
|
||||
## Collaborate with your team
|
||||
|
||||
- [ ] [Invite team members and collaborators](https://docs.gitlab.com/ee/user/project/members/)
|
||||
- [ ] [Create a new merge request](https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html)
|
||||
- [ ] [Automatically close issues from merge requests](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically)
|
||||
- [ ] [Enable merge request approvals](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/)
|
||||
- [ ] [Set auto-merge](https://docs.gitlab.com/user/project/merge_requests/auto_merge/)
|
||||
|
||||
## Test and Deploy
|
||||
|
||||
Use the built-in continuous integration in GitLab.
|
||||
|
||||
- [ ] [Get started with GitLab CI/CD](https://docs.gitlab.com/ee/ci/quick_start/)
|
||||
- [ ] [Analyze your code for known vulnerabilities with Static Application Security Testing (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/)
|
||||
- [ ] [Deploy to Kubernetes, Amazon EC2, or Amazon ECS using Auto Deploy](https://docs.gitlab.com/ee/topics/autodevops/requirements.html)
|
||||
- [ ] [Use pull-based deployments for improved Kubernetes management](https://docs.gitlab.com/ee/user/clusters/agent/)
|
||||
- [ ] [Set up protected environments](https://docs.gitlab.com/ee/ci/environments/protected_environments.html)
|
||||
|
||||
***
|
||||
|
||||
# Editing this README
|
||||
|
||||
When you're ready to make this README your own, just edit this file and use the handy template below (or feel free to structure it however you want - this is just a starting point!). Thanks to [makeareadme.com](https://www.makeareadme.com/) for this template.
|
||||
|
||||
## Suggestions for a good README
|
||||
|
||||
Every project is different, so consider which of these sections apply to yours. The sections used in the template are suggestions for most open source projects. Also keep in mind that while a README can be too long and detailed, too long is better than too short. If you think your README is too long, consider utilizing another form of documentation rather than cutting out information.
|
||||
|
||||
## Name
|
||||
Choose a self-expla
|
||||
|
||||
... (gekuerzt)
|
||||
+101
@@ -0,0 +1,101 @@
|
||||
# logging-utils
|
||||
|
||||
> Quelle: https://git.tech.rz.db.de/bestellsystem1/libraries/logging-utils
|
||||
|
||||
# logging-utils
|
||||
|
||||
Logging Library fasst die besten O2C-Lösungen zusammen.
|
||||
|
||||
## Das Konzept, wenn wir eine neue Bibliothek machen wollen
|
||||
Um die Erfassung und Verarbeitung von Protokollen zu zentralisieren,
|
||||
verfügt das DB-System über eine eigene Entwicklung – Talo,
|
||||
die ein eigenes Json-basiertes Protokoll bereitstellt.
|
||||
Um dieses Protokoll zu verwenden, wurden die folgenden Bibliotheken geschrieben: [TaloJava 4](https://git.tech.rz.db.de/kolt/talo/talo-java) und [Talo Spring Boot](https://git.tech.rz.db.de/kolt/talo/talo-spring-boot). <br />
|
||||
Diese Bibliothek verwendet die Talo-Bibliothek, um einen gemeinsamen Protokollierungsstandard aufrechtzuerhalten, und bringt ihre nützlichen Zusatzfunktionen mit.
|
||||
|
||||
### features:
|
||||
|
||||
- [PropertyLogger] (+LoggingProperties)
|
||||
- [LoggingScheduledJobs]
|
||||
- @Secret
|
||||
- @Truncated
|
||||
|
||||
#### PropertyLogger
|
||||
Loggs alle Environment und Applikation Properties bei Start von der Spring-Boot Anwendung.
|
||||
Werte von Geheime Properties sind mit "\<masked\>" ersetzt.
|
||||
Geheime Properties sind in Application.yaml/properties gesteuert.
|
||||
|
||||
in Yaml:
|
||||
|
||||
logging:
|
||||
propertyExclusions:
|
||||
- credentials
|
||||
- password
|
||||
- apikey
|
||||
- clientsecret
|
||||
|
||||
in Properties:
|
||||
|
||||
logging.propertyExclusions: credentials,password,apikey,clientsecret
|
||||
|
||||
in Log zu erwarten:
|
||||
|
||||
..
|
||||
someKey: someValue
|
||||
..
|
||||
password: <masked>
|
||||
..
|
||||
|
||||
#### LoggingScheduledJobs
|
||||
Funktioniert bei alle Methoden Annotated mit @Scheduled. Es schreibt Log Einträge durch ein Custom
|
||||
Talo Catalog wenn der Funktion aufgerufen und wenn es beendet ist.
|
||||
Am Ende ist der Laufzeit auch berechnet und ins Log geschrieben.
|
||||
Wenn der Method zu lange dauert (mehr als 10 Sekunden) gibt's ein Warning.
|
||||
|
||||
In Log zu erwarten:
|
||||
|
||||
Scheduledjob 'SomeJob.SomeMethod' started.
|
||||
..
|
||||
Scheduledjob 'SomeJob.SomeMethod' succeeded in PT0.04S.
|
||||
|
||||
#### @Secret
|
||||
Wenn der markierte Parameter ein String ist, ersetzt es der Wert mit Sterne.
|
||||
Bei Default mit "*****"
|
||||
#### @Truncated
|
||||
Wenn der markierte Parameter ein String ist, ersetzt es der Wert mit eine gekürtze Version.
|
||||
Bei Default mit der erste 100 Zeichen.
|
||||
|
||||
|
||||
## Nutzung von der Logging Bibliothek.
|
||||
### Dependency in pom.xml
|
||||
|
||||
<properties>
|
||||
..
|
||||
<LoggingUtil.version>0.0.0-20220826111346-f7e1b93</LoggingUtil.version>
|
||||
..
|
||||
</properties>
|
||||
|
||||
<dependency>
|
||||
<groupId>com.dbnetz.bestellsystem</groupId>
|
||||
<artifactId>LoggingUtil</artifactId>
|
||||
<version>${LoggingUtil.version}</version>
|
||||
</dependency>
|
||||
|
||||
### Spring-Boot Application
|
||||
Wegen der Bibliothek ist an eine andere Paket braucht der Applikation auch für der Logging ein ComponentScan.
|
||||
Bsp:
|
||||
|
||||
@ComponentScan(basePackages = {"com.dbnetz.bestellsystem"})
|
||||
|
||||
oder
|
||||
|
||||
@ComponentScan(basePackages = {"com.dbnetz.bestellsystem.logging", "com.dbnetz.bestellsystem.evurecorder"})
|
||||
|
||||
|
||||
### PropertyLogger und LoggingScheduledJobs
|
||||
Wenn der Bibliothek als Dependency in eine Projekt eingebunden ist, sind die automatisch benutzt.
|
||||
|
||||
### @Secret und @Truncated
|
||||
Die können als Method Param
|
||||
|
||||
... (gekuerzt)
|
||||
+64
@@ -0,0 +1,64 @@
|
||||
# selenium-node-chrome
|
||||
|
||||
> Quelle: https://git.tech.rz.db.de/bestellsystem1/qa/selenium-node-chrome
|
||||
|
||||
# selenium-node-chrome
|
||||
|
||||
|
||||
|
||||
## Getting started
|
||||
|
||||
To make it easy for you to get started with GitLab, here's a list of recommended next steps.
|
||||
|
||||
Already a pro? Just edit this README.md and make it your own. Want to make it easy? [Use the template at the bottom](#editing-this-readme)!
|
||||
|
||||
## Add your files
|
||||
|
||||
* [Create](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#create-a-file) or [upload](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#upload-a-file) files
|
||||
* [Add files using the command line](https://docs.gitlab.com/topics/git/add_files/#add-files-to-a-git-repository) or push an existing Git repository with the following command:
|
||||
|
||||
```
|
||||
cd existing_repo
|
||||
git remote add origin https://git.tech.rz.db.de/bestellsystem1/qa/selenium-node-chrome.git
|
||||
git branch -M main
|
||||
git push -uf origin main
|
||||
```
|
||||
|
||||
## Integrate with your tools
|
||||
|
||||
* [Set up project integrations](https://git.tech.rz.db.de/bestellsystem1/qa/selenium-node-chrome/-/settings/integrations)
|
||||
|
||||
## Collaborate with your team
|
||||
|
||||
* [Invite team members and collaborators](https://docs.gitlab.com/ee/user/project/members/)
|
||||
* [Create a new merge request](https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html)
|
||||
* [Automatically close issues from merge requests](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically)
|
||||
* [Enable merge request approvals](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/)
|
||||
* [Set auto-merge](https://docs.gitlab.com/user/project/merge_requests/auto_merge/)
|
||||
|
||||
## Test and Deploy
|
||||
|
||||
Use the built-in continuous integration in GitLab.
|
||||
|
||||
* [Get started with GitLab CI/CD](https://docs.gitlab.com/ee/ci/quick_start/)
|
||||
* [Analyze your code for known vulnerabilities with Static Application Security Testing (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/)
|
||||
* [Deploy to Kubernetes, Amazon EC2, or Amazon ECS using Auto Deploy](https://docs.gitlab.com/ee/topics/autodevops/requirements.html)
|
||||
* [Use pull-based deployments for improved Kubernetes management](https://docs.gitlab.com/ee/user/clusters/agent/)
|
||||
* [Set up protected environments](https://docs.gitlab.com/ee/ci/environments/protected_environments.html)
|
||||
|
||||
***
|
||||
|
||||
# Editing this README
|
||||
|
||||
When you're ready to make this README your own, just edit this file and use the handy template below (or feel free to structure it however you want - this is just a starting point!). Thanks to [makeareadme.com](https://www.makeareadme.com/) for this template.
|
||||
|
||||
## Suggestions for a good README
|
||||
|
||||
Every project is different, so consider which of these sections apply to yours. The sections used in the template are suggestions for most open source projects. Also keep in mind that while a README can be too long and detailed, too long is better than too short. If you think your README is too long, consider utilizing another form of documentation rather than cutting out information.
|
||||
|
||||
## Name
|
||||
Choose a self-explaining name for your project.
|
||||
|
||||
## Descri
|
||||
|
||||
... (gekuerzt)
|
||||
@@ -0,0 +1,62 @@
|
||||
# smoketest
|
||||
|
||||
> Quelle: https://git.tech.rz.db.de/bestellsystem1/qa/smoketest
|
||||
|
||||
# test12345
|
||||
|
||||
|
||||
|
||||
## Getting started
|
||||
|
||||
To make it easy for you to get started with GitLab, here's a list of recommended next steps.
|
||||
|
||||
Already a pro? Just edit this README.md and make it your own. Want to make it easy? [Use the template at the bottom](#editing-this-readme)!
|
||||
|
||||
## Add your files
|
||||
|
||||
- [ ] [Create](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#create-a-file) or [upload](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#upload-a-file) files
|
||||
- [ ] [Add files using the command line](https://docs.gitlab.com/ee/gitlab-basics/add-file.html#add-a-file-using-the-command-line) or push an existing Git repository with the following command:
|
||||
|
||||
```
|
||||
cd existing_repo
|
||||
git remote add origin https://git.tech.rz.db.de/bestellsystem1/qa/test.git
|
||||
git branch -M main
|
||||
git push -uf origin main
|
||||
```
|
||||
|
||||
## Integrate with your tools
|
||||
|
||||
- [ ] [Set up project integrations](https://git.tech.rz.db.de/bestellsystem1/qa/test/-/settings/integrations)
|
||||
|
||||
## Collaborate with your team
|
||||
|
||||
- [ ] [Invite team members and collaborators](https://docs.gitlab.com/ee/user/project/members/)
|
||||
- [ ] [Create a new merge request](https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html)
|
||||
- [ ] [Automatically close issues from merge requests](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically)
|
||||
- [ ] [Enable merge request approvals](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/)
|
||||
- [ ] [Set auto-merge](https://docs.gitlab.com/ee/user/project/merge_requests/merge_when_pipeline_succeeds.html)
|
||||
|
||||
## Test and Deploy
|
||||
|
||||
Use the built-in continuous integration in GitLab.
|
||||
|
||||
- [ ] [Get started with GitLab CI/CD](https://docs.gitlab.com/ee/ci/quick_start/index.html)
|
||||
- [ ] [Analyze your code for known vulnerabilities with Static Application Security Testing (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/)
|
||||
- [ ] [Deploy to Kubernetes, Amazon EC2, or Amazon ECS using Auto Deploy](https://docs.gitlab.com/ee/topics/autodevops/requirements.html)
|
||||
- [ ] [Use pull-based deployments for improved Kubernetes management](https://docs.gitlab.com/ee/user/clusters/agent/)
|
||||
- [ ] [Set up protected environments](https://docs.gitlab.com/ee/ci/environments/protected_environments.html)
|
||||
|
||||
***
|
||||
|
||||
# Editing this README
|
||||
|
||||
When you're ready to make this README your own, just edit this file and use the handy template below (or feel free to structure it however you want - this is just a starting point!). Thanks to [makeareadme.com](https://www.makeareadme.com/) for this template.
|
||||
|
||||
## Suggestions for a good README
|
||||
|
||||
Every project is different, so consider which of these sections apply to yours. The sections used in the template are suggestions for most open source projects. Also keep in mind that while a README can be too long and detailed, too long is better than too short. If you think your README is too long, consider utilizing another form of documentation rather than cutting out information.
|
||||
|
||||
## Name
|
||||
C
|
||||
|
||||
... (gekuerzt)
|
||||
+7
@@ -0,0 +1,7 @@
|
||||
# stammdaten-adapter-request-collection
|
||||
|
||||
> Quelle: https://git.tech.rz.db.de/bestellsystem1/qa/stammdaten-adapter-request-collection
|
||||
|
||||
# stammdaten-adapter-request-collection
|
||||
|
||||
Das Repository enthält eine Ansammlung von Beispiel-Requests in Form von Postman Collections, die zur Vertestung der Stammdaten-Adapter-Schnittstelle genutzt werden können.
|
||||
+51
@@ -0,0 +1,51 @@
|
||||
# system-integration-tests
|
||||
|
||||
> Quelle: https://git.tech.rz.db.de/bestellsystem1/qa/system-integration-tests
|
||||
|
||||
# System-Integration-Tests
|
||||
|
||||
Projekt zur Anlage initialer und weiterführender System-Integration-Tests.
|
||||
|
||||
# Local running
|
||||
- Copy and adapt your local copy of `testProperties.properties`. The credentials must be set, the rest can remain.
|
||||
- Start Selenium locally
|
||||
- Linux using Docker on Franks Laptop (-> no VPN DNS -> /etc/hosts)
|
||||
- Normal Standalone
|
||||
- ``docker run --rm -p 4444:4444 -v /etc/hosts:/etc/hosts --name selenium-hub selenium/standalone-chrome:3.141.59-20210713``
|
||||
- Selenium Grid
|
||||
- ``docker run --rm -p 4444:4444 --name selenium-hub selenium/hub:3.141.59-20210713``
|
||||
- ``docker run --rm -v /etc/hosts:/etc/hosts --link selenium-hub:hub --name selenium-node selenium/node-chrome:3.141.59-20210713``
|
||||
- ``-v `` part is optional
|
||||
- Use chromedriver: Add the system property as like as here `-Dwebdriver.chrome.driver=$(pwd)/chromedriver`
|
||||
- `mvn clean test`
|
||||
- `mvn clean test -Dcucumber.filter.tags="@123 and not @456 or @789"`
|
||||
- Automatic environment selection in Gitlab pipeline, default is 'sit'
|
||||
- Automatic detection for your machine: `sit`
|
||||
- Manual environment selection
|
||||
- Your machine: `mvn clean test -Denvironment=$TARGET`
|
||||
- Gitlab: Configure pipeline variable ENVIRONMENT to $TARGET
|
||||
- ...where $TARGET can be one of:
|
||||
- `ieu`
|
||||
- `local`
|
||||
- The configuration can be found here: `localEnvironment.properties`
|
||||
- `custom`
|
||||
- The configuration file must be created and adapted: `customEnvironment.properties` -- This file isn't checked in normally but could on a temporary base
|
||||
- Idea: Copy it based on `localEnvironment.properties`
|
||||
- `cnp`
|
||||
- Specific environment URLs
|
||||
- Can be set up and independently of the manually configured or automatically detected environment as following:
|
||||
- `mvn clean test -Dbestellsystem.portal-ui.url=https://...`
|
||||
- `mvn clean test -Dbestellsystem.portal-middleware.url=https://...`
|
||||
- `mvn clean test -Dbestellsystem.auftrags-verwaltung-trasse.url=https://...`
|
||||
- `mvn clean test -Dbestellsystem.evu-recorder.url=https://...`
|
||||
- `mvn clean test -Dbestellsystem.ifp-mock.url=https://...`
|
||||
- `mvn clean test -Dbestellsystem.common-interface.url=https://...`
|
||||
- Java KeyStore and Ubuntu CA trust store updates
|
||||
- Download DB root public certificate to /usr/local/share/ca-certificates/DB.crt (as root)
|
||||
- `sudo update-ca-certificates`
|
||||
- `sudo keytool -import -trustcacerts -keystore /usr/lib/jvm/java-11-amazon-corretto/lib/security/cacerts -storepass changeit -noprompt -alias DB_root -file /usr/local/share/ca-certificates/DB.crt`
|
||||
- Cert issues with Keycloak / PortalMiddleware login
|
||||
- Download the pem file using your browser / or directly the cer file
|
||||
- `openssl x509 -outform der -in Downloads/west-dbcs-db-de.pem -out Downloads/west-dbcs-db-de.cer`
|
||||
- `sudo keytool -import -alias keycloak -keystore /usr/lib/jvm/java-11-amazon-corretto/lib/security/cacerts -f Downloads/west-dbcs-db-de.cer`
|
||||
|
||||
@@ -0,0 +1,41 @@
|
||||
# system-tests
|
||||
|
||||
> Quelle: https://git.tech.rz.db.de/bestellsystem1/qa/system-tests
|
||||
|
||||
# System-Tests
|
||||
|
||||
Projekt zur Anlage initialer und weiterführender System-Tests.
|
||||
|
||||
# Pipeline parameters
|
||||
Important CI/CD variables for this pipeline:
|
||||
|
||||
- `ENVIRONMENT` (default: "ieu") selects the target environment. It has some shortcodes, otherwise the last deployment info for that environment name is fetched from the GitLab pipelines of [bestellsystem-deployment](https://git.tech.rz.db.de/bestellsystem1/infra/bestellsystem-deployment).
|
||||
- `DEBUG_MAVEN_OPS` (default: "") gets appended to the Maven command line, this is the place to add all custom settings or filters like "-Dcucumber.filter.tags=@SOAP"
|
||||
- `BSZ_SYSTEM_TEST_USE_LOCAL_URLS` (default: "false") changes the config to use cluster local URLs.\
|
||||
If left unset or "false" the test uses the `url_*` entries from the environment.json (for the given Deployment name), if set to "true" the test uses the `url_local_*` entries instead. This function depends on a correct deployment and a matching environment.json; for example the test cannot work if it is run with `BSZ_SYSTEM_TEST_USE_LOCAL_URLS=false` while the deployment does not provide `url_*` values (deployment without Ingress).
|
||||
|
||||
## Adapting the Pipeline to Hotfixes
|
||||
The following variables can be used to run the system tests pipeline against a previous Base und using a previous version of system tests. They must be set at the `.gitlab-ci.yml` in the original project (e.g. portal-middleware) as variable for the job `run_bsz_system_test`:
|
||||
- `ENV_SYSTEM_TEST_BASE_DEPLOYMENT_BRANCH` (default: "master") sets the branch to use to get the version of Base to install.
|
||||
- `ENV_SYSTEM_TEST_BRANCH` (default: "master") sets the branch of the system tests to use to test the changes on the original project
|
||||
|
||||
|
||||
# Local running
|
||||
- Copy and adapt your local copy of `config/testProperties.properties`. The credentials must be set, the rest can remain.
|
||||
- Start Selenium locally
|
||||
- Linux using Docker on Franks Laptop (-> no VPN DNS -> /etc/hosts)
|
||||
- Normal Standalone
|
||||
- ``docker run --rm -p 4444:4444 -v /etc/hosts:/etc/hosts --name selenium-hub selenium/standalone-chrome:3.141.59-20210713``
|
||||
- Selenium Grid
|
||||
- ``docker run --rm -p 4444:4444 --name selenium-hub selenium/hub:3.141.59-20210713``
|
||||
- ``docker run --rm -v /etc/hosts:/etc/hosts --link selenium-hub:hub --name selenium-node selenium/node-chrome:3.141.59-20210713``
|
||||
- This command can be run multiple times to add more chrome nodes and make use of parallelism in the selenium tests. The name must be changed for every node.
|
||||
- ``-v `` part is optional
|
||||
- Use chromedriver: Add the system property as like as here `-Dwebdriver.chrome.driver=$(pwd)/chromedriver`
|
||||
- `mvn clean test`
|
||||
- Filtering for Cucumber Tags:
|
||||
- Locally: `mvn clean test -Dcucumber.filter.tags="@SOAP and not @NEGATIVE or @PORTAL"`
|
||||
- Pipeline execution: Set the variable `DEBUG_MAVEN_OPS`, e.g. to "-Dcucumber.filter.tags=@SOAP"
|
||||
- But: multiple tags with "and" and "or combined don't work due to lack of Pipeship to
|
||||
|
||||
... (gekuerzt)
|
||||
+26
@@ -0,0 +1,26 @@
|
||||
# trivy-scan-container-image
|
||||
|
||||
> Quelle: https://git.tech.rz.db.de/bestellsystem1/qa/trivy-scan-container-image
|
||||
|
||||
# trivy-scan-container-image
|
||||
|
||||
Das Projekt erstellt Pipelines, um Trivy-Sans für Container-Images aller Pods eines K8s-Namespaces durchzuführen.
|
||||
Anschließend werden die Trivy-Reports in Defect-Dojo importiert.
|
||||
|
||||
## Getting started
|
||||
|
||||
Pipeline-Variablen
|
||||
|
||||
* TARGET_NAMESPACE_TAG: K8s-Namespaces zum Scan. z.B. bszneu-e2e (default)
|
||||
* IMAGE_BLACK_LIST: Liste von Imagenamen, die nicht gescant werden sollen. Die Imagenamen müssen mit "|"
|
||||
separiert werden. z.B. "auftrags-verwaltung-trasse|common-interface"
|
||||
|
||||
NOTE: Das Image aws-appmesh-envoy wird nicht gescant, da es ein CNP-Image ist und Bestellsystem ist nicht berechtigt
|
||||
das Image aus AWS herunterzuladen.
|
||||
|
||||
## HTML Report
|
||||
|
||||
Page URL: **https://bestellsystem1.gitpages.tech.rz.db.de/qa/trivy-scan-container-image/**
|
||||
|
||||
The HTML Report generation is copied and adapted from https://git.tech.rz.db.de/bestellsystem1/qa/trivy-scan-pipeline, where it was previously copied and adapted from https://git.tech.rz.db.de/bestellsystem1/docs/installierte-versionen. It could use some refactoring across those projects.
|
||||
|
||||
+7
@@ -0,0 +1,7 @@
|
||||
# Abwärtskompatibilität
|
||||
|
||||
> Quelle: https://git.tech.rz.db.de/bestellsystem1/sandbox/abwaertskompatibilitaet
|
||||
|
||||
== TaDeF-Connector API
|
||||
|
||||
Projekt zur Spezifikation der API für den Zugriff von TaDeF auf CommonInterface-TafTap-Nachrichten.
|
||||
+57
@@ -0,0 +1,57 @@
|
||||
# C2S Kafka Toolbox
|
||||
|
||||
> Quelle: https://git.tech.rz.db.de/bestellsystem1/sandbox/c2s-kafka-toolbox
|
||||
|
||||
# Kafka toolbox
|
||||
|
||||
Die Kafka toolbox ist zum debuggen und testen einer MSK Kafkainstanz da, insbesondere um Berechtigungs und Zugriffsprobleme zu finden.
|
||||
Das Image wird ebenfalls in diesem Repository gepflegt, und via gitlabCI in die C2S Artifactory gepushed.
|
||||
|
||||
## Vorrausetzung (IFP mit Zugriff auf das Kubernetes cluster)
|
||||
|
||||
Vorausetzung für die Nutzung des Scripts `toolbox-sts.sh` ist eine `bash` shell und ein funktionierdes setup, was Zugriff auf den Kubernetes cluster erlaubt und ein installiertes `kubectl`. Weiterhin muss die Berechitung existieren ein Statefulset zu erstellen.
|
||||
|
||||
## Vorausetzung bei direkter Nutzung des Dockerimages (Team Bestand und alle die keinen Zugriff auf ein Kubernetes Cluster haben)
|
||||
|
||||
Vorraussetzung ist der Zugriff auf die EC2 instanz und ein installiertes docker und die möglichkeit `docker run` auszuführen. Weiterhin muss das Dockerimage in artifactory oder anderweitig im Zugriff sein.
|
||||
Die Folgenden Anweisungen betreffen die Nutzung im Kubernetes cluster. Es kann von hier direkt zu [starten der Toolbox](#starten-der-toolbox) gesprungen werden.
|
||||
|
||||
## Einrichten von IAM Role und PolicyAttachment
|
||||
|
||||
Um auf den kafka-cluster zugreifen zu können muss der ServiceAccount, mit welchem der pod des services läuft die entsprechenden Berechtigungen haben.
|
||||
|
||||
Dazu benötigt wird eine `IRSA` und ein `RolePolicyAttachment` welches die für den jeweiligen Cluster existierende Policy an die `IRSA` attached. Wie man die ensprechende Policy findet kann man hier nachlesen https://cnp.gitpages.tech.rz.db.de/core/docs/cnp/latest/cnp-portfolio/kafka/cluster/usage.html#access.
|
||||
Das Binden der `IRSA` an den ServiceAccount wird durch die annotation `eks.amazonaws.com/role-arn` erreicht.
|
||||
|
||||
### Beispiel
|
||||
|
||||
Angenommen wir wollen einen pod für den Kafka-Vollzugriff auf den MSK in IAT berechtigen brauchen wir folgende cnp Resourcen die so aussehen könnten:
|
||||
( Werte in <...> müssen ggf. angepasst werden). Wichtig dabei ist, dass der `roleNameRef` im `RolePolicyAttachment` auf den Namen der `IRSA` verweist und als prefix den jeweiligen namespace auf der cnp hat (in diesem Beispiel `ifp-iat-`...). Die entprechende Policy Arn bitte https://cnp.gitpages.tech.rz.db.de/core/docs/cnp/latest/cnp-portfolio/kafka/cluster/usage.html#access entnehmen.
|
||||
|
||||
* IRSA
|
||||
|
||||
```yaml
|
||||
apiVersion: iam.cnp.comp.db.de/v1alpha1
|
||||
kind: IRSA
|
||||
metadata:
|
||||
name: <kafka-access-ifp-integration>
|
||||
namespace: ifp-iat
|
||||
labels:
|
||||
cnp.comp.db.de/application-id: A-107915
|
||||
cnp.comp.db.de/cost-reference: F-330951-53-05
|
||||
cnp.comp.db.de/owner: ifp
|
||||
ifp.cnp.comp.db.de/environment: ifp-sit
|
||||
ifp.cnp.comp.db.de/service: <kafka-mein-service>
|
||||
spec:
|
||||
compositionSelector:
|
||||
matchLabels:
|
||||
stage: cnp-iat
|
||||
parameters:
|
||||
description: IAM-Role <kafka-mein-service>
|
||||
serviceAccountNamespace: ifp-sit
|
||||
serviceAccountName: <kafka-access-ifp-integration>
|
||||
clusterOIDCIssuer: 7CD151F765F985657D40010B8F935A32
|
||||
maxSessionDuration: 7200 # optional, duration of the role session in seconds, default: 360
|
||||
|
||||
|
||||
... (gekuerzt)
|
||||
+62
@@ -0,0 +1,62 @@
|
||||
# gitLabTest
|
||||
|
||||
> Quelle: https://git.tech.rz.db.de/bestellsystem1/sandbox/gitlabtest
|
||||
|
||||
# gitLabTest
|
||||
|
||||
|
||||
|
||||
## Getting started
|
||||
|
||||
To make it easy for you to get started with GitLab, here's a list of recommended next steps.
|
||||
|
||||
Already a pro? Just edit this README.md and make it your own. Want to make it easy? [Use the template at the bottom](#editing-this-readme)!
|
||||
|
||||
## Add your files
|
||||
|
||||
- [ ] [Create](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#create-a-file) or [upload](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#upload-a-file) files
|
||||
- [ ] [Add files using the command line](https://docs.gitlab.com/topics/git/add_files/#add-files-to-a-git-repository) or push an existing Git repository with the following command:
|
||||
|
||||
```
|
||||
cd existing_repo
|
||||
git remote add origin https://git.tech.rz.db.de/bestellsystem1/sandbox/gitlabtest.git
|
||||
git branch -M main
|
||||
git push -uf origin main
|
||||
```
|
||||
|
||||
## Integrate with your tools
|
||||
|
||||
- [ ] [Set up project integrations](https://git.tech.rz.db.de/bestellsystem1/sandbox/gitlabtest/-/settings/integrations)
|
||||
|
||||
## Collaborate with your team
|
||||
|
||||
- [ ] [Invite team members and collaborators](https://docs.gitlab.com/ee/user/project/members/)
|
||||
- [ ] [Create a new merge request](https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html)
|
||||
- [ ] [Automatically close issues from merge requests](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically)
|
||||
- [ ] [Enable merge request approvals](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/)
|
||||
- [ ] [Set auto-merge](https://docs.gitlab.com/user/project/merge_requests/auto_merge/)
|
||||
|
||||
## Test and Deploy
|
||||
|
||||
Use the built-in continuous integration in GitLab.
|
||||
|
||||
- [ ] [Get started with GitLab CI/CD](https://docs.gitlab.com/ee/ci/quick_start/)
|
||||
- [ ] [Analyze your code for known vulnerabilities with Static Application Security Testing (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/)
|
||||
- [ ] [Deploy to Kubernetes, Amazon EC2, or Amazon ECS using Auto Deploy](https://docs.gitlab.com/ee/topics/autodevops/requirements.html)
|
||||
- [ ] [Use pull-based deployments for improved Kubernetes management](https://docs.gitlab.com/ee/user/clusters/agent/)
|
||||
- [ ] [Set up protected environments](https://docs.gitlab.com/ee/ci/environments/protected_environments.html)
|
||||
|
||||
***
|
||||
|
||||
# Editing this README
|
||||
|
||||
When you're ready to make this README your own, just edit this file and use the handy template below (or feel free to structure it however you want - this is just a starting point!). Thanks to [makeareadme.com](https://www.makeareadme.com/) for this template.
|
||||
|
||||
## Suggestions for a good README
|
||||
|
||||
Every project is different, so consider which of these sections apply to yours. The sections used in the template are suggestions for most open source projects. Also keep in mind that while a README can be too long and detailed, too long is better than too short. If you think your README is too long, consider utilizing another form of documentation rather than cutting out information.
|
||||
|
||||
## Name
|
||||
Choose a self-explaining n
|
||||
|
||||
... (gekuerzt)
|
||||
+112
@@ -0,0 +1,112 @@
|
||||
# kiro-test-review
|
||||
|
||||
> Quelle: https://git.tech.rz.db.de/bestellsystem1/sandbox/kiro-test-review
|
||||
|
||||
# Jira Test-Ticket Review mit Kiro
|
||||
|
||||
Dieses Setup ermöglicht es, Jira Test-Tickets (Xray) direkt in Kiro zu reviewen, zu verbessern und die Xray Test Steps zu pflegen.
|
||||
|
||||
## Überblick
|
||||
|
||||
Kiro nutzt zwei MCP-Server, um mit Jira und Xray zu kommunizieren:
|
||||
|
||||
| MCP-Server | Zweck |
|
||||
|---|---|
|
||||
| **jira** | Jira-Tickets lesen und Beschreibungen aktualisieren |
|
||||
| **mcp-xray** | Xray Test Steps lesen, erstellen, aktualisieren, löschen |
|
||||
|
||||
Ein Steering-File steuert den Review-Ablauf automatisch.
|
||||
|
||||
## Voraussetzungen
|
||||
|
||||
- [Kiro IDE](https://kiro.dev) installiert
|
||||
- Zugang zur Jira-Instanz mit Xray-Plugin
|
||||
- Personal Access Token (PAT) für Jira/Xray
|
||||
- Python 3.12+ und [uv](https://docs.astral.sh/uv/getting-started/installation/) (für mcp-xray)
|
||||
|
||||
## Einrichtung
|
||||
|
||||
### 1. uv installieren
|
||||
|
||||
`uv` ist der Paketmanager für mcp-xray. Installation unter Windows (PowerShell):
|
||||
|
||||
```powershell
|
||||
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"
|
||||
```
|
||||
|
||||
Alternativ via pip:
|
||||
|
||||
```bash
|
||||
pip install uv
|
||||
```
|
||||
|
||||
Nach der Installation prüfen:
|
||||
|
||||
```bash
|
||||
uv --version
|
||||
```
|
||||
|
||||
Weitere Installationsoptionen: [uv Installation Guide](https://docs.astral.sh/uv/getting-started/installation/)
|
||||
|
||||
### 2. Repository klonen
|
||||
|
||||
```bash
|
||||
git clone <repo-url>
|
||||
cd kiro_test
|
||||
```
|
||||
|
||||
### 3. mcp-xray installieren
|
||||
|
||||
Das mcp-xray Projekt liegt im Unterordner `mcp-xray/` und stammt von [https://github.com/tivaliy/mcp-xray](https://github.com/tivaliy/mcp-xray).
|
||||
|
||||
```bash
|
||||
cd mcp-xray
|
||||
uv sync
|
||||
cd ..
|
||||
```
|
||||
|
||||
### 4. MCP-Server konfigurieren
|
||||
|
||||
Eine Vorlage liegt unter `.kiro/settings/mcp-local.json`. Kopiere sie als deine lokale Konfiguration:
|
||||
|
||||
```bash
|
||||
cp .kiro/settings/mcp-local.json .kiro/settings/mcp.json
|
||||
```
|
||||
|
||||
Dann in `.kiro/settings/mcp.json` folgende Platzhalter ersetzen:
|
||||
|
||||
| Platzhalter | Ersetzen durch |
|
||||
|---|---|
|
||||
| `<DEIN_JIRA_PAT>` | Dein Personal Access Token (gleicher Token für Jira und Xray) |
|
||||
| `<pfad-zu-uv>` | Absoluter Pfad zum `uv.exe` (z.B. `C:\Users\DEIN_USER\AppData\Roaming\Python\Python313\Scripts`) |
|
||||
| `<pfad-zum-mcp-xray-ordner>` | Absoluter Pfad zum `mcp-xray` Ordner im Projekt |
|
||||
|
||||
**Wichtig:**
|
||||
- `X-Jira-Mode: "write"` ist erforderlich, damit Kiro Ticket-Beschreibungen aktualisieren kann
|
||||
- Die `autoApprove`-Listen sorgen dafür, dass häufig genutzte Aktionen ohne manuelle Bestätigung laufen
|
||||
- Die `mcp.json` ist in der `.gitignore` und wird nicht ins Repo eingecheckt (enthält Tokens)
|
||||
|
||||
### 5. Steering-File prüfen
|
||||
|
||||
Das Steering-File liegt unter `.kiro/steering/jira-test-ticket-review.md` und ist auf `inclusion: manual` gesetzt. Das bedeutet, du musst es im Chat explizit referenzieren.
|
||||
|
||||
## Benutzung
|
||||
|
||||
### Review starten
|
||||
|
||||
1. Öffne den Kiro Chat
|
||||
2. Referenziere das Steering-File und gib ein Ticket an:
|
||||
|
||||
```
|
||||
/jira-test-ticket-review O2CZERO-1234
|
||||
```
|
||||
|
||||
### Was passiert dann?
|
||||
|
||||
Kiro folgt automatisch diesem Ablauf:
|
||||
|
||||
1. **Ticket analysieren** — Holt das Ticket aus Jira und die Xray Test Steps
|
||||
2. **Feedback geben** — Bewertet Qualität, Vollständigkeit und Reproduzierbarkeit
|
||||
3. **Verbesserungsvorschlag** — Erstellt
|
||||
|
||||
... (gekuerzt)
|
||||
+103
@@ -0,0 +1,103 @@
|
||||
# LoganalyseSystemZustandCheck
|
||||
|
||||
> Quelle: https://git.tech.rz.db.de/bestellsystem1/sandbox/loganalysesystemzustandcheck
|
||||
|
||||
# Grafana Log Fetcher & Analyser
|
||||
|
||||
Holt ERROR-Logs aus Grafana/Loki per Playwright + Edge und gibt eine gruppierte Fehleranalyse aus.
|
||||
|
||||
## Voraussetzungen
|
||||
|
||||
- Node.js (>= 18)
|
||||
- Microsoft Edge installiert
|
||||
- Zugang zu `grafana-v2.cnp.comp.db.de` (Zertifikat im System-Keystore)
|
||||
|
||||
## Installation
|
||||
|
||||
```bash
|
||||
npm install
|
||||
npx playwright install msedge
|
||||
```
|
||||
|
||||
## Verwendung
|
||||
|
||||
```bash
|
||||
node fetch_logs.mjs <namespace1> [namespace2] [...] [optionen]
|
||||
```
|
||||
|
||||
Beim ersten Start öffnet sich Edge sichtbar für den OAuth-Login (Zertifikatsauswahl). Danach wird die Session im Profil gespeichert.
|
||||
|
||||
## Optionen
|
||||
|
||||
| Option | Default | Beschreibung |
|
||||
|---|---|---|
|
||||
| `--days N` | `1` | Letzte N Tage |
|
||||
| `--hours N` | - | Letzte N Stunden (überschreibt --days) |
|
||||
| `--from DATUM` | - | Startdatum (ISO-Format, z.B. `2026-04-10` oder `2026-04-10T08:00`) |
|
||||
| `--to DATUM` | jetzt | Enddatum (ISO-Format) |
|
||||
| `--url URL` | `https://grafana-v2.cnp.comp.db.de` | Grafana Base-URL |
|
||||
| `--orgId N` | `98` | Grafana Organisation ID |
|
||||
| `--datasource UID` | `f02a916b-...` | Loki Datasource UID |
|
||||
| `--filter TEXT` | `"ERROR"` | Log-Level Filter |
|
||||
| `--limit N` | `5000` | Max Einträge pro API-Request |
|
||||
| `--batches N` | `20` | Max Anzahl API-Requests pro Namespace |
|
||||
|
||||
## Beispiele
|
||||
|
||||
```bash
|
||||
# Eine Umgebung, letzte 24h
|
||||
node fetch_logs.mjs bsz-abn1
|
||||
|
||||
# Mehrere Umgebungen gleichzeitig
|
||||
node fetch_logs.mjs bsz-abn1 bsz-abn8
|
||||
|
||||
# Letzte 3 Tage
|
||||
node fetch_logs.mjs bsz-abn1 bsz-abn8 --days 3
|
||||
|
||||
# Letzte 12 Stunden
|
||||
node fetch_logs.mjs bsz-abn1 --hours 12
|
||||
|
||||
# Fester Zeitraum
|
||||
node fetch_logs.mjs bsz-abn1 bsz-abn8 --from 2026-04-10 --to 2026-04-11T14:00
|
||||
|
||||
# Andere OrgId / Datasource (z.B. bsz-ieu)
|
||||
node fetch_logs.mjs bsz-ieu --orgId 69 --datasource 5xZyOwzVk
|
||||
|
||||
# Produktion (andere Grafana-URL)
|
||||
node fetch_logs.mjs bsz-abn1 bsz-abn2 --url https://grafana-prod.example.de --orgId 42 --datasource abc123
|
||||
```
|
||||
|
||||
## Output
|
||||
|
||||
| Datei | Inhalt |
|
||||
|---|---|
|
||||
| `logs-<namespace>-output.txt` | Rohe Logzeilen pro Namespace |
|
||||
| `log-analyse.txt` | Gruppierte Fehleranalyse aller Namespaces |
|
||||
|
||||
### Detaillierte Analyse
|
||||
|
||||
Für eine ausführlichere Analyse mit Zeitverlauf, Exception-Tracking und Spike-Erkennung:
|
||||
|
||||
```bash
|
||||
node analyze_logs.mjs logs-bsz-abn1-output.txt logs-bsz-abn2-output.txt
|
||||
```
|
||||
|
||||
Gibt pro Namespace aus:
|
||||
- Metriken-Tabelle (Gesamt Errors, bekannte Exceptions, Zeitraum)
|
||||
- Fehler pro App mit Anteil
|
||||
- Top Fehler-Kategorien mit Exception-Klasse, betroffenen Pods und stündlichem Verlauf (inkl. Peak-Erkennung)
|
||||
|
||||
Konsolenausgabe zeigt die Analyse direkt an — gruppiert nach App, mit Exception-Klasse und Host:
|
||||
|
||||
```
|
||||
============================================================
|
||||
bsz-abn2: 4 Errors
|
||||
============================================================
|
||||
|
||||
common-interface: (4x total)
|
||||
(3x) << Error in message processing ResponseEvent with key null from abn2-bsz-abn2-taftap-message-from-kombau
|
||||
host: abn2-common-interface
|
||||
(1x) Retries exhausted, push message with key 'null' to dead-letter-queue
|
||||
host: abn2-common-interfac
|
||||
|
||||
... (gekuerzt)
|
||||
+7
@@ -0,0 +1,7 @@
|
||||
# prmjsonxmlconverter
|
||||
|
||||
> Quelle: https://git.tech.rz.db.de/bestellsystem1/sandbox/prmjsonxmlconverter
|
||||
|
||||
OBSOLETED
|
||||
see https://git.tech.rz.db.de/bestellsystem1/tools/tdm-prm-json2xml-konverter
|
||||
|
||||
+66
@@ -0,0 +1,66 @@
|
||||
# logs-report
|
||||
|
||||
> Quelle: https://git.tech.rz.db.de/bestellsystem1/tools/logs-report
|
||||
|
||||
# Log Report
|
||||
|
||||
Diese Applikation fragt die "neuen" Error-Logs aller relevanten (konfigurierbar) PathOs-Services einer Umgebung über die Grafana-API ab und stellt diese Logs durch eine "statische" Html-Seite dar.
|
||||
|
||||
GitLab Page: https://bestellsystem1.gitpages.tech.rz.db.de/tools/logs-report/
|
||||
|
||||
## Workflow
|
||||
* Für jeden relevanten PathOs-Service einer Umgebung wird eine Grafana-Query generiert. Die "bekannte" Error-Logs werden anhand des Konfig-Blocks "conditions" (siehe `ignore-log-rules-config.yaml`) in der Grafana-Query angehängt um die "bekannte" Errors auszufiltern.
|
||||
* Alle neue Error-Logs aller Services der Umgebung werden in einer Liste zusammengefügt.
|
||||
* Anschließende werden die "neue" Error-Logs anhand der Konfig `log-normalise-config.yaml` normalisiert.
|
||||
* Anhand der normalisierten Logs werden die "neue" Error-Logs de-dupliziert.
|
||||
* Die neuen Error-Logs werden durch eine statische Html-Seit dargestellt.
|
||||
|
||||
## Grafana API Token
|
||||
|
||||
Das Grafana API Token wird regelmäßig (alle 48h?) rotiert, deshalb müssen wir es aus der CNP API auslesen.
|
||||
|
||||
Hilfs-Script dazu:
|
||||
```
|
||||
get_check_grafana_api_token() {
|
||||
if [ "$1" = "dev" ]; then
|
||||
cnp_api
|
||||
KEY_SECRET_NAME="bsz-dev-api-reader-token"
|
||||
elif [ "$1" = "abn" ]; then
|
||||
cnp_api_abn
|
||||
KEY_SECRET_NAME="bsz-abn-api-reader-token"
|
||||
elif [ "$1" = "prod" ]; then
|
||||
cnp_api_prod
|
||||
KEY_SECRET_NAME="bsz-prod-api-reader-token"
|
||||
else
|
||||
echo "no env parameter given. please run as 'get_check_grafana_api_token {dev|abn|prod}'"
|
||||
return
|
||||
fi
|
||||
export GRAFANA_API_TOKEN=$(kubectl get \
|
||||
secrets "${KEY_SECRET_NAME}" \
|
||||
--template="{{ index .data \"attribute.key\" | base64decode}}")
|
||||
test "$CI" || echo $GRAFANA_API_TOKEN
|
||||
curl --request GET \
|
||||
--url https://grafana-v2.cnp.comp.db.de/api/org \
|
||||
--header "authorization: Bearer $GRAFANA_API_TOKEN"
|
||||
}
|
||||
|
||||
get_check_grafana_api_token abn
|
||||
```
|
||||
## Konfiguration
|
||||
### ignore-log-rules-config.yaml:
|
||||
* baseQuery: verwendet bei allen generierten Grafana-Queries
|
||||
* environment: Umgebung sowie PathOS-Services, für die die Logs über Grafana-API abgefragt werden. "namespace" kann auch über Env/Gitlab-Job-Variable `OVERWRITE_NAMESPACE` zur Laufzeit überschrieben werden.
|
||||
* ignoreRules: Bekannte Error-Logs. In "conditions" werden GrafanaQuery-Filter definiert, um die Logs auszufiltern.
|
||||
|
||||
### log-normalise-config.yaml
|
||||
* definiert die Replace-Patterns, um die zurückgelieferten "neue" Error-Logs zu normalisieren und danach zu de-duplizieren.
|
||||
|
||||
## Lokal ausführen
|
||||
* Main-Klasse: `com.dbnetz.bestellsystem.logsreport.App`
|
||||
* Env-Variable: $GRAFANA_API_TOKEN
|
||||
* Voraussetzung: Config Datei muss im Pfad liegen, wo die jar ausgeführt wird (ggf. via Umgebungsvarbalen kann der Pfad zur Config Datei angepasst)
|
||||
```
|
||||
logs-report % export GRAFANA_API_TOKEN="XXX"
|
||||
logs-report % mvn package
|
||||
logs-report % java -jar target/logs-report-jar-with-dependencies.jar
|
||||
```
|
||||
+12
@@ -0,0 +1,12 @@
|
||||
# tdm-prm-json2xml-konverter
|
||||
|
||||
> Quelle: https://git.tech.rz.db.de/bestellsystem1/tools/tdm-prm-json2xml-konverter
|
||||
|
||||
Vorraussetzungen:
|
||||
- Java 21 oder höher
|
||||
- JAVA_HOME ist gesetzt
|
||||
|
||||
Vorgehensweise:
|
||||
- Dateien mit PRM als json in inputfiles Ordner anlegen
|
||||
- start.bat doppelklicken
|
||||
- warten bis Dateien in outputfiles erzeugt werden.
|
||||
Reference in New Issue
Block a user