Deploy Helm Charts
To deploy Helm charts, you need to configure them within the deployments
section of the devspace.yaml
.
#
Examples- Component Chart
- Custom Chart
- Local Chart
- Git Chart Repo
Component Chart Docs
The component chart is a flexible Helm chart for deploying custom applications in a standardized manner. Learn more in the Component Chart Documentation.
#
ChartcomponentChart
#
The componentChart
option expects a boolean which states if the Component Helm Chart should be used for deployment.
Component Chart Docs
The component chart is a flexible Helm chart for deploying custom applications in a standardized manner. Learn more in the Component Chart Documentation.
warning
If componentChart: true
is configured, all options under chart
will be ignored.
componentChart
#
Default Value for #
Example: Component Chart Deploymentchart.name
#
The name
option is mandatory and expects a string stating either:
- a path to a local chart that is stored on the filesystem
- or the name of a remote chart that is stored in a repository (one specified via
repo
option) or in the form ofrepo/name
, whererepo
was added viahelm repo add repo https://repo.url
beforehand
DevSpace follows the same behavior as helm install
and first checks if the path specified in name
exists on the file system and is a valid chart. If not, DevSpace will assume that the name
is not a path but the name of a remote chart located in a chart repository.
#
Example: Simple Helm DeploymentExplanation:
Deploying the above example would roughly be equivalent to this command:
chart.version
#
The version
option expects a string stating the version of the chart that should be used.
version
#
Default Value for Latest Version
If no version is specified, Helm will by default use the latest version of the chart.
#
Example: Custom Chart VersionExplanation:
Deploying the above example would roughly be equivalent to this command:
chart.repo
#
The repo
option expects a string with a URL to a Helm Chart Repository. This is equivalent of using the --repo
flag in helm install
#
Example: Custom Chart RepositoryExplanation:
Deploying the above example would roughly be equivalent to this command:
chart.username
#
The username
option expects a string that specifies the user that should be used to access chart.repo
. Will be used as value for the helm flag --username
chart.password
#
The password
option expects a string that specifies the password that should be used to access chart.repo
. Will be used as value for the helm flag --password
#
ValuesHelm charts can be configured by overriding the default values of the chart.
values
#
The values
option expects an object with values that should be overriding the default values of this Helm chart.
Compared to the valuesFiles
option, using values
has the following advantages:
- It is easier to comprehend and faster to find (no references)
- It allows you to use dynamic config variables
info
Because both, values
and valuesFiles
, have advantages and disadvantages, it is often useful to combine them. When setting both, values defined in values
have precedence over values defined in valuesFiles
.
values
#
Default Value for #
Example: Using Values in devspace.yamlExplanation:
Deploying the above example would roughly be equivalent to this command:
valuesFiles
#
The valuesFiles
option expects an array of paths to yaml files which specify values for overriding the values.yaml of the Helm chart.
Compared to the values
option, using valuesFiles
has the following advantages:
- It reduces the size of your
devspace.yaml
especially when setting many values for a chart - It allows you to run Helm commands directly without DevSpace, e.g.
helm upgrade [NAME] -f mysql/values.yaml
info
Because both, values
and valuesFiles
, have advantages and disadvantages, it is often useful to combine them. When setting both, values defined in values
have precedence over values defined in valuesFiles
.
valuesFiles
#
Default Value for #
Example: Using Values FilesExplanation:
Deploying the above example would roughly be equivalent to this command:
replaceImageTags
#
The replaceImageTags
option expects a boolean stating if DevSpace should do Image Tag Replacement.
By default, DevSpace searches all your values (specified via values
or valuesFiles
) for images that are defined in the images
section of the devspace.yaml
. If DevSpace finds an image, it replaces or appends the image tag with the tag it created during the image building process. Image tag replacement makes sure that your application will always be started with the most up-to-date image that DevSpace has built for you.
DevSpace will replace the following things:
- registry.url/repo/name that corresponds to a
images.*.image
, will be rewritten toregistry.url/repo/name:generated_tag
In-Memory Tag Replacement
Tag replacement takes place in-memory and is not writing anything to the filesystem, i.e. it will never change any of your configuration files.
replaceImageTags
#
Default Value for #
Example: Disable Tag Replacement#
Helm OptionsupgradeArgs
#
The upgradeArgs
specifies an array of arguments that will be passed by devspace additionally to the standard arguments to helm upgrade
during deployment.
templateArgs
#
The templateArgs
specifies an array of arguments that will be passed by devspace additionally to the standard arguments to helm template
during devspace render
.
deleteArgs
#
The deleteArgs
specifies an array of arguments that will be passed by devspace additionally to the standard arguments to helm delete
during devspace purge
.
wait
#
The wait
option expects a boolean that will be used for the helm flag --wait
.
wait
#
Default Value for #
Example: Helm Flag WaitExplanation:
Deploying the above example would roughly be equivalent to this command:
displayOutput
#
The displayOutput
option expects a boolean and allows helm output to be printed to the console after helm install
and helm upgrade
. This can be used to display notes.txt
from your helm charts.
displayOutput
#
Default Value for #
Example: displayOutputExplanation:
Deploying the above example would print the helm output and the notes.txt
from the bitnami/mysql chart.
timeout
#
The timeout
option expects an integer representing a number of seconds that will be used for the helm flag --timeout
.
timeout
#
Default Value for #
Example: Helm Flag TimeoutExplanation:
Deploying the above example would roughly be equivalent to this command:
force
#
The force
option expects a boolean that will be used for the helm flag --force
.
force
#
Default Value for #
Example: Helm Flag ForceExplanation:
Deploying the above example would roughly be equivalent to this command:
recreate
#
The recreate
option expects a boolean that states if DevSpace should set the Helm flag --recreate-pods
. It tells Helm to restart all pods for applicable resources (e.g. Deployments).
recreate
#
Default Value for #
Example: Enable Recreate Podsatomic
#
The atomic
option expects a boolean that states if DevSpace should pass the --atomic
flag to Helm. If set, the upgrade process rolls back all changes in case the upgrade fails. This flag also sets the --wait
option.
atomic
#
Default Value for #
Example: Enable Atomic DeploymentcleanupOnFail
#
The cleanupOnFail
option expects a boolean that states if DevSpace should set the Helm flag --cleanup-on-fail
. It allows that Helm deletes newly created resources during a rollback in case the rollback fails.
cleanupOnFail
#
Default Value for #
Example: Enable Cleanup On FaildisableHooks
#
The disableHooks
option expects a boolean that tells DevSpace to disable hooks when executing Helm commands.
disableHooks
#
Default Value for #
Example: Disable Hooksv2
#
The v2
option expects a boolean that tells DevSpace to use the legacy version 2 of Helm instead of Helm v3.
v2
#
Default Value for tillerNamespace
#
The tillerNamespace
option expects a string that will be used for the helm flag --tiller-namespace
.
Helm 2 Only
This config option is only used when v2: true
is configured as well.
Deprecated
This config option is deprecated because Tiller is not necessary anymore since DevSpace supports Helm v3.
tillerNamespace
#
Default Value for #
Example: Change Tiller NamespaceExplanation:
Deploying the above example would roughly be equivalent to this command:
path
#
The path
option is optional and expects a string with the path of an Helm v2 binary / executable file which should be used for Helm v2 deployments.
Helm 2 Only
This config option is only used when v2: true
is configured as well.
warning
Setting path
makes it much harder to share your devspace.yaml
with other team mates. It is recommended to add helm
to your $PATH
environment variable instead.
#
General Optionsname
#
The name
option is required and expects a string with the name of the release used to deploy this Helm chart.
#
Example: Deployment Namenamespace
#
The namespace
option is required and expects a string with the namespace used to deploy the Helm chart to.
warning
Only use this option if you really need to. Hard-coding the namespace in devspace.yaml
makes it harder to share the configuration with your colleagues. It is recommended to set the default namespace of the current context instead using:
#
Example: Deployment Namespacedisabled
#
If true, the deployment will not be deployed, rendered or purged. Can be useful in combination with config expressions or command variables.