Optimize Node.js Development Workflows in Kubernetes with Skaffold and Rancher Desktop

Hi there, I'm Lucan de Muela, or you can call me Luke. I'm going to be talking to you about optimizing your Node.js development workflows in Kubernetes with Scaffold and Rancher Desktop. I'm a Principal Technical Evangelist at SUSE, so you can feel free to get in touch with me on various social media platforms, whether it's Twitter or LinkedIn, following me on GitHub, or subscribing to my YouTube channel.

Now, this is a lightning talk, but I've still got some golden nuggets that you can walk away with in a short amount of time. For starters, we're going to consider the developer experience when building your Node.js apps for Kubernetes. Then, we'll look at how Rancher Desktop simplifies the cluster management life cycle, followed by optimizing build and release workflows with Scaffold, and then we'll cap it off with a demo. Which is usually everyone's favorite part.

Now, if you're a developer and you've got experience working on cloud-native apps, you might actually have been reluctant to tune into this session, because you want to focus on your application development. Kubernetes is predominantly seen as a separate world that shouldn't get in the way of what you should be prioritizing. Personally, I agree with that. However, there's a slight conundrum because Kubernetes does solve real problems. And your team might be dealing with those problems, and so Kubernetes might be a solution that's in the bigger picture of your architecture. So you have to be a part of the journey either way.

And this is where things get even trickier because there's different ideas around who should own what. Now, my goal is to demonstrate how Rancher Desktop and Scaffold can complement the core developer priorities and still incorporate DevOps practices like release workflows for application deployments to your Kubernetes cluster. An example of this would be going beyond NodeMod. Now, I love using NodeMod when building out my Node.js apps because it quickly rebuilds the changes and I get to see those reflected. But what if you could accomplish that with a full CICD pipeline on your local machine with all the intricacies abstracted away, but still remaining configurable for a local context as well as for remote deployments? We'll take a look at that shortly.

Now, the first tool in this solution is Rancher Desktop. RD is a desktop application available on Windows, Linux, and Mac. It's an electron-based application that wraps a host of components under the hood with a virtual machine running K3S and either ContainerD or DockerD, depending on your configuration choice. In the end, you have an intuitive UI that simplifies the cluster management process, and you can easily upgrade or reset your cluster with just a few clicks.

The second tool in this solution, or one-two punch in mind, is Skaffold. And Skaffold's goal is to simplify the Kubernetes development workflow by automating and abstracting away the process of building and deploying container images. The inter-development loop of iteratively coding, building, and testing your apps is something that can be enhanced by Skaffold, because it will take your local changes and trigger a pipeline for deployment whenever it detects them. And this is especially helpful for debugging your apps before they end up in the final target cluster. So using RD and Skaffold enables developers to stay focused on application optimization because they give you the combination of a cluster that's easy to interact with and manage, and a configurable workflow process that is automated and abstracts the DevOps details. So let's take a look at this in action real quick. As you can see, I've got Rancher Desktop open and running, and I'm currently in the Kubernetes settings section. And over here, a lot of the main things that happen around your Kubernetes cluster management and optimization would actually be consolidated in this particular section.

So as you can see, I can easily update my Kubernetes version just by using this dropdown over here. And this will obviously depend on the particular version that you or your team have agreed upon. In addition to that, if you wanted to choose a particular container runtime between ContainerD and DockerD, that's something that you can toggle with over here. And then you have different situations when it comes to your applications. You might find that some are memory intensive, some are compute intensive, but you want to have the opportunity to modify the virtual machine that you're working with. And so you can do that over here by updating the particular memory in the CPU, and that will just reset your cluster. And also, if you did need to do a hard reset to delete all the workloads and the configuration that you had set up, for whatever reason, you could simply hit the reset button over here. And that's cool, especially when it comes to local cluster development because you have the safety of the blast radius not impacting other people or other teams. But nonetheless, you want to be able to have a nice way of just ejecting and starting all over again.