mirror of https://github.com/cirruslabs/tart.git
Document automatic resources set by the Orchard Worker (#1134)
* Fix MkDocs warnings w.r.t. absolute instead of relative links * Document automatic resources set by the Orchard Worker * .markdownlint.yml: ignore MD051
This commit is contained in:
parent
a655edd826
commit
84147f29b5
|
|
@ -11,3 +11,4 @@
|
|||
"MD045": false # OK not to have a description for an image
|
||||
"MD046": false # Code block style [Expected: fenced; Actual: indented]
|
||||
"MD059": false # It's OK to have "here" links
|
||||
"MD051": false # MkDocs generates "#-no-pki" anchors, but markdownlint expects "#--no-pki" anchors
|
||||
|
|
|
|||
|
|
@ -60,9 +60,9 @@ device without a physical display connected. For example, a Mac Mini with a HDMI
|
|||
but a Mac Mini on a desk with a connected physical display is considered a personal computer. **Usage on personal computers
|
||||
and before reaching the 100 CPU cores limit is royalty-free and does not have the viral properties of AGPL.**
|
||||
|
||||
When an organization surpasses the 100 CPU cores limit, they will be required to obtain a [Gold Tier License](/licensing#license-tiers),
|
||||
which costs \$1000 per month. Upon reaching a limit of 500 CPU cores, a [Platinum Tier License](/licensing#license-tiers)
|
||||
(\$3000 per month) will be required, and for organizations that exceed 3000 CPU cores, a custom [Diamond Tier License](/licensing#license-tiers)
|
||||
When an organization surpasses the 100 CPU cores limit, they will be required to obtain a [Gold Tier License](../../licensing.md#license-tiers),
|
||||
which costs \$1000 per month. Upon reaching a limit of 500 CPU cores, a [Platinum Tier License](../../licensing.md#license-tiers)
|
||||
(\$3000 per month) will be required, and for organizations that exceed 3000 CPU cores, a custom [Diamond Tier License](../../licensing.md#license-tiers)
|
||||
(\$1 per core per month) will be necessary. **All paid license tiers will include priority feature development and SLAs on support with urgent issues.**
|
||||
|
||||
## Have we considered alternatives?
|
||||
|
|
|
|||
|
|
@ -89,6 +89,6 @@ orchard dev
|
|||
This will launch a development cluster with a single worker on your machine. Refer to [Orchard documentation](https://github.com/cirruslabs/orchard#creating-virtual-machines)
|
||||
on how to create your first virtual machine and access it.
|
||||
|
||||
In a [separate blog post](/blog/2023/04/28/ssh-over-grpc-or-how-orchard-simplifies-accessing-vms-in-private-networks/)
|
||||
In a [separate blog post](2023-04-28-orchard-ssh-over-grpc.md)
|
||||
we’ll cover how Orchard implements seamless SSH access over a gRPC connection. Stay tuned and please don’t hesitate to
|
||||
[reach out](https://github.com/cirruslabs/orchard/discussions/landing)!
|
||||
|
|
|
|||
|
|
@ -64,7 +64,7 @@ We’ve also initially considered using [Yamux](https://github.com/hashicorp/yam
|
|||
|
||||
First of all, we’ve made the new port-forwarding functionality available for integrations via the Orchard’s REST API:
|
||||
|
||||

|
||||

|
||||
|
||||
All you need is to use a WebSocket client when accessing this endpoint to make it work.
|
||||
|
||||
|
|
|
|||
|
|
@ -43,7 +43,7 @@ allocate time to continue improving Tart which brings us to the section below.
|
|||
In the last 7 months we've had 12 feature releases that brought a lot of features requested by the community. Here are just
|
||||
a few of them to highlight:
|
||||
|
||||
-[Custom GitLab Runner Executor](/integrations/gitlab-runner/).
|
||||
-[Custom GitLab Runner Executor](../../integrations/gitlab-runner.md).
|
||||
-[Cluster Management via Orchard](2023-04-25-orchard-ga.md).
|
||||
-Numerous compatibility improvements for all kinds of OCI-registries.
|
||||
-Sonoma Support (see details [below](#macos-sonoma-updates)).
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ with preconfigured Tart installation that is optimized to work within AWS infras
|
|||
EC2 Mac Instances is a gem of engineering powered by AWS Nitro devices. Just imagine there is a physical Mac Mini with
|
||||
a plugged in Nitro device that can push the physical power button!
|
||||
|
||||

|
||||

|
||||
|
||||
This clever synergy between Apple Hardware and Nitro System allows seamless integration with VPC networking and booting macOS from an EBS volume.
|
||||
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ than recently announced Apple Silicon GitHub-manged runners that cost $0.16 per
|
|||
Now lets take a look at the new Cirrus Runners dashboard of a real customers that run their workflows on Cirrus Runners
|
||||
and **practically pushing the price performance pretty close to the theoretical minimum**.
|
||||
|
||||

|
||||

|
||||
|
||||
As you can see above Cirrus Runners Dashboard focuses on 4 core metrics:
|
||||
|
||||
|
|
@ -50,7 +50,7 @@ we can see that the downside of such great price performance is that jobs are wa
|
|||
Here is another example of Cirrus Runners Dashboard for a different customer that has a slightly higher price performance of $0.017 per minute
|
||||
but at the same time doesn't experience queue time at all. **Note that $0.017 is still 10 times cheaper than GitHub-managed Apple Silicon runners**.
|
||||
|
||||

|
||||

|
||||
|
||||
## Conclusion
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ description: Run pipeline steps in isolated ephemeral Tart Virtual Machines.
|
|||
|
||||
It is possible to run [Buildkite](https://buildkite.com/) pipeline steps in isolated ephemeral Tart Virtual Machines with the help of [Tart Buildkite Plugin](https://github.com/cirruslabs/tart-buildkite-plugin):
|
||||
|
||||

|
||||

|
||||
|
||||
## Configuration
|
||||
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ brew install cirruslabs/cli/cirrus
|
|||
cirrus run
|
||||
```
|
||||
|
||||

|
||||

|
||||
|
||||
[Cirrus CI](https://cirrus-ci.org/) already leverages Tart to power its macOS cloud infrastructure. The `.cirrus.yml`
|
||||
config from above will just work in Cirrus CI and your tasks will be executed inside Tart VMs in our cloud.
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ Orchard cluster consists of three components:
|
|||
|
||||
* 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](/orchard/using-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](using-orchard-cli.md) or [an API consumer](integration-guide.md)
|
||||
|
||||
At the moment, only one Controller instance is currently supported, while you can deploy one or more Workers and run any number of Clients.
|
||||
|
||||
|
|
@ -14,7 +14,7 @@ In terms of networking requirements, only Controller needs to be directly access
|
|||
|
||||
When an Orchard Client or a Worker connects to the Controller, they need to establish trust and verify that they're talking to the right Controller, so that no [man-in-the-middle attack](https://en.wikipedia.org/wiki/Man-in-the-middle_attack) is possible.
|
||||
|
||||
Similarly to web-browsers (that rely on the [public key infrastructure](https://en.wikipedia.org/wiki/Public_key_infrastructure)) and SSH (which relies on semi-automated fingerprint verification), Orchard combines these two traits in a hybrid approach by defaulting to automatic PKI verification (can be disabled by [`--no-pki`](#--no-pki-override)) and falling-back to a manual verification for self-signed certificates.
|
||||
Similarly to web-browsers (that rely on the [public key infrastructure](https://en.wikipedia.org/wiki/Public_key_infrastructure)) and SSH (which relies on semi-automated fingerprint verification), Orchard combines these two traits in a hybrid approach by defaulting to automatic PKI verification (can be disabled by [`--no-pki`](#-no-pki-override)) and falling-back to a manual verification for self-signed certificates.
|
||||
|
||||
This hybrid approach is needed because the Controller can be configured in two ways:
|
||||
|
||||
|
|
@ -29,7 +29,7 @@ Below we'll explain how Orchard client and Worker secure the connection when acc
|
|||
|
||||
Client is associated with the Controller using a `orchard context create` command, which works as follows:
|
||||
|
||||
* Client attempts to connect to the Controller and validate its certificate using host's root CA set (can be disabled with [`--no-pki`](#--no-pki-override))
|
||||
* Client attempts to connect to the Controller and validate its certificate using host's root CA set (can be disabled with [`--no-pki`](#-no-pki-override))
|
||||
* if the Client encounters a *Controller with a publicly valid certificate*, that would be the last step and the association would succeed
|
||||
* if the Client is dealing with *Controller with a self-signed certificate*, the Client will do another connection attempt to probe the Controller's certificate
|
||||
* the probed Controller's certificate fingerprint is then presented to the user, and if the user agrees to trust it, the Client then considers that certificate to be trusted for a given context
|
||||
|
|
@ -53,7 +53,7 @@ The way Worker connects to the Controller using the `orchard worker run` command
|
|||
* when the Bootstrap Token contains the Controller's certificate:
|
||||
* the Orchard Worker will try to connect to the Controller with a trusted CA set containing only that certificate
|
||||
* when the Bootstrap Token has no Controller's certificate:
|
||||
* the Orchard Worker will try the PKI approach (can be disabled with [`--no-pki`](#--no-pki-override) to effectively prevent the Worker from connecting) and fail if certificate verification using PKI is not possible
|
||||
* the Orchard Worker will try the PKI approach (can be disabled with [`--no-pki`](#-no-pki-override) to effectively prevent the Worker from connecting) and fail if certificate verification using PKI is not possible
|
||||
|
||||
### `--no-pki` override
|
||||
|
||||
|
|
|
|||
|
|
@ -53,7 +53,7 @@ Here's other command-line arguments associated with this functionality:
|
|||
* `--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.
|
||||
Check out our [Jumping through the hoops: SSH jump host functionality in Orchard](../blog/posts/2024-06-20-jumping-through-the-hoops.md) blog post for more information.
|
||||
|
||||
## Deployment Methods
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@ Orchard has a REST API that follows [OpenAPI specification](https://swagger.io/s
|
|||
|
||||
You can run `orchard dev` locally and navigate to `http://127.0.0.1:6120/v1/` for interactive documentation.
|
||||
|
||||

|
||||

|
||||
|
||||
## Using the API
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ a couple of VMs is not enough anymore for your needs? This is where [Orchard](ht
|
|||
comes in to play!
|
||||
|
||||
It allows you to orchestrate multiple Tart-capable hosts from either an Orchard CLI (which we demonstrate below)
|
||||
or [through the API](/orchard/integration-guide).
|
||||
or [through the API](integration-guide.md).
|
||||
|
||||
The easiest way to start is to run Orchard in local development mode:
|
||||
|
||||
|
|
@ -18,7 +18,7 @@ test both the CLI functionality and the API from a tool like cURL or programming
|
|||
authenticate requests.
|
||||
|
||||
Note that in production deployments, these two components are started separately and enable security by default. Please
|
||||
refer to [Deploying Controller](/orchard/deploying-controller) and [Deploying Workers](/orchard/deploying-workers) for
|
||||
refer to [Deploying Controller](deploying-controller.md) and [Deploying Workers](deploying-workers.md) for
|
||||
more information.
|
||||
|
||||
## Creating Virtual Machines
|
||||
|
|
@ -92,10 +92,10 @@ orchard delete vm sequoia-base
|
|||
In addition to controlling the Orchard via the CLI arguments, there are environment variables that may be beneficial
|
||||
both when automating Orchard and in daily use:
|
||||
|
||||
| Variable name | Description |
|
||||
|---------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| `ORCHARD_HOME` | Override Orchard's home directory. Useful when running multiple Orchard instances on the same host and when testing. |
|
||||
| `ORCHARD_LICENSE_TIER` | The default license limit only allows connecting 4 Orchard Workers to the Orchard Controller. If you've purchased a [Gold Tier License](/licensing/), set this variable to `gold` to increase the limit to 20 Orchard Workers. And if you've purchased a [Platinum Tier License](/licensing/), set this variable to `platinum` to increase the limit to 200 Orchard Workers. |
|
||||
| `ORCHARD_URL` | Override controller URL on per-command basis. |
|
||||
| `ORCHARD_SERVICE_ACCOUNT_NAME` | Override service account name (used for controller API auth) on per-command basis. |
|
||||
| `ORCHARD_SERVICE_ACCOUNT_TOKEN` | Override service account token (used for controller API auth) on per-command basis. |
|
||||
| Variable name | Description |
|
||||
|---------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| `ORCHARD_HOME` | Override Orchard's home directory. Useful when running multiple Orchard instances on the same host and when testing. |
|
||||
| `ORCHARD_LICENSE_TIER` | The default license limit only allows connecting 4 Orchard Workers to the Orchard Controller. If you've purchased a [Gold Tier License](../licensing.md), set this variable to `gold` to increase the limit to 20 Orchard Workers. And if you've purchased a [Platinum Tier License](../licensing.md), set this variable to `platinum` to increase the limit to 200 Orchard Workers. |
|
||||
| `ORCHARD_URL` | Override controller URL on per-command basis. |
|
||||
| `ORCHARD_SERVICE_ACCOUNT_NAME` | Override service account name (used for controller API auth) on per-command basis. |
|
||||
| `ORCHARD_SERVICE_ACCOUNT_TOKEN` | Override service account token (used for controller API auth) on per-command basis. |
|
||||
|
|
|
|||
|
|
@ -75,3 +75,12 @@ 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.
|
||||
|
||||
## Automatic resources
|
||||
|
||||
In addition to manually specifying resources when starting a worker, the following resources are discovered and set automatically by the worker for convenience:
|
||||
|
||||
* `org.cirruslabs.logical-cores` — number of logical cores on the host
|
||||
* `org.cirruslabs.memory-mib` — total memory in MiB (mebibytes) on the host
|
||||
|
||||
Note that the values for these resources are scraped only once at worker startup.
|
||||
|
|
|
|||
Loading…
Reference in New Issue