Add helm chart

[waammar]

Purpose

Add Helm chart for Ralph

Description

Created the chart under src/helm I tried to migrate the logic from the .j2 tray files.
The version label was replaced as the helm convention for app.kubernetes.io/version
The checksum from the secret name was deleted. The annotation checksum/config: was used instead on the secret, the checksum is automatically generated from vault.yaml it help to update the secret object every time a value is updated.
Note that the .Chart.AppVersion is better used to track the version deployed and it should reflect the image.tag
There is only one vars files values.yaml the vault is under specific file vault.yaml used only for generating the secrets.

Questions

• Why do you have two service with the same config? the only difference is the label static
• What is deployment_stamp ?
• What is the purpose of prefix ?
• How would you like to manage env.?

ToDo

• Add README.md

You can use helm template . under ./src/helm/ralph to check the output of the chart, it will show you the final manifest that will be deployed.

[jmaupetit]

Why do you have two service with the same config? the only difference is the label static

To make a long story short: to be able to point to a service that has a fixed name (e.g. without blue-green suffix).
Context: openfun/arnold#427

What is deployment_stamp ?

Our way to distinguish stacks (previous/current/next) in a blue-green deployment strategy. Our playbooks use this selector.

What is the purpose of prefix ?

Prefix for ingresses?

How would you like to manage env.?

We want to use the most relevant/recommended community tools. What do you suggest?

[waammar]

Why do you have two service with the same config? the only difference is the label static

To make a long story short: to be able to point to a service that has a fixed name (e.g. without blue-green suffix). Context: openfun/arnold#427

Do you want to keep this strategy? you can still have one service, (one for each blue and green version) and add two host in the ingress for the last working (static) version with a hostname without the suffix blue/green

What is deployment_stamp ?

Our way to distinguish stacks (previous/current/next) in a blue-green deployment strategy. Our playbooks use this selector.

I assume you want to preserve this mechanism? so I need to implement this label on the chart

What is the purpose of prefix ?

Prefix for ingresses?

Yes, I saw it on ingress and services I assume now that the value will be either blue or green?

How would you like to manage env.?

We want to use the most relevant/recommended community tools. What do you suggest?

The convention is to start with one values.yaml file that contains all the default values and config, and add one values file by env. that only change the related configuration. You must then add the correct values file to your deployment argument, in next iteration we may think of using Helmfile tool, that may improve a bit the deploy process to make it more simple, in the long run, it is better to automate the deploy with CD tool like ArgoCD

[jmaupetit]

Why do you have two service with the same config? the only difference is the label static

To make a long story short: to be able to point to a service that has a fixed name (e.g. without blue-green suffix). Context: openfun/arnold#427

Do you want to keep this strategy? you can still have one service, (one for each blue and green version) and add two host in the ingress for the last working (static) version with a hostname without the suffix blue/green

No we don't want to keep Arnold-related strategy in this new standard implementation. From what we understand, flux/flagger can handle the blue-green deployment strategy without having to manage this as we did. As a consequence, only one version of each service is required: the static-one.

What is deployment_stamp ?

Our way to distinguish stacks (previous/current/next) in a blue-green deployment strategy. Our playbooks use this selector.

I assume you want to preserve this mechanism? so I need to implement this label on the chart

Nope.

What is the purpose of prefix ?

Prefix for ingresses?

Yes, I saw it on ingress and services I assume now that the value will be either blue or green?

This is a URL prefix, e.g. previous.my-service.com or next.my-service.com

How would you like to manage env.?

We want to use the most relevant/recommended community tools. What do you suggest?

The convention is to start with one values.yaml file that contains all the default values and config, and add one values file by env. that only change the related configuration. You must then add the correct values file to your deployment argument, in next iteration we may think of using Helmfile tool, that may improve a bit the deploy process to make it more simple, in the long run, it is better to automate the deploy with CD tool like ArgoCD

Duly noted. ArgoCD is in the scope, but for now you don't have to handle this complexity in the current implementation.

[waammar]

@jmaupetit Can you please make a full review of this PR? I made the final clean up.

[jmaupetit]

Great! I'll test it by the end of the day and give you more feedback.

[waammar]

I fixed some issues, but I still have one related to the auth.json of LRS, the yaml to json conversion is failing, it is also related to the complex logic here, maybe we should discuss the design of this solution

[jmaupetit]

As mentioned yesterday, this can be improved thanks to a ConfigMap (looping over a values.yml file configuration) injected in the environment.

[jmaupetit]

Thank you for this contribution @waammar!