diff --git a/docs/vendor/testing-ci-cd.md b/docs/vendor/testing-ci-cd.md new file mode 100644 index 0000000000..1749e06b5e --- /dev/null +++ b/docs/vendor/testing-ci-cd.md @@ -0,0 +1,29 @@ +import TestRecs from "../partials/ci-cd/_test-recs.mdx" + +# Use Compatibility Matrix with CI/CD + +This topic describes how to integrate Replicated Compatibility Matrix into your CI/CD workflows. + +## About Using Compatibility Matrix with CI/CD + +Replicated recommends that you integrate Compatibility Matrix into your existing CI/CD workflow to automate the process of creating clusters to install your application and run tests. For more information, including additional best practices and recommendations for CI/CD, see [About Integrating with CI/CD](/vendor/ci-overview). + +### Replicated GitHub Actions + +Replicated maintains a set of custom GitHub actions that are designed to replace repetitive tasks related to using Compatibility Matrix and distributing applications with Replicated. + +If you use GitHub Actions as your CI/CD platform, you can include these custom actions in your workflows rather than using Replicated CLI commands. Integrating the Replicated GitHub actions into your CI/CD pipeline helps you quickly build workflows with the required inputs and outputs, without needing to manually create the required CLI commands for each step. + +To view all the available GitHub actions that Replicated maintains, see the [replicatedhq/replicated-actions](https://github.com/replicatedhq/replicated-actions/) repository in GitHub. + +For more information, see [Use Replicated GitHub Actions in CI/CD](/vendor/ci-workflows-github-actions). + +### Recommended Workflows + +Replicated recommends that you maintain unique CI/CD workflows for development (continuous integration) and for releasing your software (continuous delivery). For example development and release workflows that integrate Compatibility Matrix for testing, see [Recommended CI/CD Workflows](/vendor/ci-workflows). + +### Test Script Recommendations + +Incorporating code tests into your CI/CD workflows is important for ensuring that developers receive quick feedback and can make updates in small iterations. Replicated recommends that you create and run all of the following test types as part of your CI/CD workflows: + + \ No newline at end of file diff --git a/docs/vendor/testing-how-to.md b/docs/vendor/testing-how-to.md index 4f9dce091d..b6d4ac2f18 100644 --- a/docs/vendor/testing-how-to.md +++ b/docs/vendor/testing-how-to.md @@ -1,29 +1,32 @@ -import TestRecs from "../partials/ci-cd/_test-recs.mdx" import Prerequisites from "../partials/cmx/_prerequisites.mdx" -# Use Compatibility Matrix +# Create Clusters -This topic describes how to use Replicated Compatibility Matrix to create ephemeral clusters. +This topic describes how to use Replicated Compatibility Matrix to create and manage ephemeral clusters to test your applications across different Kubernetes distributions and versions. -## Prerequisites +This topic includes information about creating and managing clusters with Compatibility Matrix using the Replicated Vendor Portal or the Replicated CLI. For information about creating and managing clusters with the Vendor API v3, see the [clusters](https://replicated-vendor-api.readme.io/reference/listclusterusage) section in the Vendor API v3 documentation. -Before you can use Compatibility Matrix, you must complete the following prerequisites: +## About Compatibility Matrix Clusters - +Compatibility Matrix supports both VM-based clusters (such as kind, k3s, RKE2, OpenShift, and Embedded Cluster) and cloud-managed clusters (such as EKS, GKE, and AKS). VM-based clusters run on Replicated bare metal servers, while cloud clusters are provisioned in Replicated-managed cloud accounts for faster delivery. -* Existing accounts must accept the TOS for the trial on the [**Compatibility Matrix**](https://vendor.replicated.com/compatibility-matrix) page in the Replicated Vendor Portal. +You can use Compatibility Matrix clusters for testing and troubleshooting Kubernetes-based deployments and Helm installations for your application. -## Create and Manage Clusters +For information about creating VMs with Compatibility Matrix to test Replicated Embedded Cluster installers or when you need full OS control, see [Create VMs](/vendor/testing-vm-create). -This section explains how to use Compatibility Matrix to create and manage clusters with the Replicated CLI or the Vendor Portal. +## Prerequisites -For information about creating and managing clusters with the Vendor API v3, see the [clusters](https://replicated-vendor-api.readme.io/reference/listclusterusage) section in the Vendor API v3 documentation. +Before you can use Compatibility Matrix clusters, you must complete the following prerequisites: -### Create Clusters + + +* Existing accounts must accept the TOS for the trial on the [**Compatibility Matrix**](https://vendor.replicated.com/compatibility-matrix) page in the Replicated Vendor Portal. + +## Create Clusters You can create clusters with Compatibility Matrix using the Replicated CLI or the Vendor Portal. -#### Replicated CLI +### With the Replicated CLI To create a cluster using the Replicated CLI: @@ -36,7 +39,14 @@ To create a cluster using the Replicated CLI: 1. Run the following command to create a cluster: + + ```bash + replicated cluster create --distribution DISTRIBUTION ``` + + To specify more options: + + ```bash replicated cluster create --name NAME --distribution K8S_DISTRO --version K8S_VERSION --disk DISK_SIZE --instance-type INSTANCE_TYPE [--license-id LICENSE_ID] ``` Where: @@ -68,7 +78,7 @@ To create a cluster using the Replicated CLI: In the output of the command, you can see that the `STATUS` of the cluster is `assigned`. When the kubeconfig for the cluster is accessible, the cluster's status is changed to `running`. For more information about cluster statuses, see [Cluster Status](testing-about#cluster-status) in _About Compatibility Matrix._ -#### Vendor Portal +### Vendor Portal To create a cluster using the Vendor Portal: @@ -138,7 +148,7 @@ To create a cluster using the Vendor Portal: [View a larger version of this image](/images/cmx-assigned-cluster.png) -### Prepare Clusters +## Prepare Clusters For applications distributed with the Replicated Vendor Portal, the [`cluster prepare`](/reference/replicated-cli-cluster-prepare) command reduces the number of steps required to provision a cluster and then deploy a release to the cluster for testing. This is useful in continuous integration (CI) workflows that run multiple times a day. For an example workflow that uses the `cluster prepare` command, see [Recommended CI/CD Workflows](/vendor/ci-workflows). @@ -197,7 +207,7 @@ The `cluster prepare` command requires either a Helm chart archive or a director For command usage, including additional options, see [cluster prepare](/reference/replicated-cli-cluster-prepare). -### Access Clusters +## Access Clusters Compatibility Matrix provides the kubeconfig for clusters so that you can access clusters with the kubectl command line tool. For more information, see [Command line tool (kubectl)](https://kubernetes.io/docs/reference/kubectl/) in the Kubernetes documentation. @@ -227,7 +237,7 @@ To access a cluster from the command line: 1. Press Ctrl-D or type `exit` when done to end the shell and the connection to the server. -### Upgrade Clusters (kURL Only) +## Upgrade Clusters (kURL Only) For kURL clusters provisioned with Compatibility Matrix, you can use the the `cluster upgrade` command to upgrade the version of the kURL installer specification used to provision the cluster. A recommended use case for the `cluster upgrade` command is for testing your application's compatibility with Kubernetes API resource version migrations after upgrade. @@ -239,11 +249,11 @@ replicated cluster upgrade cabb74d5 --version 9d5a44c For command usage, see [cluster upgrade](/reference/replicated-cli-cluster-upgrade). -### Delete Clusters +## Delete Clusters You can delete clusters using the Replicated CLI or the Vendor Portal. -#### Replicated CLI +### Replicated CLI To delete a cluster using the Replicated CLI: @@ -276,7 +286,8 @@ To delete a cluster using the Replicated CLI: ``` Where `CLUSTER_ID` is the ID of the target cluster. In the output of the command, you can see that the `STATUS` of the cluster is `terminated`. For command usage, see [cluster ls](/reference/replicated-cli-cluster-ls). -#### Vendor Portal + +### Vendor Portal To delete a cluster using the Vendor Portal: @@ -286,28 +297,4 @@ To delete a cluster using the Vendor Portal: Delete cluster button - [View a larger version of this image](/images/cmx-delete-cluster.png) - -## About Using Compatibility Matrix with CI/CD - -Replicated recommends that you integrate Compatibility Matrix into your existing CI/CD workflow to automate the process of creating clusters to install your application and run tests. For more information, including additional best practices and recommendations for CI/CD, see [About Integrating with CI/CD](/vendor/ci-overview). - -### Replicated GitHub Actions - -Replicated maintains a set of custom GitHub actions that are designed to replace repetitive tasks related to using Compatibility Matrix and distributing applications with Replicated. - -If you use GitHub Actions as your CI/CD platform, you can include these custom actions in your workflows rather than using Replicated CLI commands. Integrating the Replicated GitHub actions into your CI/CD pipeline helps you quickly build workflows with the required inputs and outputs, without needing to manually create the required CLI commands for each step. - -To view all the available GitHub actions that Replicated maintains, see the [replicatedhq/replicated-actions](https://github.com/replicatedhq/replicated-actions/) repository in GitHub. - -For more information, see [Use Replicated GitHub Actions in CI/CD](/vendor/ci-workflows-github-actions). - -### Recommended Workflows - -Replicated recommends that you maintain unique CI/CD workflows for development (continuous integration) and for releasing your software (continuous delivery). For example development and release workflows that integrate Compatibility Matrix for testing, see [Recommended CI/CD Workflows](/vendor/ci-workflows). - -### Test Script Recommendations - -Incorporating code tests into your CI/CD workflows is important for ensuring that developers receive quick feedback and can make updates in small iterations. Replicated recommends that you create and run all of the following test types as part of your CI/CD workflows: - - + [View a larger version of this image](/images/cmx-delete-cluster.png) \ No newline at end of file diff --git a/docs/vendor/testing-vm-create.md b/docs/vendor/testing-vm-create.md new file mode 100644 index 0000000000..cfb7ab4808 --- /dev/null +++ b/docs/vendor/testing-vm-create.md @@ -0,0 +1,328 @@ +import Prerequisites from "../partials/cmx/_prerequisites.mdx" + +# Create VMs (Beta) + +This topic describes how to use Replicated Compatibility Matrix to create and manage ephemeral VMs. + +## About Compatibility Matrix VMs + +Compatibility Matrix VMs provide isolated Linux environments for testing your applications. Unlike clusters, VMs give you full control over the operating system (OS) and allow you to test installation methods that require direct OS access. + +You can use Compatibility Matrix VMs for testing and troubleshooting VM-based installations for your application with [Replicated Embedded Cluster](/intro-replicated#embedded-cluster). + +For information about creating clusters with Compatibility Matrix to test Kubernetes-based deployments and Helm installations, see [Create Clusters](/vendor/testing-how-to). + +## Supported VM Types + +The following VM types are supported: + +| Distribution | Versions | Instance Types | +| :---- | :---- | :---- | +| ubuntu | 24.04, 22.04 | r1.small, r1.medium, r1.large, r1.xlarge, r1.2xlarge | +| almalinux | 8 | r1.small, r1.medium, r1.large, r1.xlarge, r1.2xlarge | + +## Limitations + +Creating VMs with Compatibility Matrix has the following limitations: + +- Creating VMs with Compatibility Matrix is a Beta feature. +- Installing Embedded Cluster on a VM created with Compatibility Matrix is supported for Embedded Cluster versions 1.21.0 or later. +- [GitHub Actions](/vendor/testing-how-to#replicated-github-actions) are not supported for Compatibility Matrix VMs. +- The [cluster prepare](/reference/replicated-cli-cluster-prepare) command is not supported for Compatibility Matrix VMs. + +## Prerequisites + +Before you can use Compatibility Matrix VMs, you must complete the following prerequisites: + + + +* Existing accounts must accept the TOS for the trial on the [**Compatibility Matrix**](https://vendor.replicated.com/compatibility-matrix) page in the Replicated Vendor Portal. + +## Set Up SSH Access + +In order to access VMs that you create with Compatibility Matrix, you need to set up SSH access. You can do this using your personal GitHub account or a GitHub service account used by your team. + +For setting up SSH access to VMs that you create on your local machine, Replicated recommends that you use your personal GitHub account. For setting up SSH access for VMs created in CI/CD workflows used by your team, use a GitHub service account. For more information, see the sections below. + +:::note +Your GitHub usernames and SSH keys are synced to a VM when it is first created. If you update your GitHub username or keys after creating a VM, you can manually sync by updating your [Account Settings](https://vendor.replicated.com/account-settings) in the Vendor Portal and clicking **Save**. +::: + +### Use Your GitHub Account + +To set up and verify SSH access for Compatibility Matrix VMs using your personal GitHub account: + +1. Log in to your GitHub account and add an SSH key if you do not have one already. For information about how to generate and add a new SSH key, see [Generate a new SSH key](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent#generati[…]w-ssh-key) and [Adding a new SSH key to your GitHub account](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account) in the GitHub documentation. + +1. Run the following command to verify that your public/private SSH key is properly set up with GitHub. + + ```bash + ssh -T git@github.com + ``` + + If successful, you will see: + + ``` + Hi ! You've successfully authenticated, but GitHub does not provide shell access. + ``` + +1. Log in to the Vendor Portal and go to [**Account Settings**](https://vendor.replicated.com/account-settings/info). + +1. On the **Account Settings > Account Information** page, for **GitHub username**, add your GitHub username. + +1. On the command line, authenticate with the Replicated CLI using your Vendor Portal account: + + ```bash + replicated login + ``` + :::note + To log out of an existing session, first run `replicated logout`. + ::: + +1. Run the following command to verify that your SSH setup is working: + + ```bash + ssh -T replicated@replicatedvm.com + ``` + If successful, you will see a message similar to the following: + + ``` + Hi ! You have successfully authenticated, use [VM_ID]@replicatedvm.com to access your VM. + ``` + + :::note + If you see the prompt `Are you sure you want to continue connecting (yes/no/[fingerprint])?`, type `yes` and press Enter to continue. You might see this prompt if it is the first time you are authenticating with the public/private SSH key in your GitHub account. + ::: + +### Use a Service Account + +To automate the creation of VMs in your CI/CD workflows, you can use the flag `--ssh-public-key` to provide the SSH public key for a GitHub service account. For example: + +```bash +replicated vm create --distribution ubuntu --version 24.04 --ssh-public-key ~/.ssh/id_rsa.pub +``` + +Using multiple SSH public keys: + +```bash +replicated vm create --distribution ubuntu --version 24.04 --ssh-public-key ~/.ssh/id_rsa.pub --ssh-public-key ~/.ssh/id_ed25519.pub +``` + +## Create VMs + +To create VMs with Compatibility Matrix: + +1. (Optional) View the available VM distributions, including the supported VM distribution versions and instance types: + + ```bash + replicated vm versions + ``` + For command usage, see [vm versions](/reference/replicated-cli-vm-versions). + + +1. Run the following command to create a VM: + + ```bash + replicated vm create --distribution DISTRIBUTION + ``` + + To specify more options: + + + ```bash + replicated vm create --name NAME --distribution DISTRIBUTION --version VERSION --instance-type INSTANCE_TYPE --count COUNT --ttl TTL + ``` + + Where: + * `NAME` is any name for the VM. If `--name` is excluded, a name is automatically generated for the VM. + * `DISTRIBUTION` is the operating system distribution for the VM (e.g., ubuntu, almalinux). + * `VERSION` is the version of the distribution to provision (e.g., 22.04, 24.04 for Ubuntu). + * `INSTANCE_TYPE` is the instance type to use for the VM (e.g., r1.medium, r1.large). + * `COUNT` is the number of VMs to create. If `--count` is excluded, one VM is created by default. + * `TTL` is the VM Time-To-Live duration (maximum 48h). If `--ttl` is excluded, the default TTL is 1 hour. + + For command usage and additional optional flags, see [vm create](/reference/replicated-cli-vm-create). + + **Example:** + + The following example creates an Ubuntu VM with version 22.04, a disk size of 50 GiB, and an instance type of `r1.medium`. + + ```bash + replicated vm create --distribution ubuntu --version 22.04 --disk 50 --instance-type r1.medium + ``` + +## Connect to a VM + +You can SSH into a VM using one of the following methods: + +* [**Compatibility Matrix Forwarder**](#compatibility-matrix-forwarder): To use the Compatibility Matrix Forwarder, you only need to know the VM ID to connect to the machine with SSH. This is more approachable for users less familiar with SSH clients. + +* [**Direct SSH**](#direct-ssh): When you connect to a VM using direct SSH, you can use your SSH tool of choice and pass any client supported flags, without any added connection lag of being routed through the Compatibility Matrix Forwarder. Example use cases for direct SSH include transferring large assets such as air gap bundles to the VM using SCP, or passing specific SHH flags during testing workflows. + +For information about how to copy files to a VM after connecting, see [Copy Files to a VM](#copy-files-to-a-vm) below. + +### Compatibility Matrix Forwarder + +To connect to a VM using the Forwarder: + +* SSH into the VM: + + ```bash + ssh VMID@replicatedvm.com + ``` + + Where `VMID` is the ID of the VM. + +For information about copying files to the VM after connecting, see [After Connecting to the VM with the Forwarder](#after-connecting-to-the-vm-with-the-forwarder) below. + +### Direct SSH + +Connecting to a VM with direct SSH requires Replicated CLI v0.104.0 or later. + +To connect to a VM using direct SSH: + +1. Get the SSH endpoint for the VM: + + ```bash + replicated vm ssh-endpoint VMID_OR_VMNAME [--username GITHUB_USERNAME] + ``` + + Where: + * `VMID_OR_VMNAME` is the ID or name of the VM. Run `replicated vm ls`. + * (Optional) `GITHUB_USERNAME` is a GitHub username used to connect to the SSH endpoint. This is an optional flag that overrides the GitHub username listed in your Vendor Portal account. The `--username` flag is required if you want to: + * Use a different GitHub username than what is in Vendor Portal (or if there is no username set in the Vendor Portal) + * When creating a VM, you used the `--ssh-public-key` flag to associate the VM with a GitHub service account, and this doesn't match the GitHub username set in Vendor Portal + + **Example:** + + ```bash + replicated vm ssh-endpoint aba1acc2 + ``` + + The output of the command displays the SSH endpoint that you can use to connect to the VM: + + ``` + ssh://[github-user-name]@[ssh-endpoint]:[port] + ``` + For example, `ssh://yourusername@37.27.52.116:46795`. + + :::note + You can also get the SSH endpoint and port in JSON format by running `replicated vm ls --output json`. + ::: + +1. Copy the SSH endpoint. + +1. SSH into the VM using the SSH endpoint that you copied: + + ```bash + ssh ssh://YOUR_GITHUB_USERNAME@SSH_ENDPOINT:PORT + ``` + Where `GITHUB_USERNAME`, `SSH_ENDPOINT`, and `PORT` are all copied from the SSH endpoint that you retrieved. + + **Example:** + + ```bash + ssh ssh://yourusername@37.27.52.116:46795 + ``` + + Alternatively, run the following command to SSH into the VM without needing to copy the endpoint: + + ```bash + ssh $(replicated vm ssh-endpoint VMID_OR_VMNAME) + ``` + + **Example** + + ``` + ssh $(replicated vm ssh-endpoint aba1acc2) + ``` + +## Copy Files to a VM + +You can copy files to a VM either using direct SSH and an SCP endpoint, or by using SCP after connecting to the VM with the Compatibility Matrix Forwarder. Transferring files using direct SSH allows you to use your SSH tool of choice, and pass any client-supported flags. + +### Using the SCP Endpoint + +To copy files to a VM using the scp endpoint: + +1. Run the following command to get the SCP endpoint: + + ```bash + replicated vm scp-endpoint VMID_OR_VMNAME [--username GITHUB_USERNAME] + ``` + + Where + * `VMID_OR_VMNAME` is the ID or name of the VM. + * (Optional) `GITHUB_USERNAME` is a GitHub username used to connect to the SCP endpoint. This is an optional flag that overrides the GitHub username listed in your Vendor Portal account. The `--username` flag is required if you want to: + * Use a different GitHub username than what is in Vendor Portal (or if there is no username set in the Vendor Portal) + * When creating a VM, you used the `--ssh-public-key` flag to associate the VM with a GitHub service account, and this doesn't match the GitHub username set in Vendor Portal + + **Example** + ```bash + replicated vm scp-endpoint aba1acc2 + ``` + + The output of the command lists the SCP endpoint for the VM: + + ``` + scp://GITHUB_USERNAME@SSH_ENDPOINT:PORT + ``` + + For example, `scp://yourusername@37.27.52.116:46795`. + +1. Copy the SCP endpoint. + +1. SCP files into the VM: + + ```bash + scp somefile scp://GITHUB_USERNAME@SSH_ENDPOINT:PORT//PATH + ``` + Where: + * `GITHUB_USERNAME`, `SSH_ENDPOINT`, and `PORT` are all copied from the SCP endpoint that you retrieved. + * `PATH` is the destination path on the VM. + + Alternatively, run the following command to SCP files into the VM without needing to copy the endpoint: + + ```bash + scp somefile $(replicated vm scp-endpoint VMID_OR_VMNAME)//PATH + ``` + +### After Connecting to the VM with the Forwarder + +:::note +Transferring files using Compatibility Matrix Forwarder is slower than using direct SSH due to added latency. If you want to transfer large files such as air gap bundles onto the VM, use direct SSH in combination with SCP. See [Using the SCP Endpoint](#using-the-scp-endpoint) above. +::: + +#### Limitations +Transferring files using the Compatibility Matrix Forwarder has the following limitations: +- `scp` with flag `-O` (legacy scp protocol) is not supported. +- Relative paths is not supported. For example: + - Unsupported: `scp somefile VMID@replicatedvm.com:~` + - Supported: `scp somefile VMID@replicatedvm:/home/folder/somefile` +- File permissions are not inherited. + +To copy files to the VM using SCP after connecting with the Compatibility Matrix Forwarder: + +1. SSH into the VM using the Forwarder: + + ```bash + ssh VMID@replicatedvm.com + ``` + + Where `VMID` is the ID of the VM. + +1. Copy files onto the machine: + ```bash + scp FILENAME VMID@replicatedvm:PATH + ``` + + Where: + * `FILENAME` is the name of the file. + * `VMID` is the ID of the VM. + * `PATH` is the path on the VM where you want to copy the file. For example, `/home/folder/somefile`. Relative paths are not supported. + + **Example:** + + ```bash + scp somefile 123abc@replicatedvm:/home/folder/somefile + ``` \ No newline at end of file diff --git a/docs/vendor/testing-vm-networking.md b/docs/vendor/testing-vm-networking.md new file mode 100644 index 0000000000..55db1b8fee --- /dev/null +++ b/docs/vendor/testing-vm-networking.md @@ -0,0 +1,110 @@ +# VM Networking (Beta) + +This topic describes advanced networking features for Replicated Compatibility Matrix VMs, including port exposure, VM-to-cluster connections, and shared networks. + +## Limitations + +Creating wildcard DNS entries for VMs is not supported. For feedback, contact Replicated support. + +## Compatibility Matrix Tunnels + +You can expose ports on a VM and make them accessible on the public internet. For more information about a similar feature, see [Compatibility Matrix Tunnels for Clusters](testing-ingress#compatibility-matrix-tunnels-beta). + +### Create a Tunnel + +```bash +replicated vm port expose VMID_OR_VMNAME --port PORT --protocol PROTOCOL +``` + +For example, to expose port 3000 with HTTP protocol: +```bash +replicated vm port expose VM_ID --port 30000 --protocol http +``` + +### List Tunnels + +```bash +replicated vm port ls VMID_OR_VMNAME +``` + +### Remove a Tunnel + +```bash +replicated vm port rm VMID_OR_VMNAME +``` + +## Connect a Compatibility Matrix VM with a Compatibility Matrix Cluster + +You can make a Compatibility Matrix cluster available on the same network as a Compatibility Matrix VM. + +**Compatible clusters:** Openshift, K3s, RKE2, EC, kURL, kind +**Requirement:** Replicated CLI 0.90.0 or later + +To connect a Compatibility Matrix VM with a Compatibility Matrix cluster on the same network: + +1. Create a cluster: + + ```bash + replicated cluster create --distribution K8S_DISTRIBUTION + ``` + + For example, `replicated cluster create --distribution k3s`. + +1. In the output of the `cluster create` command, under `NETWORK`, copy the network ID. + + Example: + + ``` + ID NAME DISTRIBUTION VERSION STATUS NETWORK CREATED EXPIRES COST + 6b14376c ecstatic_raman k3s 1.33.2 queued accbd6a7 2025-08-04 13:20 PDT - $0.60 + ``` + In the example above, the network ID is `accbd6a7`. + +1. Create a VM on the same network: + + ```bash + replicated vm create --distribution DISTRIBUTION --network NETWORK_ID + ``` + Where `NETWORK_ID` is the network ID that you copied in the previous step. + + For example, `replicated vm create --distribution ubuntu --network accbd6a7`. + + Example output: + + ``` + ID NAME DISTRIBUTION VERSION STATUS NETWORK CREATED EXPIRES COST + 760a30b1 suspicious_poitras ubuntu 24.04 assigned accbd6a7 2025-08-04 13:24 PDT - $0.60 + ``` + +## Connect Compatibility Matrix VMs on a Shared Network + +### Create VMs on the Same Network + +Use the `--count` flag to create multiple VMs with the same name, all running on the same Network ID. + +```bash +replicated vm create --distribution ubuntu --count 3 +``` + +### Join VMs to an Existing VM Network + +1. Run one of the following commands to get the ID of an existing VM network: + + * List VMs: + ```bash + replicated vm ls + ``` + + * List networks: + ```bash + replicated network ls + ``` + +1. In the output of the command, copy the network ID. + +1. Use the `--network` flag to create a new VM on the same network: + + ```bash + replicated vm create --distribution ubuntu --network NETWORK_ID + ``` + Where `NETWORK_ID` is the network ID that you copied in the previous step. \ No newline at end of file diff --git a/sidebars.js b/sidebars.js index 233c57fa5f..d2e94507d7 100644 --- a/sidebars.js +++ b/sidebars.js @@ -230,9 +230,18 @@ const sidebars = { 'vendor/testing-about', 'vendor/testing-pricing', 'vendor/testing-supported-clusters', + { + type: 'category', + label: 'Use Compatibility Matrix', + items: [ + 'vendor/testing-how-to', + 'vendor/testing-vm-create', + 'vendor/testing-vm-networking', + 'vendor/testing-ci-cd', + ], + }, 'vendor/testing-cluster-addons', 'vendor/compatibility-matrix-usage', - 'vendor/testing-how-to', 'vendor/testing-ingress', ], },