How to Deploy .NET Apps to Kubernetes
2024 ж. 6 Нау.
32 526 Рет қаралды
Use code KUBE20 and get 20% off the brand new "From Zero to Hero: Kubernetes for Developers" course on Dometrain: dometrain.com/course/from-zer...
Become a Patreon and get special perks: / nickchapsas
Hello, everybody, I'm Nick, and in this video, I will show you how you can deploy your .NET applications and system to Kubernetes (k8s), and we will do that using .NET Aspire.
Give Aspirate a star on GitHub: github.com/prom3theu5/aspirat...
Workshops: bit.ly/nickworkshops
Don't forget to comment, like and subscribe :)
Social Media:
Follow me on GitHub: github.com/Elfocrash
Follow me on Twitter: / nickchapsas
Connect on LinkedIn: / nick-chapsas
Keep coding merch: keepcoding.shop
#csharp #dotnet
Thanks Nick, Sorry about the name :P
All the tutorials are starting new projects. What I need to see is how I can convert my many services (in many repos) into an aspire project without a ton of refactoring
My thoughts exactly. I'm just talking with a colleague on Teams about this very thing.
Same.
I would tell you to wait, because this isn't production ready yet
Most asp net core apps by virtue of the default templates are mostly monolithic and I don't personally really think one can gain much advantage with kubernetes for monolithic apps except increase complexity to a certain extent. But if you have a Microservices based architecture then that is most definitely going to take advantage of orchestration systems or distributed solutions such as kubernetes and the entire ecosystem behind it. For anyone deploying to kubernetes I always remind them that managing kubernetes and understanding the ecosystem is also a significant thing. If you think you need kubernetes you must have a very good reason to do so otherwise I discourage anyone moving to kubernetes without a kubernetes guy who knows it inside out when deploying mission critical applications. Remember when you move to solutions such as kubernetes it is not only kubernetes that you need to understand but everything around it's ecosystem because it's rarely being the only one involved. I highly encourage any dev to learn and understand kubernetes and similar solutions and most importantly to be guided by that wisdom to know when a project is at the level it needs kubernetes or not need it yet. Also make sure to be wary with aspire as it is in its infancy. Good to study and learn it but not yet ripe for production mission critical applications. I have deployed a many production distributed applications on managed (Azure, gcp, AWS, do, Linode) and on premise kubernetes (k3s) and I've seen headaches around adapting configurations when upgrading kubernetes as well so adjusting to real world networking constraints I'm just glad I'm still sane today. 😂 But if you are really interested in Kubernetes do not forget to master terraform (or the True open-source variants) as well as both go hand in hand nowadays. Good luck with your migrations 😂
Not difficult at all and no refactoring of your code. But you do need to be running VS 2022 Preview and convert your project to .NET 8. Then you'll tell VS to "Add .NET Aspire Orchestration Support" and you're off to the races. It's NOT production so create a feature branch in Git to test it out. I've done it to some existing projects with good success.
I have been looking forward to it, Thanks Nick
Wow, I was just looking for it. Thanks Nick!
I was exiting of Aspire since Microsoft pre-released 1 view. And I was waiting for your video about deploying my awesome micro-services app XD thx for you guide lines, Nick!
Hey Nick! Great stuff! It would be great to see how Aspire can be meaningful used in combination with Dapr. Which responsibilities overtakes the one or another framework and how it could streamline the whole development from dev over test to prod. Many thanks
TBH the name Aspirate is kinda cool 😅 like as-pirate
You mean ass-pirate?
I don't really get the value proposition of Aspire. We can already deploy to Kubernetes quite easily with helm and dockerfiles. My first impression of Aspire is that it is just another layer on top of this, but not a very thick layer so there doesn't seem to be a lot of simplification at all and no point locking myself into Aspire when I can just keep using helm etc. What am I missing?
It's sort like asking why does helm add value when I can use kustomize and bash scripts. Aspire is more productive because it adds a layer of abstraction that can be tooled so you don't need to worry about every little detail. This is what *any* good tool does. Tries to hide the details until you need to know them. The best tools allow you to drop down to the lower layers beneath the abstraction for full control as well.
Great video! Is it possible to run the .NET debug mode (integrated in Rider) inside a Kubernetes deployment ?
what is the difference between aspire and dapr?
Is this a limitation for .Net Aspire that your services needs to be under the same solution/same repo? What about connecting your API to a SPA build in React/Vue?
They don’t need to be under the same repo, no. They don’t even have to be .NET
@@nickchapsas A tutorial covering how to connect multiple microservices across repos & programming languages will be insane to watch 👀
Nick is lazy and feeding us again and again with Weather Forecast, lol 😂
Dude you read my mind, how do you do it? :D
Hi Nick! Whats the name of the app to visualize the k8's containers and services? Thanks!
It's called Lens
@@nickchapsas Thank you very much!!!!
What's the ui app you are using to manage kubernetes .?
Looks like Lens.
aspirate AKA aspir8 for k8
The problem with .net aspire is that you have all the projects (backend and front end) in the same solution. This is quite problematic for large projects and companies where workloads are splitter through different teams. First remark
Hey, Nick, would you show us some tests of latest Claude AI model regarding its C# coding capabilities?
Cake is good
I just want an API, this is too complex for someone who just wants to put food on the plate. Requires a lot of understanding of concepts that one might not be using on a day-to-day basis. It will require a Team and specialization in the field. I will stick with Containers and container apps Its a Bliss
I agree - it is stupidly complicated for what it gives you. The deployment tools are getting more complex than the code in the deployed application!