DevSpace v4.2 Released with Localhost UI for Kubernetes Development
Boosting developer experience with a client-only dashboard for cloud-native development.
We are happy to announce that v4.2 of DevSpace ships with a lightweight client-only UI that will drastically improve the developer experience for building cloud-native applications with Kubernetes.
DevSpace is an open-source development tool for Kubernetes which is available on GitHub.
To start and open the new DevSpace UI in the browser, run:
devspace ui
You do not need to have a devspace.yaml configuration file to run this command. DevSpace works with your current kube-context similar to kubectl or helm. If you have a devspace.yaml in your project and you run devspace dev, the UI is also started but not opened.
The localhost UI of DevSpace provides the following features:
- Log Streaming & Terminal Sessions:
- namespace inspection
- stream the logs of pods/containers (terminal colors are preserved)
- open interactive terminal sessions
- start port-forwarding for containers with one click
- Stack: inspect the config of the currently deployed stack*
- Commands: run any commands defined in devspace.yaml*
* These features require the UI to be started either via devspace dev or via devspace ui within a project that contains a devspace.yaml config file.
Motivation
It is exciting to see the increasing adoption of DevSpace as an open-source tool for iteratively deploying and developing cloud-native applications with Kubernetes. The previous release of DevSpace had over 1,000 downloads and some of our power users as well as new members of the community reached out to us and asked if it was possible to integrate a client-side UI such as VMware's Octant to give developers an easier way for observing what is going on inside their namespaces.
We checked out several client-side UIs for Kubernetes but saw the issue that all of them are optimized for cluster administrators rather than for developers.
Why do we need a separate UI for development? Because developers have entirely different use cases than cluster administrators. And so far, there is no great way for developers to:
- switch between logs of different containers very quickly
- identify failing pods and containers with ease
- open container terminals without copy&pasting pod ids back and forth
- access applications quickly inside pods without a lot of configuration
- launch a UI in a kube-context with very restrictive permissions (e.g. no cluster access, no permission to even list namespace etc.)
With the localhost UI we are launching today, we are shipping a UI optimized for the use cases of developers. And this is just the start. A lot of developer-focused features for this UI will follow over time.
To learn more about the differences between admin and developer use cases and about why none of the existing client-side UIs was an option for us to built our UI on top of, take a look at the Design Decisions & UX section of this blog post.
But let's get to the fun part first: Check out the features of our Kubernetes dashboard alternative and take a look at the screenshots and screencasts in the following section.
Features & Demos
The following sections show different features of the new client-side UI included in DevSpace v4.2.
Namespace Inspection
After starting the UI, the "Logs" view is the start page for every developer. It allows to switch the context and namespace and shows:
- a list of containers (grouped by pods) in the selected namespace
- the status of each container (more details are visible on hover)
- several buttons to interact with the container (e.g. open container using 1-click port-forwarding, see YAML or start terminal session)
This view is the central hub for developers to observe the status of their containers. While being able to stream logs and open interactive terminal sessions, the list of pods will always remain visible and errors or failing pods and containers can be quickly noticed very quickly without having to navigate back and forth between different views.
Log Streaming (colorized)
When clicking on one of the containers' names, the UI will open the log stream which shows the last 100 log lines of this container and then starts streaming the container logs in real-time.
A highlight of the log stream is that it shows a colored output that looks the same as if you would execute the container entrypoint in a regular terminal.
The log stream can be maximized using the icon shown on the right upper corner of the log stream.
Interactive Terminal Sessions
When clicking on the terminal icon of a container (on the very right), the UI will open an interactive terminal session.
A highlight of the terminal sessions is that they stay open even if you switch to a container log. The terminal icon of the container will be highlighted in blue if a terminal session is currently running in the background. Simply click the terminal icon again to resume the session. Your output will be there and you can continue running commands immediately.
Similar to the log stream, terminal windows can also be maximized and also provide a colored output similar to a regular terminal on your development machine.
1-Click Port-Forwarding
The localhost UI of DevSpace makes it much easier to access an application that is running inside a container. With the 1-click port-forwarding, you can just click on the "Open" icon and DevSpace will start a port-forwarding session to this container and open the localhost address of the forwarded port in a new browser tab.
The localhost port will be randomly selected and DevSpace will check if the port is not used by any other process before starting the port-forwarding.
1-Click port-forwarding only works for pods that are selected by at least one service, i.e. the pod must be the endpoint of a service. If the service has multiple ports, DevSpace will use the first one.
Config Inspection (Stack)
When using config variables in your devspace.yaml as well as profiles and config patches, it is often hard to know which configuration was actually used by DevSpace when deploying the containers to your namespace. With the "Stack" view, you can see the config after patches have been applied and after config variables have been filled in.
In addition to the config, the UI tells you which profile is currently active and provides a list of available config variables as well as their values. In the future, it will be possible to change these values and secret values will be hidden by default and only showing on hover or when clicking a button.
Running Saved Commands
DevSpace allows you to define custom commands in your devspace.yaml. With the localhost UI, you can now see a list of these commands and execute them with a simple click.
When running a command, the UI opens an interactive terminal session to run the DevSpace command, which allows you to interact with the command as shown in the screencast above.
Design Decisions & UX
Currently, there is a lot of buzz around localhost UIs for Kubernetes. Instead of replicating features of the Kubernetes dashboard, we decided to focus the functionality of the DevSpace UI on things that matter most for developers working within a Kubernetes namespace.
This release ships the first version of the localhost UI for DevSpace and there are lots of things to come. If you spot a bug or think there is something missing that could improve your development workflow, reach out and open an issue on GitHub.
No YAML Editing (Read-Only)
We strongly believe in everything-as-code and think that developers should not manually edit resources directly inside the Kubernetes cluster. We think it is important to be able to inspect resources and show the YAML definition via the UI but editing resources should be done via the manifests and helm charts located within a project's configuration files.
All-In-One Logs View
Our goal is to provide the best developer experience for Kubernetes. Building microservices with Kubernetes requires to launch a whole bunch of containers and nothing is better to observe these containers and monitor their logs as by using a visual user interface. One of the most important goals was to support switching logs without delays. Therefore, DevSpace continues to stream the logs of containers after they are opened once. So, even when currently streaming another container, DevSpace will still stream the logs of all container you previously viewed through the log stream. This allows you to switch between log stream within seconds and without missing out on logs or having to wait for the connection to the Kubernetes API server to be re-established.
Additionally, the pods and containers in your current namespace as well as their status is always visible while streaming logs, which lets developers catch failing pods and containers with ease.
Developer vs Admin UI
Most existing UIs for Kubernetes, including VMware's client-only Octant and the good old server-side Kubernetes dashboard, are designed to be used by cluster administrators. They let an admin quickly check the health of a cluster, observe all different kinds of resource types, scale up replicasets and much more. Most of this functionality is pretty much useless for developers and pretty hard to navigate. Developers need their own dashboard which suits their use cases.
Let me give you an example: Let's say you are running a microservice system with 12 different services. Each of these services runs inside a separate Kubernetes pod. As a developer, there are a couple of things which are important for you in such a scenario:
- Get an overview of your pods and access their YAML definitions quickly
- Get notifications about failing pods and containers with ease
- Stream logs and quickly switch between the logs of different containers
- Start port-forwarding to your pods for localhost access
- Exec into containers if needed (e.g. to verify the content of mounted volumes etc.)
While 1. and 2. are definitely possible with most Kubernetes dashboards, 3.-5. are missing in every client-side UI we took a look at. While Octant, for example, allows you to stream logs, it requires quite a few clicks every time you switch between the logs of one pod to the logs of another pod and due to the fact that the log stream has to be re-established every time you switch, it gets very painful to always wait until the logs come up again. Of course, you could create 12 tabs in your browser for each of your microservices but the entire idea of our localhost UI is to save the developer from having to open 12 terminal windows or in this case browser tabs to be able to observe what is going on in their dev environment.
Additionally, most client-side UIs for Kubernetes are not able to run in a kube-context that allows access to one namespace only. Most DevSpace users work in sandboxed Kubernetes namespaces, which is not compatible with the approach of most client-side UIs that the developer needs to be able to perform cluster-wide operations such as listing namespaces or persistent volumes.
Observations like this one motivated us to start from scratch rather than building on an existing project. Don't misunderstand our evaluation: Octant and other projects are doing an excellent job at providing value for cluster admins, but we are working on a UI optimized for the developers and their use cases. And having different specialized UIs for different personas makes a lot of sense because one-size-fits-all solutions by nature have a hard time creating a great experience for individual personas and instead offer a mediocre experience for everybody.
Feedback or Questions?
If you have any feedback or questions regarding this release or if you have any feature requests for an upcoming release, reach out to us via:
- Slack: slack.devspace.cloud
- GitHub: Open Issue for DevSpace
- Email: team@devspace.cloud
Get involved! Let us build the best developer tool for Kubernetes.