|
| 1 | +--- |
| 2 | +title: Workspace Provider Deployment |
| 3 | +description: Learn how to deploy a workspace provider. |
| 4 | +state: beta |
| 5 | +--- |
| 6 | + |
| 7 | +This article walks you through the process of deploying a workspace provider to |
| 8 | +a [Kubernetes cluster](../../setup/kubernetes/index.md). |
| 9 | + |
| 10 | +[Workspace Providers](index.md) are logical groups of resources to which |
| 11 | +developers can deploy environments. As with the Coder installation, Helm manages |
| 12 | +the deployment of workspace providers into the Kubernetes cluster that will contain |
| 13 | +your environments. |
| 14 | + |
| 15 | +## Dependencies |
| 16 | + |
| 17 | +Install the following dependencies if you haven't already: |
| 18 | + |
| 19 | +- [Coder CLI](../../cli/installation.md) |
| 20 | +- [Helm](https://helm.sh/docs/intro/install/) |
| 21 | +- [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) |
| 22 | + |
| 23 | +## Requirements |
| 24 | + |
| 25 | +1. Workspace providers **must have a hostname set** that is a subdomain of the |
| 26 | + Coder deployment. For example, if the Coder deployment's hostname is |
| 27 | + `coder.example.com`, the workspace provider's hostname must match the format |
| 28 | + `*.coder.example.com`. |
| 29 | +1. The main Coder deployment and the workspace provider must be able to |
| 30 | + communicate bi-directionally via their respective hostnames. |
| 31 | +1. The workspace provider scheme (HTTP or HTTPS) must match that of the Coder |
| 32 | + deployment Access URL. |
| 33 | +1. The Kubernetes cluster address must be reachable from the Coder deployment. |
| 34 | + |
| 35 | +## Connecting to the Cluster |
| 36 | + |
| 37 | +To add a Kubernetes cluster as a workspace provider, you must first make sure |
| 38 | +that you're connected to the cluster you want to expand into. Run the following |
| 39 | +command: |
| 40 | + |
| 41 | +```bash |
| 42 | +kubectl config current-context |
| 43 | +``` |
| 44 | + |
| 45 | +Confirm that your current kubectl context correct before continuing; otherwise, |
| 46 | +connect to the correct context. |
| 47 | + |
| 48 | +## Creating the Coder Namespace (Optional) |
| 49 | + |
| 50 | +We recommend running workspace providers in a separate |
| 51 | +[namespace](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/); |
| 52 | +to do so, run: |
| 53 | + |
| 54 | +```bash |
| 55 | +kubectl create namespace coder |
| 56 | +``` |
| 57 | + |
| 58 | +Next, change the kubectl context to point to your newly created namespace: |
| 59 | + |
| 60 | +```bash |
| 61 | +kubectl config set-context --current --namespace=coder |
| 62 | +``` |
| 63 | + |
| 64 | +## Creating the New Workspace Provider |
| 65 | + |
| 66 | +Using the Coder CLI, create a new workspace provider in the `pending` state. |
| 67 | + |
| 68 | +```bash |
| 69 | +coder providers create [NAME] \ |
| 70 | + --hostname=[HOSTNAME] \ |
| 71 | + --cluster-address=[CLUSTER_ADDRESS] |
| 72 | +``` |
| 73 | + |
| 74 | +You must provide the following arguments: |
| 75 | + |
| 76 | +- `name`: A unique name of the workspace provider |
| 77 | +- `hostname`: The hostname of the workspace provider |
| 78 | +- `cluster-address`: The address of your Kubernetes cluster. You can retrieve this |
| 79 | + using: |
| 80 | + |
| 81 | + ```bash |
| 82 | + kubectl config view -o jsonpath='{.clusters[?(@.name == "'"$(kubectl config current-context)"'")].cluster.server}{"\n"}' |
| 83 | + ``` |
| 84 | + |
| 85 | +The `coder providers create` command will generate a Helm command you will use |
| 86 | +for the next steps, so make sure to save the output. |
| 87 | + |
| 88 | +The returned `REMOTE_ENVPROXY_TOKEN` is a shared secret between the two |
| 89 | +deployments and is what the workspace provider will use to authenticate itself |
| 90 | +when communicating with the Coder deployment. |
| 91 | + |
| 92 | +## Installing a Workspace Provider |
| 93 | + |
| 94 | +1. If you haven't already, add the Coder helm repo: |
| 95 | + |
| 96 | + ```bash |
| 97 | + helm repo add coder https://helm.coder.com |
| 98 | + ``` |
| 99 | + |
| 100 | +1. Install the helm chart onto your cluster using helm command you generated in |
| 101 | + the previous step where you created the workspace provider. The helm command |
| 102 | + will follow this pattern: |
| 103 | + |
| 104 | + ```bash |
| 105 | + helm upgrade coder-workspace-provider coder/workspace-provider \ |
| 106 | + --version=[CODER_VERSION] \ |
| 107 | + --atomic \ |
| 108 | + --install \ |
| 109 | + --set envproxy.token=[REMOTE_ENVPROXY_TOKEN] \ |
| 110 | + --set envproxy.accessURL=[HOSTNAME] \ |
| 111 | + --set ingress.host=[HOSTNAME_WITH_NO_PROTOCOL] \ |
| 112 | + --set envproxy.clusterAddress=[CLUSTER_ADDRESS] \ |
| 113 | + --set cemanager.accessURL=[CEMANAGER_ACCESS_URL] |
| 114 | + ``` |
| 115 | + |
| 116 | + Optionally, you can provide additional helm configuration values by providing |
| 117 | + a `values.yaml` file and adding the argument `-f my-values.yaml` to the |
| 118 | + generated command. Helm values control attributes of the workspace provider, |
| 119 | + including DevURLs, Kubernetes storage classes, SSH, and more. See the |
| 120 | + [Workspace Provider Helm Chart |
| 121 | + Values]("https://github.com/cdr/enterprise-helm/blob/workspace-providers-envproxy-only/README.md") |
| 122 | + for more details. |
| 123 | + |
| 124 | + For installations using HTTPS, you must [ensure the deployment has a valid certificate](../../guides/ssl-certificates/index.md). |
| 125 | + |
| 126 | + If you're unfamiliar with the helm configuration values file, see our doc on |
| 127 | + [updating a helm chart](../../guides/helm-charts.md) |
| 128 | + |
| 129 | +1. Once the helm chart is successfully deployed, fetch the ingress address: |
| 130 | + |
| 131 | + ```bash |
| 132 | + kubectl get ingress web-ingress |
| 133 | + ``` |
| 134 | + |
| 135 | + Use this IP to create a DNS record for the provided hostname of the workspace |
| 136 | + provider. |
| 137 | + |
| 138 | +1. Once the Helm chart has deployed successfully, you should see the workspace |
| 139 | + provider in a `ready` state on the Workspace Provider Admin page. |
| 140 | + |
| 141 | +  |
| 142 | + |
| 143 | +1. From the Workspace Provider Admin page, add the desired organizations to its |
| 144 | + allowlist. |
| 145 | + |
| 146 | +Users in the allowed organizations can now choose to deploy into the newly set |
| 147 | +up workspace provider. |
| 148 | + |
| 149 | +## Upgrading the Workspace Provider |
| 150 | + |
| 151 | +We strongly recommend that you upgrade your workspace providers in lockstep with |
| 152 | +your Coder deployment. |
| 153 | + |
| 154 | +You only need to update the `--version` flag if you want to make no other helm |
| 155 | +values changes; you can do this with |
| 156 | + |
| 157 | +```bash |
| 158 | +helm upgrade coder-workspace-provider coder/workspace-provider \ |
| 159 | + --version=[CODER_VERSION] \ |
| 160 | + --atomic \ |
| 161 | + --install \ |
| 162 | + --force |
| 163 | +``` |
| 164 | + |
| 165 | +If you want to update any of the helm chart's values, you can do so by supplying |
| 166 | +a values file (`-f myvalues.yaml`) or using with the `--set` flag. Any existing |
| 167 | +values that were set during installation will persist unless you explicitly |
| 168 | +write over them. |
| 169 | + |
| 170 | +## Deleting a Workspace Provider |
| 171 | + |
| 172 | +You can only remove a workspace provider if it no longer contains any |
| 173 | +environments, so you must remove all environments before deleting the workspace |
| 174 | +provider. |
| 175 | + |
| 176 | +To remove a workspace provider, run the following command using the Coder CLI: |
| 177 | + |
| 178 | +```bash |
| 179 | +coder providers rm [NAME] |
| 180 | +``` |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?v=4&size=40){kind=avatar}
0 commit comments