Skip to content

HOLD FOR RELEASE: Add CMX VMs beta docs #3407

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 20 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
29 changes: 29 additions & 0 deletions docs/vendor/testing-ci-cd.md
Original file line number Diff line number Diff line change
@@ -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:

<TestRecs/>
75 changes: 31 additions & 44 deletions docs/vendor/testing-how-to.md
Original file line number Diff line number Diff line change
@@ -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

<Prerequisites/>
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, air-gap installations, or when you need full OS control, see [Create VMs](/vendor/testing-vm-create).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Airgap is referenced here but we never talk about it in the Create VMs page.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah yeah I had noticed that too and forgot to remove it. Good catch!


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
<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.

## 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:

Expand All @@ -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:
Expand Down Expand Up @@ -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:

Expand Down Expand Up @@ -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).

Expand Down Expand Up @@ -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.

Expand Down Expand Up @@ -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.

Expand All @@ -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:

Expand Down Expand Up @@ -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:

Expand All @@ -286,28 +297,4 @@ To delete a cluster using the Vendor Portal:

<img alt="Delete cluster button" src="/images/cmx-delete-cluster.png" width="700px"/>

[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:

<TestRecs/>
[View a larger version of this image](/images/cmx-delete-cluster.png)
Loading