Deployment with DevSpace

Once you are done with developing your application or you just want to test if it works even outside of development mode with your actual container image, you can start a clean deployment.

DevSpace CLI - Deployment

Kube-Context & Namespace

For this clean deployment, you may want to switch to a different namespace or even to a different cluster to test your application in a cloud-powered cluster, for example.

Local Cluster

Local Clusters

Local clusters run on your local dev machine and include: minikube, kind, k3s, mikrok8s etc.

If you want to deploy to a local Kubernetes cluster, make sure your current kube-context points to this cluster and tell DevSpace which namespace to use:

devspace use context # to select the right k8s cluster

devspace use namespace my-namespace # will be automatically created during deployment

Kube-Context Namespace

Running the command above will change the default namespace of your kube-context, i.e. instead of using the default namespace, kubectl and other tools will now use a different namespace when working with this kube-context. That also means, you will not always need to use the --namespace / -n flag.

Remote Cluster

Remote Clusters

Remote clusters run in a cloud or private data center and include: GKE, EKS, AKS, bare metal etc.

Use cluster alone

devspace use context # to select the right k8s cluster

devspace use namespace my-namespace # will be automatically created during deployment

Kube-Context Namespace

Running the command above will change the default namespace of your kube-context, i.e. instead of using the default namespace, kubectl and other tools will now use a different namespace when working with this kube-context. That also means, you will not always need to use the --namespace / -n flag.

Share cluster with others

STEP 1

Setup Loft and connect your cluster

See the Loft getting started guide for details.

STEP 2

Install the Loft plugin for DevSpace

devspace add plugin https://github.com/loft-sh/loft-devspace-plugin

STEP 3

Login to Loft via DevSpace

devspace login https://your-loft-instance.tld

STEP 4

Create isolated namespaces (= Spaces)

devspace create space my-app

Kube-Context

DevSpace automatically sets up a kube-context for this Space, so you can also access your namespace using kubectl, helm or any other Kubernetes tool. Try it:

kubectl get pods

STEP 5

Add cluster users and allow them to create Spaces

Learn more about how to do this in the Loft documentation.

Deploy Project

Run the local deployment pipeline using this command:

devspace deploy -p production

DevSpace CLI - Deployment Workflow

Running devspace deploy -p production will do the following:

1. Build the Dockerfile(s) specified in the images section of the devspace.yaml
2. Tag the resulting image(s) with an auto-generated tag according to a customizable tag schema
3. Push the resulting Docker images to the specified registries
4. Create image pull secrets in your Kubernetes namespace (optional, enabled by default)
5. Deploy everything that is defined within the deployments section in the devspace.yaml

Image Building Only

If you only want to build, tag and push all images but not deploy anything, run:

devspace build

Understand Profiles

As shown earlier, DevSpace is by default configured to skip image building, for example. However, to fully test your containerized application you may want to create a fresh image and push this image to a registry.

Profiles allow you to apply modifications to your devspace.yaml configuration for certain use cases or for different deployment targets (e.g. dev vs testing vs production).

By default, devspace init adds a small example profile called production which only removes the disabled: true statement from our images section which in turn enables image building:

profiles:

- name: production

patches:

- op: remove

path: images.app.build.disabled

You can print the config after a profile has been applied to see what the profile actually changes:

devspace print -p production

The flag -p / --profile is global, so we can also use them for other commands and define profiles that apply to different workflows for commands such as devspace dev:

devspace dev -p start-debugger