diff --git a/README.md b/README.md index 9fbd186d2e..eea5a7ce2d 100644 --- a/README.md +++ b/README.md @@ -9,7 +9,7 @@ ![Total Downloads (GitHub Releases)](https://img.shields.io/github/downloads/devspace-cloud/devspace/total?style=for-the-badge&label=Total%20Downloads&color=%23007ec6) ![NPM Installs per Month](https://img.shields.io/npm/dm/devspace?label=NPM%20Installs&style=for-the-badge&color=%23007ec6) -[![Join us on Slack!](static/img/slack.svg)](https://kubernetes.slack.com/?redir=%2Fmessages%2Fdevspace#/) +[![Join us on Slack!](static/img/slack.svg)](https://slack.k8s.io/#devspace) ### Client-Only Developer Tool for Cloud-Native Development with Kubernetes - **Build, test and debug applications directly inside Kubernetes** @@ -1198,7 +1198,7 @@ docker run --net=host --ipc=host --uts=host --pid=host -it --security-opt=seccom Help us make DevSpace the best tool for developing, deploying and debugging Kubernetes apps. -[![Join us on Slack!](static/img/slack.svg)](https://kubernetes.slack.com/?redir=%2Fmessages%2Fdevspace#/) +[![Join us on Slack!](static/img/slack.svg)](https://slack.k8s.io/#devspace) ### Reporting Issues diff --git a/docs/README.md b/docs/README.md index 89e067933b..9e59d0287a 100644 --- a/docs/README.md +++ b/docs/README.md @@ -37,7 +37,7 @@ If you are using GitHub pages for hosting, this command is a convenient way to b ## Creating New Versions -### 1. Generate Command Docs +### 1. Generate Command Docs ```bash cd ../ # main project directory go run -mod= ./hack/gen-docs.go @@ -45,6 +45,5 @@ go run -mod= ./hack/gen-docs.go ### 2. Create Version ```bash -cd website yarn run docusaurus docs:version 4.5 ``` diff --git a/docs/docusaurus.config.js b/docs/docusaurus.config.js index 64c70e8838..142bfd925e 100644 --- a/docs/docusaurus.config.js +++ b/docs/docusaurus.config.js @@ -33,9 +33,10 @@ module.exports = { target: '_self' }, { - to: 'docs/introduction', + href: __webpack_public_path__ + 'docs/' + (process.env.NODE_ENV == 'production' ? '' : 'next/') + 'introduction', label: 'Docs', - position: 'left' + position: 'left', + target: '_self' }, { href: 'https://devspace.cloud/blog', @@ -43,7 +44,7 @@ module.exports = { position: 'left' }, { - href: 'https://kubernetes.slack.com/?redir=%2Fmessages%2Fdevspace#/', + href: 'https://slack.k8s.io/#devspace', className: 'slack-link', 'aria-label': 'Slack', position: 'right', diff --git a/docs/versioned_docs/version-4.13/commands/devspace.md b/docs/versioned_docs/version-4.13/commands/devspace.md new file mode 100644 index 0000000000..19f3c5f431 --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace.md @@ -0,0 +1,37 @@ +--- +title: "Command - devspace" +sidebar_label: devspace +--- + +## devspace + +Welcome to the DevSpace! + +### Synopsis + +DevSpace accelerates developing, deploying and debugging applications with Docker and Kubernetes. Get started by running the init command in one of your projects: + + devspace init + +### Options + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + -h, --help help for devspace + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + +``` + +``` + + +## Flags +## Global & Inherited Flags \ No newline at end of file diff --git a/docs/versioned_docs/version-4.13/commands/devspace_add.md b/docs/versioned_docs/version-4.13/commands/devspace_add.md new file mode 100644 index 0000000000..3daf350c4e --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_add.md @@ -0,0 +1,40 @@ +--- +title: "Command - devspace add" +sidebar_label: devspace add +--- + + +Convenience command: adds something to devspace.yaml + +## Synopsis + + +``` +####################################################### +#################### devspace add ##################### +####################################################### +Adds config sections to devspace.yaml +``` + + +## Flags + +``` + -h, --help help for add +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_add_deployment.md b/docs/versioned_docs/version-4.13/commands/devspace_add_deployment.md new file mode 100644 index 0000000000..c26faa76a5 --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_add_deployment.md @@ -0,0 +1,69 @@ +--- +title: "Command - devspace add deployment" +sidebar_label: devspace add deployment +--- + + +Adds a deployment to devspace.yaml + +## Synopsis + + +``` +devspace add deployment [deployment-name] [flags] +``` + +``` +####################################################### +############# devspace add deployment ################# +####################################################### +Adds a new deployment to this project's devspace.yaml + +Examples: +# Deploy a predefined component +devspace add deployment my-deployment --component=mysql +# Deploy a local dockerfile +devspace add deployment my-deployment --dockerfile=./Dockerfile +devspace add deployment my-deployment --image=myregistry.io/myuser/myrepo --dockerfile=frontend/Dockerfile --context=frontend/Dockerfile +# Deploy an existing docker image +devspace add deployment my-deployment --image=mysql +devspace add deployment my-deployment --image=myregistry.io/myusername/mysql +# Deploy local or remote helm charts +devspace add deployment my-deployment --chart=chart/ +devspace add deployment my-deployment --chart=stable/mysql +# Deploy local kubernetes yamls +devspace add deployment my-deployment --manifests=kube/pod.yaml +devspace add deployment my-deployment --manifests=kube/* --namespace=devspace +####################################################### +``` + + +## Flags + +``` + --chart string A helm chart to deploy (e.g. ./chart or stable/mysql) + --chart-repo string The helm chart repository url to use + --chart-version string The helm chart version to use + --component devspace list available-components A predefined component to use (run devspace list available-components to see all available components) + --context string + --dockerfile string A dockerfile + -h, --help help for deployment + --image string A docker image to deploy (e.g. dscr.io/myuser/myrepo or dockeruser/repo:0.1 or mysql:latest) + --manifests string The kubernetes manifests to deploy (glob pattern are allowed, comma separated, e.g. manifests/** or kube/pod.yaml) +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_add_image.md b/docs/versioned_docs/version-4.13/commands/devspace_add_image.md new file mode 100644 index 0000000000..c5cb33fd7e --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_add_image.md @@ -0,0 +1,58 @@ +--- +title: "Command - devspace add image" +sidebar_label: devspace add image +--- + + +Add an image + +## Synopsis + + +``` +devspace add image [flags] +``` + +``` +####################################################### +############# devspace add image ###################### +####################################################### +Adds a new image to this project's devspace.yaml + +Examples: +devspace add image my-image --image=dockeruser/devspaceimage2 +devspace add image my-image --image=dockeruser/devspaceimage2 --tag=alpine +devspace add image my-image --image=dockeruser/devspaceimage2 --context=./context +devspace add image my-image --image=dockeruser/devspaceimage2 --dockerfile=./Dockerfile +devspace add image my-image --image=dockeruser/devspaceimage2 --buildtool=docker +devspace add image my-image --image=dockeruser/devspaceimage2 --buildtool=kaniko +####################################################### +``` + + +## Flags + +``` + --buildtool string Specify which engine should build the file. Should match this regex: docker|kaniko + --context string The path of the images' context + --dockerfile string The path of the images' dockerfile + -h, --help help for image + --image string The image name of the image (e.g. myusername/devspace) + --tag string The tag of the image +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_add_port.md b/docs/versioned_docs/version-4.13/commands/devspace_add_port.md new file mode 100644 index 0000000000..005d787417 --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_add_port.md @@ -0,0 +1,49 @@ +--- +title: "Command - devspace add port" +sidebar_label: devspace add port +--- + + +Add a new port forward configuration + +## Synopsis + + +``` +devspace add port [flags] +``` + +``` +####################################################### +################ devspace add port #################### +####################################################### +Add a new port mapping to this project's devspace.yaml + +Format is port(:remotePort) comma separated, e.g. +devspace add port 8080:80,3000 +####################################################### +``` + + +## Flags + +``` + -h, --help help for port + --label-selector string Comma separated key=value label-selector list (e.g. release=test) +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_add_provider.md b/docs/versioned_docs/version-4.13/commands/devspace_add_provider.md new file mode 100644 index 0000000000..8151355157 --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_add_provider.md @@ -0,0 +1,49 @@ +--- +title: "Command - devspace add provider" +sidebar_label: devspace add provider +--- + + +Adds a new cloud provider to the configuration + +## Synopsis + + +``` +devspace add provider [flags] +``` + +``` +####################################################### +############## devspace add provider ################## +####################################################### +Add a new cloud provider. + +Example: +devspace add provider app.devspace.cloud +####################################################### +``` + + +## Flags + +``` + -h, --help help for provider + --host string The URL DevSpace should use for this provider +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_add_sync.md b/docs/versioned_docs/version-4.13/commands/devspace_add_sync.md new file mode 100644 index 0000000000..d526b2140e --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_add_sync.md @@ -0,0 +1,52 @@ +--- +title: "Command - devspace add sync" +sidebar_label: devspace add sync +--- + + +Add a sync path + +## Synopsis + + +``` +devspace add sync [flags] +``` + +``` +####################################################### +################# devspace add sync ################### +####################################################### +Add a sync path to this project's devspace.yaml + +Example: +devspace add sync --local=app --container=/app +####################################################### +``` + + +## Flags + +``` + --container string Absolute container path + --exclude string Comma separated list of paths to exclude (e.g. node_modules/,bin,*.exe) + -h, --help help for sync + --label-selector string Comma separated key=value selector list (e.g. release=test) + --local string Relative local path +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_analyze.md b/docs/versioned_docs/version-4.13/commands/devspace_analyze.md new file mode 100644 index 0000000000..429d2a69d1 --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_analyze.md @@ -0,0 +1,53 @@ +--- +title: "Command - devspace analyze" +sidebar_label: devspace analyze +--- + + +Analyzes a kubernetes namespace and checks for potential problems + +## Synopsis + + +``` +devspace analyze [flags] +``` + +``` +####################################################### +################## devspace analyze ################### +####################################################### +Analyze checks a namespaces events, replicasets, services +and pods for potential problems + +Example: +devspace analyze +devspace analyze --namespace=mynamespace +####################################################### +``` + + +## Flags + +``` + -h, --help help for analyze + --patient If true, analyze will ignore failing pods and events until every deployment, statefulset, replicaset and pods are ready or the timeout is reached + --timeout int Timeout until analyze should stop waiting (default 120) + --wait Wait for pods to get ready if they are just starting (default true) +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_attach.md b/docs/versioned_docs/version-4.13/commands/devspace_attach.md new file mode 100644 index 0000000000..07ce380f78 --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_attach.md @@ -0,0 +1,55 @@ +--- +title: "Command - devspace attach" +sidebar_label: devspace attach +--- + + +Attaches to a container + +## Synopsis + + +``` +devspace attach [flags] +``` + +``` +####################################################### +################# devspace attach ##################### +####################################################### +Attaches to a running container + +devspace attach +devspace attach --pick # Select pod to enter +devspace attach -c my-container +devspace attach -n my-namespace +####################################################### +``` + + +## Flags + +``` + -c, --container string Container name within pod where to execute command + -h, --help help for attach + --image string Image is the config name of an image to select in the devspace config (e.g. 'default'), it is NOT a docker image like myuser/myimage + -l, --label-selector string Comma separated key=value selector list (e.g. release=test) + --pick Select a pod + --pod string Pod to open a shell to +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_build.md b/docs/versioned_docs/version-4.13/commands/devspace_build.md new file mode 100644 index 0000000000..509e2dd403 --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_build.md @@ -0,0 +1,53 @@ +--- +title: "Command - devspace build" +sidebar_label: devspace build +--- + + +Builds all defined images and pushes them + +## Synopsis + + +``` +devspace build [flags] +``` + +``` +####################################################### +################## devspace build ##################### +####################################################### +Builds all defined images and pushes them +####################################################### +``` + + +## Flags + +``` + --allow-cyclic When enabled allows cyclic dependencies + --build-sequential Builds the images one after another instead of in parallel + --dependency strings Builds only the specific named dependencies + -b, --force-build Forces to build every image + --force-dependencies Forces to re-evaluate dependencies (use with --force-build --force-deploy to actually force building & deployment of dependencies) (default true) + -h, --help help for build + --skip-push Skips image pushing, useful for minikube deployment + -t, --tag strings Use the given tag for all built images + --verbose-dependencies Builds the dependencies verbosely +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_cleanup.md b/docs/versioned_docs/version-4.13/commands/devspace_cleanup.md new file mode 100644 index 0000000000..1170adb63c --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_cleanup.md @@ -0,0 +1,39 @@ +--- +title: "Command - devspace cleanup" +sidebar_label: devspace cleanup +--- + + +Cleans up resources + +## Synopsis + + +``` +####################################################### +################## devspace cleanup ################### +####################################################### +``` + + +## Flags + +``` + -h, --help help for cleanup +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_cleanup_images.md b/docs/versioned_docs/version-4.13/commands/devspace_cleanup_images.md new file mode 100644 index 0000000000..b50bbb1cdb --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_cleanup_images.md @@ -0,0 +1,45 @@ +--- +title: "Command - devspace cleanup images" +sidebar_label: devspace cleanup images +--- + + +Deletes all locally created images from docker + +## Synopsis + + +``` +devspace cleanup images [flags] +``` + +``` +####################################################### +############# devspace cleanup images ################# +####################################################### +Deletes all locally created docker images from docker +####################################################### +``` + + +## Flags + +``` + -h, --help help for images +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_connect.md b/docs/versioned_docs/version-4.13/commands/devspace_connect.md new file mode 100644 index 0000000000..319b0c5247 --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_connect.md @@ -0,0 +1,39 @@ +--- +title: "Command - devspace connect" +sidebar_label: devspace connect +--- + + +Connect an external cluster to devspace cloud + +## Synopsis + + +``` +####################################################### +################# devspace connect #################### +####################################################### +``` + + +## Flags + +``` + -h, --help help for connect +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_connect_cluster.md b/docs/versioned_docs/version-4.13/commands/devspace_connect_cluster.md new file mode 100644 index 0000000000..0f241f7588 --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_connect_cluster.md @@ -0,0 +1,62 @@ +--- +title: "Command - devspace connect cluster" +sidebar_label: devspace connect cluster +--- + + +Connects an existing cluster to DevSpace Cloud + +## Synopsis + + +``` +devspace connect cluster [flags] +``` + +``` +####################################################### +############ devspace connect cluster ################# +####################################################### +Connects an existing cluster to DevSpace Cloud. + +Examples: +devspace connect cluster +####################################################### +``` + + +## Flags + +``` + --admission-controller Deploy the admission controller (default true) + --cert-manager Deploy a cert manager (default true) + --context string The kube context to use + --domain string The domain to use + --gatekeeper Deploy the gatekeeper + --gatekeeper-rules Deploy the gatekeeper default rules + -h, --help help for cluster + --ingress-controller Deploy an ingress controller (default true) + --key string The encryption key to use + --name string The cluster name to create + --open-ui Opens the UI and displays the cluster overview + --provider string The cloud provider to use + --public Connects a new public cluster + --use-domain Use an automatic domain for the cluster + --use-hostnetwork Use the host network for the ingress controller instead of a loadbalancer +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_create.md b/docs/versioned_docs/version-4.13/commands/devspace_create.md new file mode 100644 index 0000000000..44e09af13d --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_create.md @@ -0,0 +1,39 @@ +--- +title: "Command - devspace create" +sidebar_label: devspace create +--- + + +Create spaces in the cloud + +## Synopsis + + +``` +####################################################### +################## devspace create #################### +####################################################### +``` + + +## Flags + +``` + -h, --help help for create +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_create_space.md b/docs/versioned_docs/version-4.13/commands/devspace_create_space.md new file mode 100644 index 0000000000..8353bdebbb --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_create_space.md @@ -0,0 +1,51 @@ +--- +title: "Command - devspace create space" +sidebar_label: devspace create space +--- + + +Create a new cloud space + +## Synopsis + + +``` +devspace create space [flags] +``` + +``` +####################################################### +############### devspace create space ################# +####################################################### +Creates a new space + +Example: +devspace create space myspace +####################################################### +``` + + +## Flags + +``` + --active Use the new Space as active Space for the current project (default true) + --cluster string The cluster to create a space in + -h, --help help for space + --provider string The cloud provider to use +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_deploy.md b/docs/versioned_docs/version-4.13/commands/devspace_deploy.md new file mode 100644 index 0000000000..cb74ac7cc6 --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_deploy.md @@ -0,0 +1,61 @@ +--- +title: "Command - devspace deploy" +sidebar_label: devspace deploy +--- + + +Deploy the project + +## Synopsis + + +``` +devspace deploy [flags] +``` + +``` +####################################################### +################## devspace deploy #################### +####################################################### +Deploys the current project to a Space or namespace: + +devspace deploy +devspace deploy -n some-namespace +devspace deploy --kube-context=deploy-context +####################################################### +``` + + +## Flags + +``` + --allow-cyclic When enabled allows cyclic dependencies + --build-sequential Builds the images one after another instead of in parallel + --dependency strings Deploys only the specific named dependencies + --deployments string Only deploy a specifc deployment (You can specify multiple deployments comma-separated + -b, --force-build Forces to (re-)build every image + --force-dependencies Forces to re-evaluate dependencies (use with --force-build --force-deploy to actually force building & deployment of dependencies) (default true) + -d, --force-deploy Forces to (re-)deploy every deployment + -h, --help help for deploy + --skip-build Skips building of images + --skip-push Skips image pushing, useful for minikube deployment + --timeout int Timeout until deploy should stop waiting (default 120) + --verbose-dependencies Deploys the dependencies verbosely + --wait If true will wait for pods to be running or fails after given timeout +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_dev.md b/docs/versioned_docs/version-4.13/commands/devspace_dev.md new file mode 100644 index 0000000000..7fa89dae87 --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_dev.md @@ -0,0 +1,74 @@ +--- +title: "Command - devspace dev" +sidebar_label: devspace dev +--- + + +Starts the development mode + +## Synopsis + + +``` +devspace dev [flags] +``` + +``` +####################################################### +################### devspace dev ###################### +####################################################### +Starts your project in development mode: +1. Builds your Docker images and override entrypoints if specified +2. Deploys the deployments via helm or kubectl +3. Forwards container ports to the local computer +4. Starts the sync client +5. Streams the logs of deployed containers + +Open terminal instead of logs: +- Use "devspace dev -t" for opening a terminal +- Use "devspace dev -i" for opening a terminal and overriding container entrypoint with sleep command +####################################################### +``` + + +## Flags + +``` + --allow-cyclic When enabled allows cyclic dependencies + --build-sequential Builds the images one after another instead of in parallel + --deployments string Only deploy a specifc deployment (You can specify multiple deployments comma-separated + --exit-after-deploy Exits the command after building the images and deploying the project + -b, --force-build Forces to build every image + --force-dependencies Forces to re-evaluate dependencies (use with --force-build --force-deploy to actually force building & deployment of dependencies) (default true) + -d, --force-deploy Forces to deploy every deployment + -h, --help help for dev + -i, --interactive Enable interactive mode for images (overrides entrypoint with sleep command) and start terminal proxy + --open Open defined URLs in the browser, if defined (default true) + --portforwarding Enable port forwarding (default true) + --skip-build Skips building of images + -x, --skip-pipeline Skips build & deployment and only starts sync, portforwarding & terminal + --skip-push Skips image pushing, useful for minikube deployment + --sync Enable code synchronization (default true) + -t, --terminal Open a terminal instead of showing logs + --timeout int Timeout until dev should stop waiting and fail (default 120) + --ui Start the ui server (default true) + --verbose-dependencies Deploys the dependencies verbosely + --verbose-sync When enabled the sync will log every file change + --wait If true will wait first for pods to be running or fails after given timeout +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_enter.md b/docs/versioned_docs/version-4.13/commands/devspace_enter.md new file mode 100644 index 0000000000..4e4857cc74 --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_enter.md @@ -0,0 +1,59 @@ +--- +title: "Command - devspace enter" +sidebar_label: devspace enter +--- + + +Open a shell to a container + +## Synopsis + + +``` +devspace enter [flags] +``` + +``` +####################################################### +################## devspace enter ##################### +####################################################### +Execute a command or start a new terminal in your +devspace: + +devspace enter +devspace enter --pick # Select pod to enter +devspace enter bash +devspace enter -c my-container +devspace enter bash -n my-namespace +devspace enter bash -l release=test +####################################################### +``` + + +## Flags + +``` + -c, --container string Container name within pod where to execute command + -h, --help help for enter + --image string Image is the config name of an image to select in the devspace config (e.g. 'default'), it is NOT a docker image like myuser/myimage + -l, --label-selector string Comma separated key=value selector list (e.g. release=test) + --pick Select a pod + --pod string Pod to open a shell to + --wait Wait for the pod(s) to start if they are not running +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_init.md b/docs/versioned_docs/version-4.13/commands/devspace_init.md new file mode 100644 index 0000000000..68d8b230fb --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_init.md @@ -0,0 +1,50 @@ +--- +title: "Command - devspace init" +sidebar_label: devspace init +--- + + +Initializes DevSpace in the current folder + +## Synopsis + + +``` +devspace init [flags] +``` + +``` +####################################################### +#################### devspace init #################### +####################################################### +Initializes a new devspace project within the current +folder. Creates a devspace.yaml with all configuration. +####################################################### +``` + + +## Flags + +``` + --context string Context path to use for intialization + --dockerfile string Dockerfile to use for initialization (default "./Dockerfile") + -h, --help help for init + --provider string The cloud provider to use + -r, --reconfigure Change existing configuration +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_list.md b/docs/versioned_docs/version-4.13/commands/devspace_list.md new file mode 100644 index 0000000000..96dcf1cd03 --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_list.md @@ -0,0 +1,39 @@ +--- +title: "Command - devspace list" +sidebar_label: devspace list +--- + + +Lists configuration + +## Synopsis + + +``` +####################################################### +#################### devspace list #################### +####################################################### +``` + + +## Flags + +``` + -h, --help help for list +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_list_clusters.md b/docs/versioned_docs/version-4.13/commands/devspace_list_clusters.md new file mode 100644 index 0000000000..ec65d659e1 --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_list_clusters.md @@ -0,0 +1,50 @@ +--- +title: "Command - devspace list clusters" +sidebar_label: devspace list clusters +--- + + +Lists all connected clusters + +## Synopsis + + +``` +devspace list clusters [flags] +``` + +``` +####################################################### +############## devspace list clusters ################# +####################################################### +List all connected user clusters + +Example: +devspace list clusters +####################################################### +``` + + +## Flags + +``` + --all Show all available clusters including hosted DevSpace cloud clusters + -h, --help help for clusters + --provider string Cloud Provider to use +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_list_commands.md b/docs/versioned_docs/version-4.13/commands/devspace_list_commands.md new file mode 100644 index 0000000000..fdd7fe2a24 --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_list_commands.md @@ -0,0 +1,46 @@ +--- +title: "Command - devspace list commands" +sidebar_label: devspace list commands +--- + + +Lists all custom DevSpace commands + +## Synopsis + + +``` +devspace list commands [flags] +``` + +``` +####################################################### +############## devspace list commands ################# +####################################################### +Lists all DevSpace custom commands defined in the +devspace.yaml +####################################################### +``` + + +## Flags + +``` + -h, --help help for commands +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_list_contexts.md b/docs/versioned_docs/version-4.13/commands/devspace_list_contexts.md new file mode 100644 index 0000000000..f2d060c3d5 --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_list_contexts.md @@ -0,0 +1,48 @@ +--- +title: "Command - devspace list contexts" +sidebar_label: devspace list contexts +--- + + +Lists all kube contexts + +## Synopsis + + +``` +devspace list contexts [flags] +``` + +``` +####################################################### +############## devspace list contexts ################# +####################################################### +Lists all available kube contexts + +Example: +devspace list contexts +####################################################### +``` + + +## Flags + +``` + -h, --help help for contexts +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_list_deployments.md b/docs/versioned_docs/version-4.13/commands/devspace_list_deployments.md new file mode 100644 index 0000000000..64f302b0cd --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_list_deployments.md @@ -0,0 +1,45 @@ +--- +title: "Command - devspace list deployments" +sidebar_label: devspace list deployments +--- + + +Lists and shows the status of all deployments + +## Synopsis + + +``` +devspace list deployments [flags] +``` + +``` +####################################################### +############# devspace list deployments ############### +####################################################### +Shows the status of all deployments +####################################################### +``` + + +## Flags + +``` + -h, --help help for deployments +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_list_namespaces.md b/docs/versioned_docs/version-4.13/commands/devspace_list_namespaces.md new file mode 100644 index 0000000000..478b3dad62 --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_list_namespaces.md @@ -0,0 +1,45 @@ +--- +title: "Command - devspace list namespaces" +sidebar_label: devspace list namespaces +--- + + +Lists all namespaces in the current context + +## Synopsis + + +``` +devspace list namespaces [flags] +``` + +``` +####################################################### +############ devspace list namespaces ################# +####################################################### +Lists all namespaces in the selected kube context +####################################################### +``` + + +## Flags + +``` + -h, --help help for namespaces +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_list_ports.md b/docs/versioned_docs/version-4.13/commands/devspace_list_ports.md new file mode 100644 index 0000000000..da7f61a13c --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_list_ports.md @@ -0,0 +1,45 @@ +--- +title: "Command - devspace list ports" +sidebar_label: devspace list ports +--- + + +Lists port forwarding configurations + +## Synopsis + + +``` +devspace list ports [flags] +``` + +``` +####################################################### +############### devspace list ports ################### +####################################################### +Lists the port forwarding configurations +####################################################### +``` + + +## Flags + +``` + -h, --help help for ports +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_list_profiles.md b/docs/versioned_docs/version-4.13/commands/devspace_list_profiles.md new file mode 100644 index 0000000000..9dee4c47e6 --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_list_profiles.md @@ -0,0 +1,45 @@ +--- +title: "Command - devspace list profiles" +sidebar_label: devspace list profiles +--- + + +Lists all DevSpace profiles + +## Synopsis + + +``` +devspace list profiles [flags] +``` + +``` +####################################################### +############## devspace list profiles ################# +####################################################### +Lists all DevSpace configuartions for this project +####################################################### +``` + + +## Flags + +``` + -h, --help help for profiles +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_list_providers.md b/docs/versioned_docs/version-4.13/commands/devspace_list_providers.md new file mode 100644 index 0000000000..ffa9a40991 --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_list_providers.md @@ -0,0 +1,45 @@ +--- +title: "Command - devspace list providers" +sidebar_label: devspace list providers +--- + + +Lists all providers + +## Synopsis + + +``` +devspace list providers [flags] +``` + +``` +####################################################### +############# devspace list providers ################# +####################################################### +Lists the providers that exist +####################################################### +``` + + +## Flags + +``` + -h, --help help for providers +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_list_spaces.md b/docs/versioned_docs/version-4.13/commands/devspace_list_spaces.md new file mode 100644 index 0000000000..dcc1080453 --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_list_spaces.md @@ -0,0 +1,54 @@ +--- +title: "Command - devspace list spaces" +sidebar_label: devspace list spaces +--- + + +Lists all user spaces + +## Synopsis + + +``` +devspace list spaces [flags] +``` + +``` +####################################################### +############### devspace list spaces ################## +####################################################### +List all user cloud spaces + +Example: +devspace list spaces +devspace list spaces --cluster my-cluster +devspace list spaces --all +####################################################### +``` + + +## Flags + +``` + --all List all spaces the user has access to in all clusters (not only created by the user) + --cluster string List all spaces in a certain cluster + -h, --help help for spaces + --name string Space name to show (default: all) + --provider string Cloud Provider to use +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_list_sync.md b/docs/versioned_docs/version-4.13/commands/devspace_list_sync.md new file mode 100644 index 0000000000..768ddb97a2 --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_list_sync.md @@ -0,0 +1,45 @@ +--- +title: "Command - devspace list sync" +sidebar_label: devspace list sync +--- + + +Lists sync configuration + +## Synopsis + + +``` +devspace list sync [flags] +``` + +``` +####################################################### +################# devspace list sync ################## +####################################################### +Lists the sync configuration +####################################################### +``` + + +## Flags + +``` + -h, --help help for sync +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_list_vars.md b/docs/versioned_docs/version-4.13/commands/devspace_list_vars.md new file mode 100644 index 0000000000..2bee64acfa --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_list_vars.md @@ -0,0 +1,46 @@ +--- +title: "Command - devspace list vars" +sidebar_label: devspace list vars +--- + + +Lists the vars in the active config + +## Synopsis + + +``` +devspace list vars [flags] +``` + +``` +####################################################### +############### devspace list vars #################### +####################################################### +Lists the defined vars in the devspace config with their +values +####################################################### +``` + + +## Flags + +``` + -h, --help help for vars +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_login.md b/docs/versioned_docs/version-4.13/commands/devspace_login.md new file mode 100644 index 0000000000..feed05401b --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_login.md @@ -0,0 +1,52 @@ +--- +title: "Command - devspace login" +sidebar_label: devspace login +--- + + +Log into DevSpace Cloud + +## Synopsis + + +``` +devspace login [flags] +``` + +``` +####################################################### +################### devspace login #################### +####################################################### +If no --key is supplied the browser will be opened +and the login page is shown + +Example: +devspace login +devspace login --key myaccesskey +####################################################### +``` + + +## Flags + +``` + -h, --help help for login + --key string Access key to use + --provider string Provider to use +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_logs.md b/docs/versioned_docs/version-4.13/commands/devspace_logs.md new file mode 100644 index 0000000000..b2f39878df --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_logs.md @@ -0,0 +1,57 @@ +--- +title: "Command - devspace logs" +sidebar_label: devspace logs +--- + + +Prints the logs of a pod and attaches to it + +## Synopsis + + +``` +devspace logs [flags] +``` + +``` +####################################################### +#################### devspace logs #################### +####################################################### +Logs prints the last log of a pod container and attachs +to it + +Example: +devspace logs +devspace logs --namespace=mynamespace +####################################################### +``` + + +## Flags + +``` + -c, --container string Container name within pod where to execute command + -f, --follow Attach to logs afterwards + -h, --help help for logs + --image string Image is the config name of an image to select in the devspace config (e.g. 'default'), it is NOT a docker image like myuser/myimage + -l, --label-selector string Comma separated key=value selector list (e.g. release=test) + --lines int Max amount of lines to print from the last log (default 200) + --pick Select a pod + --pod string Pod to print the logs of +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_open.md b/docs/versioned_docs/version-4.13/commands/devspace_open.md new file mode 100644 index 0000000000..bf95e0e21d --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_open.md @@ -0,0 +1,49 @@ +--- +title: "Command - devspace open" +sidebar_label: devspace open +--- + + +Opens the space in the browser + +## Synopsis + + +``` +devspace open [flags] +``` + +``` +####################################################### +#################### devspace open #################### +####################################################### +Opens the space domain in the browser + +Example: +devspace open +####################################################### +``` + + +## Flags + +``` + -h, --help help for open + --provider string The cloud provider to use +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_print.md b/docs/versioned_docs/version-4.13/commands/devspace_print.md new file mode 100644 index 0000000000..de19f3c0ec --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_print.md @@ -0,0 +1,47 @@ +--- +title: "Command - devspace print" +sidebar_label: devspace print +--- + + +Print displays the configuration + +## Synopsis + + +``` +devspace print [flags] +``` + +``` +####################################################### +################## devspace print ##################### +####################################################### +Prints the configuration for the current or given +profile after all patching and variable substitution +####################################################### +``` + + +## Flags + +``` + -h, --help help for print + --skip-info When enabled, only prints the configuration without additional information +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_purge.md b/docs/versioned_docs/version-4.13/commands/devspace_purge.md new file mode 100644 index 0000000000..1d3d3d4bbc --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_purge.md @@ -0,0 +1,54 @@ +--- +title: "Command - devspace purge" +sidebar_label: devspace purge +--- + + +Delete deployed resources + +## Synopsis + + +``` +devspace purge [flags] +``` + +``` +####################################################### +################### devspace purge #################### +####################################################### +Deletes the deployed kuberenetes resources: + +devspace purge +devspace purge --dependencies +devspace purge -d my-deployment +####################################################### +``` + + +## Flags + +``` + --allow-cyclic When enabled allows cyclic dependencies + --dependencies When enabled purges the dependencies as well + --dependency strings Purges only the specific named dependencies + -d, --deployments string The deployment to delete (You can specify multiple deployments comma-separated, e.g. devspace-default,devspace-database etc.) + -h, --help help for purge + --verbose-dependencies Builds the dependencies verbosely +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_remove.md b/docs/versioned_docs/version-4.13/commands/devspace_remove.md new file mode 100644 index 0000000000..fdb71d3679 --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_remove.md @@ -0,0 +1,39 @@ +--- +title: "Command - devspace remove" +sidebar_label: devspace remove +--- + + +Changes devspace configuration + +## Synopsis + + +``` +####################################################### +################## devspace remove #################### +####################################################### +``` + + +## Flags + +``` + -h, --help help for remove +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_remove_cluster.md b/docs/versioned_docs/version-4.13/commands/devspace_remove_cluster.md new file mode 100644 index 0000000000..d4b504b1ce --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_remove_cluster.md @@ -0,0 +1,50 @@ +--- +title: "Command - devspace remove cluster" +sidebar_label: devspace remove cluster +--- + + +Removes a connected cluster + +## Synopsis + + +``` +devspace remove cluster [flags] +``` + +``` +####################################################### +############# devspace remove cluster ################# +####################################################### +Removes a connected cluster + +Example: +devspace remove cluster my-cluster +####################################################### +``` + + +## Flags + +``` + -h, --help help for cluster + --provider string The cloud provider to use + -y, --yes Ignores all questions and deletes the cluster with all services and spaces +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_remove_context.md b/docs/versioned_docs/version-4.13/commands/devspace_remove_context.md new file mode 100644 index 0000000000..047b1bb014 --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_remove_context.md @@ -0,0 +1,51 @@ +--- +title: "Command - devspace remove context" +sidebar_label: devspace remove context +--- + + +Removes a kubectl-context + +## Synopsis + + +``` +devspace remove context [flags] +``` + +``` +####################################################### +############# devspace remove context ################# +####################################################### +Removes a kubectl-context + +Example: +devspace remove context myspace +devspace remove context --all-spaces +####################################################### +``` + + +## Flags + +``` + --all-spaces Remove all kubectl contexts belonging to Spaces + -h, --help help for context + --provider string The cloud provider to use +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_remove_deployment.md b/docs/versioned_docs/version-4.13/commands/devspace_remove_deployment.md new file mode 100644 index 0000000000..5d70b4a24b --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_remove_deployment.md @@ -0,0 +1,51 @@ +--- +title: "Command - devspace remove deployment" +sidebar_label: devspace remove deployment +--- + + +Removes one or all deployments from devspace configuration + +## Synopsis + + +``` +devspace remove deployment [deployment-name] [flags] +``` + +``` +####################################################### +############ devspace remove deployment ############### +####################################################### +Removes one or all deployments from the devspace +configuration (If you want to delete the deployed +resources, run 'devspace purge -d deployment_name'): + +devspace remove deployment devspace-default +devspace remove deployment --all +####################################################### +``` + + +## Flags + +``` + --all Remove all deployments + -h, --help help for deployment +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_remove_image.md b/docs/versioned_docs/version-4.13/commands/devspace_remove_image.md new file mode 100644 index 0000000000..de12e26816 --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_remove_image.md @@ -0,0 +1,48 @@ +--- +title: "Command - devspace remove image" +sidebar_label: devspace remove image +--- + + +Removes one or all images from the devspace + +## Synopsis + + +``` +devspace remove image [flags] +``` + +``` +####################################################### +############ devspace remove image #################### +####################################################### +Removes one or all images from a devspace: +devspace remove image default +devspace remove image --all +####################################################### +``` + + +## Flags + +``` + --all Remove all images + -h, --help help for image +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_remove_port.md b/docs/versioned_docs/version-4.13/commands/devspace_remove_port.md new file mode 100644 index 0000000000..b52b8d1a25 --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_remove_port.md @@ -0,0 +1,50 @@ +--- +title: "Command - devspace remove port" +sidebar_label: devspace remove port +--- + + +Removes forwarded ports from a devspace + +## Synopsis + + +``` +devspace remove port [flags] +``` + +``` +####################################################### +############### devspace remove port ################## +####################################################### +Removes port mappings from the devspace configuration: +devspace remove port 8080,3000 +devspace remove port --label-selector=release=test +devspace remove port --all +####################################################### +``` + + +## Flags + +``` + --all Remove all configured ports + -h, --help help for port + --label-selector string Comma separated key=value selector list (e.g. release=test) +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_remove_provider.md b/docs/versioned_docs/version-4.13/commands/devspace_remove_provider.md new file mode 100644 index 0000000000..45fd0b6170 --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_remove_provider.md @@ -0,0 +1,49 @@ +--- +title: "Command - devspace remove provider" +sidebar_label: devspace remove provider +--- + + +Removes a cloud provider from the configuration + +## Synopsis + + +``` +devspace remove provider [flags] +``` + +``` +####################################################### +############ devspace remove provider ################# +####################################################### +Removes a cloud provider. + +Example: +devspace remove provider app.devspace.cloud +####################################################### +``` + + +## Flags + +``` + -h, --help help for provider + --name string Cloud provider name to use +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_remove_space.md b/docs/versioned_docs/version-4.13/commands/devspace_remove_space.md new file mode 100644 index 0000000000..8ba3fd9f4a --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_remove_space.md @@ -0,0 +1,53 @@ +--- +title: "Command - devspace remove space" +sidebar_label: devspace remove space +--- + + +Removes a cloud space + +## Synopsis + + +``` +devspace remove space [flags] +``` + +``` +####################################################### +############## devspace remove space ################## +####################################################### +Removes a cloud space. + +Example: +devspace remove space myspace +devspace remove space --id=1 +devspace remove space --all +####################################################### +``` + + +## Flags + +``` + --all Delete all spaces + -h, --help help for space + --id string SpaceID id to use + --provider string Cloud Provider to use +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_remove_sync.md b/docs/versioned_docs/version-4.13/commands/devspace_remove_sync.md new file mode 100644 index 0000000000..8d60203b1d --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_remove_sync.md @@ -0,0 +1,55 @@ +--- +title: "Command - devspace remove sync" +sidebar_label: devspace remove sync +--- + + +Remove sync paths from the devspace + +## Synopsis + + +``` +devspace remove sync [flags] +``` + +``` +####################################################### +############### devspace remove sync ################## +####################################################### +Remove sync paths from the devspace + +How to use: +devspace remove sync --local=app +devspace remove sync --container=/app +devspace remove sync --label-selector=release=test +devspace remove sync --all +####################################################### +``` + + +## Flags + +``` + --all Remove all configured sync paths + --container string Absolute container path to remove + -h, --help help for sync + --label-selector string Comma separated key=value selector list (e.g. release=test) + --local string Relative local path to remove +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_render.md b/docs/versioned_docs/version-4.13/commands/devspace_render.md new file mode 100644 index 0000000000..9d9d2c8ec9 --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_render.md @@ -0,0 +1,58 @@ +--- +title: "Command - devspace render" +sidebar_label: devspace render +--- + + +Render builds all defined images and shows the yamls that would be deployed + +## Synopsis + + +``` +devspace render [flags] +``` + +``` +####################################################### +################## devspace render ##################### +####################################################### +Builds all defined images and shows the yamls that would +be deployed via helm and kubectl, but skips actual +deployment. +####################################################### +``` + + +## Flags + +``` + --allow-cyclic When enabled allows cyclic dependencies + --build-sequential Builds the images one after another instead of in parallel + --dependency strings Renders only the specific named dependencies + --deployments string Only deploy a specifc deployment (You can specify multiple deployments comma-separated + -b, --force-build Forces to build every image + -h, --help help for render + --show-logs Shows the build logs + --skip-build Skips image building + --skip-dependencies Skips rendering the dependencies + --skip-push Skips image pushing, useful for minikube deployment + -t, --tag strings Use the given tag for all built images + --verbose-dependencies Builds the dependencies verbosely +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_reset.md b/docs/versioned_docs/version-4.13/commands/devspace_reset.md new file mode 100644 index 0000000000..a30507147f --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_reset.md @@ -0,0 +1,39 @@ +--- +title: "Command - devspace reset" +sidebar_label: devspace reset +--- + + +Resets an cluster token + +## Synopsis + + +``` +####################################################### +################## devspace reset ##################### +####################################################### +``` + + +## Flags + +``` + -h, --help help for reset +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_reset_dependencies.md b/docs/versioned_docs/version-4.13/commands/devspace_reset_dependencies.md new file mode 100644 index 0000000000..d130b0529b --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_reset_dependencies.md @@ -0,0 +1,48 @@ +--- +title: "Command - devspace reset dependencies" +sidebar_label: devspace reset dependencies +--- + + +Resets the dependencies cache + +## Synopsis + + +``` +devspace reset dependencies [flags] +``` + +``` +####################################################### +############ devspace reset dependencies ############## +####################################################### +Deletes the complete dependency cache + +Examples: +devspace reset dependencies +####################################################### +``` + + +## Flags + +``` + -h, --help help for dependencies +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_reset_key.md b/docs/versioned_docs/version-4.13/commands/devspace_reset_key.md new file mode 100644 index 0000000000..b1a63388b8 --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_reset_key.md @@ -0,0 +1,50 @@ +--- +title: "Command - devspace reset key" +sidebar_label: devspace reset key +--- + + +Resets a cluster key + +## Synopsis + + +``` +devspace reset key [flags] +``` + +``` +####################################################### +############### devspace reset key #################### +####################################################### +Resets a key for a given cluster. Useful if the key +cannot be obtained anymore. Needs cluster access scope + +Examples: +devspace reset key my-cluster +####################################################### +``` + + +## Flags + +``` + -h, --help help for key + --provider string The cloud provider to use +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_reset_vars.md b/docs/versioned_docs/version-4.13/commands/devspace_reset_vars.md new file mode 100644 index 0000000000..411ce77ce6 --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_reset_vars.md @@ -0,0 +1,48 @@ +--- +title: "Command - devspace reset vars" +sidebar_label: devspace reset vars +--- + + +Resets the current config vars + +## Synopsis + + +``` +devspace reset vars [flags] +``` + +``` +####################################################### +############### devspace reset vars ################### +####################################################### +Resets the saved variables of the current config + +Examples: +devspace reset vars +####################################################### +``` + + +## Flags + +``` + -h, --help help for vars +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_run.md b/docs/versioned_docs/version-4.13/commands/devspace_run.md new file mode 100644 index 0000000000..5e6c9bce83 --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_run.md @@ -0,0 +1,51 @@ +--- +title: "Command - devspace run" +sidebar_label: devspace run +--- + + +Run executes a predefined command + +## Synopsis + + +``` +devspace run [flags] +``` + +``` +####################################################### +##################### devspace run #################### +####################################################### +Run executes a predefined command from the devspace.yaml + +Examples: +devspace run mycommand --myarg 123 +devspace run mycommand2 1 2 3 +devspace --dependency my-dependency run any-command --any-command-flag +####################################################### +``` + + +## Flags + +``` + --dependency string Run a command from a specific dependency + -h, --help help for run +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_set.md b/docs/versioned_docs/version-4.13/commands/devspace_set.md new file mode 100644 index 0000000000..608f85998b --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_set.md @@ -0,0 +1,39 @@ +--- +title: "Command - devspace set" +sidebar_label: devspace set +--- + + +Make global configuration changes + +## Synopsis + + +``` +####################################################### +#################### devspace set ##################### +####################################################### +``` + + +## Flags + +``` + -h, --help help for set +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_set_analytics.md b/docs/versioned_docs/version-4.13/commands/devspace_set_analytics.md new file mode 100644 index 0000000000..a168c2cf38 --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_set_analytics.md @@ -0,0 +1,46 @@ +--- +title: "Command - devspace set analytics" +sidebar_label: devspace set analytics +--- + + +Update analytics settings + +## Synopsis + + +``` +devspace set analytics [flags] +``` + +``` +####################################################### +############### devspace set analytics ################ +####################################################### +Example: +devspace set analytics disabled true +####################################################### +``` + + +## Flags + +``` + -h, --help help for analytics +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_set_encryptionkey.md b/docs/versioned_docs/version-4.13/commands/devspace_set_encryptionkey.md new file mode 100644 index 0000000000..a09459afba --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_set_encryptionkey.md @@ -0,0 +1,50 @@ +--- +title: "Command - devspace set encryptionkey" +sidebar_label: devspace set encryptionkey +--- + + +Sets the encryption + +## Synopsis + + +``` +devspace set encryptionkey [flags] +``` + +``` +####################################################### +############## devspace set encryptionkey ############# +####################################################### +Sets an encryption key for a given cluster + +Examples: +devspace set encryptionkey mykey --cluster mycluster +devspace set encryptionkey --cluster mycluster --reset +####################################################### +``` + + +## Flags + +``` + --cluster string The cluster to apply this key for + -h, --help help for encryptionkey +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_set_var.md b/docs/versioned_docs/version-4.13/commands/devspace_set_var.md new file mode 100644 index 0000000000..07ff807d21 --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_set_var.md @@ -0,0 +1,49 @@ +--- +title: "Command - devspace set var" +sidebar_label: devspace set var +--- + + +Sets a variable + +## Synopsis + + +``` +devspace set var [flags] +``` + +``` +####################################################### +################# devspace set var #################### +####################################################### +Sets a specific variable + +Examples: +devspace set var key=value +devspace set var key=value key2=value2 +####################################################### +``` + + +## Flags + +``` + -h, --help help for var +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_status.md b/docs/versioned_docs/version-4.13/commands/devspace_status.md new file mode 100644 index 0000000000..4e037d9a42 --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_status.md @@ -0,0 +1,39 @@ +--- +title: "Command - devspace status" +sidebar_label: devspace status +--- + + +Show the current status + +## Synopsis + + +``` +####################################################### +################## devspace status #################### +####################################################### +``` + + +## Flags + +``` + -h, --help help for status +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_status_sync.md b/docs/versioned_docs/version-4.13/commands/devspace_status_sync.md new file mode 100644 index 0000000000..846f8968ed --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_status_sync.md @@ -0,0 +1,45 @@ +--- +title: "Command - devspace status sync" +sidebar_label: devspace status sync +--- + + +Shows the sync status + +## Synopsis + + +``` +devspace status sync [flags] +``` + +``` +####################################################### +################ devspace status sync ################# +####################################################### +Shows the sync status +####################################################### +``` + + +## Flags + +``` + -h, --help help for sync +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_sync.md b/docs/versioned_docs/version-4.13/commands/devspace_sync.md new file mode 100644 index 0000000000..c01f335df8 --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_sync.md @@ -0,0 +1,65 @@ +--- +title: "Command - devspace sync" +sidebar_label: devspace sync +--- + + +Starts a bi-directional sync between the target container and the local path + +## Synopsis + + +``` +devspace sync [flags] +``` + +``` +####################################################### +################### devspace sync ##################### +####################################################### +Starts a bi-directionaly sync between the target container +and the current path: + +devspace sync +devspace sync --local-path=subfolder --container-path=/app +devspace sync --exclude=node_modules --exclude=test +devspace sync --pod=my-pod --container=my-container +devspace sync --container-path=/my-path +####################################################### +``` + + +## Flags + +``` + -c, --container string Container name within pod where to execute command + --container-path string Container path to use (Default is working directory) + --download-on-initial-sync DEPRECATED: Downloads all locally non existing remote files in the beginning (default true) + --download-only If set DevSpace will only download files + -e, --exclude strings Exclude directory from sync + -h, --help help for sync + --initial-sync string The initial sync strategy to use (mirrorLocal, mirrorRemote, preferLocal, preferRemote, preferNewest, keepAll) + -l, --label-selector string Comma separated key=value selector list (e.g. release=test) + --local-path string Local path to use (Default is current directory + --no-watch Synchronizes local and remote and then stops + --pick Select a pod + --pod string Pod to open a shell to + --upload-only If set DevSpace will only upload files + --verbose Shows every file that is synced +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_ui.md b/docs/versioned_docs/version-4.13/commands/devspace_ui.md new file mode 100644 index 0000000000..9a36d8dadf --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_ui.md @@ -0,0 +1,48 @@ +--- +title: "Command - devspace ui" +sidebar_label: devspace ui +--- + + +Opens the localhost UI in the browser + +## Synopsis + + +``` +devspace ui [flags] +``` + +``` +####################################################### +##################### devspace ui ##################### +####################################################### +Opens the localhost UI in the browser +####################################################### +``` + + +## Flags + +``` + --dev Ignore errors when downloading UI + -h, --help help for ui + --port int The port to use when opening the server + --server If enabled will force start a server (otherwise an existing UI server is searched) +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_update.md b/docs/versioned_docs/version-4.13/commands/devspace_update.md new file mode 100644 index 0000000000..0d5948b3be --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_update.md @@ -0,0 +1,39 @@ +--- +title: "Command - devspace update" +sidebar_label: devspace update +--- + + +Updates the current config + +## Synopsis + + +``` +####################################################### +################## devspace update #################### +####################################################### +``` + + +## Flags + +``` + -h, --help help for update +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_update_config.md b/docs/versioned_docs/version-4.13/commands/devspace_update_config.md new file mode 100644 index 0000000000..43cc004eca --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_update_config.md @@ -0,0 +1,48 @@ +--- +title: "Command - devspace update config" +sidebar_label: devspace update config +--- + + +Converts the active config to the current config version + +## Synopsis + + +``` +devspace update config [flags] +``` + +``` +####################################################### +############### devspace update config ################ +####################################################### +Updates the currently active config to the newest +config version + +Note: This does not upgrade the overwrite configs +####################################################### +``` + + +## Flags + +``` + -h, --help help for config +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_update_dependencies.md b/docs/versioned_docs/version-4.13/commands/devspace_update_dependencies.md new file mode 100644 index 0000000000..99b3ce8830 --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_update_dependencies.md @@ -0,0 +1,47 @@ +--- +title: "Command - devspace update dependencies" +sidebar_label: devspace update dependencies +--- + + +Updates the git repositories of the dependencies defined in the devspace.yaml + +## Synopsis + + +``` +devspace update dependencies [flags] +``` + +``` +####################################################### +############ devspace update dependencies ############# +####################################################### +Updates the git repositories of the dependencies defined +in the devspace.yaml +####################################################### +``` + + +## Flags + +``` + --allow-cyclic When enabled allows cyclic dependencies + -h, --help help for dependencies +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_upgrade.md b/docs/versioned_docs/version-4.13/commands/devspace_upgrade.md new file mode 100644 index 0000000000..84f9ab2855 --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_upgrade.md @@ -0,0 +1,45 @@ +--- +title: "Command - devspace upgrade" +sidebar_label: devspace upgrade +--- + + +Upgrade the DevSpace CLI to the newest version + +## Synopsis + + +``` +devspace upgrade [flags] +``` + +``` +####################################################### +################## devspace upgrade ################### +####################################################### +Upgrades the DevSpace CLI to the newest version +####################################################### +``` + + +## Flags + +``` + -h, --help help for upgrade +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_use.md b/docs/versioned_docs/version-4.13/commands/devspace_use.md new file mode 100644 index 0000000000..07be96a98f --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_use.md @@ -0,0 +1,39 @@ +--- +title: "Command - devspace use" +sidebar_label: devspace use +--- + + +Use specific config + +## Synopsis + + +``` +####################################################### +#################### devspace use ##################### +####################################################### +``` + + +## Flags + +``` + -h, --help help for use +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_use_context.md b/docs/versioned_docs/version-4.13/commands/devspace_use_context.md new file mode 100644 index 0000000000..e977ed941e --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_use_context.md @@ -0,0 +1,48 @@ +--- +title: "Command - devspace use context" +sidebar_label: devspace use context +--- + + +Tells DevSpace which kube context to use + +## Synopsis + + +``` +devspace use context [flags] +``` + +``` +####################################################### +############### devspace use context ################## +####################################################### +Switch the current kube context + +Example: +devspace use context my-context +####################################################### +``` + + +## Flags + +``` + -h, --help help for context +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_use_namespace.md b/docs/versioned_docs/version-4.13/commands/devspace_use_namespace.md new file mode 100644 index 0000000000..a498b4b8ba --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_use_namespace.md @@ -0,0 +1,49 @@ +--- +title: "Command - devspace use namespace" +sidebar_label: devspace use namespace +--- + + +Tells DevSpace which namespace to use + +## Synopsis + + +``` +devspace use namespace [flags] +``` + +``` +####################################################### +############## devspace use namespace ################# +####################################################### +Set the default namespace to deploy to + +Example: +devspace use namespace my-namespace +####################################################### +``` + + +## Flags + +``` + -h, --help help for namespace + --reset Resets the default namespace of the current kube-context +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_use_profile.md b/docs/versioned_docs/version-4.13/commands/devspace_use_profile.md new file mode 100644 index 0000000000..f84fb52f4e --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_use_profile.md @@ -0,0 +1,51 @@ +--- +title: "Command - devspace use profile" +sidebar_label: devspace use profile +--- + + +Use a specific DevSpace profile + +## Synopsis + + +``` +devspace use profile [flags] +``` + +``` +####################################################### +################ devspace use profile ################# +####################################################### +Use a specific DevSpace profile + +Example: +devspace use profile production +devspace use profile staging +devspace use profile --reset +####################################################### +``` + + +## Flags + +``` + -h, --help help for profile + --reset Don't use a profile anymore +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_use_provider.md b/docs/versioned_docs/version-4.13/commands/devspace_use_provider.md new file mode 100644 index 0000000000..b9ee1b9693 --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_use_provider.md @@ -0,0 +1,49 @@ +--- +title: "Command - devspace use provider" +sidebar_label: devspace use provider +--- + + +Change the default provider + +## Synopsis + + +``` +devspace use provider [flags] +``` + +``` +####################################################### +############### devspace use provider ################# +####################################################### +Use a specific cloud provider as default for future +commands + +Example: +devspace use provider my.domain.com +####################################################### +``` + + +## Flags + +``` + -h, --help help for provider +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/commands/devspace_use_space.md b/docs/versioned_docs/version-4.13/commands/devspace_use_space.md new file mode 100644 index 0000000000..41c107a5ad --- /dev/null +++ b/docs/versioned_docs/version-4.13/commands/devspace_use_space.md @@ -0,0 +1,51 @@ +--- +title: "Command - devspace use space" +sidebar_label: devspace use space +--- + + +Use an existing space for the current configuration + +## Synopsis + + +``` +devspace use space [flags] +``` + +``` +####################################################### +################ devspace use space ################### +####################################################### +Use an existing space for the current configuration + +Example: +devspace use space my-space +####################################################### +``` + + +## Flags + +``` + --get-token Prints the service token to the console + -h, --help help for space + --provider string The cloud provider to use + --space-id string The space id to use +``` + + +## Global & Inherited Flags + +``` + --config string The devspace config file to use + --debug Prints the stack trace if an error occurs + --kube-context string The kubernetes context to use + -n, --namespace string The kubernetes namespace to use + --no-warn If true does not show any warning when deploying into a different namespace or kube-context than before + -p, --profile string The devspace profile to use (if there is any) + --silent Run in silent mode and prevents any devspace log output except panics & fatals + -s, --switch-context Switches and uses the last kube context and namespace that was used to deploy the DevSpace project + --var strings Variables to override during execution (e.g. --var=MYVAR=MYVALUE) +``` + diff --git a/docs/versioned_docs/version-4.13/configuration/commands/basics.mdx b/docs/versioned_docs/version-4.13/configuration/commands/basics.mdx new file mode 100644 index 0000000000..559345a0df --- /dev/null +++ b/docs/versioned_docs/version-4.13/configuration/commands/basics.mdx @@ -0,0 +1,91 @@ +--- +title: Custom Commands +sidebar_label: commands +--- + +The idea of custom commands is that someone on a team defines a set of useful commands and stores them in the `devspace.yaml`, then commits and pushes this config to the code repository. Now, others can run these custom commands without having to remember all the details or having to read through endless pages of documentation. + +Custom commands are being shared in the `commands` section of `devspace.yaml`: +```yaml +# File: devspace.yaml +images: + default: + image: john/backend +commands: +- name: debug-backend + command: "devspace dev -i --profile=debug-backend" +profiles: +- name: debug-backend + patches: + - op: replace + path: images.default.entrypoint + value: ["npm", "run", "debug"] +``` + +:::note +Custom commands can be used for more than just running `devspace` commands, e.g. they can run any other script or command, set environment variables etc. If you are familiar with the `scripts` section of the `package.json` for Node.js, you will find that `devspace run [name]` works pretty much the same way as `npm run [name]` +::: + +The above example configuration would allow everyone to run the custom command `debug-backend` like this: +```bash +devspace run debug-backend +devspace run debug-backend --verbose-dependencies +devspace run debug-backend -- --verbose-dependencies -s +``` + +And `devspace run` would execute the following commands internally: +```bash +devspace dev -i --profile=debug-backend +devspace dev -i --profile=debug-backend --verbose-dependencies +devspace dev -i --profile=debug-backend --verbose-dependencies -s +``` + +:::note `--` End of Options Separator +The `--` between the command name and the additional flags for the command tells your terminal that the arguments and flags that follow after the `--` do not belong to `devspace run` and should not be parsed. It is not required but often helpful to use `--` when executing commands using `devspace run`. +::: + +:::info Interactive Commands +Custom commands proxy input and output streams, so you can even share interactive commands such as `devspace enter`. +::: + + +## Configuration + +### `name` +The `name` option is mandatory and expects a string with name that serves as an alias for the command provided in the `command` option. + + +### `command` +The `command` option is mandatory and expects a string with an arbitrary terminal command. + +While you can run any `devspace` command, you can also run other commands (if installed), set environment variables or use `bash` style expressions such as `&&`, `||` or `;`. To ensure that many of your team mates can run the command on any platform, it is highly recommended to keep your command expressions as simple as possible. + +:::info Cross-Platform +Write all commands in `bash` style. DevSpace is using a library to make them cross-platform executable. +::: + +### `description` +The `description` option is optional and expects a string with a description of what this command does and when it should be used. This is only used for helping other users to understand the meaning of a command and will be shown when the user runs: `devspace list commands` + + +
+ +## Useful Commands + +### `devspace list commands` +Run this command to list all custom commands that are configured: +```bash +devspace list commands +``` + + +### `devspace --dependency [x] run ...` +You can run a command defined in one of the dependencies of the current project like this: +```bash +devspace --dependency [name] run [command] [command-flags-and-args] +``` +**Note that the `--dependency` flag must be placed before the `run` command.** + +:::note Working Directory +When running a command of a dependency, DevSpace will use the root folder of the dependency as current working directory when executing the command. +::: diff --git a/docs/versioned_docs/version-4.13/configuration/dependencies/basics.mdx b/docs/versioned_docs/version-4.13/configuration/dependencies/basics.mdx new file mode 100644 index 0000000000..4e9528e034 --- /dev/null +++ b/docs/versioned_docs/version-4.13/configuration/dependencies/basics.mdx @@ -0,0 +1,89 @@ +--- +title: Dependencies +sidebar_label: "Basics" +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +DevSpace allows you to define dependencies between several software projects that have a `devspace.yaml`, e.g. across different git repositories. This makes DevSpace a great tool for building and deploying software that consists of several microservices. + +Dependencies for DevSpace projects are defined within the `dependencies` section of `devspace.yaml`. + + + + +```yaml +dependencies: +- source: + git: https://github.com/my-api-server + branch: stable +- source: + git: https://github.com/my-auth-server + revision: c967392 + profile: production +- source: + git: https://github.com/my-database-server + tag: v3.0.1 + subPath: /configuration +``` + + + + +```yaml +dependencies: +- source: + path: ./different/subproject +- source: + path: ./different/another-subproject +``` + + + + + +## Dependency Source +DevSpace is able to work with dependencies from the following sources: +- [`git` repository](../../configuration/dependencies/git-repository.mdx) as dependency that has a devspace configuration (**recommended**) +- [`path` to a local folder](../../configuration/dependencies/git-repository.mdx) that contains a dependency (path is relative to the current project's root directory) + +:::tip +Using `git` as dependency source is recommended because it makes it much easier to share the configuration with other developers on your team without forcing everyone to check out the dependencies and to place them in the same folder structure. +::: + + +## Dependency Resolution +When a DevSpace project has dependencies, DevSpace will: + +1. Resolve all dependencies in a recursive manner +2. Build a non-cyclic dependency tree +3. Choose a leave node from the dependency tree, build its images (unless skip is defined) and deploy its deployments +4. Remove the leave node from the tree and repeat step 3 until everything has been deployed + +The algorithm used by DevSpace for building and deploying dependencies ensures that all dependencies have been deployed in the correct order before the project you are calling DevSpace from will be built and deployed. + +### Redundant Dependencies +If DevSpace detects that two projects within the dependency tree define the same child-dependency (i.e. a redundant dependency), DevSpace will try to resolve this by removing the denepdency that is "higher" (i.e. found first when resolving dependencies) within the tree. + +### Circular Dependencies +If DevSpace detects two projects which define each other as dependencies (either directly or via child-dependencies), DevSpace will terminate with an error showing the problematic dependency path within the dependency tree. + +:::info +To resolve circular dependencies, DevSpace allows you to ignore dependencies of dependencies by setting `ignoreDependencies: true` for a dependency. +::: + + +## Useful Commands + +### `devspace update dependencies` +If you want to force DevSpace to update the dependencies (e.g. git fetch & pull), you can run the following command: +```bash +devspace update dependencies +``` diff --git a/docs/versioned_docs/version-4.13/configuration/dependencies/git-repository.mdx b/docs/versioned_docs/version-4.13/configuration/dependencies/git-repository.mdx new file mode 100644 index 0000000000..9205f1ed5f --- /dev/null +++ b/docs/versioned_docs/version-4.13/configuration/dependencies/git-repository.mdx @@ -0,0 +1,136 @@ +--- +title: Deploy Git-based Dependencies +sidebar_label: "source.git" +--- + +import FragmentDependencyProfile from '../../fragments/dependency-profile.mdx'; +import FragmentDependencySkipBuild from '../../fragments/dependency-skipBuild.mdx'; +import FragmentDependencyIgnoreDependencies from '../../fragments/dependency-ignoreDependencies.mdx'; +import FragmentDependencyNamespace from '../../fragments/dependency-namespace.mdx'; +import FragmentDependencyName from '../../fragments/dependency-name.mdx'; + + +## Example +```yaml +dependencies: +- source: + git: https://github.com/my-api-server + branch: stable +- source: + git: https://github.com/my-auth-server + revision: c967392 + profile: production +- source: + git: https://github.com/my-database-server + tag: v3.0.1 + subPath: /configuration +``` + +:::info Authentication +DevSpace is using the git credential store. So, if you are able to clone or pull from the specified repository, DevSpace will also be able clone or pull this repository. +::: + +## `source` + +### `source.git` +The `source.git` option expects a string with the URL of a git repository. DevSpace will use the `master` branch by default and assumes that the `devspace.yaml` is located at the root directory of the git repository. To customize this behavior, use the following, complementary config options: +- [`branch` for a different git branch](#sourcebranch) +- [`tag` for a specific git tag or release](#sourcetag) +- [`revision` for a specific git commit hash](#sourcerevision) +- [`subPath` for custom location of `devspace.yaml` within the repository](#sourcesubpath) + +:::note Caching +DevSpace will clone the git repository which is defined as a dependency and cache the project in the global cache folder (i.e. `$HOME/.devspace`). DevSpace will also pull new commits before deploying the dependency. +::: + +#### Example: Git Projects as Dependency +```yaml +dependencies: +- source: + git: https://github.com/my-api-server + branch: stable +- source: + git: https://github.com/my-auth-server + revision: c967392 +- source: + git: https://github.com/my-auth-server + tag: v3.0.1 +``` +**Explanation:** +- When you run `devspace deploy` or `devspace dev` for the first time after defining the dependencies, DevSpace will check out all git projects into the global cache folder `$HOME/.devspace`. +- Whenever you run `devspace deploy` or `devspace dev` (even the first time), DevSpace will: + - Run a `git pull` for all cached repositories. + - Load the `devspace.yaml` files of the dependency projects and resolve their dependencies respectively. + - Deploy all dependency projects according to their `devspace.yaml` files. + +### `source.branch` +The `source.branch` option expects a string stating the branch of the git repository referenced via `source.git` that should be used when deploying this dependency. + +#### Default Value For `source.branch` +```yaml +branch: master +``` + +### `source.tag` +The `source.tag` option expects a string stating a tag of the git repository referenced via `source.git` that should be used when deploying this dependency. + +### `source.revision` +The `source.revision` option expects a string stating a commit hash of the git repository referenced via `source.git` that should be used when deploying this dependency. + +### `source.subPath` +The `source.subPath` option expects a string stating a folder within the git repository referenced via `source.git` that contains the `devspace.yaml` for this dependency. + +#### Default Value For `source.subPath` +```yaml +subPath: / +``` + + +## Git Options + +### `source.disableShallow` +The `source.disableShallow` option expects a boolean that prevents DevSpace from using shallow clones (git flag `--depth 1`) when retrieving a dependency via git clone. + +:::info Shallow Clone By Default +DevSpace uses shallow clones of git dependencies which reduces the time to retrieve the dependency. +::: + +#### Default Value For `source.disableShallow` +```yaml +disableShallow: false +``` + +### `source.cloneArgs` +The `source.cloneArgs` option expects an array of additional arguments that DevSpace will pass when cloning a git dependency using the `git clone` command. + +#### Default Value For `source.cloneArgs` +```yaml +cloneArgs: [] +``` + + +## General Options + +### `profile` + + + + +### `skipBuild` + + + + +### `ignoreDependencies` + + + + +### `name` + + + + +### `namespace` + + diff --git a/docs/versioned_docs/version-4.13/configuration/dependencies/local-folder.mdx b/docs/versioned_docs/version-4.13/configuration/dependencies/local-folder.mdx new file mode 100644 index 0000000000..aa958243f7 --- /dev/null +++ b/docs/versioned_docs/version-4.13/configuration/dependencies/local-folder.mdx @@ -0,0 +1,69 @@ +--- +title: Deploy Path-Based Local Dependencies +sidebar_label: "source.path" +--- + +import FragmentDependencyProfile from '../../fragments/dependency-profile.mdx'; +import FragmentDependencySkipBuild from '../../fragments/dependency-skipBuild.mdx'; +import FragmentDependencyIgnoreDependencies from '../../fragments/dependency-ignoreDependencies.mdx'; +import FragmentDependencyNamespace from '../../fragments/dependency-namespace.mdx'; +import FragmentDependencyName from '../../fragments/dependency-name.mdx'; + + +## Example +```yaml +dependencies: +- source: + path: ./different/subproject +- source: + path: ./different/another-subproject +``` + +:::warning +Using local projects with `path` option makes the configuration in `devspace.yaml` harder to share compared to [`git` based dependencies](../../configuration/dependencies/git-repository.mdx) and is therefore discouraged. +::: + +## `source` + +### `source.path` +The `source.path` option expects a string with a relative path to a folder that contains a `devspace.yaml` which marks a project that is a dependency of the project referencing it. + +#### Example: Local Project as Dependency +```yaml +dependencies: +- source: + path: ../other-project +- source: + path: ./different/subproject +``` +**Explanation:** +- Whenever you run `devspace deploy` or `devspace dev`, DevSpace will: + - Load the `devspace.yaml` files of both dependencies and resolve their dependencies respectively. + - Deploy both projects according to their `devspace.yaml` files. + + +## General Options + +### `profile` + + + + +### `skipBuild` + + + + +### `ignoreDependencies` + + + + +### `name` + + + + +### `namespace` + + diff --git a/docs/versioned_docs/version-4.13/configuration/deployments/basics.mdx b/docs/versioned_docs/version-4.13/configuration/deployments/basics.mdx new file mode 100644 index 0000000000..117e0a8dd4 --- /dev/null +++ b/docs/versioned_docs/version-4.13/configuration/deployments/basics.mdx @@ -0,0 +1,169 @@ +--- +title: Deployments +sidebar_label: Basics +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; +import FragmentWorkflowDeployDependencies from '../../fragments/workflow-deploy-dependencies.mdx'; +import FragmentWorkflowBuildImages from '../../fragments/workflow-build-images.mdx'; +import FragmentWorkflowReplaceTags from '../../fragments/workflow-replace-tags.mdx'; +import FragmentWorkflowDeployProject from '../../fragments/workflow-deploy-project.mdx'; + +Deployments are configured within the `deployments` section of the `devspace.yaml`. + +## Examples + + + + +```yaml +deployments: +- name: "deployment-1" # Name of this deployment + helm: # Deploy using the Component Helm Chart + componentChart: true # Use the component chart + values: ... # See: https://devspace.sh/component-chart/docs/introduction + +- name: "deployment-2" # Name of this deployment + kubectl: # Deploy Kubernetes manifests or Kustomizations + manifests: + - app/manifests/ + - db/deployment.yaml + +- name: "deployment-3" # Name of this deployment + helm: # Deploy a Helm Chart + chart: + name: stable/mysql # Deploy chart from stable registry + values: ... + +- name: "deployment-4" # Name of this deployment + helm: ... # Deploy another Helm Chart + chart: + name: ./chart # Deploy chart from local folder + values: ... +``` + + + + +```yaml +deployments: +- name: "deployment-1" # Name of this deployment + helm: # Deploy using the Component Helm Chart + componentChart: true # Use the component chart + values: ... # See: https://devspace.sh/component-chart/docs/introduction +``` + + + + +```yaml +deployments: +- name: database # Name of this deployment + helm: # Deploy a Helm Chart + chart: + name: stable/mysql # Deploy chart from stable registry + values: ... +- name: backend # Name of this deployment + helm: ... # Deploy another Helm Chart + chart: + name: ./chart # Deploy chart from local folder + values: ... +``` + + + + +```yaml +deployments: +- name: backend # Name of this deployment + kubectl: # Deploy Kubernetes manifests or Kustomizations + manifests: + - app/manifests/ + - db/deployment.yaml +``` + + + + +```yaml +deployments: +- name: backend # Name of this deployment + kubectl: # Deploy Kubernetes manifests or Kustomizations + kustomize: true + manifests: + - app/kustomization/ +``` + + + + +:::info Sequential Deployment +Unlike images which are build in parallel, deployments will be deployed sequentially following the order in which they are specified in the `devspace.yaml`. +::: + +## Run Deployments +When you run one of the following commands, DevSpace will run the deployment process: +- `devspace deploy` (before deploying the application) +- `devspace dev` (before deploying the application and starting the development mode) + +### Important Flags +The following flags are available for all commands that trigger the deployment process: +- `-d / --force-deploy` redeploy all deployments (even if they could be skipped because they have not changed) +- `-b / --force-build` rebuild all images (even if they could be skipped because context and Dockerfile have not changed) + + +## Deployment Process +DevSpace loads the `deployments` configuration from `devspace.yaml` and builds one deployment after another in the order that they are specified in the `deployments` array. Additionally, DevSpace also deploys related projects speficied in `dependencies`. + + +### 1. Deploy Dependencies + + + + +### 2. Build, Tag & Push Images + + + + +### 3. Tag Replacement + + + + +### 4. Deploy Project + + + +
+ +--- + +## Useful Commands + +### `devspace list deployments` +This command lists all deployments and their status: +```bash +devspace list deployments +``` + +### `devspace render` +This command prints all Kubernetes manifests that would be created when running `devspace deploy` or `devspace dev` but without actually deploying them to the cluster: +```bash +devspace render +``` +In case of Helm deployments, this command behaves similar to `helm install --dry-run --debug` + +:::info Image Building & Tag Replacement +This command will build images (if necessary) and update the tags within manifests and Helm chart values. +::: diff --git a/docs/versioned_docs/version-4.13/configuration/deployments/helm-charts.mdx b/docs/versioned_docs/version-4.13/configuration/deployments/helm-charts.mdx new file mode 100644 index 0000000000..fec9c4aa68 --- /dev/null +++ b/docs/versioned_docs/version-4.13/configuration/deployments/helm-charts.mdx @@ -0,0 +1,541 @@ +--- +title: Deploy Helm Charts +sidebar_label: helm +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; +import FragmentInfoComponentChart from '../../fragments/info-component-chart.mdx'; + +To deploy Helm charts, you need to configure them within the `deployments` section of the `devspace.yaml`. + +## Examples + + + + +```yaml {5} +deployments: +- name: database + helm: + chart: + name: stable/mysql + values: + mysqlRootPassword: ${MYSQL_ROOT_PASSWORD} + mysqlUser: db_user + mysqlDatabase: app_database +``` + + + + +```yaml {4} +deployments: +- name: backend + helm: + componentChart: true + values: + containers: + - image: reg.tld/username/devspace + service: + ports: + - port: 3000 +``` + + + + + + +```yaml {5,6} +deployments: +- name: backend + helm: + chart: + name: chart-name + repo: https://my-charts.company.tld/ + values: + ingress: + enabled: true +``` + + + + +```yaml {5} +deployments: +- name: backend + helm: + chart: + name: ./path/to/chart + values: + ingress: + enabled: true +``` + + + + + +## Chart + +### `componentChart` +The `componentChart` option expects a boolean which states if the Component Helm Chart should be used for deployment. + + + +:::warning +If `componentChart: true` is configured, all options under `chart` will be ignored. +::: + +#### Default Value for `componentChart` +```yaml +componentChart: false +``` + +#### Example: Component Chart Deployment +```yaml {4} +deployments: +- name: backend + helm: + componentChart: true + values: + containers: + - image: reg.tld/username/devspace + service: + ports: + - port: 3000 +``` + +### `chart.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 (either the default (stable) repository or one specified via [`repo` option](#chartrepo)) + +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 Deployment +```yaml +deployments: +- name: database + helm: + chart: + name: stable/mysql +``` +**Explanation:** +Deploying the above example would roughly be equivalent to this command: +```bash +helm install database stable/mysql +``` + +### `chart.version` +The `version` option expects a string stating the version of the chart that should be used. + +#### Default Value for `version` +```yaml +version: "" +``` + +:::note Latest Version +If no version is specified, Helm will by default use the latest version of the chart. +::: + +#### Example: Custom Chart Version +```yaml +deployments: +- name: database + helm: + chart: + name: stable/mysql + version: "1.3.1" +``` +**Explanation:** +Deploying the above example would roughly be equivalent to this command: +```bash +helm install database stable/mysql --version="1.3.1" +``` + +### `chart.repo` +The `repo` option expects a string with an URL to a [Helm Chart Repository](https://helm.sh/docs/chart_repository/). + +:::note Stable Repository +The [official Helm Chart Repository `stable`](https://github.com/helm/charts) does not need to be explicitly specified. Using the `stable/` prefix for the chart name is sufficient. +::: + +#### Default Value for `repo` +```yaml +repo: stable +``` + +#### Example: Custom Chart Repository +```yaml +deployments: +- name: database + helm: + chart: + name: custom-chart + repo: https://my-repo.tld/ +``` +**Explanation:** +Deploying the above example would roughly be equivalent to this command: +```bash +helm install database custom-chart --repo "https://my-repo.tld/" +``` + + +## Values +Helm 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](../../configuration/variables/basics.mdx) + +:::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`. +::: + +#### Default Value for `values` +```yaml +values: {} +``` + +#### Example: Using Values in devspace.yaml +```yaml +deployments: +- name: database + helm: + chart: + name: stable/mysql + values: + mysqlRootPassword: ${MYSQL_ROOT_PASSWORD} + mysqlUser: db_user + mysqlDatabase: app_database +``` +**Explanation:** +Deploying the above example would roughly be equivalent to this command: +```bash +helm install database stable/mysql --set mysqlRootPassword="$MYSQL_ROOT_PASSWORD" --set mysqlUser="db_user" --set mysqlDatabase="app_database" +``` + +### `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`. +::: + +#### Default Value for `valuesFiles` +```yaml +valuesFiles: [] +``` + +#### Example: Using Values Files +```yaml +deployments: +- name: database + helm: + chart: + name: stable/mysql + valuesFiles: + - mysql/values.yaml + - mysql/values.production.yaml +``` +**Explanation:** +Deploying the above example would roughly be equivalent to this command: +```bash +helm install database stable/mysql -f mysql/values.yaml -f mysql/values.production.yaml +``` + + +### `replaceImageTags` +The `replaceImageTags` option expects a boolean stating if DevSpace should do [Image Tag Replacement](../../configuration/deployments/basics.mdx#3-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. + +:::info 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. +::: + +#### Default Value for `replaceImageTags` +```yaml +replaceImageTags: true +``` + +#### Example: Disable Tag Replacement +```yaml +deployments: +- name: database + helm: + chart: + name: stable/mysql + replaceImageTags: false +``` + + +## Helm Options + +### `wait` +The `wait` option expects a boolean that will be used for the [helm flag `--wait`](https://helm.sh/docs/intro/using_helm/#helpful-options-for-installupgraderollback). + +#### Default Value for `wait` +```yaml +wait: false +``` + +#### Example: Helm Flag Wait +```yaml +deployments: +- name: database + helm: + chart: + name: stable/mysql + wait: true +``` +**Explanation:** +Deploying the above example would roughly be equivalent to this command: +```bash +helm install database stable/mysql --wait +``` + +### `timeout` +The `timeout` option expects an integer representing a number of seconds that will be used for the [helm flag `--timeout`](https://helm.sh/docs/intro/using_helm/#helpful-options-for-installupgraderollback). + +#### Default Value for `timeout` +```yaml +timeout: 180 +``` + +#### Example: Helm Flag Timeout +```yaml +deployments: +- name: database + helm: + chart: + name: stable/mysql + timeout: 300 +``` +**Explanation:** +Deploying the above example would roughly be equivalent to this command: +```bash +helm install database stable/mysql --timeout=300 +``` + +### `force` +The `force` option expects a boolean that will be used for the [helm flag `--force`](https://helm.sh/docs/helm/helm_upgrade). + +#### Default Value for `force` +```yaml +force: false +``` + +#### Example: Helm Flag Force +```yaml +deployments: +- name: database + helm: + chart: + name: stable/mysql + force: true +``` +**Explanation:** +Deploying the above example would roughly be equivalent to this command: +```bash +helm install database stable/mysql --force +``` + +### `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). + +#### Default Value for `recreate` +```yaml +recreate: false +``` + +#### Example: Enable Recreate Pods +```yaml +deployments: +- name: database + helm: + chart: + name: stable/mysql + recreate: true +``` + +### `atomic` +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](#wait). + +#### Default Value for `atomic` +```yaml +atomic: false +``` + +#### Example: Enable Atomic Deployment +```yaml +deployments: +- name: database + helm: + chart: + name: stable/mysql + atomic: true +``` + +### `cleanupOnFail` +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. + +#### Default Value for `cleanupOnFail` +```yaml +cleanupOnFail: false +``` + +#### Example: Enable Cleanup On Fail +```yaml +deployments: +- name: database + helm: + chart: + name: stable/mysql + cleanupOnFail: true +``` + +### `disableHooks` +The `disableHooks` option expects a boolean that tells DevSpace to disable hooks when executing Helm commands. + +#### Default Value for `disableHooks` +```yaml +disableHooks: false +``` + +#### Example: Disable Hooks +```yaml +deployments: +- name: database + helm: + chart: + name: stable/mysql + disableHooks: true +``` + +### `driver` +The `driver` option expects a string that states the storage driver that should be used by Helm. By default, Helm 3 uses Kubneretes secrets to store the deployment configuration of a release. Alternative options include `configmaps` or `memory`. + +:::warning +This option is **not** compatible with `v2: true`. +::: + +#### Default Value for `driver` +```yaml +driver: secrets +``` + +#### Example: Use Different Driver +```yaml +deployments: +- name: database + helm: + chart: + name: stable/mysql + driver: configmaps +``` + +### `v2` +The `v2` option expects a boolean that tells DevSpace to use the legacy version 2 of Helm instead of Helm v3. + +#### Default Value for `v2` +```yaml +v2: false +``` + +### `tillerNamespace` +The `tillerNamespace` option expects a string that will be used for the [helm flag `--tiller-namespace`](https://helm.sh/docs/intro/using_helm/#helpful-options-for-installupgraderollback). + +:::warning Helm 2 Only +This config option is only used when [`v2: true`](#v2) is configured as well. +::: + +:::warning Deprecated +This config option is deprecated because Tiller is not necessary anymore since DevSpace supports Helm v3. +::: + +#### Default Value for `tillerNamespace` +```yaml +tillerNamespace: "" # defaults to default namespace of current context +``` + +#### Example: Change Tiller Namespace +```yaml +deployments: +- name: database + helm: + chart: + name: stable/mysql + tillerNamespace: my-tiller-ns + v2: true +``` +**Explanation:** +Deploying the above example would roughly be equivalent to this command: +```bash +# Helm v2 CLI +helm install --name database stable/mysql --tiller-namespace=my-tiller-ns +``` + + +### `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. + +:::warning Helm 2 Only +This config option is only used when [`v2: true`](#v2) 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 Options + +### `name` +The `name` option is required and expects a string with the name of the release used to deploy this Helm chart. + +#### Example: Deployment Name +```yaml {2} +deployments: +- name: database + helm: + chart: + name: stable/mysql +``` + +### `namespace` +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: +```bash +devspace use namespace [some-namespace] +``` +::: + +#### Example: Deployment Namespace +```yaml {3} +deployments: +- name: database + namespace: some-namespace + helm: + chart: + name: stable/mysql +``` diff --git a/docs/versioned_docs/version-4.13/configuration/deployments/kubernetes-manifests.mdx b/docs/versioned_docs/version-4.13/configuration/deployments/kubernetes-manifests.mdx new file mode 100644 index 0000000000..033550ece8 --- /dev/null +++ b/docs/versioned_docs/version-4.13/configuration/deployments/kubernetes-manifests.mdx @@ -0,0 +1,145 @@ +--- +title: Deploy Kubernetes Manifests +sidebar_label: kubectl (manifests) +--- + +import FragmentReplaceImageTags from '../../fragments/kubectl-replaceImageTags.mdx'; +import FragmentKubectlApplyArgs from '../../fragments/kubectl-options-applyArgs.mdx'; +import FragmentKubectlDeleteArgs from '../../fragments/kubectl-options-deleteArgs.mdx'; +import FragmentKubectlCmdPath from '../../fragments/kubectl-options-cmdPath.mdx'; +import FragmentKubectlKustomize from '../../fragments/kubectl-kustomize.mdx'; + +To deploy Kubernetes manifests with `kubectl apply`, you need to configure them within the `deployments` section of the `devspace.yaml`. + +## Example +```yaml +deployments: +- name: backend + kubectl: + manifests: + - backend/ + - backend-extra/ +- name: frontend + kubectl: + manifests: + - frontend/manifest.yaml +``` + +The above example will be executing during the deployment process as follows: +```bash +kubectl apply -f backend/ +kubectl apply -f backend-extra/ +kubectl apply -f frontend/manifest.yaml +``` + +:::note Kubectl +Deployments with `kubectl` require `kubectl` to be installed. If the `kubectl` binary cannot be found within the `$PATH` variable and it is not specified by specifying the [`cmdPath` option](#cmdpath), DevSpace will download the `kubectl` binary into the `$HOME/.devspace/bin` folder. +::: + + +## Manifests + +### `manifests` +The `manifests` option is mandatory and expects an array of paths or path globs that point to Kubernetes manifest files (yaml or json files) or to folders containing Kubernetes manifests or Kustomizations. + +#### Example: Manifests +```yaml +deployments: +- name: backend + kubectl: + manifests: + - backend/ + - backend-extra/ + - glob/path/to/manifests/ +``` + + +### `kustomize` + + + + +### `replaceImageTags` + + + + +## Kubectl Options + +### `applyArgs` + + + +### `createArgs` +The `createArgs` option expects an array of strings stating additional arguments (and flags) that should be used when calling `kubectl create`. + +:::info Kustomize Deployments +DevSpace only uses `kustomize create` to render the manifests using the default flags `--dry-run --output yaml --validate=false`. The actual deployment will be executed using `kubectl apply` after DevSpace has replaced the image tags within the rendered manifests in memory. +::: + +#### Default Value for `createArgs` +```yaml +createArgs: [] +``` + +#### Example: Custom Kubectl Args & Flags +```yaml +deployments: +- name: backend + kubectl: + manifests: + - backend/ + createArgs: + - "--recursive" +``` +**Explanation:** +Deploying the above example would roughly be equivalent to this command: +```bash +kubectl create --dry-run --output yaml --validate=false --recursive -f backend/ +``` + +### `deleteArgs` + + + + +### `cmdPath` + + + + +## General Options + +### `name` +The `name` option is required and expects a string to identify this deployment. + +#### Example: Deployment Name +```yaml {2} +deployments: +- name: backend + kubectl: + manifests: + - backend/ + - backend-extra/ +``` + +### `namespace` +The `namespace` option is required and expects a string with the namespace used to deploy the manifests. + +:::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: +```bash +devspace use namespace [some-namespace] +``` +::: + +#### Example: Deployment Namespace +```yaml {3} +deployments: +- name: backend + namespace: some-namespace + kubectl: + manifests: + - backend/ + - backend-extra/ +``` diff --git a/docs/versioned_docs/version-4.13/configuration/deployments/kustomizations.mdx b/docs/versioned_docs/version-4.13/configuration/deployments/kustomizations.mdx new file mode 100644 index 0000000000..74d10d7539 --- /dev/null +++ b/docs/versioned_docs/version-4.13/configuration/deployments/kustomizations.mdx @@ -0,0 +1,145 @@ +--- +title: Deploy Kustomizations +sidebar_label: kubectl (kustomize) +--- + +import FragmentReplaceImageTags from '../../fragments/kubectl-replaceImageTags.mdx'; +import FragmentKubectlApplyArgs from '../../fragments/kubectl-options-applyArgs.mdx'; +import FragmentKubectlDeleteArgs from '../../fragments/kubectl-options-deleteArgs.mdx'; +import FragmentKubectlCmdPath from '../../fragments/kubectl-options-cmdPath.mdx'; +import FragmentKubectlKustomize from '../../fragments/kubectl-kustomize.mdx'; + +To deploy Kustomizations using `kustomize` / `kubectl apply -k`, you need to configure them within the `deployments` section of the `devspace.yaml`. + +## Example +```yaml {4} +deployments: +- name: my-deployment + kubectl: + kustomize: true + manifests: + - my-kustomization/ + - another-kustomization/ +``` + +The above example will be executing during the deployment process as follows: +```bash +kubectl apply -k my-kustomization/ +kubectl apply -k another-kustomization/ +``` + +:::warning Kubectl or Kustomize Required +Kustomization deployments require `kubectl` or `kustomize` to be installed. If both are available, DevSpace will use the `kustomize` binary by default. +::: + + +## Manifests + +### `manifests` +The `manifests` option is mandatory and expects an array of paths that point to directories containing Kustomizations. + +#### Example: Manifests +```yaml +deployments: +- name: backend + kubectl: + kustomize: true + manifests: + - my-kustomization/ + - another-kustomization/ +``` + + +### `kustomize` + + + + +### `replaceImageTags` + + + + +## Kubectl Options + +### `applyArgs` + + + +### `kustomizeArgs` +The `kustomizeArgs` option expects an array of strings stating additional arguments (and flags) that should be used when calling `kustomize build`. + +:::info Kustomize Deployments +DevSpace only uses `kustomize build` to render the manifest templates. The actual deployment will be executed using `kubectl apply`. +::: + +#### Default Value for `kustomizeArgs` +```yaml +kustomizeArgs: [] +``` + +#### Example: Custom Kustomize Args & Flags +```yaml +deployments: +- name: backend + kubectl: + manifests: + - backend/ + kustomize: true + kustomizeArgs: + - "--timeout" + - "10s" + - "--grace-period" + - "30" +``` +**Explanation:** +Deploying the above example would roughly be equivalent to this command: +```bash +kustomize build --timeout=10s --grace-period=30 -f backend/ +``` + +### `deleteArgs` + + + + +### `cmdPath` + + + + +## General Options + +### `name` +The `name` option is required and expects a string to identify this deployment. + +#### Example: Deployment Name +```yaml {2} +deployments: +- name: backend + kubectl: + manifests: + - backend/ + - backend-extra/ +``` + +### `namespace` +The `namespace` option is required and expects a string with the namespace used to deploy the manifests. + +:::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: +```bash +devspace use namespace [some-namespace] +``` +::: + +#### Example: Deployment Namespace +```yaml {3} +deployments: +- name: backend + namespace: some-namespace + kubectl: + manifests: + - backend/ + - backend-extra/ +``` diff --git a/docs/versioned_docs/version-4.13/configuration/development/auto-reloading.mdx b/docs/versioned_docs/version-4.13/configuration/development/auto-reloading.mdx new file mode 100644 index 0000000000..a6dce7ff88 --- /dev/null +++ b/docs/versioned_docs/version-4.13/configuration/development/auto-reloading.mdx @@ -0,0 +1,58 @@ +--- +title: Configure Auto-Reloading +sidebar_label: autoReload +--- + +There are certain use cases where you want to rebuild and redeploy the whole application instead of using the file synchronization and hot reloading. DevSpace provides you the options to specify special paths that are watched during `devspace dev` and any change to such a path will trigger a redeploy. + +Auto-reloading can be configured in the `dev.autoReload` section of `devspace.yaml`. +```yaml {19-26} +images: + backend: + image: john/devbackend + database: + image: john/database +deployments: +- name: app-backend + helm: + componentChart: true + values: + containers: + - image: john/devbackend +- name: custom-manifests + kubectl: + manifests: + - manifests/ + - more/manifests/ +dev: + autoReload: + paths: + - ./package.json + - ./important-config-files/* + images: + - database + deployments: + - custom-manifests +``` + +Take a look at the [redeploy-instead-of-hot-reload exmaple](https://github.com/devspace-cloud/devspace/tree/master/examples/redeploy-instead-of-hot-reload) to see how to disable hot reloading at all and enable redeployment on every file change instead. + + +## Configuration + +### `paths` +The `paths` option expects an array of strings with paths that should be watched for changes. If a change occurs in any of the specified paths, DevSpace will stop the development mode, rebuild the images (if the context has changed), redeploy the application and restart the development mode (sync, port-forwarding, log streaming etc.) afterwards. + +### `images` +The `images` option expects an array of strings with image names from the `images` section of the `devspace.yaml`. If a change occurs to the `dockerfile` or to one of the files within the `context` of this image (if its context has changed), DevSpace will stop the development mode, rebuild the images, redeploy the application and restart the development mode (sync, port-forwarding, log streaming etc.) afterwards. + +### `deployments` +The `deployments` option expects an array of strings with names of deployments from the `deployments` section of the `devspace.yaml`. If a change occurs to any of the files that belong to this deployment, DevSpace will stop the development mode, rebuild the images (if the context has changed), redeploy the application and restart the development mode (sync, port-forwarding, log streaming etc.) afterwards. + +:::note Manifest Deployments +For `kubectl` deployments, DevSpace watches for all paths configured under `manifests`. +::: + +:::note Helm Chart Deployments +For `helm` deployments, DevSpace watches for changes in the `valuesFiles` or changes in the chart path of a local chart (configured as `chart.name`). +::: diff --git a/docs/versioned_docs/version-4.13/configuration/development/basics.mdx b/docs/versioned_docs/version-4.13/configuration/development/basics.mdx new file mode 100644 index 0000000000..7c77dede1d --- /dev/null +++ b/docs/versioned_docs/version-4.13/configuration/development/basics.mdx @@ -0,0 +1,227 @@ +--- +title: Development Mode +sidebar_label: Basics +--- + +import FragmentWarningMultipleDev from '../../fragments/warning-multiple-dev.mdx'; +import FragmentWorkflowDeployDependencies from '../../fragments/workflow-deploy-dependencies.mdx'; +import FragmentWorkflowBuildImages from '../../fragments/workflow-build-images.mdx'; +import FragmentWorkflowReplaceTags from '../../fragments/workflow-replace-tags.mdx'; +import FragmentWorkflowDeployProject from '../../fragments/workflow-deploy-project.mdx'; +import FragmentNoteGeneralPurposeCommand from '../../fragments/note-general-purpose-command.mdx'; +import FragmentWorkflowOpenLinks from '../../fragments/workflow-open-links.mdx'; + +## Why? +The biggest advantages of developing directly inside Kubernetes is that your dev environment will be very similar to your production environment and you can have a much greater confidence that everything will work in production when shipping new features. + +Kubernetes-based development can be useful in the following cases: +- Your applications needs to access cluster-internal services (e.g. Cluster DNS) +- You want to test your application in a production-like environment +- You want to debug issues that are hard to reproduce on your local machine + +The development experience is very similar to using `docker-compose`, so if you are already familiar on how to develop with `docker-compose`, DevSpace will behave very similar. One of the major benefits of DevSpace versus docker-compose is that DevSpace allows you to develop in any Kubernetes cluster, either locally using minikube, Docker Kubernetes etc. or in any remote Kubernetes cluster. + + +## Start Development Mode +Start the development mode using this command: +```bash +devspace dev +``` + + + +### Important Flags for `devspace dev` +The following flags are available for all commands that trigger image building: +- `-i / --interactive` starts the [interactive mode](../../configuration/development/interactive-mode.mdx) +- `-d / --force-deploy` redeploy all deployments (even if they could be skipped because they have not changed) +- `-b / --force-build` rebuild all images (even if they could be skipped because context and Dockerfile have not changed) + + + +## Development Process +The development process first runs the [deployment process](../../configuration/deployments/basics.mdx) (1. - 4.) and then continues with starting the development-specific features. + +### 1. Deploy Dependencies + + + + +### 2. Build, Tag & Push Images + + + + +### 3. Tag Replacement + + + + +### 4. Deploy Project + + + + +### 5. Start Port-Forwarding +DevSpace iterates over every item in the `dev.ports` array defined in the `devspace.yaml` and starts port-forwarding for each of the entries and the port mappings they define in the `forward` section. + +:::note +Before starting the actual port-forwarding threads, DevSpace waits until the containers and services are ready. +::: + +:::info +Port-Fowarding allows you to access your containers and Kubernetes services via localhost. +::: + +For detailed logs about the port-forwarding, take a look at `.devspace/logs/portforwarding.log`. + + +### 6. Start File Synchronization +DevSpace iterates over every item in the `dev.sync` array defined in the `devspace.yaml` and starts a bi-directional, real-time code synchronization for each of the entries and the path mappings they define. + +:::note Initial Sync +Right after starting the file synchronization, DevSpace runs the so-called initial sync which quickly computes the differences between your local folders and the remote container filesystems. If DevSpace detects changes, it synchronizes them first to get a clean state before starting the real-time synchronization which is invoked every time a file changes. +::: + +For detailed logs about the file synchronzation, take a look at `.devspace/logs/sync.log` for the current session and `.devspace/logs/sync.log.old` for previous logs. + + +### 7. Stream Logs or Open Terminal +DevSpace provides two options to develop applications in Kubernetes: +- using multi-container log streaming (default) +- using an interactive terminal session (run `devspace dev -i`) + +:::note Multi-Container Log Streaming (default) +The first option starts your application as defined in your Dockerfile or in your Kubernetes pod definition. After the pods are started, DevSpace streams the logs of all containers that are started with an image that was built during the image building process. Each log line is prefixed with the image name or alternatively with the pod name of the container. Before starting the actual log streaming, DevSpace prints the last 50 log lines of each container by default. + +Learn how to [customize which containers should be included in the log stream and how many log lines should be shown in the beginning](../../configuration/development/log-streaming.mdx). +::: + +:::note Interactive Terminal Session +To start interactive mode, run: +```bash +devspace dev -i +``` +Instead of starting the multi-container log streaming, you can also start development mode using an interactive terminal session. This interactive mode builds your images (by default) using an `ENTRYPOINT = [sleep, 999999]` override for the image you want to work on and starts an interactive terminal session for the container that is being started with this image. This means that your container starts but without starting your application which allows you to run a command through the terminal session to manually start the application. This is often useful for debugging container start issues or for quickly testing different commands that could be used as an `ENTRYPOINT`. + +Interactive mode works out of the box but is also [customizable using the `dev.interactive` configuration section](../../configuration/development/interactive-mode.mdx). +::: + +### 8. Open Links (optional) +DevSpace iterates over every item in the `dev.open` array defined in the `devspace.yaml` and tries to open the URL you provide for each item using the following method: + + + +Learn more about [configuring auto-opening links](../../configuration/development/open-links.mdx). + + + +## Useful Commands + +### `devspace dev -i` +To start development in interactive mode, run: +```bash +devspace dev -i +``` + +Learn more about [using interactive mode](../../guides/interactive-mode.mdx). + + +### `devspace enter` +The command `devspace dev -i` starts a terminal but it also starts port-forwarding and file synchronization which can only be opened once. However, you often need additional terminal sessions. To open a simple terminal session without starting port-forwarding and file sync, run the following command: +```bash +devspace enter +``` + +If you do not provide a selector (e.g. pod name, label selector or image selector), DevSpace will show a picker with all available pods and containers. + + + + +### `devspace logs [-f]` +If you want to print or stream the logs of a single container, run: +```bash +# Print logs +devspace logs + +# Stream logs +devspace logs -f +``` + +If you do not provide a selector (e.g. pod name, label selector or image selector), DevSpace will show a picker with all available pods and containers. + + + + +### `devspace sync` +If you want to start code synchronization on-demand (and even outside a DevSpace project), you can run commands like the ones shown here: +```bash +devspace sync --local-path=subfolder --container-path=/app +devspace sync --exclude=node_modules --exclude=test +devspace sync --pod=my-pod --container=my-container +``` + +If you do not provide a selector (e.g. pod name, label selector or image selector), DevSpace will show a picker with all available pods and containers. + + + + +### `devspace open` +To view your project in the browser either via port-forwarding or via ingress (domain), run the following command: +```bash +devspace open +``` +When DevSpace asks you how to open your application, you have two options as shown here: +```bash +? How do you want to open your application? + [Use arrows to move, space to select, type to filter] +> via localhost (provides private access only on your computer via port-forwarding) + via domain (makes your application publicly available via ingress) +``` +To use the second option, you either need to make sure the DNS of your domain points to your Kubernetes cluster and you have an ingress-controller running in your cluster OR you use [DevSpace Cloud](https://devspace.cloud/cloud/docs/introduction), either in form of Hosted Spaces or by connecting your own cluster using the command `devspace connect cluster`. + +:::info Automatic Error Analytics +If your application does not open as exepected, run [`devspace analyze` and DevSpace will try to identify the issue](#devspace-analyze). +::: + + +### `devspace analyze` +If your application is not starting as expected or there seems to be some kind of networking issue, you can let DevSpace run an automated analysis of your namespace using the following command: +```bash +devspace analyze +``` +After analyzing your namespace, DevSpace compiles a report with potential issues, which is a good starting point for debugging and fixing issues with your deployments. + + +### `devspace list commands` +DevSpace allows you to share commands for common development tasks which can be executed with `devspace run [command-name]`. To get a list of available commands, run: +```bash +devspace list commands +``` +Learn how to [configure shared commands for `devspace run`](../../configuration/commands/basics.mdx). + + +### `devspace list deployments` +To get a list of all deployments as well as their status and other information, run the following command: +```bash +devspace list deployments +``` + + +### `devspace purge` +If you want to delete a deployment from Kubernetes you can run: +```bash +# Removes all deployments remotely +devspace purge +# Removes deployment with given name +devspace purge --deployments=my-deployment-1,my-deployment-2 +``` + +:::warning +Purging a deployment does not remove it from the `deployments` section in the `devspace.yaml`. It just removes the deployment from the Kubernetes cluster. To remove a deployment from `devspace.yaml`, run `devspace remove deployment [NAME]`. +::: + +### `devspace update dependencies` +If you are using dependencies from other git repositories, use the following command to update the cached git repositories of dependencies: +```bash +devspace update dependencies +``` diff --git a/docs/versioned_docs/version-4.13/configuration/development/file-synchronization.mdx b/docs/versioned_docs/version-4.13/configuration/development/file-synchronization.mdx new file mode 100644 index 0000000000..b15b961e88 --- /dev/null +++ b/docs/versioned_docs/version-4.13/configuration/development/file-synchronization.mdx @@ -0,0 +1,668 @@ +--- +title: Configure File Synchronization +sidebar_label: sync +--- + +The code synchronization feature of DevSpace allows you to use hot reloading during development. Especially when using programming languages and frameworks that support hot reloading with tools like nodemon, re-building and re-deploying containers is very annoying and time consuming. Therefore, DevSpace uses a smart syncing mechanism that is able to sync local file changes to remote containers directly without the need of rebuilding or restarting the container. + +When starting the development mode, DevSpace starts the file sync as configured in the `dev.sync` section of the `devspace.yaml`. +```yaml {15-21} +images: + backend: + image: john/devbackend + backend-debugger: + image: john/debugger +deployments: +- name: app-backend + helm: + componentChart: true + values: + containers: + - image: john/devbackend + - image: john/debugger +dev: + sync: + - imageName: backend + localSubPath: ./ + containerPath: /app + excludePaths: + - node_modules/ + - logs/ +``` + +:::info Start Sync Only +To only start the file sync without the other functions of the development mode, use `devspace sync` or `devspace sync --config=devspace.yaml` (to load the config). +::: + +Every sync configuration consists of two essential parts: +- [Pod/Container Selection](#podcontainer-selection) +- [Sync Path Mapping via `localSubPath` and `containerPath`](#sync-path-mapping) + + +## Pod/Container Selection +The following config options are needed to determine the container which the file synchronization should be established to: +- [`imageName`](#imagename) +- [`labelSelector`](#labelselector) +- [`containerName`](#containername) +- [`namespace`](#namespace) + +:::info Combine Otions +If you specify multiple these config options, they will be jointly used to select the pod / container (think logical `AND / &&`). +::: + +:::info Auto Reconnect +If the sync is unable to establish a connection to the selected container or loses it after starting the sync, DevSpace will try to restart the sync several times. +::: + +### `imageName` +The `imageName` option expects a string with the name of an image from the `images` section of the `devspace.yaml`. Using `imageName` tells DevSpace to select the container based on the referenced image that was last built using DevSpace. + +:::note +If `imageName` is specified in any of the sync configurations, `devspace dev` will **not** rebuild this image because DevSpace assumes that instead of rebuilding the image, the user wants to use the much faster file synchronization. If you still want to force rebuilding all images, run `devspace dev -b`. +::: + +:::note +When multiple `deployments` in your `devspace.yaml` use the same `image`, you generally want to select the right pod using the [`labelSelector`](#labelselector) but you should additionally define the `imageName` option if you want to enable faster image building (see note above). +::: + +#### Example: Select Container by Image Name +```yaml {2,4,18,22} +images: + backend: + image: john/devbackend + backend-debugger: + image: john/debugger +deployments: +- name: app-backend + helm: + componentChart: true + values: + containers: + - name: container-0 + image: john/devbackend + - name: container-1 + image: john/debugger +dev: + sync: + - imageName: backend + excludePaths: + - node_modules/ + - logs/ + - imageName: backend-debugger + localSubPath: ./debug-logs + containerPath: /logs +``` +**Explanation:** +- The above example defines two images that can be used as `imageName`: `backend` and `backend-debugger` +- The deployment starts two containers and each of them uses an image from the `images` section. +- The `imageName` option of the first sync configuration in the `dev.sync` section references `backend`. That means DevSpace would select the first container for file synchronzation, as this container uses the `image: john/devbackend` which belongs to the `backend` image as defined in the `images` section. +- The first sync configuration does not define `localSubPath`, so it defaults to the project's root directory (location of `devspace.yaml`). +- The first sync configuration does not define `containerPath`, so it defaults to the container's working directory (i.e. `WORKDIR`). +- The `imageName` option of the second sync configuration in the `dev.sync` section references `backend-debugger`. That means DevSpace would select the second container for file synchronization, as this container uses the `image: john/debugger` which belongs to the `backend-debugger` image as defined in the `images` section. + +In consequence, the following sync processes would be started when using the above config example assuming the local project root directoy `/my/project/`: + +1. `localhost:/my/project/` forwards to `container-0:$WORKDIR` **\*** +2. `localhost:/my/project/debug-logs/` forwards to `container-1:/logs` + +**\* Changes on either side (local and container filesystem) that occur within the sub-folders `node_modules/` and `logs/` would be ingored.** + +### `labelSelector` +The `labelSelector` option expects a key-value map of strings with Kubernetes labels. + +:::info +If you are using the `labelSelector` option, you may want to additionally specify the [`imageName` option](#imagename) to speed up the image building process. +::: + +#### Example: Select Container by Label +```yaml {18-21} +images: + backend: + image: john/devbackend + backend-debugger: + image: john/debugger +deployments: +- name: app-backend + helm: + componentChart: true + values: + containers: + - name: container-0 + image: john/devbackend + - name: container-1 + image: john/debugger +dev: + sync: + - labelSelector: + app.kubernetes.io/name: devspace-app + app.kubernetes.io/component: app-backend + custom-label: custom-label-value + containerName: container-0 + localSubPath: ./src + containerPath: /app/src +``` +**Explanation:** +- The `labelSelector` would select the pod created for the component deployment `app-backend`. +- Because the selected pod has two containers, we also need to specify the `containerName` option which defines the container that should be used for the file synchronization. + + +### `containerName` +The `containerName` option expects a string with a container name. This option is used to decide which container should be selected when using the `labelSelector` option because `labelSelector` selects a pod and a pod can have multiple containers. + +:::info +The `containerName` option is not required if the pod you are selecting using `imageName` or `labelSelector` has only one container. +::: + +#### Example +**See "[Example: Select Container by Label](#example-select-container-by-label)"** + + +### `namespace` +The `namespace` option expects a string with a Kubernetes namespace used to select the container from. + +:::warning +It is generally **not** needed (nor recommended) to specify the `namespace` option because by default, DevSpace uses the default namespace of your current kube-context which is usually the one that has been used to deploy your containers to. +::: + + +
+ +## Sync Path Mapping + +### `localSubPath` +The `localSubPath` option expects a string with a path that is relative to the location of `devspace.yaml`. + +#### Default Value For `localSubPath` +```yaml +localSubPath: ./ # Project root directory (folder containing devspace.yaml) +``` + +#### Example +**See "[Example: Select Container by Image Name](#example-select-container-by-image-name)"** + + +### `containerPath` +The `containerPath` option expects a string with an absolute path on the container filesystem. + +#### Default Value For `containerPath` +```yaml +containerPath: $WORKDIR # working directory, set as WORKDIR in the Dockerfile +``` + +#### Example +**See "[Example: Select Container by Image Name](#example-select-container-by-image-name)"** + + +
+ +## Exclude Paths +The config options for excluding paths use the same syntax as `.gitignore`. + +:::note +An exclude path that matches a folder recursively excludes all files and sub-folders within this folder. +::: + +### `excludePaths` +The `excludePaths` option expects an array of strings with paths that should not be synchronized between the local filesystem and the remote container filesystem. + +#### Default Value For `excludePaths` +```yaml +excludePaths: [] # Do not exclude anything from file synchronization +``` + +#### Example: Exclude Paths from Synchronization +```yaml {14-20} +images: + backend: + image: john/devbackend +deployments: +- name: app-backend + helm: + componentChart: true + values: + containers: + - image: john/devbackend +dev: + sync: + - imageName: backend + excludePaths: + - logs/ + - more/logs/ + uploadExcludePaths: + - node_modules/ + downloadExcludePaths: + - tmp/ +``` +**Explanation:** +- Files in `logs/` and in `more/logs/` would not be synchronized at all. +- Files in `node_modules/` would only be synchronized from the container to the local filesystem but not the other way around. +- Files in `tmp/` would only be synchroniyed from the local to the container filesystem but not the other way around. + + +### `downloadExcludePaths` +The `downloadExcludePaths` option expects an array of strings with paths that should not be synchronized from the remote container filesystem to the local filesystem. + +#### Default Value For `downloadExcludePaths` +```yaml +downloadExcludePaths: [] # Do not exclude anything from file synchronization +``` + +#### Example +**See "[Example: Exclude Paths from Synchronization](#example-exclude-paths-from-synchronization)"** + +### `uploadExcludePaths` +The `uploadExcludePaths` option expects an array of strings with paths that should not be synchronized from the local filesystem to the remote container filesystem. + +:::info +This option is often useful if you want to download a dependency folder (e.g. `node_modules/`) for code completion but you never want to upload anything from there because of compiled binaries that are not portable between local filesystem and container filesystem (e.g. when your local system is Windows but your containers run Linux). +::: + +#### Default Value For `uploadExcludePaths` +```yaml +uploadExcludePaths: [] # Do not exclude anything from file synchronization +``` + +#### Example +**See "[Example: Exclude Paths from Synchronization](#example-exclude-paths-from-synchronization)"** + + +
+ +## Post-Sync Commands +Sometimes it is useful to execute commands after the sync downloads or uploads files/directories between container and local filesystem. + +:::warning +Make sure that post-sync commands will **not** trigger a new sync process which could lead to an **endless loop**. +::: + +### `onUpload.restartContainer` +The `restartContainer` option expects a boolean which defines if DevSpace should restart the container every time either a single file or even a batch of files have been uploaded to the container using file sync. + +:::caution Restart Helper Required +Setting `restartContainer: true` requires to set `injectRestartHelper: true` for the image that is used to run the affected container. Otherwise, this option does not have any effect. +::: + +:::note When not to use this option +Using `restartContainer: true` is most useful if your application runs based on a compiled language and you are **not** using a framework or language specific tool which provides hot reloading capabilities. If you are using tools like nodemon or frameworks like React, Rails or Flask, they allow you to enable hot reloading which may be much faster than restarting the entire container. In this case you should disable `restartContainer`. +::: + +#### Example: Enable Container Restart +```yaml {4,16} +images: + backend: + image: john/devbackend + injectRestartHelper: true +deployments: +- name: app-backend + helm: + componentChart: true + values: + containers: + - image: john/devbackend +dev: + sync: + - imageName: backend + onUpload: + restartContainer: true +``` + + +### `onUpload` +The `onUpload` option defines command(s) that should be executed after a file/directory was uploaded from the local filesystem to the container. + +#### Example: Post-Upload Commands +```yaml {14-29} +images: + backend: + image: john/devbackend +deployments: +- name: app-backend + helm: + componentChart: true + values: + containers: + - image: john/devbackend +dev: + sync: + - imageName: backend + onUpload: + execRemote: # These post-sync commands will be executed inside the affected container + command: chmod # Command to execute for files and folders + args: + - +x + - {} # {} will be replaced with the path of the synced file/directory + onFileChange: # Command to execute ONLY for files + command: chmod + args: + - +x + - {} # {} will be replaced with the path of the synced file/directory + onDirCreate: # Command to execute ONLY for newly created directories + command: chmod + args: + - +x + - {} # {} will be replaced with the path of the synced file/directory + onBatch: # Command to execute after sync has processed a full batch of files and folders + command: recompile + args: # NOTE: {} is NOT available for onBatch + - assets + - --minify +``` + +### `onDownload` +The `onDownload` option defines command(s) that should be executed after a file/directory was downloaded from the container to the local filesystem. + +#### Example: Post-Download Commands +```yaml {14-29} +images: + backend: + image: john/devbackend +deployments: +- name: app-backend + helm: + componentChart: true + values: + containers: + - image: john/devbackend +dev: + sync: + - imageName: backend + onDownload: + execLocal: # These post-sync commands will be executed on the local dev machine + command: chmod # Command to execute for files and folders + args: + - +x + - {} # {} will be replaced with the path of the synced file/directory + onFileChange: # Command to execute ONLY for files + command: chmod + args: + - +x + - {} # {} will be replaced with the path of the synced file/directory + onDirCreate: # Command to execute ONLY for newly created directories + command: chmod + args: + - +x + - {} # {} will be replaced with the path of the synced file/directory +``` + + +
+ +## One-Directional Sync +These flags allow for local or remote container filesystems to be ignored during synchronization. + +### `disableDownload` +The `disableDownload` option expects a boolean which enables/disables all synchronization from the remote container filesystem to the local filesystem. + +#### Default Value For `disableDownload` +```yaml +disableDownload: false # Do not ignore remote container files during synchronization +``` + +#### Example: Synchronize Local Filesystem Only +```yaml {14-20} +images: + backend: + image: john/devbackend +deployments: +- name: app-backend + helm: + componentChart: true + values: + containers: + - image: john/devbackend +dev: + sync: + - imageName: backend + disableDownload: true + excludePaths: + - logs/ + - more/logs/ + uploadExcludePaths: + - node_modules/ +``` + +### `disableUpload` +The `disableUpload` option expects a boolean which enables/disables all synchronization from the local filesystem to the remote container filesystem. + +#### Default Value For `disableUpload` +```yaml +disableUpload: false # Do not ignore local files during synchronization +``` + +#### Example: Synchronize Remote Container Filesystem Only +```yaml {14-20} +images: + backend: + image: john/devbackend +deployments: +- name: app-backend + helm: + componentChart: true + values: + containers: + - image: john/devbackend +dev: + sync: + - imageName: backend + disableUpload: true + excludePaths: + - logs/ + - more/logs/ + downloadExcludePaths: + - tmp/ +``` + + +
+ +## Initial Sync + +### `initialSync` +The `initialSync` option expects a string with an initial sync strategy. The following strategies are available: + +#### • `mirrorLocal` mirrors the local filesystem inside the container (default) + +1. deletes all files inside the conainer that are not existing on the local filesystem +2. uploads all files which are existing on the local filesystem but are missing within the container +3. resolves all file conflicts (different content on local filesystem than in inside the container) by preferring the file on the local filesystem (i.e. all files in the container will be replaced if they are different than on the local filesystem) + +#### • `preferLocal` is like `mirrorLocal` but skips step 1. + +#### • `mirrorRemote` mirrors the container files to the local filesystem: + +1. deletes all files on the local filesystem that are not existing inside the container +2. downloads all files which are existing inside the container but are missing on the local filesystem +3. resolves all file conflicts (different content on local filesystem than inside the container) by preferring the file within the container (i.e. all files on the local filesystem will be replaced if they are different than inside the container) + +#### • `preferRemote` is like `mirrorRemote` but skips step 1. + +#### • `preferNewest` merges local and remote filesystem while resolving all conflicts + +1. uploads all files which are existing on the local filesystem but are missing within the container +2. downloads all files which are existing inside the container but are missing on the local filesystem +3. resolves all file conflicts (different content on local filesystem than inside the container) by preferring the newest file (i.e. compares last modified timestamps and replaces all outdated files) + +#### • `keepAll` merges local and remote filesystem without resolving any conflicts + +1. uploads all files which are existing on the local filesystem but are missing within the container +2. downloads all files which are existing inside the container but are missing on the local filesystem + +#### Default Value For `initialSync` +```yaml +initialSync: mirrorLocal +``` + +#### Example: Configuring Initial Sync +```yaml {19} +images: + backend: + image: john/devbackend +deployments: +- name: app-backend + helm: + componentChart: true + values: + containers: + - image: john/devbackend +dev: + sync: + - imageName: backend + excludePaths: + - node_modules/* + - imageName: backend + localSubPath: ./node_modules/ + containerPath: /app/node_modules/ + initialSync: preferRemote +``` +**Explanation:** +With this configuration, `devspace dev` would do the following: +- DevSpace would start port-forwarding and file synchronzation. +- Initial sync would be started automatically. +- The first sync config section would synchronize all files except files within `node_modules/`. This means that during initial sync, all remote files that are not existing locally would be deleted and other files would be updated to the most recent version. +- The second sync config section would only synchronize files within `node_modules/` and because of `initialSync: preferRemote`, DevSpace would download all remote files which are not present on the local filesystem and override all local files which are different than the files within the container. + + +### `waitInitialSync` +The `waitInitialSync` option expects a boolean which defines if DevSpace should wait until the initial sync process has terminated before opening the container terminal or the multi-container log streaming. + +#### Default Value For `waitInitialSync` +```yaml +waitInitialSync: false # Start container terminal or log streaming before initial sync is completed +``` + +#### Example: Wait For Initial Sync To Complete +```yaml {14} +images: + backend: + image: john/devbackend +deployments: +- name: app-backend + helm: + componentChart: true + values: + containers: + - image: john/devbackend +dev: + sync: + - imageName: backend + waitInitialSync: true +``` +**Explanation:** +With the configuration `devspace dev` would do the following: +- DevSpace would start port-forwarding and file synchronzation. +- Initial sync would be started automatically. +- After the initial sync process is finished, DevSpace starts the multi-container log streaming. + + +
+ +## Network Bandwidth Limits +Sometimes it is useful to throttle the file synchronization, especially when large files or a large number of files are expected to change during development. The following config options provide these capabilities: + +### `bandwidthLimits.download` +The `bandwidthLimits.download` option expects an integer representing the max file download speed in KB/s, e.g. `download: 100` would limit the file sync to a download speed of `100 KB/s`. + +:::note +By default, the file synchronization algorithm uses the maximum bandwidth possible to make the sync process as fast as possible. +::: + +#### Example: Limiting Network Bandwidth +```yaml {14-16} +images: + backend: + image: john/devbackend +deployments: +- name: app-backend + helm: + componentChart: true + values: + containers: + - image: john/devbackend +dev: + sync: + - imageName: backend + bandwidthLimits: + download: 200 + upload: 100 +``` +**Explanation:** +- Downloading files from the container to the local filesystem would be limited to a transfer speed of `200 KB/s`. +- Upload files from the local filesystem to the container would be limited to a transfer speed of `100 KB/s`. + +### `bandwidthLimits.upload` +The `bandwidthLimits.upload` option expects an integer representing the max file upload speed in KB/s, e.g. `upload: 100` would limit the file sync to a upload speed of `100 KB/s`. + +:::note +By default, the file synchronization algorithm uses the maximum bandwidth possible to make the sync process as fast as possible. +::: + +#### Example +**See "[Example: Limiting Network Bandwidth](#example-limiting-network-bandwidth)"** + + + +## Useful Commands + +### `devspace status sync` +To get information about current synchronization activities, simply run: +```bash +devspace status sync +``` +Additionally, you can ciew the sync log within `.devspace/logs/sync.log` to get more detailed information. + + +### `devspace sync` +If you want to start file synchronzation on-demand without having to configure it in `devspace.yaml` and without starting port-forwarding or log streaming etc, you can use the `devspace sync` command as shown in the examples below: +```bash +# Select pod with a picker +devspace sync --local-path=subfolder --container-path=/app + +# Select pod and container by name and use current working directory as local-path +devspace sync --pod=my-pod --container=my-container --container-path=/app +``` + + + +## FAQ + +
+How does the sync work? + +
+ +DevSpace establishes a bi-directional code synchronization between the specified local folders and the remote container folders. It automatically recognizes any changes within the specified folders during the session and will update the corresponding files locally and remotely in the background. It uses a small helper binary that is injected into the target container to accomplish this. + +The algorithm roughly works like this: + +1. Inject a small helper binary via `kubectl cp` into the target container +2. Run initial sync accoring to the [`initialSync` config option](#initial-sync) +3. Watch for file changes on both sides (local and remote) and sync them accorind to the [sync path mappings](#sync-path-mapping) +4. After every sync process, [restart the container](#onuploadrestartcontainer) or run other custom [post-sync commands](#post-sync-commands) (optional) + +
+ +
+ +
+Are there any requirements for the sync to work? + +
+ +The `tar` command has to be present in the container otherwise `kubectl cp` does not work and the helper binary cannot be injected into the container. + +Other than that, no server-side component or special container privileges for code synchronization are required, as the sync algorithm runs completely client-only within DevSpace. The synchronization mechanism works with any container filesystem and no special binaries have to be installed into the containers. File watchers running within the containers like nodemon will also recognize changes made by the synchronization mechanism. + +
+ +
+ +
+What is the performance impact on using the file sync? + +
+ +The sync mechanism is normally very reliable and fast. Syncing several thousand files is usually not a problem. Changes are packed together and compressed during synchronization, which improves performance especially for transferring text files. Transferring large compressed binary files is possible, but can affect performance negatively. Remote changes can sometimes have a delay of 1-2 seconds till they are downloaded, depending on how big the synchronized folder is. It should be generally avoided to sync the complete container filesystem. + +
+ +
diff --git a/docs/versioned_docs/version-4.13/configuration/development/interactive-mode.mdx b/docs/versioned_docs/version-4.13/configuration/development/interactive-mode.mdx new file mode 100644 index 0000000000..9a699a2e2f --- /dev/null +++ b/docs/versioned_docs/version-4.13/configuration/development/interactive-mode.mdx @@ -0,0 +1,200 @@ +--- +title: Configure Interactive Mode +sidebar_label: interactive +--- + +The development mode of DevSpace can be started using the `-i / --interactive` flag which overrides the `ENTRYPOINT` of an image with `[sleep, 999999]` and opens an interactive terminal session for one of the containers that use the 'sleeping' image. Due to the `ENTRYPOINT` override, the application has not been started within the container and the user can start the application manually through the interactive terminal session. + +To control the default behavior when using the interactive mode, you can configure the `dev.interactive` section in the `devspace.yaml`. +```yaml {24-37} +images: + frontend: + image: dscr.io/${DEVSPACE_USERNAME}/appfrontend + backend: + image: john/appbackend + database: + image: john/database +deployments: +- name: app-frontend + helm: + componentChart: true + values: + containers: + - image: dscr.io/${DEVSPACE_USERNAME}/appfrontend +- name: app-backend + helm: + componentChart: true + values: + containers: + - image: john/appbackend + name: some-container + - image: john/appbackend +dev: + interactive: + images: + - name: backend + entrypoint: + - tail + cmd: + - -f + - /dev/null + - name: frontend + entrypoint: + - /debug_entrypoing.sh + terminal: + imageName: backend + containerName: some-container +``` + +## Start Interactive Mode +Start the interactive mode using this command: +```bash +devspace dev -i +``` + +## Configuration + +### `images` +The `images` option expects an array of objects having the following properties: +- `name` stating an image name which references an image in the `images` within `devspace.yaml` (required) +- `entrypoint` defining an [`ENTRYPOINT` override](../../configuration/images/entrypoint-cmd.mdx#entrypoint) that will be applied only in interactive mode (optional) +- `cmd` defining a [`CMD` override](../../configuration/images/entrypoint-cmd.mdx#cmd) that will be applied only in interactive mode (optional) + +:::info In-Memory Image Override +`ENTRYPOINT` and `CMD` overrides for interactive mode work the same way as regular [overrides for image building](../../configuration/images/entrypoint-cmd.mdx). However, they take precedence over regular overrides and are only used during interactive mode. +::: + +:::note +By default, DevSpace asks which image to override when starting interactive mode (or skips the question if only one image is defined). This image will then be built using the `ENTRYPOINT [sleep, 999999]` override if not configured differently via `images`. +::: + +#### Example: Setting Interactive Mode Images +```yaml {25-34} +images: + frontend: + image: dscr.io/${DEVSPACE_USERNAME}/appfrontend + backend: + image: john/appbackend + database: + image: john/database +deployments: +- name: app-frontend + helm: + componentChart: true + values: + containers: + - image: dscr.io/${DEVSPACE_USERNAME}/appfrontend +- name: app-backend + helm: + componentChart: true + values: + containers: + - image: john/appbackend + name: some-container + - image: john/appbackend-sidecar +dev: + interactive: + images: + - name: backend + entrypoint: + - tail + cmd: + - -f + - /dev/null + - name: frontend + entrypoint: + - /debug_entrypoing.sh +``` +**Explanation:** +- The above example defines 3 images and 2 deployments. +- The `images` option defines that the image `backend` should be built using a `ENTRYPOINT [tail]` and using `CMD [-f, /dev/null]` when building this image in interactive mode +- The `images` option defines that the image `frontend` should be built using a `ENTRYPOINT [/debug_entrypoint.sh]` when building this image in interactive mode + + +### `terminal` +The `terminal` option expects an object having the following properties: +- `imageName` to select a container based on an image specified in `images` +- `labelSelector` to select a pod based a Kubernetes label selector +- `containerName` to select a container based on its name (optional, useful if pod has multiple containers) +- `namespace` to select a container from a namespace different than the default namespace of the current kube-context +- `command` defines a command to run when starting the terminal session (default: `/bin/bash` with fallback `/bin/sh`) + +:::info Combine Options +The first four options are used to select the appropriate pod / container. If you specify multiple these config options, they will be jointly used to select the pod / container (think logical `AND / &&`). +::: + +:::note Command Termination +If `command` is a non-interactive command that terminates, DevSpace will run the command and exits after the command has terminated. +::: + +#### Example: Configuring Terminal for Interactive Mode +```yaml {25-27} +images: + frontend: + image: dscr.io/${DEVSPACE_USERNAME}/appfrontend + backend: + image: john/appbackend + database: + image: john/database +deployments: +- name: app-frontend + helm: + componentChart: true + values: + containers: + - image: dscr.io/${DEVSPACE_USERNAME}/appfrontend +- name: app-backend + helm: + componentChart: true + values: + containers: + - image: john/appbackend + name: some-container + - image: john/appbackend-sidecar +dev: + interactive: + terminal: + imageName: backend + containerName: some-container +``` +**Explanation:** +The above configuration would open the container with name `some-container` that belongs to the deployment `app-backend` when running `devspace dev -i`. + + +### `defaultEnabled` +The `defaultEnabled` option expects a boolean that determines if interactive mode should be started by default even if no `-i / --interactive` flag was provided. + +#### Default Value For `defaultEnabled` +```yaml +defaultEnabled: false +``` + +#### Example: Enabling Interactive Mode By Default +```yaml +images: + backend: + image: john/appbackend +deployments: +- name: app-backend + helm: + componentChart: true + values: + containers: + - image: john/appbackend + name: some-container + - image: john/appbackend-sidecar +dev: + interactive: + defaultEnabled: true + images: + - name: backend + entrypoint: + - /debug_entrypoing.sh + terminal: + imageName: backend + containerName: some-container +``` +**Explanation:** +Running `devspace dev` with the above configuration leads to: +- during image building: the overrides defined in `images` would be applied +- after deployment: an interactive terminal session for a container with name `some-container` and with image `john/appbackend` would be started diff --git a/docs/versioned_docs/version-4.13/configuration/development/log-streaming.mdx b/docs/versioned_docs/version-4.13/configuration/development/log-streaming.mdx new file mode 100644 index 0000000000..68fa14538c --- /dev/null +++ b/docs/versioned_docs/version-4.13/configuration/development/log-streaming.mdx @@ -0,0 +1,153 @@ +--- +title: Configure Log Streaming +sidebar_label: logs +--- + +By default, DevSpace streams the logs of all containers that use one of the images defined in the `images` section of the `devspace.yaml`. + +To control which container logs should be streamed, you can configure the `dev.logs` section in the `devspace.yaml`. +```yaml {9-13} +images: + frontend: + image: dscr.io/${DEVSPACE_USERNAME}/appfrontend + backend: + image: john/appbackend + database: + image: john/database +dev: + logs: + showLast: 200 + images: + - backend + - frontend +``` + + +## Configuration + +### `images` +The `images` option expects an array of strings with image names. DevSpace uses this list to determine which containers to use for the multi-container log streaming. + +:::info +By default, DevSpace streams the logs of **all** containers that are created based on images defined in the `images` section of the `devspace.yaml`. +::: + +#### Example: Stream Only Containers Using Specified Images +```yaml {2,4,35-38} +images: + frontend: + image: dscr.io/${DEVSPACE_USERNAME}/appfrontend + backend: + image: john/appbackend + database: + image: john/database +deployments: +- name: app-frontend + helm: + componentChart: true + values: + containers: + - image: dscr.io/${DEVSPACE_USERNAME}/appfrontend +- name: app-backend + helm: + componentChart: true + values: + containers: + - image: john/appbackend + - image: john/appbackend-sidecar +- name: app-database + helm: + componentChart: true + values: + containers: + - image: john/database +- name: app-cache + helm: + componentChart: true + values: + containers: + - image: redis:5.0.5 +dev: + logs: + images: + - backend + - frontend +``` +**Explanation:** +- The above example defines 3 images and 5 deployments. +- The `images` option defines that only containers using the `image` value of the images `backend` and `frontend` should be streamed. +- The result would be that DevSpace streams the logs of: + - The container of deployment `app-frontend` because the image is `dscr.io/${DEVSPACE_USERNAME}/appfrontend` = `images.frontend.image` + - Only the first container of deployment `app-backend` because the image is `john/appbackend` = `images.backend.image` + +:::note +The **second** container of deployment `app-backend` would **not** be streamed in this example. +::: + + +### `showLast` +The `showLast` option expects an integer which defines how many log lines DevSpace will print for each container before starting to stream the container's logs in real-time. + +#### Default Value For `showLast` +```yaml +showLast: 50 +``` + +#### Example: Show Last 200 Log Lines +```yaml {22} +images: + frontend: + image: dscr.io/${DEVSPACE_USERNAME}/appfrontend + backend: + image: john/appbackend +deployments: +- name: app-frontend + helm: + componentChart: true + values: + containers: + - image: dscr.io/${DEVSPACE_USERNAME}/appfrontend +- name: app-backend + helm: + componentChart: true + values: + containers: + - image: john/appbackend + - image: john/appbackend-sidecar +dev: + logs: + showLast: 200 +``` +**Explanation:** +- The above example defines 2 images and 2 deployments. +- DevSpace would stream the logs of: + - The container of deployment `app-frontend` because the image is `dscr.io/${DEVSPACE_USERNAME}/appfrontend` = `images.frontend.image` + - Only the first container of deployment `app-backend` because the image is `john/appbackend` = `images.backend.image` +- For each of the two containers, DevSpace would print the last 200 log lines before starting to stream the logs + + +### `disabled` +The `disabled` option expects a boolean which defines if DevSpace should start multi-container log streaming when running `devspace dev` or if DevSpace should just start other services (e.g. port-forwarding and sync) without starting the log stream. + +#### Default Value For `disabled` +```yaml +disabled: false +``` + +#### Example: Disable Log Streaming +```yaml {14} +images: + backend: + image: john/appbackend +deployments: +- name: app-backend + helm: + componentChart: true + values: + containers: + - image: john/appbackend + - image: john/appbackend-sidecar +dev: + logs: + disabled: true +``` diff --git a/docs/versioned_docs/version-4.13/configuration/development/open-links.mdx b/docs/versioned_docs/version-4.13/configuration/development/open-links.mdx new file mode 100644 index 0000000000..41c1af1852 --- /dev/null +++ b/docs/versioned_docs/version-4.13/configuration/development/open-links.mdx @@ -0,0 +1,48 @@ +--- +title: Open Links in Browser +sidebar_label: open +--- + +import FragmentWorkflowOpenLinks from '../../fragments/workflow-open-links.mdx'; + +DevSpace allows you to define URLs that should open after deploying an application in development mode, i.e. using `devspace dev`. + +The configuration for automatically opening URLs can be found in the `dev.open` section of `devspace.yaml`. +```yaml +dev: + open: + - url: http://localhost:3000/ + - url: http://localhost:8089/ # DevSpace UI +``` + +:::note +Setting `dev.open` only affects `devspace dev`. To open your application after running `devspace deploy`, run `devspace open`. +::: + + +## Workflow + + + +## Configuration + +### `open` +The `open` option expects an array of auto-open configurations with exactly one of the following properties: +- `url` to open a URL in the default browser + +#### Default Value For `open` +```yaml +open: [] +``` + +#### Example: Open URL when Starting Dev Mode +```yaml +dev: + open: + - url: http://localhost:3000/login +``` +**Explanation:** +Running `devspace dev` using the above configuration would do the following: +- Build images and deploy the application +- Start port-forwarding and code-synchronization +- DevSpace opens the browser with URL `http://localhost:3000/login` diff --git a/docs/versioned_docs/version-4.13/configuration/development/port-forwarding.mdx b/docs/versioned_docs/version-4.13/configuration/development/port-forwarding.mdx new file mode 100644 index 0000000000..b352b28fe7 --- /dev/null +++ b/docs/versioned_docs/version-4.13/configuration/development/port-forwarding.mdx @@ -0,0 +1,176 @@ +--- +title: Configure Port-Forwarding +sidebar_label: ports[].forward +--- + +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`. +```yaml {15-19} +images: + backend: + image: john/devbackend + backend-debugger: + image: john/debugger +deployments: +- name: app-backend + helm: + componentChart: true + values: + containers: + - image: john/devbackend + - image: john/debugger +dev: + ports: + - imageName: backend + forward: + - port: 8080 + remotePort: 80 +``` + +:::warning Unique Local Port +The `port` option must be unique across your entire `ports` section, e.g. you can only use the value `8080` once for the `port` option in your `ports` section. +::: + +Every port-forwarding configuration consists of two parts: +- [Pod/Container Selection](#pod-selection) +- [Port Mapping via `port` (and optionally via `remotePort` and `bindAddress`)](#port-mapping-forward) + + +## Pod Selection +The following config options are needed to determine the pod to which the traffic should be forwarded: +- [`imageName`](#imagename) +- [`labelSelector`](#labelselector) +- [`namespace`](#namespace) + +:::info Combine Options +If you specify multiple of these config options, they will be jointly used to select the pod / container (think logical `AND / &&`). +::: + +:::info Auto Reconnect +If DevSpace is unable to establish a port-forwarding connection to the selected pod or loses it after starting the port-forwarding, DevSpace will try to restart port-forwarding several times. +::: + +### `imageName` +The `imageName` option expects a string with the name of an image from the `images` section of the `devspace.yaml`. Using `imageName` tells DevSpace to select the container/pod based on the referenced image that was last built using DevSpace. + +:::warning +Using `imageName` is not possible if multiple deployments use the same image that belongs to this `imageName` referencing the `images` section of the `devspace.yaml`. +::: + +#### Example: Select Pod by Image Name +```yaml {2,4,18,22} +images: + backend: + image: john/devbackend + backend-debugger: + image: john/debugger +deployments: +- name: app-backend + helm: + componentChart: true + values: + containers: + - name: container-0 + image: john/devbackend + - name: container-1 + image: john/debugger +dev: + ports: + - imageName: backend + forward: + - port: 8080 + remotePort: 80 + - imageName: backend-debugger + forward: + - port: 3000 +``` +**Explanation:** +- The above example defines two images that can be used as `imageName`: `backend` and `backend-debugger` +- The deployment starts two containers and each of them uses an image from the `images` section. +- The `imageName` option of the first port-forwarding configuration in the `dev.ports` section references `backend`. That means DevSpace would select the first container for port-forwarding, as this container uses the `image: john/devbackend` which belongs to the `backend` image as defined in the `images` section. +- The `imageName` option of the second port-forwarding configuration in the `dev.ports` section references `backend-debugger`. That means DevSpace would select the second container for port-forwarding, as this container uses the `image: john/debugger` which belongs to the `backend-debugger` image as defined in the `images` section. + +In consequence, the following port-forwarding processes would be started when using the above config example: +- `localhost:8080` forwards to `container-0:80` +- `localhost:3000` forwards to `container-1:3000` + + +### `labelSelector` +The `labelSelector` option expects a key-value map of strings with Kubernetes labels. + +#### Example: Select Pod by Label +```yaml {18-21} +images: + backend: + image: john/devbackend + backend-debugger: + image: john/debugger +deployments: +- name: app-backend + helm: + componentChart: true + values: + containers: + - name: container-0 + image: john/devbackend + - name: container-1 + image: john/debugger +dev: + ports: + - labelSelector: + app.kubernetes.io/name: devspace-app + app.kubernetes.io/component: app-backend + custom-label: custom-label-value + forward: + - port: 8080 + remotePort: 80 +``` +**Explanation:** +- The `labelSelector` would select the pod created for the component deployment `app-backend`. +- Because containers in the same pod share the same network stack, we do not need to specify which container should be selected. + + +### `namespace` +The `namespace` option expects a string with a Kubernetes namespace used to select the pod from. + +:::warning +It is generally **not** needed (nor recommended) to specify the `namespace` option because, by default, DevSpace uses the default namespace of your current kube-context which is usually the one that has been used to deploy your containers to. +::: + +## Port Mapping `forward` +The `forward` section defines which localhost `port` should be forwarded to the `remotePort` of the selected container. + +:::note +By default, `remotePort` will take the same value as `port` if `remotePort` is not explicitly defined. +::: + +### `port` +The `port` option is mandatory and expects an integer from the range of user ports [1024 - 49151]. + +:::warning +Using a `port` < 1024 is likely to cause problems as these ports are reserved as system ports. +::: + +#### Example +**See "[Example: Select Pod by Image Name](#example-select-pod-by-image-name)"** + + +### `remotePort` +The `remotePort` option expects an integer from the range of valid ports [0 - 65535]. + +:::info +By default, `remotePort` has the same value as `port` if `remotePort` is not explictly defined. +::: + +#### Example +**See "[Example: Select Pod by Image Name](#example-select-pod-by-image-name)"** + + +### `bindAddress` +The `bindAddress` option expects a valid IP address that the local port should be bound to. + +#### Default Value For `bindAddress` +```yaml +bindAddress: "0.0.0.0" # listen on all network interfaces +``` diff --git a/docs/versioned_docs/version-4.13/configuration/development/reverse-port-forwarding.mdx b/docs/versioned_docs/version-4.13/configuration/development/reverse-port-forwarding.mdx new file mode 100644 index 0000000000..c11e7d4120 --- /dev/null +++ b/docs/versioned_docs/version-4.13/configuration/development/reverse-port-forwarding.mdx @@ -0,0 +1,189 @@ +--- +title: Configure Reverse Port-Forwarding +sidebar_label: ports[].reverseForward +--- + +Reverse port-forwarding allows you to forward traffic from within your containers to your local machine. This can be useful when: +- using certain remote debuggers that connect to your IDE instead of the other way around +- developing a service on localhost which should be accessed from other services that run within the cluster, i.e. using the [Telepresence development model](https://www.telepresence.io/discussion/why-telepresence) but with DevSpace to get better performance and cross-platform support + +With reverse port-forwarding, you can access `localhost:[PORT]` inside the container and it will redirect to a program that runs on your local dev machine. + +When starting the development mode, DevSpace starts reverse port-forwarding as configured in the `dev.ports` section of the `devspace.yaml`. +```yaml {20-23} +images: + backend: + image: john/devbackend + backend-debugger: + image: john/debugger +deployments: +- name: app-backend + helm: + componentChart: true + values: + containers: + - image: john/devbackend + - image: john/debugger +dev: + ports: + - imageName: backend + forward: + - port: 8080 + remotePort: 80 + reverseForward: + - port: 5678 + remotePort: 5678 + - port: 3303 +``` + +:::warning Unique Remote Port +The `remotePort` option must be unique across your entire `ports` section for all selectors that match the same pods, e.g. you can only use the value `8080` once for the `remotePort` option in your `ports` section unless multiple port mappings target different pods. +::: + +Every reverse port-forwarding configuration consists of two parts: +- [Pod/Container Selection](#pod-selection) +- [Port Mapping via `port` (and optionally via `remotePort` and `bindAddress`)](#port-mapping-forward) + + +## Pod Selection +The following config options are needed to determine the pod from which the traffic should be forwarded to localhost: +- [`imageName`](#imagename) +- [`labelSelector`](#labelselector) +- [`containerName`](#containername) +- [`namespace`](#namespace) + +:::info Combine Options +If you specify multiple of these config options, they will be jointly used to select the pod / container (think logical `AND / &&`). +::: + +:::info Auto Reconnect +If DevSpace is unable to establish a reverse port-forwarding connection to the selected pod or loses it after starting the reverse port-forwarding, DevSpace will try to restart reverse port-forwarding several times. +::: + +### `imageName` +The `imageName` option expects a string with the name of an image from the `images` section of the `devspace.yaml`. Using `imageName` tells DevSpace to select the container/pod based on the referenced image that was last built using DevSpace. + +:::warning +Using `imageName` is not possible if multiple deployments use the same image that belongs to this `imageName` referencing the `images` section of the `devspace.yaml`. +::: + +#### Example: Select Pod by Image Name +```yaml {2,4,18,22} +images: + backend: + image: john/devbackend + backend-debugger: + image: john/debugger +deployments: +- name: app-backend + helm: + componentChart: true + values: + containers: + - name: container-0 + image: john/devbackend + - name: container-1 + image: john/debugger +dev: + ports: + - imageName: backend + reverseForward: + - port: 8080 + remotePort: 80 + - imageName: backend-debugger + reverseForward: + - port: 3000 +``` +**Explanation:** +- The above example defines two images that can be used as `imageName`: `backend` and `backend-debugger` +- The deployment starts two containers and each of them uses an image from the `images` section. +- The `imageName` option of the first reverse port-forwarding configuration in the `dev.ports` section references `backend`. That means DevSpace would select the first container for reverse port-forwarding, as this container uses the `image: john/devbackend` which belongs to the `backend` image as defined in the `images` section. +- The `imageName` option of the second reverse port-forwarding configuration in the `dev.ports` section references `backend-debugger`. That means DevSpace would select the second container for reverse port-forwarding, as this container uses the `image: john/debugger` which belongs to the `backend-debugger` image as defined in the `images` section. + +In consequence, the following reverse port-forwarding processes would be started when using the above config example: +- `localhost:80` inside the container will forward to `localhost:8080` on your local machine +- `localhost:3000` inside the container will forward to `localhost:3000` on your local machine + + +### `labelSelector` +The `labelSelector` option expects a key-value map of strings with Kubernetes labels. + +#### Example: Select Pod by Label +```yaml {18-21} +images: + backend: + image: john/devbackend + backend-debugger: + image: john/debugger +deployments: +- name: app-backend + helm: + componentChart: true + values: + containers: + - name: container-0 + image: john/devbackend + - name: container-1 + image: john/debugger +dev: + ports: + - labelSelector: + app.kubernetes.io/name: devspace-app + app.kubernetes.io/component: app-backend + custom-label: custom-label-value + reverseForward: + - port: 8080 + remotePort: 80 +``` +**Explanation:** +- The `labelSelector` would select the pod created for the component deployment `app-backend`. +- Because containers in the same pod share the same network stack, we do not need to specify which container should be selected. + + +### `containerName` +The `containerName` option expects a string with the name of the container to use within the pod selected by `labelSelector`. This option is not required if `imageName` is used or there is only one container inside the selected pod. + + +### `namespace` +The `namespace` option expects a string with a Kubernetes namespace used to select the pod from. + +:::warning +It is generally **not** needed (nor recommended) to specify the `namespace` option because, by default, DevSpace uses the default namespace of your current kube-context which is usually the one that has been used to deploy your containers to. +::: + +## Port Mapping `reverseForward` +The `reverseForward` section defines which `remotePort` inside the selected container should be forwarded to the `port` on your local machine. + +:::note +By default, `remotePort` will take the same value as `port` if `remotePort` is not explicitly defined. +::: + +### `port` +The `port` option is mandatory and expects an integer from the range of user ports [1024 - 49151]. + +:::warning +Using a `port` < 1024 is likely to cause problems as these ports are reserved as system ports. +::: + +#### Example +**See "[Example: Select Pod by Image Name](#example-select-pod-by-image-name)"** + + +### `remotePort` +The `remotePort` option expects an integer from the range of valid ports [0 - 65535]. + +:::info +By default, `remotePort` has the same value as `port` if `remotePort` is not explictly defined. +::: + +#### Example +**See "[Example: Select Pod by Image Name](#example-select-pod-by-image-name)"** + + +### `bindAddress` +The `bindAddress` option expects a valid IP address that the local port should be bound to. + +#### Default Value For `bindAddress` +```yaml +bindAddress: "0.0.0.0" # listen on all network interfaces +``` diff --git a/docs/versioned_docs/version-4.13/configuration/env-file.mdx b/docs/versioned_docs/version-4.13/configuration/env-file.mdx new file mode 100644 index 0000000000..d196a4fc62 --- /dev/null +++ b/docs/versioned_docs/version-4.13/configuration/env-file.mdx @@ -0,0 +1,30 @@ +--- +title: Environment Variable File +sidebar_label: .env +--- + +Besides reading environment variables available in your terminal session, DevSpace also reads environment variables from the `.env` file inside your project. The syntax of the `.env` file is the [same as for docker-compose](https://docs.docker.com/compose/env-file/): + +- Each line should have the format `VAR_NAME=VAR_VALUE`. +- **There is *no* special handling of quotation marks. This means that they are part of the `VAR_VALUE`.** +- Lines beginning with # are processed as comments and ignored. + +## Precedence +- Environment variables defined in your terminal session (including system variables) always take precendence over the variables in your `.env` file. +- Variables defined in your `.env` file take precende over the default values defined for config variables (configured in the `vars` section of `devspace.yaml`). + +## Define Default Flags +A common use case for the `.env` file is to set default flags for the `devspace` commands such as `devspace dev` or `devspace deploy`. You can define the following environment variables to set default flags: +- `DEVSPACE_FLAGS` for global flags that should be added to each commands (e.g. `DEVSPACE_FLAGS=-s -p dev`) +- `DEVSPACE_[COMMAND]_FLAGS` to add default flags for single commands (e.g. `DEVSPACE_DEV_FLAGS=-s --verbose-dependencies`) + +:::note Overriding Default Flags +Specifying flags for a command will override the default flags, e.g. if `DEVSPACE_FLAGS=-s -p dev` is configured and you run `devspace dev -p production`, the following command would be executed: `devspace dev -s -p production` +::: + +#### Example: Setting Default Flags for DevSpace +```bash +# File: .env +DEVSPACE_FLAGS=-s -p dev +DEVSPACE_DEV_FLAGS=-s --verbose-dependencies +``` diff --git a/docs/versioned_docs/version-4.13/configuration/hooks/basics.mdx b/docs/versioned_docs/version-4.13/configuration/hooks/basics.mdx new file mode 100644 index 0000000000..ef70128e39 --- /dev/null +++ b/docs/versioned_docs/version-4.13/configuration/hooks/basics.mdx @@ -0,0 +1,33 @@ +--- +title: Hooks +sidebar_label: hooks +--- + +DevSpace allows you to define execution of custom commands during certain lifecycle events. This makes it possible to customize the deployment and development process with DevSpace. + +Hooks can be defined in the `hooks` section of `devspace.yaml`: +```yaml +hooks: +- command: echo + args: + - before image building + when: + before: + images: all +``` + +:::note Example Project +For a complete example take a look at [this example project on GitHub](https://github.com/devspace-cloud/devspace/tree/master/examples/hooks). +::: + +This tells DevSpace to execute the command `echo before image building` before any image will be built. You are able to define hooks for the following life cycle events: +- **before image building**: Will be executed before building any images. Value: `when.before.images: all` +- **after image building**: Will be executed after images have been successfully built. Value: `when.after.images: all` +- **before deploying**: Will be executed before any deployment is deployed. Value: `when.before.deployments: all` +- **after deploying**: Will be executed after all deployments are deployed. Value: `when.after.deployments: all` +- **before certain deployment**: Will be executed before a certain deployment is deployed. Value: `when.before.deployments: my-deployment` +- **after certain deployment**: Will be executed after a certain deployment is deployed. Value: `when.after.deployments: my-deployment` + +:::info Errors in Hooks +If any hook returns a non zero exit code, DevSpace will abort and print an error message. +::: diff --git a/docs/versioned_docs/version-4.13/configuration/images/append-dockerfile-instructions.mdx b/docs/versioned_docs/version-4.13/configuration/images/append-dockerfile-instructions.mdx new file mode 100644 index 0000000000..78fc212199 --- /dev/null +++ b/docs/versioned_docs/version-4.13/configuration/images/append-dockerfile-instructions.mdx @@ -0,0 +1,18 @@ +--- +title: Append Build Instructions In-Memory +sidebar_label: appendDockerfileInstructions +--- + + +## `appendDockerfileInstructions` +The `appendDockerfileInstructions` expects an array of strings with each string containing a Dockerfile instruction, e.g. `RUN chmod...`, `USER root`. + +This option is very useful to add development-specific instructions (installing dev tooling like debuggers, setting a different runtime user for the container etc.) without the need to change the actual Dockerfile. + +:::info In-Memory +DevSpace adds these instructions dynamically to your Dockerfile when building images. However, this happens in-memory and does **not** change the Dockerfile. +::: + +:::tip Combination with Profiles +It is often useful to create a [profile](../profiles/basics.mdx) `production` with a patch that removes the `appendDockerfileInstructions` entirely. This way, you can also evaluate what you are working on in a more production-like way using a single command: `devspace deploy -p production` +::: diff --git a/docs/versioned_docs/version-4.13/configuration/images/basics.mdx b/docs/versioned_docs/version-4.13/configuration/images/basics.mdx new file mode 100644 index 0000000000..598c1feb6d --- /dev/null +++ b/docs/versioned_docs/version-4.13/configuration/images/basics.mdx @@ -0,0 +1,217 @@ +--- +title: Image Building +sidebar_label: Basics +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; +import FragmentFaqImageContext from '../../fragments/faq-image-context.mdx'; +import WarningBuildToolPriority from '../../fragments/warning-build-tool-priority.mdx'; + +Images are configured within the `images` section of the `devspace.yaml`. + +## Examples + + + + +```yaml {3} +images: + backend: + image: my-docker-username/appbackend + database: + image: my-docker-company/appbackend +``` + + + + +```yaml {3} +images: + backend: + image: image.company.tld/appbackend + database: + image: image.company.tld/appbackend +``` + + + + +```yaml {4-6} +images: + backend: + image: image.company.tld/appbackend + tags: + - latest + - dev-${DEVSPACE_GIT_COMMIT}-${DEVSPACE_RANDOM} + database: + image: image.company.tld/appbackend +``` + + + + +```yaml {4-6} +images: + backend: + image: john/appbackend + build: + kaniko: + cache: true +``` + +:::info What is kaniko? +Kaniko is an open-source tool that lets you build images inside containers that run on top of Kubernetes. DevSpace uses kaniko as automatic fallback if Docker is not installed. To force image building using kaniko, set `build.kaniko.cache: true` as shown above. Learn more about [configuring kaniko builds](../../configuration/images/kaniko.mdx). +::: + + + + +```yaml {4-11} +images: + backend: + image: john/appbackend + build: + custom: + command: ./build + args: + - "--arg1" + - "arg-value-1" + - "--arg2" + - "arg-value-2" +``` + + + + +```yaml {5} +images: + frontend: + image: dscr.io/${DEVSPACE_USERNAME}/appfrontend + build: + disabled: true + backend: + image: john/appbackend +``` + + + + +:::note Parallel Image Building +To speed up the build process, the images you specify under `images` will all be built in parallel (unless you use the `--build-sequential` flag). +::: + + + + +## Run Image Building +When you run one of the following commands, DevSpace will run the image building process: +- `devspace build` (only image building without deployment) +- `devspace deploy` (before deploying the application) +- `devspace dev` (before deploying the application and starting the development mode) + +### Important Flags +The following flags are available for all commands that trigger image building: +- `--build-sequential` build images sequentially instead of in parallel (provides more detailed logs for each image) +- `-b / --force-build` rebuild all images (even if they could be skipped because context and Dockerfile have not changed since the latest build) + +## Image Building Process +DevSpace loads the `images` configuration from `devspace.yaml` and builds all images in parallel. The multi-threaded, parallel build process of DevSpace speeds up image building drastically, especially when building many images and using remote build methods. + +### 1. Load Dockerfile +DevSpace loads the contents of the Dockerfile specified in `image[*].dockerfile` (defaults to `./Dockerfile`). + +:::info Use Relative Paths +Dockerfile paths used in `dockerfile` should be relative to the `devspace.yaml`. +::: + +### 2. Override Entrypoint (if needed) +DevSpace allows you to apply an in-memory override of a Dockerfile's `ENTRYPOINT` by configuring the `entrypoint` option for the image. Similar to the Dockerfile `ENTRYPOINT`, the `images[*].entrypoint` option should be defined as an array. + +:::note Useful for Profiles +Configuring `ENTRYPOINT` overrides can be particularly useful when defining different [config profiles](../../configuration/profiles/basics.mdx) in your `devspace.yaml`. +::: + +### 3. Load Build Context +DevSpace loads the context to build this image as specified in `context` (defaults to `./`). The context path serves as root directory for Dockerfile statements like `ADD` or `COPY`. + +:::info Use Relative Paths +Context paths used in `context` should be relative to the `devspace.yaml`. +::: + + + +### 4. Skip Build & Push (if possible) +DevSpace tries to speed up image building by skipping images when they have not changed since the last build process. To do this, DevSpace caches the following information after building an image: +- a hash of the `Dockerfile` used to build the image (including ENTRYPOINT override) +- a hash over all files in the `context` used to build this image (excluding files in `.dockerignore`) + +The next time you trigger the image building process, DevSpace will generate these hashes again and compare them to the hashes of the last image building process. If all newly generated hashes are equal to the old ones stored during the last image building process, then nothing has changed and DevSpace will skip this image. + +:::note Force Build +You can use the `-b / --force-build` flag to tell DevSpace to build all images even if nothing has changed. +::: + +### 5. Build Image +DevSpace uses one of the following [build tools](../../configuration/images/basics.mdx) to create an image based on your Dockerfile and the provided context: +- [`docker`](../../configuration/images/docker.mdx) for building images using a Docker daemon (default, prefers Docker daemon of local Kubernetes clusters) +- [`kaniko`](../../configuration/images/kaniko.mdx) for building images directly inside Kubernetes (automatic fallback for `docker`) +- [`custom`](../../configuration/images/custom.mdx) for building images with a custom build command (e.g. for using Google Cloud Build) +- [`disabled`](../../configuration/images/disabled.mdx) if this image should not be built (especially useful for [config `profiles`](../../configuration/profiles/basics.mdx)) + +### 6. Tag Image +DevSpace automatically tags all images after building them using a tagging schema that you can customize using the `tag` option. By default, this option is configured to generate a random string consisting of 5 characters. + +[Learn more about defining a custom tagging schema.](../../configuration/images/image-tagging.mdx#tag-tagging-schema) + +:::info Tag Replacement +Before deploying your application, DevSpace will use the newly generated image tags and replace them in-memory in the values for your [Helm charts](../../configuration/deployments/helm-charts.mdx) and [Kubernetes manifests](../../configuration/deployments/kubernetes-manifests.mdx), so they will be deployed using the newest image tag. +::: + +### 7. Push Image +DevSpace automatically pushes your images to the respective registry that should be specified as part of the `image` option. Just as with regular Docker images, DevSpace uses Docker Hub if no registry hostname is provided within `image`. + + +:::note +You can skip this step when proving the `--skip-push` flag. Beware that deploying your application after using `--skip-push` will only work when your images have already been pushed to the registry or when you are using a local Kubernetes cluster (e.g. minikube). +::: + +### 8. Create Pull Secrets +When deploying your application via DevSpace, Kubernetes needs to be able to pull your images from the registry that is used to store your images when pushing them. For this purpose, Kubernetes relies on so-called image pull secrets. DevSpace can automatically create these secrets for you, if you configure `createPullSecret: true` for the respective image in your `devspace.yaml`. + +:::note +You do **not** need to change anything in your Kubernetes manifests or Helm charts to use the image pull secrets that DevSpace creates because DevSpace [adds these secrets to the default service account in the namespace](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) used to deploy your project. + +After running `devspace build`, `devspace deploy` or `devspace dev`, you should be able to see the auto-generated pull secrets created by DevSpace when you run the following command: +```bash +kubectl get serviceaccount default -o yaml +``` +Take a look at the `imagePullSecrets` section of the output showing the yaml definition of the service account `default`. +::: + +## Advanced Topics + +### Authentication (Registry) +DevSpace uses the same credential store as Docker. So, if you already have Docker installed and you have logged in to a private registry before, DevSpace will be able to push to this registry. So, if you want to push to a registry using DevSpace, simply authenticate using this command: +```bash +docker login # for Docker Hub +docker login [REGISTRY] # for any other registry (e.g. my-registry.tld) +``` + +:::note +If you do **not** have Docker installed, DevSpace initializes a Docker credential store for you and stores your login information just like Docker would do it. +::: + + +### Skip Push (Local Clusters) +If you are using a local Kubernetes cluster, DevSpace will try to build the image using the Docker deamon of this local cluster. If this process is successful, DevSpace will skip the step of pushing the image to a registry as it is not required for deploying your application. diff --git a/docs/versioned_docs/version-4.13/configuration/images/custom.mdx b/docs/versioned_docs/version-4.13/configuration/images/custom.mdx new file mode 100644 index 0000000000..05008433fd --- /dev/null +++ b/docs/versioned_docs/version-4.13/configuration/images/custom.mdx @@ -0,0 +1,133 @@ +--- +title: Custom Build Scripts +sidebar_label: custom +--- + +## `custom` +Using `custom` as build tool allows you to define a custom command for building images. This is particularly useful if you want to use a remote build system such as Google Cloud Build. + +:::warning +Make sure your `custom` build command terminates with exit code 0 when the build process was successful. +::: + +### `command` +The `onChange` option expects an array of strings which represent paths to files or folders that should be watched for changes. DevSpace uses these paths and the hash values it stores about these paths for evaluating if an image should be rebuilt or if the image building can be skipped because the context of the image has not changed. + +:::info +It is highly recommended to specify this option when using `custom` as build tool in order to speed up the build process. +::: + +#### Example: Building Images With `custom` Build Command +```yaml +images: + backend: + image: john/appbackend + build: + custom: + command: ./build + args: + - "--arg1" + - "--flag" + - "flag-value" + - "--arg2" +``` +**Explanation:** +The image `backend` would be built using the command `./build arg1 --flag=flag-value arg2 "[IMAGE]:[TAG]"` while `[IMAGE]` would be replaced with the `image` option (in this case: `john/appbackend`) and `[TAG]` would be replaced with the tag generated according to the [tagging schema](../../configuration/images/basics.mdx#6-tag-image). + + +### `imageFlag` +The `onChange` option expects a string which states the name of the flag that is used to pass the image name (including auto-generated tag) to the custom build script defined in `command`. + +#### Default Value For `imageFlag` +```yaml +imageFlag: "" # Defaults to passing image and tag as an argument instead of using a flag +``` + +#### Example: Defining `imageFlag` For `custom` Build Command +```yaml +images: + backend: + image: john/appbackend + build: + custom: + command: ./build + imageFlag: image + args: + - "--arg1" + - "--flag" + - "flag-value" + - "--arg2" +``` +**Explanation:** +The image `backend` would be built using the command `./build arg1 --flag=flag-value arg2 --image="[IMAGE]:[TAG]"` while `[IMAGE]` would be replaced with the `image` option (in this case: `john/appbackend`) and `[TAG]` would be replaced with the tag generated according to the [tagging schema](../../configuration/images/basics.mdx#6-tag-image). + + +### `args` +The `args` option expects an array of strings which represent additional flags and arguments that should be passed to the custom build command **before** the argument containing `[IMAGE]:[TAG]`. + +#### Default Value For `args` +```yaml +args: [] +``` + +#### Example: Using `args` and `appendArgs` For Custom Builds +```yaml +images: + backend: + image: john/appbackend + build: + custom: + command: ./build + args: + - "--flag1" + - "flag-value-1" + - "arg1" + - "arg2" + appendArgs: + - "arg3" + - "--flag2" + - "flag-value-2" +``` +**Explanation:** +The image `backend` would be built using the command `./build --flag1=flag-value-1 arg1 arg2 [IMAGE]:[TAG] arg3 --flag2=flag-value-2` while `[IMAGE]` would be replaced with the `image` option (in this case: `john/appbackend`) and `[TAG]` would be replaced with the tag generated according to the [tagging schema](../../configuration/images/basics.mdx#6-tag-image). + + +### `appendArgs` +The `appendArgs` option expects an array of strings which represent additional flags and arguments that should be passed to the custom build command **after** the argument containing `[IMAGE]:[TAG]`. + +#### Default Value For `appendArgs` +```yaml +appendArgs: [] +``` + +#### Example +**See "[Example: Using `args` and `appendArgs` For Custom Builds](#example-using-args-and-appendargs-for-custom-builds)"** + + +### `onChange` +The `onChange` option expects an array of strings which represent paths to files or folders that should be watched for changes. DevSpace uses these paths and the hash values it stores about these paths for evaluating if an image should be rebuilt or if the image building can be skipped because the context of the image has not changed. + +:::info +It is highly recommended to specify this option when using `custom` as build tool in order to speed up the build process. +::: + +#### Default Value For `onChange` +```yaml +onChange: [] +``` + +#### Example: OnChange Option For custom Build Command +```yaml +images: + backend: + image: john/appbackend + build: + custom: + command: ./build + imageFlag: image + onChange: + - some/path/ + - another/path/file.txt +``` +**Explanation:** +The image `backend` would be built using the command `./build --image="[IMAGE]:[TAG]"` and DevSpace would skip the build if none of the files within `some/path/` nor the file `another/path/file.txt` has changed since the last build. diff --git a/docs/versioned_docs/version-4.13/configuration/images/disabled.mdx b/docs/versioned_docs/version-4.13/configuration/images/disabled.mdx new file mode 100644 index 0000000000..2ed8096497 --- /dev/null +++ b/docs/versioned_docs/version-4.13/configuration/images/disabled.mdx @@ -0,0 +1,26 @@ +--- +title: Disable Image Building +sidebar_label: disabled +--- + +## `disabled` +The `disabled` option expects a boolean and allows you to disable image building for an image. + +#### Default Value For `disabled` +```yaml +disabled: false +``` + +#### Example: Disabling Image Building +```yaml +images: + frontend: + image: dscr.io/${DEVSPACE_USERNAME}/appfrontend + build: + disabled: true + backend: + image: john/appbackend +``` +**Explanation:** +- The first image `frontend` would not be built at all. +- The second image `backend` would be built using [`docker`](../../configuration/images/docker.mdx) because nothing is specified and `docker` is the default build tool for images. diff --git a/docs/versioned_docs/version-4.13/configuration/images/docker.mdx b/docs/versioned_docs/version-4.13/configuration/images/docker.mdx new file mode 100644 index 0000000000..3d1bea3fa3 --- /dev/null +++ b/docs/versioned_docs/version-4.13/configuration/images/docker.mdx @@ -0,0 +1,171 @@ +--- +title: Build Images with Docker +sidebar_label: docker +--- + +import FragmentBuildOptionsTarget from '../../fragments/build-option-target.mdx'; +import FragmentBuildOptionsNetwork from '../../fragments/build-option-network.mdx'; +import FragmentBuildOptionsBuildArgs from '../../fragments/build-option-buildArgs.mdx'; + +## `docker` +If nothing is specified, DevSpace always tries to build the image using `docker` as build tool. + + +### `useBuildKit` +The `useBuildKit` option expects a boolean which allows to enable buildkit builds (i.e. `DOCKER_BUILDKIT=1`). + +#### Default Value For `useBuildKit` +```yaml +useBuildKit: false +``` + +#### Example: Docker useBuildKit +```yaml +images: + backend: + image: john/appbackend + build: + docker: + useBuildKit: true +``` + + +### `args` +The `args` option expects an array of strings to be passed as arguments and flags to Docker. + +:::warning +When specifying `args`, DevSpace will invoke your installed Docker CLI via a command-line call instead of using the built-in Docker client. This has the negative effects that: +- The kaniko fallback will not be used anymore. +- You need to make sure that everyone who is using this configuration has the same version (or a compatible one) of Docker installed. +::: + +#### Example: Docker args +```yaml +images: + backend: + image: john/appbackend + build: + docker: + args: + - "--no-cache" + - "--compress" +``` + + +### `disableFallback` +When using `docker` as build tool, DevSpace checks if Docker is installed and running. If Docker is not installed or not running, DevSpace will use kaniko as fallback to build the image unless the option `disableFallback` is set to `false`. + +#### Default Value For `disableFallback` +```yaml +disableFallback: false +``` + +#### Example: Disabling kaniko Fallback +```yaml +images: + backend: + image: john/appbackend + frontend: + image: dscr.io/${DEVSPACE_USERNAME}/appfrontend + build: + docker: + disableFallback: true +``` +**Explanation:** +- The first image `backend` would be built using Docker and if Docker is not available, the image would be built using kaniko as a fallback. +- The second image `frontend` would be built using Docker and if Docker is not available, DevSpace would exit with a fatal error instead of using the kaniko fallback. + + +### `preferMinikube` +DevSpace preferably uses the Docker daemon running in the virtual machine that belongs to your local Kubernetes cluster instead of your regular Docker daemon. This has the advantage that images do not need to be pushed to a registry because Kubernetes can simply use the images available in the Docker daemon belonging to the kubelet of the local cluster. Using this method is only possible when your current kube-context points to a local Kubernetes cluster and is named `minikube`, `docker-desktop` or `docker-for-desktop`. + +#### Default Value For `preferMinikube` +```yaml +preferMinikube: true +``` + +#### Example: Building Images in Minikube +```yaml +images: + backend: + image: john/appbackend + build: + docker: + preferMinikube: true + frontend: + image: dscr.io/${DEVSPACE_USERNAME}/appfrontend + build: + docker: + preferMinikube: false +``` +**Explanation:** +- The first image `backend` would be preferably built with Minikube's Docker daemon and the image would **not** be pushed to a registry. +- The second image `frontend` would **not** be built with the Docker daemon of Minikube and it would be pushed to a registry after building and tagging the image using Docker (or kaniko as fallback). + +### `skipPush` +The `skipPush` option expects a boolean value stating if pushing the image to a registry should be skipped during the build process. + +If DevSpace is using a local Kubernetes cluster, pushing images might not be necessary because the image might already be accessible by Kubernetes via a local Docker daemon. In this case, it can make sense to speed up the process by setting `skipPush` to `true`. + +:::info Auto-Enabled for Minikube & Docker Desktop +DevSpace automatically skips image push for kube-contexts with the following names: +- `minikube` +- `docker-desktop` +- `docker-for-desktop` + +This allows to keep `skipPush: false` for these local clusters which helps to keep the configuration reusable and indepent of the kube-context, i.e. it makes it easier to switch between local and remote clusters. +::: + +:::warning Remote Clusters +Setting this option means that the configuration cannot be used to deploy to remote clusters anymore, which makes it harder to switch between clusters and keep the configuration cluster-independent. +::: + +#### Default Value For `skipPush` +```yaml +skipPush: false +``` + +#### Example +```yaml {7} +images: + backend: + image: john/appbackend + build: + docker: + preferMinikube: true + skipPush: true + frontend: + image: dscr.io/${DEVSPACE_USERNAME}/appfrontend + build: + docker: + preferMinikube: false +``` +The above configration would only push the `frontend` image but not the `backend` image. To manually trigger image building and pushing for all images, run: +```bash +devspace build +``` + + + +
+ +## Build Options +DevSpace allows you to configure the following build options: +- `target` defining the build target for multi-stage builds +- `network` to define which network to use during building (e.g. `docker build --network=host`) +- `buildArgs` to pass arguments to the Dockerfile during the build process + + +### `target` + + + + +### `network` + + + + +### `buildArgs` + + diff --git a/docs/versioned_docs/version-4.13/configuration/images/dockerfile-context.mdx b/docs/versioned_docs/version-4.13/configuration/images/dockerfile-context.mdx new file mode 100644 index 0000000000..40971daa0b --- /dev/null +++ b/docs/versioned_docs/version-4.13/configuration/images/dockerfile-context.mdx @@ -0,0 +1,52 @@ +--- +title: Configure Dockerfile & Context +sidebar_label: dockerfile + context +--- + +import FragmentFaqImageContext from '../../fragments/faq-image-context.mdx'; + +## `dockerfile` +The `dockerfile` option expects a string with a path to a `Dockerfile`. +- The path in `dockerfile` should be relative to the `devspace.yaml`. +- When setting the `dockerfile` option, it is often useful to set the [`context` option](#context) as well. +- To share your configuration with team mates, make sure `devspace.yaml` and all `Dockerfiles` used in the `images` section are checked into your code repository. + +#### Default Value For `dockerfile` +```yaml +dockerfile: ./Dockerfile +``` + +#### Example: Different Dockerfile +```yaml +images: + backend: + image: john/appbackend + frontend: + image: dscr.io/${DEVSPACE_USERNAME}/appfrontend + dockerfile: frontend/Dockerfile + context: frontend/ +``` +**Explanation:** +- The first image would be built using the Dockerfile in `./Dockerfile` and the context path `./`. +- The second image would be built using the Dockerfile in `./frontend/Dockerfile` and the context path `./frontend/`. +- Switching the `context` for image `frontend` would assure that a statement like `ADD file.txt` or `COPY file.txt .` in `./frontend/Dockerfile` would use the local file `./frontend/file.txt` instead of `./file.txt`. +- In this example, it would probably be useful to have a `./.dockerignore` file which ignores the `frontend/` folder when building the first image called `backend`. + +:::note +See **[Best Practices for Image Building](../../guides/image-building.mdx)** for details on how to optimize your Dockerfiles and use `.dockerignore` for faster image building. +::: + + + +## `context` +The `context` option expects a string with a path to the folder used as context path when building the image. The context path serves as root directory for Dockerfile statements like ADD or COPY. + + + +#### Default Value For `context` +```yaml +context: ./ +``` + +#### Example +**See "[Example: Different Dockerfiles](#example-different-dockerfile)"** diff --git a/docs/versioned_docs/version-4.13/configuration/images/entrypoint-cmd.mdx b/docs/versioned_docs/version-4.13/configuration/images/entrypoint-cmd.mdx new file mode 100644 index 0000000000..91fbd8b243 --- /dev/null +++ b/docs/versioned_docs/version-4.13/configuration/images/entrypoint-cmd.mdx @@ -0,0 +1,64 @@ +--- +title: Override ENTRYPOINT and CMD +sidebar_label: entrypoint + cmd +--- + +:::warning +If you are overriding the Dockerfile `ENTRYPOINT` or `CMD`, it only affects the image but **not** the deployment in Kubernetes. If a deployment using this image defines the `command` or `args` options, they will take precedence over the overrides you define for the image. +::: + +### `entrypoint` +The `entrypoint` option expects an array of strings which tells DevSpace to override the `ENTRYPOINT` defined in the `Dockerfile` during the image building process. + +:::note +If you are overriding the `ENTRYPOINT`, it is often useful to also [override the `CMD` statement](#cmd). If you want to define `entrypoint: ...` for an image and you do **not** want the `CMD` statement from the Dockerfile, add `cmd: []` to the image configuration in your `devspace.yaml`. +::: + +#### Default Value For `entrypoint` +```yaml +entrypoint: [] +``` + +#### Example: Override ENTRYPOINT For Image +```yaml +images: + backend: + image: john/appbackend + frontend: + image: dscr.io/${DEVSPACE_USERNAME}/appfrontend + entrypoint: + - npm + - run + - dev +``` +**Explanation:** +- The first image `backend` will be built using the regular `ENTRYPOINT` (e.g. `[npm, start]`) defined by the Dockerfile located in `./Dockerfile` +- The second image `frontend` will be built using the same Dockerfile but instead of the original `ENTRYPOINT`, DevSpace would use the `[npm, run, dev]` as value for `ENTRYPOINT` + + +## `cmd` +The `cmd` option expects an array of strings which tells DevSpace to override the `CMD` defined in the `Dockerfile` during the image building process. + +:::note +`CMD` generally defines the arguments for `ENTRYPOINT`. +::: + +#### Default Value For `cmd` +```yaml +cmd: [] +``` + +#### Example: Override CMD For Image +```yaml +images: + backend: + image: john/appbackend + frontend: + image: dscr.io/${DEVSPACE_USERNAME}/appfrontend + cmd: + - run + - dev +``` +**Explanation:** +- The first image `backend` will be built using the regular `CMD` (e.g. `[start]`) for `ENTRYPOINT` (e.g. `[npm]`) defined by the Dockerfile located in `./Dockerfile` +- The second image `frontend` will be built using the same Dockerfile but instead of the original `CMD`, DevSpace would use the `[run, dev]` as value for `CMD` diff --git a/docs/versioned_docs/version-4.13/configuration/images/image-tagging.mdx b/docs/versioned_docs/version-4.13/configuration/images/image-tagging.mdx new file mode 100644 index 0000000000..d1ca0e0c8d --- /dev/null +++ b/docs/versioned_docs/version-4.13/configuration/images/image-tagging.mdx @@ -0,0 +1,69 @@ +--- +title: Image Name & Tagging Schema +sidebar_label: image + tags +--- + +The `images` section in `devspace.yaml` is a map with keys representing the name of the image and values representing the image definition including `tag`, `dockerfile` etc. +```yaml +images: # map[string]struct | Images to be built and pushed + image1: # string | Name of the image + image: dscr.io/username/image # string | Image repository and name + tags: # string[] | Image tags (may be a tagging schema with variables) + - latest + - 0.0.1 + - dev-${DEVSPACE_GIT_COMMIT} +``` + +## `image` *Image Repository* +The `image` option expects a string containing the image repository including registry and image name. + +- Make sure you [authenticate with the image registry](../../configuration/images/basics.mdx#authentication-registry) before using in here. +- For Docker Hub images, do not specify a registry hostname and use just the image name instead (e.g. `mysql`, `my-docker-username/image`). + +#### Example: Multiple Images +```yaml +images: + backend: + image: john/appbackend + frontend: + image: dscr.io/${DEVSPACE_USERNAME}/appfrontend +``` +**Explanation:** +- The first image `backend` would be tagged as `appbackend:[TAG]` pushed to Docker Hub using the path `john` (which generally could be your Docker Hub username). +- The second image `frontend` would be tagged as `appfrontend:[TAG]` and pushed to `dscr.io` using the path `${DEVSPACE_USERNAME}` which is a [dynamic config variable](../../configuration/variables/basics.mdx) that resolves to your username in DevSpace Cloud. + + +## `tags` *Tagging Schema* +The `tags` option expects an array of strings, each containing a static tag or a tagging schema used to automatically tag images before pushing them to the registry. The tagging schema can contain [dynamic config variables](../../configuration/variables/basics.mdx). While you can define your own config variables, DevSpace provides a set of pre-defined variables. The most commonly used variables for tagging are: +- **DEVSPACE_RANDOM**: A random 6 character long string +- **DEVSPACE_TIMESTAMP** A unix timestamp when the config was loaded +- **DEVSPACE_GIT_COMMIT**: A short hash of the local repo's current git commit +- **DEVSPACE_USERNAME**: The username currently logged into DevSpace Cloud + +:::info Unique Tags For Development +**Make sure tags are unique** when defining a custom tagging schema for development. Unique tags ensure that your application gets started with the newly built image instead of using an older, cached version. Therefore, it is highly recommended for non-production tags to either use `DEVSPACE_RANDOM` or `DEVSPACE_TIMESTAMP` as a suffix in your tagging schema (see [example below](#example-custom-tagging-schema)). +::: + +#### Default Value For `tag` +```yaml +tags: +- ${DEVSPACE_RANDOM} +``` + +#### Example: Custom Tagging Schema +```yaml +images: + backend: + image: john/appbackend + tags: + - latest + - dev-${DEVSPACE_USERNAME}-backend-${DEVSPACE_GIT_COMMIT}-${DEVSPACE_RANDOM} +``` +**Explanation:** +The above example would always use the tag `latest` and additionaly generate random tags which could look like this one: `dev-john-backend-b6caf8a-Jak9i`. This example tag consists of the following substrings defined by the tagging schema: +- `dev-` static string +- `john` [DevSpace Cloud](https://devspace.cloud/cloud/docs/introduction) username +- `-backend-` static string +- `b6caf8a` latest git commit hash on current local branch +- `-` static string +- `Jak9i` auto-generated random string diff --git a/docs/versioned_docs/version-4.13/configuration/images/inject-restart-helper.mdx b/docs/versioned_docs/version-4.13/configuration/images/inject-restart-helper.mdx new file mode 100644 index 0000000000..ed65bbd851 --- /dev/null +++ b/docs/versioned_docs/version-4.13/configuration/images/inject-restart-helper.mdx @@ -0,0 +1,92 @@ +--- +title: Container Restart Helper +sidebar_label: injectRestartHelper +--- + +## `injectRestartHelper` +The `injectRestartHelper` option expects a boolean which decides if DevSpace should inject a restart helper and override the `ENTRYPOINT+CMD` of the image in runtime during the build process which wraps the regular container start command and allows to restart the regular container start command without terminating/recreating the container. + + +:::note How does it work? +The idea of the restart helper is to start the restart helper script as PID 1 inside the conainer. This script will then start the original container entrypoint which will run your application. If a [restart is triggered](#trigger-a-restart), the restart helper will just restart the application again. +::: + +:::tip Automatic Restart On File Change +The restart helper per se does not do much except restarting your application if it has been killed. You can combine this config option with the [post-sync command `restartContainer: true`](../development/file-synchronization.mdx#onuploadrestartcontainer) which will effectively restart your application inside the container every time DevSpace syncs files into the container. +::: + + +#### Default Value For `injectRestartHelper` +```yaml +injectRestartHelper: false +``` + +#### Example: Inject Restart Helper +```yaml +images: + backend: + image: john/appbackend + frontend: + image: dscr.io/${DEVSPACE_USERNAME}/appfrontend + injectRestartHelper: true +``` + + +
+ +## Trigger a Restart +You can manually trigger a restart through the restart helper by doing the following: +```bash +# 1. Get the PID of your applications process +PID=$(cat /devspace-pid) + +# 2. Remove the PID file to tell the restart helper that this is an intended restart +# (otherwise the restart helper will terminate as well which will kill the container) +rm /devspace-pid + +# 3. Kill the application process (restart helper on PID 1 will detect this and restart it again) +kill -9 $PID +``` + +:::note Automatic Restart On File Change +This is exactly what DevSpace is doing when the [post-sync command `restartContainer: true`](../development/file-synchronization.mdx#onuploadrestartcontainer) is configured. +::: + + +
+ +## Restart Helper Script +```bash +#!/bin/sh +# +# A process wrapper script to simulate a container restart. This file was injected with devspace during the build process +# +set -e +pid="" +trap quit TERM INT +quit() { + if [ -n "$pid" ]; then + kill $pid + fi +} +while true; do + setsid "$@" & + pid=$! + echo "$pid" > /.devspace/devspace-pid + set +e + wait $pid + exit_code=$? + if [ -f /.devspace/devspace-pid ]; then + # if the sync is currently active we try to restart instead of exiting + if [ -f /tmp/sync ]; then + rm -f /.devspace/devspace-pid + printf "\nContainer exited with $exit_code. Will restart in 7 seconds...\n" + sleep 7 + else + exit $exit_code + fi + fi + set -e + printf "\n\n############### Restart container ###############\n\n" +done +``` diff --git a/docs/versioned_docs/version-4.13/configuration/images/kaniko.mdx b/docs/versioned_docs/version-4.13/configuration/images/kaniko.mdx new file mode 100644 index 0000000000..791e6c9709 --- /dev/null +++ b/docs/versioned_docs/version-4.13/configuration/images/kaniko.mdx @@ -0,0 +1,307 @@ +--- +title: Build Images with kaniko +sidebar_label: kaniko +--- + +import FragmentBuildOptionsTarget from '../../fragments/build-option-target.mdx'; +import FragmentBuildOptionsNetwork from '../../fragments/build-option-network.mdx'; +import FragmentBuildOptionsBuildArgs from '../../fragments/build-option-buildArgs.mdx'; + +Using `kaniko` as build tool allows you to build images direclty inside your Kubernetes cluster without a Docker daemon. DevSpace simply starts a build pod and builds the image using `kaniko`. + +:::note Automatic Cleanup +After the build process completes, the build pod started for the kaniko build process will be deleted again. +::: + +To set `kaniko` as default build tool, use the following configuration: +```yaml +images: + backend: + image: john/appbackend + build: + kaniko: + cache: true +``` + +## Flags & Arguments + +### `cache` +The `cache` option expects a boolean that states if kaniko should make use of layer caching by pulling the previously build image and using the layers of this image as cache. + +#### Default Value For `cache` +```yaml +cache: true +``` + +#### Example: Building Images with kaniko +```yaml +images: + backend: + image: john/appbackend + build: + kaniko: + cache: true + frontend: + image: dscr.io/${DEVSPACE_USERNAME}/appfrontend + build: + kaniko: + cache: false +``` +**Explanation:** +- The first image `backend` would be built using kaniko and make use of the build cache. +- The second image `frontend` would be built using kaniko and **not** use the build cache. + + +### `snapshotMode` +The `snapshotMode` option expects a string that can have the following values: +- `full` tells kaniko to do a full filesystem snapshot +- `time` tells kaniko to do a filesystem snapshot based on `mtime` (default) + +:::warning Limitations +One of the biggest limitations of the `time` mode is that kaniko might **miss** file metadata changes introduced by `RUN` statements, e.g. kaniko might skip a command such as `RUN chown 333:333 -R /app`. In cases where this is not an option, use `full` instead. Learn more about [limitations related to kaniko snapshots using `mtime`](https://github.com/GoogleContainerTools/kaniko#mtime-and-snapshotting). +::: + +#### Default Value For `snapshotMode` +```yaml +snapshotMode: time +``` + +#### Example: Building Images with kaniko +```yaml +images: + backend: + image: john/appbackend + build: + kaniko: + cache: true + frontend: + image: dscr.io/${DEVSPACE_USERNAME}/appfrontend + build: + kaniko: + snapshotMode: time +``` +**Explanation:** +- The first image `backend` would be built using kaniko and creating full filesystem snapshots. +- The second image `frontend` would be built using kaniko and calculate filesystem snapthots only based on `mtime`. + + +### `insecure` +The `insecure` option expects a boolean stating if kaniko should allow to push to an insecure (plain HTTP instead of HTTPS) registry. + +:::warning +This option should only be set to `true` for testing purposes. +::: + +#### Default Value For `insecure` +```yaml +insecure: false +``` + +#### Example: Push to Insecure Registry With kaniko +```yaml +images: + backend: + image: 123.456.789.0:5000/john/appbackend + build: + kaniko: + insecure: false +``` +**Explanation:** +The image `backend` would be built using kaniko and pushing to the insecure registry `123.456.789.0:5000` would be allowed. + + +### `args` +The `args` option expects an array of strings that will be passed as arguments (and flags) when running the kaniko build command. + +:::note Kaniko Documentation +Take a look at the kaniko documentation for a full [list of available flags](https://github.com/GoogleContainerTools/kaniko#additional-flags). +::: + +#### Default Value For `args` +```yaml +args: [] +``` + +#### Example: Passing Args to kaniko +```yaml +images: + backend: + image: john/appbackend + build: + kaniko: + args: + - --cache-dir=/tmp + - --verbosity=debug +``` +**Explanation:** +The image `backend` would be built using kaniko and the flags `--cache-dir=/tmp --verbosity=debug` would be set when running the build command within the kaniko pod used for image building. + + + +
+ +## Build Pod Configuration + +### `image` +The `image` option expects a string stating the image that should be used for the kaniko container within the build pod. + +:::warning +This option should only be set to `true` for testing purposes. +::: + +#### Default Value For `image` +```yaml +image: gcr.io/kaniko-project/executor:v0.17.1 +``` + +#### Example: Use Different Kaniko Image/Version +```yaml +images: + backend: + image: 123.456.789.0:5000/john/appbackend + build: + kaniko: + image: gcr.io/kaniko-project/executor:v0.19.0 +``` + + +### `pullSecret` +The `pullSecret` option expects a string with the name of a Kubernetes secret which is used by kaniko as pull/push secret (e.g. for pulling the base image defined in the `FROM` statement of the Dockerfile and for pushing the newly built image after the kaniko build process). + +:::info +In most cases, DevSpace already makes sure that kaniko gets the correct pull secrets to push and pull to registries. +::: + +#### Default Value For `pullSecret` +```yaml +pullSecret: "" +``` + +#### Example: Pull Secret For kaniko +```yaml +images: + backend: + image: john/appbackend + build: + kaniko: + pullSecret: custom-pull-secret +``` +**Explanation:** +The image `backend` would be built using kaniko and kaniko would use the Kubernete secret `custom-pull-secret` to pull images from registries that require authentication. + +:::tip Creating Pull Secrets using `hooks` +If you use the `pullSecret` option, you have to manually create the secret before DevSpace tries to build your images. You can automate this by [defining a hook in devspace.yaml](../../configuration/hooks/basics.mdx) as show in this example: +```yaml +hooks: +- command: kubectl + args: + - create + - secret + - generic + - custom-pull-secret + - --from-literal + - config.json='{ "credsStore":"ecr-login" }' + when: + before: + images: all +``` +::: + +:::note Building AWS ECR images on EKS +If your EKS instance is [configured with access to ECR (see instance role permissions for AWS EKS and ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ECR_on_EKS.html), your pull secret referenced by the `pullSecret` option, could be created with this kubectl command: +```yaml +kubectl create secret generic custom-pull-secret --from-literal config.json='{ "credsStore":"ecr-login" }' +``` +The resulting Kubernetes secret would look like this: +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: custom-pull-secret +data: + config.json: eyAiY3JlZHNTdG9yZSI6ImVjci1sb2dpbiIgfQ== +``` +If you define `pullSecret: custom-pull-secret` as shown in the example above, DevSpace will automatically mount this secret into the kaniko container and kaniko will be able to pull from and push to ECR. +::: + + +### `additionalMounts` +The `additionalMounts` option expects an array of mount options that allow to mount Kubernetes Secrets and ConfigMaps into the kaniko container within the build pod. + +#### Default Value For `additionalMounts` +```yaml +additionalMounts: [] +``` + +#### Example: Mount ConfigMaps & Secrets For Kaniko +```yaml +images: + backend: + image: john/appbackend + build: + kaniko: + additionalMounts: + - mountPath: /some/configmap/dir + configMap: + name: my-configmap + - mountPath: /some/secret/dir + secret: + name: my-secret + items: + - key: aws-token + path: token.json +``` +**Explanation:** +The above configuration would create a kaniko container which mounts the following volumes: +- All keys within the ConfigMap `my-configmap` will be mounted as files within the folder `/some/configmap/dir`. The filenames will be the keys within the ConfigMap. +- The key `aws-token` within the Secret `my-secret` will be mounted as the file `/some/secret/dir/token.json`. + + +### `namespace` +The `namespace` option expects a string stating a namespace that should be used to start the kaniko build pod in. + +:::warning Hard-Coding Namespaces Discouraged +Unless you really know what you are doing, it is discouraged to hard-code namespaces within devspace.yaml because that makes it harder to share the project and its configuration with others. +::: + +#### Default Value For `namespace` +```yaml +namespace: "" # defaults to the default namespace of the current kube-context +``` + +#### Example: Different Namespace For kaniko +```yaml +images: + backend: + image: john/appbackend + build: + kaniko: + namespace: build-namespace +``` +**Explanation:** +The image `backend` would be built using kaniko and the build pod started to run the kaniko build process would be created within the namespace `build-namespace` within the cluster that the current kube-context points to. + + + +
+ +## Build Options +DevSpace allows you to configure the following build options: +- `target` defining the build target for multi-stage builds +- `network` to define which network to use during building (e.g. `docker build --network=host`) +- `buildArgs` to pass arguments to the Dockerfile during the build process + + +### `options.target` + + + + +### `options.network` + + + + +### `options.buildArgs` + + diff --git a/docs/versioned_docs/version-4.13/configuration/images/prefer-sync-over-rebuild.mdx b/docs/versioned_docs/version-4.13/configuration/images/prefer-sync-over-rebuild.mdx new file mode 100644 index 0000000000..e558bc7c27 --- /dev/null +++ b/docs/versioned_docs/version-4.13/configuration/images/prefer-sync-over-rebuild.mdx @@ -0,0 +1,47 @@ +--- +title: Reduce Rebuilds During Dev +sidebar_label: preferSyncOverRebuild +--- + +## `preferSyncOverRebuild` +The `preferSyncOverRebuild` option expects a boolean which decides if DevSpace should skip rebuilding an image during `devspace dev` in case the file sync is configured for a container which references this image using the `imageName` option. + +:::note Development Only +Using `preferSyncOverRebuild: true` does not affect `devspace deploy` because file sync is not being started even if it may be configured in devspace.yaml. So, this option takes effect during image builds via `devspace dev`. +::: + +:::note Regular Skip Check +Even if this option is enabled, DevSpace may still skip building an image if neither the Dockerfile nor any files within the context have changed since the latest rebuild. +::: + +:::tip Trigger Rebuild Manually +DevSpace will still rebuild when the `-b / --force-rebuild` flag is explicitly provided. +::: + +#### Default Value For `preferSyncOverRebuild` +```yaml +preferSyncOverRebuild: false +``` + +#### Example: Prefer Sync Over Rebuild +```yaml {4,12} +images: + backend: + image: john/appbackend + preferSyncOverRebuild: true + frontend: + image: dscr.io/${DEVSPACE_USERNAME}/appfrontend + preferSyncOverRebuild: true + cache: + image: dscr.io/${DEVSPACE_USERNAME}/cache +dev: + sync: + - imageName: backend + onUpload: + restartContainer: true +``` +**Explanation:** +When running `devspace dev` using the above configuration, DevSpace would: +- **not** build the image `backend` because `dev.sync[0].imageName` is referencing this image and `preferSyncOverRebuild: true` is configured +- build the image `frontend` because although `preferSyncOverRebuild: true` is configured, no sync configuration is referencing this image +- build the image `cache` because `preferSyncOverRebuild` is not set to `true` diff --git a/docs/versioned_docs/version-4.13/configuration/images/pull-secrets.mdx b/docs/versioned_docs/version-4.13/configuration/images/pull-secrets.mdx new file mode 100644 index 0000000000..6f28057b12 --- /dev/null +++ b/docs/versioned_docs/version-4.13/configuration/images/pull-secrets.mdx @@ -0,0 +1,28 @@ +--- +title: Image Pull Secrets +sidebar_label: createPullSecret +--- + +## `createPullSecret` +The `createPullSecret` option expects a boolean that tells DevSpace if a pull secret should be created for the registry where this image will be pushed to. +- If there are multiple images with the **same registry** and any of the images will define `createPullSecret: true`, the pull secret will be created no matter if any of the other images using the same registry explicitly defines `createPullSecret: false`. +- There is **no need to change your Kubernetes manifests, Helm charts or other deployments to reference the pull secret** because DevSpace will [add the pull secret to the service account](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) which deploys your project. This ensures that the pull secret is automatically considered by Kubernetes altough it is not explicitly referenced by your pods. +- After running `devspace deploy` or `devspace dev`, you should be able to see the auto-generated pull secrets created by DevSpace when you run the command `kubectl get serviceaccount default -o yaml` and take a look at the `imagePullSecrets` section of this service account. + +#### Default Value For `createPullSecret` +```yaml +createPullSecret: false +``` + +#### Example: Different Dockerfiles +```yaml +images: + backend: + image: john/appbackend + frontend: + image: dscr.io/${DEVSPACE_USERNAME}/appfrontend + createPullSecret: true +``` +**Explanation:** +- The first image `backend` will be pushed to Docker Hub and DevSpace will **not** create a pull secret for Docker Hub because `createPullSecret` defaults to `false`. This makes sense for public images where no login is required to pull the image or where you want to manage the pull secret yourself. +- The second image `frontend` will be pushed to dscr.io and DevSpace will create a pull secret for dscr.io, so Kubernetes is able to pull the image from dscr.io. diff --git a/docs/versioned_docs/version-4.13/configuration/profiles/basics.mdx b/docs/versioned_docs/version-4.13/configuration/profiles/basics.mdx new file mode 100644 index 0000000000..0e05d7fb42 --- /dev/null +++ b/docs/versioned_docs/version-4.13/configuration/profiles/basics.mdx @@ -0,0 +1,89 @@ +--- +title: Config Profiles +sidebar_label: Basics +--- + +import FragmentInfoPrintConfig from '../../fragments/tip-print-config.mdx'; + +DevSpace allows you to define different profiles for different use cases (e.g. working on different services in the same project, starting certain debugging environments) or for different deployment targets (e.g. dev, staging production). + +Profiles allow you to define: +- [`replace`](../../configuration/profiles/replace.mdx) statements to override entire sections of the config +- [`patches`](../../configuration/profiles/patches.mdx) to modify certain parts of the config. + +:::note Combine Replace & Patches +It is possible to use the `replace` and `patches` together within one profile. +::: + +:::tip Debug Profiles + + + +::: + +A profile has to be configured in the `profiles` section of the `devspace.yaml`. +```yaml {15-25} +images: + backend: + image: john/devbackend + backend-debugger: + image: john/debugger +deployments: +- name: backend + helm: + componentChart: true + values: + containers: + - image: john/devbackend + - image: john/debugger +profiles: +- name: production + patches: + - op: replace + path: images.backend.image + value: john/prodbackend + - op: remove + path: deployments.name=backend.helm.values.containers[1] + - op: add + path: deployments.name=backend.helm.values.containers + value: + image: john/cache +``` + + +## Useful Commands + +### `devspace print -p [profile]` + + + +### `devspace list profiles` +To get a list of available profiles, you can run this command: +```bash +devspace list profiles +``` + +### `devspace use profile [profile]` +To permanently switch to a different profile, you can run this command: +```bash +devspace use profile [PROFILE_NAME] +``` + +:::note +Permanently switching to a profile means that all future commands (e.g. `devspace deploy` or `devspace dev`) will be executed using this profile until the user [resets the profile](#devspace-use-profile---reset) (see below). +::: + +### `devspace use profile --reset` +To permanently switch back to the default configuration (no profile replaces and patches active), you can run this command: +```bash +devspace use profile --reset +``` + +### `devspace [deploy] -p [profile]` +Most DevSpace commands support the `-p / --profile` flag. Using this flag, you can run a single command with a different profile without switching your profile permenantly: +```bash +devspace build -p [PROFILE_NAME] +devspace deploy -p [PROFILE_NAME] +devspace dev -p [PROFILE_NAME] +devspace dev -i -p [PROFILE_NAME] +``` diff --git a/docs/versioned_docs/version-4.13/configuration/profiles/patches.mdx b/docs/versioned_docs/version-4.13/configuration/profiles/patches.mdx new file mode 100644 index 0000000000..10147053a8 --- /dev/null +++ b/docs/versioned_docs/version-4.13/configuration/profiles/patches.mdx @@ -0,0 +1,150 @@ +--- +title: "Profiles: Patches" +sidebar_label: patches +--- + +import FragmentInfoPrintConfig from '../../fragments/tip-print-config.mdx'; +import FragmentProfileParent from '../../fragments/profile-parent.mdx'; + +Patches are a way to perform minor overrides to the configuration without having to create a separate config file. Patch functionality follows JSON Patch([RFC](https://tools.ietf.org/html/rfc6902)) semantics, as implemented by the [yaml-patch](https://github.com/krishicks/yaml-patch) library. + +## Example +Patches are ideal for reflecting changes between different environments, e.g. dev, staging and production. +```yaml {15-25} +images: + backend: + image: john/devbackend + backend-debugger: + image: john/debugger +deployments: +- name: backend + helm: + componentChart: true + values: + containers: + - image: john/devbackend + - image: john/debugger +profiles: +- name: production + patches: + - op: replace + path: images.backend.image + value: john/prodbackend + - op: remove + path: deployments.name=backend.helm.values.containers[1] + - op: add + path: deployments.name=backend.helm.values.containers + value: + image: john/cache +``` +**Explanation:** +- The above example defines 1 profile: `production` +- When using the profile `production`, the config would be patched with 3 patches. +- The resulting config used in-memory when the profile `production` is used would look like this: + +```yaml +# In-Memory Config After Applying Patches For Profile `production` +images: + backend: + image: john/devbackend + backend-debugger: + image: john/debugger +deployments: +- name: backend + helm: + componentChart: true + values: + containers: + - image: john/prodbackend + - image: john/cache +``` + +## Configuration + +### `name` +The `name` option is mandatory and expects a string defining the name of the profile. + +### `patches` +The `patches` option expects a patch object which consists of the following properties: +- `op` stating the patch operation (possible values: `replace`, `add`, `remove`) +- `path` stating a jsonpath or an xpath within the config (e.g. `images.backend.image`, `deployments.name=backend.helm.values.containers[1]`) +- `value` stating an arbitrary value used by the operation (e.g. a string, an integer, a boolean, a yaml object) + +:::warning `op: add` only for arrays +Using `op: add` only works as expected when `path` points to an array value. Using `op: add` to add properties to an object (e.g. `deployments[*].helm.values`) will **not** work and instead replace all existing properties. +::: + +:::tip Array Paths +When you want to define a `path` that contains an array (e.g. `deployments`), you have two options: + +1. Use the index of the array item you want to patch, e.g. `deployments[0]` +2. Use a property selector matching the array item(s) you want to patch, e.g. `deployments.name=backend` + +Using a property selector is often better because it is more resilient and will not cause any issues even if the order of an array's items is changed later on. A property selector is also able to select multiple array items if all of them have the same value for this property. +::: + +:::info Value For Replace / Add +If you use the `replace` or `add` operation, `value` is a mandatory property. +::: + +:::info +If `value` is defined, the new value must provide the correct type to be used when adding or replacing the existing value found under `path` using the newly provided `value`, e.g. an array must be replaced with an array. +::: + +:::note +The `patches` of a profile can modify all parts of the configuration **except** the sections `profiles` and `commands`. +::: + +#### Example: Config Patches +```yaml {15-32} +images: + backend: + image: john/devbackend + backend-debugger: + image: john/debugger +deployments: +- name: backend + helm: + componentChart: true + values: + containers: + - image: john/devbackend + - image: john/debugger +profiles: +- name: staging + patches: + - op: replace + path: images.backend.image + value: john/stagingbackend + - op: remove + path: deployments.name=backend.helm.values.containers[1] +- name: production + patches: + - op: replace + path: images.backend.image + value: john/prodbackend + - op: remove + path: deployments.name=backend.helm.values.containers[1] + - op: add + path: deployments.name=backend.helm.values.containers + value: + image: john/cache +``` +**Explanation:** +- The above example defines 2 profiles: `staging`, `production` +- Users can use the flag `-p staging` to use the `staging` profile for a single command execution +- Users can use the flag `-p production` to use the `production` profile for a single command execution +- Users can permanently switch to the `staging` profile using: `devspace use profile staging` +- Users can permanently switch to the `production` profile using: `devspace use profile production` + + +### `parent` + + + + +## Useful Commands + +### `devspace print -p [profile]` + + diff --git a/docs/versioned_docs/version-4.13/configuration/profiles/replace.mdx b/docs/versioned_docs/version-4.13/configuration/profiles/replace.mdx new file mode 100644 index 0000000000..1fb1da927b --- /dev/null +++ b/docs/versioned_docs/version-4.13/configuration/profiles/replace.mdx @@ -0,0 +1,81 @@ +--- +title: "Profiles: Replace" +sidebar_label: replace +--- + +import FragmentInfoPrintConfig from '../../fragments/tip-print-config.mdx'; +import FragmentProfileParent from '../../fragments/profile-parent.mdx'; + +## Configuration + +### `name` +The `name` option is mandatory and expects a string defining the name of the profile. + +### `replace` + +The `replace` option expects an object with the following (optional) fields: +- `images` which will replace the entire `images` section of the devspace.yaml +- `deployments` which will replace the entire `deployments` section of the devspace.yaml +- `dev` which will replace the entire `dev` section of the devspace.yaml +- `dependencies` which will replace the entire `dependencies` section of the devspace.yaml +- `hooks` which will replace the entire `hooks` section of the devspace.yaml + +#### Example: Using Config Replace For Profile `production` +```yaml {16-19} +images: + backend: + image: john/devbackend + backend-debugger: + image: john/debugger +deployments: +- name: app-backend + helm: + componentChart: true + values: + containers: + - image: john/devbackend + - image: john/debugger +profiles: +- name: production + replace: + images: + backend: + image: john/prodbackend + patches: + - op: remove + path: deployments[0].helm.values.containers[1] +``` +**Explanation:** +- The above example defines 1 profile: `production` +- When using the profile `production`, the config section `images` would be entirely replaced and additionally, 1 patch would be applied. +- The resulting config used in-memory when the profile `production` is used would look like this: + +```yaml +# In-Memory Config After Applying Profile `production` +images: + backend: + image: john/prodbackend +deployments: +- name: app-backend + helm: + componentChart: true + values: + containers: + - image: john/prodbackend +``` + +:::tip Combine Replace & Patches +As shown in this example, it is possible to use `replace` and `patch` options in combination. +::: + + +### `parent` + + + + +## Useful Commands + +### `devspace print -p [profile]` + + diff --git a/docs/versioned_docs/version-4.13/configuration/reference.mdx b/docs/versioned_docs/version-4.13/configuration/reference.mdx new file mode 100644 index 0000000000..b6330b6730 --- /dev/null +++ b/docs/versioned_docs/version-4.13/configuration/reference.mdx @@ -0,0 +1,326 @@ +--- +title: Config Reference +sidebar_label: devspace.yaml +--- + +import FragmentConfigImages from '../fragments/config-images.mdx'; +import FragmentConfigDeployments from '../fragments/config-deployments.mdx'; +import FragmentConfigDev from '../fragments/config-dev.mdx'; +import FragmentConfigDependencies from '../fragments/config-dependencies.mdx'; +import FragmentConfigVars from '../fragments/config-vars.mdx'; +import FragmentConfigProfiles from '../fragments/config-profiles.mdx'; +import FragmentConfigCommands from '../fragments/config-commands.mdx'; +import FragmentConfigHooks from '../fragments/config-hooks.mdx'; +import WarningBuildToolPriority from '../fragments/warning-build-tool-priority.mdx'; + +## `version` +```yaml +version: v1beta8 # string | Version of the config +``` + +## `images` + + + +[Learn more about how to configure image building.](../configuration/images/basics.mdx) + +### `images[*].build` +```yaml +build: # struct | Build configuration for an image + docker: ... # struct | Build image with docker and set options for docker + kaniko: ... # struct | Build image with kaniko and set options for kaniko + custom: ... # struct | Build image using a custom build script + disabled: false # bool | Disable image building (Default: false) +``` +:::info +Setting the key `docker`, `kaniko`, `custom` or `disabled` will define the build tool for this image. + +- If neither `docker`, `kaniko`, `custom` nor `disabled` is specified, `docker` will be used by default. +- By default, `docker` will use `kaniko` as fallback when DevSpace is unable to reach the Docker host. +::: + + + +### `images[*].build.docker` +```yaml +docker: # struct | Options for building images with Docker + preferMinikube: true # bool | If available, use minikube's in-built docker daemon instaed of local docker daemon (default: true) + skipPush: false # bool | Skip pushing image to registry, enabled automatically for minikube and docker-desktop (Default: false) + disableFallback: false # bool | Disable using kaniko as fallback when Docker is not installed (Default: false) + useBuildKit: true # bool | Enable BuildKit for Docker build process (default: false) + options: ... # struct | Set general build options +``` + +### `images[*].build.kaniko` +```yaml +kaniko: # struct | Options for building images with kaniko + cache: true # bool | Use caching for kaniko build process + snapshotMode: "time" # string | Type of snapshotMode for kaniko build process (compresses layers) + insecure: false # bool | Allow working with an insecure registry by not validating the SSL certificate (Default: false) + args: [] # string[] | Array of args for kaniko build command + image: "" # string | Allows to change the kaniko image or kaniko version / image tag. + pullSecret: "" # string | Mount this Kubernetes secret instead of creating one to authenticate to the registry (default: "") + additionalMounts: [] # struct[] | Array of mount configurations for Kubernetes Secrets and ConfigMaps that should be mounted into the kaniko build container + namespace: "" # string | Kubernetes namespace to run kaniko build pod in (Default: "" = deployment namespace) + options: ... # struct | Set build general build options +``` + +### `images[*].build.custom` +```yaml +custom: # struct | Options for building images with a custom build script + command: "./scripts/builder" # string | Command to be executed for building (e.g. path to build script or executable) + args: [] # string[] | Array of arguments for the custom build command + imageFlag: string # string | Name of the flag that DevSpace uses to pass the image name + tag to the build script + onChange: [] # string[] | Array of paths (glob format) to check for file changes to see if image needs to be rebuilt +``` + +### `images[*].build.disabled` +```yaml +build: # struct | Build configuration for an image + disabled: true # bool | Disable image building (Default: false) +``` + +### `images[*].build.*.options` +```yaml +options: # struct | Options for building images + target: "" # string | Target used for multi-stage builds + network: "" # string | Network mode used for building the image + buildArgs: {} # map[string]string | Key-value map specifying build arguments that will be passed to the build tool (e.g. docker) +``` + + +## `deployments` + + + +:::info +Using the `helm` or `kubectl` key will define the type of deployment and the deployment tool to be used. +::: + +:::warning +You **cannot** use `helm` and `kubectl` in combination. +::: + +### `deployments[*].helm` +```yaml +helm: # struct | Options for deploying with Helm + chart: ... # struct | Relative path + componentChart: false # bool | Use the DevSpace component chart instead of a custom `chart` = deployment is a component (Default: false) + values: {} # struct | Any object with Helm values to override values.yaml during deployment + valuesFiles: # string[] | Array of paths to values files + - ./chart/my-values.yaml # string | Path to a file to override values.yaml with + replaceImageTags: true # bool | Enable automated tag replacement (Default: true) + wait: false # bool | Wait for pods to start after deployment (Default: false) + timeout: 180 # int | Timeout to wait for pods to start after deployment (Default: 180) + force: false # bool | Force deleting and re-creating Kubernetes resources during deployment (Default: false) + atomic: false # bool | Rollback deployment if it fails (Default: false) + cleanupOnFail: false # bool | Delete resources if rollback fails (Default: false) + recreate: false # bool | Recreate pods for applicable resources, e.g. deployments (Default: false) + disableHooks: false # bool | Disable hooks (Default: false) + driver: secrets|configmaps|memory # enum | Driver used by Helm v3 to store release configuration (Default: secrets) + v2: false # bool | Use legacy Helm v2 (Default: false) + tillerNamespace: "" # string | Kubernetes namespace to run Tiller in when using Helm v2 (Default: "" = same a deployment namespace) +``` +[Learn more about configuring deployments with Helm.](../configuration/deployments/helm-charts.mdx) + +### `deployments[*].helm.componentChart` +```yaml +helm: + componentChart: true # bool | Use Component chart + values: # struct | Options for deploying a component = Deployment/StatefulSet + initContainers: ... # struct[] | Init Containers of this Deployment/StatefulSet + containers: ... # struct[] | Containers of this Deployment/StatefulSet + labels: {} # map[string]string | Map of Kubernetes labels for labeling the pods of this component + annotations: {} # map[string]string | Map of Kubernetes annotations for annotating the pods of this component + volumes: ... # struct | Component volumes + service: ... # struct | Component service + serviceName: my-service # string | Service name for headless service (for StatefulSets) + ingress: ... # struct | Component ingress + replicas: 1 # int | Number of replicas (Default: 1) + autoScaling: ... # struct | AutoScaling configuration + rollingUpdate: ... # struct | RollingUpdate configuration + pullSecrets: ... # string[] | Array of PullSecret names + podManagementPolicy: OrderedReady # enum | "OrderedReady" or "Parallel" (for StatefulSets) + options: ... # struct | Options for deploying this component with helm +``` + +[Learn more about configuring the component chart.](https://devspace.sh/component-chart/docs/introduction) + +### `deployments[*].helm.chart` +```yaml +chart: # struct | Chart to deploy + name: my-chart # string | Path to local chart on filesystem OR chart name for remote chart in helm chart repository + version: v1.0.1 # string | Chart version + repo: "https://my-repo.tld/" # string | Helm chart repository + username: "my-username" # string | Username for Helm chart repository + password: "my-password" # string | Password for Helm chart repository +``` + +### `deployments[*].kubectl` +```yaml +kubectl: # struct | Options for deploying with "kubectl apply" + manifests: [] # string[] | Array containing glob patterns for the Kubernetes manifests to deploy using "kubectl apply" (e.g. kube or manifests/service.yaml) + kustomize: false # bool | Use kustomize when deploying manifests via "kubectl apply" (Default: false) + replaceImageTags: true # bool | Enable automated tag replacement (Default: true) + applyArgs: [] # string[] | Array of args for the "kubectl apply" command during deployment + createArgs: [] # string[] | Array of args for the "kubectl create" command during deployment + kustomizeArgs: [] # string[] | Array of args for the "kustomize build" command during deployment + deleteArgs: [] # string[] | Array of args for the "kubectl delete" command when purging deployments + cmdPath: "" # string | Path to the kubectl binary (Default: "" = detect automatically) +``` +[Learn more about configuring deployments with kubectl.](../configuration/deployments/kubernetes-manifests.mdx) + + +## `dev` + + + +[Learn more about configuring development mode.](../configuration/development/basics.mdx) + +### `dev.ports` +```yaml +ports: # struct[] | Array of port forwarding settings for selected pods +- imageName: someImage # string | Name of an image defined in `images` to select pods with + labelSelector: ... # struct | Key Value map of labels and values to select pods with + namespace: "" # string | Kubernetes namespace to select pods in + forward: # struct[] | Array of ports to be forwarded + - port: 8080 # int | Forward this port on your local computer + remotePort: 3000 # int | Forward traffic to this port exposed by the pod/container selected + bindAddress: "" # string | Address used for binding / use 0.0.0.0 to bind on all interfaces (Default: "localhost" = 127.0.0.1) +``` +[Learn more about configuring port forwarding.](../configuration/development/port-forwarding.mdx) + +### `dev.open` +```yaml +open: # struct[] | Array of auto-open settings +- url: "https://localhost:3000/" # string | URL to open after application has started +``` +[Learn more about configuring auto-opening links.](../configuration/development/open-links.mdx) + +### `dev.sync` +```yaml +sync: # struct[] | Array of file sync settings for selected pods +- imageName: someImage # string | Name of an image defined in `images` to select pods with + labelSelector: ... # struct | Key Value map of labels and values to select pods with + containerName: "" # string | Container name to use after selecting a pod + namespace: "" # string | Kubernetes namespace to select pods in + localSubPath: ./ # string | Relative path to a local folder that should be synchronized (Default: "./" = entire project) + containerPath: /app # string | Path in the container that should be synchronized with localSubPath (Default is working directory of container (".")) + excludePaths: [] # string[] | Paths to exclude files/folders from sync in .gitignore syntax + downloadExcludePaths: [] # string[] | Paths to exclude files/folders from download in .gitignore syntax + uploadExcludePaths: [] # string[] | Paths to exclude files/folders from upload in .gitignore syntax + initialSync: mirrorLocal # enum | Specifies the initialSync algorithm: mirrorLocal, mirrorRemote, preferLocal, preferRemote, preferNewest, keepAll (Default: mirrorLocal) + waitInitialSync: false # bool | Wait until initial sync is completed before continuing (Default: false) + bandwidthLimits: # struct | Bandwidth limits for the synchronization algorithm + download: 0 # int64 | Max file download speed in kilobytes / second (e.g. 100 means 100 KB/s) + upload: 0 # int64 | Max file upload speed in kilobytes / second (e.g. 100 means 100 KB/s) + onUpload: # struct | After a file/folder has been uploaded to the container... + restartContainer: true # bool | Restart container after uploading files (requires images.*.injectRestartHelper: true) + execRemote: # struct | ...execute the following command inside the container: + command: chmod # string | Command to execute for files and folders + args: # string[] | Argument list + - +x # string | Argument 1 + - {} # string | Argument 2: {} will be replaced with path of the file/folder + onFileChange: # struct | Command to execute ONLY for files + command: chmod # string | Command + args: # string[] | Argument list + - +x # string | Argument 1 + - {} # string | Argument 2: {} will be replaced with path of the file/folder + onDirCreate: # struct | Command to execute ONLY for newly created directories + command: chmod # string | Command + args: # string[] | Argument list + - +x # string | Argument 1 + - {} # string | Argument 2: {} will be replaced with path of the file/folder + onBatch: # struct | Command to execute after sync has processed a full batch of files and folders + command: recompile # string | Command + args: # string[] | Argument list (NOTE: {} is NOT available for onBatch) + - assets # string | Arument 1 + - --minify # string | Argument 2 + onDownload: # struct | After a file/folder has been downloaded from the container to the local filesystem... + execLocal: # struct | ...execute the following command on the local machine: + command: chmod # string | Command to execute for files and folders + args: # string[] | Argument list + - +x # string | Argument 1 + - {} # string | Argument 2: {} will be replaced with path of the file/folder + onFileChange: # struct | Command to execute ONLY for files + command: chmod # string | Command + args: # string[] | Argument list + - +x # string | Argument 1 + - {} # string | Argument 2: {} will be replaced with path of the file/folder + onDirCreate: # struct | Command to execute ONLY for newly created directories + command: chmod # string | Command + args: # string[] | Argument list + - +x # string | Argument 1 + - {} # string | Argument 2: {} will be replaced with path of the file/folder +``` +[Learn more about confguring the file synchronization.](../configuration/development/file-synchronization.mdx) + +### `dev.logs` +```yaml +logs: # struct | Options for multi-container log streaming in development mode + disabled: false # bool | Disable log streaming in development mode (Default: false) + showLast: 200 # int | Number of last log lines to show before starting stream (Default: 50) + images: [] # string[] | Array of image names referencing images defined in `images` for selecting containers for log streaming +``` +[Learn more about configuring multi-container log streaming.](../configuration/development/log-streaming.mdx) + +### `dev.autoReload` +```yaml +autoReload: # struct | Options for auto-reloading (i.e. re-deploying deployments and re-building images) + paths: [] # string[] | Array containing glob patterns of files that are watched for auto-reloading (i.e. reload when a file matching any of the patterns changes) + deployments: [] # string[] | Array containing names of deployments to watch for auto-reloading (i.e. reload when kubectl manifests or files within the Helm chart change) + images: [] # string[] | Array containing names of images to watch for auto-reloading (i.e. reload when the Dockerfile changes) +``` + +### `dev.interactive` +```yaml +interactive: # struct | Options for interactive mode + defaultEnabled: false # bool | Start interactive mode instead of log streaming by default, even without -i / --interactive flag (Default: false) + images: # struct[] | Array of image override configurations for interactive mode + - name: default # string | Name of the image to apply this override rule to (key in `images`) + entrypoint: [] # string[] | Array defining with the ENTRYPOINT that should be used instead of the ENTRYPOINT defined in the Dockerfile + cmd: [] # string[] | Array defining with the CMD that should be used instead of the CMD defined in the Dockerfile + terminal: # struct | Options for the terminal proxy + imageName: someImage # string | Name of an image defined in `images` to select pods with + labelSelector: ... # struct | Key Value map of labels and values to select pods with + containerName: "" # string | Container name to use after selecting a pod + namespace: "" # string | Kubernetes namespace to select pods in + command: [] # string[] | Array defining the shell command to start the terminal with (Default: ["sh", "-c", "command -v bash >/dev/null 2>&1 && exec bash || exec sh"]) +``` +[Learn more about configuring interactive mode.](../configuration/development/interactive-mode.mdx) + + +## `dependencies` + + + +[Learn more about configuring dependencies.](../configuration/dependencies/basics.mdx) + +:::warning +You **cannot** use `source.git` and `source.path` in combination. You **must** exactly use one of the two. +::: + +## `hooks` + + + + +## `commands` + + + +[Learn more about configuring custom commands.](../configuration/commands/basics.mdx) + + +## `vars` + + + +[Learn more about configuring config variables.](../configuration/variables/basics.mdx) + + +## `profiles` + + + +[Learn more about configuring profiles and patches.](../configuration/profiles/basics.mdx) diff --git a/docs/versioned_docs/version-4.13/configuration/variables/basics.mdx b/docs/versioned_docs/version-4.13/configuration/variables/basics.mdx new file mode 100644 index 0000000000..faf7fe1b40 --- /dev/null +++ b/docs/versioned_docs/version-4.13/configuration/variables/basics.mdx @@ -0,0 +1,188 @@ +--- +title: Config Variables +sidebar_label: Basics +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +DevSpace allows you to make your configuration dynamic by using variables in `devspace.yaml`. + +While there is no need to explicitly define a config variable, it allows you to customize the behavior of DevSpace when working with the variable. Variables are defined within the `vars` section of `devspace.yaml`. + + + + +```yaml {3,5-7} +images: + database: + image: "mysql:${MYSQL_VERSION}" +vars: +- name: MYSQL_VERSION + question: Which mysql version do you want to use? + default: "5.7" +``` + + + + +```yaml {3,5-10} +images: + database: + image: "mysql:${MYSQL_VERSION}" +vars: +- name: MYSQL_VERSION + question: Which mysql version do you want to use? + options: + - "5.5" + - "5.6" + - "5.7" +``` + + + + +```yaml {3,5-7} +images: + database: + image: "mysql:${MYSQL_VERSION}" +vars: +- name: MYSQL_VERSION + question: Which mysql version do you want to use? + password: true +``` + + + + +```yaml {3,5-7} +images: + database: + image: "mysql:${MYSQL_VERSION}" +vars: +- name: MYSQL_VERSION + source: env + default: "5.5" +``` + + + + +```yaml {3} +images: + database: + image: "mysql:${MYSQL_VERSION}" +vars: {} +``` + +:::tip +DevSpace allows you to use config variables without explicitly defining them as variables. You can simply reference them via `${MY_ENV_VAR}` anywhere in your `devspace.yaml`. Implicit variables use `source: all`. +::: + + + + +:::info Source +The `source` option of a config variable expects either: +- `all` means to check environment variables **first** and then ask a question if no env variable is defined (**default**) +- [`env`](../../configuration/variables/source-env.mdx) means to check environment variables **only** +- [`input`](../../configuration/variables/source-input.mdx) means to ask the user a question **once** (values will be cached in `.devspace/generated.yaml`) +::: + +:::note Input Caching +If `source` is either `all` or `input` and the variable is not defined, the user will be asked to provide a value either using a generic question or the one provided via the [`question` option](../../configuration/variables/source-input.mdx#question). The user-provided value will be cached in `.devspace/generated.yaml` and the user will only be asked again after the cache has been cleared first using: +```bash +devspace reset vars +``` +::: + + + +## Predefined Variables +DevSpace provides some variables that are filled automatically and can be used within the config. These can be helpful for image tagging and other use cases: + +- **DEVSPACE_RANDOM**: A random 6 character long string +- **DEVSPACE_TIMESTAMP** A unix timestamp when the config was loaded +- **DEVSPACE_GIT_COMMIT**: A short hash of the local repo's current git commit +- **DEVSPACE_SPACE**: The name of the Space that is currently used +- **DEVSPACE_SPACE_NAMESPACE**: The Kubernetes namespace of the Space in the cluster +- **DEVSPACE_USERNAME**: The username currently logged into DevSpace Cloud + +#### Example: Using `${DEVSPACE_GIT_COMMIT}` +```yaml +images: + default: + image: myrepo/devspace + tag: ${DEVSPACE_GIT_COMMIT}-${DEVSPACE_TIMESTAMP} +``` +**Explanation:** +This config will tag the image in the form of `myrepo/devspace:d9b4bcd-1559766514`. Many other combinations are possible with this method. + + + +## Useful Commands + +### `devspace list vars` +To get a list of all variables defined in the `devspace.yaml`, you can run this command: +```bash +devspace list vars +``` + +### `devspace reset vars` +Once DevSpace asks you to provide a value for a variable, this value will be stored in the variables cache, so you will not asked about this variable again. To reset the variables cache, run: +```bash +devspace reset vars +``` + +DevSpace will fill the variables cache again, once you run the next build or deployment command. + +### `devspace print` +The following command prints the config after all variables have been replaced: +```bash +devspace print +``` +You can optionally add the `-p / --profiles` flag to this command. + +### `export VAR_NAME=value` +The value for a config variable can also be set by defining an environment variable named `[VAR_NAME]`. Setting the value of a config variable with name `${IMAGE_NAME}` would be possible by setting an environment value `IMAGE_NAME`. + + + + + +```powershell +$env:IMAGE_NAME = "some-value" +``` + + + + +```bash +export IMAGE_NAME="some-value" +``` + + + + +```bash +export IMAGE_NAME="some-value" +``` + + + diff --git a/docs/versioned_docs/version-4.13/configuration/variables/source-env.mdx b/docs/versioned_docs/version-4.13/configuration/variables/source-env.mdx new file mode 100644 index 0000000000..a073063561 --- /dev/null +++ b/docs/versioned_docs/version-4.13/configuration/variables/source-env.mdx @@ -0,0 +1,36 @@ +--- +title: Environment Variables +sidebar_label: "source: env" +--- + +import FragmentVarsName from '../../fragments/vars-name.mdx'; +import FragmentVarsDefault from '../../fragments/vars-default.mdx'; +import FragmentVarsForceString from '../../fragments/vars-force-string.mdx'; + +If the `source` is `env`, DevSpace will **not** ask the user a question and instead use environment variables to determine the value of the variable. +```yaml {3,5-7} +images: + database: + image: "mysql:${MYSQL_VERSION}" +vars: +- name: MYSQL_VERSION + source: env + default: "5.5" +``` + +:::info +If `source` is `env` and the environment variable is **not** defined, DevSpace will use the [`default` value](#default) or terminate with a fatal error, if there is **no** [`default` value](#default) configured. +::: + + + +## Configuration + +### `name` + + + + +### `default` + + diff --git a/docs/versioned_docs/version-4.13/configuration/variables/source-input.mdx b/docs/versioned_docs/version-4.13/configuration/variables/source-input.mdx new file mode 100644 index 0000000000..2a02097a47 --- /dev/null +++ b/docs/versioned_docs/version-4.13/configuration/variables/source-input.mdx @@ -0,0 +1,157 @@ +--- +title: Input-based Variables +sidebar_label: "source: all | input" +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; +import FragmentVarsName from '../../fragments/vars-name.mdx'; +import FragmentVarsDefault from '../../fragments/vars-default.mdx'; +import FragmentVarsForceString from '../../fragments/vars-force-string.mdx'; + +If `source: all (default) | input`, DevSpace may ask the user a question to determine the value of a config variable. + + + + +```yaml {3,5-7} +images: + database: + image: "mysql:${MYSQL_VERSION}" +vars: +- name: MYSQL_VERSION + question: Which mysql version do you want to use? + default: "5.7" +``` + + + + +```yaml {3,5-10} +images: + database: + image: "mysql:${MYSQL_VERSION}" +vars: +- name: MYSQL_VERSION + question: Which mysql version do you want to use? + options: + - "5.5" + - "5.6" + - "5.7" +``` + + + + +```yaml {3,5-7} +images: + database: + image: "mysql:${MYSQL_VERSION}" +vars: +- name: MYSQL_VERSION + question: Which mysql version do you want to use? + password: true +``` + + + + +:::tip Ignore Env Variables +If you want DevSpace to ignore environment variables, you can explicitly define `source: input` to make sure only explict user input will be used to set the value of the variable. +::: + + + + +## Configuration + +### `name` + + + + +### `default` + + + + +### `question` +The `question` option expects a string with a question that will be asked when the variable is not defined. DevSpace tries to resolve the variable according to the `source` of the variable and if it is not set via any of the accepted sources, DevSpace will prompt the user to define the value by entering a string. + +:::note Question +- Defining the `question` is optional but often helpful to provide a better usability for other users. +- If [valid `options` for the variable value](#options) are configured, DevSpace will show a picker/selector instead of a regular input field/prompt. +- If a [`default` value](#default) is configured for the variable, DevSpace will use this [`default` value](#default) as default answer for the question that can be easily selected by pressing enter. +::: + +#### Default Value For `question` +```yaml +question: Please enter a value for [VAR_NAME] # using the variable name +``` + + +### `options` +The `options` option expects an array of strings with each string stating a allowed value for the variable. + +#### Example: Define Variable Options +```yaml +vars: +- name: REGISTRY + question: Which registry do you want to push to? + source: input + options: + - hub.docker.com + - my.private-registry.tld + - dscr.io + default: my.private-registry.tld +``` +**Explanation:** +If the variable `REGISTRY` is used for the first time during `devspace deploy`, DevSpace will ask the user to select which value to use by showing this question: +```bash +Which registry do you want to push to? (Default: my.private-registry.tld) +Use the arrows UP/DOWN to select an option and ENTER to choose the selected option. + hub.docker.com +> my.private-registry.tld + dscr.io +``` + +### `password` +The `password` option expects a boolean that defines if DevSpace should hide the user input when the user provides the value for this variable by entering a response to the question asked in the command line. + +#### Default Value For `password` +```yaml +password: false +``` + +#### Example: Hide User Response +```yaml +vars: +- name: REGISTRY_TOKEN + question: "Please enter your registry token:" + source: input + password: true +``` +**Explanation:** +If the variable `REGISTRY_TOKEN` is used for the first time during `devspace deploy`, DevSpace will ask the user to provide a value by showing this question: +```bash +? Please enter your registry token: ******* +``` +The response the user enters will be hidden as `*******` to protect others from seeing the input while the user is typing. + + +### `validationPattern` +The `validationPattern` option expects a string stating a regular expression that validates if the value entered by the user is allowed as a value for this variable. + +:::info +If the provided value does **not** match the regex in `validationPattern`, DevSpace will either show a generic error message or the message provided in [`validationMessage`](#validationmessage). +::: + +### `validationMessage` +The `validationMessage` option expects a string stating an error message that is shown to the user when providing a value for the variable that does not match the regex provided in [`validationPattern`](#validationpattern). diff --git a/docs/versioned_docs/version-4.13/configuration/variables/source-none.mdx b/docs/versioned_docs/version-4.13/configuration/variables/source-none.mdx new file mode 100644 index 0000000000..97c8c2c812 --- /dev/null +++ b/docs/versioned_docs/version-4.13/configuration/variables/source-none.mdx @@ -0,0 +1,34 @@ +--- +title: Fixed Variables +sidebar_label: "source: none" +--- + +import FragmentVarsName from '../../fragments/vars-name.mdx'; +import FragmentVarsDefault from '../../fragments/vars-default.mdx'; + +If the `source` is `none`, DevSpace will use the `default` value as value for this config variable. +```yaml {3,5-7} +images: + database: + image: "mysql:${MYSQL_VERSION}" +vars: +- name: MYSQL_VERSION + source: none + default: "5.5" +``` + + +## Configuration + +### `name` + + + + +### `default` + + + +:::info +If using `source: none`, the default value is the fixed value for this variable. It will only be changed using a [config patch](../../configuration/profiles/patches.mdx). +::: diff --git a/docs/versioned_docs/version-4.13/fragments/build-option-buildArgs.mdx b/docs/versioned_docs/version-4.13/fragments/build-option-buildArgs.mdx new file mode 100644 index 0000000000..e393e26231 --- /dev/null +++ b/docs/versioned_docs/version-4.13/fragments/build-option-buildArgs.mdx @@ -0,0 +1,16 @@ +The `buildArgs` option expects a map of buildArgs representing values for the `--build-arg` flag used for `docker` or `kaniko` build commands. + +#### Example: Defining Build Args for Docker +```yaml +images: + backend: + image: john/appbackend + build: + docker: + options: + buildArgs: + arg1: arg-value-2 + arg2: arg-value-2 +``` +**Explanation:** +The image `backend` would be built using `docker` and `docker build` would be called using the `--build-arg arg1=arg-value-1 --build-arg arg2=arg-value-2` flags. diff --git a/docs/versioned_docs/version-4.13/fragments/build-option-network.mdx b/docs/versioned_docs/version-4.13/fragments/build-option-network.mdx new file mode 100644 index 0000000000..550dad783c --- /dev/null +++ b/docs/versioned_docs/version-4.13/fragments/build-option-network.mdx @@ -0,0 +1,15 @@ + +The `network` option expects a string stating the network setting for building the image. + +#### Example: Defining a Network for Docker +```yaml +images: + backend: + image: john/appbackend + build: + docker: + options: + network: host +``` +**Explanation:** +The image `backend` would be built using `docker` and `docker build` would be called using the `--network=host` flag. diff --git a/docs/versioned_docs/version-4.13/fragments/build-option-target.mdx b/docs/versioned_docs/version-4.13/fragments/build-option-target.mdx new file mode 100644 index 0000000000..9755b00e7c --- /dev/null +++ b/docs/versioned_docs/version-4.13/fragments/build-option-target.mdx @@ -0,0 +1,14 @@ +The `target` option expects a string stating the build target when using multi-stage builds. + +#### Example: Defining a Build Target for Docker +```yaml +images: + backend: + image: john/appbackend + build: + docker: + options: + target: production +``` +**Explanation:** +The image `backend` would be built using `docker` and the target `production` would be used for building the image as defined in the `Dockerfile`. diff --git a/docs/versioned_docs/version-4.13/fragments/config-commands.mdx b/docs/versioned_docs/version-4.13/fragments/config-commands.mdx new file mode 100644 index 0000000000..4e23313312 --- /dev/null +++ b/docs/versioned_docs/version-4.13/fragments/config-commands.mdx @@ -0,0 +1,5 @@ +```yaml +commands: # struct[] | Array of custom commands +- name: "debug-backend" # string | Name of the command to run via `devspace run debug-backend` + command: "devspace dev -i backend" # string | Command to be executed when running `devspace run [name]` +``` diff --git a/docs/versioned_docs/version-4.13/fragments/config-dependencies.mdx b/docs/versioned_docs/version-4.13/fragments/config-dependencies.mdx new file mode 100644 index 0000000000..885d5f634b --- /dev/null +++ b/docs/versioned_docs/version-4.13/fragments/config-dependencies.mdx @@ -0,0 +1,16 @@ +```yaml +dependencies: # struct[] | Array of dependencies (other projects containing a devspace.yaml or devspace-configs.yaml) that need to be deployed before this project +- source: # struct | Defines where to find the dependency (exactly one source is allowed) + git: https://github.com/my-repo # string | HTTP(S) URL of the git repository (recommended method for referencing dependencies, must have the format of the git remote repo as usually checked out via git clone) + subPath: repo/sub/path # string | Path within the git repo where devspace.yaml can be found + branch: master # string | Git branch to checkout + tag: v1.2.3 # string | Git tag to checkout + revision: ac66e49 # string | Git revision (commit has) to checkout + disableShallow: false # bool | Allows to disable shallow git clones using "--depth 1" + cloneArgs: [] # string[] | Array of args for the "git clone" command for retrieving git based dependencies + path: ../../my-projects/repo # string | Path to a project on your local computer (not recommended, instead of using git-related options) + profile: default # string | Name of the profile used to deploy this dependency (when multiple profiles are defined in the devspace.yaml of the dependency) + skipBuild: false # bool | Do not build images of this dependency (= only start deployments) + ignoreDependencies: false # bool | Do not build and deploy dependencies of this dependency + namespace: "" # string | Kubernetes namespace to deploy dependency to (Default: default namespace of current kube-context) +``` diff --git a/docs/versioned_docs/version-4.13/fragments/config-deployments.mdx b/docs/versioned_docs/version-4.13/fragments/config-deployments.mdx new file mode 100644 index 0000000000..9e8c34ce4e --- /dev/null +++ b/docs/versioned_docs/version-4.13/fragments/config-deployments.mdx @@ -0,0 +1,7 @@ +```yaml +deployments: # struct[] | Array of deployments +- name: my-deployment # string | Name of the deployment + namespace: "" # string | Namespace to deploy to (Default: "" = namespace of the active namespace/Space) + helm: ... # struct | Use Helm as deployment tool and set options for Helm + kubectl: ... # struct | Use "kubectl apply" as deployment tool and set options for kubectl +``` diff --git a/docs/versioned_docs/version-4.13/fragments/config-dev.mdx b/docs/versioned_docs/version-4.13/fragments/config-dev.mdx new file mode 100644 index 0000000000..04b77d614e --- /dev/null +++ b/docs/versioned_docs/version-4.13/fragments/config-dev.mdx @@ -0,0 +1,9 @@ +```yaml +dev: # struct | Options for "devspace dev" + ports: [] # struct[] | Array of port-forwarding settings for selected pods + open: [] # struct[] | Array of auto-open settings + sync: [] # struct[] | Array of file sync settings for selected pods + logs: ... # struct | Options for configuring multi-container log streaming + autoReload: ... # struct | Options for auto-reloading (i.e. re-deploying deployments and re-building images) + interactive: ... # struct | Options for configuring the interactive mode +``` diff --git a/docs/versioned_docs/version-4.13/fragments/config-hooks.mdx b/docs/versioned_docs/version-4.13/fragments/config-hooks.mdx new file mode 100644 index 0000000000..8f2226d93c --- /dev/null +++ b/docs/versioned_docs/version-4.13/fragments/config-hooks.mdx @@ -0,0 +1,12 @@ +```yaml +hooks: # struct[] | Array of hooks to be executed +- command: "./scripts/my-hook" # string | Command to be executed when this hook is triggered + args: [] # string[] | Array of arguments for the command of this hook + when: # struct | Trigger for executing this hook + before: # struct | Run hook before a certain execution step + images: "all" # string | Name of the image you want to run this hook before building OR "all" for running hook before building the first image + deployments: "all" # string | Name of the deployment you want to run this hook before deploying OR "all" for running hook before deploying the first deployment + after: # struct | Run hook after a certain execution step + images: "all" # string | Name of the image you want to run this hook after building OR "all" for running hook after building the last image + deployments: "all" # string | Name of the deployment you want to run this hook after deploying OR "all" for running hook after deploying the last deployment +``` diff --git a/docs/versioned_docs/version-4.13/fragments/config-images.mdx b/docs/versioned_docs/version-4.13/fragments/config-images.mdx new file mode 100644 index 0000000000..b3bf3ef93f --- /dev/null +++ b/docs/versioned_docs/version-4.13/fragments/config-images.mdx @@ -0,0 +1,16 @@ +```yaml +images: # map[string]struct | Images to be built and pushed + image1: # string | Name of the image + image: dscr.io/username/image # string | Image repository and name + tags: # string[] | Image tags (may be a tagging schema with variables) + - latest + - 0.0.1 + - dev-${DEVSPACE_GIT_COMMIT} + dockerfile: ./Dockerfile # string | Relative path to the Dockerfile used for building (Default: ./Dockerfile) + context: ./ # string | Relative path to the context used for building (Default: ./) + entrypoint: [] # string[] | Override ENTRYPOINT defined in Dockerfile + cmd: [] # string[] | Override CMD defined in Dockerfile + createPullSecret: true # bool | Create a pull secret containing your Docker credentials (Default: false) + build: ... # struct | Build options for this image + image2: ... +``` diff --git a/docs/versioned_docs/version-4.13/fragments/config-profiles.mdx b/docs/versioned_docs/version-4.13/fragments/config-profiles.mdx new file mode 100644 index 0000000000..52e911fa32 --- /dev/null +++ b/docs/versioned_docs/version-4.13/fragments/config-profiles.mdx @@ -0,0 +1,16 @@ +```yaml +profiles: # struct[] | Array of config profiles +- name: profile-name # string | Name of the profile + name: parent-profile # string | Name of the parent of this profile (profile inheritance) + patches: # struct[] | Array of config patches + - op: "replace" # enum | Patch operation (replace, add, remove) + path: "images.backend.cmd" # string | Jsonpath or xpath to config option that should be patched + value: "" # arbitrary | Value to use for patch operation + from: "" # string | Jsonpath or xpath to config option which should be used as value for operation + replace: # struct | Array of replacements for entire config sections + images: {} # struct | Replacement for entire `images` section + deployments: {} # struct | Replacement for entire `deployments` section + dev: {} # struct | Replacement for entire `dev` section + dependencies: {} # struct | Replacement for entire `dependencies` section + hooks: {} # struct | Replacement for entire `hooks` section +``` diff --git a/docs/versioned_docs/version-4.13/fragments/config-vars.mdx b/docs/versioned_docs/version-4.13/fragments/config-vars.mdx new file mode 100644 index 0000000000..6bad579bd5 --- /dev/null +++ b/docs/versioned_docs/version-4.13/fragments/config-vars.mdx @@ -0,0 +1,11 @@ +```yaml +vars: # struct[] | Array of config variables +- name: CONFIG_VAR # string | Name of the config variable + question: "What is CONFIG_VAR?" # string | Question to ask the user if no value is found for variable + options: [] # string[] | Options for picker (selector) to show to user (to choose a value for variable) + password: false # bool | Hide user input when providing value via command-line, i.e. replaces input with `*****` (Default: false) + validationPattern: "" # string | Regexp to validate user input + validationMessage: "" # string | Message to show to user for input validation + default: "" # string | Default value for variable + source: "all" # enum | Source for variable (all = default, env, input) +``` diff --git a/docs/versioned_docs/version-4.13/fragments/dependency-ignoreDependencies.mdx b/docs/versioned_docs/version-4.13/fragments/dependency-ignoreDependencies.mdx new file mode 100644 index 0000000000..43fbfdfd5f --- /dev/null +++ b/docs/versioned_docs/version-4.13/fragments/dependency-ignoreDependencies.mdx @@ -0,0 +1,18 @@ +The `ignoreDependencies` option expects a boolean that defines if the dependencies of this dependencies should not be resolved and deployed. + +:::info +Using `ignoreDependencies` can be useful to prevent problematic **circular dependencies**. +::: + +#### Default Value For `ignoreDependencies` +```yaml +ignoreDependencies: false +``` + +#### Example: Ignore Dependencies of Dependency +```yaml +dependencies: +- source: + git: https://github.com/my-api-server + ignoreDependencies: true +``` diff --git a/docs/versioned_docs/version-4.13/fragments/dependency-name.mdx b/docs/versioned_docs/version-4.13/fragments/dependency-name.mdx new file mode 100644 index 0000000000..113b05ec86 --- /dev/null +++ b/docs/versioned_docs/version-4.13/fragments/dependency-name.mdx @@ -0,0 +1,10 @@ +The `name` option is optional and expects a string stating the name of this dependency. + +:::note +Adding a `name` for a dependency makes it possible to reference the dependency using flags, e.g. +```bash +devspace deploy --dependency=[name] +devspace purge --dependency=[name] +devspace render --dependency=[name] +``` +::: diff --git a/docs/versioned_docs/version-4.13/fragments/dependency-namespace.mdx b/docs/versioned_docs/version-4.13/fragments/dependency-namespace.mdx new file mode 100644 index 0000000000..7b19c52545 --- /dev/null +++ b/docs/versioned_docs/version-4.13/fragments/dependency-namespace.mdx @@ -0,0 +1,9 @@ +The `namespace` option is optional and expects a string stating a namespace that should be used to deploy the dependency to. + +:::note +By default, DevSpace deploys project dependencies in the same namespace as the project itself. +::: + +:::info +You should only use the `namespace` option if you are an advanced user because using this option requires any user that deploys this project to be able to create this namespace during the deployment process or to have access to the namespace with the current kube-context, if the namespace already exists. +::: diff --git a/docs/versioned_docs/version-4.13/fragments/dependency-profile.mdx b/docs/versioned_docs/version-4.13/fragments/dependency-profile.mdx new file mode 100644 index 0000000000..c239f9232c --- /dev/null +++ b/docs/versioned_docs/version-4.13/fragments/dependency-profile.mdx @@ -0,0 +1,9 @@ +The `profile` option expects a string with the name of a profile defined in the `devspace.yaml` of this dependency. When configuring this option, this profile will be used to deploy the dependency, i.e. the dependency will be deployed similar to running `devspace deploy -p [profile]` within the folder of the dependency. + +#### Example: Use Config Profile for Dependency +```yaml +dependencies: +- source: + git: https://github.com/my-api-server + profile: production +``` diff --git a/docs/versioned_docs/version-4.13/fragments/dependency-skipBuild.mdx b/docs/versioned_docs/version-4.13/fragments/dependency-skipBuild.mdx new file mode 100644 index 0000000000..96fee3ea55 --- /dev/null +++ b/docs/versioned_docs/version-4.13/fragments/dependency-skipBuild.mdx @@ -0,0 +1,18 @@ +The `skipBuild` option expects a boolean that defines if the image building process should be skipped when deploying this dependency. This is often useful if you rather want to use the tags that are defined in the deployment files (e.g. manifests or helm charts) which may reference more stable, production-like versions of the images. + +:::info +Using `skipBuild` is useful when trying to speed up the dependency deployment process, especially when working with many dependencies that frequently change. +::: + +#### Default Value For `skipBuild` +```yaml +skipBuild: false +``` + +#### Example: Skip Build for Dependency +```yaml +dependencies: +- source: + git: https://github.com/my-api-server + skipBuild: true +``` diff --git a/docs/versioned_docs/version-4.13/fragments/faq-image-context.mdx b/docs/versioned_docs/version-4.13/fragments/faq-image-context.mdx new file mode 100644 index 0000000000..ca104f7443 --- /dev/null +++ b/docs/versioned_docs/version-4.13/fragments/faq-image-context.mdx @@ -0,0 +1,10 @@ +
+What does "context" mean in terms of image building? + +
+ +The context is archived and sent to the Docker daemon before starting to process the Dockerfile. All references of local files within the Dockerfile are relative to the root directory of the context. + +That means that a Dockerfile statement such as `COPY ./src /app` would copy the folder `src/` within the context path into the path `/app` within the container image. So, if the context would be `/my/project/database`, for example, the folder that would be copied into `/app` would have the absolute path `/my/project/database/src` on your local computer. + +
diff --git a/docs/versioned_docs/version-4.13/fragments/info-component-chart.mdx b/docs/versioned_docs/version-4.13/fragments/info-component-chart.mdx new file mode 100644 index 0000000000..298ca4cdf0 --- /dev/null +++ b/docs/versioned_docs/version-4.13/fragments/info-component-chart.mdx @@ -0,0 +1,3 @@ +:::info 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](https://devspace.sh/component-chart/docs/introduction)**. +::: diff --git a/docs/versioned_docs/version-4.13/fragments/kubectl-kustomize.mdx b/docs/versioned_docs/version-4.13/fragments/kubectl-kustomize.mdx new file mode 100644 index 0000000000..a70dde2e5e --- /dev/null +++ b/docs/versioned_docs/version-4.13/fragments/kubectl-kustomize.mdx @@ -0,0 +1,21 @@ +The `kustomize` option expects a boolean stating if DevSpace should deploy using `kustomize` (or alternatively: `kubectl apply -k`). + +:::warning +If you set `kustomize = true`, all of your `manifests` must be paths to Kustomizations. If you want to deploy some plain manifests and some Kustomizations, create multiple deployments for each of them. +::: + +#### Default Value for `kustomize` +```yaml +kustomize: false +``` + +#### Example: Kustomize +```yaml {4} +deployments: +- name: backend + kubectl: + kustomize: true + manifests: + - kustomization1/ + - glob/path/to/more/kustomizations/ +``` diff --git a/docs/versioned_docs/version-4.13/fragments/kubectl-options-applyArgs.mdx b/docs/versioned_docs/version-4.13/fragments/kubectl-options-applyArgs.mdx new file mode 100644 index 0000000000..b1ba2ed738 --- /dev/null +++ b/docs/versioned_docs/version-4.13/fragments/kubectl-options-applyArgs.mdx @@ -0,0 +1,29 @@ +The `applyArgs` option expects an array of strings stating additional arguments (and flags) that should be used when calling `kubectl apply`. + +:::info Apply for Kustomize Deployments +Even if you set `kustomize: true`, DevSpace only renders the manifest templates using kustomize but the actual deployment will be executed using `kubectl apply`. +::: + +#### Default Value for `applyArgs` +```yaml +applyArgs: [] +``` + +#### Example: Custom Kubectl Args & Flags +```yaml +deployments: +- name: backend + kubectl: + manifests: + - backend/ + applyArgs: + - "--timeout" + - "10s" + - "--grace-period" + - "30" +``` +**Explanation:** +Deploying the above example would roughly be equivalent to this command: +```bash +kubectl apply --timeout=10s --grace-period=30 -f backend/ +``` diff --git a/docs/versioned_docs/version-4.13/fragments/kubectl-options-cmdPath.mdx b/docs/versioned_docs/version-4.13/fragments/kubectl-options-cmdPath.mdx new file mode 100644 index 0000000000..337bdb4e2a --- /dev/null +++ b/docs/versioned_docs/version-4.13/fragments/kubectl-options-cmdPath.mdx @@ -0,0 +1,20 @@ +The `cmdPath` option expects an array of strings stating additional flags and flag values that should be used when calling `kubectl apply`. + +:::warning +Setting `cmdPath` makes it much harder to share your `devspace.yaml` with other team mates. It is recommended to add `kubectl` to your `$PATH` environment variable instead. +::: + +#### Example: Setting Path To Kubectl Binary +```yaml +deployments: +- name: backend + kubectl: + manifests: + - backend/ + cmdPath: /path/to/kubectl +``` +**Explanation:** +Deploying the above example would roughly be equivalent to this command: +```bash +/path/to/kubectl apply -f backend/ +``` diff --git a/docs/versioned_docs/version-4.13/fragments/kubectl-options-deleteArgs.mdx b/docs/versioned_docs/version-4.13/fragments/kubectl-options-deleteArgs.mdx new file mode 100644 index 0000000000..70a473533c --- /dev/null +++ b/docs/versioned_docs/version-4.13/fragments/kubectl-options-deleteArgs.mdx @@ -0,0 +1,29 @@ +The `deleteArgs` option expects an array of strings stating additional arguments (and flags) that should be used when calling `kubectl delete`. + +:::info Purging Deployments +For plain manifests or Kustomizations, DevSpace uses `kubectl delete` to remote deployments when you run the command `devspace purge`. +::: + +#### Default Value for `deleteArgs` +```yaml +deleteArgs: [] +``` + +#### Example: Custom Kubectl Args & Flags +```yaml +deployments: +- name: backend + kubectl: + manifests: + - backend/ + deleteArgs: + - "--timeout" + - "10s" + - "--grace-period" + - "30" +``` +**Explanation:** +Deploying the above example would roughly be equivalent to this command: +```bash +kubectl delete --timeout=10s --grace-period=30 -f backend/ +``` diff --git a/docs/versioned_docs/version-4.13/fragments/kubectl-replaceImageTags.mdx b/docs/versioned_docs/version-4.13/fragments/kubectl-replaceImageTags.mdx new file mode 100644 index 0000000000..aae897a71a --- /dev/null +++ b/docs/versioned_docs/version-4.13/fragments/kubectl-replaceImageTags.mdx @@ -0,0 +1,22 @@ +The `replaceImageTags` option expects a boolean stating if DevSpace should replace/update all image tags before deploying the project. + +By default, DevSpace searches all your manifests 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. + +:::info 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. +::: + +#### Default Value for `replaceImageTags` +```yaml +replaceImageTags: true +``` + +#### Example: Disable Tag Replacement +```yaml {4} +deployments: +- name: backend + kubectl: + replaceImageTags: false + manifests: + - backend/ +``` diff --git a/docs/versioned_docs/version-4.13/fragments/note-create-space.mdx b/docs/versioned_docs/version-4.13/fragments/note-create-space.mdx new file mode 100644 index 0000000000..d0e360b7bd --- /dev/null +++ b/docs/versioned_docs/version-4.13/fragments/note-create-space.mdx @@ -0,0 +1,6 @@ +:::note 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: +```bash +kubectl get pods +``` +::: diff --git a/docs/versioned_docs/version-4.13/fragments/note-general-purpose-command.mdx b/docs/versioned_docs/version-4.13/fragments/note-general-purpose-command.mdx new file mode 100644 index 0000000000..6ef545d400 --- /dev/null +++ b/docs/versioned_docs/version-4.13/fragments/note-general-purpose-command.mdx @@ -0,0 +1,3 @@ +:::note +This command is a general purpose command which also works for any pod/container in Kubernetes even if you are not within a DevSpace project. +::: diff --git a/docs/versioned_docs/version-4.13/fragments/profile-parent.mdx b/docs/versioned_docs/version-4.13/fragments/profile-parent.mdx new file mode 100644 index 0000000000..bdec5b6140 --- /dev/null +++ b/docs/versioned_docs/version-4.13/fragments/profile-parent.mdx @@ -0,0 +1,42 @@ +The `parent` option is optional and expects the name of another profile which should be applied before this profile. The kind of profile inheritance that the `parent` option provides can help to reduce redundancy when multiple profiles need to change the config in a similar way. + +:::info Execution Order +A parent profile is applied before the profile that defines the parent. A parent profile can have a parent of its own. +::: + +#### Example: Defining a Parent Profile +```yaml {16} +images: + backend: + image: john/devbackend + backend-debugger: + image: john/debugger +deployments: +- name: backend + helm: + componentChart: true + values: + containers: + - image: john/devbackend + - image: john/debugger +profiles: +- name: production + parent: staging + patches: + - op: add + path: deployments.name=backend.helm.values.containers + value: + image: john/cache +- name: staging + replace: + images: + backend: + image: john/backendprod + patches: + - op: replace + path: deployments.name=backend.helm.values.container[0].image + value: john/backendprod + - op: remove + path: deployments.name=backend.helm.values.containers[1] +``` +When the `production` profile is active, the `replace` and `patches` statements configured in `staging` would be applied first because of the `parent: staging` statement in line 16. After applying the `staging` profile, DevSpace would additionally apply the currently active `production` profile. In this example, the `production` profile is based on the `staging` profile and the only difference is that the `production` profile adds another container to the `backend` deployment which is using the image `john/cache`. diff --git a/docs/versioned_docs/version-4.13/fragments/tip-print-config.mdx b/docs/versioned_docs/version-4.13/fragments/tip-print-config.mdx new file mode 100644 index 0000000000..9a335a196e --- /dev/null +++ b/docs/versioned_docs/version-4.13/fragments/tip-print-config.mdx @@ -0,0 +1,5 @@ +The following command is useful to verify that the profile modifies the config as intended: +```bash +devspace print -p my-profile +``` +The above command would print the config after applying all profile `patches` and `replace` statements as well as after replacing all config variables. diff --git a/docs/versioned_docs/version-4.13/fragments/tip-use-namespace.mdx b/docs/versioned_docs/version-4.13/fragments/tip-use-namespace.mdx new file mode 100644 index 0000000000..91299c6d90 --- /dev/null +++ b/docs/versioned_docs/version-4.13/fragments/tip-use-namespace.mdx @@ -0,0 +1,3 @@ +:::tip 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. +::: diff --git a/docs/versioned_docs/version-4.13/fragments/vars-default.mdx b/docs/versioned_docs/version-4.13/fragments/vars-default.mdx new file mode 100644 index 0000000000..db6c0d4e3b --- /dev/null +++ b/docs/versioned_docs/version-4.13/fragments/vars-default.mdx @@ -0,0 +1,5 @@ +The `default` option expects a string defining the default value for the variable. + +:::note Type Casting +If a default value is specified, DevSpace will assume the type of the default value as the type for the variable, i.e. when `default: "123"` is defined and a value of `123` (int) is provided it would be casted to `"123"` (string). To explicitly use the value of a variable as a string within `devspace.yaml`, use `$!{VAR_NAME}` instead of `${VAR_NAME}`. +::: diff --git a/docs/versioned_docs/version-4.13/fragments/vars-force-string.mdx b/docs/versioned_docs/version-4.13/fragments/vars-force-string.mdx new file mode 100644 index 0000000000..7509a3df05 --- /dev/null +++ b/docs/versioned_docs/version-4.13/fragments/vars-force-string.mdx @@ -0,0 +1,3 @@ +:::note Variable Type +By default, the type (string, int, bool) of variable will be determined by the type of its [`default` value](#default) (if defined) or automatically detected if no default value is defined. To explicitly use the value of a variable as a string, use `$!{VAR_NAME}` instead of `${VAR_NAME}`. +::: diff --git a/docs/versioned_docs/version-4.13/fragments/vars-name.mdx b/docs/versioned_docs/version-4.13/fragments/vars-name.mdx new file mode 100644 index 0000000000..49014a7d7e --- /dev/null +++ b/docs/versioned_docs/version-4.13/fragments/vars-name.mdx @@ -0,0 +1,5 @@ +The `name` option expects a string stating the name of the config variable that will be used to reference it within the remainder of the configuration. + +:::info Must be unique +The `name` of a config variable must be unique and is mandatory when defining a config variable. +::: diff --git a/docs/versioned_docs/version-4.13/fragments/warning-build-tool-priority.mdx b/docs/versioned_docs/version-4.13/fragments/warning-build-tool-priority.mdx new file mode 100644 index 0000000000..f709c200df --- /dev/null +++ b/docs/versioned_docs/version-4.13/fragments/warning-build-tool-priority.mdx @@ -0,0 +1,7 @@ +:::warning Build Tool Priority +If you specify multiple build tools, DevSpace will try to use them in the following order: +1. `disabled` +2. `custom` +3. `docker` (uses kaniko as fallback if Docker host not reachable) +4. `kaniko` +::: diff --git a/docs/versioned_docs/version-4.13/fragments/warning-multiple-dev.mdx b/docs/versioned_docs/version-4.13/fragments/warning-multiple-dev.mdx new file mode 100644 index 0000000000..652cdbedd9 --- /dev/null +++ b/docs/versioned_docs/version-4.13/fragments/warning-multiple-dev.mdx @@ -0,0 +1,8 @@ +:::warning +It is highly discouraged to run `devspace dev` multiple times in parallel because multiple instances of port forwarding and file synchronization will disturb each other. Instead: + +- Run `devspace enter` to open additional terminal sessions without port forwarding and file sync +- Run `devspace logs` to start log streaming without port forwarding and file sync +- Run `devspace sync` to sync files on-demand without starting port forwarding etc. +- Run `devspace ui` to open the localhost development UI in the browser +::: diff --git a/docs/versioned_docs/version-4.13/fragments/workflow-build-images.mdx b/docs/versioned_docs/version-4.13/fragments/workflow-build-images.mdx new file mode 100644 index 0000000000..fc3261d5d8 --- /dev/null +++ b/docs/versioned_docs/version-4.13/fragments/workflow-build-images.mdx @@ -0,0 +1 @@ +DevSpace triggers the image building process for the images specified in the `images` section of the `devspace.yaml`. diff --git a/docs/versioned_docs/version-4.13/fragments/workflow-deploy-dependencies.mdx b/docs/versioned_docs/version-4.13/fragments/workflow-deploy-dependencies.mdx new file mode 100644 index 0000000000..dc4766551b --- /dev/null +++ b/docs/versioned_docs/version-4.13/fragments/workflow-deploy-dependencies.mdx @@ -0,0 +1,7 @@ +DevSpace loads the `dependencies` section from the `devspace.yaml` and creates a dependency tree. The current project will represent the root of this tree. Based on this dependency tree, DevSpace will start from the leaves and run these steps for each dependency: +- Build images of the dependency as configured in the `images` section of the dependency's `devspace.yaml` (unless `skipBuild: true`) +- Deploy the dependency as configured in the `deployments` section of the dependency's `devspace.yaml` + +:::note What are Dendencies? +Dependencies allow you to deploy microservices, that the project you are currently deploying relies on. Dependencies can be located in a subpath of your project or they can be automatically loaded from a different git repository. +::: diff --git a/docs/versioned_docs/version-4.13/fragments/workflow-deploy-project.mdx b/docs/versioned_docs/version-4.13/fragments/workflow-deploy-project.mdx new file mode 100644 index 0000000000..cc11700257 --- /dev/null +++ b/docs/versioned_docs/version-4.13/fragments/workflow-deploy-project.mdx @@ -0,0 +1,7 @@ +DevSpace iterates over every item in the `deployments` array defined in the `devspace.yaml` and deploys each of the deployments using the respective deployment tool: +- `kubectl` deployments will be deployed with `kubectl` (optionally using `kustomize` if `kustomize: true`) +- `helm` deployments will be deployed with the `helm` client that comes in-built with DevSpace + +:::info kubectl Required +Deployments with `kubectl` require `kubectl` to be installed. +::: diff --git a/docs/versioned_docs/version-4.13/fragments/workflow-open-links.mdx b/docs/versioned_docs/version-4.13/fragments/workflow-open-links.mdx new file mode 100644 index 0000000000..cb54a95ec2 --- /dev/null +++ b/docs/versioned_docs/version-4.13/fragments/workflow-open-links.mdx @@ -0,0 +1,4 @@ + +1. DevSpace starts to periodically send `HTTP GET` requests to the URLs provideded via `dev.open[*].url`. +2. As soon as the first HTTP response has a status code which is neither 502 (Bad Gateway) nor 503 (Service Unavailable), DevSpace assumes that the application is now started, stops sending any further requests and opens the provided URL in the browser. +3. If the URL is still returning status code 502 or 503 after 4min, DevSpace will stop trying to open it. To not disturb the log streaming or the interactive terminal session, DevSpace will not show an error when hitting the 4min timeout. diff --git a/docs/versioned_docs/version-4.13/fragments/workflow-replace-tags.mdx b/docs/versioned_docs/version-4.13/fragments/workflow-replace-tags.mdx new file mode 100644 index 0000000000..5b20a0e0be --- /dev/null +++ b/docs/versioned_docs/version-4.13/fragments/workflow-replace-tags.mdx @@ -0,0 +1,7 @@ +After finishing the image building process, DevSpace searches your deployments for references to the images that are specified in the `images` section of the `devspace.yaml`. If DevSpace finds that an image is used by one of your deployments and the deployment does not explicitly define a tag for the image, DevSpace will append the tag that has been auto-generated as part of the automated image tagging during the image building process. + +:::warning Prevent Hard-Coded Tags +To use automated tag replacement, make sure you do **not** specify image tags in the deployment configuration. +::: + +Replacing or appending tags to images that are used in your deployments makes sure that your deployments are always started using the most recently pushed image tag. This automated process saves a lot of time compared to manually replacing image tags each time before you deploy something. diff --git a/docs/versioned_docs/version-4.13/getting-started/deployment.mdx b/docs/versioned_docs/version-4.13/getting-started/deployment.mdx new file mode 100644 index 0000000000..baa1f49b32 --- /dev/null +++ b/docs/versioned_docs/version-4.13/getting-started/deployment.mdx @@ -0,0 +1,67 @@ +--- +title: Deployment with DevSpace +sidebar_label: 4. Build & Deploy +--- + + +
+ +
DevSpace CLI - Deployment
+
+ + +## Deploy Project +Run the local deployment pipeline using this command: +```bash +devspace deploy +``` + +Running `devspace deploy` will do the following: + +1. **Build the Dockerfile(s)** specified in the [`images` section of the `devspace.yaml`](../configuration/images/basics.mdx) +2. **Tag** the resulting image(s) with an auto-generated tag according to a [customizable tag schema](../configuration/images/basics.mdx) +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`](../configuration/deployments/basics.mdx) + +
+ Deployment Workflow +
DevSpace CLI - Deployment Workflow
+
+ +:::note Image Building Only +If you only want to build, tag and push all images but not deploy anything, run: +```bash +devspace build +``` +::: + + +
+ +## Deploy to Production +As shown earlier, DevSpace is by default configured to override your `ENTRYPOINT` to restart your application after files are synchronized into the container. However, in production, we don't want DevSpace to change anything about our Docker image. That's why you see the following section in your devspace.yaml: + +```yaml +profiles: +- name: production # Name of this profile: production + patches: # Patches to change the config for this profile + - op: remove # A patch to remove the injectResartHelper option + path: images.app.injectRestartHelper + - op: remove # Second patch ONLY for multi-stage builds + path: images.app.build.docker.options.target # Remote the build target to build entire Dockerfile +``` + +Profiles allow you to modify the config for certain use cases or deployment environment (e.g. your production cluster). You can print the config after applying all patches of this profile using this command: +```bash +devspace print -p production +``` + +The flag `-p / --profile` is a global flag, so we can also use it to apply this profile during the deployment process: +```bash +devspace deploy -p production +``` + +Learn more about [integrating DevSpace into your CI/CD pipelines](../guides/ci-cd-integration.mdx). diff --git a/docs/versioned_docs/version-4.13/getting-started/development.mdx b/docs/versioned_docs/version-4.13/getting-started/development.mdx new file mode 100644 index 0000000000..7f98361257 --- /dev/null +++ b/docs/versioned_docs/version-4.13/getting-started/development.mdx @@ -0,0 +1,118 @@ +--- +title: Development with DevSpace +sidebar_label: 4. Build & Develop +--- + +import FragmentWarningMultipleDev from '../fragments/warning-multiple-dev.mdx'; + +DevSpace allows you to develop applications directly inside a Kubernetes cluster. + +The biggest advantages of developing directly inside Kubernetes is that your dev environment will be very similar to your production environment and you can have a much greater confidence that everything will work in production when shipping new features. + +## Start Development Mode +Run the following command to start your application in development mode: +```bash +devspace dev +``` + +
+ +
DevSpace CLI - Development Mode
+
+ + +When running `devspace dev`, the `dev` section in `devspace.yaml` becomes important: +```yaml +dev: + ports: # Port Forwarding Configuration + - imageName: app # Select pod & container by image name (reference to images section) + forward: # List of ports to forward + - port: 8080 + open: # Open Browser (after deployment) + - url: http://localhost:8080 + sync: # File Sync Configuration + - imageName: app # Select pod & container by image name (reference to images section) + uploadExcludePaths: # Never upload these files from local filesystem to the container + - Dockerfile + - .git + - devspace.yaml + onUpload: # Commands to execute after uploading files + restartContainer: true # Restart the container (uses the restart helper) +``` + +Running `devspace dev` will do the following: + +1. **Build and deploy** your application +2. **Stream the logs** of all containers deployed during the deployment process +3. **Forward all ports** specified in the [`dev.ports` section in the `devspace.yaml`](../configuration/development/port-forwarding.mdx) +4. **Sync all file changes** according to the [sync config in `dev.sync`](../configuration/development/file-synchronization.mdx), so you can restart your application inside the running container without having to rebuild images or redeploy anything + +
+ +
+ Deployment Workflow +
DevSpace CLI - Deployment Workflow
+
+ + +
+ +## Workflows + +### 1. Edit Files & Restart +While `devspace dev` is running, your source code files will be synchronized between your local project folder and your containers running inside Kubernetes. This allows you to code with your favorite IDE or text editor without having to rebuild your images or redeploy your containers. + +**Try it and just edit a file!** + +You will see that the logs show how DevSpace restarts your application inside the container: +```logs +[app] ############### Restart container ############### +``` + + +### 2. Open UI (in the browser) +When running `devspace dev`, DevSpace starts a client-only UI for Kubernetes. You can see that in the output of `devspace dev` which should contain a log line similar to this one: +```bash +######################################################### +[info] DevSpace UI available at: http://localhost:8090 +######################################################### +``` + +By default, DevSpace starts the development UI on port `8090` but if the port is already in use, it will use a different port. If `devspace dev` is running, you can open the link shown in the `devspace dev` logs, e.g. [http://localhost:8090](http://localhost:8090) + +You can also start the UI without running `devspace dev` using this command: +```bash +devspace ui +``` + +[Follow this guide to learn more about the functionalities of the DevSpace UI for Kubernetes development.](../guides/localhost-ui.mdx) + +
+ +
DevSpace CLI - Development UI
+
+ +:::info Runs on Localhost +The UI of DevSpace is open-source just like the rest of the CLI and it runs entirely on localhost. +::: + + +### 3. Use Port Forwarding +While `devspace dev` is running, you can access your application via `localhost:[PORT]` because DevSpace starts port forwarding for all ports specified in the `dev.ports` section of your project's `devspace.yaml`. + +Port forwarding also allows you to attach to remote debuggers if you package them into your development Docker image. This allows you to set breakpoints in your IDE and the code execution will break inside the remote container while you can debug in your IDE. + +:::info Port Detection +When running `devspace init`, DevSpace detects all ports within your Dockerfile (i.e. `EXPOSE [PORT]` lines) and automatically configures forwarding for them when creating the `devspace.yaml`. +::: + +Learn more about how to [configure port forwarding](../configuration/development/port-forwarding.mdx). + + +## Notes + + diff --git a/docs/versioned_docs/version-4.13/getting-started/initialize-project.mdx b/docs/versioned_docs/version-4.13/getting-started/initialize-project.mdx new file mode 100644 index 0000000000..b1c07db3a3 --- /dev/null +++ b/docs/versioned_docs/version-4.13/getting-started/initialize-project.mdx @@ -0,0 +1,270 @@ +--- +title: Initialize a Project +sidebar_label: 2. Initialize Project +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; +import Step from '@site/src/components/Step/Step'; +import FragmentTipUseNamespace from '../fragments/tip-use-namespace.mdx'; +import FragmentNoteCreateSpace from '../fragments/note-create-space.mdx'; + +## Choose a Project +You can either deploy one of your own projects or alternatively, checkout one of our demo applications using git: + + + + +```bash +git clone https://github.com/devspace-cloud/quickstart-nodejs +cd quickstart-nodejs +``` + +:::note Tutorials +After finishing this Getting Started Guide, make sure to also check out one of these tutorials: +- [Deploy an Express.js Server to Kubernetes using DevSpace](https://devspace.cloud/blog/2019/10/15/deploy-express.js-server-to-kubernetes) +- [Deploy React.js Apps to Kubernetes using DevSpace](https://devspace.cloud/blog/2019/03/07/deploy-react-js-to-kubernetes) +- [Deploy Vue.js Apps to Kubernetes using DevSpace](https://devspace.cloud/blog/2019/09/30/deploy-vue-js-to-kubernetes) +::: + + + + +```bash +git clone https://github.com/devspace-cloud/quickstart-python +cd quickstart-python +``` + +:::note Tutorial +After finishing this Getting Started Guide, make sure to also check out the tutorial: [Deploy Django Projects to Kubernetes using DevSpace](https://devspace.cloud/blog/2019/10/18/deploy-django-to-kubernetes) +::: + + + + +```bash +git clone https://github.com/devspace-cloud/quickstart-ruby +cd quickstart-ruby +``` + +:::note Tutorial +After finishing this Getting Started Guide, make sure to also check out the tutorial: [Deploy Ruby on Rails to Kubernetes using DevSpace](https://devspace.cloud/blog/2019/10/21/deploy-ruby-on-rails-to-kubernetes) +::: + + + + +```bash +git clone https://github.com/devspace-cloud/quickstart-golang +cd quickstart-golang +``` + + + + +```bash +git clone https://github.com/devspace-cloud/quickstart-php +cd quickstart-php +``` + +:::note Tutorial +After finishing this Getting Started Guide, make sure to also check out the tutorial: [Deploy Laravel Projects to Kubernetes using DevSpace](https://devspace.cloud/blog/2019/10/16/deploy-laravel-to-kubernetes) +::: + + + + +```bash +git clone https://github.com/devspace-cloud/quickstart-java +cd quickstart-java +``` + + + + +```bash +git clone https://github.com/devspace-cloud/quickstart-asp-dotnet +cd quickstart-asp-dotnet +``` + + + + +```bash +# Navigate to the root directory of your project +cd /path/to/your/project +``` + +:::info +If you are using DevSpace for the first time, it is highly recommended that you use one of the demo projects. +::: + + + + + +
+ +## Initialize Your Project +Run this command in your project directory to create a `devspace.yaml` config file for your project: +```bash +devspace init +``` + +
+ +
DevSpace CLI - Initialize Project
+
+ +While initializing your project, DevSpace will ask you a couple of questions and then create the config file `devspace.yaml` which will look similar to this one: + +```yaml +# Config version +version: v1beta9 + +# Defines all Dockerfiles that DevSpace will build, tag and push +images: + app: # Key 'app' = Name of this image + image: reg.tld/username/devspace # Registry and image name for pushing the image + preferSyncOverRebuild: true + injectRestartHelper: true + build: ... + +# Defines an array of everything (component, Helm chart, Kubernetes maninfests) +# that will be deployed with DevSpace in the specified order +deployments: +- name: quickstart # Name of this deployment + helm: # Deploy using Helm + componentChart: true # Use the Component Helm Chart + values: # Override Values for chart (can also be set using valuesFiles option) + containers: # Defines an array of containers that run in the same pods started by this component + - image: reg.tld/username/devspace # Image of this container + service: # Expose this component with a Kubernetes service + ports: # Array of container ports to expose through the service + - port: 3000 # Exposes container port 3000 on service port 3000 + +# Settings for development mode (will be explained later) +dev: ... + +# Settings for development mode (will be explained later) +profiles: ... +``` + +
+ +## Prepare Kube-Context +To develop and deploy your project with DevSpace, you need a valid kube-context because DevSpace uses the kube-config file just like kubectl or helm. + + + + +:::info Free Demo Namespace +If you don't have a Kubernetes cluster or simply want to test DevSpace without using your own cluster, choose the free demo namespaces sponsored by DevSpace Cloud. [Learn more about Demo Spaces.](https://devspace.cloud/products/devspace-cloud#pricing) +::: + +Run the following command to create a free Kubernetes namespace: +```bash +devspace create space my-app # requires login via GitHub or email +``` + + + + + + +:::note 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: + +```bash +devspace use namespace my-namespace # will be automatically created during deployment +``` + + + + + + +:::note Remote Clusters +Remote clusters run in a cloud or private data center and include: GKE, EKS, AKS, bare metal etc. +::: + +When using a remote cluster, you can either use it just for yourself or you can share the cluster with your colleagues. + + + + +```bash +devspace use namespace my-namespace # will be automatically created during deployment +``` + + + + + + +
+1 + +Connect cluster to DevSpace Cloud +```bash +devspace connect cluster +``` +Learn more about connecting cluster in the [documentation of DevSpace Cloud](https://devspace.cloud/cloud/docs/admin/getting-started/connect-clusters). + +:::info DevSpace Cloud On-Premise +Instead of using the SaaS edition of DevSpace Cloud, you can also [install the on-premise edition in your own cluster](https://devspace.cloud/cloud/docs/admin/getting-started/setup#choose-saas-vs-on-premise). +::: + +
+2 + +Create isolated namespace (= Space) + +```bash +devspace create space my-app # requires login via GitHub or email +``` + + + +
+3 + +Add cluster users and allow them to create Spaces + +Learn more about how to do this in the [documentation of DevSpace Cloud](https://devspace.cloud/cloud/docs/admin/getting-started/cluster-users). + + + + + + diff --git a/docs/versioned_docs/version-4.13/getting-started/installation.mdx b/docs/versioned_docs/version-4.13/getting-started/installation.mdx new file mode 100644 index 0000000000..67904c9e9f --- /dev/null +++ b/docs/versioned_docs/version-4.13/getting-started/installation.mdx @@ -0,0 +1,72 @@ +--- +title: Install DevSpace CLI +sidebar_label: 1. Install CLI +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + + + + +```bash +npm install -g devspace +``` + + + + +```bash +yarn global add devspace +``` + + + + +```bash +curl -s -L "https://github.com/devspace-cloud/devspace/releases/latest" | sed -nE 's!.*"([^"]*devspace-darwin-amd64)".*!https://github.com\1!p' | xargs -n 1 curl -L -o devspace && chmod +x devspace; +sudo mv devspace /usr/local/bin; +``` + + + + +```bash +curl -s -L "https://github.com/devspace-cloud/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; +``` + + + + +```powershell {4} +md -Force "$Env:APPDATA\devspace"; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]'Tls,Tls11,Tls12'; +Invoke-WebRequest -UseBasicParsing ((Invoke-WebRequest -URI "https://github.com/devspace-cloud/devspace/releases/latest" -UseBasicParsing).Content -replace "(?ms).*`"([^`"]*devspace-windows-amd64.exe)`".*","https://github.com/`$1") -o $Env:APPDATA\devspace\devspace.exe; +$env:Path += ";" + $Env:APPDATA + "\devspace"; +[Environment]::SetEnvironmentVariable("Path", $env:Path, [System.EnvironmentVariableTarget]::User); +``` + +:::info Check Environment Variable $PATH +Line 4 of this install script adds the install directory `%APPDATA%\devspace` to the `$PATH` environment variable. This is only effective for the current powershell session, i.e. when opening a new terminal window, `devspace` may not be found. + +**Make sure to add the folder `%APPDATA%\devspace` to the `PATH` environment variable after installing DevSpace via Powershell. Afterwards, a reboot might be necessary.** + +To confirm that DevSpace is successfully installed, reboot and test via: +```bash +devspace --version +``` +::: + + + + +Alternatively, you can simply download the binary for your platform from the [GitHub Releases](https://github.com/devspace-cloud/devspace/releases) page and add this binary to your PATH. diff --git a/docs/versioned_docs/version-4.13/getting-started/next-steps.mdx b/docs/versioned_docs/version-4.13/getting-started/next-steps.mdx new file mode 100644 index 0000000000..7f7c87e197 --- /dev/null +++ b/docs/versioned_docs/version-4.13/getting-started/next-steps.mdx @@ -0,0 +1,23 @@ +--- +title: Next Steps +sidebar_label: 5. Next Steps +--- + +## Tutorials +- **Ruby:** [Deploy Ruby on Rails to Kubernetes using DevSpace](https://devspace.cloud/blog/2019/10/21/deploy-ruby-on-rails-to-kubernetes) +- **Python:** [Deploy Django Projects to Kubernetes using DevSpace](https://devspace.cloud/blog/2019/10/18/deploy-django-to-kubernetes) +- **PHP:** [Deploy Laravel Projects to Kubernetes using DevSpace](https://devspace.cloud/blog/2019/10/16/deploy-laravel-to-kubernetes) +- **Node.js:** + - [Deploy an Express.js Server to Kubernetes using DevSpace](https://devspace.cloud/blog/2019/10/15/deploy-express.js-server-to-kubernetes) + - [Deploy Vue.js Apps to Kubernetes using DevSpace](https://devspace.cloud/blog/2019/09/30/deploy-vue-js-to-kubernetes) + - [Deploy React.js Apps to Kubernetes using DevSpace](https://devspace.cloud/blog/2019/03/07/deploy-react-js-to-kubernetes) + +## Guides +- [Onboarding Guide](../guides/basics.mdx) to share with the rest of your team +- [Network & Domains Guide](../guides/networking-domains.mdx) +- [CI/CD Integration Guide](../guides/ci-cd-integration.mdx) + +## Best Practices +- [Image Building](../guides/image-building.mdx) +- [Dev vs Staging vs Production](../guides/dev-staging-production.mdx) +- [Remote Debugging](../guides/remote-debugging.mdx) diff --git a/docs/versioned_docs/version-4.13/guides/basics.mdx b/docs/versioned_docs/version-4.13/guides/basics.mdx new file mode 100644 index 0000000000..dbf59e2588 --- /dev/null +++ b/docs/versioned_docs/version-4.13/guides/basics.mdx @@ -0,0 +1,237 @@ +--- +title: Onboarding Guide +sidebar_label: Onboarding +--- + +## View Help & Flags +To see help information and a list of all flags for any command, simply use the `-h` flag: +```bash +devspace dev -h +``` + +
+ +--- + + +## Project-Specific Commands + +:::note devspace.yaml required +The project-specific commands require that your project is already [initialized](../getting-started/initialize-project.mdx), i.e. there is a `devspace.yaml` config file. +::: + + +### Start Development +This command deploys the project and then starts the development mode: +```bash +devspace dev +``` + +To start a terminal at the end of `devspace dev` instead of showing the container logs, run: +```bash +devspace dev -t +``` + +This command starts the interactive mode for development: +```bash +devspace dev -i +``` +:::info +Interactive mode is similar to the `-t` flag which shows a terminal instead of streaming the logs in the development mode but interactive mode also overrides the `ENTRYPOINT` of one of your containers, so you can start your application manually. This is great for debugging failing containers. +::: + + +### Deploy Project +This commands deploys the project to Kubernetes: +```bash +devspace deploy +``` + +Run this command to just build, tag and push all images to a registry without deploying the project: +```bash +devspace build +``` + + +### Open Project +This command opens the current project in the browser: +```bash +devspace open +``` + +:::note Must be deployed +This command requires that the project has already been deployed. +::: + + +### Commands +This command lists all available command: +```bash +devspace list commands +``` + +Use this command to run one of the custom commands: +```bash +devspace run command [command-name] -- --some-flag --another-flag=value +``` + + +### Profiles +This command lists all available profiles: +```bash +devspace list profiles +``` + +Use this command to switch to a different profile: +```bash +devspace use profile [optional:profile-name] +``` + +Use the `-p` flag to just run a single command with a different profile without switching it permanently: +```bash +devspace deploy -p [profile-name] +``` + +Use this command to print the config after a profile has been applied: +```bash +devspace print -p [profile-name] +``` + + +### Variables +This command lists all variables as well as their values: +```bash +devspace list vars +``` + +Use this command to reset all variables, i.e. delete variable values from the variable cache: +```bash +devspace reset vars +``` + +Use this command to print the config after all variables have been replaced: +```bash +devspace print +``` + + +### Dependencies +Use this command to update git-based dependencies: +```bash +devspace update dependencies +``` +This command performs a `git fetch && git pull` for all git-based dependencies. + +Use this command to clear the dependencies cache: +```bash +devspace reset dependencies +``` + +
+ +--- + +## General Purpose Commands + +### Open UI +This command opens the localhost development UI: +```bash +devspace ui +``` +:::note Development Mode +The localhost development UI starts automatically in the background when running: `devspace dev` +::: + + +### Stream Logs +This command streams logs of a container: +```bash +devspace logs +``` + + +### Terminal & Commands +This command opens an interactive terminal session for a container: +```bash +devspace enter +``` + +To run just a single command inside a container, use: +```bash +devspace enter -- my-command --my-flag=my-value ... +``` + + +### File Sync +This command starts an on-demand file synchronization between localhost and a container: +```bash +devspace sync +``` + +:::note Development Mode +If file sync is configured in your project, it automatically starts when running: `devspace dev` +::: + +Use this command to view the status of the file sync during development mode: +```bash +devspace status sync +``` + + +
+ +--- + + +## Namespace & Contexts +This command creates a new Space: +```bash +devspace create space [space-name] +``` + +This command switches to a different Space: +```bash +devspace use space [optional:space-name] +``` + +This command switches to a different kube-context: +```bash +devspace use context [optional:context-name] +``` + +This command sets a different namespace as default namespace for the current kube-context: +```bash +devspace use namespace [optional:namespace] +``` + +:::info Not for Spaces +The command `devspace use namespace` does **not** work for Spaces. Use `devspace use space` instead. +::: + + +
+ +## Advanced + +### Clean up Images +When using Docker for image building, disk space on your local computer can get sparse after a lot of Docker builds. DevSpace provides a convenient command to clean up all images that were built with your local Docker daemon using DevSpace. This command does not remove any pushed images remotely and just clears local images and space. + +In order to clean up all created images locally, simply run the following command in your project folder: +```bash +devspace cleanup images +``` + +### Clean up Docker +In addition, it also makes sense to prune your Docker environment to free additional space with the following command: + +```bash +docker system prune +``` + +This command will remove: +- all stopped containers +- all networks not used by at least one container +- all dangling images +- all build cache + +These commands should free up a lot of space for new image builds to come. diff --git a/docs/versioned_docs/version-4.13/guides/ci-cd-integration.mdx b/docs/versioned_docs/version-4.13/guides/ci-cd-integration.mdx new file mode 100644 index 0000000000..85ee881727 --- /dev/null +++ b/docs/versioned_docs/version-4.13/guides/ci-cd-integration.mdx @@ -0,0 +1,86 @@ +--- +title: CI/CD Integration +sidebar_label: CI/CD Integration +--- + +DevSpace is designed to work in non-interactive environments the same way it does in interactive environments. To use DevSpace inside a CI/CD pipeline, simply install it as part of your pipeline or start the pipeline with a VM or container image that already contains DevSpace and run any of the DevSpace commands. + +## Docker Image +DevSpace provides an official Docker image that [can be found on Docker Hub](https://hub.docker.com/r/devspacesh/devspace). The Dockerfile for this image is [available on GitHub](https://github.com/devspace-cloud/devspace/blob/master/Dockerfile). + +Use this image as shown here: +```bash +docker run devspacesh/devspace devspace [command] [args] +``` + +#### Example: Get Version +```bash +docker run devspacesh/devspace devspace --version +``` + +#### Example: Deployment +```bash +docker run -v ${PWD}:/project -w /project devspacesh/devspace devspace deploy +``` +1. Mounts current working directory into `/project` within the container +2. Sets `/project` as working dir +3. Runs `devspace deploy` inside working dir + +#### Example: Start Interactive Terminal Session +```bash +docker run -it -v ${PWD}:/project -w /project devspacesh/devspace +``` + +
+ + +## Deployment Tips + +### Avoid Pickers +If you want to run commands such as `devspace enter`, make sure you specify a label selector using `-l`, a container using `-c` etc. to make sure DevSpace can find the right pod/container without having to ask you to select one (which would lead to your pipeline getting stuck). + +### `--wait` Flag +DevSpace is configured to deploy and terminate when you run `devspace deploy`. In CI/CD pipelines, it is common to wait until the deployment is actually up and running before continuing the pipeline. You can achieve this by using `--wait`: +```bash +devspace deploy --wait --timeout=120 +``` +The above command will wait until the desired number of pods is created for all ReplicaSets and until none of the pods are failing anymore. If this is not achieved within the number of seconds specified in `--timeout`, DevSpace will exit with a fatal error. + +### Define Profiles +It is often useful to [define profiles in `devspace.yaml`](../configuration/profiles/basics.mdx) for staging, review or production deployments using CI/CD. You can deploy a project using such a profile using the `-p / --profile` flag: +```bash +devspace deploy -p production +``` + +### Separate Build & Deploy +DevSpace allows you to split up the build and deployment process into two separate commands: +```bash +devspace build # Build, tag and push images +devspace deploy --skip-build # Deploy project without rebuilding images +``` + +### Run Tests +To run unit or integration tests in your CI/CD pipeline, you have multiple options: +- [Split up build and deployment command](#separate-build--deploy) and run tests before after or in between the commands +- [Define hooks](../configuration/hooks/basics.mdx) that execute commands before/after certain image builds or deployments + +
+ + +## DevSpace Cloud + +### Authentication +If you want to use DevSpace Cloud in your CI/CD pipeline as well, you need to generate an ["Access Key"](https://app.devspace.cloud/settings/access-keys) and use it to login to DevSpace Cloud using the following non-interactive command: +```bash +devspace login --key=[YOUR_ACCESS_KEY] +``` + +### Encryption Key +If you are using the SaaS edition of DevSpace Cloud, you will need an encryption key to run commands such as `devspace create space` or `devspace use space`. To set an encryption key in a non-interactive environment, use: +```bash +devspace set encryptionkey [ENCRYPTION_KEY] --cluster=[cluster-name] +``` +The encryption key is a user-defined password that you defined when connecting your cluster to DevSpace Cloud. You can reset the encryption key for a cluster by running the following command and choosing the appropriate kube-context of the cluster: +```bash +devspace reset key +``` diff --git a/docs/versioned_docs/version-4.13/guides/community-projects.mdx b/docs/versioned_docs/version-4.13/guides/community-projects.mdx new file mode 100644 index 0000000000..0a9b622d25 --- /dev/null +++ b/docs/versioned_docs/version-4.13/guides/community-projects.mdx @@ -0,0 +1,24 @@ +--- +title: Community Projects +sidebar_label: Community Projects +--- + +:::note Submit Your Project +To submit a project: + +1. Make sure the project has a `LICENSE` file containing an **MIT** or **Apache 2.0** license. +2. Make sure to add a `README.md` file to your project describing what the project does and how to use it. +3. Click on the "**Edit this page**" button or follow **[this link](https://github.com/devspace-cloud/devspace/edit/master/docs/pages/guides/community-projects.mdx)**. +4. Add your project to the list **in alphabetical order**. +5. **Submit a pull request** containing your changes. + +❤️ Thank you! +::: + +The following projects are contributed and maintained by community members. + +|Project|Description|Maintainer| +|-|-|-| +|[nginx-auth-jwt](https://github.com/FactFiber/devspace-nginx-auth-jwt)|Auth requests through NGINX with JWT tokens|[shaunc](https://github.com/shaunc)| +|[nginx-s3](https://github.com/FactFiber/devspace-nginx-s3)|Serves static files from private S3 bucket using NGINX|[shaunc](https://github.com/shaunc)| +|[trilium](https://github.com/Addono/trilium-devspace)|Host a [trilium](https://github.com/zadam/trilium) server|[Addono](https://github.com/Addono)| diff --git a/docs/versioned_docs/version-4.13/guides/dev-staging-production.mdx b/docs/versioned_docs/version-4.13/guides/dev-staging-production.mdx new file mode 100644 index 0000000000..3eaeaac13f --- /dev/null +++ b/docs/versioned_docs/version-4.13/guides/dev-staging-production.mdx @@ -0,0 +1,21 @@ +--- +title: Dev vs Staging vs Production +sidebar_label: Dev vs Staging vs Prod +--- + +To configure the differences between development, staging and production environments, there are several techniques which may be used separately or combined in certain use cases: +- For image building: + 1. Using [different Dockerfiles](../configuration/images/dockerfile-context.mdx) for each environment + 2. Using the same Dockerfile and: + - [overriding the `ENTRYPOINT` or the `CMD` of the Dockerfile](../configuration/images/entrypoint-cmd.mdx) for each environment + - using multi-stage builds and [setting the `target`](../configuration/images/docker.mdx#target) during the build process + - using [different `buildArgs`](../configuration/images/docker.mdx#buildargs) for different environments +- For deployments: + 1. Using a different `cmd` and/or `args` for your containers depending on the environment + 2. Using a different `image` name or `image` tag for your containers depending on the environment + 3. Setting different `env` variables for your containers depending on the environment + +No matter which options are working for your use case, the following DevSpace features will allow you to set up the desired differences: +- [Config Profiles & Patches](../configuration/profiles/basics.mdx) +- [Config Variables](../configuration/variables/basics.mdx) +- [Hooks](../configuration/hooks/basics.mdx) diff --git a/docs/versioned_docs/version-4.13/guides/file-synchronization.mdx b/docs/versioned_docs/version-4.13/guides/file-synchronization.mdx new file mode 100644 index 0000000000..0875c1853c --- /dev/null +++ b/docs/versioned_docs/version-4.13/guides/file-synchronization.mdx @@ -0,0 +1,54 @@ +--- +title: File Synchronization +sidebar_label: File Synchronization +--- + +There are two types of file synchronzation processes: +- on-demand file sync using `devspace sync` and +- file synchronization during development mode using `devspace dev`. + + +## Start On-Demand File Sync +To establish an on-demand file synchronization between your local computer and the containers running inside Kubernetes, use the following command: +```bash +devspace sync # common flags: --local-path=./ --container-path=/app --no-watch --config=./devspace.yaml +``` +[Learn more about the `devspace sync` command.](https://devspace.cloud/blog/2019/10/18/release-devspace-v4.1.0-kubectl-cp-file-synchronization) + + +## Configure File Sync +If you want to start file synchronization every time you run `devspace dev`, you can configure it within `devspace.yaml`. + +[Learn more about configuring file synchronization using `devspace.yaml`.](../configuration/development/file-synchronization.mdx) + +
+ + +## Troubleshooting + +### Check `sync.log` +DevSpace logs all sync activity in `.devspace/logs/sync.log`. Check this file to get more detailed error information. + +### Verbose Sync +DevSpace provides the flag `--verbose-sync` to print additional information while running `devspace dev`: +```bash +devspace dev --verbose-sync +``` + +For an even cleaner output (sync-only logs, without container logs), deploy your application using `devspace dev` once, then abort the dev mode and start a standalone sync process using the `--verbose` flag: +```bash +devspace sync --config=devspace.yaml --verbose +``` + +### Ignore `.git/` +The sync can fail when files are constantly being changed while they are being synchronized. DevSpace will retry failing sync attempts but for folder such as `.git/` which contain continuously changing information and files which may be locked by the IDE, we recommmend to [ignore them via the `excludePaths` option](../configuration/development/file-synchronization.mdx#excludepaths) in `devspace.yaml`. + +### File Permissions +Without file write permission, the sync will not be able to work. If you start your containers (in production) using a different user than `root` and this user does not have sufficient permissions to read and write certain files, you can: +- exclude these files using the [`excludePaths` option](../configuration/development/file-synchronization.mdx#excludepaths) +- exclude these files using the [`uploadExcludePaths` option](../configuration/development/file-synchronization.mdx#uploadexcludepaths) +- run the containers using a different user during development\* + +\* You can achieve this by: +- Adding a `USER` statement in your Dockerfile: This is especially recommended when you are using multi-stage builds because you can add the `USER` statement for your development/build stage and add another `USER` statment to your production stage. Then, control the build target using the [`options.target` option](../configuration/images/docker.mdx#target) for Docker and kaniko builds and define a profile for removing the build stage for production deployments. +- Setting `runAsUser` and `runAsGroup` to `0` within the `securityContext` of your Kubernetes pods. diff --git a/docs/versioned_docs/version-4.13/guides/image-building.mdx b/docs/versioned_docs/version-4.13/guides/image-building.mdx new file mode 100644 index 0000000000..5ebad20b8f --- /dev/null +++ b/docs/versioned_docs/version-4.13/guides/image-building.mdx @@ -0,0 +1,56 @@ +--- +title: Image Building +sidebar_label: Image Building +--- + +Take a look at the following best practices to speed up image building and to set up DevSpace for an ideal workflow. + +## Optimize Dockerfiles +You can drastically speed up image building by optimizing your Dockerfiles with the following tips: +- Use a small base image (e.g. alpine version) +- Use layer caching for dependencies: Add dependency file, install dependencies, then add the rest of your source code as shown in the example snippet below + +```Dockerfile +FROM 8.16.1-alpine + +# Set working dir +WORKDIR /app + +# Copy dependency file to WORKDIR +ADD package.json + +# Install dependencies +RUN npm install + +# Copy remaining source code from local WORKDIR to image WORKDIR +COPY . . +``` + +## `.dockerignore` For Better Caching +DevSpace respects the `.dockerignore` file when defined on the root level of your context directory. This file follows a similar syntax as the `.gitignore` file but instead of excluding files from git, the `.dockerignore` file defines files and folders which should not be included in the context for building an image. + +:::info Skip Image Building +Adding paths to the `.dockerignore` file makes sure that DevSpace is not forced to rebuild images when files belonging to these paths change. +::: + +It can often be useful to: +- Add `devspace.yaml` to `.dockerignore` to prevent config changes from triggering image rebuilding (`devspace init` does this by default) +- Add temporary files (e.g. `.DS_Store`) to `.dockerignore` (DevSpace ALWAYS ignores `.devspace/` temp folder even if not specified in `.dockerignore`) +- Add dependency folders to `.dockerignore`, here are a few examples of dependency folders for different languages: + +### Recommended Paths for `.dockerignore` +| Language / Dependency Tool | `.dockerignore` statements | +| ------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | +| All Languages | `devspace.yaml` | +| PHP / composer | `composer.phar`
`vendor/` | +| Node.js / npm | `node_modules/`
`npm-debug.log*`
`report.[0-9]*.[0-9]*.[0-9]*.[0-9]*.json`
`pids`
`*.pid*`
`*.seed*`
`*.pid.lock*` | +| Python / pip | `__pycache__/`
`wheels/`
`pip-log.txt`
`pip-wheel-metadata/` | + + +## Different Images for Development vs. Staging vs. Production +Generally, there are several options to achieve this: +- using multiple Dockerfiles (e.g. `Dockerfile`, `Dockerfile_production`) +- using one Dockerfile in combination with `BUILD_ARGS` and `ENTRYPOINT` overrides for each environment +- using one Dockerfile in combination with multi-stage builds with targets for each environment + +All options have their benefits and caveats. Which one is the best for your project depends on your use case and your priorities. diff --git a/docs/versioned_docs/version-4.13/guides/interactive-mode.mdx b/docs/versioned_docs/version-4.13/guides/interactive-mode.mdx new file mode 100644 index 0000000000..1a06190c23 --- /dev/null +++ b/docs/versioned_docs/version-4.13/guides/interactive-mode.mdx @@ -0,0 +1,12 @@ +--- +title: Interactive Mode +sidebar_label: Interactive Mode +--- + +The development mode of DevSpace can be started using the `-i / --interactive` flag which overrides the `ENTRYPOINT` of an image with `[sleep, 999999]` and opens an interactive terminal session for one of the containers that use the 'sleeping' image. Due to the `ENTRYPOINT` override, the application has not been started within the container and the user can start the application manually through the interactive terminal session. + +## Start Interactive Mode +Start the interactive mode using this command: +```bash +devspace dev -i +``` diff --git a/docs/versioned_docs/version-4.13/guides/localhost-ui.mdx b/docs/versioned_docs/version-4.13/guides/localhost-ui.mdx new file mode 100644 index 0000000000..28178c8e78 --- /dev/null +++ b/docs/versioned_docs/version-4.13/guides/localhost-ui.mdx @@ -0,0 +1,131 @@ +--- +title: DevSpace Localhost UI +sidebar_label: DevSpace UI +--- + +DevSpace provides a powerful client-only UI for Kubernetes development. + +
+ DevSpace Localhost UI +
DevSpace Localhost UI - Overview
+
+ +## Open The UI +Running `devspace dev` will automatically start the UI in the background and then show a log output similar to this one: +```bash +######################################################### +[info] DevSpace UI available at: http://localhost:8090 +######################################################### +``` +By default, DevSpace starts the UI on port `8090` but it chooses a different port if the default port is already in use by another process. + +To access the UI started by `devspace dev`, just copy and paste the URL shown in the output of the command (see example above) into the address bar of your browser. + +Additionally, you can also start the UI using the following command: +```bash +devspace ui +``` + +:::info Use without Config +The advantage of `devspace ui` is that it does not require a `devspace.yaml` and can be run from anywhere no matter what your current working directory is. +::: + +:::note +If you run `devspace ui` while `devspace dev` is already running, the command will not start a second command and will rather open the existing UI started by the `devspace dev` command. +::: + +## Logs +The logs view is the central point for development. Here, you can find your pods and containers, stream logs, start interactive terminal sessions and more. + +### Inspecting Pods & Containers +The logs view allows you to: +- switch the kube-context and namespace +- list all containers (grouped by pods) in a namespace +- observe the status of all containers and detect issues +- view the YAML definition of each pod +- [stream the logs of a container](#stream-logs) +- [start interactive terminal sessions for a container](#start-terminals) + +
+ DevSpace Localhost UI +
DevSpace Localhost UI - Inspecting Pods & Containers
+
+ + +### Stream Logs +To stream the logs of a container, just click on the name of the container on the right-hand side of the logs view. + +
+ DevSpace Localhost UI +
DevSpace Localhost UI - Streaming Container Logs
+
+ +If you want to stream the logs of all containers that `devspace dev` has deployed using an image that is specified in the `devspace.yaml` of your current project, click on "All deployed containers (merged logs)". This feature is only available when you start the UI via `devspace dev` or by running `devspace ui` within a project that contains a `devspace.yaml`. + +**To close the log stream**, click on the trash icon on the right upper corner of the log stream window. + +**To maximize the log stream**, click on the maximize icon on the right upper corner of the log stream window. + +:::info Last 100 Lines +The log stream prints the last 100 log lines and then starts streaming the logs in real-time. +::: + +:::note Streaming in the background +Once you start the log stream for a container, DevSpace will keep the streaming connection open even if you switch to the logs of another container. This will allow you to quickly switch between log streams without having to wait until the connection has to be re-established. +::: + + +### Start Terminals +To start an interactive terminal session for running commands inside a container, just click on the `>_` icon next to the container's name. + +
+ DevSpace Localhost UI +
DevSpace Localhost UI - Starting Interactive Terminals
+
+ +The terminal session will stay open even if you click on a container name to stream the logs of this container. The `>_` icon will be highlighted using a blue color to indicate that the terminal session is still running. Click on the icon to resume the terminal session. + +**To close a terminal** using the kill command, click on the trash icon on the right upper corner of the terminal window. + +**To maximize a terminal**, click on the maximize icon on the right upper corner of the terminal window. + + +### Open / 1-Click Port-Forwarding +If you want to access an application running inside a container, you can click on the "Open" icon next to the container's name. After clicking on this icon, DevSpace will start a port-forwarding process between a randomly chosen local port and the application's port inside the container. After the port-forwarding connection is established, DevSpace will open the application on `localhost` using the randomly selected local port. + +:::info Service Required +This feature is only available for containers inside pods that are selected by the `labelSelector` of at least one service (i.e. the pod must be an endpoint of the service). +::: + +
+ DevSpace Localhost UI +
DevSpace Localhost UI - Open Applications in Containers (via 1-Click Port-Forwarding)
+
+ + +## Stack +If you open the stack view, DevSpace will show: +- the config that is currently loaded (in-memory, after applying [config patches defined in profiles](../configuration/profiles/basics.mdx) and after filling [config variables](../configuration/variables/basics.mdx)) +- the [config profile](../configuration/profiles/basics.mdx) that was used to load the config +- the [config variables](../configuration/variables/basics.mdx) available for this project + +
+ DevSpace Localhost UI +
DevSpace Localhost UI - Stack: Config, Profile, Variables
+
+ + +## Commands +DevSpace allows you to [define custom commands](../configuration/commands/basics.mdx) in your project's `devspace.yaml` which allows you to store and execute commonly used commands and share them with other developers. + +The localhost UI of DevSpace provides a view that shows all available commands defined in your project's `devspace.yaml`. You can view the commands definition and execute the command by clicking on the "Play" button. + +
+ DevSpace Localhost UI +
DevSpace Localhost UI - Open Containers (via 1-Click Port-Forwarding)
+
+ +Clicking the "Play" button for a command with name `my-command` is equivalent to running the following command in your terminal: +```bash +devspace run my-command +``` diff --git a/docs/versioned_docs/version-4.13/guides/networking-domains.mdx b/docs/versioned_docs/version-4.13/guides/networking-domains.mdx new file mode 100644 index 0000000000..c2388aa259 --- /dev/null +++ b/docs/versioned_docs/version-4.13/guides/networking-domains.mdx @@ -0,0 +1,48 @@ +--- +title: Services, Ingresses & Domains +sidebar_label: Networking & Domains +--- + +import FragmentInfoComponentChart from '../fragments/info-component-chart.mdx'; + +The easiest way to connect a domain to your deployment is to run the following command within your project directory: +```bash +devspace open +``` +Choose **via domain** to connect a domain or choose **via localhost** to use port-forwarding. + +
+ +## Component Chart +If you are looking for the documentation of the component chart values that let you configure the ingress and service for a component in `devspace.yaml`, please look into the **[Component Chart Documentation](https://devspace.sh/component-chart/docs/introduction)**. + + + +
+ +## Troubleshooting +Here are some steps to debug issues with your application when your domain is not able to reach your application. + +### Listen On All Interfaces +Make sure your application is running on `0.0.0.0` and not on `localhost`. If you see a log message in your container logs such as `Listening on localhost:PORT` or `Listening on 127.0.0.1:PORT`, you need to change the configuration of your application, so that it starts listening on `0.0.0.0` instead of `localhost`/`127.0.0.1`. + +:::info Only Localhost Works +This is often the problem when you are able to use `devspace open` with `via localhost` but not with the `via domain` option. +::: + +### Check For Failing Containers +Make sure none of your containers is constantly restarting (`Restarts` > 0) or unable to starting (`Status` != Running): +```bash +kubectl get po +``` + +### Check Services and Endpoints +Make sure you have at least one service for your main application configured: +```bash +kubectl get svc +``` + +And make sure all your services have at least one endpoint: +```bash +kubectl get ep +``` diff --git a/docs/versioned_docs/version-4.13/guides/remote-debugging.mdx b/docs/versioned_docs/version-4.13/guides/remote-debugging.mdx new file mode 100644 index 0000000000..d2be954168 --- /dev/null +++ b/docs/versioned_docs/version-4.13/guides/remote-debugging.mdx @@ -0,0 +1,13 @@ +--- +title: Remote Debugging +sidebar_label: Remote Debugging +--- + +DevSpace lets you easily [start applications in development mode](../getting-started/development.mdx) and connect remote debuggers for your application using the following steps: + +1. Configure DevSpace to use a development Dockerfile that: + - ships with the appropriate tools for debugging your application + - starts your application together with the debugger, e.g. setting the `ENTRYPOINT` of your Dockerfile to `node --inspect=0.0.0.0:9229 index.js` would start the Node.js remote debugger on port `9229` +2. Define port-forwarding for the port of your remote debugger (e.g. `9229`) within the `dev.ports` section of your `devspace.yaml` +3. Connect your IDE to the remote debugger (see the docs of your IDE for help) +4. Set breakpoints and debug your application directly inside Kubernetes diff --git a/docs/versioned_docs/version-4.13/introduction.md b/docs/versioned_docs/version-4.13/introduction.md new file mode 100644 index 0000000000..b474f724bd --- /dev/null +++ b/docs/versioned_docs/version-4.13/introduction.md @@ -0,0 +1,56 @@ +--- +title: What is DevSpace? +sidebar_label: Introduction +--- + +DevSpace is a client-only, open-source developer tool for Kubernetes: +- **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 + +## How does it work? +DevSpace runs as a single binary CLI tool directly on your computer and ideally, you use it straight from the terminal within your IDE. DevSpace does not require a server-side component as it communicates directly to your Kubernetes cluster using your kube-context, just like kubectl. + + + + +## Why DevSpace? +Building modern, distributed and highly scalable microservices with Kubernetes is hard - and it is even harder for large teams of developers. DevSpace is the next-generation tool for fast cloud-native software development. + + +### Declarative Workflows +DevSpace allows you to store all your workflows in one declarative config file: `devspace.yaml` +- **Codify workflow knowledge** about building images, deploying your project and its dependencies etc. +- **Version your workflows together with your code** (i.e. you can get any old version up and running with just a single command) +- **Share your workflows** with your team mates + + +### Made For Teams +DevSpace helps your team to standardize deployment and development workflows without requiring everyone on your team to become a Kubernetes expert. +- The DevOps and Kubernetes expert on your team can configure DevSpace using `devspace.yaml` and simply commits it via git +- If other developers on your team check out the project, they only need to run `devspace deploy` to deploy the project (including image building and deployment of other related project etc.) and they have a running instance of the project +- The configuration of DevSpace is highly dynamic, so you can configure everything using [config variables](configuration/variables/basics.mdx) that make it much easier to have one base configuration but still allow differences among developers (e.g. different sub-domains for testing) + + +### Hot Reloading +Instead of rebuilding images and redeploying containers, DevSpace allows you to **hot reload running containers while you are coding**: +- Simply edit your files with your IDE and see how your application reloads within the running container. +- The **high performance, bi-directional file synchronization** detects code changes immediately and synchronizes files immediately between your local dev environment and the containers running in Kubernetes +- Stream logs, connect debuggers or open a container terminal directly from your IDE with just a single command. + + +### Automation +Deploying and debugging services with Kubernetes requires a lot of knowledge and forces you to repeatedly run commands like `kubectl get pod` and copy pod ids back and forth. Stop wasting time and let DevSpace automate the tedious parts of working with Kubernetes: +- DevSpace lets you build multiple images in parallel, tag them automatically and deploy your entire application (including its dependencies) with just a single command +- Let DevSpace automatically start port-fowarding and log streaming, so you don't have to constantly copy and paste pod ids or run 10 commands to get everything started. + + +### Compatibility +DevSpace is battle tested with many Kubernetes distributions including: +- **Local Kubernetes clusters** like minikube, k3s, MikroK8s, kind +- **Managed Kubernetes clusters** in GKE (Google), EKS (AWS), AKS (Azure), DOKS (Digital Ocean) +- **Self-managed Kubernetes clusters** (e.g. created with Rancher) + +
+ diff --git a/docs/versioned_sidebars/version-4.13-sidebars.json b/docs/versioned_sidebars/version-4.13-sidebars.json new file mode 100644 index 0000000000..da4b0f6b6c --- /dev/null +++ b/docs/versioned_sidebars/version-4.13-sidebars.json @@ -0,0 +1,617 @@ +{ + "version-4.13/adminSidebar": [ + { + "type": "doc", + "id": "version-4.13/introduction" + }, + { + "type": "category", + "label": "Getting Started", + "items": [ + { + "type": "doc", + "id": "version-4.13/getting-started/installation" + }, + { + "type": "doc", + "id": "version-4.13/getting-started/initialize-project" + }, + { + "type": "doc", + "id": "version-4.13/getting-started/development" + }, + { + "type": "doc", + "id": "version-4.13/getting-started/deployment" + }, + { + "type": "doc", + "id": "version-4.13/getting-started/next-steps" + } + ] + }, + { + "type": "category", + "label": "Configuration", + "items": [ + { + "type": "doc", + "id": "version-4.13/configuration/reference" + }, + { + "type": "category", + "label": "images", + "items": [ + { + "type": "doc", + "id": "version-4.13/configuration/images/basics" + }, + { + "type": "doc", + "id": "version-4.13/configuration/images/image-tagging" + }, + { + "type": "doc", + "id": "version-4.13/configuration/images/dockerfile-context" + }, + { + "type": "doc", + "id": "version-4.13/configuration/images/entrypoint-cmd" + }, + { + "type": "doc", + "id": "version-4.13/configuration/images/append-dockerfile-instructions" + }, + { + "type": "doc", + "id": "version-4.13/configuration/images/inject-restart-helper" + }, + { + "type": "doc", + "id": "version-4.13/configuration/images/prefer-sync-over-rebuild" + }, + { + "type": "doc", + "id": "version-4.13/configuration/images/pull-secrets" + }, + { + "type": "category", + "label": "build", + "items": [ + { + "type": "doc", + "id": "version-4.13/configuration/images/docker" + }, + { + "type": "doc", + "id": "version-4.13/configuration/images/kaniko" + }, + { + "type": "doc", + "id": "version-4.13/configuration/images/custom" + }, + { + "type": "doc", + "id": "version-4.13/configuration/images/disabled" + } + ] + } + ] + }, + { + "type": "category", + "label": "deployments", + "items": [ + { + "type": "doc", + "id": "version-4.13/configuration/deployments/basics" + }, + { + "type": "doc", + "id": "version-4.13/configuration/deployments/helm-charts" + }, + { + "type": "doc", + "id": "version-4.13/configuration/deployments/kubernetes-manifests" + }, + { + "type": "doc", + "id": "version-4.13/configuration/deployments/kustomizations" + } + ] + }, + { + "type": "category", + "label": "dev", + "items": [ + { + "type": "doc", + "id": "version-4.13/configuration/development/basics" + }, + { + "type": "doc", + "id": "version-4.13/configuration/development/open-links" + }, + { + "type": "doc", + "id": "version-4.13/configuration/development/port-forwarding" + }, + { + "type": "doc", + "id": "version-4.13/configuration/development/reverse-port-forwarding" + }, + { + "type": "doc", + "id": "version-4.13/configuration/development/file-synchronization" + }, + { + "type": "doc", + "id": "version-4.13/configuration/development/auto-reloading" + }, + { + "type": "doc", + "id": "version-4.13/configuration/development/log-streaming" + }, + { + "type": "doc", + "id": "version-4.13/configuration/development/interactive-mode" + } + ] + }, + { + "type": "category", + "label": "dependencies", + "items": [ + { + "type": "doc", + "id": "version-4.13/configuration/dependencies/basics" + }, + { + "type": "doc", + "id": "version-4.13/configuration/dependencies/git-repository" + }, + { + "type": "doc", + "id": "version-4.13/configuration/dependencies/local-folder" + } + ] + }, + { + "type": "category", + "label": "vars", + "items": [ + { + "type": "doc", + "id": "version-4.13/configuration/variables/basics" + }, + { + "type": "doc", + "id": "version-4.13/configuration/variables/source-env" + }, + { + "type": "doc", + "id": "version-4.13/configuration/variables/source-input" + }, + { + "type": "doc", + "id": "version-4.13/configuration/variables/source-none" + } + ] + }, + { + "type": "category", + "label": "profiles", + "items": [ + { + "type": "doc", + "id": "version-4.13/configuration/profiles/basics" + }, + { + "type": "doc", + "id": "version-4.13/configuration/profiles/patches" + }, + { + "type": "doc", + "id": "version-4.13/configuration/profiles/replace" + } + ] + }, + { + "type": "doc", + "id": "version-4.13/configuration/commands/basics" + }, + { + "type": "doc", + "id": "version-4.13/configuration/hooks/basics" + }, + { + "type": "doc", + "id": "version-4.13/configuration/env-file" + } + ] + }, + { + "type": "category", + "label": "Guides & Best Practices", + "items": [ + { + "type": "doc", + "id": "version-4.13/guides/basics" + }, + { + "type": "doc", + "id": "version-4.13/guides/localhost-ui" + }, + { + "type": "doc", + "id": "version-4.13/guides/networking-domains" + }, + { + "type": "doc", + "id": "version-4.13/guides/file-synchronization" + }, + { + "type": "doc", + "id": "version-4.13/guides/interactive-mode" + }, + { + "type": "doc", + "id": "version-4.13/guides/ci-cd-integration" + }, + { + "type": "doc", + "id": "version-4.13/guides/dev-staging-production" + }, + { + "type": "doc", + "id": "version-4.13/guides/image-building" + }, + { + "type": "doc", + "id": "version-4.13/guides/remote-debugging" + }, + { + "type": "doc", + "id": "version-4.13/guides/community-projects" + } + ] + }, + { + "type": "category", + "label": "Tutorials", + "items": [ + { + "type": "link", + "label": "↗️ Ruby on Rails", + "href": "https://devspace.cloud/blog/2019/10/21/deploy-ruby-on-rails-to-kubernetes" + }, + { + "type": "link", + "label": "↗️ Python Django", + "href": "https://devspace.cloud/blog/2019/10/18/deploy-django-to-kubernetes" + }, + { + "type": "link", + "label": "↗️ PHP Laravel", + "href": "https://devspace.cloud/blog/2019/10/16/deploy-laravel-to-kubernetes" + }, + { + "type": "category", + "label": "↗️ Node / JavaScript", + "items": [ + { + "type": "link", + "label": "↗️ Express.js", + "href": "https://devspace.cloud/blog/2019/10/15/deploy-express.js-server-to-kubernetes" + }, + { + "type": "link", + "label": "↗️ React.js", + "href": "https://devspace.cloud/blog/2019/03/07/deploy-react-js-to-kubernetes" + }, + { + "type": "link", + "label": "↗️ Vue.js", + "href": "https://devspace.cloud/blog/2019/09/30/deploy-vue-js-to-kubernetes" + } + ] + } + ] + }, + { + "type": "category", + "label": "CLI Commands", + "items": [ + { + "type": "category", + "label": "devspace add", + "items": [ + { + "type": "doc", + "id": "version-4.13/commands/devspace_add_deployment" + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_add_image" + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_add_port" + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_add_provider" + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_add_sync" + } + ] + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_analyze" + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_attach" + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_build" + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_cleanup_images" + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_connect_cluster" + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_create_space" + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_deploy" + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_dev" + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_enter" + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_init" + }, + { + "type": "category", + "label": "devspace list", + "items": [ + { + "type": "doc", + "id": "version-4.13/commands/devspace_list_clusters" + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_list_commands" + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_list_contexts" + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_list_deployments" + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_list_namespaces" + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_list_ports" + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_list_profiles" + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_list_providers" + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_list_spaces" + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_list_sync" + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_list_vars" + } + ] + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_login" + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_logs" + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_open" + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_print" + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_purge" + }, + { + "type": "category", + "label": "devspace remove", + "items": [ + { + "type": "doc", + "id": "version-4.13/commands/devspace_remove_cluster" + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_remove_context" + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_remove_deployment" + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_remove_image" + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_remove_port" + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_remove_provider" + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_remove_space" + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_remove_sync" + } + ] + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_render" + }, + { + "type": "category", + "label": "devspace reset", + "items": [ + { + "type": "doc", + "id": "version-4.13/commands/devspace_reset_dependencies" + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_reset_key" + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_reset_vars" + } + ] + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_run" + }, + { + "type": "category", + "label": "devspace set", + "items": [ + { + "type": "doc", + "id": "version-4.13/commands/devspace_set_analytics" + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_set_encryptionkey" + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_set_var" + } + ] + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_status_sync" + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_sync" + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_ui" + }, + { + "type": "category", + "label": "devspace update", + "items": [ + { + "type": "doc", + "id": "version-4.13/commands/devspace_update_config" + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_update_dependencies" + } + ] + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_upgrade" + }, + { + "type": "category", + "label": "devspace use", + "items": [ + { + "type": "doc", + "id": "version-4.13/commands/devspace_use_context" + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_use_namespace" + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_use_profile" + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_use_provider" + }, + { + "type": "doc", + "id": "version-4.13/commands/devspace_use_space" + } + ] + } + ] + }, + { + "type": "link", + "label": "↗️ Component Chart", + "href": "https://devspace.sh/component-chart/docs/introduction" + }, + { + "type": "link", + "label": "↗️ loft", + "href": "https://loft.sh/docs/introduction" + }, + { + "type": "link", + "label": "↗️ DevSpace Cloud", + "href": "https://devspace.cloud/cloud/docs/introduction" + } + ] +} diff --git a/docs/versions.json b/docs/versions.json index 32f9157c31..559689ae68 100644 --- a/docs/versions.json +++ b/docs/versions.json @@ -1,4 +1,5 @@ [ + "4.13", "4.12", "4.11", "4.10",