DevSpace - The Fastest Developer Tool for Kubernetes ⚡ Automate your deployment workflow with DevSpace and develop software directly inside Kubernetes.
APACHE-2.0 License
Bot releases are hidden (Show)
Published by FabianKramm over 3 years ago
With dev.replacePods
we introduced a new feature that gives you the option to exchange an already running or just deployed pod with a modified version. This is especially useful if you:
For example:
version: v1beta10
deployments:
- name: my-app
helm:
componentChart: true
values:
containers:
- name: my-container
image: idonotexist:neverexisted # this will create a failing pod
dev:
# DevSpace will try to find a pod with the given label selector. If found (even if its currently in a failed state)
# DevSpace will copy the pod, scale down the owning ReplicaSet, Deployment or StatefulSet
# and create the new modified pod in the cluster.
replacePods:
- labelSelector:
app.kubernetes.io/component: my-app
replaceImage: ubuntu:latest # you could also use image(default):tag(default) if you want to make this more dynamic
patches:
- op: replace
path: spec.containers.name=my-container.command
value: ["sleep"]
- op: replace
path: spec.containers.name=my-container.args
value: ["9999999999"]
- op: replace
path: spec.containers.name=my-container.workingDir
value: "/workdir"
# This will create a terminal to the replaced pod
terminal:
labelSelector:
app.kubernetes.io/component: my-app
# This will sync to the replaced pod's working directory
sync:
- labelSelector:
app.kubernetes.io/component: my-app
For more informations take a look at the devspace docs
With v5.12.0, we greatly improved dependencies and you are now able to reference dependency images and reuse dependency dev
configuration. This makes it possible to create much more flexible pipelines and enables you to outsource parts of your devspace.yaml
enterly.
For example, you can now reference dependency images in every imageName
field via dependency1.image1
. In deployment values, you can now use image(dependency1.image1):tag(dependency1.image1)
to insert an image that was built within a dependency. You can even reference dependencies of dependencies via depdency1.dependency2.image1
. You can also run a command of a dependency with devspace run dependency1.command
now.
For example ./devspace.yaml
:
version: v1beta10
dependencies:
- name: dep1
source:
path: ./dep1
dev:
ports: true
deployments:
- name: quickstart
helm:
componentChart: true
values:
containers:
- image: image(dependency1.image1):tag(dependency1.image1) # will be replaced with -> myrepo/image:xxxx
dev:
# Will open a terminal to the pod with the
# image from dep1
terminal:
imageName: dep1.image1
Then the dependency ./dep1/devspace.yaml
could look like this:
version: v1beta10
images:
image1:
image: myrepo/image
dev:
ports:
- imageName: image1
forward:
- port: 3000
This makes it a lot easier to divide your devspace.yaml
into multiple parts or to build a much complexer pipeline with multiple build and deploy steps.
For more informations take a look at the devspace docs
With the new config version v1beta10
we cleaned up some options that were now deprecated for a while (especially dev.interactive
was changed). Older config versions will still continue to work as expected and there are no breaking changes as DevSpace will convert them automatically in memory, you can see how DevSpace translates your current config by running devspace print
. We changed the following options with v1beta10
:
dev.interactive
completely. We also removed all related documentation regarding interactive mode and encourage users to use dev.terminal
instead, which opens a terminal without touching the Dockerfile and is much easier to understand. If you need to exchange the entrypoint of the container with DevSpace, we encourage you to use either images[*].entrypoint
& images[*].cmd
, set command
& args
in your deployment (if thats supported by your helm chart or manifests) or use the new feature dev.replacePods
to modify the pod's spec.containers[*].command
& spec.containers[*].args
dev.terminal
which if set, will tell DevSpace to open a terminal by default instead of printing logs.dev.sync[*].waitInitialSync
is now true by defaultimages[*].tagsAppendRandom
& images[*].preferSyncOverRebuild
dependencies[*].name
is now required (for older config versions, the array index will be used as dependency name)dependencies[*].dev
to specify which dev config should be reused from the dependency (currently only ports
and sync
are supported)We removed the deprecated commands devspace add deployment
, devspace add image
, devspace add port
, devspace add sync
, devspace remove deployment
, devspace remove image
, devspace remove port
, devspace remove sync
, devspace status sync
and devspace update config
.
source: command
via the integrated golang shell. The advantage of this shell is that it works cross platform and you can use logical expressions such as echo 123 && echo 456
. DevSpace will use the shell if no hooks[*].args
or vars[*].args
are provided and only a hooks[*].command
or vars[*].command
is configured:vars:
- name: MY_VAR_FROM_SHELL
command: "echo value"
- name: MY_VAR_DIRECT
command: "echo"
args: ["value"]
hooks:
- command: "echo 123 && echo 456"
when:
before:
images: all
vars[*].value
that is a shortcut for using vars[*].source: none
and vars[*].default
devspace reset pods
to reset changes made by dev.replacePods
commands[*].args
that if defined will execute the command directly instead of in a golang shellimage()
and tag()
that can be used within helm deployment values or kubectl manifests can now also be used to reference an image key in images.*
or in a dependency. If naming of an image key name and the actual image collide, the image key has precedence. For exampleversion: v1beta10
images:
default:
image: myusername/devspace
deployments:
- name: quickstart
helm:
componentChart: true
values:
containers:
- image: image(default):tag(default) # <- will be replaced during deploy with myusername/devspace:xxxxx. You can also use dependency1.image1 to reference a dependency image instead
--all
/-a
for devspace purge
to purge dependencies as well (the old flag --dependencies
is now deprecated)${DEVSPACE_USER_HOME}
that holds the user's home directorydevspace init
: there are now more options to choose from how you want to initialize your devspace.yaml
. We also set dev.replacePods
with dev.terminal
now by default instead of printing logs and reloading the container process.profiles[*].patches
and dev.replacePods[*].patches
with op: replace
patches do not fail if the target path does not exist anymore and behave like a op: add
insteadprofiles[*].patches
and dev.replacePods[*].patches
with op: remove
patches do not fail if the target path does not exist anymore and do nothing insteadhooks[*].when.before.images
was triggered even though the image was not builtv1.5.2
v1.20.4
Published by FabianKramm over 3 years ago
Published by FabianKramm over 3 years ago
Published by FabianKramm over 3 years ago
docker buildx
to build images either with the local docker daemon (or minikube daemon if available) or build images directly in the kubernetes cluster with the buildkit kubernetes driver (see the devspace docs for more information). For example:images:
myBuildKitImage:
image: buildkit/local
build:
# This will enable building with build kit
buildKit: {}
myInClusterBuildKitImage:
image: buildkit/incluster
build:
buildKit:
# By default this will use the devspace target namespace to build
# within kubernetes. This will deploy a new priviledged
# deployment that acts as daemon for docker to build with.
inCluster: {}
# You can also use rootless building with buildKit
# rootless: true
# You could also use another namespace with a shared
# build deployment to have a global cache.
# namespace: shared-builder
command
, args
or commands
field of other variables. For example these variable definitions are now valid:vars:
- name: SPECIAL_NAMESPACE
command: "./script.sh"
args: ["${DEVSPACE_NAMESPACE"}]
- name: OTHER_VARIABLE
command: "${SPECIAL_NAMESPACE}"
args: ["other-args-${DEVSPACE_NAMESPACE}"]
dev.sync.arch
and dev.ports.arch
to specify the target container architecture. Currently amd64
and arm64
are supported (#1389)Invalid standard handle identifier
.dockerignore
was used even though a devspace.dockerignore
existeddocker.useCli
or docker.useBuildKit
would not target the minikube daemon correctly (#1386)devspace use profile
and devspace list profiles
would try to fill in config variablesdevspace build
for kaniko builds (#1384).devspace/
to the .dockerignore
during devspace init
(#1371)app.kubernetes.io/component
label is foundPublished by FabianKramm over 3 years ago
Published by FabianKramm over 3 years ago
Published by FabianKramm over 3 years ago
Deprecation of commands devspace add deployment
, devspace add image
, devspace add port
, devspace add sync
, devspace remove deployment
, devspace remove image
, devspace remove port
, devspace remove sync
, devspace status sync
and devspace update config
. We feel these commands are rarely used, mostly outdated in terms of config options and are an increasing maintenance burden. The commands are still available, however DevSpace will now print a warning if you use them. The commands will be removed in a future DevSpace version.
version: v1beta9
images:
default:
image: ${IMAGE}
vars:
- name: IMAGE_REPOSITORY
default: myrepository
source: none
- name: IMAGE_NAME
default: devspace
source: none
- name: IMAGE
default: ${IMAGE_REPOSITORY}/${IMAGE_NAME}
source: none
- name: NAMESPACE
default: ${DEVSPACE_NAMESPACE}
source: none
images.*.rebuildStrategy
that can either take always
or ignoreContextChanges
to specify when DevSpace should rebuild an image (#1353)--max-concurrent-builds
that limits the amount of concurrent image during devspace build
, devspace dev
, devspace render
or devspace deploy
(#1347)images.*.build.kaniko.envFrom
that allows you to specify environment variables from a config map or secret for the kaniko build pod (#1348)devspace.dockerignore
that will take precedence over a regular .dockerignore
during image build (#1356)--output
flag for devspace list vars
that accepts the values keyvalue
or json
--overwrite
flag for devspace set var
that if set to false will not overwrite the variable when found in cache--sequential-build
, --max-concurrent-builds
and --skip-push-local-kube
will now also apply to dependency buildsdevspace set var
would fail with base64 encoded stringshooks.when.after.purgeDeployments
hook (#1361)devspace update plugin
cannot update the plugin because it is the newest version (#1352)devspace list vars
will now print all resolved variables of the current applied config instead of only all cached variablesPublished by FabianKramm over 3 years ago
Published by FabianKramm over 3 years ago
devspace enter
would hang in certain proxy scenariosPublished by FabianKramm over 3 years ago
devspace enter
would hang in certain proxy scenariosPublished by FabianKramm over 3 years ago
wait
that will wait for containers or pods to be running before continuing with the pipeline. This can be useful if you want to ensure a certain pod is running before you continue with the pipeline, like a database. For more information please take a look at the docs. An example configuration could look like this:...
deployments:
- name: my-database
helm:
componentChart: true
values:
...
hooks:
# This hook will ensure that everytime the deployment
# my-database is deployed DevSpace will wait until
# all pods and containers that match the labelSelector
# app.kubernetes.io/component=my-database are running
- wait:
# DevSpace will wait for all containers that match the label selector below to become running.
# If there are init containers, make sure to set terminatedWithCode as well.
running: true
# This can be needed if there are for example init containers
# that terminate instead of become running.
terminatedWithCode: 0
where:
container:
labelSelector:
app.kubernetes.io/component: my-database
# You could also select just a specific container with
# containerName: database-container
when:
after:
deployments: my-database
...
logs
that can print logs of a selected container. This can be useful to print logs of jobs or print the logs of init containers that would not be printed otherwise during devspace dev
. For more information, check out the docs.--wait
to devspace logs
that waits for pods to become running before printing the logs--inactivity-timeout
that will exit DevSpace automatically if the user is idle for the given amount of time (#1313)Published by FabianKramm over 3 years ago
wait
that will wait for containers or pods to be running before continuing with the pipeline. This can be useful if you want to ensure a certain pod is running before you continue with the pipeline, like a database. For more information please take a look at the docs. An example configuration could look like this:...
deployments:
- name: my-database
helm:
componentChart: true
values:
...
hooks:
# This hook will ensure that everytime the deployment
# my-database is deployed DevSpace will wait until
# all pods and containers that match the labelSelector
# app.kubernetes.io/component=my-database are running
- wait:
# DevSpace will wait for all containers that match the label selector below to become running.
# If there are init containers, make sure to set terminatedWithCode as well.
running: true
# This can be needed if there are for example init containers
# that terminate instead of become running.
terminatedWithCode: 0
where:
container:
labelSelector:
app.kubernetes.io/component: my-database
# You could also select just a specific container with
# containerName: database-container
when:
after:
deployments: my-database
...
logs
that can print logs of a selected container. This can be useful to print logs of jobs or print the logs of init containers that would not be printed otherwise during devspace dev
. For more information, check out the docs.--wait
to devspace logs
that waits for pods to become running before printing the logs--inactivity-timeout
that will exit DevSpace automatically if the user is idle for the given amount of time (#1313)Published by FabianKramm over 3 years ago
Unfortunately DevSpace version v5.8.2
has a small bug where devspace upgrade
will sometimes run into a nil pointer panic. In order to upgrade from v5.8.2
to v5.8.4
, please run instead:
# Only needed if you have version v5.8.2
devspace upgrade --version v5.8.4
devspace upgrade
would lead to a nil pointer exceptionPublished by FabianKramm over 3 years ago
devspace upgrade
would lead to a nil pointer exceptionPublished by FabianKramm over 3 years ago
Published by FabianKramm over 3 years ago
devspace list deployments
, devspace list profiles
etc. (#1327)--version
flag for devspace upgrade
to select a specific devspace version (including alpha and beta versions) (#1330)DEVSPACE_DISABLE_VARS_ENCRYPTION
that will disable automatic config variable encryption if set to true
(#1326)Published by FabianKramm over 3 years ago
Published by FabianKramm over 3 years ago
.devspace/generated.yaml
with a private keydevspace init
now allows you to use an image registry even though you are not authenticated to it--save-vars
was specified and the target namespace was not foundPublished by FabianKramm over 3 years ago
Published by FabianKramm over 3 years ago
images.*.build.custom.skipImageArg
to prevent devspace from adding an argument to the custom command with the image name and tagimages.*.build.custom.imageTagOnly
to add only the image tag instead of the full image name with tag as argument to the custom command (my-image-repo.com/repo/image:my-tag
will just become my-tag
)images.*.build.custom.commands
to change the base command depending on the operating system. For example:images:
default:
image: test
tags:
- my-tag
build:
custom:
# Use this command as fall back
command: './scripts/my-bash-build-script.sh'
# Use a special base command for windows
commands:
- command: './scripts/my-powershell-build-script.ps'
os: windows
# DevSpace will then build on windows with:
# ./scripts/my-powershell-build-script.ps test:my-tag
# And on any other operating system with:
# ./scripts/my-bash-build-script.sh test:my-tag
.devspace/logs/ui.log
)