Configure Component Deployments
To deploy components, you need to configure them within the deployments
section of the devspace.yaml
.
deployments:
- name: frontend
helm:
componentChart: true
values:
containers:
- image: dscr.io/${DEVSPACE_USERNAME}/appfrontend
service:
ports:
- port: 3000
- name: backend
helm:
componentChart: true
values:
containers:
- image: john/appbackend
- image: mysql
volumeMounts:
- containerPath: /var/lib/mysql
volume:
name: mysql-data
subPath: /mysql
readOnly: false
volumes:
- name: mysql-data
size: "5Gi"
Containers & Pods
deployments[*].component.containers
See Containers for details.
deployments[*].component.initContainers
The initContainers
section allows the exact same configuration options as the containers
section. See Containers for details.
deployments[*].component.labels
The labels
option expects a map with Kubernetes labels.
By default, the component chart sets a couple of labels following the best practices described in the Kubernetes documentation:
app.kubernetes.io/name: devspace-app
app.kubernetes.io/component: [DEPLOYMENT_NAME]
app.kubernetes.io/managed-by: Tiller
You can specify additional labels using the
labels
option but the default / best practice labels will still be set for the component.
All additional labels will be added to the pods of this component as well as to your Deployments or StatefulSets used to create the pods.
labels
Default Value For labels: []
Example: Additional Labels
deployments:
- name: backend
helm:
componentChart: true
values:
containers:
- image: john/appbackend
labels:
label1: label-value-1
label1: label-value-2
deployments[*].component.annotations
The annotations
option expects a map with Kubernetes annotations.
By default, the component chart sets a couple of annotations following the best practices described in the Kubernetes documentation:
helm.sh/chart: component-chart-vX.Y.Z
You can specify additional annotations using the
annotations
option but the default / best practice annotations will still be set for the component.
All additional annotations will be added to the pods of this component as well as to your Deployments or StatefulSets used to create the pods.
annotations
Default Value For annotations: []
Example: Additional Annotations
deployments:
- name: backend
helm:
componentChart: true
values:
containers:
- image: john/appbackend
annotations:
annotation1: annotation-value-1
annotation1: annotation-value-2
Volumes & Persistent Storage
deployments[*].component.volumes
See Volumes for details.
Service & In-Cluster Networking
deployments[*].component.service
See Service for details.
deployments[*].component.serviceName
The serviceName
option expects a string that will be used as a name for the headless service if the component will be deployed as a StatefulSet instead of a Deployment. This happens automatically when one of the containers mounts a persistent volume.
serviceName
Default Value For serviceName: "[COMPONENT_NAME]-headless"
Example: Custom Name for Headless Service
deployments:
- name: backend
helm:
componentChart: true
values:
containers:
- image: mysql
volumeMounts:
- containerPath: /var/lib/mysql
volume:
name: mysql-data
subPath: /mysql
readOnly: false
volumes:
- name: mysql-data
size: "5Gi"
serviceName: "custom-name-for-headless-service"
Explanation:
Instead of the default name backend-headless
, the headless service for the ReplicaSet created by this component would be custom-name-for-headless-service
.
Ingress & Domain
deployments[*].component.ingress
See Ingress (Domain) for details.
Scaling
deployments[*].component.replicas
See Scaling for details.
deployments[*].component.autoScaling
See Scaling for details.
Advanced
deployments[*].component.rollingUpdate
The rollingUpdate
option the Kubernetes configuration for rolling updates.
The following fields are supported for Deployments (none of the containers mounts any persistent volumes):
enabled
maxSurge
maxUnavailable
The following fields are supported for StatefulSets (at least one of the containers mounts a persistent volume):
partition
If
enabled = true
, the Kubernetes rolling update type will be set toRollingUpdate
. By default, this value isRecreate
.
rollingUpdate
Default Value For rollingUpdate:
enabled: false
maxSurge: "25%"
maxUnavailable: "0%"
partition: 0
Example: Enabling Rolling Updates
deployments:
- name: backend
helm:
componentChart: true
values:
containers:
- image: john/appbackend
rollingUpdate:
enabled: true
maxUnavailable: "50%"
deployments[*].component.pullSecrets
The pullSecrets
option expects an array of strings with names of Kubernetes secrets containing image registry authentification data.
Adding a secret name to pullSecrets
will tell DevSpace to add the secret name as pullSecret to the Deployment or StatefulSet that will be created for this component.
DevSpace is also able to create pull secrets for registries automatically. These pull secrets do not need to be added to
pullSecrets
as they will be added to the service account instead which makes them available to Kubernetes without adding them to each Deployment or StatefulSet.
pullSecrets
Default Value For pullSecrets: []
Example: Custom Name for Headless Service
deployments:
- name: backend
helm:
componentChart: true
values:
containers:
- image: john/appbackend
pullSecrets:
- pull-secret-1
- pull-secret-2
deployments[*].component.podManagementPolicy
The podManagementPolicy
option expects a string which sets the podManagementPolicy
Kubernetes attribute for a StatefulSets.
podManagementPolicy
Default Value For podManagementPolicy: OrderedReady
Example: Custom Name for Headless Service
deployments:
- name: backend
helm:
componentChart: true
values:
containers:
- image: john/appbackend
podManagementPolicy: Parallel
deployments[*].component.options
The options
option provides a way to set several config options that are generally available for Helm deployments because a component is a highly flexible Helm chart where you only provide the values
such as containers
.
Available options are:
All options listed above can be configured for components in the same way as for regular Helm charts. Please refer to the Helm Chart Configuration page for default values and configuration details.
Useful Commands
devspace list available-components
Run the following command to get a list of predefined components:
devspace list available-components
Use devspace add deployment [NAME] --component=[COMPONENT_NAME]
to add one of these components to the deployments
section in devspace.yaml
.
devspace add deployment [NAME] --component=mysql|redis|...
Run the following command to add a predefined component to the deployments
section in devspace.yaml
:
devspace add deployment [deployment-name] --component=[component-name]
Example: devspace add deployment database --component=mysql
Running
devspace add deployment
only adds a deployment todevspace.yaml
but does not actually deploy anything. To deploy the newly added deployment, rundevspace deploy
ordevspace dev
.
List of predefined components
DevSpace provides the following predefined components:
- mariadb
- mongodb
- mysql
- postgres
- redis
devspace add deployment [NAME] --dockerfile=[PATH]
Run one of the following commands to add a component deployment to the deployments
section in devspace.yaml
based on an existing Dockerfile:
devspace add deployment [deployment-name] --dockerfile="./path/to/Dockerfile"
devspace add deployment [deployment-name] --dockerfile="./path/to/Dockerfile" --image="my-registry.tld/[username]/[image]"
Both commands would add a component deployment to the deployments
and a image to the images
section defining how the image would be built, tagged and pushed using the Dockerfile you provided.
The difference between the first command and the second one is that the second one specifically defines where the Docker image should be pushed to after building the Dockerfile. Using the first command, DevSpace would assume that you want to use a private repository at dscr.io, the free image registry sponsored by DevSpace Cloud.
If you are using a private Docker registry, make sure to login to this registry.
Running
devspace add deployment
only adds a deployment todevspace.yaml
but does not actually deploy anything. To deploy the newly added deployment, rundevspace deploy
ordevspace dev
.
devspace add deployment [NAME] --image=[IMAGE]
Run the following command to add a component deployment to the deployments
section in devspace.yaml
based on an existing Docker image:
devspace add deployment [deployment-name] --image="my-registry.tld/[username]/[image]"
This command would add a component deployment to the deployments
section in devspace.yaml
.
If you are using a private Docker registry, make sure to login to this registry.
Running
devspace add deployment
only adds a deployment todevspace.yaml
but does not actually deploy anything. To deploy the newly added deployment, rundevspace deploy
ordevspace dev
.
Example using Docker Hub
devspace add deployment database --image="mysql"
devspace remove deployment [NAME]
Instead of manually removing a deployment from your devspace.yaml
, it is recommended to run this command instead:
devspace remove deployment [deployment-name]
The benefit of running devspace remove deployment
is that DevSpace will ask you this question:
? Do you want to delete all deployment resources deployed? [Use arrows to move, type to filter]
> yes
no
If you select yes, DevSpace will remove your deployment from your Kubernetes cluster before deleting it in your devspace.yaml
. This is great to keep your Kubernetes namespaces clean from zombie deployments that cannot be easily tracked, removed and updated anymore.