diff --git a/docs/reference/replicated-cli-release-create.md b/docs/reference/replicated-cli-release-create.md index 9b5e678dc9..c87e6779b9 100644 --- a/docs/reference/replicated-cli-release-create.md +++ b/docs/reference/replicated-cli-release-create.md @@ -11,10 +11,6 @@ Create a new release using a collection of application manifest files and/or one replicated release create --yaml-dir YAML_DIR [flags] ``` -```bash -replicated release create --chart HELM_CHART [flags] -``` - :::note Additional flags returned by `--help` that are not supported by Replicated are omitted from the table below. ::: @@ -30,11 +26,6 @@ Additional flags returned by `--help` that are not supported by Replicated are o path

The local directory containing multiple YAML manifest files for a release. (Required)

- - --chart - string -

The path to the Helm chart for a release.(Required)

- --promote string @@ -75,16 +66,6 @@ replicated release create --yaml-dir ./manifests • SEQUENCE: 58 ``` -### `--chart` - -```bash -replicated release create --chart=my-chart-1.0.0.tgz - - • Reading chart from my-chart-1.0.0.tgz ✓ - • Creating Release ✓ - • SEQUENCE: 58 -``` - ### `--promote` ```bash diff --git a/docs/vendor/releases-about.mdx b/docs/vendor/releases-about.mdx index 49fca3d441..751c787067 100644 --- a/docs/vendor/releases-about.mdx +++ b/docs/vendor/releases-about.mdx @@ -63,44 +63,18 @@ The following describes each of the channel settings: This section provides additional information about releases, including details about release promotion, properties, sequencing, and versioning. -### Release Types +### Release Files -You can create the following types of releases in the Vendor Portal: +A release contains your application files as well as the manifests required to install the application with the Replicated installers ([Replicated Embedded Cluster](/vendor/embedded-overview) and [Replicated KOTS](../intro-kots)). -* **Helm-only Releases**: A release that contains one or more Helm charts. Helm-only releases can be installed with the Helm CLI only. For more information, see [Installing with Helm](install-with-helm). +The application files in releases can be Helm charts and/or Kubernetes manifests. However, Replicated strongly recommends that all applications are packaged with Helm. Releases for Helm applications can be installed with Embedded Cluster and KOTS, or with the Helm CLI. For more information, see [About Packaging Applications](/vendor/distributing-overview#about-packaging-applications). -* **KOTS Releases**: A release that contains your application files as well as the manifests required to install the application with Replicated KOTS. The application files in KOTS releases can be Helm charts and/or Kubernetes manifests. KOTS releases that contain one or more Helm charts can be installed with KOTS or the Helm CLI. For more information, see [Introduction to KOTS](../intro-kots). - -The following shows the Helm-only and KOTS release options that appear in the **Create release** dropdown in the Vendor Portal: - -create a release dropdown - -[View a larger version of this image](/images/create-release-dropdown.png) - -### Promotion +### Release Promotion Each release is promoted to one or more channels. While you are developing and testing releases, Replicated recommends promoting to a channel that does not have any real customers assigned, such as the default Unstable channel. When the release is ready to be shared externally with customers, you can then promote to a channel that has the target customers assigned, such as the Beta or Stable channel. A release cannot be edited after it is promoted to a channel. This means that you can test a release on an internal development channel, and know with confidence that the same release will be available to your customers when you promote it to a channel where real customers are assigned. -#### Promoting KOTS-Only and Helm CLI-Only Releases {#kots-helm-releases} - - - -To prevent KOTS or Helm CLI-only customers from accessing a release that they cannot install, Replicated enforces the following release promotion rules: - -* A release must contain the required KOTS manifests to be promoted to a channel where one or more KOTS customers are assigned. - - Release without the required manifests blocked from promotion - - [View a larger version of this image](/images/release-promotion-kots-customers.png) - -* A release must contain at least one Helm chart to be promoted to a channel where one or more Helm CLI-only customers are assigned. - - Release with no helm charts blocked from being promoted - - [View a larger version of this image](/images/release-promotion-helm-customers.png) - ### Properties Each release has properties. You define release properties when you promote a release to a channel. You can edit release properties at any time from the channel **Release History** page in the Vendor Portal. For more information, see [Edit Release Properties](releases-creating-releases#edit-release-properties) in _Managing Releases with the Vendor Portal_. diff --git a/docs/vendor/releases-creating-cli.mdx b/docs/vendor/releases-creating-cli.mdx index 88862c2761..3712249617 100644 --- a/docs/vendor/releases-creating-cli.mdx +++ b/docs/vendor/releases-creating-cli.mdx @@ -28,7 +28,7 @@ You can use the Replicated CLI to create a release from a local directory that c To create and promote a release: -1. (Helm Charts Only) If your release contains any Helm charts: +1. If your release contains any Helm charts: 1. Package each Helm chart as a `.tgz` file. See [Packaging a Helm Chart for a Release](/vendor/helm-install-release). @@ -47,7 +47,7 @@ To create and promote a release: mv wordpress-1.3.5.tgz manifests ``` - 1. (KOTS Only) In the same directory that contains the release files, add a HelmChart custom resource for each Helm chart in the release. See [Configuring the HelmChart Custom Resource](helm-native-v2-using). + 1. In the same directory that contains the release files, add a separate KOTS HelmChart custom resource for each Helm chart in the release. See [Configuring the HelmChart Custom Resource](helm-native-v2-using). 1. Lint the application manifest files and ensure that there are no errors in the YAML: @@ -111,27 +111,3 @@ To create and promote a release: ``` replicated release ls ``` - -## Create a Release With One Helm Chart Only - -For applications that contain only one Helm chart, you can use the `--chart` flag to create a release. - -To create a release that contains one Helm chart: - -1. Package the chart as a `.tgz` file. See [Packaging a Helm Chart for a Release](/vendor/helm-install-release). - -1. Create and promote the release: - - ```bash - replicated release create --chart=CHART_ARCHIVE --promote=CHANNEL - ``` - - Where: - * `CHART_ARCHIVE` is the Helm chart `.tgz` file. For example, `--chart=my-chart-1.0.0.tgz`. - * `CHANNEL` is the channel ID or case sensitive name of the channel. - -1. Verify that the release was promoted to the target channel: - - ``` - replicated release ls - ``` diff --git a/docs/vendor/releases-creating-releases.mdx b/docs/vendor/releases-creating-releases.mdx index e233d01b45..2fd3dd4e1d 100644 --- a/docs/vendor/releases-creating-releases.mdx +++ b/docs/vendor/releases-creating-releases.mdx @@ -21,26 +21,15 @@ To create and promote a release in the Vendor Portal: [View a larger version of this image](/images/release-create-new.png) -1. If a drop down is displayed, select one of the following options: - * **Create Helm-only release**: Create a release with one or more Helm charts. Supports installations with the Helm CLI only. - * **Create KOTS release**: Create a release that supports installations with Replicated KOTS. KOTS releases can contain Kubernetes manifests and one or more Helm charts. KOTS releases that contain Helm charts can also be installed with the Helm CLI. +1. Add files to the release. This includes your application files (like Helm charts or Kubernetes manifests) as well as the manifests required to install with the Replicated installers (like Embedded Cluster, KOTS, or kURL). - If no drop down is displayed, continue to the next step. - -1. Add your files to the release: - * **Helm-only**: For Helm-only releases, follow the steps in the **Add the Replicated SDK to your Helm Chart** dialog to package your chart and upload a `.tgz` chart archive. - - upload helm chart dialog - - [View a larger version of this image](/images/upload-helm-chart-modal.png) - - * **KOTS**: For KOTS releases, drag and drop your release files to the file directory in the YAML editor. You can also click the plus icon to add a new, untitled YAML file. + You can either drag and drop files to the file directory in the YAML editor or click the plus icon to add a new, untitled YAML file. - For any Helm charts that you add, in the **Select Installation Method** dialog, select the version of the HelmChart custom resource that KOTS will use to install the chart. kots.io/v1beta2 is recommended. For more information about the HelmChart custom resource, see [Configuring the HelmChart Custom Resource](helm-native-v2-using). + For any Helm charts that you add, in the **Select Installation Method** dialog, select the version of the HelmChart custom resource that KOTS will use to install the chart. kots.io/v1beta2 is recommended. For more information about the HelmChart custom resource, see [Configuring the HelmChart Custom Resource](helm-native-v2-using). - select installation method dialog + select installation method dialog - [View a larger version of this image](/images/helm-select-install-method.png) + [View a larger version of this image](/images/helm-select-install-method.png) 1. Click **Save release**. This saves a draft that you can continue to edit until you promote it. diff --git a/docs/vendor/replicated-onboarding.mdx b/docs/vendor/replicated-onboarding.mdx index 43bc7ac6ef..8818ab5c87 100644 --- a/docs/vendor/replicated-onboarding.mdx +++ b/docs/vendor/replicated-onboarding.mdx @@ -7,137 +7,133 @@ import HelmPackage from "../partials/helm/_helm-package.mdx" # Replicated Quick Start -Welcome! This topic provides an onboarding workflow and a feature checklist to help you get started with the Replicated Platform. For more information about Replicated, see [Introduction to Replicated](../intro-replicated). +Welcome! This topic provides an quick start workflow and an onboarding checklist to help you get started with the Replicated Platform. For more information about Replicated, see [Introduction to Replicated](../intro-replicated). -The goals of this topic are to introduce new Replicated users to the following common tasks so that they can successfully onboard their application to the Replicated Platform: -* Working with applications, channels, releases, and customers in the Replicated Vendor Portal and Replicated CLI -* Testing and iterating on releases by installing in a development environment -* Integrating key Replicated features and functionality with an application +## Set Up the Environment -## Best Practices and Recommendations +Before you begin, do the following to set up your environment: -The following are Replicated's best practices and recommendations for successfully onboarding: +* Ensure that you have kubectl access to a Kubernetes cluster. You can use any cloud provider or tool that you prefer to create a cluster, such as [Replicated Compatibility Matrix](/vendor/testing-how-to), Google Kubernetes Engine (GKE), or minikube. -* If you are relatively new to Kubernetes or Helm, start with a basic tutorial. For example, see [10 Helm Tutorials to Start your Kubernetes Journey](https://jfrog.com/blog/10-helm-tutorials-to-start-your-kubernetes-journey/) or [Tutorials](https://kubernetes.io/docs/tutorials/) in the Kubernetes documentation. +* Install the Helm CLI. To install the Helm CLI using Homebrew, run: -* When integrating new Replicated features with an application, make changes in small iterations and test frequently by installing or upgrading the application in a development environment. This will help you to more easily identify issues and troubleshoot. - -* Try creating and managing releases with both the Vendor Portal and the Replicated CLI. For more information, see [Installing the Replicated CLI](/reference/replicated-cli-installing). - -* Ask for help from the Replicated community. For more information, see [Get Help from the Community](#get-help-from-the-community). - -* Replicated also offers labs in Instruqt that provide a hands-on introduction to working with Replicated features, without needing your own sample application or development environment. To complete one or more labs before you begin the onboarding workflow, see: - * [Distributing Your Application with Replicated](https://play.instruqt.com/embed/replicated/tracks/distributing-with-replicated?token=em_VHOEfNnBgU3auAnN): Learn how to quickly get value from the Replicated Platform for your application. - * [Avoiding Installation Pitfalls](https://play.instruqt.com/embed/replicated/tracks/avoiding-installation-pitfalls?token=em_gJjtIzzTTtdd5RFG): Learn how to use preflight checks to avoid common installation issues and assure your customer is installing into a supported environment. - * [Closing the Support Information Gap](https://play.instruqt.com/embed/replicated/tracks/closing-information-gap?token=em_MO2XXCz3bAgwtEca): Learn how to use support bundles to close the information gap between your customers and your support team. - -## Prerequisites - -Before you begin, complete the following prerequisites: + ``` + brew install helm + ``` -* This workflow assumes that you have a Helm chart that you can install and develop against. Replicated strongly recommends that all vendors distribute their application as a Helm chart because many enterprise users expect to be able to install using Helm. + For more information, including alternative installation options, see [Install Helm](https://helm.sh/docs/intro/install/) in the Helm documentation. - You can use your own application chart or a sample chart. If you want to use a sample chart, Replicated recommends that you run the following Helm CLI command to create a new `replicated-onboarding` folder with a basic NGINX deployment: - ```bash - helm create replicated-onboarding - ``` - For more information, see [Helm Create](https://helm.sh/docs/helm/helm_create/) in the Helm documentation. - - Alternatively, more advanced users can also use one of the following open source Helm charts: - * [Gitea](https://github.com/bitnami/charts/tree/main/bitnami/gitea) +## Quick Start - ``` - helm pull --untar oci://registry-1.docker.io/bitnamicharts/gitea - ``` +This workflow shows how to create, install, and update releases for a sample [Bitnami Gitea](https://github.com/bitnami/charts/tree/main/bitnami/gitea) Helm chart using the Replicated Platform. You will repeat these same basic steps to create and test releases throughout the onboarding process to integrate Replicated features with your own application. - * [MediaWiki](https://github.com/bitnami/charts/tree/main/bitnami/mediawiki) +To get started with Replicated: - ``` - helm pull --untar oci://registry-1.docker.io/bitnamicharts/mediawiki - ``` +1. Create an account in the Vendor Portal. You can either create a new team or join an existing team. For more information, see [Creating a Vendor Account](vendor-portal-creating-account). - * [WordPress](https://github.com/bitnami/charts/tree/main/bitnami/wordpress) +1. Create an application using the Replicated CLI: - ``` - helm pull --untar oci://registry-1.docker.io/bitnamicharts/wordpress - ``` + 1. On your local machine, install the Replicated CLI: - :::note - If you do not intend to distribute a Helm chart-based application with Replicated, see [KOTS Tutorial (UI)](tutorial-ui-setup) to follow an onboarding workflow that uses a sample application with standard Kubernetes manifests and demonstrates installing with Replicated KOTS. - ::: + ```bash + brew install replicatedhq/replicated/cli + ``` + For more installation options, see [Installing the Replicated CLI](/reference/replicated-cli-installing). -* You must have kubectl access to a cluster where you can develop against the Helm chart. Replicated recommends that you confirm that you can successfully install the chart in the cluster and also log in to the application UI. After you confirm that you can install and access the application, uninstall it before proceeding to the onboarding workflow. For more information, see [Helm Install](https://helm.sh/docs/helm/helm_install/) and [Helm Uninstall](https://helm.sh/docs/helm/helm_uninstall/) in the Helm documentation. + 1. Authorize the Replicated CLI: -## Workflow + ```bash + replicated login + ``` + In the browser window that opens, complete the prompts to log in to your Vendor Portal account and authorize the CLI. -This onboarding workflow provides steps for using the Replicated Platform to create releases for a Helm chart-based application, then using the Helm CLI to install in a development environment. + 1. Create an application named `Gitea`: -You will repeat these same basic steps to create and test releases throughout the onboarding process to test Replicated features. You will also repeat these steps after onboarding whenever you need to integrate new Replicated features with your application. + ```bash + replicated app create Gitea + ``` -To begin onboarding to the Replicated Platform with a Helm chart: + 1. Set the `REPLICATED_APP` environment variable to the application that you created. This allows you to interact with the application using the Replicated CLI without needing to use the `--app` flag with every command: -1. Create an account in the Vendor Portal. You can either create a new team or join an existing team. For more information, see [Creating a Vendor Account](vendor-portal-creating-account). + 1. Get the slug for the application that you created: -1. Create a new application: + ```bash + replicated app ls + ``` + **Example output**: + ```bash + ID NAME SLUG SCHEDULER + 2WthxUIfGT13RlrsUx9HR7So8bR Gitea gitea-kite kots + ``` + In the example above, the application slug is `gitea-kite`. - 1. In the [Vendor Portal](https://vendor.replicated.com/), from the application drop down, click **Create new app..**. + 1. Set the `REPLICATED_APP` environment variable to the application slug. - 1. In the **Name your application** field, enter a name based on the Helm chart that you will use for onboarding. For example, "Wordpress Test" or "MediaWiki Onboarding". + **Example:** -1. Create a release for the application: + ```bash + export REPLICATED_APP=gitea-kite + ``` - 1. In the Vendor Portal, click **Releases > Create release**. - - :::note - If a drop down is displayed, click **Create Helm-only release**. - ::: - - 1. In the **Add the Replicated SDK to your Helm chart** dialog, click **Yes, I have a Helm chart for my app that I'd like to use**, and then click **Next**. +1. Get the sample Bitnami Gitea Helm chart and add the Replicated SDK as a dependency: - Add the SDK dialog - [View a larger version of this image](/images/do-you-have-a-helm-chart-modal.png) + 1. Run the following command to pull and untar version 1.0.6 of the Bitnami Gitea Helm chart: - 1. Follow the steps in the dialog to add the Replicated SDK, package the chart to a `.tgz`, and then upload the `.tgz`: + ``` + helm pull --untar oci://registry-1.docker.io/bitnamicharts/gitea --version 1.0.6 + ``` + For more information about this chart, see the [bitnami/gitea](https://github.com/bitnami/charts/tree/main/bitnami/gitea) repository in GitHub. - Upload Helm chart dialog - [View a larger version of this image](/images/upload-helm-chart-modal.png) + 1. Change to the new `gitea` directory that was created: + + ```bash + cd gitea + ``` - The following describes the steps in the dialog: + 1. In the Helm chart `Chart.yaml`, add the Replicated SDK as a dependency: - 1. In the Helm chart `Chart.yaml`, add the Replicated SDK as a dependency: + - + The Replicated SDK is a Helm chart that provides access to Replicated features and can be installed as a small service alongside your application. For more information, see [About the Replicated SDK](/vendor/replicated-sdk-overview). - The Replicated SDK is a Helm chart that provides access to Replicated features and can be installed as a small service alongside your application. For more information, see [About the Replicated SDK (Beta)](/vendor/replicated-sdk-overview). + 1. Update dependencies and package the Helm chart to a `.tgz` chart archive: - 1. Update dependencies and package the chart as a `.tgz` file: + - +1. Add the chart archive to a release and promote the release to the Unstable channel: - 1. Under **Upload your Helm chart**, drag and drop the Helm chart `.tgz` file that you created. Click **Upload chart**. - - 1. On the release page, click **Promote**. + ```bash + replicated release create --yaml-dir . --promote=Unstable + ``` + **Example output**: + ```bash + You are creating a release that will only be installable with the helm CLI. + For more information, see + https://docs.replicated.com/vendor/helm-install#about-helm-installations-with-replicated + + • Reading chart from gitea-1.0.6.tgz ✓ + • Creating Release ✓ + • SEQUENCE: 1 + • Promoting ✓ + • Channel 2kvspHtBIWqsNORGJw4KDv3L8eI successfully set to release 1 + ``` - 1. In the dialog, for **Which channels you would like to promote this release to?** select **Unstable**. Unstable is a default channel that is intended for use with internal testing. - - Promote release dialog +1. Create a customer so that you can install the release in your cluster: - [View a larger image](/images/release-promote.png) + 1. In the [Vendor Portal](https://vendor.replicated.com), click **Customers > Create customer**. - 1. Click **Promote**. + The **Create a new customer** page opens: - :::note - You can ignore any error messages in the **Promote Release** dialog. - ::: + ![Customer a new customer page in the Vendor Portal](/images/create-customer.png) -1. Create a customer so that you can install the release in your cluster: + [View a larger version of this image](/images/create-customer.png) - 1. Click **Customer > Create customer**. - - 1. For **Customer name**, add a name. + 1. For **Customer name**, enter a name for the customer. For example, `Example Customer`. 1. For **Channel**, select **Unstable**. This allows the customer to install releases promoted to the Unstable channel. + 1. For **License type**, select **Development**. + 1. For **Customer email**, enter an email address. An email address is required for Helm installations to authenticate with the Replicated registry. This email address is never used to send emails to customers. 1. Click **Save Changes**. @@ -145,67 +141,202 @@ To begin onboarding to the Replicated Platform with a Helm chart: For more information, see [Creating and Managing Customers](/vendor/releases-creating-customer). 1. Install the application: - 1. On the **Customers** page for the customer that you created, click **Helm install instructions**. - ![Helm install instructions button](/images/helm-install-button.png) + 1. Create a `gitea` namespace for the installation: - [View a larger image](/images/helm-install-button.png) + ``` + kubectl create namespace gitea + ``` - 1. Run the commands in the **Helm install instructions** dialog to log in to the registry and install the Helm chart. Skip the step to run preflight checks. + 1. Update the current kubectl context to target the new `gitea` namespace. This ensures that the chart is installed in the `gitea` namespace without requiring you to set the `--namespace` flag with the `helm install` command: + + ``` + kubectl config set-context --namespace=gitea --current + ``` + + 1. In the Vendor Portal, on the page for the customer that you created, click **Helm Install Instructions**. + + 1. Run the commands in the **Helm install instructions** dialog to log in to the Replicated registry and install the chart in your cluster. Skip the steps to run preflight checks and install the Replicated SDK in integration mode. Helm install instructions dialog [View a larger image](/images/helm-install-instructions-no-preflights.png) :::note - Ignore the **No preflight checks found** warning, if one is displayed in the dialog. This warning appears because there are no specifications for preflight checks in the Helm chart archive. You will add preflight checks later in the onboarding process. + Ignore the **No preflight checks found** warning. This warning appears because there are no specifications for preflight checks in the Helm chart archive. You will add preflight checks later. ::: - 1. After you install, in the Vendor Portal, go to **Customers**. Under the name of the customer, confirm that you can see an active instance. + 1. After the installation command completes, you can see that both the `gitea` Deployment and the Replicated SDK `replicated` Deployment were created: + + ``` + kubectl get deploy + ``` + **Example output:** + ``` + NAME READY UP-TO-DATE AVAILABLE AGE + gitea 0/1 1 0 35s + replicated 1/1 1 1 35s + ``` - **Example**: + 1. Watch the `gitea` LoadBalancer service until an external IP is available: - ![Customers page with one customer that has an active isntance](/images/onboarding-view-telemetry.png) - - [View a larger image](/images/onboarding-view-telemetry.png) - - This instance telemetry is automatically collected and sent back to the Vendor Portal when the Replicated SDK is installed alongside the application. For more information, see [About Instance and Event Data](/vendor/instance-insights-event-data). + ``` + kubectl get svc gitea --watch + ``` + + 1. After an external IP address is available for the `gitea` LoadBalancer service, confirm that you can open the application in a browser by going to `http://SERVICE_IP`, where `SERVICE_IP` is the external IP address for the `gitea` LoadBalancer service. + + Gitea app landing page + + [View a larger version of this image](/images/gitea-app.png) + +1. View instance insights for the installation: + + 1. Return to the Vendor Portal and go to **Customers**. Under the name of the customer, confirm that you can see an active instance. + + This instance telemetry is automatically collected and sent back to the Vendor Portal when the Replicated SDK is installed alongside the application. For more information, see [About Instance and Event Data](/vendor/instance-insights-event-data). 1. Under **Instance ID**, click on the ID to view additional insights including the versions of Kubernetes and the Replicated SDK running in the cluster where you installed the application. For more information, see [Instance Details](/vendor/instance-insights-details). -1. Create a new release in the Vendor Portal and then upgrade the instance in the cluster: +1. Create a new release that adds preflight checks to the application: + + 1. In your local filesystem, go to the `gitea` directory. + + 1. Create a `gitea-preflights.yaml` file in the `templates` directory: + + ``` + touch templates/gitea-preflights.yaml + ``` + + 1. In the `gitea-preflights.yaml` file, add the following YAML to create a Kubernetes Secret with a simple preflight spec: + + ```yaml + apiVersion: v1 + kind: Secret + metadata: + labels: + troubleshoot.sh/kind: preflight + name: "{{ .Release.Name }}-preflight-config" + stringData: + preflight.yaml: | + apiVersion: troubleshoot.sh/v1beta2 + kind: Preflight + metadata: + name: preflight-sample + spec: + collectors: + - http: + collectorName: slack + get: + url: https://api.slack.com/methods/api.test + analyzers: + - textAnalyze: + checkName: Slack Accessible + fileName: slack.json + regex: '"status": 200,' + outcomes: + - pass: + when: "true" + message: "Can access the Slack API" + - fail: + when: "false" + message: "Cannot access the Slack API. Check that the server can reach the internet and check [status.slack.com](https://status.slack.com)." + ``` + The YAML above defines a preflight check that confirms that an HTTP request to the Slack API at `https://api.slack.com/methods/api.test` made from the cluster returns a successful response of `"status": 200,`. + + 1. In the `Chart.yaml` file, increment the version to 1.0.7: + + ```yaml + # Chart.yaml + version: 1.0.7 + ``` + + 1. Update dependencies and package the chart to a `.tgz` chart archive: + + ```bash + helm package . --dependency-update + ``` + + 1. Create and promote a new release with the `gitea-1.0.7.tgz` archive: + + ```bash + replicated release create --chart=gitea-1.0.7.tgz --promote Unstable + ``` + **Example output**: + ```bash + You are creating a release that will only be installable with the helm CLI. + For more information, see + https://docs.replicated.com/vendor/helm-install#about-helm-installations-with-replicated + + • Reading chart from gitea-1.0.7.tgz ✓ + • Creating Release ✓ + • SEQUENCE: 2 + • Promoting ✓ + • Channel 2kvspHtBIWqsNORGJw4KDv3L8eI successfully set to release 2 + ``` - 1. Make a small change in the chart, such as incrementing the semantic version in the `Chart.yaml` to a new version. Then, package the chart again. +1. Upgrade to the new version: - 1. In the Vendor Portal, create a new release (**Releases > Create release**). Drag and drop the new chart `.tgz` and then promote the new release to the Unstable channel. + 1. In the Vendor Portal, open the **Helm Install Instructions** for the customer again. - 1. In your cluster, run `helm upgrade` to upgrade the instance to the new release that you just promoted. The `helm upgrade` command is the same as the command you used for `helm install` in a previous step, replacing `install` with `upgrade`. + The **Helm Install Instructions** dialog now includes steps for installing the preflight plugin and running preflight checks. - **Example**: + Helm install instructions with preflight commands + + [View a larger version of this command](/images/helm-install-instructions-preflights.png) + + 1. Run the first command to log in to the registry. + + 1. Run the second command to install the preflight plugin. + + 1. Run the third command to run preflight checks. + + The results of the preflight checks are displayed in the CLI. + + 1. Instead of running the install command, use Helm to upgrade the instance to the new release that you just promoted. The `helm upgrade` command is the same as the `helm install` command, replacing `install` with `upgrade`: ``` - helm upgrade wordpress oci://registry.replicated.com/my-app/unstable/wordpress + helm upgrade gitea oci://registry.replicated.com/gitea/unstable/gitea ``` See [Helm Upgrade](https://helm.sh/docs/helm/helm_upgrade/) in the Helm documentation. - 1. After the upgrade completes, return to the **Instance details** page in the Vendor Portal and confirm that you can see the new application version. + 1. After the upgrade completes, return to the **Instance details** page in the Vendor Portal and confirm that you can see the new 1.0.7 application version. + +1. Uninstall the Helm chart and the Replicated SDK from your cluster: + + ``` + helm uninstall gitea + ``` - **Example**: +1. Delete the `gitea` namespace: - ![Instance details page](/images/onboarding-instance-details-new-version.png) + ```bash + kubectl delete namespace gitea + ```` - [View a larger version](/images/onboarding-instance-details-new-version.png) +Now that you are familiar with the workflow of creating, installing, and updating releases, you can begin onboarding your own application to the Replicated Platform. -1. Now that you are familiar with the workflow of creating and installing releases, repeat step 8 to integrate and test new Replicated features with the application. Integrate one feature at a time by creating a release and then upgrading in a development environment to test. For the list of recommended features to integrate, see [Features Checklist](#features-checklist) below. +## Onboard -1. (Recommended) Finish setting up your Vendor Portal account and team: +This section provides information about how to onboard your application to the Replicated platform by integrating various Replicated features. - 1. If you are an admin, invite and manage team members. See [Invite Members](/vendor/team-management#invite-members) in _Managing Team Members_. +### Best Practices and Recommendations - 1. Set up Slack or email notifications to be notified when there are changes in the installed instances of your application. Notifications can help catch problems before they happen and let you proactively contact customers to prevent support cases. See [Configuring Instance Notifications](/vendor/instance-notifications-config). +The following are some best practices and recommendations for successfully onboarding with Replicated: + +* When integrating new Replicated features with an application, make changes in small iterations and test frequently by installing or upgrading the application in a development environment. This will help you to more easily identify issues and troubleshoot. + +* Use the Replicated CLI to create and manage your application and releases. Getting familiar with the Replicated CLI will help later on when integrating Replicated workflows into your CI/CD pipelines. For more information, see [Installing the Replicated CLI](/reference/replicated-cli-installing). + +* Ask for help from the Replicated community. For more information, see [Get Help from the Community](#get-help-from-the-community). + +* Replicated also offers labs in Instruqt that provide a hands-on introduction to working with Replicated features, without needing your own sample application or development environment. To complete one or more labs before you begin the onboarding workflow, see: + * [Distributing Your Application with Replicated](https://play.instruqt.com/embed/replicated/tracks/distributing-with-replicated?token=em_VHOEfNnBgU3auAnN): Learn how to quickly get value from the Replicated Platform for your application. + * [Avoiding Installation Pitfalls](https://play.instruqt.com/embed/replicated/tracks/avoiding-installation-pitfalls?token=em_gJjtIzzTTtdd5RFG): Learn how to use preflight checks to avoid common installation issues and assure your customer is installing into a supported environment. + * [Closing the Support Information Gap](https://play.instruqt.com/embed/replicated/tracks/closing-information-gap?token=em_MO2XXCz3bAgwtEca): Learn how to use support bundles to close the information gap between your customers and your support team. -## Features Checklist +### Onboarding Checklist This section provides a checklist of key Replicated features to integrate with your application to fully onboard onto the Replicated Platform. These features are provided in a suggested order, though you can configure and test the features in any order. @@ -352,7 +483,7 @@ This section provides a checklist of key Replicated features to integrate with y -## Get Help from the Community +### Get Help from the Community The [Replicated community site](https://community.replicated.com/) is a forum where Replicated team members and users can post questions and answers related to working with the Replicated Platform. It is designed to help Replicated users troubleshoot and learn more about common tasks involved with distributing, installing, observing, and supporting their application. diff --git a/static/images/create-release-dropdown.png b/static/images/create-release-dropdown.png deleted file mode 100644 index 164985d4cb..0000000000 Binary files a/static/images/create-release-dropdown.png and /dev/null differ diff --git a/static/images/upload-helm-chart-modal.png b/static/images/upload-helm-chart-modal.png deleted file mode 100644 index af7f925228..0000000000 Binary files a/static/images/upload-helm-chart-modal.png and /dev/null differ