Flux CD v2 With GitOps Toolkit - Kubernetes Deployment And Sync Mechanism

Flux v2 is a tool for converging the actual state (Kubernetes clusters) into the desired state defined in Git. It is a GitOps-based deployment mechanism often used in continuous delivery (CD) processes.

Timecodes ⏱:
00:00 Intro
01:39 Creating environment repos
06:39 Bootstrapping
11:34 Creating sources
20:08 Deploying the first release
25:39 Deploying new releases
27:18 Promoting to production
30:06 What did I do?
32:16 Conclusion

[kenichishibata]

I love how forthright this is, we need more people having intellectual honesty like you :) great job!

[cne]

It would be much more clear if you had your path and GitHub repo/branch for the current directory displayed in your prompt. Otherwise good content, thanks.

[nbensa]

Excelent tutorial (as always from Viktor). What's missing here is how do I recreate the environments to a new cluster. I did `kubectl apply -k (twice because of crd issues) and then `kubectl apply -f path/to/fleet/apps/` and it seems to be working, but I'm not sure if it is "the right way".

[yongshengyang]

I have flux installed in cluster. Now I have to update the image tag inside the deployment.yaml file in code repo during my build pipeline running. Is there a good way to do it? I am trying to run some git thanks

[kazakman]

sorry but ur video is outdated all commands not working.
apart that flux bootstrap not working as well whenever u enter tokens. not connecting to github.
please update it.
remote add origin
push -u origin main etc etc

[kazakman]

This is ok for beginners hands on
Keep in mind in real Corp world it is different when u got 5 clusters with 5 different repository
U need helm chart to install them and make sure they are syncing with ssh keys

[StephenSpencer]

Indeed. I didn't see the original version. This one is a very well done introduction! Also, thank you for the (gentle) acknowledgement of the quality of flux's documentation ^relative to the code and function. The kube ecosystem is littered with so many hyperbolic claims of the This-Will-Change-Your-Life variety that worthwhile projects can be overlooked simply because the documentation is poorly written and/or poorly maintained.

(and in case any fluxcd contributors are reading, try to limit the use of the word "declarative" to no more than twice on any given doc page :grin:)

[QnJhbQ]

Thank you so much for your videos! I really like them. It would be a bit improvement to show Git / Directory context in the PS1 of your shell so it's easier to follow. Just a thought :)

[rubbercable]

Please increase the recording volume.
I have to turn my volume to to 7 to hear you, then my speakers get blown out with the Ads.

[webmakaka]

Hi! Thanks for videos! Can you also write a video about FluxCD 2 + Flagger in the future.
Thanks!

[--QS--]

Hi, first of all I appreciate the effort you are putting into your videos. 
When I tried to follow along I noticed a problem, when adding private repos. 
If I use the url method authentication is a problem and if I use the ssh method flux creates a dialog, which is piped into the corresponding file. Thereby corrupting it. 
My Solution is adding private repos manually, which works but is not 100% GitOps. 

Also: Flag --validation has been deprecated, this arg is no longer used, all resources are validated using server-side apply dry-run

Has anybody some ideas regarding this Problem?

Best Regards QS

[sujaydey]

Just started exploring this channel and I am already loving it❤

[nikolanovkovic]

Hello,
At @7:35 "the path where we will store the definitions, the manifests is 'apps', remember we created that directory before"... Can you explain this? You've created apps directories in production and staging repo. Now, you are initialising new repo. How are 'apps' folders between theese three repos conected?

Great content btw, keep up the good work!

[JohnMatthew]

Thanks for the demo and enthusiasm! Also, i was unclear on how to do a helmrelease, so thanks for showing that :)

[Digalog]

Why having separate repositories for environments ? why not use branches ?

I don't understand entirely this central fleet repository. So I have to configure both a staging system and a production system pointing to this fleet repository meaning both clusters need a secret to update the same git repo. That means you need to fine grain RBAC to the secret on the staging system because if you give (rather you want developpers to have decent ) access on the staging system would give them implicitly access to the same secret to write to the fleet-system for prod.. a security risk for people to change things on the production system may they get access to this secret on the staging system.

[ashhere]

Thank god you have favorable opinion of Flux v2 now.
I used it and thought it was an excellent improvement over Flux V1.
And having read your books, it matters to us what you think is ok and what you think is great related to DevOps and K8s

So appreciate this video and candid opinion

[vincentyin]

Super! You said at the end of the video that you might make another video "in 6 months" about your up-to-date opinion of Flux vs. ArgoCD. That timeline has arrived. I'd be very interested to hear your current opinion. One particular problem I can't find a solution for is that Flux doesn't seem to have an equivalent to the command `argocd app wait ...` or `helm upgrade --wait ...`.

[nachof]

What's confusing to me is that ideally developers will simply be making changes to the app source code, and not the infrastructure yaml. The app code needs to be containerized, the container deployed to a registry, and the deployment changed to point to the corresponding tag. This solution does not seem to cover that unless I'm missing something.

[koodauskanava]

flux get sources git is giving me this error error: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain

[bobbyray]

Really loving your videos man. Keep it up.

Also -w in kubectl will watch, no need to use watch cmd