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
Copy file name to clipboardExpand all lines: docs/docs/configuration/config.yaml.md
+41-41Lines changed: 41 additions & 41 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -110,26 +110,26 @@ Defines how the DevSpace is deployed to your cluster. See [Type: Release](#type-
110
110
111
111
### devspace.portForwarding
112
112
To access applications running inside a DevSpace, the DevSpace CLI allows to configure port forwardings. A port forwarding consists of the following:
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_
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
116
117
117
### devspace.portForwarding[*].portMappings[*]
118
118
PortMapping:
119
-
- `localPort`_string_ on localhost
120
-
- `remotePort`_string_ remote pod port
119
+
- `localPort`*string* on localhost
120
+
- `remotePort`*string* remote pod port
121
121
122
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.
123
123
124
124
### devspace.sync
125
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:
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
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
133
133
134
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.
135
135
@@ -138,74 +138,74 @@ This section of the config defines a map of images that can be used in the helm
138
138
139
139
### images[*]
140
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
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
145
146
146
### images[*].build
147
147
BuildConfig:
148
-
- `engine`_Engine_ The engine that should be used for building the image
148
+
- `engine`*Engine* The engine that should be used for building the image
149
149
150
150
### images[*].build.engine
151
151
Engine:
152
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
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
155
156
156
### images[*].build.engine.docker
157
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
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
160
161
161
### images[*].build.engine.kaniko
162
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
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
165
165
166
166
## registries
167
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)
168
168
169
169
### registries[*]
170
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
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
174
175
175
### registries[*].user
176
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
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
179
179
180
180
## services
181
181
Defines cluster services that the DevSpace uses.
182
182
183
183
### services.internalRegistry
184
184
The `internalRegistry` is used to tell the DevSpace CLI to deploy a private registry inside the Kubernetes cluster:
185
-
- `release` _Release_ for deploying the registry (see [Type: Release](#type-release))
185
+
- `release` *Release* for deploying the registry (see [Type: Release](#type-release))
186
186
187
187
### services.tiller
188
188
The `tiller` service is defined by:
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
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
191
191
192
192
## cluster
193
193
The `cluster` field specifies:
194
-
- `useKubeConfig`_bool_ if true use the credentials defined in $HOME/.kube/config
194
+
- `useKubeConfig`*bool* if true use the credentials defined in $HOME/.kube/config
195
195
196
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_
197
+
- `apiServer`*string* (Kubernetes API-Server URL)
198
+
- `caCert`*string* (CaCert for the Kubernetes API-Server in PEM format)
199
+
- `user`*ClusterUser*
200
200
201
201
### cluster.user
202
202
ClusterUser:
203
-
- `username`_string_
204
-
- `clientCert`_string_ (PEM format)
205
-
- `clientKey`_string_ (PEM format)
203
+
- `username`*string*
204
+
- `clientCert`*string* (PEM format)
205
+
- `clientKey`*string* (PEM format)
206
206
207
207
## Type: Release
208
208
A `release` is specified through:
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)
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