Replies: 4 comments 3 replies
-
@haimari please take a look at: https://github.com/fluxcd/flux2-kustomize-helm-example |
Beta Was this translation helpful? Give feedback.
-
As far as I can see, it's way too early to be talking about 'best practices' with how to setup Flux for different use-cases. We're still discovering what patterns work and work well. You can define a Flux HelmRelease once and use a per-environment Kustomization patch to make the modifications to the values. Caring about duplication is a much lower priority than making sure my Flux model/layout works. My model is more complex as have a separate repo per environment and an environment can optionally be multi-tenant, with the tenant name as part of the target deployment namespace. I also need to deploy the same chart multiple times in an environment with a different release name and config. All of this is possible with Flux v2, but it requires experimentation with the repo layout and implementation of Flux and K8s Kustomizations. |
Beta Was this translation helpful? Give feedback.
-
This discussion is a few years old now, but interested to hear what patterns have solidifed over the years with relation to the subject. Personally, I prefer to avoid multiple branches and try and shift all logic away from branches to elsewhere in the pipeline. However, subjective and nuanced per requirement and environment. |
Beta Was this translation helpful? Give feedback.
-
We went the whole way of using a separate Git repo per K8s cluster. This is easier to manage and allows custom rules per repo for access and control. The downside is lack of off-the-shelf tooling for migration/promotion between Git repos. |
Beta Was this translation helpful? Give feedback.
-
Hello,
I'll try to describe the situation with as much details as I can.
Today I have 3 K8s (On Prem RKE) clusters in different DataCenters.
In Our Private GitLab(On prem) we have multiple microservices projects.
Each project currently builds only from the "Master" branch.
In the
release
stage of the pipeline, atag
is created as well as a docker image tag with the release version:v.0.0.2
in the Private GitLab Registry.On
release
the pipeline runs a stage which goes to a project named 'helm' which holds all helm charts of all projects, and updates thevalues.yaml
file of the specific project which was released with the newimage tag
ArgoCD then picks up the changes in the
helm
repository (apps created with Terraform) and updates the k8s app accordingly.What is wrong with the above flow ?
{{ .Release.Name }}
variable generally. (for example foringress host path
) forcing us to have too many duplications of configuration files.release
from master branch. other branches cannot be deployed as part of the same app... as they will overwrite the production release... or if we will deploy them as different service, they will not have the same endpoint and will not receive the same traffic, or provide a way to control the amount of traffic.What do we want to achieve ?
dev
branch is build with new code.I've been looking at the documentation of v2 and would like to know which if any of the requirements above can be achieved using flux.
Also if there are any Best practices for such GitFlow with multiple clusters.
Beta Was this translation helpful? Give feedback.
All reactions