diff --git a/docs/intro-kots.md b/docs/intro-kots.mdx similarity index 54% rename from docs/intro-kots.md rename to docs/intro-kots.mdx index 2dcefb9f66..ba383ab8ad 100644 --- a/docs/intro-kots.md +++ b/docs/intro-kots.mdx @@ -12,14 +12,14 @@ The Replicated KOTS entitlement is required to install applications with KOTS. F -KOTS communicates securely with the Replicated vendor platform to synchronize customer licenses, check for available application updates, send instance data, share customer-generated support bundles, and more. +KOTS communicates securely with the Replicated Vendor Portal to synchronize customer licenses, check for available application updates, send instance data, share customer-generated support bundles, and more. Installing an application with KOTS provides access to feautures such as: -* Support for air gap installations -* Support for installations on VMs or bare metal servers +* Support for air gap installations in environments with limited or no outbound internet access +* Support for installations on VMs or bare metal servers, when using Replicated Embedded Cluster or Replicated kURL * The KOTS Admin Console, which provides a user interface where customers can install and manage their application instances -* Instance telemetry automatically sent to the vendor portal for instances running in customer environments +* Instance telemetry automatically sent to the Vendor Portal for instances running in customer environments * Strict preflight checks that block installation if environment requirements are not met * Backup and restore with Replicated snapshots * Support for marking releases as required to prevent users from skipping them during upgrades @@ -28,25 +28,25 @@ KOTS is an open source project that is maintained by Replicated. For more inform ## About Installing with KOTS -KOTS can be used to install applications in Kubernetes clusters, including: +KOTS can be used to install Kubernetes applications and Helm charts in the following environments: +* Clusters provisioned on VMs or bare metal servers with Replicated Embedded Cluster or Replicated kURL * Existing clusters brought by the user -* Online or air gapped clusters -* Embedded clusters provisioned on VMs or bare metal servers with Replicated Embedded Cluster or Replicated kURL +* Online (internet-connected) or air-gapped (disconnected) environments -To install an application with KOTS, users first run an installation script to install KOTS in the target cluster and deploy the KOTS Admin Console. After KOTS is installed, users can log in to the KOTS Admin Console to upload their license file, configure the application, run preflight checks, and install and deploy the application. +To install an application with KOTS, users first run an installation script that installs KOTS in the target cluster and deploys the KOTS Admin Console. After KOTS is installed, users can log in to the KOTS Admin Console to upload their license file, configure the application, run preflight checks, and install and deploy the application. -The following diagram demonstrates how a single release promoted to the Stable channel in the Replicated vendor platform can be installed using KOTS in an embedded cluster on a VM, in an air gapped cluster, and in an existing internet-connected cluster: +The following diagram demonstrates how a single release promoted to the Stable channel in the Vendor Portal can be installed using KOTS on a VM, in an air gap cluster, and in an existing internet-connected cluster: Embedded cluster, air gap, and existing cluster app installation workflows [View a larger version of this image](/images/kots-installation-overview.png) As shown in the diagram above: -* For installations in existing internet-connected clusters, users run a command to install KOTS in their cluster. -* For embedded cluster installations on VMs or bare metal servers, users run an installation script that both provisions a cluster in their environment and installs KOTS in the cluster. -* For installations in air gapped clusters, users download air gap bundles for KOTS and the application from the Replicated download portal and then provide the bundles during installation. +* For installations in existing online (internet-connected) clusters, users run a command to install KOTS in their cluster. +* For installations on VMs or bare metal servers, users run an Embedded Cluster or kURL installation script that both provisions a cluster in their environment and installs KOTS in the cluster. +* For installations in air-gapped clusters, users download air gap bundles for KOTS and the application from the Replicated Download Portal and then provide the bundles during installation. -All users must provide a license file to install with KOTS. After KOTS is installed in the cluster, users can access the KOTS Admin Console to provide their license file and deploy the application. +All users must have a valid license file to install with KOTS. After KOTS is installed in the cluster, users can access the KOTS Admin Console to provide their license and deploy the application. For more information about how to install applications with KOTS, see the [Installing an Application](/enterprise/installing-overview) section. @@ -64,9 +64,15 @@ The following shows an example of the Admin Console dashboard for an application [View a larger version of this image](/images/guides/kots/application.png) +For applications installed with Replicated Embedded Cluster in a VM or bare metal server, the Admin Console also includes a **Cluster Management** tab where users can add and manage nodes in the embedded cluster, as shown below: + +![Admin console dashboard with Cluster Management tab](/images/gitea-ec-ready.png) + +[View a larger version of this image](/images/gitea-ec-ready.png) + ### KOTS CLI -The kots command-line interface (CLI) is a kubectl plugin. Customers can run commands with the KOTS CLI to install and manage their application instances with KOTS programmatically. +The KOTS command-line interface (CLI) is a kubectl plugin. Customers can run commands with the KOTS CLI to install and manage their application instances with KOTS programmatically. For information about getting started with the KOTS CLI, see [Installing the KOTS CLI](/reference/kots-cli-getting-started). diff --git a/docs/intro-replicated.md b/docs/intro-replicated.md deleted file mode 100644 index 4cc3883ce8..0000000000 --- a/docs/intro-replicated.md +++ /dev/null @@ -1,112 +0,0 @@ ---- -pagination_prev: null ---- - -import ApiAbout from "/docs/partials/vendor-api/_api-about.mdx" -import Kots from "/docs/partials/kots/_kots-definition.mdx" - -# Introduction to Replicated - -This topic provides an introduction to working with the Replicated Platform, including key features, supported application installation options, and interfaces. - -## Overview - -The Replicated Platform is a commercial software distribution platform. Independent software vendors (ISVs) can use features of the Replicated Platform to distribute modern enterprise software into complex, customer-controlled environments, including on-prem and air gap. - -Replicated Platform features are designed to support ISVs in each phase of the commercial software distribution life cycle, as shown below: - -![software distribution life cycle wheel](/images/software-dev-lifecycle.png) - -[View a larger version of this image](/images/software-dev-lifecycle.png) - -The following describes the phases of the software distribution life cycle: - -* **[Develop](#develop)**: Application design and architecture decisions align with customer needs, and development teams can quickly iterate on new features. -* **[Test](#test)**: Run automated tests in several customer-representative environments as part of continuous integration and continuous delivery (CI/CD) workflows. -* **[Release](#release)**: Use a single, automated release process to share new releases with both on-prem and SaaS customers. -* **[License](#license)**: Licenses are customized to each customer and are easy to issue, manage, and update. -* **[Install](#install)**: Provide unique installation options depending on customers' preferences and experience levels. -* **[Report](#report)**: Make more informed prioritization decisions by collecting adoption and performance data for application instances running in customer environments. -* **[Support](#support)**: Diagnose and resolve support issues quickly. - -For more information about the Replicated features that support each of these phases, see the sections below. - -### Develop - -The Replicated SDK exposes an in-cluster API that can be developed against to quickly integrate and test core functionality with an application. For example, when the SDK is installed alongside an application in a customer environment, the in-cluster API can be used to send custom metrics from the instance to the Replicated vendor platform. - -For more information about using the Replicated SDK, see [About the Replicated SDK](/vendor/replicated-sdk-overview). - -### Test - -The Replicated Compatibility Matrix rapidly provisions ephemeral Kubernetes clusters, including multi-node and OpenShift clusters. When integrated into existing CI/CD pipelines for an application, the Compatibility Matrix can be used to automatically create a variety of customer-representative environments for testing code changes. - -For more information, see [About Compatibility Matrix](/vendor/testing-about). - -### Release - -Release channels in the Replicated Vendor Portal allow ISVs to make different application versions available to different customers, without needing to maintain separate code bases. For example, a "Beta" channel can be used to share beta releases of an application with only a certain subset of customers. - -For more information about working with channels, see [About Channels and Releases](/vendor/releases-about). - -Additionally, the Replicated proxy registry grants proxy access to private application images using the customers' license. This ensures that customers have the right access to images based on the channel they are assigned. For more information about using the proxy registry, see [About the Replicated Proxy Registry](/vendor/private-images-about). - -### License - -Create customers in the Replicated Vendor Portal to handle licensing for your application in both online and air gap environments. For example: -* License free trials and different tiers of product plans -* Create and manage custom license entitlements -* Automatically restrict access to expired accounts -* Verify license entitlements both before installation and during runtime - -For more information about working with customers and custom license fields, see [About Customers](/vendor/licenses-about). - -### Install - -Applications distributed with Replicated can be installed using the Helm CLI or the Replicated KOTS installer. The Helm CLI supports installation of Helm charts and KOTS supports installation of Helm charts and Kubernetes manifests. - - - -For more information, see the [KOTS documentation](intro-kots). - -### Report - -When installed alongside an application, the Replicated SDK and Replicated KOTS automatically send instance data from the customer environment to the Replicated Vendor Portal. This instance data includes health and status indicators, adoption metrics, and performance metrics. For more information, see [About Instance and Event Data](/vendor/instance-insights-event-data). - -ISVs can also set up email and Slack notifications to get alerted of important instance issues or performance trends. For more information, see [Configuring Instance Notifications](/vendor/instance-notifications-config). - -### Support - -Support teams can use Replicated features to more quickly diagnose and resolve application issues. For example: - -- Customize and generate support bundles, which collect and analyze redacted information from the customer's cluster, environment, and application instance. See [About Preflights Checks and Support Bundles](/vendor/preflight-support-bundle-about). -- Provision customer-representative environments with Compatibility Matrix to recreate and diagnose issues. See [About Compatibility Matrix](/vendor/testing-about). -- Get insights into an instance's status by accessing telemetry data, which covers the health of the application, the current application version, and details about the infrastructure and cluster where the application is running. For more information, see [Customer Reporting](/vendor/customer-reporting). For more information, see [Customer Reporting](/vendor/customer-reporting). - -## Vendor Platform Interfaces - -This section describes the GUI, CLI, and API that software vendors use to interact with the vendor platform. - -### Vendor Portal - -The Replicated Vendor Portal is the web-based user interface that you can use to configure and manage all of the Replicated features for distributing and managing application releases, supporting your release, viewing customer insights and reporting, and managing teams. - -The following shows an example of the **Reporting** page for a customer: - -![Customer reporting page showing two active instances](/images/customer-reporting-page.png) - -[View a larger version of this image](/images/customer-reporting-page.png) - -### Replicated CLI - -The Replicated command-line interface (CLI) is the CLI for the Vendor Portal. The Replicated CLI can be used to complete tasks programmatically, including all tasks for packaging and managing applications, and managing artifacts such as teams, license files, and so on. For more information, see [Installing the Replicated CLI](/reference/replicated-cli-installing). - -![terminal with Replicated CLI commands](/images/replicated-cli.gif) - -### Vendor API v3 - - - -For more information, see [Using the Vendor API V3](/reference/vendor-api-using). - -![landing page of the vendor api documentation site](/images/vendor-api-docs.png) diff --git a/docs/intro-replicated.mdx b/docs/intro-replicated.mdx new file mode 100644 index 0000000000..25fe20a3da --- /dev/null +++ b/docs/intro-replicated.mdx @@ -0,0 +1,166 @@ +--- +pagination_prev: null +--- + +import ApiAbout from "/docs/partials/vendor-api/_api-about.mdx" +import Replicated from "/docs/partials/getting-started/_replicated-definition.mdx" +import Helm from "/docs/partials/helm/_helm-definition.mdx" +import Kots from "/docs/partials/kots/_kots-definition.mdx" +import KotsEntitlement from "/docs/partials/kots/_kots-entitlement-note.mdx" +import SDKOverview from "/docs/partials/replicated-sdk/_overview.mdx" +import CSDL from "/docs/partials/getting-started/_csdl-overview.mdx" +import PreflightSbAbout from "/docs/partials/preflights/_preflights-sb-about.mdx" + +# Introduction to Replicated + +This topic provides an introduction to the Replicated Platform, including a platform overview and a list of key features. It also describes the Commercial Software Distribution Lifecycle and how Replicated features can be used in each phase of the lifecycle. + +## About the Replicated Platform + + + +The Replicated Platform features are designed to support ISVs during each phase of the Commercial Software Distribution Lifecycle. For more information, see [Commercial Software Distribution Lifecycle](#csdl) below. + +The following diagram demonstrates the process of using the Replicated Platform to distribute an application, install the application in a customer environment, and support the application after installation: + +![replicated platform features workflow](/images/replicated-platform.png) + +[View a larger version of this image](/images/replicated-platform.png) + +The diagram above shows an application that is packaged with the [**Replicated SDK**](replicated-sdk-overview). The application is tested in clusters provisioned with the [**Replicated Compatibility Matrix**](testing-about), then added to a new release in the [**Vendor Portal**](/vendor/releases-about) using an automated CI/CD pipeline. + +The application is then installed by a customer ("Big Bank") in a VM. To install, the customer downloads their license, which grants proxy access to the application images through the [**Replicated proxy registry**](/vendor/private-images-about). They also download the installation assets for the [**Replicated Embedded Cluster**](/vendor/embedded-overview) installer. + +Embedded Cluster runs [**preflight checks**](preflight-support-bundle-about) to verify that the environment meets the installation requirements, provisions a cluster on the VM, and uses [**Replicated KOTS**](intro-kots) to deploy the application. KOTS provides an [**Admin Console**](intro-kots#kots-admin-console) where the customer can manage the application and the cluster. + +Finally, the diagram shows how [**instance data**](instance-insights-event-data) is automatically sent from the customer environment to the Vendor Portal by the Replicated SDK API and the KOTS Admin Console. Additionally, tooling from the open source [**Troubleshoot**](https://troubleshoot.sh/docs/collect/) project is used to generate and send [**support bundles**](preflight-support-bundle-about), which include logs and other important diagnostic data. + +## Replicated Platform Features + +The following describes the key features of the Replicated Platform. + +### Compatibility Matrix + +Replicated Compatibility Matrix can be used to get kubectl access to running clusters within minutes or less. Compatibility Matrix supports various Kubernetes distributions and versions and can be interacted with through the Vendor Portal or the Replicated CLI. + +For more information, see [About Compatibility Matrix](/vendor/testing-about). + +### Embedded Cluster + +Replicated Embedded Cluster is a Kubernetes installer based on the open source Kubernetes distribution k0s. With Embedded Cluster, users install and manage both the cluster and the application together as a single appliance on a VM or bare metal server. In this way, Kubernetes is _embedded_ with the application. + +Additionally, each version of Embedded Cluster includes a specific version of the Replicated KOTS installer. KOTS is used to install the application and also provides the Admin Console. + +For more information, see [Using Embedded Cluster](/vendor/embedded-overview). + +### KOTS (Admin Console) + +KOTS is a kubectl plugin and in-cluster Admin Console that installs Kubernetes applications in customer-controlled environments. + +The Admin Console is the user interface for installing and managing applications with KOTS. KOTS also provides a CLI that can be used to programmatically install and manage applications. + +For more information, see [Introduction to KOTS](intro-kots). + +### Preflight Checks and Support Bundles + + + +For more information, see [About Preflight Checks and Support Bundles](/vendor/preflight-support-bundle-about). + +### Proxy Registry + +The Replicated proxy registry grants proxy access to an application's images using the customer's unique license. This means that customers can get access application images during installation without the vendor needing to provide registry credentials. + +For more information, see [About the Replicated Proxy Registry](/vendor/private-images-about). + +### Replicated SDK + +The Replicated SDK is a Helm chart that can be installed as a small service alongside your application. It provides an in-cluster API that can be used to communicate with the Vendor Portal. For example, the SDK API can return details about the customer's license or report telemetry on the application instance back to the Vendor Portal. + +For more information, see [About the Replicated SDK](/vendor/replicated-sdk-overview). + +### Vendor Portal + +The Replicated Vendor Portal is the web-based user interface that you can use to configure and manage all of the Replicated features for distributing and managing application releases, supporting your release, viewing customer insights and reporting, and managing teams. + +The Vendor Portal can also be interacted with programmatically using the following developer tools: + +* **Replicated CLI**: The Replicated CLI can be used to complete tasks programmatically, including all tasks for packaging and managing applications, and managing artifacts such as teams, license files, and so on. For more information, see [Installing the Replicated CLI](/reference/replicated-cli-installing). + +* **Vendor API v3**: The Vendor API can be used to complete tasks programmatically, including all tasks for packaging and managing applications, and managing artifacts such as teams and license files. For more information, see [Using the Vendor API v3](/reference/vendor-api-using). + +## Commercial Software Distribution Lifecycle {#csdl} + +Replicated Platform features are designed to support ISVs in each phase of the Commercial Software Distribution Lifecycle shown below: + +![software distribution lifecycle wheel](/images/software-dev-lifecycle.png) + +[View a larger version of this image](/images/software-dev-lifecycle.png) + + + +For more information about to download a copy of The Commercial Software Distribution Handbook, see [The Commercial Software Distribution Handbook](https://www.replicated.com/the-commercial-software-distribution-handbook). + +The following describes the phases of the software distribution lifecycle: + +* **[Develop](#develop)**: Application design and architecture decisions align with customer needs, and development teams can quickly iterate on new features. +* **[Test](#test)**: Run automated tests in several customer-representative environments as part of continuous integration and continuous delivery (CI/CD) workflows. +* **[Release](#release)**: Use channels to share releases with external and internal users, publish release artifacts securely, and use consistent versioning. +* **[License](#license)**: Licenses are customized to each customer and are easy to issue, manage, and update. +* **[Install](#install)**: Provide unique installation options depending on customers' preferences and experience levels. +* **[Report](#report)**: Make more informed prioritization decisions by collecting usage and performance metadata for application instances running in customer environments. +* **[Support](#support)**: Diagnose and resolve support issues quickly. + +For more information about the Replicated features that support each of these phases, see the sections below. + +### Develop + +The Replicated SDK exposes an in-cluster API that can be developed against to quickly integrate and test core functionality with an application. For example, when the SDK is installed alongside an application in a customer environment, the in-cluster API can be used to send custom metrics from the instance to the Replicated vendor platform. + +For more information about using the Replicated SDK, see [About the Replicated SDK](/vendor/replicated-sdk-overview). + +### Test + +The Replicated Compatibility Matrix rapidly provisions ephemeral Kubernetes clusters, including multi-node and OpenShift clusters. When integrated into existing CI/CD pipelines for an application, the Compatibility Matrix can be used to automatically create a variety of customer-representative environments for testing code changes. + +For more information, see [About Compatibility Matrix](/vendor/testing-about). + +### Release + +Release channels in the Replicated Vendor Portal allow ISVs to make different application versions available to different customers, without needing to maintain separate code bases. For example, a "Beta" channel can be used to share beta releases of an application with only a certain subset of customers. + +For more information about working with channels, see [About Channels and Releases](/vendor/releases-about). + +Additionally, the Replicated proxy registry grants proxy access to private application images using the customers' license. This ensures that customers have the right access to images based on the channel they are assigned. For more information about using the proxy registry, see [About the Replicated Proxy Registry](/vendor/private-images-about). + +### License + +Create customers in the Replicated Vendor Portal to handle licensing for your application in both online and air gap environments. For example: +* License free trials and different tiers of product plans +* Create and manage custom license entitlements +* Verify license entitlements both before installation and during runtime +* Measure and report usage + +For more information about working with customers and custom license fields, see [About Customers](/vendor/licenses-about). + +### Install + +Applications distributed with the Replicated Platform can support multiple different installation methods from the same application release, helping you to meet your customers where they are: + +* Customers who are not experienced with Kubernetes or who prefer to deploy to a dedicated cluster in their environment can install on a VM or bare metal server with the Replicated Embedded Cluster installer. For more information, see [Using Embedded Cluster](/vendor/embedded-overview). +* Customers familiar with Kubernetes and Helm can install in their own existing cluster using Helm. For more information, see [Installing with Helm](/vendor/install-with-helm). +* Customers with limited or no outbound internet access can securely access and push images to their own internal registry, then install using Helm or a Replicated installer. For more information, see [Air Gap Installation with Embedded Cluster](/enterprise/installing-embedded-air-gap) and [Installing and Updating with Helm in Air Gap Environments (Alpha)](/vendor/helm-install-airgap). + +### Report + +When installed alongside an application, the Replicated SDK and Replicated KOTS automatically send instance data from the customer environment to the Replicated Vendor Portal. This instance data includes health and status indicators, adoption metrics, and performance metrics. For more information, see [About Instance and Event Data](/vendor/instance-insights-event-data). + +ISVs can also set up email and Slack notifications to get alerted of important instance issues or performance trends. For more information, see [Configuring Instance Notifications](/vendor/instance-notifications-config). + +### Support + +Support teams can use Replicated features to more quickly diagnose and resolve application issues. For example: + +- Customize and generate support bundles, which collect and analyze redacted information from the customer's cluster, environment, and application instance. See [About Preflights Checks and Support Bundles](/vendor/preflight-support-bundle-about). +- Provision customer-representative environments with Compatibility Matrix to recreate and diagnose issues. See [About Compatibility Matrix](/vendor/testing-about). +- Get insights into an instance's status by accessing telemetry data, which covers the health of the application, the current application version, and details about the infrastructure and cluster where the application is running. For more information, see [Customer Reporting](/vendor/customer-reporting). For more information, see [Customer Reporting](/vendor/customer-reporting). \ No newline at end of file diff --git a/docs/partials/getting-started/_csdl-overview.mdx b/docs/partials/getting-started/_csdl-overview.mdx new file mode 100644 index 0000000000..6b51ad955e --- /dev/null +++ b/docs/partials/getting-started/_csdl-overview.mdx @@ -0,0 +1,5 @@ +Commercial software distribution is the business process that independent software vendors (ISVs) use to enable enterprise customers to self-host a fully private instance of the vendor's application in an environment controlled by the customer. + +Replicated has developed the Commercial Software Distribution Lifecycle to represents the stages that are essential for every company that wants to deliver their software securely and reliably to customer controlled environments. + +This lifecycle was inspired by the DevOps lifecycle and the Software Development Lifecycle (SDLC), but it focuses on the unique things that must be done to successfully distribute third party, commercial software to tens, hundreds, or thousands of enterprise customers. \ No newline at end of file diff --git a/docs/partials/getting-started/_replicated-definition.mdx b/docs/partials/getting-started/_replicated-definition.mdx index a22180a8d7..be99b21668 100644 --- a/docs/partials/getting-started/_replicated-definition.mdx +++ b/docs/partials/getting-started/_replicated-definition.mdx @@ -1 +1 @@ -Replicated is a commercial software distribution platform. Independent software vendors (ISVs) can use features of the Replicated Platform to distribute modern enterprise software into complex, customer-controlled environments, including on-prem and air gap. \ No newline at end of file +Replicated is a commercial software distribution platform. Independent software vendors (ISVs) can use features of the Replicated Platform to distribute modern commercial software into complex, customer-controlled environments, including on-prem and air gap. \ No newline at end of file diff --git a/docs/partials/kots/_kots-definition.mdx b/docs/partials/kots/_kots-definition.mdx index 379119143e..89f851c327 100644 --- a/docs/partials/kots/_kots-definition.mdx +++ b/docs/partials/kots/_kots-definition.mdx @@ -1 +1 @@ -Replicated KOTS is a kubectl plugin and an in-cluster Admin Console that provides highly successful installations of Helm charts and Kubernetes applications into customer-controlled environments, including on-prem and air gap environments. KOTS also supports installations on VMs or bare metal servers through _embedded clusters_, which are clusters built from a customized Kubernetes distribution embedded with an application and provisioned in the customer environment at the time of installation. \ No newline at end of file +Replicated KOTS is a kubectl plugin and an in-cluster Admin Console that provides highly successful installations of Helm charts and Kubernetes applications into customer-controlled environments, including on-prem and air gap environments. \ No newline at end of file diff --git a/docs/partials/preflights/_preflights-sb-about.mdx b/docs/partials/preflights/_preflights-sb-about.mdx new file mode 100644 index 0000000000..f899f05d24 --- /dev/null +++ b/docs/partials/preflights/_preflights-sb-about.mdx @@ -0,0 +1,5 @@ +Preflight checks and support bundles are provided by the Troubleshoot open source project, which is maintained by Replicated. Troubleshoot is a kubectl plugin that provides diagnostic tools for Kubernetes applications. For more information, see the open source [Troubleshoot](https://troubleshoot.sh/docs/collect/) documentation. + +Preflight checks and support bundles analyze data from customer environments to provide insights that help users to avoid or troubleshoot common issues with an application: +* **Preflight checks** run before an application is installed to check that the customer environment meets the application requirements. +* **Support bundles** collect troubleshooting data from customer environments to help users diagnose problems with application deployments. \ No newline at end of file diff --git a/docs/vendor/distributing-overview.mdx b/docs/vendor/distributing-overview.mdx deleted file mode 100644 index 0e44d267a3..0000000000 --- a/docs/vendor/distributing-overview.mdx +++ /dev/null @@ -1,98 +0,0 @@ ---- -pagination_prev: null ---- - -import Replicated from "../partials/getting-started/_replicated-definition.mdx" -import Helm from "../partials/helm/_helm-definition.mdx" -import Kots from "../partials/kots/_kots-definition.mdx" -import KotsEntitlement from "../partials/kots/_kots-entitlement-note.mdx" -import SDKOverview from "../partials/replicated-sdk/_overview.mdx" - -# About Distributing Applications - -This topic provides an overview of distributing applications with the Replicated Platform. It includes information about the Replicated Platform features used to distribute applications, as well as the options for packaging applications. - -## About Distributing with Replicated - - - -_Distributing_ software with the Replicated Platform refers to using Replicated features to enhance and support each phase of the commercial software distribution life cycle: -* Develop -* Test -* Release -* License -* Install -* Report -* Support - -For more information about how Replicated defines the commercial software distribution life cycle, see [Introduction to Replicated](../intro-replicated). - -The following diagram demonstrates the process of distributing an application with the Replicated Platform and then installing the application in an enterprise customer environment: - -![replicated platform features workflow](/images/replicated-platform.png) - -[View a larger version of this image](/images/replicated-platform.png) - -As shown in the diagram above: -* The Replicated SDK can be distributed alongside an application to get access to an in-cluster API to more easily integrate key features. -* Replicated Compatibility Matrix can be used to quickly generate Kubernetes clusters for running application tests as part of continuous integration and continuous delivery (CI/CD) workflows. -* After testing, application releases can be promoted to a channel in the Replicated Vendor Portal to be shared with customers or internal teams. -* Customers can be assigned to channels in order to control which application releases they are able to access and install. -* Customers' unique licenses grant proxy access to private application images through the Replicated proxy registry. -* Before installation, customers can run preflight checks to verify that their environment meets installation requirements. -* Customers can install using any method, including the Helm CLI, Replicated KOTS, or any proprietary installation method already used by the ISV. -* Instance data is automatically sent to the Vendor Portal by the Replicated SDK. If the application was installed using KOTS, then KOTS also sends instance data. -* If any issues occur during installation or at runtime, customers can generate and send a support bundle. Support bundles can be uploaded in the Vendor Portal for analysis. - -For more information about the Replicated features depicted in this diagram, see: -* [About the Replicated SDK](replicated-sdk-overview) -* [About Compatibility Matrix](testing-about) -* [About Channels and Releases](releases-about) -* [About Customers](licenses-about) -* [About Installing an Application](/enterprise/installing-overview) in the KOTS documentation -* [Installing with Helm](install-with-helm) -* [About Preflight Checks and Support Bundles](preflight-support-bundle-about) -* [About Instance and Event Data](instance-insights-event-data) - -## About Packaging Applications - -This section describes the options for packaging an application that is distributed with the Replicated platform. -### Packaging with Helm (Recommended) - - - -Replicated strongly recommends that all applications are packaged using Helm because many enterprise users expect to be able to install an application with the Helm CLI. - -Helm-based applications distributed with Replicated can be installed with the Helm CLI or with the Replicated KOTS installer. - -#### Helm CLI Installations - -Helm-based applications distributed with the Replicated platform can be installed with the Helm CLI. This allows you to continue to support Helm CLI installations for your customers, while also having access to Replicated features such as tools for licensing, releasing, and supporting applications. - -For more information about installing applications distributed with Replicated using the Helm CLI, see [Installing with Helm](install-with-helm). - -#### KOTS Installations - - - -Deploying Helm-based applications with KOTS provides additional functionality not directly available with the Helm CLI, such as the KOTS Admin Console and support for air gap installations. Additionally, when you package your application using Helm, you can support Helm CLI and KOTS installations from the same release without having to maintain separate sets of Helm charts and application manifests. - -For more information about how to distribute and install Helm charts with KOTS, see [About Distributing Helm Charts with KOTS](/vendor/helm-native-about). - - - -### Packaging with Kubernetes - -For ISVs that do not want to use Helm, applications distributed with Replicated can be packaged as standard Kubernetes manifest files. Applications packaged as Kubernetes manifests can be installed using Replicated KOTS or any proprietary installer already used by the ISV. - - - -For more information about how to distribute and install Kubernetes manifest-based applications with KOTS, see the [KOTS documentation](../intro-kots). - - - -## About Distributing the Replicated SDK with an Application {#sdk} - - - -For information about the Replicated SDK API endpoints, see [Replicated SDK API](/reference/replicated-sdk-apis). For information about developing against the SDK API locally, see [Developing Against the SDK API](replicated-sdk-development). \ No newline at end of file diff --git a/docs/vendor/preflight-support-bundle-about.md b/docs/vendor/preflight-support-bundle-about.mdx similarity index 93% rename from docs/vendor/preflight-support-bundle-about.md rename to docs/vendor/preflight-support-bundle-about.mdx index cc9e7f615b..844c1aee11 100644 --- a/docs/vendor/preflight-support-bundle-about.md +++ b/docs/vendor/preflight-support-bundle-about.mdx @@ -1,14 +1,12 @@ +import Overview from "../partials/preflights/_preflights-sb-about.mdx" + # About Preflight Checks and Support Bundles This topic provides an introduction to preflight checks and support bundles, which are provided by the [Troubleshoot](https://troubleshoot.sh/) open source project. ## Overview -Preflight checks and support bundles are provided by the Troubleshoot open source project, which is maintained by Replicated. Troubleshoot is a kubectl plugin that provides diagnostic tools for Kubernetes applications. For more information, see the open source [Troubleshoot](https://troubleshoot.sh/docs/collect/) documentation. - -Preflight checks and support bundles analyze data from customer environments to provide insights that help users to avoid or troubleshoot common issues with an application: -* **Preflight checks** run before an application is installed to check that the customer environment meets the application requirements. -* **Support bundles** collect troubleshooting data from customer environments to help users diagnose problems with application deployments. + Preflight checks and support bundles consist of _collectors_, _redactors_, and _analyzers_ that are defined in a YAML specification. When preflight checks or support bundles are executed, data is collected, redacted, then analyzed to provide insights to users, as illustrated in the following diagram: diff --git a/netlify.toml b/netlify.toml index a0b9ef5177..c74029dc25 100644 --- a/netlify.toml +++ b/netlify.toml @@ -128,11 +128,11 @@ [[redirects]] from="https://docs.replicated.com/vendor/helm-overview" - to="https://docs.replicated.com/vendor/distributing-overview" + to="https://docs.replicated.com/vendor/helm-native-about" [[redirects]] from="https://docs.replicated.com/vendor/helm-install" - to="https://docs.replicated.com/vendor/distributing-overview" + to="https://docs.replicated.com/vendor/helm-native-about" [[redirects]] from="https://docs.replicated.com/vendor/testing-replicated-instance-types" @@ -174,7 +174,11 @@ [[redirects]] from="https://docs.replicated.com/vendor/support-bundle-helm-customizing" - to="https://docs.replicated.com/vendor/support-bundle-customizing" + to="https://docs.replicated.com/vendor/support-bundle-customizing" + +[[redirects]] + from="https://docs.replicated.com/vendor/distributing-overview" + to="https://docs.replicated.com/intro-replicated" [[redirects]] from="https://docs.replicated.com/vendor/distributing-workflow" diff --git a/static/images/replicated-platform.png b/static/images/replicated-platform.png index 9b18ded22e..5d7b3f77aa 100644 Binary files a/static/images/replicated-platform.png and b/static/images/replicated-platform.png differ