I didn't know you were a Udemy instructor. I'll take your "DevOps Catalog, Patterns, And Blueprints" course. You're doing a great job man. Thank you so much.
wonderful ; May I know how does the destination namespace "production" works. Can it be set from the argocd UI. And where is that ingress host get substituted
Argo CD UI is not meant to be used to create resources in k8s. That would defy its purpose. What you can do is push define the Namespace is push it to Git.
Nice concept "app of apps". I'll try that like "app of appsets which generates apps" because I want to reuse as much as I can for many apps in one appset.
Thank you for your nice videos. Please do you have a tutorial, for an end-to-end ci/cd pipeline where the image tag in the values file is updated, and this update is pushed to the gitops (k8s minifest) repo to trigger the CD? thank you
The real competitor of Argo CD is Flux. Both are very similar and it would be hard to say that one is clearly better than the other. All the other tools I know in that area are either a waste of time or are built on top of one of those two.
Hi Viktor. What is your approach for cicd in gitops in terms of do you change the new image in the argo app only or do you change the new image in the source values file of the helm chart too? Thanks upfront.
As far as I know, it'll not create namespaces automatically without you telling it to do that. Argo CD applies whichever manifests it finds in the repo it monitors. It's up to us to make sure that those manifests are what they should be, including Namespaces we want to use.
Thank you for this video, Viktor. Could you please explain diff between ArgoCD & Tekton? And also, could you please make a video on how to use both together & advantages/disadvantages of using them together?
Great suggestion! I'll start by doing individual videos for those I haven't done before. That would be Tekton and Jenkins X (I made a lot of material about JX, but that's all older than a year). After that, I'll probably do a comparison between all those.
Just published a video about Tekton (th-cam.com/video/7mvrpxz_BfE/w-d-xo.html). Next should be Jenkins X and then I can do a comparison. Argo CD and Flux CD are completely different categories. They are not pipelines and they do not do CD (except having it in their names). They are GitOps-style deployment mechanisms.
@@DevOpsToolkit awesome! yes, that's why the combo between these tools are great. Instead pushing deployments using tekton, gitlabci, etc.. use instead gitops strategies to constantly pulling for changes in the state.
If you want to ask whether it can use "pure" Kubernetes YAML instead of Helm charts, the answer is yes. It can be Helm, Kustomize, "pure" YAML, and, probably, a few others.
Good stuff... just started new project and definitely moving to a similiar GitOps workflow using GitLab, Helm, ArgoCD and k8s. WHat was the name of the software tool used to draw your diagram on screen?
When I recorded that video, I used krita.org with a green background that is removed by OBS while recording. Since then, I moved to presentify.compzets.com/ which allows me to draw directly over the screen.
So.. We use ArgoCD and we're looking to use Argo Rollouts - but I have a question for you.. What if we wanted a progressive delivery model to release and support multiple versions of an application?.. For example, we release V2 with breaking changes and we need to have V1 and V2 running, do we treat this new V2 as a brand new application altogether and handle the routing ourselves at the ingress controller, or is there a way to have a single argo application definition that has two versions of the same application and support progressive delivery of both versions simultaneously?..
How would that work on the Ingress level? Would both V1 and V2 be accessible through the same host? If the answer is yes you'd need something else that would ensure that a request is redirected to the correct version. Typically, you would need to add some identifier to the requests. On the other hand, if you prefer to have those accessible through different hosts, I would just deploy it as a different application.
It's very hard for me to know what is beginner and what is advanced, mostly since my own learning process is chaotic and unstructured. Maybe you can help by giving me tips whether a video you watched is beginner or advanced?
Argo CD is concerned only about synchronization of different states. To build an image, you can, for example, use Kaniko ( th-cam.com/video/EgwVQN6GNJg/w-d-xo.html ). You might want to watch th-cam.com/video/XNXJtxkUKeY/w-d-xo.html as well. It is about combining different tools to automate full lifecycle, including building images
I forgot to answer "when"... You build a new image whenever you push changes to a git repo of an app. Typically, that would trigger a webhook that would notify something that there was a change in an app repo. That something can be any pipeline/workflow tool. You'll find a video about Argo Workflows in my channel, but it could be just as well any other like, for example, Jenkins, Circle I, etc.
@@ViktorFarcic i feel like thats the issue with all of the current ci cd tools depending On yaml, feels like doing it in some language like go could work better
@@amabamo5769 I agree completely. Jenkins has that through its DSL. However, new pipeline tools are ignoring it completely and focusing on YAML. That's, in a way, strange, since pipelines are not declarative in nature, but, rather, imperative statements of what should be executed under which conditions.
@@DevOpsToolkit This leads to a problem where most of my commits are just fixing the .gitlab-ci.yml. I don't feel like any yaml based pipeline tool is gonna be good enough. I also wonder what people that came to the same conclusion are working with. What are the tools or resources that the smart people are using?
My approach to CI/CD is to work on pipelines at the very end. The idea is to write all the automation scripts first, and then use whichever pipelines tool you have only to orchestrate those scripts. Preferably, I would keep all those scripts inside repos so the job of my pipelines is only to clone a repo and execute commands like `run-tests.sh`, `build-image.sh`, etc. That way, testing is easier, and there isn't much coupling between automation and pipelines. That being said, I think that many are taking the opposite approach and start defining everything in pipelines.
Is it possible to use values.yaml in this flow to allow for dynamic helm charts? Is argoCD able to dynamically create the a templates referencing .Values.xxx.xxx?
I'm not sure what you mean by "dynamically". Argo CD Application manifest can include Helm values but something needs to create/update the manifest. The goal of GitOps is to have the desired state stored in Git so everything needs to end up, in one form or another, in version control.
@@DevOpsToolkit in your demo you overwrite some helm values via the Argo application manifest. I want to know if it is possible to instead use a values.yaml file located in the git repo (in the helm directory) for these values.
@@Kcouture0827 You can do that through `spec.source.helm.valueFiles` entry. The values over there are paths relative to whatever you set in `spec.source.path` which, in your case, should be the directory of the Helm chart.
Good job
I really like the direct approach you use to show things actually running. Great video :D
I didn't know you were a Udemy instructor. I'll take your "DevOps Catalog, Patterns, And Blueprints" course.
You're doing a great job man. Thank you so much.
Thank you for saying that.
Another awesome video ❤, thank you Viktor we appreciate you 🙏
wonderful ; May I know how does the destination namespace "production" works. Can it be set from the argocd UI. And where is that ingress host get substituted
Argo CD UI is not meant to be used to create resources in k8s. That would defy its purpose. What you can do is push define the Namespace is push it to Git.
@@DevOpsToolkit I tried, unfortunately project with different name are not created ?
@@SanjeevKumar-nq8td I'm not 100% sure what you meant by "project with different name are not created" in relation to namespaces.
This is great! I'm just starting to learn Argo CD for work, I'm looking forward to starting your course.
Nice concept "app of apps".
I'll try that like "app of appsets which generates apps" because I want to reuse as much as I can for many apps in one appset.
superb high-level, basic introduction to ArgoCD. Thank you.
Great video. You are rock!
Thank you for your video.
@DevOpsToolkit
Why you didn't use Application Set?
When that video was published, Application Sets were still in the planning phase.
Very clear demonstration. Thank you!
I really enjoy to watching your videos :)
Looks like you got some new upgrades... you deserve them.
This introduction was great! Thank you very much for producing this. My team will love Argo. :D
Thank you very much for all effort, i really wanted to buy your udemy course, but could not find it
I removed all my Udemy courses. The tech changes fast and i felt that those courses do not fully represent recommendation i would give today.
Thank you Viktor!..really great explanation!
Great job. Bought the course starting now.
Hope you enjoy it!
Thank you for your nice videos. Please do you have a tutorial, for an end-to-end ci/cd pipeline where the image tag in the values file is updated, and this update is pushed to the gitops (k8s minifest) repo to trigger the CD? thank you
Will do... Ading it to my TODO list...
This is really helpful. Can you please tell how Argo CD is different from other tool like seldon.
I have not yet tried Seldon so I cannot compare it with Argo CD. Judging from a quick glimpse at it, it seems to be a wrapper around Argo CD.
The real competitor of Argo CD is Flux. Both are very similar and it would be hard to say that one is clearly better than the other. All the other tools I know in that area are either a waste of time or are built on top of one of those two.
Can you please show this exact same thing but on the Terraform?
I can't do the same with Terraform since it is a different type of tool (it's IaC and not GitOps). I could show the same with Flux or Rancher Fleet.
@@DevOpsToolkit Yea, Flux will be good as well
Adding it to my TODO list... :)
Hi Viktor. What is your approach for cicd in gitops in terms of do you change the new image in the argo app only or do you change the new image in the source values file of the helm chart too? Thanks upfront.
I tend to keep manifests in the main branch with tags that reflect production with the option to overwrite that in argo CD app.
@@DevOpsToolkit thanks.
Thanks for sharing.
Does this video come with a gist url?
That one doesn't :) I started adding Gists soon after I published that one.
i often press like button then watch video:)
Great video Viktor. Does Argocd allow to create namespaces automatically based on branch names? Or does that have to be configured manually?
As far as I know, it'll not create namespaces automatically without you telling it to do that. Argo CD applies whichever manifests it finds in the repo it monitors. It's up to us to make sure that those manifests are what they should be, including Namespaces we want to use.
@@DevOpsToolkit Thanks Viktor. Just saw your other video on argocd and pull requests. That is not far off where we await to get to.
Thank you for this video, Viktor.
Could you please explain diff between ArgoCD & Tekton? And also, could you please make a video on how to use both together & advantages/disadvantages of using them together?
That's a good idea. I'll do my best to work on it ASAP.
It's done and available in th-cam.com/video/dAUpAq7hfeA/w-d-xo.html
@@DevOpsToolkit thank you so much
So how is having an application referencing other two applications different from ArgoCD AppProject resource type?
Argo project does not reference any repo/manifests. The project is mostly about permissions.
very nice! love it
Very practical! Thanks for share it. It would be nice to have a comparison (or possible combination) between Argo CD, Tekton, Flux CD, JenkinsX, etc..
Great suggestion! I'll start by doing individual videos for those I haven't done before. That would be Tekton and Jenkins X (I made a lot of material about JX, but that's all older than a year). After that, I'll probably do a comparison between all those.
Just published a video about Tekton (th-cam.com/video/7mvrpxz_BfE/w-d-xo.html). Next should be Jenkins X and then I can do a comparison.
Argo CD and Flux CD are completely different categories. They are not pipelines and they do not do CD (except having it in their names). They are GitOps-style deployment mechanisms.
@@DevOpsToolkit awesome! yes, that's why the combo between these tools are great. Instead pushing deployments using tekton, gitlabci, etc.. use instead gitops strategies to constantly pulling for changes in the state.
Thanks. Excellent Job !
Glad you liked it!
Amazing content!👍🏻
Is there any possibility to point specific tag to deploy ,not latest tag
Yes, there is. You can point to anything in Git (branch, commit, tag, etc.).
Great video, thank you
Excellent content. Love the channel and whats-a-not.
Can you create a video on kpack?
Great suggestion. Adding it to my TODO list...
Done :)
th-cam.com/video/fbSoKu8NGSU/w-d-xo.html
Great video!
Thanks!
It is unclear why a Chart.yaml is needed? Can ArgoCd just peek up yaml files for applications from a specified directory?
If you want to ask whether it can use "pure" Kubernetes YAML instead of Helm charts, the answer is yes. It can be Helm, Kustomize, "pure" YAML, and, probably, a few others.
Many thanks!
Is the udemy course out for argo?
It's not. I did not even start working on it. For now, my focus is on free TH-cam content.
@@DevOpsToolkit I’m not complaining. Keep up the great work. I’m working my way through your vids :)
Nice work. You have a typo in the title though. Add an article, “manage a production” not “manage production”
Thanks for that. Title changed...
thanks a lot, keep posting more on this
Thank you, I will
Good stuff... just started new project and definitely moving to a similiar GitOps workflow using GitLab, Helm, ArgoCD and k8s. WHat was the name of the software tool used to draw your diagram on screen?
When I recorded that video, I used krita.org with a green background that is removed by OBS while recording. Since then, I moved to presentify.compzets.com/ which allows me to draw directly over the screen.
So.. We use ArgoCD and we're looking to use Argo Rollouts - but I have a question for you.. What if we wanted a progressive delivery model to release and support multiple versions of an application?.. For example, we release V2 with breaking changes and we need to have V1 and V2 running, do we treat this new V2 as a brand new application altogether and handle the routing ourselves at the ingress controller, or is there a way to have a single argo application definition that has two versions of the same application and support progressive delivery of both versions simultaneously?..
How would that work on the Ingress level? Would both V1 and V2 be accessible through the same host? If the answer is yes you'd need something else that would ensure that a request is redirected to the correct version. Typically, you would need to add some identifier to the requests. On the other hand, if you prefer to have those accessible through different hosts, I would just deploy it as a different application.
please make proper playlist on kuberneets beginneradvanced so hthat all benfited
It's very hard for me to know what is beginner and what is advanced, mostly since my own learning process is chaotic and unstructured. Maybe you can help by giving me tips whether a video you watched is beginner or advanced?
Thanks man!
Very nice :)
Hi Victor! I am missing the point of where and when the new image version is getting built of the apps.
Great videos, thank you!
Argo CD is concerned only about synchronization of different states. To build an image, you can, for example, use Kaniko ( th-cam.com/video/EgwVQN6GNJg/w-d-xo.html ). You might want to watch th-cam.com/video/XNXJtxkUKeY/w-d-xo.html as well. It is about combining different tools to automate full lifecycle, including building images
I forgot to answer "when"... You build a new image whenever you push changes to a git repo of an app. Typically, that would trigger a webhook that would notify something that there was a change in an app repo. That something can be any pipeline/workflow tool. You'll find a video about Argo Workflows in my channel, but it could be just as well any other like, for example, Jenkins, Circle I, etc.
@@DevOpsToolkit Ah okay, I see now in your all-in-one Argo video: th-cam.com/video/XNXJtxkUKeY/w-d-xo.html Thank you!
Dude you look like a gamer and also talks like a gamer
8:10 Q: Should you also change metadata name to devops-paradox? / 9:15 A: Yes
That's what happens when doing it, more or less, loosely unscripted and partly improvised. Mistakes are bound to happen.
@@ViktorFarcic i feel like thats the issue with all of the current ci cd tools depending On yaml, feels like doing it in some language like go could work better
@@amabamo5769 I agree completely. Jenkins has that through its DSL. However, new pipeline tools are ignoring it completely and focusing on YAML. That's, in a way, strange, since pipelines are not declarative in nature, but, rather, imperative statements of what should be executed under which conditions.
@@DevOpsToolkit This leads to a problem where most of my commits are just fixing the .gitlab-ci.yml. I don't feel like any yaml based pipeline tool is gonna be good enough. I also wonder what people that came to the same conclusion are working with. What are the tools or resources that the smart people are using?
My approach to CI/CD is to work on pipelines at the very end. The idea is to write all the automation scripts first, and then use whichever pipelines tool you have only to orchestrate those scripts.
Preferably, I would keep all those scripts inside repos so the job of my pipelines is only to clone a repo and execute commands like `run-tests.sh`, `build-image.sh`, etc.
That way, testing is easier, and there isn't much coupling between automation and pipelines.
That being said, I think that many are taking the opposite approach and start defining everything in pipelines.
A wizard.
👌
Thank you for this 😀😀😀😀😀😀😀
Is it possible to use values.yaml in this flow to allow for dynamic helm charts? Is argoCD able to dynamically create the a templates referencing .Values.xxx.xxx?
I'm not sure what you mean by "dynamically". Argo CD Application manifest can include Helm values but something needs to create/update the manifest. The goal of GitOps is to have the desired state stored in Git so everything needs to end up, in one form or another, in version control.
@@DevOpsToolkit in your demo you overwrite some helm values via the Argo application manifest. I want to know if it is possible to instead use a values.yaml file located in the git repo (in the helm directory) for these values.
@@Kcouture0827 You can do that through `spec.source.helm.valueFiles` entry. The values over there are paths relative to whatever you set in `spec.source.path` which, in your case, should be the directory of the Helm chart.
@@DevOpsToolkit perfect. That’s what I was looking for. Thanks, you the man!