please please on youtube we want like nana devops , devops guy very very simple yet understanble just and projct way K8 realtime Q Most important Kubernetes 7-8 topics as per recent competition and live interview , these questions asking regular concept istio , what is service mesh very imp , ingress controller nginx why v imp? fluend for logs , prometheus grafan how intall monitor k8 , helm why? how?, gitops flow explanation using argo operator vimp .( helm and prome.. in all projects 100 prcnt questions ) concept of role based access security , service accounts very imp , meaning of manifest. meaning of policy in K8 , pod lifecycle what stages like pending? ===================================================================================================================================================== Terraform realtime concept asking- State file , global S3 state local state , taint untaint , import ,(how sync manual machine by mistake creation and the current state), using cache terraform fast process.
I'm not convinced about what seems to be a k8s centric (or "k8s native") CI/CD system. I quite like GitHub Actions (TypeScript beats YAML templating every time), GitLab [CI], and Buildkite. Do you have a video about the advantages of a k8s native solution?
@@steshaw6510 Being k8s-native does not necessarily mean that it is better or worse than NOT being that. Instead, it means that it was designed for Kubernetes (e.g., CRDs, communication through Kube API, operators, monitoring, scaling, etc.). Unfortunately, I don't have a video taking specifically about the advantages (and disadvantages) of k8s-native solutions. Let me add that to my TODO list...
@@DevOpsToolkit great, thanks! One thing might be that you need at least 3 nodes. I find it strange that CI developers want to build on k8s with CRDs for everything. It seems kind of constraining, so there must be a big payoff that I am missing. Beyond k8s fever that is 😉
Haven't used Tekton yet, but I've already had a lot of experience working with Argo Workflows... and I really love it! There is so much you can do just with pure Argo Workflows: simulating try-catch statements, retries, excellent artifact repository support from S3 to HDFS, workflow metrics to Prometheus, workflow of workflows, automatic workflow's archiving,.... this is really amazing. The only weak point is the documentation - sometimes it's hard to find the answer. But the community provides numerous examples in the git repo and it really helps!
I do not like calling it CI and CD since people tend to interpret it differently. Instead, I tend to say "pipeline" and "sync" tools. Pipelines execute a set of steps as a reaction on a commit to a git repo. That would be Argo workflows, tekton, Jenkins, GitHub actions, etc. Sync tools (or GitOps tools) are synchronizing the actual (cluster) into the desired (git) state and doing that continuously instead as a one-shot reaction to, let's say, git commits.
Seems you haven't explored Tekton Triggers. It's a great add-on to Tekton and you can create any event for triggering your Tekton pipelines. Maybe not used as a standalone tool, Tekton Triggers is very easy to set up and works miraculously with Tekton pipelines.
Being neutral and truthful is the most important guideline in this channel. If you follow my work history you'll notice that I avoided talking about certain subjects when that would prevent me from being truthful.
Thank you! Before watching your videos, from personal research I had concluded that Tekton was better, because Argo was limited to just cd. Turns out, I was completely wrong, there is Argo cd, workflows, events, and rollouts, which makes it a far superior project! And as you said Tekton is too low level for most end users! Thank you for putting me back on the right track, you saved me so much time! 🙏
Yeah, I also thinked the same. I went there after I heard about Argo Workflows 3.3 release, where there was a multi-tenancy big change in the changelog. I'm trying Jenkins X for a few weeks, but if it will not suit needs then I will give Argo Workflows a chance.
Amazing video as always, thanks a lot!! But this time I have some doubts about your analysis... First of all I think you missed an important point in the decision flow: cli tool (argo cli vs tkn cli). I know we should always go for GitOps but for debugging, and especially at the beginning, a good cli tool is really important. Then in the "Web UI" section you forgot to mention that Tekton UI is completely insecure :( no auth, no rbac, nothing... just a simple UI! Instead Argo Workflows offers different auth mode (server, client and sso) and better security (closer to ArgoCD UI which is PCI compliant!) So imo Argo Workflows UI is way better than Tekton. Moreover in the "Events and Triggers" section I think you were a bit too short and fast. Argo Events is a complete stand-alone project in respect to Argo Workflow, created as an event-based dependency manager, not only to trigger Argo Workflows. Instead Tekton Triggers (which you didn't mention) is made only for the purpose of triggering a pipeline. So in this area maybe Argo Workflows + Events could be better, but not SOOO BETTER than Tekton. Finally projects built on top of Tekton... JenkinsX is not stable, not mature and not same as OpenShift Pipelines. OpenShift Pipelines hides Tekton and gives you a better UI in the same style and completely integrated with OpenShift. JenkinsX instead is completely opinionated, if you want to customize something you have to deal directly with Tekton, uses Prow instead of Tekton Triggers forcing you to deal with that as well, and the UI is only a plugin of Octant.
> for debugging, and especially at the beginning, a good cli tool is really important. You're right. I should have included the CLI as one of the comparison points. > Instead Argo Workflows offers different auth mode (server, client and sso) and better security (closer to ArgoCD UI which is PCI compliant!) You're right about that one as well. I should have included auth. > Moreover in the "Events and Triggers" section I think you were a bit too short and fast. I did pass through it in the UI section. However, later on, I did talk about events and stated that as probably the main differentiators between the two. Argo Events are awesome and Tekton has a webhook trigger only that is silly. > Finally projects built on top of Tekton... JenkinsX is not stable, not mature and not same as OpenShift Pipelines. OpenShift Pipelines hides Tekton and gives you a better UI in the same style and completely integrated with OpenShift. JenkinsX instead is completely opinionated, if you want to customize something you have to deal directly with Tekton, uses Prow instead of Tekton Triggers forcing you to deal with that as well, and the UI is only a plugin of Octant. I did not want to go deeper into projects on top of Tekton since I felt that would derail the video. But, instead of skipping them, I thought it is fair to mention their existence. I'm planning separate once about Jenkins X and OC Pipelines. All that being said, it's difficult to condense everything in ~20 min., and I often make mistakes and miss the things that might be important. Improving as we go...
@@DevOpsToolkit > All that being said, it's difficult to condense everything in ~20 min., and I often make mistakes and miss the things that might be important. Improving as we go... Of course! I posted my impressions, doubts and suggestions for sake of completeness and discussion :) > I did pass through it in the UI section. However, later on, I did talk about events and stated that as probably the main differentiators between the two. Argo Events are awesome and Tekton has a webhook trigger only that is silly. Probably a bit too fast, maybe an additional 30sec/1min, anyway... imo it's not silly that Tekton includes/offers only triggers... it's a CI/CD specialized tool, not a broader one like the Argo ecosystem...
This is a great comparison. I like other parts of the Argo ecosystem, so it's good to see it hold up here. I get concerned about doing builds in k8s clusters because of performance issues. Builds need to be fast. Building large projects-particularly native/AOT ones-can be quite time consuming (e.g. C, C++, Haskell, and Rust). Both CPU cores and fast disks are required to reach acceptable build times for some projects. I tend to favour build agents on powerful bare metal machines with very fast SSDs or RAM disks. What do you think about this scenario, would you prefer a custom k8s cluster with powerful bare metal nodes as above? I'm thinking that best of both worlds is to have Argo take over deployment once a container hits a registry, etc.
Being a k8s cluster might cause some performance issues around networking but that applies mostly to cases when extremely fast response times are concerned. For pipeline type of tools, k8s tend to have an opposite effect. It improves performance due to k8s capability to schedule Pods to nodes that have available resources and to reduce or even eliminate the time something is waiting in a queue and distribute parallel executions to multiple pods/nodes. Now, all that assumes that the k8s cluster is running on the same hardware as pipelines that are not running in k8s. Even if performance is not increased, the amount of resources used will be decreased. So you either get a performance boost or you end up being the same but with fewer resources used. All that assumes that quite a few things are done right. For example, you need to define resource requests and limits, and, maybe, affinities, so that k8s knows where to schedule pods acting as pipeline executors. The more information you give to k8s, the better it will do its job of figuring out the best place to run a build. All that being said, at the end of the day, it's all about trying it out and seeing whether it is an improvement for your use case. Just do not jump to conclusions right away. It's hard to evaluate something you do not have much experience with against something you're using for a while since the latter is likely already better optimized given that you're more familiar with it.
@@DevOpsToolkit that's fair. Most CI systems do a decent job of running jobs in parallel across build agents but it wouldn't be as packed as with k8s (given accurate resource configuration). For my builds, I've found them to be much slower when building inside a container. The main limitation is disk. Disk within a container is much slower. With k8s I'd need to configure local volumes for native disk performance. More performance can be had by using compilation caches on local disk. I suppose this could be done in k8s with persistent local volumes. And where it's more performant to run a certain job on the same node, there's node affinity. It does seem like a lot of trouble to go to but I suppose it's just alternative configuration to that required by traditional CI systems. It does require a k8s cluster though, so perhaps a cost overhead for smaller companies.
Can Tekton Triggers cover events functionality the same as Argo Events? As I understand trigger can create any kind of k8s resource based on any CloudEvents.io supported. And one more thing it's artifacts I thinks it's really important for modern CI/CD solution too. Thanks for video. It was awesome.
Tekton can do events (through integrations) but they are nowhere near to what Argo Events does, how it works, and how it integrated with Argo Workflows.
Really nice comparison and it matches my (limited) experience. I do like very much the ability to run commands "on the fly" though for debugging, but I also very much enjoy a UI which shows me the status of a not-so-trivial pipeline in a live state. A lot of time is spent on debugging. Which one is better for that development use-case in your experience?
I'm not sure JX is a tool worth exploring. Contributions to the project decreased drastically since October 2021. It looks like a project that is mostly abandoned. You can see that through github.com/jenkins-x/jx/graphs/contributors. You'll see that the number of commits was reduced drastically and that all the major contributors stopped working on it around October last year.
@@DevOpsToolkit Thank you for the response.Currently I am using containerized version of team city for our build pipelines which runs windows and linux agents.I was looking at options that can automate these pipelines in cloud native way using tekton as building block and can produce repeatable pipelines.
Tekton is a good choice, but I would not use JX on top of it. I do not think it'll go anywhere, especially since all the major contributors moved to other projects.
Argo CD is great, but there is no "special" relation between it and Argo Workflows. CD expects changes to be pushed to a manifests repo and that is just as easy (or hard) with any pipeline tool. Argo Notifications are a stripped-down version of what Events do.
Interesting. I'm now on the pipeline portion of my project and went down the rabbit hole of Jenkins. I looked at Cloudbees and JenkinsX. Cloudbees is crap, because it is expensive/ not totally open source. JenkinsX was a huge disappointment, because it installs in a very strange manner via a huge repository you have to fork and then config, to have it then be ran via their CLI. Nasty stuff and I couldn't get it to work. And even worse, JenkinsX requires Hashicorp Vault. Oh my god. Why???? At any rate. I'm running with the Argo suite. I'll see how far I get. Btw, I ran into this video via the Argo Workflow docs. 😃 Your vids, as always are informative and good. Thanks!
I was involved with Jenkins X at the time. It was a good idea, but it did not work out so I and most of the others eventually abandoned it. I think that it's mostly unmaintained right now so I don't think anyone should be adopting it.
It's Pandora Box which is in the shape of the control board of the old arcade machines. It comes with hundreds of arcade games, has the same joysticks as old arcades, etc. It's awesome.
I already have a video about Knative (ua-cam.com/video/8vrLEbwSu7U/v-deo.html). I can create a new one if you think I missed something or if you feel a newer video is due (that one is 6 months old and one of the first ones I made).
Adding it to my TODO list... I will probably create a video about Flagger alone, so that it's a fair comparison given that I have a few videos about Argo CD. From there on, a comparison between the two should come next.
I just published a video about Flagger (ua-cam.com/video/NrytqS43dgw/v-deo.html). Since I already had a video about Argo Rollouts, the only thing missing is to compare the two.
It is true that Tekton is too much verbose too many yaml files, i am using it, but i am unable to find argo workflow examples which actually shows a production level cicd pipeline, what i find is duckt tapped examples, if anyone knows where to find good examples i am more then happy to switch lol
It's been 2 years since you published this video, and only 1 new entry has been added to the argo workflow catalog (slack-workflow-notifications). That's pretty bad.
Tekton and Argo Workflows started from different points but, over time, they were getting closer and closer to each other. The situation is similar to the one with Argo CD and Flux. There are differences, but, as time passes, there are fewer and fewer. That's a good thing.
Argo Workflows and Events make a really strong combo but there is a significant learning curve. I wouldn't say knowing where to start is intuitive (You're helping there ua-cam.com/video/XNXJtxkUKeY/v-deo.html) I've also run across projects building products on top of Argo Workflows. With the strong integration with Kubernetes objects, there is so much room to grow! Haven't taken the time to try Tekton yet. Really excited about all the activity in this space. Thanks for all you do for the community Viktor!
please create atlest detailed sequnetial veddios prometheus , how what how intasll how monitor the last project , no use sir youmade this only or professionals
The nature of this channel is a bit different from providing detailed in-depth tutorials. I might do that in the future but, for now, the goals are a bit different. You might want to check out www.devopstoolkitseries.com/posts/devops-25/ if you're looking for an in-depth exploration of monitoring with Prometheus
Which one CI/CD pipeline do you prefer within the self-managed category? Argo Workflows, Tekton, or something else?
Evaluating right now the best one for us :) still deciding, but probably Tekton will be the choice...
please please on youtube we want like nana devops , devops guy very very simple yet understanble just and projct way K8 realtime Q
Most important Kubernetes 7-8 topics as per recent competition and live interview , these questions asking regular
concept istio , what is service mesh very imp , ingress controller nginx why v imp? fluend for logs , prometheus grafan how intall monitor k8 , helm why? how?, gitops flow explanation using argo operator vimp .( helm and prome.. in all projects 100 prcnt questions )
concept of role based access security , service accounts very imp , meaning of manifest. meaning of policy in K8 , pod lifecycle what stages like pending?
=====================================================================================================================================================
Terraform realtime concept asking-
State file , global S3 state local state , taint untaint , import ,(how sync manual machine by mistake creation and the current state), using cache terraform fast process.
I'm not convinced about what seems to be a k8s centric (or "k8s native") CI/CD system. I quite like GitHub Actions (TypeScript beats YAML templating every time), GitLab [CI], and Buildkite. Do you have a video about the advantages of a k8s native solution?
@@steshaw6510 Being k8s-native does not necessarily mean that it is better or worse than NOT being that. Instead, it means that it was designed for Kubernetes (e.g., CRDs, communication through Kube API, operators, monitoring, scaling, etc.).
Unfortunately, I don't have a video taking specifically about the advantages (and disadvantages) of k8s-native solutions. Let me add that to my TODO list...
@@DevOpsToolkit great, thanks! One thing might be that you need at least 3 nodes. I find it strange that CI developers want to build on k8s with CRDs for everything. It seems kind of constraining, so there must be a big payoff that I am missing. Beyond k8s fever that is 😉
Haven't used Tekton yet, but I've already had a lot of experience working with Argo Workflows... and I really love it! There is so much you can do just with pure Argo Workflows: simulating try-catch statements, retries, excellent artifact repository support from S3 to HDFS, workflow metrics to Prometheus, workflow of workflows, automatic workflow's archiving,.... this is really amazing. The only weak point is the documentation - sometimes it's hard to find the answer. But the community provides numerous examples in the git repo and it really helps!
Thank you! We were not sure whether ArgoCD can take on CI, but your video explained it quite well that Argo is quite good.
I do not like calling it CI and CD since people tend to interpret it differently. Instead, I tend to say "pipeline" and "sync" tools. Pipelines execute a set of steps as a reaction on a commit to a git repo. That would be Argo workflows, tekton, Jenkins, GitHub actions, etc. Sync tools (or GitOps tools) are synchronizing the actual (cluster) into the desired (git) state and doing that continuously instead as a one-shot reaction to, let's say, git commits.
Seems you haven't explored Tekton Triggers. It's a great add-on to Tekton and you can create any event for triggering your Tekton pipelines. Maybe not used as a standalone tool, Tekton Triggers is very easy to set up and works miraculously with Tekton pipelines.
When I did that video tekton triggers was in its infancy. It is much better now and I should probsbñy create a follow up video.
At this point, do you recommend Argo Workflows or tekton?@@DevOpsToolkit
I started argo, very useful comparison. Events for me is the deciding factor.
Oh yeah. Argo Events are the main differentiating factor.
Awesome talk! Really liked the points you exposed and the neutrality.
Being neutral and truthful is the most important guideline in this channel. If you follow my work history you'll notice that I avoided talking about certain subjects when that would prevent me from being truthful.
Thank you! Before watching your videos, from personal research I had concluded that Tekton was better, because Argo was limited to just cd. Turns out, I was completely wrong, there is Argo cd, workflows, events, and rollouts, which makes it a far superior project! And as you said Tekton is too low level for most end users! Thank you for putting me back on the right track, you saved me so much time! 🙏
Yeah, I also thinked the same. I went there after I heard about Argo Workflows 3.3 release, where there was a multi-tenancy big change in the changelog. I'm trying Jenkins X for a few weeks, but if it will not suit needs then I will give Argo Workflows a chance.
RH OCP GitOps Operator has based on ArgoCD, RH has been putting serious eng hrs to take it further fyi.
Amazing video as always, thanks a lot!! But this time I have some doubts about your analysis...
First of all I think you missed an important point in the decision flow: cli tool (argo cli vs tkn cli). I know we should always go for GitOps but for debugging, and especially at the beginning, a good cli tool is really important.
Then in the "Web UI" section you forgot to mention that Tekton UI is completely insecure :( no auth, no rbac, nothing... just a simple UI!
Instead Argo Workflows offers different auth mode (server, client and sso) and better security (closer to ArgoCD UI which is PCI compliant!)
So imo Argo Workflows UI is way better than Tekton.
Moreover in the "Events and Triggers" section I think you were a bit too short and fast. Argo Events is a complete stand-alone project in respect to Argo Workflow, created as an event-based dependency manager, not only to trigger Argo Workflows. Instead Tekton Triggers (which you didn't mention) is made only for the purpose of triggering a pipeline. So in this area maybe Argo Workflows + Events could be better, but not SOOO BETTER than Tekton.
Finally projects built on top of Tekton... JenkinsX is not stable, not mature and not same as OpenShift Pipelines. OpenShift Pipelines hides Tekton and gives you a better UI in the same style and completely integrated with OpenShift. JenkinsX instead is completely opinionated, if you want to customize something you have to deal directly with Tekton, uses Prow instead of Tekton Triggers forcing you to deal with that as well, and the UI is only a plugin of Octant.
> for debugging, and especially at the beginning, a good cli tool is really important.
You're right. I should have included the CLI as one of the comparison points.
> Instead Argo Workflows offers different auth mode (server, client and sso) and better security (closer to ArgoCD UI which is PCI compliant!)
You're right about that one as well. I should have included auth.
> Moreover in the "Events and Triggers" section I think you were a bit too short and fast.
I did pass through it in the UI section. However, later on, I did talk about events and stated that as probably the main differentiators between the two. Argo Events are awesome and Tekton has a webhook trigger only that is silly.
> Finally projects built on top of Tekton... JenkinsX is not stable, not mature and not same as OpenShift Pipelines. OpenShift Pipelines hides Tekton and gives you a better UI in the same style and completely integrated with OpenShift. JenkinsX instead is completely opinionated, if you want to customize something you have to deal directly with Tekton, uses Prow instead of Tekton Triggers forcing you to deal with that as well, and the UI is only a plugin of Octant.
I did not want to go deeper into projects on top of Tekton since I felt that would derail the video. But, instead of skipping them, I thought it is fair to mention their existence. I'm planning separate once about Jenkins X and OC Pipelines.
All that being said, it's difficult to condense everything in ~20 min., and I often make mistakes and miss the things that might be important. Improving as we go...
@@DevOpsToolkit
> All that being said, it's difficult to condense everything in ~20 min., and I often make mistakes and miss the things that might be important. Improving as we go...
Of course! I posted my impressions, doubts and suggestions for sake of completeness and discussion :)
> I did pass through it in the UI section. However, later on, I did talk about events and stated that as probably the main differentiators between the two. Argo Events are awesome and Tekton has a webhook trigger only that is silly.
Probably a bit too fast, maybe an additional 30sec/1min, anyway... imo it's not silly that Tekton includes/offers only triggers... it's a CI/CD specialized tool, not a broader one like the Argo ecosystem...
This is a great comparison. I like other parts of the Argo ecosystem, so it's good to see it hold up here.
I get concerned about doing builds in k8s clusters because of performance issues. Builds need to be fast. Building large projects-particularly native/AOT ones-can be quite time consuming (e.g. C, C++, Haskell, and Rust). Both CPU cores and fast disks are required to reach acceptable build times for some projects. I tend to favour build agents on powerful bare metal machines with very fast SSDs or RAM disks. What do you think about this scenario, would you prefer a custom k8s cluster with powerful bare metal nodes as above? I'm thinking that best of both worlds is to have Argo take over deployment once a container hits a registry, etc.
Being a k8s cluster might cause some performance issues around networking but that applies mostly to cases when extremely fast response times are concerned. For pipeline type of tools, k8s tend to have an opposite effect. It improves performance due to k8s capability to schedule Pods to nodes that have available resources and to reduce or even eliminate the time something is waiting in a queue and distribute parallel executions to multiple pods/nodes. Now, all that assumes that the k8s cluster is running on the same hardware as pipelines that are not running in k8s. Even if performance is not increased, the amount of resources used will be decreased. So you either get a performance boost or you end up being the same but with fewer resources used.
All that assumes that quite a few things are done right. For example, you need to define resource requests and limits, and, maybe, affinities, so that k8s knows where to schedule pods acting as pipeline executors. The more information you give to k8s, the better it will do its job of figuring out the best place to run a build.
All that being said, at the end of the day, it's all about trying it out and seeing whether it is an improvement for your use case. Just do not jump to conclusions right away. It's hard to evaluate something you do not have much experience with against something you're using for a while since the latter is likely already better optimized given that you're more familiar with it.
@@DevOpsToolkit that's fair. Most CI systems do a decent job of running jobs in parallel across build agents but it wouldn't be as packed as with k8s (given accurate resource configuration). For my builds, I've found them to be much slower when building inside a container. The main limitation is disk. Disk within a container is much slower. With k8s I'd need to configure local volumes for native disk performance. More performance can be had by using compilation caches on local disk. I suppose this could be done in k8s with persistent local volumes. And where it's more performant to run a certain job on the same node, there's node affinity. It does seem like a lot of trouble to go to but I suppose it's just alternative configuration to that required by traditional CI systems. It does require a k8s cluster though, so perhaps a cost overhead for smaller companies.
Thank you for this great video. Do you have ArgoCD and GoCD comparison?
Unfortunately no.
Great man! Thank you very much
Nice explanation Viktor 👍
Can Tekton Triggers cover events functionality the same as Argo Events? As I understand trigger can create any kind of k8s resource based on any CloudEvents.io supported.
And one more thing it's artifacts I thinks it's really important for modern CI/CD solution too.
Thanks for video. It was awesome.
Tekton can do events (through integrations) but they are nowhere near to what Argo Events does, how it works, and how it integrated with Argo Workflows.
Really nice comparison and it matches my (limited) experience. I do like very much the ability to run commands "on the fly" though for debugging, but I also very much enjoy a UI which shows me the status of a not-so-trivial pipeline in a live state. A lot of time is spent on debugging.
Which one is better for that development use-case in your experience?
If the choice is between those two, I prefer Argo Workflows.
I love your video, keep working
Can you please create a video on Jenkins-X and how it uses tekton underneath ?
I'm not sure JX is a tool worth exploring. Contributions to the project decreased drastically since October 2021. It looks like a project that is mostly abandoned. You can see that through github.com/jenkins-x/jx/graphs/contributors. You'll see that the number of commits was reduced drastically and that all the major contributors stopped working on it around October last year.
@@DevOpsToolkit Thank you for the response.Currently I am using containerized version of team city for our build pipelines which runs windows and linux agents.I was looking at options that can automate these pipelines in cloud native way using tekton as building block and can produce repeatable pipelines.
Tekton is a good choice, but I would not use JX on top of it. I do not think it'll go anywhere, especially since all the major contributors moved to other projects.
Can’t wait to listen to this one
Excellent ! 👏 👏 👏 👏 👏 👏 👏
I was expecting the other Argo Projects such as ArgoCD and Argo Notifications to tally points for Workflows, but only Argo Events did.
Argo CD is great, but there is no "special" relation between it and Argo Workflows. CD expects changes to be pushed to a manifests repo and that is just as easy (or hard) with any pipeline tool. Argo Notifications are a stripped-down version of what Events do.
Interesting. I'm now on the pipeline portion of my project and went down the rabbit hole of Jenkins. I looked at Cloudbees and JenkinsX. Cloudbees is crap, because it is expensive/ not totally open source. JenkinsX was a huge disappointment, because it installs in a very strange manner via a huge repository you have to fork and then config, to have it then be ran via their CLI. Nasty stuff and I couldn't get it to work. And even worse, JenkinsX requires Hashicorp Vault. Oh my god. Why???? At any rate. I'm running with the Argo suite. I'll see how far I get. Btw, I ran into this video via the Argo Workflow docs. 😃 Your vids, as always are informative and good. Thanks!
I was involved with Jenkins X at the time. It was a good idea, but it did not work out so I and most of the others eventually abandoned it. I think that it's mostly unmaintained right now so I don't think anyone should be adopting it.
@@DevOpsToolkit - I did have the feeling it was sort of "left alone". Glad my findings were correct.
What the joysticks are in the background ?)
It's Pandora Box which is in the shape of the control board of the old arcade machines. It comes with hundreds of arcade games, has the same joysticks as old arcades, etc. It's awesome.
Thanks for the content, could you pls do another episode introducing Knative? Tekton used to be bundled ith Knative as the build part
Adding it to my TODO list... :)
I already have a video about Knative (ua-cam.com/video/8vrLEbwSu7U/v-deo.html). I can create a new one if you think I missed something or if you feel a newer video is due (that one is 6 months old and one of the first ones I made).
hello viktor
could create a video comparing argocd rollouts vs flagger and your opinions
thanks
Adding it to my TODO list...
I will probably create a video about Flagger alone, so that it's a fair comparison given that I have a few videos about Argo CD. From there on, a comparison between the two should come next.
I just published a video about Flagger (ua-cam.com/video/NrytqS43dgw/v-deo.html). Since I already had a video about Argo Rollouts, the only thing missing is to compare the two.
It is true that Tekton is too much verbose too many yaml files, i am using it, but i am unable to find argo workflow examples which actually shows a production level cicd pipeline, what i find is duckt tapped examples, if anyone knows where to find good examples i am more then happy to switch lol
Docs were one of the points I gave to Tekton. It has much more information and examples than Argo Workflows.
It's been 2 years since you published this video, and only 1 new entry has been added to the argo workflow catalog (slack-workflow-notifications). That's pretty bad.
yeah. I don't think it's going places.
Tekton using Knative in conjunction with git hooks can give Argo bit of competition and we will get serverless pipeline
Tekton and Argo Workflows started from different points but, over time, they were getting closer and closer to each other. The situation is similar to the one with Argo CD and Flux. There are differences, but, as time passes, there are fewer and fewer. That's a good thing.
Tekton dashboard is a Sxhxixt
It was horrible the last time I checked it. It's been a while so I'm not sure what it's current state is.
To be honest I expected from video the features comparison, not only those like files look like
i dont really like that argo cd and workflows/events is separated like that, a bit annoying when you need to have couple UI's and etc.
That's one of the reason CodeFresh might be interesting. Among other things, they are trying to provide a seamless experience across Argo projects.
Last time we checked ArgoCD had RBAC and ACL, Tekton had no such thing.
You're right, with a small correction. Argo Workflows is comparable to Tekton, not Argo CD.
Nice vedio
Argo Workflows and Events make a really strong combo but there is a significant learning curve. I wouldn't say knowing where to start is intuitive (You're helping there ua-cam.com/video/XNXJtxkUKeY/v-deo.html) I've also run across projects building products on top of Argo Workflows. With the strong integration with Kubernetes objects, there is so much room to grow! Haven't taken the time to try Tekton yet. Really excited about all the activity in this space. Thanks for all you do for the community Viktor!
Oh yeah. They are very powerful, but not user-friendly. That's why I do not easily recommend them.
please create atlest detailed sequnetial veddios prometheus , how what how intasll how monitor the last project , no use sir youmade this only or professionals
The nature of this channel is a bit different from providing detailed in-depth tutorials. I might do that in the future but, for now, the goals are a bit different. You might want to check out www.devopstoolkitseries.com/posts/devops-25/ if you're looking for an in-depth exploration of monitoring with Prometheus