mirror of
https://github.com/coder/coder.git
synced 2026-11-03 05:55:24 +08:00
Nick Vigilante
c84aa564ba
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.*
136 lines
4.8 KiB
Markdown
136 lines
4.8 KiB
Markdown
# Microsoft Azure
|
||
|
||
This guide shows you how to set up the Coder server on Azure which will
|
||
provision Azure-hosted Linux workspaces.
|
||
|
||
## Requirements
|
||
|
||
This guide assumes you have full administrator privileges on Azure.
|
||
|
||
## Create An Azure VM
|
||
|
||
From the Azure Portal, navigate to the Virtual Machines Dashboard. Click Create,
|
||
and select creating a new Azure Virtual machine .
|
||
|
||
<img src="../../images/platforms/azure/azure1.jpg" alt="Azure VM creation page">
|
||
|
||
This will bring you to the `Create a virtual machine` page. Select the
|
||
subscription group of your choice, or create one if necessary.
|
||
|
||
Next, name the VM something relevant to this project using the naming convention
|
||
of your choice. Change the region to something more appropriate for your current
|
||
location. For this tutorial, we will use the base selection of the Ubuntu Gen2
|
||
Image and keep the rest of the base settings for this image the same.
|
||
|
||
<img src="../../images/platforms/azure/azure2.png" alt="Azure VM instance details">
|
||
|
||
<img src="../../images/platforms/azure/azure3.png" alt="Azure VM size selection">
|
||
|
||
Up next, under `Inbound port rules` modify the Select `inbound ports` to also
|
||
take in `HTTPS` and `HTTP`.
|
||
|
||
<img src="../../images/platforms/azure/azure4.png" alt="Azure VM inbound port rules">
|
||
|
||
The set up for the image is complete at this stage. Click `Review and Create` -
|
||
review the information and click `Create`. A popup will appear asking you to
|
||
download the key pair for the server. Click
|
||
`Download private key and create resource` and place it into a folder of your
|
||
choice on your local system.
|
||
|
||
<img src="../../images/platforms/azure/azure5.png" alt="Azure VM key pair generation">
|
||
|
||
Click `Return to create a virtual machine`. Your VM will start up!
|
||
|
||
<img src="../../images/platforms/azure/azure6.png" alt="Azure VM deployment complete">
|
||
|
||
Click `Go to resource` in the virtual machine and copy the public IP address.
|
||
You will need it to SSH into the virtual machine via your local machine.
|
||
|
||
Follow
|
||
[these instructions](https://learn.microsoft.com/en-us/azure/virtual-machines/linux-vm-connect?tabs=Linux)
|
||
to SSH into the virtual machine. Once on the VM, you can run and install Coder
|
||
using your method of choice. For the fastest install, we recommend running Coder
|
||
as a system service.
|
||
|
||
## Install Coder
|
||
|
||
For this instance, we will run Coder as a system service, however you can run
|
||
Coder a multitude of different ways. You can learn more about those
|
||
[here](https://coder.com/docs/install).
|
||
|
||
In the Azure VM instance, run the following command to install Coder
|
||
|
||
```sh
|
||
curl -fsSL https://coder.com/install.sh | sh
|
||
```
|
||
|
||
## Run Coder
|
||
|
||
Run the following command to start Coder as a system level service:
|
||
|
||
```sh
|
||
sudo systemctl enable --now coder
|
||
```
|
||
|
||
The following command will get you information about the Coder launch service
|
||
|
||
```sh
|
||
journalctl -u coder.service -b
|
||
```
|
||
|
||
This will return a series of logs related to running Coder as a system service.
|
||
Embedded in the logs is the Coder Access URL.
|
||
|
||
Copy the URL and run the following command to create the first user, either on
|
||
your local machine or in the instance terminal.
|
||
|
||
```sh
|
||
coder login <url***.try.coder.app>
|
||
```
|
||
|
||
Fill out the prompts. Be sure to save use email and password as these are your
|
||
admin username and password.
|
||
|
||
You can now access Coder on your local machine with the relevant
|
||
`***.try.coder.app` URL and logging in with the username and password.
|
||
|
||
## Creating and Uploading Your First Template
|
||
|
||
First, run `coder template init` to create your first template. You’ll be given
|
||
a list of possible templates to use. This tutorial will show you how to set up
|
||
your Coder instance to create a Linux based machine on Azure.
|
||
|
||
<img src="../../images/platforms/azure/azure9.png" alt="Coder CLI template init">
|
||
|
||
Press `enter` to select `Develop in Linux on Azure` template. This will return
|
||
the following:
|
||
|
||
<img src="../../images/platforms/azure/azure10.png" alt="Coder CLI template init">
|
||
|
||
To get started using the Azure template, install the Azure CLI by following the
|
||
instructions
|
||
[here](https://learn.microsoft.com/en-us/cli/azure/install-azure-cli-linux?pivots=apt).
|
||
Run `az login` and follow the instructions to configure the Azure command line.
|
||
|
||
Coder is running as a system service, which creates the system user `coder` for
|
||
handling processes. The Coder user will require access to the Azure credentials
|
||
to initialize the template.
|
||
|
||
Run the following commands to copy the Azure credentials and give the `coder`
|
||
user access to them:
|
||
|
||
```sh
|
||
sudo cp -r ~/.azure /home/coder/.azure
|
||
sudo chown -R coder:coder /home/coder/.azure/
|
||
```
|
||
|
||
Navigate to the `./azure-linux` folder where you created your template and run
|
||
the following command to put the template on your Coder instance.
|
||
|
||
```sh
|
||
coder templates push
|
||
```
|
||
|
||
Congrats! You can now navigate to your Coder dashboard and use this Linux on
|
||
Azure template to create a new workspace!
|