Devtron - Kubernetes-Native User-Friendly CI, CD, and GitOps

[@DevOpsToolkit]

What do you think about Devtron? Please let me know if you're already using it or planning to give it a try. A few notes/corrections: - I made a mistake when saying that it uses Lens. The `lens` Pod running as part of the Devtron package is not the same as Lens dashbaord. - Devtron is not really "hiding" the tools it integrates with. At least not literally. Instead, it does not mention them (much) in the docs or the UI so it's not that obvious what it integrates with. IMPORTANT: For reasons I do not comprehend (and Google support could not figure out), KZbin tends to delete comments that contain links. Please exclude from the links to ensure that your comments are not removed.

[@EliMaor]

look cool tools for CI/CD

[@hirenkamat7900]

Thanks

[@hirenkamat7900]

I am really enjoying your videos and i get to learn a lot - though i am just starting in K8s world. Thanks for all.

[@DevOpsToolkit]

Thanks a ton, Hiren.

[@unixbashscript9586]

Thank you for introducing this tool to us!

[@felipeozoski]

Gotta love this channel man!!!

[@valour.se47]

There is potential in this tool and i think i am going to use it for my homelab in the future , but you made very valid points regarding how it is dealing with argo stack, i mean give us a button in the ui so we can directly hop through the awesome dashboards comes with those tools.

[@DavidVotino]

Excellent review, kudos to you

[@DiogoBaeder]

Super nice video, man, thanks a bunch! I like how you constructively criticize the project, I think they can go even further with it. BTW, I just checked and it doesn't seem like their Canary strategy supports checking the app health in order to do automatic rollbacks, which is a bummer. But, overall, the project is really amazing!

[@haimari871]

"It uses modified version of argo rollout" - this is mentioned at the project. I prefer to use upstream projects to prevent vendor locking (for example, my argo rollouts would work the same if I use CodeFresh or not) As mentioned, this project has great potential but at the time of writing this, it's not robust enough for enterprise with multiple teams & Clusters to my opinion.

[@jonassteinberg3779]

haha "I can only deploy to environments in parallel" dayum! that is C0NF1D3NC3!

[@josephcasey7479]

This was such a great walk through of Devtron. I really appreciated your breakdown of the various difficulties you had debugging and using Devtron when there are issues. In your opinion, do you think Devtron is ready to be used in an enterprise or large company setting? Did you feel Devtron would scale from a workflow and corporate governance standpoint when used by more than a single-user?

[@DevOpsToolkit]

I am not yet sure about that. For now, I think it is worth trying it out and keeping and eye on it. It takes time until a product reaches the maturity stage required by large orgs...

[@javisartdesign]

Thanks for share it. It is difficult to integrate this all-in-one tools into an organization. Also dependencies could be a problem when you need to update it without update devtron entirely. It is a mix between kubernetes native and Openshift, since it is not a distribution at all and mainly focused on GitOps.

[@DevOpsToolkit]

That's very similar to my thoughts. For now, I see Devtron as a tool with a lot of potentials, but also a lot of pending work to make it work well, especially in organizations that are not starting from scratch (99.9% of them)

[@user-qr4jf4tv2x]

besides devtron being all in one.. any others?

[@DevOpsToolkit]

otomi.io is out there as well.

[@MrNiceseb]

How does Devtron deal with full-stack apps where we have separate backend/frontend Dockerfiles ? Also tried to docker-compose konvert to helm via kompose and then uploaded the helm chart into Devtron, but upon usage all given was that YAML cannot parse?

[@DevOpsToolkit]

I don't use Kompose so I can't answer the second question (YAML parse issue) without taking a look at the chart. As for the first question (multiple Dockerfiles), you can specify the path to Dockerfile.

[@MrNiceseb]

@@DevOpsToolkit but I thought Dockerfile path is set in configuration to look for a specific one only in Global Configuration? Wasn’t clear how it can set to look for another Dockerfile

[@DevOpsToolkit]

