Github Helm Chart - Githubissues

hupling commented 4 months ago

ein Chart zusammen für Frontend und Backend. also helm install und man hat alles
helm create
lhm spezifische Sachen in die values.yml auslagern
anders als das Dave-Projekt auch versuchen möglichst wenig Code zu kopieren. z. B. einmal eine Deployment erstellen und dann in den Sub-Charts darauf referenzieren
[ ] helm create
[ ] beispiel in https://github.com/it-at-m/helm-charts
[ ] template erstellen

hupling commented 2 months ago

@banzuu https://github.com/it-at-m/helm-charts/tree/main/charts/refarch-gateway bitte auch das vom refarch-team anschauen

hupling commented 2 months ago

@simonhir @devtobi @DanielOber also für mich macht das Chart refarch-gateway keinen Sinn. Es ist für mich sinnvoller, wenn es das Chart refarch gibt. Als externe Firma möchte ich keine 10 Helm-Charts brauchen für eine Software, sondern das Backend/Frontend in einem Helm Chart. Es wäre schön, wenn das SPS-Team eure MergeRequests zu Actions/Helm-Charts/Dockerfiles vor dem Mergen reviewen können. Weil sonst muss man wieder alles einzeln zusammenbasteln, um einen gleichen Stand zu haben, wie bei den Github-Actions jetzt. https://github.com/it-at-m/.github/issues/18

simonhir commented 2 months ago

Meiner Meinung nach stimmt das schon, weil du im Realfall, nur das Gateway übernimmst und der Rest individuell ist. Das heißt jeder Service hat ein eigenes Helm-Chart welches dann nur das Refarch-Gateway Helm Chart einbindet als Dependency.

Hab das bei DigiWF mal testweise gemacht, wobei hier jetzt noch eigene zusätzliche Services fehlen: https://git.muenchen.de/digitalisierung/digiwf/digiwf-ops/-/merge_requests/490

devtobi commented 2 months ago

@simonhir @devtobi @DanielOber also für mich macht das Chart refarch-gateway keinen Sinn. Es ist für mich sinnvoller, wenn es das Chart refarch gibt. Als externe Firma möchte ich keine 10 Helm-Charts brauchen für eine Software, sondern das Backend/Frontend in einem Helm Chart. Es wäre schön, wenn das SPS-Team eure MergeRequests zu Actions/Helm-Charts/Dockerfiles vor dem Mergen reviewen können. Weil sonst muss man wieder alles einzeln zusammenbasteln, um einen gleichen Stand zu haben, wie bei den Github-Actions jetzt. #18

Alternativ wäre es natürlich eine Möglichkeit, wenn wir im Refarch-Templates ein Helm-Chart bereitstellen, welches das Deployment der gesamten Anwendung mit allen Komponenten ermöglicht. Nachteil hierbei ist, dass wir dann nicht per se ein Helm Chart Release können, sondern die Projekte ihre individuellen Helm Charts selbst managen müssen. Das API-Gateway wäre somit dann Teil des Template-Helm-Charts. Da das API-Gateway aber künftig nur noch als fertiges Image von anderen Projekten genutzt werden soll, macht es m.M.n auch Sinn, dass es hierfür ein gesondertes separates Helm-Chart gibt. Das RefArch-Template Helm-Chart könnte dann wie von @simonhir beschrieben als Dependency eingebunden werden.

hupling commented 2 months ago

so sieht der neue stand aus:

frontend --> image ngix ( nicht außen erreichbar)
apigateway -> leitet alles weiter (auf frontend/backend) (außen erreichbar)
backend -> so wie bisher ( nicht außen erreichbar)

hupling commented 1 month ago

Ich habe erstmal eine docker-compose.yml

