You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is an example of a [.devspace/config.yaml](#)
6
6
```yaml
7
+
# Devspace version, currently is always v1
7
8
version: v1
8
9
devSpace:
9
10
release:
11
+
# Name of helm release that is used for deploying
12
+
# the devspace chart (contents of /chart)
10
13
name: my-project
14
+
# Release namespace
11
15
namespace: my-namespace
16
+
# Automatically forwarded ports on `devspace up` (same functionality as running manually kubectl port-forward)
12
17
portForwarding:
18
+
# Currently only pod is supported
13
19
- resourceType: pod
20
+
# Map of key value matchLabel selectors
14
21
labelSelector:
15
22
release: my-app
23
+
# Array of port mappings
16
24
portMappings:
25
+
# The local machine port
17
26
- localPort: 3000
27
+
# The selected pod port
18
28
remotePort: 3000
19
29
- localPort: 8080
20
30
remotePort: 80
21
31
sync:
32
+
# Currently only resource type pod is supported
22
33
- resourceType: pod
23
34
labelSelector:
24
35
release: my-app
36
+
# Sync the complete local project path
25
37
localSubPath: ./
38
+
# Into the remote container path /app
26
39
containerPath: /app
40
+
# Exclude node_modules from up and download
41
+
excludePaths:
42
+
- node_modules/
43
+
# A list of images that should be build during devspace up
27
44
images:
28
45
default:
46
+
# Image name
29
47
name: devspace-user/devspace
48
+
# Image tag (auto-generated)
30
49
tag: 9u5ye0G
50
+
# Registry where the build image will be pushed to
31
51
registry: default
32
52
build:
33
53
engine:
34
54
docker:
55
+
# Use docker for image building
35
56
enabled: true
57
+
# Use the minikube docker daemon, if the current kubectl context is minikube
36
58
preferMinikube: true
37
59
database:
38
60
name: devspace-user/devspace
@@ -41,101 +63,149 @@ images:
41
63
build:
42
64
engine:
43
65
kaniko:
66
+
# Use kaniko within the target cluster to build the image
67
+
# instead of local or minikube docker
44
68
enabled: true
69
+
# The registries the images should be pushed to
45
70
registries:
46
71
default:
47
72
url: hub.docker.com
73
+
# Internal registry that will be automatically deployed to the target
74
+
# cluster if desired
48
75
internal:
76
+
# Auto-generated user and password
49
77
user:
50
78
username: user-XXXXX
51
79
password: XXXXXXXXXX
80
+
# Services that are used within the target cluster
52
81
services:
82
+
# The deployed internal registry within the cluster
53
83
internalRegistry:
54
84
release:
85
+
# The helm release name of the internal registry
55
86
name: devspace-registry
56
87
namespace: my-namespace
88
+
# Tiller server that should be used within the cluster
57
89
tiller:
90
+
# A list of namespaces where tiller is allowed to deploy namespaces to
58
91
appNamespaces:
59
92
- my-namespace
60
93
release:
94
+
# Namespace where the tiller server is located
61
95
namespace: my-namespace
96
+
# Target cluster configuration
62
97
cluster:
98
+
# Use the local kubectl client config
63
99
useKubeConfig: true
64
100
```
65
101
A [.devspace/config.yaml](#) contains any public/shared configuration for running a DevSpace for the respective project. It is highly recommended to put this file under version control (e.g. git add).
66
102
67
103
**Note: You can easily re-configure your DevSpace by running `devspace init -r`.**
68
104
69
105
## devspace
70
-
Defines your DevSpace including everything related to portForwarding, sync, and the release config.
106
+
Defines the DevSpace including everything related to portForwarding, sync, and the helm release config.
71
107
72
108
### devspace.release
73
109
Defines how the DevSpace is deployed to your cluster. See [Type: Release](#type-release) for details.
74
110
75
111
### devspace.portForwarding
76
112
To access applications running inside a DevSpace, the DevSpace CLI allows to configure port forwardings. A port forwarding consists of the following:
77
-
- `resourceType`(currently only `pod` is supported)
78
-
- `labelSelector`(usually the release/app name)
79
-
- a list of `portMappings` (each specifying a `localPort` on localhost and a `remotePort` within the DevSpace)
113
+
- `resourceType`_string_ kubernetes resource type that is selected (currently only `pod` is supported)
114
+
- `labelSelector`_map[string]string_ usually the release/app name
115
+
- `portMappings`_PortMapping array_
116
+
117
+
### devspace.portForwarding[*].portMappings[*]
118
+
PortMapping:
119
+
- `localPort`_string_ on localhost
120
+
- `remotePort`_string_ remote pod port
80
121
81
122
In the example above, you could open `localhost:8080` inside your browser to see the output of the application listening on port 80 within your DevSpace.
82
123
83
124
### devspace.sync
84
125
To comfortably sync code to a DevSpace, the DevSpace CLI allows to configure real-time code synchronizations. A sync config consists of the following:
85
-
- `resourceType`(currently only `pod` is supported)
86
-
- `labelSelector`(usually the release/app name)
87
-
- `localSubPath`(relative to your local project root)
88
-
- `containerPath`(absolute path within your DevSpace)
89
-
- `excludePaths`(for excluding files/folders from sync in .gitignore syntax)
90
-
- `DownloadExcludePaths`(for excluding files/folders from download in .gitignore syntax)
91
-
- `UploadExcludePaths`(for excluding files/folders from upload in .gitignore syntax)
126
+
- `resourceType`_string_ kubernetes resource type that is selected (currently only `pod` is supported)
127
+
- `labelSelector`_map[string]string_ usually the release/app name
128
+
- `localSubPath` _string_ relative path to the folder that should be synced (default: path to your local project root)
129
+
- `containerPath`_string_ absolute path within the container
130
+
- `excludePaths`_string array_ paths to exclude files/folders from sync in .gitignore syntax
131
+
- `downloadExcludePaths`_string array_ paths to exclude files/folders from download in .gitignore syntax
132
+
- `uploadExcludePaths`_string array_ paths to exclude files/folders from upload in .gitignore syntax
92
133
93
-
In the example above, the entire code within the project would be synchronized with the folder `/app` inside the DevSpace.
134
+
In the example above, the entire code within the project would be synchronized with the folder `/app` inside the DevSpace, with the exception of the `node_modules/` folder.
94
135
95
136
## images
96
-
This section of the config defines a map of images that can be used in the helm chart that is deployed during `devspace up`. An image is defined by:
97
-
- `name`of the image that is being pushed to the registry
98
-
- `tag`stating the latest tag pushed to the registry
99
-
- `registry`referencing one of the keys defined in the `registries` map
100
-
- `build`defining the build procedure for this image
101
-
102
-
## images[*].build
103
-
An image build is mainly defined by the build engine. There are 2 build engines currently supported:
104
-
- `docker`uses the local Docker daemon or a Docker daemon running inside a Minikube cluster (if `preferMinikube` == true)
105
-
- `kaniko`builds images in userspace within a build pod running inside the Kubernetes cluster
137
+
This section of the config defines a map of images that can be used in the helm chart that is deployed during `devspace up`.
138
+
139
+
### images[*]
140
+
An image is defined by:
141
+
- `name`_string_ of the image that is being pushed to the registry
142
+
- `tag`_string_ stating the latest tag pushed to the registry (auto-generated)
143
+
- `registry`_string_ referencing one of the keys defined in the `registries` map
144
+
- `build`_BuildConfig_ defines the build procedure for this image
145
+
146
+
### images[*].build
147
+
BuildConfig:
148
+
- `engine`_Engine_ The engine that should be used for building the image
149
+
150
+
### images[*].build.engine
151
+
Engine:
152
+
An image build is mainly defined by the build engine. There are 2 build engines currently supported (choose only one):
153
+
- `docker`_DockerConfig_ uses the local Docker daemon or a Docker daemon running inside a Minikube cluster (if `preferMinikube` == true)
154
+
- `kaniko`_KanikoConfig_ builds images in userspace within a build pod running inside the Kubernetes cluster
155
+
156
+
### images[*].build.engine.docker
157
+
DockerConfig:
158
+
- `enabled`_bool_ if true the local docker daemon is used for image building
159
+
- `preferMinikube`_bool_ if true and the current kubectl context is minikube, the minikube docker daemon is used for image building
160
+
161
+
### images[*].build.engine.kaniko
162
+
KanikoConfig:
163
+
- `enabled`_bool_ if true a kaniko build pod is used for image building
164
+
- `namespace`_string_ specifies the namespace where the build pod should be started
106
165
107
166
## registries
108
167
This section of the config defines a map of image registries. You can use any external registry or link to the [services.internalRegistry](#services-internal-registry)
109
-
- `url` of the registry (format: myregistry.com:port)
110
-
- `user`credentials (`username`, `password`) for pushing to / pulling from the registry
111
-
- `insecure`flag to allow pushing to registries without HTTPS
168
+
169
+
### registries[*]
170
+
ImageRegistry:
171
+
- `url` _string_ of the registry (format: myregistry.com:port)
172
+
- `insecure`_bool_ flag to allow pushing to registries without HTTPS
173
+
- `user`_RegistryUser_ credentials for pushing to / pulling from the registry
174
+
175
+
### registries[*].user
176
+
RegistryUser:
177
+
- `username`_string_ that should be used for pushing and pulling from the registry
178
+
- `password`_string_ that should be used for pushing and pulling from the registry
112
179
113
180
## services
114
-
Defines additional services for your DevSpace.
181
+
Defines cluster services that the DevSpace uses.
115
182
116
183
### services.internalRegistry
117
184
The `internalRegistry` is used to tell the DevSpace CLI to deploy a private registry inside the Kubernetes cluster:
118
-
- `release` for deploying the registry (see [Type: Release](#type-release))
185
+
- `release` _Release_ for deploying the registry (see [Type: Release](#type-release))
119
186
120
187
### services.tiller
121
188
The `tiller` service is defined by:
122
-
- `release` definition for tiller (see [Type: Release](#type-release))
123
-
- `appNamespaces`defining a list of namespace that tiller may deploy applications to
189
+
- `release` _Release_ definition for tiller (see [Type: Release](#type-release))
190
+
- `appNamespaces`_string array_ defines a list of namespace that tiller may deploy applications to
124
191
125
192
## cluster
126
193
The `cluster` field specifies:
127
-
- `useKubeConfig`(yes to use the credentials defined in $HOME/.kube/config)
194
+
- `useKubeConfig`_bool_ if true use the credentials defined in $HOME/.kube/config
195
+
196
+
If `useKubeConfig` is `false`, the following fields need to be specified:
197
+
- `apiServer`_string_ (Kubernetes API-Server URL)
198
+
- `caCert`_string_ (CaCert for the Kubernetes API-Server in PEM format)
199
+
- `user`_ClusterUser_
128
200
129
-
If `useKubeConfig: false` is used, the following fields need to be specified:
130
-
- `apiServer`(Kubernetes API-Server URL)
131
-
- `caCert`(CaCert for the Kubernetes API-Server in PEM format)
132
-
- `user` specifying the following:
133
-
- `username`
134
-
- `clientCert`(PEM format)
135
-
- `clientKey`(PEM format)
201
+
### cluster.user
202
+
ClusterUser:
203
+
- `username`_string_
204
+
- `clientCert`_string_ (PEM format)
205
+
- `clientKey`_string_ (PEM format)
136
206
137
207
## Type: Release
138
208
A `release` is specified through:
139
-
- `name`of the release
140
-
- `namespace`to deploy the release to
141
-
- `values`that are set during the deployment (contents of the values.yaml in helm)
209
+
- `name`_string_ of the release
210
+
- `namespace`_string_ to deploy the release to
211
+
- `values`_map[string] any_ that are set during the deployment (contents of the values.yaml in helm)
0 commit comments