mirror of
https://github.com/coder/coder.git
synced 2026-09-24 15:04:27 +08:00
Normalizes non-standard code-fence language tags across `docs/**` so a strict highlighter (Shiki, used by Fumadocs) won't fail the build on an unrecognized language, and unifies redundant synonym tags onto one canonical form per language. The current renderer (Speed-Highlight) detects the language from the code content, not the fence label, so this drift wasn't visible until now. ## Changes - `hcl` -> `tf` (199 fences, including indented ones nested in numbered/bulleted lists). Shiki ships `hcl` and `terraform` as two distinct grammars (not aliases); every `hcl`-tagged fence in `docs/**` is actually Terraform resource/data/provider syntax, so the more specific `terraform` grammar is correct for all of them. `tf` is Shiki's own alias for that grammar, and it's also what GitHub's own markdown renderer resolves to the same HCL/Terraform highlighting. - `pwsh`/`powershell` -> `ps1`. Both `ps` and `ps1` are registered PowerShell aliases in Shiki, but on GitHub's renderer only `.ps1` is a registered file extension (`.ps` isn't), so `ps1` renders identically to `powershell` there today while bare `ps` would silently lose highlighting. - `env` -> `dotenv` (a dedicated Shiki grammar for `KEY=VALUE` files) - `text`/`output`/`none`/`url` -> `txt`. Same built-in plain-text fallback either way, just shorter. - `Dockerfile` -> `dockerfile` (lowercase) - `bash`/`shell` -> `sh` (732 fences). Shiki and GitHub both alias all three to a single shell grammar; this was already the style guide's stated preference, just not enforced across the existing corpus until now. - `markdown` -> `md` (4 fences). Alias of the same grammar in both Shiki and GitHub. - `jsonc` -> `json` (1 fence). The block has no comments or trailing commas, so it doesn't need the comments-capable grammar. - `ts` -> `tsx` (2 fences, `docs/about/contributing/frontend.md`). Verified the actual content tokenizes identically under both grammars, and a sibling block in the same file already needs `tsx` for real JSX, so unifying to one tag is safe for this file. Documented a caveat: `tsx` mis-tokenizes the legacy angle-bracket type-assertion syntax (`<Type>value`), which is invalid in real `.tsx` files anyway, so use `value as Type` instead. - `yml` -> `yaml` (1 fence) - Updated `docs/.style/style-guide/formatting.md` to document all canonical tags `promql` (2 fences) and `caddyfile` (2 fences) are left as-is. Shiki doesn't bundle a grammar for either, so they need a custom grammar registration when the site adopts Shiki, rather than degrading to `txt`. Tracked as follow-up work under DOCS-118 and [DOCS-544](https://linear.app/codercom/issue/DOCS-544/vendor-a-local-promql-grammar-for-shiki-syntax-highlighting) (promql). Does not touch `offlinedocs/`. Linear: [DOCS-476](https://linear.app/codercom/issue/DOCS-476/normalize-docs-code-fence-languages-de-risk-shikifumadocs) <details> <summary>How the fence tags were verified</summary> Each tag was tested against a real `shiki@latest` highlighter instance (`codeToHtml`/`codeToTokens`) and cross-checked against GitHub's `@wooorm/starry-night` grammar sources (the renderer that actually displays these `.md` files today, in repo browsing and PR diffs), since that's what determines whether brevity is safe before Shiki adoption: ```text FAIL env -- Language `env` is not included in this bundle. FAIL Dockerfile -- Language `Dockerfile` is not included in this bundle. FAIL promql -- Language `promql` is not included in this bundle. FAIL caddyfile -- Language `caddyfile` is not included in this bundle. FAIL pwsh -- Language `pwsh` is not included in this bundle. FAIL output -- Language `output` is not included in this bundle. ``` `hcl` doesn't error in Shiki, since it's a real grammar, but that's exactly the trap: it was silently rendering every fence with the generic HCL grammar instead of the Terraform-specific one. Every `hcl`-tagged fence in `docs/**` was manually checked against `origin/main` and is genuinely Terraform content. For `ts`/`tsx`, tokenizing the actual doc content confirmed identical output under both grammars; a synthetic test with the legacy angle-bracket cast syntax confirmed `tsx` degrades on that specific construct, which the style guide now calls out. The first normalization pass only matched fence tags at column 0 (`^```tag$`), missing tags indented inside numbered/bulleted lists. A follow-up pass caught the remaining occurrences at any indentation level. </details> --- *This PR description and the underlying changes were prepared with Coder Agents assistance.*
237 lines
6.2 KiB
Markdown
237 lines
6.2 KiB
Markdown
# Additional clusters
|
|
|
|
With Coder, you can deploy workspaces in additional Kubernetes clusters using
|
|
different
|
|
[authentication methods](https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs#authentication)
|
|
in the Terraform provider.
|
|
|
|

|
|
|
|
## Option 1) Kubernetes contexts and kubeconfig
|
|
|
|
First, create a kubeconfig file with
|
|
[multiple contexts](https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/).
|
|
|
|
```sh
|
|
kubectl config get-contexts
|
|
|
|
CURRENT NAME CLUSTER
|
|
workspaces-europe-west2-c workspaces-europe-west2-c
|
|
* workspaces-us-central1-a workspaces-us-central1-a
|
|
```
|
|
|
|
### Kubernetes control plane
|
|
|
|
If you deployed Coder on Kubernetes, you can attach a kubeconfig as a secret.
|
|
|
|
This assumes Coder is deployed on the `coder` namespace and your kubeconfig file
|
|
is in ~/.kube/config.
|
|
|
|
```sh
|
|
kubectl create secret generic kubeconfig-secret -n coder --from-file=~/.kube/config
|
|
```
|
|
|
|
Modify your helm values to mount the secret:
|
|
|
|
```yaml
|
|
coder:
|
|
# ...
|
|
volumes:
|
|
- name: "kubeconfig-mount"
|
|
secret:
|
|
secretName: "kubeconfig-secret"
|
|
volumeMounts:
|
|
- name: "kubeconfig-mount"
|
|
mountPath: "/mnt/secrets/kube"
|
|
readOnly: true
|
|
```
|
|
|
|
[Upgrade Coder](../../install/kubernetes.md#upgrading-coder-via-helm) with these
|
|
new values.
|
|
|
|
### VM control plane
|
|
|
|
If you deployed Coder on a VM, copy the kubeconfig file to
|
|
`/home/coder/.kube/config`.
|
|
|
|
### Create a Coder template
|
|
|
|
You can start from our
|
|
[example template](../../../examples/templates/kubernetes).
|
|
From there, add
|
|
[template parameters](../templates/extending-templates/parameters.md) to allow
|
|
developers to pick their desired cluster.
|
|
|
|
```tf
|
|
# main.tf
|
|
|
|
data "coder_parameter" "kube_context" {
|
|
name = "kube_context"
|
|
display_name = "Cluster"
|
|
default = "workspaces-us-central1-a"
|
|
mutable = false
|
|
option {
|
|
name = "US Central"
|
|
icon = "/emojis/1f33d.png"
|
|
value = "workspaces-us-central1-a"
|
|
}
|
|
option {
|
|
name = "Europe West"
|
|
icon = "/emojis/1f482.png"
|
|
value = "workspaces-europe-west2-c"
|
|
}
|
|
}
|
|
|
|
provider "kubernetes" {
|
|
config_path = "~/.kube/config" # or /mnt/secrets/kube/config for Kubernetes
|
|
config_context = data.coder_parameter.kube_context.value
|
|
}
|
|
```
|
|
|
|
## Option 2) Kubernetes ServiceAccounts
|
|
|
|
Alternatively, you can authenticate with remote clusters with ServiceAccount
|
|
tokens. Coder can store these secrets on your behalf with
|
|
[managed Terraform variables](../templates/extending-templates/variables.md).
|
|
|
|
Alternatively, these could also be fetched from Kubernetes secrets or even [HashiCorp Vault](https://registry.terraform.io/providers/hashicorp/vault/latest/docs/data-sources/generic_secret).
|
|
|
|
This guide assumes you have a `coder-workspaces` namespace on your remote
|
|
cluster. Change the namespace accordingly.
|
|
|
|
### Create a ServiceAccount
|
|
|
|
Run this command against your remote cluster to create a ServiceAccount, Role,
|
|
RoleBinding, and token:
|
|
|
|
```sh
|
|
kubectl apply -n coder-workspaces -f - <<EOF
|
|
apiVersion: v1
|
|
kind: ServiceAccount
|
|
metadata:
|
|
name: coder-v2
|
|
---
|
|
apiVersion: v1
|
|
kind: Secret
|
|
metadata:
|
|
name: coder-v2
|
|
annotations:
|
|
kubernetes.io/service-account.name: coder-v2
|
|
type: kubernetes.io/service-account-token
|
|
---
|
|
apiVersion: rbac.authorization.k8s.io/v1
|
|
kind: Role
|
|
metadata:
|
|
name: coder-v2
|
|
rules:
|
|
- apiGroups: ["", "apps", "networking.k8s.io"]
|
|
resources: ["persistentvolumeclaims", "pods", "deployments", "services", "secrets", "pods/exec","pods/log", "events", "networkpolicies", "serviceaccounts"]
|
|
verbs: ["create", "get", "list", "watch", "update", "patch", "delete", "deletecollection"]
|
|
- apiGroups: ["metrics.k8s.io", "storage.k8s.io"]
|
|
resources: ["pods", "storageclasses"]
|
|
verbs: ["get", "list", "watch"]
|
|
---
|
|
apiVersion: rbac.authorization.k8s.io/v1
|
|
kind: RoleBinding
|
|
metadata:
|
|
name: coder-v2
|
|
subjects:
|
|
- kind: ServiceAccount
|
|
name: coder-v2
|
|
roleRef:
|
|
kind: Role
|
|
name: coder-v2
|
|
apiGroup: rbac.authorization.k8s.io
|
|
EOF
|
|
```
|
|
|
|
The output should be similar to:
|
|
|
|
```txt
|
|
serviceaccount/coder-v2 created
|
|
secret/coder-v2 created
|
|
role.rbac.authorization.k8s.io/coder-v2 created
|
|
rolebinding.rbac.authorization.k8s.io/coder-v2 created
|
|
```
|
|
|
|
### 2. Modify the Kubernetes template
|
|
|
|
You can start from our
|
|
[example template](../../../examples/templates/kubernetes).
|
|
|
|
```tf
|
|
variable "host" {
|
|
description = "Cluster host address"
|
|
sensitive = true
|
|
}
|
|
|
|
variable "cluster_ca_certificate" {
|
|
description = "Cluster CA certificate (base64 encoded)"
|
|
sensitive = true
|
|
}
|
|
|
|
variable "token" {
|
|
description = "Cluster CA token (base64 encoded)"
|
|
sensitive = true
|
|
}
|
|
|
|
variable "namespace" {
|
|
description = "Namespace"
|
|
}
|
|
|
|
provider "kubernetes" {
|
|
host = var.host
|
|
cluster_ca_certificate = base64decode(var.cluster_ca_certificate)
|
|
token = base64decode(var.token)
|
|
}
|
|
```
|
|
|
|
### Create Coder template with managed variables
|
|
|
|
Fetch the values from the secret and pass them to Coder. This should work on
|
|
macOS and Linux.
|
|
|
|
To get the cluster address:
|
|
|
|
```sh
|
|
kubectl cluster-info
|
|
Kubernetes control plane is running at https://example.domain:6443
|
|
|
|
export CLUSTER_ADDRESS=https://example.domain:6443
|
|
```
|
|
|
|
To fetch the CA certificate and token:
|
|
|
|
```sh
|
|
export CLUSTER_CA_CERTIFICATE=$(kubectl get secrets coder-v2 -n coder-workspaces -o jsonpath="{.data.ca\.crt}")
|
|
|
|
export CLUSTER_SERVICEACCOUNT_TOKEN=$(kubectl get secrets coder-v2 -n coder-workspaces -o jsonpath="{.data.token}")
|
|
```
|
|
|
|
Create the template with these values:
|
|
|
|
```sh
|
|
coder templates push \
|
|
--variable host=$CLUSTER_ADDRESS \
|
|
--variable cluster_ca_certificate=$CLUSTER_CA_CERTIFICATE \
|
|
--variable token=$CLUSTER_SERVICEACCOUNT_TOKEN \
|
|
--variable namespace=coder-workspaces
|
|
```
|
|
|
|
If you're on a Windows machine (or if one of the commands fail), try grabbing
|
|
the values manually:
|
|
|
|
```sh
|
|
# Get cluster API address
|
|
kubectl cluster-info
|
|
|
|
# Get cluster CA and token (base64 encoded)
|
|
kubectl get secrets coder-service-account-token -n coder-workspaces -o jsonpath="{.data}"
|
|
|
|
coder templates push \
|
|
--variable host=API_ADDRESS \
|
|
--variable cluster_ca_certificate=CLUSTER_CA_CERTIFICATE \
|
|
--variable token=CLUSTER_SERVICEACCOUNT_TOKEN \
|
|
--variable namespace=coder-workspaces
|
|
```
|