Improve Orchard docs (#1064)

* Iterate over Orchard Architecture description

* Document Orchard Controller customization (e.g. --listen-ssh)

* New section: "Using Orchard CLI"

* Fix Markdown unordered list indentation

* Fix "fenced code blocks should have a language specified"

* the context → a context

* Clarify different port

* Simplify labels explanation

* Studios → Studio

* Better explain resources

* crate → create

* only to place → only place

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

* Surround "Using resources when creating VMs" header by blank lines

---------

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
This commit is contained in:
Nikolay Edigaryev 2025-04-29 16:10:14 +02:00 committed by GitHub
parent 5c1f5a61c1
commit 64a3999a58
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
4 changed files with 125 additions and 4 deletions

View File

@ -1,12 +1,14 @@
## Architecture
Orchard cluster consists of two components:
Orchard cluster consists of three components:
* Controller — responsible for managing the cluster and scheduling of resources
* Controller — responsible for managing the cluster and scheduling of resources
* Worker — responsible for executing the VMs
* Client — responsible for creating, modifying and removing the resources on the Controller, can either be an Orchard CLI or [an API consumer](/orchard/integration-guide)
* Client — responsible for creating, modifying and removing the resources on the Controller, can either be an [Orchard CLI](/orchard/using-orchard-cli) or [an API consumer](/orchard/integration-guide)
Normally you deploy a single Controller that needs to be accessible to both the Clients and Workers. Then you can deploy the Workers, which can reside anywhere and be inaccessible to Clients directly, e.g. behind a NAT.
At the moment, only one Controller instance is currently supported, while you can deploy one or more Workers and run any number of Clients.
In terms of networking requirements, only Controller needs to be directly accessible from Workers and Clients, while Workers and Clients can be deployed and run anywhere (e.g. behind a NAT).
## Security

View File

@ -14,6 +14,47 @@ For example to use a secure, random value:
ORCHARD_BOOTSTRAP_ADMIN_TOKEN=$(openssl rand -hex 32) orchard controller run
```
## Customization
Note that all the [Deployment Methods](#deployment-methods) essentially boil down to starting an `orchard controller run` command and keeping it alive.
This means that by introducing additional command-line arguments, you can customize the Orchard Controller's behavior. Below, we list some of the common scenarios.
### Customizing listening port
* `--listen` — address to listen on (default `:6120`)
### Customizing TLS
* `--controller-cert` — use the controller certificate from the specified path instead of the auto-generated one (requires --controller-key)
* `--controller-key` — use the controller certificate key from the specified path instead of the auto-generated one (requires --controller-cert)
* `--insecure-no-tls` — disable TLS, making all connections to the controller unencrypted
* useful when deploying Orchard Controller behind a load balancer/ingress controller
### Built-in SSH server
Orchard Controller can act as a simple SSH server that port-forwards connections to the VMs running in the Orchard Cluster.
This way you can completely skip the Orchard API when connecting to a given VM and only use the SSH client:
```shell
ssh -J <service account name>@orchard-controller.example.com <VM name>
```
To enable this functionality, pass `--listen-ssh` command-line argument to the `orchard controller run` command, for example:
```ssh
orchard controller run --listen-ssh 6122
```
Here's other command-line arguments associated with this functionality:
* `--ssh-host-key` — use the SSH private host key from the specified path instead of the auto-generated one
* `--insecure-ssh-no-client-auth` — allow SSH clients to connect to the controller's SSH server without authentication, thus only authenticating on the target worker/VM's SSH server
* useful when you already have strong credentials on your VMs, and you want to share these VMs to others without additionally giving out Orchard Cluster credentials
Check out our [Jumping through the hoops: SSH jump host functionality in Orchard](/blog/2024/06/20/jumping-through-the-hoops-ssh-jump-host-functionality-in-orchard/) blog post for more information.
## Deployment Methods
While you can always start `orchard controller run` manually with the required arguments, this method is not recommended due to lack of persistence.

View File

@ -0,0 +1,77 @@
## Installation
The easiest way to install Orchard CLI is through the [Homebrew](https://brew.sh/):
```shell
brew install cirruslabs/cli/orchard
```
Binaries and packages for other architectures can be found in [GitHub Releases](https://github.com/cirruslabs/orchard/releases).
## Setting up a context
The first step after installing the Orchard CLI is to configure its context. Configuring context is like pairing with the specified Orchard Controller, so that the commands like `orchard create vm`, `orchard ssh vm` will work.
To configure a context, `orchard context` has a subfamily of commands:
* `orchard context create <CONTROLLER ADDRESS>` — creates a new context to communicate with Orchard Controller available on the specified address
* `orchard context default <CONTROLLER ADDRESS>` — sets a context with a given Orchard Controller address as default (in case there's more than one context configured)
* `orchard context list` — lists all the configured contexts, indicating the default one
* `orchard context delete <CONTROLLER ADDRESS>` — deletes a context for the specified Orchard Controller address
Most of the time, you'll only need the `orchard context create`. For example, if you've deployed your Orchard Controller to `orchard-controller.example.com`, a new context can be configured like so:
```shell
orchard context create orchard-controller.example.com
```
`orchard context create` assumes port 6120 by default, so if you use a different port for the Orchard Controller, simply specify the port explicitly:
```shell
orchard context create orchard-controller.example.com:8080
```
When creating a new context you will be prompted for the service account name and token, which can be obtained from:
* `orchard controller run` logs
* if this is a first start
* `orchard get service-account`
* from an already configured Orchard CLI
## Using labels when creating VMs
Labels are useful if you want to restrict scheduling of a VM to workers whose labels include a subset of the VM's specified labels.
For example, you might have an Orchard Cluster consisting of the following workers:
* Mac Minis (`orchard worker run --labels location=DC1-R12-S4,model=macmini`)
* Mac Studios (`orchard worker run --labels location=DC1-R18-S8,model=macstudio`)
To create and run a VM specifically on Mac Studio machines, pass the `--labels` command-line argument to `orchard create vm` when creating a VM:
```shell
orchard create vm --labels model=macstudio <NAME>
```
When processing this VM, the scheduler will only place it on available Mac Studio workers.
## Using resources when creating VMs
Resources are useful if you want to restrict scheduling of a VM to workers that still have enough of the specified resource to fit the VM's requirements.
The difference between the labels is that the resources are finite and are automatically accounted by the scheduler.
To illustrate this with an example, let's say you have an Orchard Cluster consisting of the following workers:
* Mac Mini with 1 Gbps bandwidth (`orchard worker run --resources bandwidth-mbps=1000`)
* Mac Studio with 10 Gbps bandwidth (`orchard worker run --resources bandwidth-mbps=10000`)
VM created using the command below will only be scheduled on a Mac Studio with 10 Gbps bandwidth:
```shell
orchard create vm --resources bandwidth-mbps=7500 <NAME>
```
However, after this VM is scheduled, the 10 Gbps Mac Studio will only be able to accommodate one more VM (due to internal Apple EULA limit for macOS virtualization) with `bandwidth-mbps=2500` or less.
After the VM finishes, the unused resources will be available again.

View File

@ -102,6 +102,7 @@ nav:
- "Architecture and Security": orchard/architecture-and-security.md
- "Deploying Controller": orchard/deploying-controller.md
- "Deploying Workers": orchard/deploying-workers.md
- "Using Orchard CLI": orchard/using-orchard-cli.md
- "Managing the Cluster": orchard/managing-cluster.md
- "Integrating with the API": orchard/integration-guide.md
- "FAQ": faq.md