name: sps-test
services: 
    frontend:
        image: ghcr.io/it-at-m/sps/sps-frontend:latest
        ports:
          - "8080:8080"
    backend:
        image: ghcr.io/it-at-m/sps/sps-backend:latest
        environment:
          SPRING_PROFILES_ACTIVE: openshift,dev,no-security
        ports:
          - "8082:8080"

    gateway1:
        image:     ghcr.io/it-at-m/refarch/refarch-gateway:1.0.0
        ports: 
         - "8083:8080"
        environment:
            SPRING_PROFILES_ACTIVE:  no-security
            SSO_ISSUER_URL: https://sso.muenchen.de/auth/realms/muenchen.de

            SPRING_CLOUD_GATEWAY_ROUTES_0_ID: backend
            SPRING_CLOUD_GATEWAY_ROUTES_0_URI: "http://host.docker.internal:8082/"
            SPRING_CLOUD_GATEWAY_ROUTES_0_PREDICATES_0: Path=/api/beispielprojekt-backend-service/**
            SPRING_CLOUD_GATEWAY_ROUTES_0_FILTERS_0: RewritePath=/api/beispielprojekt-backend-service/(?<urlsegments>.*), /$\{urlsegments}        
            SPRING_CLOUD_GATEWAY_ROUTES_0_FILTERS_1: RemoveResponseHeader=WWW-Authenticate

            SPRING_CLOUD_GATEWAY_ROUTES_1_ID: frontend
            SPRING_CLOUD_GATEWAY_ROUTES_1_URI: "http://host.docker.internal:8080/"
            SPRING_CLOUD_GATEWAY_ROUTES_1_PREDICATES_0: Path=/**
            SPRING_CLOUD_GATEWAY_ROUTES_1_FILTERS_0: RewritePath=/(?<urlsegments>.*), /$\{urlsegments}        
            SPRING_CLOUD_GATEWAY_ROUTES_1_FILTERS_1: RemoveResponseHeader=WWW-Authenticate

hupling commented 1 week ago

von @simonhir :

wieso seid ihr den bei dem internen helm-template soweit von dem Standard-Template weg gegangen? Macht es vll Sinn mal eine Abwandlung von diesem zu erstellen, weil das einzige was intern ja besonders ist sind die BuildConfigs und ImageStreams oder?

Dann könnte man das halt einfach nach OpenSource bewegen Hab z.B. beim Günther jetzt auch das Standard-Template verwendet und dann manuell BuildConfig und ImageStream dazu gebaut, weil jetzt schon feststeht, dass das nach OpenSource soll

hupling commented 1 week ago

@simonhir https://git.muenchen.de/ccse/ospo/-/issues/357 Also zuerst hat @eidottermihi das Helm Chart Repo aufgesetzt. Er hat die Repos mit helm create erstellt. Dieses System habe ich dann einfach übernommen.

Versionierung ist auch wichtig damals haben wir das auch nicht beachtet, weil wir wollten nur den Template-Engine nutzen. Umso mehr Funktionen, umso komplizierter wird es.

Diese Helm Charts sind dann auch generischer, um auch in Kubernetes zu installieren.

Außerdem ist es auch besser Charts in Subcharts zusammenzufassen. So kann man einfach mit helm install installieren und musst nicht Backend/ Frontend installlieren

Als externe Firma möchte ich keine 10 Helm-Charts brauchen für eine Software, sondern das Backend/Frontend in einem Helm Chart.

@ejcsid hat damals auch schon Subcharts vorgeschlagen https://git.muenchen.de/ccse/cicd/archived-projects/helm/helm-samples/helm-subcharts. Leider habe ich das damals zu kompliziert gefunden. Aber jetzt haben wir auch mehr Erfahrung in Helm gesammelt.

Wir haben jetzt auch bisschen out-of-the-box gedacht.

Du kannst gerne auch intern Verbesserungsvorschläge bringen https://git.muenchen.de/ccse/cicd/sps/-/issues/609

simonhir commented 1 week ago

Genau das meinte ich, würde es besser finden, wenn sich das interne auch mehr an helm create orientiert und dann quasi nur zusätzlich Sachen dazukommen wie BuildConfig und ImageStream. Diese könnten man bei dem Wechsel zu OpenSource dann einfach ausbauen.

Worin sich die beiden Templates meiner Meinung nach am meisten unterscheiden ist das Thema, dass in dem Helm-Template der Release als Prefix genutzt wird. Dadurch muss man dann auch in den internen CIs beispielsweise den Namen für die BuildConfig überschreiben (ist jetzt nicht viel Aufwand muss man nur beachten).

An das Thema mit den Subcharts hab ich auch schon öfter gedacht, glaube da muss man einfach eine Art BestPractice vorgeben, weil das meiner Meinung nach teilweise in Konflikt mit der Anmerkung von oben z. B. einmal eine Deployment erstellen und dann in den Sub-Charts darauf referenzieren steht. Wenn man ein Subchart für Front- und Backend anlegt, hätte man damit ja auch zwei relativ ähnliche Deployments, wenn man es sauber trennt.

simonhir commented 1 day ago

Hab es beim SWIM jetzt mal mit dem default helm create umgesetzt:

Wie gesagt muss man dann eben den BuildConfig- und Deployment-Namen überschreiben und die CI für das Helm-Chart etwas anpassen (In dem obigen Beispiel etwas mehr, weil da zwei unabhängige Charts rein sollen).

it-at-m / .github

Github Helm Chart #14