mirror of https://github.com/cirruslabs/tart.git
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:
parent
5c1f5a61c1
commit
64a3999a58
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Reference in New Issue