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: examples/kaniko/README.md
+33-3Lines changed: 33 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,21 +4,20 @@ This example shows how kaniko can be used instead of docker to build and push an
4
4
5
5
# Step 0: Prerequisites
6
6
7
-
In order for this example to work you need access to a docker registry, where you can push images to (e.g. hub.docker.com, gcr.io etc.). There are two options how you can push images to registries with devspace.
7
+
In order for this example to work you need access to a docker registry, where you can push images to (e.g. hub.docker.com, gcr.io etc.). There are three options how you can push images to registries with devspace.
8
8
9
9
## Option 1: Use docker credentials store
10
10
If you have docker installed, devspace can take the required auth information directly out of the docker credentials store and will create the needed secret for you in the target cluster automatically. Make sure you are logged in the registry with `docker login`.
11
11
12
12
## Option 2: Provide auth information yourself
13
-
As a second option you can provide your credentials directly in the config.yaml. See example below:
13
+
As a second option you can provide your credentials directly in the config.yaml and devspace cli will create a pull secret for you automatically. See example below:
14
14
15
15
```yaml
16
16
images:
17
17
default:
18
18
build:
19
19
kaniko:
20
20
cache: true
21
-
namespace: ""
22
21
# Don't prefix image name with registry url
23
22
name: name/devspace
24
23
registry: myRegistry
@@ -33,6 +32,37 @@ registries:
33
32
34
33
devspace will then automatically create a secret for you which kaniko can use to push to that registry.
35
34
35
+
## Option 3: Provide kaniko pull secret yourself
36
+
As a third option you can provide the pullSecret to use for kaniko yourself. Make sure the pull secret has the following form:
37
+
38
+
```yaml
39
+
apiVersion: v1
40
+
kind: Secret
41
+
data:
42
+
# .dockerconfigjson encoded in base64 e.g.:
43
+
# {
44
+
# "auths": {
45
+
# "myRegistryUrl": {
46
+
# "auth": "base64Encoded(user:password/token)",
47
+
# "email": "myemail@test.de"
48
+
# }
49
+
# }
50
+
# }
51
+
.dockerconfigjson: BASE64EncodedDockerConfigJson
52
+
```
53
+
54
+
Now specify the pullsecret name as the pull secret to use for kaniko in the .devspace/config:
55
+
56
+
```yaml
57
+
images:
58
+
default:
59
+
build:
60
+
kaniko:
61
+
cache: true
62
+
name: registryName/name/devspace
63
+
pullSecret: myPullSecretName
64
+
```
65
+
36
66
## Optional: Use self hosted cluster (minikube, GKE etc.) instead of devspace-cloud
37
67
38
68
If you want to use your own cluster instead of the devspace-cloud as deployment target, make sure `kubectl` is configured correctly to access the target cluster. Then just erase the `cluster` section in the `.devspace/config.yaml` and devspace will use your current kubectl context as deployment target.
0 commit comments