DevSpace is an open-source tool that helps developers quickly deploy cloud-native applications to Kubernetes clusters. It abstracts away much of the traditional Kubernetes complexity so you can get back to writing code.
DevSpace is platform-agnostic and works with clusters ranging from your local machine to popular managed public services. The tool is a CLI that automates operations using Kubernetes APIs. You don’t need to install anything inside your cluster to use DevSpace.
Modern Development Practices for Kubernetes
DevSpace brings many aspects of the modern app programming experience to Kubernetes-based deployments. It lets you run your development environment on your cluster with support for automatic hot reloading. When a local file changes, DevSpace automatically updates your containers with the new content.
Built-in port forwarding means you can use
localhost to access your deployment. You don’t need to open ports or setup HTTP Ingresses on development clusters, offering an improved developer experience and greater security.
DevSpace aids debugging too. It supports setting breakpoints using a Remote Debugger tool, offering live inspection of containerized applications in the cloud. It’s also easy to view a container’s logs or start a terminal session without running unwieldy Kubectl commands.
A web interface running on
localhost lets you monitor and interact with your running application. You can escape your terminal altogether if you prefer a more visual experience.
DevSpace is distributed as a self-contained binary that works on Windows, Mac, and Linux systems. Several installation options are available. Here’s the recommended command to download DevSpace for Linux and add the CLI to your path:
dev sudo install devspace /usr/local/bin
Alternatively you can use npm, the Node package manager, to install and update DevSpace:
npm install -g devspace
This command will give you a functioning
devspace in your path, provided you’ve already got npm installed.
DevSpace uses your active “
KUBE_CONTEXT” in the same way as other ecosystem tools like Kubectl and Helm. Set
KUBECONFIG to a Kubectl-compatible config file defining your cluster connection:
export KUBECONFIG=/path/to/kubeconfig.yaml # Uses $KUBECONFIG devspace deploy
Creating a Project
The first step in building with DevSpace is to initialize your project directory. This will create a
devspace.yaml file that holds the DevSpace config for your repository.
You’ll be prompted to select the deployment routine you plan to use. DevSpace can work with Kubectl, Helm, or Kustomize when launching your app into your cluster.
QUICKSTART option is a special chart that lets you define components of your application, such as your frontend web server, backend API server, and database, instead of supplying manually created Helm charts or Kubectl manifests. Use this if you’re building a system with a conventional structure and don’t want to spent time creating your own Kubernetes resources.
Follow the prompts to supply DevSpace with the path to your Dockerfile. You’ll need to supply registry authentication and some basic information about your image, such as the port it listens on. DevSpace will automatically produce a ready to use config that lets you run
devspace deploy to get your app live on Kubernetes.
If you don’t use the quickstart option, you’ll need to supply the path to your Helm charts or Kubernetes manifests. Follow the prompts to build an initial configuration. Once you get out of the setup wizard, you can continue adding extra images and deployments by manually editing your
Adding an Image
DevSpace projects are built from one or more container images. To register an image in your project, add it under the
images key in your
images: app: image: example.com/example/image:latest dockerfile: ./Dockerfile build: disabled: true
image field defines the image tag name. The
dockerfile field is optional; when set, it should reference the path to the image’s Dockerfile in your project. Images with Dockerfiles will be built automatically by the
devspace build and
devspace deploy commands, unless
true in the image’s config.
Images are built in parallel to accelerate performance. The
--build-sequential flag forces images to be built singly in the order they’re specified instead. DevSpace will automatically push each image to its respective registry after a build completes.
Images aren’t rebuilt automatically unless DevSpace detects a change either in their Dockerfile or the files in their build context. You can force a rebuild of all configured images with the
Adding a Deployment
The second piece of a
devspace.yaml is your
deployments. These define the resources that will be created inside your cluster.
deployments: - name: "helm chart" helm: chart: name: example/example-app values: VARIABLE_OVERRIDE: "new-value" - name: "kubectl manifests" kubectl: manifests: - .kube/manifests
This file defines two separate deployments, one using Helm and the other Kubectl. When you run
devspace deploy, both the Helm chart and your Kubectl manifests will be installed in your cluster.
deploy command will update your deployments. DevSpace only redeploys the components that changed unless the
--force-deploy flag is used.
As DevSpace works across clusters, promoting your deployment from development to production is a case of changing your
KUBECONFIG environment variable and re-running
devspace deploy. This gives you a single consistent mechanism for managing multiple independent deployments of your system.
DevSpace supports profiles that let you modify
devspace.yaml sections for each of your environments. Each named profile can replace, merge, and modify fields within your config file.
Profiles themselves are also defined in your
images: api-server: image: example.com/api-server:latest web-server: image: example.com/web-server:latest debug: image: example.com/debug-tool:latest # ... omitted profiles: - name: production patches: - op: remove path: images.debug
Profiles are activated by passing the
--profile flag to DevSpace commands. Here’s how to start a deployment using the
production profile defined above. The deployment won’t include the
debug image as it’s removed by one of the profile’s patches.
devspace deploy --profile production
Using Hot Reload
The hot reload functionality is enabled by setting up file synchronization:
dev: sync: - imageSelector: example.com/api-server:latest localSubPath: ./api/ containerPath: /var/www/html excludePaths: - vendor/
dev key as a top-level field in your
devspace.yaml, then use
sync to configure hot reload on a per-image basis. The
imageSelector matches image tags to apply the hot reload rule to. Files from
localSubPath in your working directory will be synchronized to
containerPath in deployed container instances.
Start a hot reload session by running
devspace dev or
devspace sync. The former command starts all DevSpace’s developer environment features, including port forwarding and live log streaming.
Hot reload defaults to replacing files in existing containers. It’s similar to using Docker volumes and bind mounts when working with local container instances. In some scenarios, you might want to start a new DevSpace deployment when your filesystem changes. This is achieved via the separate
images: api: image: example.com/api-server:latest deployments: - name: api-deployment # ... omitted dev: autoReload: paths: - ./kernel/* images: - example.com/api-server:latest deployments: - api-deployment
This example will redeploy
api-deployment whenever files in your local
kernel directory change. This is ideal when you modify files that need to be run through a build process to make them useful to your containers.
Port forwarding is configured via the
dev.ports field in your
devspace.yaml. Reverse forwarding is also supported, letting
localhost addresses in your containers map to ports on your local machine.
dev: ports: - imageSelector: example.com/api-server:latest forward: - port: 8080 remotePort: 80 reverseForward: - port: 9000 remote: 9000
This example sets up a forward from
localhost:8080 on your machine to port 80 in containers running the
example.com/api-server image. There’s also a reverse forward which directs in-container traffic to
localhost:9000 back to port 9000 on your machine.
Besides the capabilities covered here, DevSpace also offers support for several other feature groups that let you monitor deployments, interact with containers, and configure advanced development workflows:
- Automatic terminal launches let you start a remote shell session each time you run
- Automatic URL opening starts websites and web apps in your browser when you enter development mode.
- Configurable logging defines which containers should appear in the dev mode log stream.
- Custom commands act as shortcuts to common actions, helping new team members interact with your deployments without needing to learn lengthy processes in Kubectl.
- Hooks run commands during the deployment process, letting you manually configure containers or record new deployments to a centralized monitoring service.
- The user interface runs automatically in development mode with
devspace devand can be opened in your browser using
DevSpace also offers plugins that can add even more functionality to the system. The plugin API supports installation from remote URLs or local scripts and facilitates new commands, hooks, and variables. Developing your own plugin provides a way to standardize your use of DevSpace across multiple independent projects.
Deployments In CI/CD Pipelines
DevSpace can handle production deployments as part of your CI/CD pipeline. It provides an official Docker image and supports non-interactive use if you include explicit selectors such as
-l for label in your commands.
A deployment inside a CI pipeline could look like this:
echo $KUBECONFIG_CI_VARIABLE > /path/to/kubeconfig export KUBECONFIG=/path/to/kubeconfig devspace deploy --profile production --timeout 60 --wait --skip-build
This will deploy your application using the
production DevSpace profile. The
--skip-build flag instructs DevSpace not to build your images. Builds should usually be handled as a separate stage earlier in your pipeline.
--wait flag forces DevSpace to wait for availability of the Pod count specified in your
devspace.yaml, instead of terminating immediately after you run the command. This is more appropriate for a CI environment where you want confirmation that your workload is live. Allowing DevSpace to exit without waiting could mean your pipeline gets marked as successful even if there’s a deployment issue.
DevSpace is gaining traction as a developer-oriented Kubernetes deployment tool that provides useful abstractions for key operations. It reduces the amount of YAML needed to launch containers into a cluster, replacing it with simple config keys and terminal commands that define, build, and start images.
As a platform- and environment-agnostic tool, DevSpace permits developers to worry less about the unique characteristics of individual clusters. Irrespective of deployment target, the overall experience is similar to building a traditional system on your local machine. This helps soften the Kubernetes learning curve by mapping the concepts back to more universally understood development practices.
- › 5 Annoying Features You Can Disable on Samsung Phones
- › Why Do I See “FBI Surveillance Van” in My Wi-Fi List?
- › What Can You Do With the USB Port on Your Router?
- › ExpressVPN Review: An Easy-to-Use and Secure VPN for Most People
- › Why Unlimited Mobile Data Isn’t Actually Unlimited
- › Here’s How Mozilla Thunderbird Is Making a Comeback in 2022