I thought it can be done per project. I might be wrong though. I haven't used it much after I made that video. It was too limiting for what I'm doing.

[@MrNiceseb]

@@DevOpsToolkit limiting in what way? Because I am also thinking that way too as it does not use docker-compose since I have cookiecutter-Django project that has local and production docker-compose yml and I cannot use it but use only its Dockerfiles

[@DevOpsToolkit]

@@MrNiceseb It's an opinionated platform and as such, it works only for those that can adopt the "opinion". It's limiting in a similar way as Heroku was limiting. That does not mean that it's bad, but that the "opinion" needs to fit what you're doing. Docker Compose, on the other hand, is a deadend. Even Docker (the company) realized that it failed to provide value in production and that it should focus on dev (mostly local) envs. It is transforming itself into dev experience type of company. Docker Compose serves no purpose and, to make it even more complicated, is preventing people from doing what should be done. I strongly suggest getting off of it.

[@avianshgupta5165]

Can you create another video on Devtron as I Devtron has added some of the features that were not there like chain deployments etc. and I didn't quite understand the Manifest/repo organisation thing how devtron handles that what is better

[@DevOpsToolkit]

Adding it to my TODO list...

[@swagatochatterjee7104]

Can I use Crossplane+KubeVela with Devtron? I mean is there a way to use your shift-left model on devtron?

[@DevOpsToolkit]

Yes, you can. Both Crossplane and KubeVela are based on Kubernetes manifests. Since Devtron works only with Helm (or at least I think it does), you'd need to package them as charts and tweak Devtron processes and templates a bit. That being said, I'm not sure whether I would recommend Devtron for those cases. It is more geared towards those that want to embrace it fully. It tends to be a bit difficult to reason with if you want to combine it with your processes, mostly because it is not well documented how it does what it does and how to extend its default behavior.

[@swagatochatterjee7104]

​@@DevOpsToolkit as far as I remember your shift-left model was independent of helm. Then what possible bottlenecks can I face here? That being said, is it worth tinkering or devling deep on this to make your custom solution, or is it better to make your own custom solution using the tech they use. Eg. I don't like how they do CD (I can rather do this with argo and do hotfix deployments), but their integration with dex for SSO and log search tool is awesome.

[@DevOpsToolkit]

@@swagatochatterjee7104 My shift-left model was designed with three actors in mind. 1. Software vendors (e.g., Crossplane, KubeVela) who create unopinionated tools designed to enable us to create opinionated services. 2. Ops, sysadmins, SREs, etc. who take those tools and create final services that can be consumed by everyone else 3. Everyone else Devtron (and most of the other tools) is taking a different approach. It is an opinionated tool that typically (even though not fully) targets everyone else. Now, one approach does not have to be better then the other. It mostly depends on the capacity and the experience. The first model (e.g., Crossplane composites, OAM/KubeVela, etc.), in my opinion, makes more sense for companies that have the know-how and can invest time. The second model (e.g., Devtron) is easier and faster. The whole premise of opinionated tooling is: "If this is what you need, it would be pointless to build it yourself. But, if you're not fully on-board, you might realize that the 20% that is missing or different is harder to do because opinionated tools are less flexible". WDYT? Does that make sense?

[@swagatochatterjee7104]

@@DevOpsToolkit yes it makes sense. What I guess I was looking for was, these are the tools we have no experience about let's use opinionated tools , and these are tools we have a great expertise so let's mould it to our needs. I guess this is a narrow case, and the fact that it's opinionated makes it hard to extend.

[@DevOpsToolkit]

@@swagatochatterjee7104 You're right saying that the less experience you have with some type of tooling, the more sense it makes to go for the opinionated route.

[@codecoffee8363]

wow, this is awsome tools, do you have any experience like devtron but using hasicorp nomad orchestration?

[@DevOpsToolkit]

Unfortunately, I don't. I'm not using Nomad (much).

[@andreykaparulin9214]

Thank you!!

[@collimarco]

Do you think it's normal / a good practice to have production and non-production environments in the same cluster (using different namespaces)?

