mirror of https://github.com/coder/coder.git synced 2026-06-03 13:08:25 +00:00

Files

T

Ben Potter 76ad116e12 docs: write 2.0.2 changelog (#9025 )

* mention provisioner authentication

* add changelog for 2.1.0

* rename to 2.0.2

2023-08-10 17:02:02 +00:00

3.9 KiB

Raw Blame History

Provisioners

By default, the Coder server runs built-in provisioner daemons, which execute terraform during workspace and template builds. However, there are sometimes benefits to running external provisioner daemons:

Secure build environments: Run build jobs in isolated containers, preventing malicious templates from gaining shell access to the Coder host.
Isolate APIs: Deploy provisioners in isolated environments (on-prem, AWS, Azure) instead of exposing APIs (Docker, Kubernetes, VMware) to the Coder server. See Provider Authentication for more details.
Isolate secrets: Keep Coder unaware of cloud secrets, manage/rotate secrets on provisoner servers.
Reduce server load: External provisioners reduce load and build queue times from the Coder server. See Scaling Coder for more details.

External provisioners are in an alpha state and the behavior is subject to change. Use GitHub issues to leave feedback.

Running external provisioners

Each provisioner can run a single concurrent workspace build. For example, running 30 provisioner containers will allow 30 users to start workspaces at the same time.

Provisioners are started with the coder provisionerd start command.

Authentication

The provisioner server must authenticate with your Coder deployment. There are two authentication methods:

PSK: Set a provisioner daemon PSK on the Coder server and start the provisioner with coder provisionerd start --psk <your-psk>
User token: Authenticate the Coder CLI as a user with the Template Admin or Owner role.

Types of provisioners

Generic provisioners can pick up any build job from templates without provisioner tags.
```
coder provisionerd start
```

Tagged provisioners can be used to pick up build jobs from templates (and corresponding workspaces) with matching tags.

coder provisionerd start \
  --tag environment=on_prem \
  --tag data_center=chicago

# In another terminal, create/push
# a template that requires this provisioner
coder templates create on-prem \
  --provisioner-tag environment=on_prem

# Or, match the provisioner exactly
coder templates create on-prem-chicago \
  --provisioner-tag environment=on_prem \
  --provisioner-tag data_center=chicago

At this time, tagged provisioners can also pick jobs from untagged templates. This behavior is subject to change.

User provisioners can only pick up jobs from user-tagged templates. Unlike the other provisioner types, any Coder can run user provisioners, but they have no impact unless there is at least one template with the scope=user provisioner tag.
```
coder provisionerd start \
  --tag scope=user

# In another terminal, create/push
# a template that requires user provisioners
coder templates create on-prem \
  --provisioner-tag scope=user
```

Example: Running an external provisioner on a VM

curl -L https://coder.com/install.sh | sh
export CODER_URL=https://coder.example.com
export CODER_SESSION_TOKEN=your_token
coder provisionerd start

Example: Running an external provisioner via Docker

docker run --rm -it \
  -e CODER_URL=https://coder.example.com/ \
  -e CODER_SESSION_TOKEN=your_token \
  --entrypoint /opt/coder \
  ghcr.io/coder/coder:latest \
  provisionerd start

Disable built-in provisioners

As mentioned above, the Coder server will run built-in provisioners by default. This can be disabled with a server-wide flag or environment variable.

coder server --provisioner-daemons=0

3.9 KiB Raw Blame History