englaender / camunda-blueprint Goto Github PK

Bessere Gruppierung von Ressourcen

Siehe Schaubild: https://textik.com/#660864b5e003e055

Soll nur den Header im GRPC Request mit Keycloak abgleichen und dann den Request weiterleiten an Gateway

Allgemein:
https://github.com/kubernetes-sigs/external-dns

Mit nginx ingress controller:
https://github.com/kubernetes-sigs/external-dns/blob/master/docs/tutorials/nginx-ingress.md

Wird trotzdem am Anfang gelesen?
-> funktioniert nur, wenn schon ein Context für diesen cluster-Namen besteht

camunda, nginx, clients

• reference mTLS Server Client example in readme and how to use it
• best practices for job workers (and roughly reference/document them in readme ?) see #8
• refactor to terraform

Desktop Modeler soll diesen Ingress verwenden können

Unternehmensnetzwerk an VPC anbinden über HA VPN Gateway: https://cloud.google.com/network-connectivity/docs/vpn/how-to/automate-vpn-setup-with-terraform#to_an_external_peer_network

Alternativ:

• nur Firewallregeln
• LB in Blueprint external lassen, Anbindung projektspezifisch machen

Geschützt durch OAuth und HTTPS
Dann automatisiertes deployen und starten möglich

https://www.github.com/elastic/helm-charts/issues/1731
Elasticsearch über Helm Chart wird wohl deprecated?
-> Wird bestimmt auch im Camunda Helm Chart verändert werden

bisher: Cluster IP
-> dann unabhängiger

Bisher:

• Error 500 bei falscher Authentifizierung
• keine Rollenbasierte Autorisierung (nur, ob Nutzer existiert)

-> Evtl besser möglich mit deutlich mehr Aufwand

Terraform Modul, welches anhand eines Container Images einen Spring-worker deployt

Vorher: operate.sandbox-lw-camunda.com
Nachher: 34.140.170.45/operate

Anzahl und Typ von Nodes + Resource-requests ertesten für:

• minimal
• prod

über Google Service
-> dann TLS möglich
-> https bei Apps

• Kommentare schreiben
• Variablen/Dateien gut benennen
• Alten Code löschen

Evtl mit Kommentar im Code jeweils beschreiben, für was es genau verwendet wird

cluster soll sich nie zerstören und wieder aufbauen bei Änderung der Anzahl der nodes

Derzeit stehen alle von Terraform generierten Passwörter plaintext im state file. Ebenso der private Key des SSL Certs.

External-Secrets:
https://external-secrets.io/v0.6.1/
https://external-secrets.io/v0.6.1/provider/google-secrets-manager/

Begriffe:
https://external-secrets.io/v0.6.1/api/clustersecretstore/
https://external-secrets.io/v0.6.1/api/externalsecret/

Soll deployen aus Desktop Modeler möglich machen (Authentifizierung mit OAuth)

bisher: selbst festgelegt als Plaintext in Terraform -> Kubernetes Secrets
-> generieren? Google Secrets?

Writing good workers:
https://docs.camunda.io/docs/components/best-practices/development/writing-good-workers/

pure java see : #18

Als Unterscheidung zwischen z.B. "dev" und "prod"
Existiert schon als Prefix für Namespaces

Zone z.B.: gcp.cimt-ag.de
Apps z.B.: tasklist.gcp.cimt-ag.de

Mit Google Domains oder Cloud Domains

https://docs.camunda.io/docs/self-managed/platform-deployment/helm-kubernetes/guides/ingress-setup/

Damit flexibel, ob Adresse
z.B. "host/tasklist"
oder
z.B. "tasklist.host/"
verwendet wird

See open PR for specific TODOs and progress

Frank hat base-infrastructure aufgeräumt
-> Eigene erstellen

Bisher: self-signed

Bisher nicht definiert -> abhängig davon, dass Provider in Root-Module alle definiert sind

Wenn ein Modul mehrfach im gleichen Projekt verwendet werden soll, entstehen immer Kollisionen bei den GCP Ressourcen (z.B. Static IP oder DNS Zone).
Bei den Kubernetes Ressourcen (z.B. Helm Charts) ist es aber sinnvoll, sie mehrfach im gleichen Projekt zu verwenden.
-> Trennen in verschiedene Module

Bisher: alles öffentlich im Internet
Besser: alles nur in unserem selbst definierten Netzwerk

Genauere Info: Problem liegt in der zeebe-node Library. Für den Keycloak-Aufruf wird die Library "got" verwendet. Der Aufruf erfolgt ohne Angabe eines Zertifikats (https://github.com/camunda-community-hub/zeebe-client-node-js/blob/master/src/lib/OAuthProvider.ts Zeile 127)-> got verwendet Standard Mozilla CAs (https://github.com/sindresorhus/got/blob/main/documentation/5-https.md). Angabe eines eigenen Zertifikats ist möglich und funktioniert (habe es getestet). Zeebe-node müsste diese Möglichkeit verwenden und der Modeler müsste eine Möglichkeit einbauen dieses Zertifikat zu übergeben.
Schritt 1 zur Lösung: Ich habe issue + pull request für zeebe-node erstellt.

(Unsicherer) Workaround bis fertig:
cmd in Location von Modeler öffnen
command: set NODE_TLS_REJECT_UNAUTHORIZED=0
dann Modeler starten
-> Modeler stoppt nicht mehr bei fehlgeschlagener Validierung