[@DevOpsToolkit]

I can't give an answer to that question that would apply to everyone. To begin with, it depends on the scale. Those running hundreds of clusters would not have benefits of sharing prod and non-prod envs. Smaller operations would, especially if the cost is an issue. There are benefits to sharing envs like the cost, agily, lower maintenance, etc. but there are also risks like potentially "leaking" things from one Namespace to another, making mistakes in non-prod that affect prod, etc.

[@tydalm.9665]

​@@DevOpsToolkit In my former company, which was a relatievely small operation in terms of esives/websites, we also used two cluster for prod/non-prod. Actually we used three clusters, as there as a build cluster as well, which hosted ArgoCD, Code CI pipleines, container registry, other registries,etc. The costs were not much higher than with a single cluster setup. Our provider did not charge for master nodes an a lot of services/apps can be shared between clusters no matter what. In terms of agily and maintenance we just pointed ArgoCdD at the same manifests, which were wrapped with small helm charts to cover the differences between environments,so we could even test the cluster itself before gong live with infrastructure changes. Also this approach allowed us to tear down the non-prod cluster (We called it "testing") and the build cluster completely and rebuild it form scratch, as everything was managed by ArgoCD. Since ArgoCD running on the build cluster was a chicken and egg problem, there was a tiny script, which jump started ArgoCD on the build cluster, and the rest would work automatically.

[@narendrabhupathiraju8986]

is it possible to do ecr image scan via jenkins pipeline?

[@DevOpsToolkit]

I'm assuming you do mean Jenkins and not Devtron... You can execute any CLI command from a Jenkins pipeline. Or, you can configure ECR to scan images without imperatively doing that from any pipeline.

[@narendrabhupathiraju8986]

@@DevOpsToolkit will you please write that stage for me , it will be very helpful to me. thanks in advance

[@DevOpsToolkit]

Are you sure you do not want scanning to be done automatically whenever you push an image. Does it have to be from a pipeline?

[@DevOpsToolkit]

If you do want it from a pipeline, you can run the commands explained in the "to start a manual scan of an image" from docs.aws.amazon.com/AmazonECR/latest/userguide/image-scanning.html#manual-scan

[@narendrabhupathiraju8986]

@@DevOpsToolkit yes from pipeline i.e: checkout---build---push to ecr---ecr scan----helm----eksclusters, this is the flow i want to develop in my project so

[@amit.gadhia]

It was a really good session Thanks, So what I conclude is Devtron is not mature enough to implement in production workflow that is already using ArgoCD and ArgoRollout.

[@DevOpsToolkit]

I would rather say that it depends on the structure you have set up with Argo CD. If it matches the one in devtron, it might make sense to switch. Otherwise, you might want to wait a bit longer. I know that the team is working on adding more flexibility to it.

[@Prakarsh]

Devtron lets you override the Deployment-template, configmaps and secrets at environment level, I think you missed configuring overrides and therefore same host for stage and production!

[@DevOpsToolkit]

I saw that but I believe that it is not intuitive. I would expect that to be available when defining deployments to environments (in pipelines). Nevertheless, that would still not fix my issue. I don't want to deploy to all the environments at once and, as far as I saw, there is no obvious way to chain deployments.

[@50flick]

Bitbucket is dead 😩 I feel like we are the only org that still use it.. zero features and zero support

[@DevOpsToolkit]

Yeah. It's on life support and you're one of the few keeping it alive.

[@jonassteinberg3779]

"I'm scolding you" bwahaha y'all better listen to Father Viktor!

[@jonassteinberg3779]

I like how 4 people disliked this lol. They just weren't feeling it haha.

[@DevOpsToolkit]

Sometimes people do not like when I say something negative about a project or a product. Given that I tend to find both good and bad things in almost everything, I'm surprised I'm not getting more dislikes.

[@jonassteinberg3779]

@@DevOpsToolkit Makes sense. Keep up the content! You're making *killer* stuff!

[@smerlos]

git add -A && git commit -m " first comment" && git push