Develop cloud-native software faster 🚀 - DevOps Tool of the Month (1)

DevOps tool of the month - This is a new series, where each month I will introduce one new useful DevOps tool. 🛠 🙌🏼

The first one is: DevSpace 🎉 - a developer tool for Kubernetes, which enables software engineers to develop cloud-native software faster.

---

What problem DevSpace solves? 👀

Developing a microservice application
Imagine you are in a developer team, working on a particular service that is part of a complex microservices application. And the target environment of this application is Kubernetes. ⎈

So you create a bugfix branch for 1 of the microservices and start making changes. While you are making changes, you want to test it in real time, in combination with the other services, as these are all interdependent.

Test on the real K8s environment ⎈
But instead of testing it locally using docker-compose or Minikube, you want to test your changes on a real K8s environment with all these services running.
Reasons for that:

• to not have any surprises, because these are 2 different environments
• with larger applications, it is often impossible to run them on local computers, as they require a lot of computing resources

The common but inefficient way of doing it 😣
So the common inefficient workflow in such use case would be:

• you test it locally with docker-compose or Minikube to make sure your changes work
• when done with all changes, you create a pull-request
• your branch is merged into master
• a CI/CD pipeline is triggered that tests the changes, builds the new image and deploys into k8s cluster on dev environment - now you can test it on the real DEV environment to make sure it works there, the same way it worked locally
• if something doesn't work, you need to go through the same cycle for each adjustment

This is a long process to be able to test your changes on the actual k8s dev environment. 🙉

Efficient way we want to do it 🚀
So, what if instead, every change you make locally would be immediately deployed into the K8s cluster so you can test your changes,

• without going through this long process mentioned above, where you need to wait until the CI/CD pipeline ran etc. and
• without having to know Kubernetes and the kubectl or needing help from the DevOps team.

The tool that lets you do exactly that is DevSpace.

---

How DevSpace works? 🤔

Using a simple devspace.yaml configuration file in your application code, DevSpace will automatically build your app into a Docker Image 🐳 using your Dockerfile, and deploy it as a Helm chart into the K8s cluster.

And on top of that, every time you make changes, DevSpace will hot reload 🔄 them by automatically recreating and restarting the container within the pod. And this can make your development process way faster and more efficient.

This will be a development mode, in which you can test every code change immediately in your K8s cluster.

Other use cases
DevSpace has other use cases as well:
For example, if you just want to deploy the application without the sync and push the image to your private docker repository.
Or what I especially like is that it gives you shortcut commands to get the container terminal or logs without checking the pod id, namespace, etc:

---

Get started with DevSpace 👩🏻‍💻

Set up the DEV mode with hot reloading in 4 simple steps 😎

Git repo for demo to follow along: Gitlab Link

1. Install devspace
2. Create a Dockerfile
3. Initiate our project with devspace
4. Start the DEV mode

1. Install devspace - open-source CLI tool

2. Dockerfile 🐳

The second step is to create a Dockerfile for your project that devspace will use.

Here an example for a Java application:

How DevSpace works is, it syncs your local code and code inside the container image and checks for any code changes, so it can perform the hot reload.
So DevSpace will build the image with all our code inside and sync it. And this will happen out-of-the-box without any configuration from our side. 👍

TIP: Use .dockerignore to ignore files, which should not be copied inside the container, e.g. code editor files like .idea for IntelliJ IDE.

3. Initialize your project with devspace

Now we can initialize the project with devspace init.

During the initialization process you need to tell DevSpace how to deploy your application. Options you can choose from:

• local Helm chart
• remote Helm chart
• K8s configuration files (e.g. Deployment.yaml)
• component-chart (where DevSpace creates Helm chart for you, so you don't need to create any k8s configuration files for your project)

During this initialization, DevSpace automatically generates the devspace.yaml configuration file for you based on your Dockerfile. It gives you a good starting point, however, you usually will have to make some adjustments to fully reflect your desired workflow. This first configuration could also be done by someone in your team who has some Kubernetes expertise.

4. Start DEV Mode 🚀

Pre-Requisite before starting the development mode:

1. the running Kubernetes cluster,
2. your built application artifact, e.g. Jar file.,
3. configure a namespace to inform devspace, which namespace to deploy your app to devspace use <namespace name>
4. you need a valid kube-context, because DevSpace uses the kube-config file just like kubectl or helm, which is a good thing so you don't have to configure anything separately.

Finally we can execute devspace dev to start the development mode!
When executing devspace dev, DevSpace does some things in the background to enable:

• DevSpace starts the file syncing, which gives you the hot reloading
• Port forwarding is configured automatically, which allows you to access the application with localhost
• Automatically starts streaming the logs, that the container running inside K8s pod is logging. So if there is an error, we would see that immediately in that stream, without having to use kubectl and do that manually.
• Finally, DevSpace ships with a built-in UI for Real-Time Log Streaming, Status Monitoring & Alerts, Interactive Terminal Sessions & more

---

Wrap Up and Preview

So with DevSpace you will have a more efficient development process when developing cloud-native software in a Kubernetes environment.

Now you may be wondering, what about the K8s cluster state? What happens if every developer would push their changes into the cluster all the time, developers would mess up the cluster, right? 🤔 Well, one solution would be using namespaces.

However, there are other good solutions for that specific problem, and this will be the topic of our next post in the DevOps tool of the month series.

---

Like, share and follow me 😍 for more content:

• Private FB group
• Twitter
• YouTube
• Instagram
• LinkedIn

Comments

[Jaime Anguiano]

nice post!