Skaffold is a command line tool from Google that facilitates continuous development for Kubernetes applications. You can iterate on your application source code locally then deploy to local or remote Kubernetes clusters. Skaffold handles the workflow for building, pushing and deploying your application.
DevSpace is a ~2.8k ⭐ open-source developer tool from Loft Labs 🐦@loft_sh for Kubernetes that lets you develop and deploy cloud-native software faster. It is a client-only CLI tool that runs on your machine and works with any Kubernetes cluster. You can use it to automate image building and deployments, to develop software directly inside Kubernetes and to streamline workflows across your team as well as across dev, staging and production.
DevSpace is platform-agnostic and works with clusters ranging from your local machine to popular managed public services. The tool 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 (see "The hot reload functionality" section below).
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.
With DevSpace developer is capable to:
- Build, test and debug applications directly inside Kubernetes
- Develop with hot reloading: updates your running containers without rebuilding images or restarting containers
- Unify deployment workflows within your team and across dev, staging and production
- Automate repetitive tasks for image building and deployment
Installing DevSpace
DevSpace is a client-only binary which works on Windows, Mac, and Linux. It is super lightweight, does not require any server-side component, and it does not have any dependencies. My machine is running Ubuntu Focal, I am a Debian fan.
$ curl -s -L "https://github.com/loft-sh/devspace/releases/latest" | sed -nE 's!.*"([^"]*devspace-linux-amd64)".*!https://github.com\1!p' | xargs -n 1 curl -L -o devspace && chmod +x devspace;
sudo install devspace /usr/local/bin;
Cluster connection
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.conf
I use k3s/k3d as my local Kubernetes development stage. Let's
Start the cluster
$k3d cluster start my-cluster
INFO[0000] Using the k3d-tools node to gather environment information
INFO[0000] Starting new tools node...
INFO[0000] Starting Node 'k3d-my-cluster-tools'
INFO[0001] HostIP: using network gateway 172.19.0.1 address
INFO[0001] Starting cluster 'my-cluster'
INFO[0001] Starting servers...
INFO[0001] Starting Node 'k3d-my-cluster-server-0'
INFO[0006] Starting agents...
INFO[0006] Starting Node 'k3d-my-cluster-agent-0'
INFO[0019] Starting helpers...
INFO[0019] Starting Node 'k3d-my-cluster-serverlb'
INFO[0026] Injecting records for hostAliases (incl. host.k3d.internal) and for 3 network members into CoreDNS configmap...
INFO[0029] Started cluster 'my-cluster'
Let's do something impressive on demo project.
$ git clone https://github.com/otomato-gh/devspace-quickstart-python.git
$ cd devspace-quickstart-python
In DevSpace terms, we're ready to
Initialize our project
$ devspace init
Choose Component Helm Chart
for the first question. In a next step you may choose a Dockerfile (we have one here in our project) and a Docker registry for storing images.
After running devspace init
, you will see a devspace.yaml
file in your project which should look like this one.
⚙️ DEVELOPment mode
$ devspace dev
What's up:
[info] Using namespace 'default'
[info] Using kube context 'k3d-my-cluster'
[info] Execute '/home/roman/.devspace/bin/helm upgrade devspace-quickstart-python --namespace default --values /tmp/740048097 --install /home/roman/.devspace/component-chart/component-chart-0.8.4.tgz --kube-context k3d-my-cluster'
[done] √ Deployed helm chart (Release revision: 1)
[done] √ Successfully deployed devspace-quickstart-python with helm
[0:replacePod] Try to find replaced pod...
[0:replacePod] Try to find replaceable pod...
[0:replacePod] Replacing Pod default/devspace-quickstart-python-69787d5b47-rvlf4...
[0:replacePod] Scaled down Deployment default/devspace-quickstart-python
[0:replacePod] Waiting for Pod devspace-quickstart-python-69787d5b47-rvlf4 to get terminated...
[0:replacePod] Successfully replaced pod default/devspace-quickstart-python-69787d5b47-rvlf4
#########################################################
[info] DevSpace UI available at: http://localhost:8090
#########################################################
[0:ports] Port-Forwarding: Waiting for containers to start...
[0:sync] Waiting for containers to start...
[0:sync] Starting sync...
[0:ports] Port forwarding started on 8080:8080 (default/devspace-quickstart-python-69787d5b47-rvlf4-742jd)
[0:sync] Sync started on /home/roman/devspace-quickstart-python <-> . (Pod: default/devspace-quickstart-python-69787d5b47-rvlf4-742jd)
[0:sync] Waiting for initial sync to complete
[info] Opening 'http://localhost:8080' as soon as application will be started (timeout: 4m0s)
[info] Terminal: Waiting for containers to start...
[info] Opening shell to pod:container devspace-quickstart-python-69787d5b47-rvlf4-742jd:container-0
DevSpace will starts the development UI on port 8090
.
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 devspace.yaml
file:
images:
app:
image: rbalashevich/app:latest
dockerfile: ./Dockerfile
build:
disabled: true
The 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 launching devspace build
and devspace deploy
commands, unless build.disabled
is true
in the image’s config.
Networking
Port-forwarding allows you to access your application on localhost:[PORT]
by forwarding the network traffic from a localhost port to a specified port of a container.
When starting the development mode, DevSpace starts port-forwarding as configured in the dev.ports
section of the
devspace.yaml
.
# `dev.ports` specifies all ports that should be forwarded while `devspace dev` is running
# Port-forwarding lets you access your application via localhost on your local machine
ports:
- imageSelector: ${IMAGE} # Select the Pod that runs our `${IMAGE}`
forward:
- port: 8080
⚙️ DEPLOYment mode
You may learn the details about deployment mode here.
The hot reload functionality
This is enabled by setting up file synchronization:
# `dev.sync` configures a file sync between our Pods in k8s and your local project files
sync:
- imageSelector: ${IMAGE} # Select the Pod that runs our `${IMAGE}`
# `excludePaths` option expects an array of strings with paths that should not be synchronized between the
# local filesystem and the remote container filesystem. It uses the same syntax as `.gitignore`.
excludePaths:
- .git/
uploadExcludePaths:
- Dockerfile
The imageSelector
matches image tags to apply the hot reload rule to. To establish an on-demand file synchronization between your local computer and the containers running inside Kubernetes, use the following command:
$ devspace sync
Common flags are described here.
What's more inside our toolbox?
DevSpace capabilities also include:
- Deployments via
helm
,kubectl
. -
Dockerfile
modification in-memory on execution time. - Development tools, such as log aggregation.
- Custom hooks (actions that are carried out based on events).
- Custom commands (to build complex or lengthy commands into a single sub-command).
- Custom profiles (to change anything in the
devspace.yaml
andDockerfile
usingadd
,patch
,remove
andmerge
operations. - The profiles bring the ability to use different configurations for specific deployment types, such as staging, production or testing.
-
Might be seen as a replacement or a companion for CI/CD tools for GitOps, such as Flux or ArgoCD, which can allow developers to only have to configure
YAML
files that are then uploaded to a Git repository for deployment.
Summing up, we at Otomato consider DevSpace makes developers more productive in the Kubernetes environment. It would not be bad to say this amazing tool have been designed to lower the Kubernetes learning curve.
Top comments (0)