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
Deis Workflow's builder component relies on registry for storing the application docker images.
3
+
Deis Workflow's builder component relies on a registry for storing application docker images.
4
4
5
5
Deis Workflow ships with a [registry][registry] component by default, which provides an in-cluster Docker registry backed by the platform-configured [object storage][storage]. Operators might want to use an off-cluster registry for performance or security reasons.
6
6
7
7
## Configuring Off-Cluster Private Registry
8
8
9
-
Every component that relies on registry uses two inputs for configuration:
9
+
Every component that relies on a registry uses two inputs for configuration:
10
10
11
11
1. Registry Location environment variable named `DEIS_REGISTRY_LOCATION`
12
12
2. Access credentials stored as a Kubernetes secret named `registry-secret`
13
13
14
-
The Helm chart for Deis Workflow can be easily configured to connect Workflow components to off-cluster registry. Deis Workflow supports external registries which provide either short-lived tokens which are valid only for a specified amount of time or long-lived tokens (basic username/password) which are valid forever for authenticating to them. For those registries which provide short lived tokens for authentication, Deis Workflow will generate and refresh them such that the deployed apps will only have access to the short-lived tokens and not to the actual credentials for the registries.
14
+
The Helm chart for Deis Workflow can be easily configured to connect Workflow components to off-cluster registry. Deis Workflow supports external registries which provide either short-lived tokens that are valid only for a specified amount of time or long-lived tokens (basic username/password) which are valid forever for authenticating to them. For those registries which provide short lived tokens for authentication, Deis Workflow will generate and refresh them such that the deployed apps will only have access to the short-lived tokens and not to the actual credentials for the registries.
15
+
16
+
When using a private registry the docker images are no longer pulled by Deis Workflow Controller but rather are managed by [Kubernetes][]. This will increase security and overall speed, however the `port` information can no longer be discovered. Instead the `port` information can be set via `deis config:set PORT=<port>` prior to deploying the application.
17
+
18
+
Deis Workflow currently supports:
15
19
16
-
When using a private registry the docker images are no longer pulled by Deis Workflow Controller but rather is managed by Kubernetes. This will increase security and overall speed, however the `port` information can no longer be discovered. Instead the `port` information can be set via `deis config:set PORT=<port>` prior to deploying the application.
17
-
Deis Workflow currently supports
18
20
1. Google Container Registry([gcr][gcr]).
19
-
2. EC2 Container Registry([ecr][ecr]).
20
-
3. off-cluster: Any provider which supports long-lived username/password authentication, such as [Azure Container Registry][acr], [Docker Hub][dockerhub], [quay.io][quay], or a self-hosted Docker registry.
21
+
1. EC2 Container Registry([ecr][ecr]).
22
+
1. off-cluster: Any provider which supports long-lived username/password authentication, such as [Azure Container Registry][acr], [Docker Hub][dockerhub], [quay.io][quay], or a self-hosted Docker registry.
23
+
24
+
## Configuration
21
25
22
-
***Step 1:** If you haven't already fetched the values file, do so with `helm inspect values deis/workflow | sed -n '1!p' > values.yaml`
23
-
***Step 2:** Update registry location details by modifying the values file.
26
+
1. If you haven't already fetched the values file, do so with `helm inspect values deis/workflow | sed -n '1!p' > values.yaml`
27
+
1. Update registry location details by modifying the values file:
24
28
* Update the `registry_location` parameter to reference the registry location you are using: `off-cluster`, `ecr`, `gcr`
25
29
* Update the values in the section which corresponds to your registry location type.
26
-
* Note: you do not need to base64 encode any of these values as Helm will handle encoding automatically
27
30
28
31
You are now ready to `helm install deis/workflow --namespace deis -f values.yaml` using your desired registry.
29
32
33
+
## Examples
34
+
Here we show how the relevant parts of the fetched `values.yaml` file might look like after configuring for a particular off-cluster registry:
35
+
36
+
### ECR
37
+
38
+
```
39
+
global:
40
+
...
41
+
registry_location: "ecr"
42
+
...
43
+
registry-token-refresher:
44
+
# Time in minutes after which the token should be refreshed.
45
+
# Leave it empty to use the default provider time.
46
+
token_refresh_time: ""
47
+
...
48
+
ecr:
49
+
# Your AWS access key. Leave it empty if you want to use IAM credentials.
50
+
accesskey: "ACCESS_KEY"
51
+
# Your AWS secret key. Leave it empty if you want to use IAM credentials.
52
+
secretkey: "SECRET_KEY"
53
+
# Any S3 region
54
+
region: "us-west-2"
55
+
registryid: ""
56
+
hostname: ""
57
+
...
58
+
```
59
+
**Note:**`registryid` and `hostname` should _not_ be set. See [this issue](https://github.com/deis/registry-token-refresher/issues/11) for more info.
60
+
61
+
### GCR
62
+
63
+
```
64
+
global:
65
+
...
66
+
registry_location: "gcr"
67
+
...
68
+
registry-token-refresher:
69
+
# Time in minutes after which the token should be refreshed.
70
+
# Leave it empty to use the default provider time.
0 commit comments