Description
-The KOTS HelmChart custom resource provides instructions to KOTS about how to deploy the Helm chart. The name and chartVersion listed in the HelmChart custom resource must match the name and version of a Helm chart archive in the release. The optionalValues field sets the specified Helm values when a given conditional statement evaluates to true. In this case, if the application is installed with Embedded Cluster, then the Gitea service type is set to `NodePort` and the node port is set to `"32000"`. This will allow Gitea to be accessed from the local machine after deployment for the purpose of this quick start.
The HelmChart custom resource provides instructions to the installer about how to deploy the Helm chart. The name and chartVersion listed in the HelmChart custom resource must match the name and version of a Helm chart archive in the release. This HelmChart resource includes several `values` and conditional `optionalValues` that are supplied to `helm template` during deployment.
YAML
Description
-The KOTS Application custom resource enables features in the Replicated Admin Console such as branding, release notes, application status indicators, and custom graphs.
The YAML below provides a name for the application to display in the Admin Console, adds a custom status informer that displays the status of the gitea Deployment resource in the Admin Console dashboard, adds a custom application icon, and adds the port where the Gitea service can be accessed so that the user can open the application after installation.
The Replicated Application custom resource enables features in the Replicated Admin Console UI, which is used to configure, install, update, and manage applications. This Application resource provides a name for the application to display in the Admin Console, adds custom status informers that are used to display the status of the deployment in the Admin Console dashboard, and adds a custom application icon.
YAML
Description
-The Kubernetes SIG Application custom resource supports functionality such as including buttons and links on the Replicated Admin Console dashboard. The YAML below adds an Open App button to the Admin Console dashboard that opens the application using the service port defined in the KOTS Application custom resource.
+The Kubernetes SIG Application custom resource supports functionality such as including buttons and links on the Admin Console dashboard. This SIG Application resource adds an Open SlackerNews button that opens the application.
YAML
YAML
Description
+The Config custom resource defines the application configuration fields that are exposed to the user in the Admin Console. These fields can then be mapped to the `values.yaml` file for the Helm chart. This Config resource includes several fields, but you will only use a few of them when installing SlackerNews for the purpose of this tutorial.
+YAML
+
+ 
- [View a larger version of this image](/images/quick-start-select-gitea-app.png)
+ [View a larger version of this image](/images/quick-start-app-dropdown-slackernews.png)
1. Click **Customers > Create customer**.
@@ -197,121 +266,228 @@ Before you begin, ensure that you have access to a VM that meets the requirement
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 **Assigned Channel**, select **Unstable**. This allows the customer to install releases promoted to the Unstable channel.
- 1. For **License type**, select **Development**.
+ 1. For **Customer type**, select **Development**.
- 1. For **License options**, enable the following entitlements:
- * **KOTS Install Enabled**
- * **Embedded Cluster Enabled**
+ 1. For **Install types**, enable **Embedded Cluster (current generation product)** and disable the other install type options.
1. Click **Save Changes**.
+1. (Optional) In the Vendor Portal, click **Releases** to view the release that you promoted. In the release viewer, you can see the Replicated manifests as well as the SlackerNews `Chart.yaml` and `values.yaml` files.
+
+1. If you brought your own VM, SSH onto your VM. Otherwise, follow these steps to create and SSH onto a VM with Compatibility Matrix:
+
+ 1. Create an Ubuntu VM that expires after two hours:
+
+ ```bash
+ replicated vm create --distribution ubuntu --version 24.04 --instance-type r1.small --disk 50 --ttl 2h
+ ```
+ **Example output:**
+ ```bash
+ ID NAME DISTRIBUTION VERSION STATUS NETWORK CREATED EXPIRES COST
+ 97940819 practical_black ubuntu 24.04 queued c726ffff 2025-08-20 14:32 MDT - $0.69
+ ```
+
+ 1. After a few minutes, check the status of the VM to see when it is `running`:
+
+ ```bash
+ replicated vm ls
+ ```
+ **Example output:**
+ ```bash
+ ID NAME DISTRIBUTION VERSION STATUS NETWORK CREATED EXPIRES COST
+ 97940819 practical_black ubuntu 24.04 running c726ffff 2025-08-20 14:32 MDT 2025-08-20 16:33 MDT $0.69
+ ```
+
+ 1. Run the following command to use the Compatibility Matrix Forwarder to SSH onto the VM:
+
+ ```bash
+ ssh VM_ID@replicatedvm.com
+ ```
+ Where `VM_ID` is the `ID` from the output of the `replicated vm ls` command.
+
+ :::note
+ If you are prompted to add the fingerprint for replicatedvm.com, type `yes` and press Enter.
+ :::
+
+ 1. When prompted, provide the passphrase for the SSH key in your linked GitHub account. Compatibility Matrix uses GitHub SSH to provide access to the VM.
+
1. Install the application with Embedded Cluster:
- 1. On the page for the customer that you created, click **Install instructions > Embedded Cluster**.
+ 1. In the Vendor Portal, on the page for the customer that you created, click **Embedded Cluster install instructions**.
- 
+ 
- [View a larger image](/images/customer-install-instructions-dropdown.png)
+ [View a larger version of this image](/images/quick-start-slackernews-customer-install-instructions-button.png)
- 1. On the command line, SSH onto your VM and run the commands in the **Embedded cluster install instructions** dialog to download the latest release, extract the installation assets, and install.
+ 1. On your VM, run the commands in the **Embedded cluster install instructions** dialog to download the latest release, extract the installation assets, and install SlackerNews.
- 
+
[View a larger version of this image](/images/embedded-cluster-install-dialog-latest.png)
- 1. When prompted, enter a password for accessing the Admin Console.
+ 1. When prompted by the `install` command, set a password for accessing the Admin Console.
+
+ :::note
+ Remember this password because you will use it to log in to the Admin Console in a later step.
+ :::
The installation command takes a few minutes to complete.
**Example output:**
```bash
- ? Enter an Admin Console password: ********
- ? Confirm password: ********
- ✔ Host files materialized!
- ✔ Running host preflights
- ✔ Node installation finished!
- ✔ Storage is ready!
- ✔ Embedded Cluster Operator is ready!
- ✔ Admin Console is ready!
- ✔ Additional components are ready!
- Visit the Admin Console to configure and install gitea-kite: http://104.155.145.60:30000
+ ? Set the Admin Console password (minimum 6 characters): ********
+ ? Confirm the Admin Console password: ********
+
+ ✔ Initialization complete
+ ✔ Host preflights passed
+ ✔ Node is ready
+ ✔ Storage is ready
+ ✔ Runtime Operator is ready
+ ✔ Admin Console is ready
+ ✔ Additional components are ready
+
+ -----------------------------------------------------------------
+ Visit the Admin Console to configure and install slackernews-gnu:
+
+ http://10.0.0.11:30000
+ -----------------------------------------------------------------
```
At this point, the cluster is provisioned and the Admin Console is deployed, but the application is not yet installed.
- 1. Go to the URL provided in the output to access to the Admin Console.
-
- 1. On the Admin Console landing page, click **Start**.
+ 1. Do one of the following to access the Admin Console:
+ * If you brought your own VM, go to the URL provided in the output of the install command.
+ :::note
+ The IP address in the provided URL might be the private IP address of your VM. You might need to edit the URL to use the public IP address.
+ :::
+ * If you created the VM with Compatibility Matrix:
+ 1. In the Vendor Portal, go to [**Compatibility Matrix**](https://vendor.replicated.com/compatibility-matrix/overview).
+ 1. Open the dot menu for your VM and click **Edit VM**.
+
+ 
+
+ [View a larger version of this image](/images/compatibility-matrix-edit-vm.png)
+
+ 1. Under **Ingress & Ports**, for **Add DNS record**, click **Add** to create a DNS record using the default settings. This will provide a hostname where you can access the Admin Console.
- 1. On the **Secure the Admin Console** screen, review the instructions and click **Continue**. In your browser, follow the instructions that were provided on the **Secure the Admin Console** screen to bypass the warning.
+ 1. Add another DNS record with a **Target Port** of **443**. This will provide a hostname where you can access SlackerNews after it's installed.
- 1. On the **Certificate type** screen, either select **Self-signed** to continue using the self-signed Admin Console certificate or click **Upload your own** to upload your own private key and certificacte.
+ The following shows an example of both of these DNS records added to a VM:
- By default, a self-signed TLS certificate is used to secure communication between your browser and the Admin Console. You will see a warning in your browser every time you access the Admin Console unless you upload your own certificate.
+ 
+ [View a larger version of this image](/images/compatibility-matrix-dns-record.png)
- 1. On the login page, enter the Admin Console password that you created during installation and click **Log in**.
+ 1. (Optional) Copy the URL for the DNS record with a target port of 443 and save it somewhere on your local machine. You will be asked to provide this hostname in the Admin Console as part of the installation process for SlackerNews.
+
+ 1. In a browser, navigate to the URL for the DNS record with a target port of 30000.
+
+ The Admin Console opens.
+
+ 1. If you are directed to the Admin Console landing page:
+ 1. Click **Start**.
+ 1. On the **Secure the Admin Console** screen, review the instructions and click **Continue**. In your browser, follow the instructions that were provided on the **Secure the Admin Console** screen to bypass the warning.
+ 1. On the **Certificate type** screen, either select **Self-signed** to continue using the self-signed Admin Console certificate or click **Upload your own** to upload your own private key and certificate. By default, a self-signed TLS certificate is used to secure communication between your browser and the Admin Console. You will see a warning in your browser every time you access the Admin Console unless you upload your own certificate.
+
+ :::note
+ If you created the VM with Compatibility Matrix, you might not see these pages. Instead, your browser might automatically redirect to the Admin Console login screen.
+ :::
+
+ 1. On the login screen, enter the Admin Console password that you set and click **Log in**.
+
+ 
+
+ [View a larger version of this image](/images/quick-start-slackernews-admin-console-login.png)
1. On the **Configure the cluster** screen, you can view details about the VM where you installed, including its node role, status, CPU, and memory. Users can also optionally add additional nodes on this page before deploying the application. Click **Continue**.
- The Admin Console dashboard opens.
+ 
+
+ [View a larger version of this image](/images/quick-start-slackernews-configure-the-cluster.png)
- 1. On the Admin Console dashboard, next to the version, click **Deploy** and then **Yes, Deploy**.
+ 1. On the **Configure SlackerNews** screen, complete the following fields:
+
+ * For **Ingress Hostname**:
+ * If you created the VM with Compatibility Matrix, enter the URL that you copied for the DNS record with a target port of 443. For example, `pensive-keldysh.ingress.replicatedcluster.com`.
- The application status changes from Missing to Unavailable while the `gitea` Deployment is being created.
+ * If you are using your own VM, provide the public IP address for your VM. You can copy the IP address from your browser's address bar where you are currently accessing the Admin Console. Alternatively, if you have a hostname for your VM's IP address, you can provide that instead.
- 1. After a few minutes when the application status is Ready, click **Open App** to view the Gitea application in a browser.
+ * For **Application Access > Service Type**, ensure that **NodePort** is selected. Leave the **Node Port** field blank to use the default port of 443.
+
+ * For **Postgresql**, ensure that **Deploy Postgresql Database** is enabled to deploy the built-in Postgresql database.
+
+ Leave the other fields on the **Configure SlackerNews** screen empty. They are not applicable for this quick start.
+
+ 
+
+ [View a larger version of this image](/images/quick-start-slackernews-configure-slackernews.png)
- For example:
+ 1. Click **Continue**.
+
+ The Admin Console dashboard opens. The application status changes from Missing to Unavailable while the application is being deployed. You can click **Details** next to the status for more information about the status of specific application resources.
+
+ After a few minutes, the status changes to Ready when the application is deployed:
+
+ 
- 
+ [View a larger version of this image](/images/quick-start-slackernews-adm-dashboard-ready.png)
- [View a larger version of this image](/images/gitea-ec-ready.png)
+ 1. After a few minutes when the application status is Ready, click **Open SlackerNews** to view SlackerNews in a browser.
- 
+ 
- [View a larger version of this image](/images/gitea-app.png)
+ [View a larger version of this image](/images/slackernews-landing-page.png)
-1. Return to the Vendor Portal and go to **Customers**. Under the name of the customer, confirm that you can see an active instance.
+1. View telemetry for the instance that you just deployed:
- This instance telemetry is automatically collected and sent back to the Vendor Portal by both KOTS and the Replicated SDK. For more information, see [About Instance and Event Data](/vendor/instance-insights-event-data).
+ 1. Return to the Vendor Portal, select the SlackerNews application, and go to **Customers**. Under the name of the customer, confirm that you can see an active instance.
-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).
+ 
+
+ [View a larger version of this image](/images/quick-start-slackernews-customer-instance.png)
+
+ This instance telemetry is automatically collected and sent back to the Vendor Portal by Embedded Cluster and the Replicated SDK. For more information, see [About Instance and Event Data](/vendor/instance-insights-event-data).
+
+ 1. (Optional) 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.
1. Create a new release that adds preflight checks to the application:
- 1. In your local filesystem, go to the `gitea` directory.
+ 1. In your local filesystem, go to the `quick-start/chart/slackernews` directory.
- 1. Create a `gitea-preflights.yaml` file in the `templates` directory:
+ 1. Create a `preflights.yaml` file in the `templates` directory for the chart:
```
- touch templates/gitea-preflights.yaml
+ touch templates/preflights.yaml
```
- 1. In the `gitea-preflights.yaml` file, add the following YAML to create a Kubernetes Secret with a simple preflight spec:
+ 1. In the `preflights.yaml` file, add the following YAML to create a Kubernetes Secret with a simple preflight spec:
```yaml
apiVersion: v1
kind: Secret
metadata:
+ name: slackernews-preflight
labels:
troubleshoot.sh/kind: preflight
- name: "{{ .Release.Name }}-preflight-config"
stringData:
- preflight.yaml: |
+ preflight.yaml: |-
apiVersion: troubleshoot.sh/v1beta2
kind: Preflight
metadata:
- name: preflight-sample
+ name: slackernews-preflight
spec:
collectors:
+ - clusterInfo: {}
+ - clusterResources: {}
- http:
collectorName: slack
get:
url: https://api.slack.com/methods/api.test
+ timeout: 20s
analyzers:
+ # verify that slack is accessible
- textAnalyze:
checkName: Slack Accessible
fileName: slack.json
@@ -324,41 +500,54 @@ Before you begin, ensure that you have access to a VM that meets the requirement
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:
+ 1. In the `Chart.yaml` file, increment the version to 1.0.1:
```yaml
# Chart.yaml
- version: 1.0.7
+ version: 1.0.1
```
1. Update dependencies and package the chart to a `.tgz` chart archive:
```bash
- helm package -u .
+ helm package --dependency-update .
```
- 1. Move the chart archive to the `manifests` directory:
+ 1. Move the `slackernews-1.0.1.tgz` chart archive to the `manifests` directory:
```bash
- mv gitea-1.0.7.tgz manifests
+ mv slackernews-1.0.1.tgz ../../manifests
```
- 1. In the `manifests` directory, open the KOTS HelmChart custom resource (`gitea.yaml`) and update the `chartVersion`:
+ 1. Change to the `manifests` directory.
+
+ 1. In the `manifests` directory, open the HelmChart custom resource (`slackernews.yaml`) and update the `chartVersion` to match the new archive:
```yaml
- # gitea.yaml KOTS HelmChart
- chartVersion: 1.0.7
+ # slackernews.yaml HelmChart
+ chartVersion: 1.0.1
```
- 1. Remove the chart archive for version 1.0.6 of the Gitea chart from the `manifests` directory:
+ 1. Remove the unused chart archive for version 1.0.0 from the `manifests` directory:
```
- rm gitea-1.0.6.tgz
+ rm slackernews-1.0.0.tgz
```
- 1. From the `manifests` directory, create and promote a new release, setting the version label of the release to `0.0.2`:
+ 1. From the `manifests` directory, lint the release manifests:
+
+ ```bash
+ replicated release lint --yaml-dir .
+ ```
+
+ :::note
+ If you see a `helm-archive-missing` error, confirm that you have only one chart archive in `manifests` for version 1.0.1, and that the `chartVersion` in the HelmChart resource is also set to `1.0.1`. If you notice that any of the errors are from files in your `.history/` directory, run `rm -rf .history` and then lint the files again.
+ :::
+
+ 1. Create and promote a new release, setting the version label of the release to `0.0.2`:
```bash
replicated release create --yaml-dir . --promote Unstable --version 0.0.2
@@ -378,32 +567,41 @@ Before you begin, ensure that you have access to a VM that meets the requirement
The new version is displayed automatically.
- 1. Click **Deploy** next to the new version.
+ 
- The Embedded Cluster upgrade wizard opens.
+ [View a larger version of this image](/images/quick-start-slackernews-available-updates.png)
- 1. In the Embedded Cluster upgrade wizard, on the **Preflight checks** screen, note that the "Slack Accessible" preflight check that you added was successful. Click **Next: Confirm and deploy**.
+ 1. Click **Deploy** next to the new version.
- 
+ The Embedded Cluster upgrade wizard opens. Follow the steps until you see the **Preflight checks** screen.
- [View a larger version of this image](/images/quick-start-ec-upgrade-wizard-preflight.png)
+ 1. On the **Preflight checks** screen, note that the "Slack Accessible" preflight check that you added was successful. Click **Next: Confirm and deploy**.
- :::note
- The **Config** screen in the upgrade wizard is bypassed because this release does not contain a KOTS Config custom resource. The KOTS Config custom resource is used to set up the Config screen in the KOTS Admin Console.
- :::
+ 
+
+ [View a larger version of this image](/images/quick-start-slackernews-preflight.png)
1. On the **Confirm and Deploy** page, click **Deploy**.
-1. Reset and reboot the VM to remove the installation:
+1. Clean up the installation:
- ```bash
- sudo ./APP_SLUG reset
- ```
- Where `APP_SLUG` is the unique slug for the application.
-
- :::note
- You can find the application slug by running `replicated app ls` on your local machine.
- :::
+ * If you created the VM with Compatibility Matrix, delete the VM:
+
+ ```bash
+ replicated vm rm VM_ID
+ ```
+ Where VM_ID is the ID of the VM. You can run `replicated vm ls` to get the ID.
+
+ * If you brought your own VM, use Embedded Cluster to reset and reboot the VM to remove the installation:
+
+ ```bash
+ sudo ./APP_SLUG reset
+ ```
+ Where `APP_SLUG` is the unique slug for the application.
+
+ :::note
+ You can find the application slug by running replicated app ls on your local machine.
+ :::
## Next Steps
@@ -413,7 +611,7 @@ Congratulations! As part of this quick start, you:
* Installed the release on a VM with Embedded Cluster
* Viewed telemetry for the installed instance in the Vendor Portal
* Created a new release to add preflight checks to the application
-* Updated the application from the Admin Console
+* Updated the application to the new version using Embedded Cluster
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.
@@ -423,18 +621,9 @@ To get started, see [Onboard to the Replicated Platform](replicated-onboarding).
For more information about the Replicated Platform features mentioned in this quick start, see:
-* [About Distributing Helm Charts with KOTS](/vendor/helm-native-about)
+* [Embedded Cluster Overview](/vendor/embedded-overview)
+* [About Compatibility Matrix](/vendor/testing-about)
* [About Preflight Checks and Support Bundles](/vendor/preflight-support-bundle-about)
* [About the Replicated SDK](/vendor/replicated-sdk-overview)
-* [Introduction to KOTS](/intro-kots)
-* [Managing Releases with the CLI](/vendor/releases-creating-cli)
-* [Packaging a Helm Chart for a Release](/vendor/helm-install-release)
-* [Using Embedded Cluster](/vendor/embedded-overview)
-
-## Related Tutorials
-
-For additional tutorials related to this quick start, see:
-
-* [Deploying a Helm Chart on a VM with Embedded Cluster](/vendor/tutorial-embedded-cluster-setup)
-* [Adding Preflight Checks to a Helm Chart](/vendor/tutorial-preflight-helm-setup)
-* [Deploying a Helm Chart with KOTS and the Helm CLI](/vendor/tutorial-kots-helm-setup)
\ No newline at end of file
+* [Manage Releases with the CLI](/vendor/releases-creating-cli)
+* [Package a Helm Chart for a Release](/vendor/helm-install-release)
\ No newline at end of file
diff --git a/docs/vendor/replicated-onboarding.mdx b/docs/vendor/replicated-onboarding.mdx
index 4e9ddf5d92..2d12edf2cd 100644
--- a/docs/vendor/replicated-onboarding.mdx
+++ b/docs/vendor/replicated-onboarding.mdx
@@ -254,8 +254,6 @@ To configure the KOTS Application custom resource:
The KOTS Admin Console Config screen is used to collect required and optional application configuration values from your users. User-supplied values provided on the Config screen can be mapped to your Helm values.
-Before you begin this task, you can complete the [Set Helm Values with KOTS](/vendor/tutorial-config-setup) tutorial to learn how to map user-supplied values from the Admin Console Config screen to a Helm chart.
-
:::note
Setting up the Admin Console config screen can include the use of various types of input fields, conditional statements, and KOTS template functions. Depending on your application's configuration options, Replicated recommends that you allow about two to three hours for configuring the Config custom resource and testing the Admin Console config screen.
:::
@@ -311,7 +309,6 @@ To set up the Admin Console Config screen for your application:
For more information, see:
* [Mapping User-Supplied Values](/vendor/config-screen-map-inputs)
- * [Tutorial: Set Helm Chart Values with KOTS](/vendor/tutorial-config-setup)
* [Setting Helm Values with KOTS](/vendor/helm-optional-value-keys)
* [`values`](/reference/custom-resource-helmchart-v2#values) in _HelmChart v2_
@@ -331,10 +328,6 @@ Preflight checks and support bundles analyze data from customer environments to
* **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.
-:::note
-Before you begin this task, you can complete the [Add Preflight Checks to a Helm Chart](/vendor/tutorial-preflight-helm-setup) tutorial to learn how to add a preflight spec to a Helm chart in a Kubernetes secret and run the preflight checks before installation.
-:::
-
To define preflight checks for your application:
1. In your Helm chart `templates` directory, add a Kubernetes Secret that includes a preflight spec. For more information, see [Define Preflight Checks](/vendor/preflight-defining). For examples, see [Example Preflight Specs](/vendor/preflight-examples).
@@ -452,10 +445,6 @@ To enable Helm installations for Helm charts distributed with Replicated, the on
This is the same secret that is passed to KOTS in the HelmChart custom resource using `'{{repl ImagePullSecretName }}'`, which you did as part of [Task 4: Create and Install the Initial Release](#first-release). So, whereas this Secret is created automatically for KOTS and Embedded Cluster installations, you need to create it and add it to your Helm chart for Helm installations.
-:::note
-Before you test Helm installations for your application, you can complete the [Deploy a Helm Chart with KOTS and the Helm CLI](tutorial-kots-helm-setup) tutorial to learn how to install a single release with both KOTS and Helm.
-:::
-
To support and test Helm installations:
1. Follow the steps in [Use the Proxy Registry with Helm CLI Installations](/vendor/helm-image-registry) to authenticate with the Replicated proxy registry by creating a Secret with `type: kubernetes.io/dockerconfigjson` in your Helm chart.
diff --git a/docs/vendor/tutorial-adding-db-config.md b/docs/vendor/tutorial-adding-db-config.md
index d24fa19f53..e30908a7ce 100644
--- a/docs/vendor/tutorial-adding-db-config.md
+++ b/docs/vendor/tutorial-adding-db-config.md
@@ -16,7 +16,7 @@ It is split into 5 sections:
This guide assumes you have:
-* A running instance of the Replicated Admin Console (`kotsadm`) to iterate against in either an existing cluster or an embedded cluster created with Replicated kURL. If you do not have a running instance of the Admin Console in an existing or kURL cluster, complete the [Install with KOTS in an Existing Cluster](tutorial-cli-setup) tutorial to package and install a sample application.
+* A running instance of the Replicated Admin Console (`kotsadm`) to iterate against in either an existing cluster or an embedded cluster created with Replicated kURL.
* A local git checkout of your application manifests.
### Accompanying Code Examples
diff --git a/docs/vendor/tutorial-cli-create-app.mdx b/docs/vendor/tutorial-cli-create-app.mdx
deleted file mode 100644
index abdf21d52d..0000000000
--- a/docs/vendor/tutorial-cli-create-app.mdx
+++ /dev/null
@@ -1,41 +0,0 @@
-# Step 2: Create an Application
-
-After you install the Replicated CLI and create an API token, you can use the CLI to create a new application.
-
-To create an application:
-
-1. Run the following command to create an application named `cli-tutorial`:
-
- ```
- replicated app create cli-tutorial
- ```
-
- **Example output**:
-
- ```
- ID NAME SLUG SCHEDULER
- 2GmY... cli-tutorial cli-tutorial kots
- ```
-
-1. Export the application slug in the output of the `app create` command as an environment variable:
-
- ```
- export REPLICATED_APP=YOUR_SLUG
- ```
- Replace `YOUR_SLUG` with the slug for the application you created in the previous step.
-
-1. Verify that both the `REPLICATED_API_TOKEN` environment variable that you created as part of [Step 1: Install the Replicated CLI](tutorial-cli-install-cli) and the `REPLICATED_APP` environment variable are set correctly:
-
- ```
- replicated release ls
- ```
-
- In the output of this command, you now see an empty list of releases for the application:
-
- ```
- SEQUENCE CREATED EDITED ACTIVE_CHANNELS
- ```
-
-## Next Step
-
-Continue to [Step 3: Get the Sample Manifests](tutorial-cli-manifests) to download the manifest files for a sample Kubernetes application. You will use these manifest files to create the first release for the `cli-tutorial` application.
diff --git a/docs/vendor/tutorial-cli-create-customer.mdx b/docs/vendor/tutorial-cli-create-customer.mdx
deleted file mode 100644
index 8b35eef837..0000000000
--- a/docs/vendor/tutorial-cli-create-customer.mdx
+++ /dev/null
@@ -1,106 +0,0 @@
-# Step 5: Create a Customer
-
-After promoting the first release for the `cli-tutorial` application, create a customer so that you can install the application.
-
-A _customer_ is an object in the Vendor Portal that represents a single licensed user of your application. When you create a customer, you define entitlement information for the user, and the Vendor Portal generates a YAML license file for the customer that you can download.
-
-When you install the application later in this tutorial, you will upload the license file that you create in this step to allow KOTS to create the application containers.
-
-To create a customer and download the license file:
-
-1. From the `replicated-cli-tutorial` directory, create a license for a customer named `Some-Big-Bank` that is assigned to the Unstable channel and expires in 10 days:
-
- ```
- replicated customer create \
- --name "Some-Big-Bank" \
- --expires-in "240h" \
- --channel "Unstable"
- ```
- The Unstable channel is the channel where you promoted the release in [Step 4: Create a Release](tutorial-cli-create-release). Assigning the customer to a channel allows them to install the releases that are promoted to that channel.
-
- **Example output:**
-
- ```
- ID NAME CHANNELS EXPIRES TYPE
- 2GuB3VYLjU5t9vNDK6byjgiTKUs Some-Big-Bank Unstable 2022-11-10 14:59:49 +0000 UTC dev
- ```
-
-1. Verify the customer creation details:
-
- ```
- replicated customer ls
- ```
-
- **Example output:**
-
- ```
- ID NAME CHANNELS EXPIRES TYPE
- 2GuB3VYLjU5t9vNDK6byjgiTKUs Some-Big-Bank Unstable 2022-11-10 14:59:49 +0000 UTC dev
- ```
-
-1. Download the license file for the customer that you just created:
-
- ```
- replicated customer download-license \
- --customer "Some-Big-Bank"
- ```
-
- The license downloads to `stdout`.
-
- **Example output**:
-
- ```
- apiVersion: kots.io/v1beta1
- kind: License
- metadata:
- name: some-big-bank
- spec:
- appSlug: cli-tutorial
- channelID: 2GmYFUFzj8JOSLYw0jAKKJKFua8
- channelName: Unstable
- customerName: Some-Big-Bank
- endpoint: https://replicated.app
- entitlements:
- expires_at:
- description: License Expiration
- title: Expiration
- value: "2022-11-10T14:59:49Z"
- valueType: String
- isNewKotsUiEnabled: true
- licenseID: 2GuB3ZLQsU38F5SX3n03x8qBzeL
- licenseSequence: 1
- licenseType: dev
- signature: eyJsaW...
- ```
-
-1. Rename the license file and save it to your Desktop folder:
-
- ```
- export LICENSE_FILE=~/Desktop/Some-Big-Bank-${REPLICATED_APP}-license.yaml
- replicated customer download-license --customer "Some-Big-Bank" > "${LICENSE_FILE}"
- ```
-
-1. Verify that the license was written properly using either `cat` or `head`:
-
- ```
- head ${LICENSE_FILE}
- ```
-
- **Example output**:
-
- ```
- apiVersion: kots.io/v1beta1
- kind: License
- metadata:
- name: some-big-bank
- spec:
- appSlug: cli-tutorial
- channelID: 2GmYFUFzj8JOSLYw0jAKKJKFua8
- channelName: Unstable
- customerName: Some-Big-Bank
- endpoint: https://replicated.app
- ```
-
-## Next Step
-
-Continue to [Step 6: Install KOTS and the Application](tutorial-cli-install-app-manager) to get the installation commands from the Unstable channel, then install the KOTS components and the sample application in your cluster.
diff --git a/docs/vendor/tutorial-cli-create-new-version.mdx b/docs/vendor/tutorial-cli-create-new-version.mdx
deleted file mode 100644
index 61779133fd..0000000000
--- a/docs/vendor/tutorial-cli-create-new-version.mdx
+++ /dev/null
@@ -1,139 +0,0 @@
-# Step 8: Create a New Version
-
-In this step, you make an edit to the Config custom resource manifest file in the `replicated-cli-tutorial/manifests` directory for the `cli-tutorial` application to create a new field on the **Config** page in the Admin Console. You will then create and promote a new release to the Unstable channel with your changes.
-
-To create and promote a new version of the application:
-
-1. In your local directory, go to the the `replicated-cli-tutorial/manifests` folder and open the `kots-config.yaml` file in a text editor.
-
-1. Copy and paste the following YAML into the file under the `example_default_value` field to create a new text field on the **Config** page:
-
- ```yaml
- - name: more_text
- title: Another Text Example
- type: text
- value: ""
- when: repl{{ ConfigOptionEquals "show_text_inputs" "1" }}
- ```
- The following shows the full YAML for the `kots-config.yaml` file after you add the new field:
-
- ```yaml
- ---
- apiVersion: kots.io/v1beta1
- kind: Config
- metadata:
- name: config-sample
- spec:
- groups:
- - name: example_settings
- title: My Example Config
- description: Configuration to serve as an example for creating your own. See [https://kots.io/reference/v1beta1/config/](https://kots.io/reference/v1beta1/config/) for configuration docs. In this case, we provide example fields for configuring an Nginx welcome page.
- items:
- - name: show_text_inputs
- title: Customize Text Inputs
- help_text: "Show custom user text inputs"
- type: bool
- default: "0"
- recommended: true
- - name: example_default_value
- title: Text Example (with default value)
- type: text
- value: ""
- default: please change this value
- when: repl{{ ConfigOptionEquals "show_text_inputs" "1" }}
- # Add the new more_text field here
- - name: more_text
- title: Another Text Example
- type: text
- value: ""
- when: repl{{ ConfigOptionEquals "show_text_inputs" "1" }}
- - name: api_token
- title: API token
- type: password
- props:
- rows: 5
- when: repl{{ ConfigOptionEquals "show_text_inputs" "1" }}
- - name: readonly_text_left
- title: Readonly Text
- type: text
- value: "{{repl RandomString 10}}"
- readonly: true
- when: repl{{ ConfigOptionEquals "show_text_inputs" "1" }}
- - name: hidden_text
- title: Secret Key
- type: password
- hidden: true
- value: "{{repl RandomString 40}}"
-
- ```
-
-1. Open the `example-configmap.yaml` file.
-
-1. In the `example-configmap.yaml` file, copy and paste the following HTML to replace the `` section:
-
- ```
-
- This is an example KOTS application.
- This is text from a user config value: '{{repl ConfigOption "example_default_value"}}'
-This is more text from a user config value: '{{repl ConfigOption "more_text"}}'
-This is a hidden value: '{{repl ConfigOption "hidden_text"}}'
- - ``` - This creates a reference to the `more_text` field using a Replicated KOTS template function. The ConfigOption template function renders the user input from the configuration item that you specify. For more information, see [Config Context](/reference/template-functions-config-context) in _Reference_. - -1. Save the changes to both YAML files. - -1. Change to the root `replicated-cli-tutorial` directory, then run the following command to verify that there are no errors in the YAML: - - ``` - replicated release lint --yaml-dir=manifests - ``` - -1. Create a new release and promote it to the Unstable channel: - - ``` - replicated release create --auto - ``` - - **Example output**: - - ``` - • Reading manifests from ./manifests ✓ - • Creating Release ✓ - • SEQUENCE: 2 - • Promoting ✓ - • Channel 2GxpUm7lyB2g0ramqUXqjpLHzK0 successfully set to release 2 - ``` - -1. Type `y` and press **Enter** to continue with the defaults. - - **Example output**: - - ``` - RULE TYPE FILENAME LINE MESSAGE - - • Reading manifests from ./manifests ✓ - • Creating Release ✓ - • SEQUENCE: 2 - • Promoting ✓ - • Channel 2GmYFUFzj8JOSLYw0jAKKJKFua8 successfully set to release 2 - ``` - - The release is created and promoted to the Unstable channel with `SEQUENCE: 2`. - -1. Verify that the release was promoted to the Unstable channel: - - ``` - replicated release ls - ``` - **Example output**: - - ``` - SEQUENCE CREATED EDITED ACTIVE_CHANNELS - 2 2022-11-03T19:16:24Z 0001-01-01T00:00:00Z Unstable - 1 2022-11-03T18:49:13Z 0001-01-01T00:00:00Z - ``` - -## Next Step - -Continue to [Step 9: Update the Application](tutorial-cli-update-app) to return to the Admin Console and update the application to the new version that you promoted. diff --git a/docs/vendor/tutorial-cli-create-release.mdx b/docs/vendor/tutorial-cli-create-release.mdx deleted file mode 100644 index 142db61b77..0000000000 --- a/docs/vendor/tutorial-cli-create-release.mdx +++ /dev/null @@ -1,85 +0,0 @@ -# Step 4: Create a Release - -Now that you have the manifest files for the sample Kubernetes application, you can create a release for the `cli-tutorial` application and promote the release to the Unstable channel. - -By default, the Vendor Portal includes Unstable, Beta, and Stable release channels. The Unstable channel is intended for software vendors to use for internal testing, before promoting a release to the Beta or Stable channels for distribution to customers. For more information about channels, see [About Channels and Releases](releases-about). - -To create and promote a release to the Unstable channel: - -1. From the `replicated-cli-tutorial` directory, lint the application manifest files and ensure that there are no errors in the YAML: - - ``` - replicated release lint --yaml-dir=manifests - ``` - - If there are no errors, an empty list is displayed with a zero exit code: - - ```text - RULE TYPE FILENAME LINE MESSAGE - ``` - - For a complete list of the possible error, warning, and informational messages that can appear in the output of the `release lint` command, see [Linter Rules](/reference/linter). - -1. Initialize the project as a Git repository: - - ``` - git init - git add . - git commit -m "Initial Commit: CLI Tutorial" - ``` - - Initializing the project as a Git repository allows you to track your history. The Replicated CLI also reads Git metadata to help with the generation of release metadata, such as version labels. - -1. From the `replicated-cli-tutorial` directory, create a release with the default settings: - - ``` - replicated release create --auto - ``` - - The `--auto` flag generates release notes and metadata based on the Git status. - - **Example output:** - - ``` - • Reading Environment ✓ - - Prepared to create release with defaults: - - yaml-dir "./manifests" - promote "Unstable" - version "Unstable-ba710e5" - release-notes "CLI release of master triggered by exampleusername [SHA: d4173a4] [31 Oct 22 08:51 MDT]" - ensure-channel true - lint-release true - - Create with these properties? [Y/n] - ``` - -1. Type `y` and press **Enter** to confirm the prompt. - - **Example output:** - - ```text - • Reading manifests from ./manifests ✓ - • Creating Release ✓ - • SEQUENCE: 1 - • Promoting ✓ - • Channel VEr0nhJBBUdaWpPvOIK-SOryKZEwa3Mg successfully set to release 1 - ``` - The release is created and promoted to the Unstable channel. - -1. Verify that the release was promoted to the Unstable channel: - - ``` - replicated release ls - ``` - **Example output:** - - ```text - SEQUENCE CREATED EDITED ACTIVE_CHANNELS - 1 2022-10-31T14:55:35Z 0001-01-01T00:00:00Z Unstable - ``` - -## Next Step - -Continue to [Step 5: Create a Customer](tutorial-cli-create-customer) to create a customer license file that you will upload when installing the application. diff --git a/docs/vendor/tutorial-cli-deploy-app.mdx b/docs/vendor/tutorial-cli-deploy-app.mdx deleted file mode 100644 index 14fbb7d146..0000000000 --- a/docs/vendor/tutorial-cli-deploy-app.mdx +++ /dev/null @@ -1,47 +0,0 @@ -# Step 7: Configure the Application - -After you install KOTS, you can log in to the KOTS Admin Console. This procedure shows you how to make a configuration change for the application from the Admin Console, which is a typical task performed by end users. - -To configure the application: - -1. Access the Admin Console using `https://localhost:8800` if the installation script is still running. Otherwise, run the following command to access the Admin Console: - - ```bash - kubectl kots admin-console --namespace NAMESPACE - ``` - - Replace `NAMESPACE` with the namespace where KOTS is installed. - -1. Enter the password that you created in [Step 6: Install KOTS and the Application](tutorial-cli-install-app-manager) to log in to the Admin Console. - - The Admin Console dashboard opens. On the Admin Console **Dashboard** tab, users can take various actions, including viewing the application status, opening the application, checking for application updates, syncing their license, and setting up application monitoring on the cluster with Prometheus. - -  - -1. On the **Config** tab, select the **Customize Text Inputs** checkbox. In the **Text Example** field, enter any text. For example, `Hello`. - -  - - This page displays configuration settings that are specific to the application. Software vendors define the fields that are displayed on this page in the KOTS Config custom resource. For more information, see [Config](/reference/custom-resource-config) in _Reference_. - -1. Click **Save config**. In the dialog that opens, click **Go to updated version**. - - The **Version history** tab opens. - -1. Click **Deploy** for the new version. Then click **Yes, deploy** in the confirmation dialog. - -  - -1. Click **Open App** to view the application in your browser. - -  - - Notice the text that you entered previously on the configuration page is displayed on the screen. - - :::note - If you do not see the new text, refresh your browser. - ::: - -## Next Step - -Continue to [Step 8: Create a New Version](tutorial-cli-create-new-version) to make a change to one of the manifest files for the `cli-tutorial` application, then use the Replicated CLI to create and promote a new release. diff --git a/docs/vendor/tutorial-cli-install-app-manager.mdx b/docs/vendor/tutorial-cli-install-app-manager.mdx deleted file mode 100644 index 2838c93385..0000000000 --- a/docs/vendor/tutorial-cli-install-app-manager.mdx +++ /dev/null @@ -1,101 +0,0 @@ -# Step 6: Install KOTS and the Application - -The next step is to test the installation process for the application release that you promoted. Using the KOTS CLI, you will install KOTS and the sample application in your cluster. - -KOTS is the Replicated component that allows your users to install, manage, and upgrade your application. Users can interact with KOTS through the Admin Console or through the KOTS CLI. - -To install KOTS and the application: - -1. From the `replicated-cli-tutorial` directory, run the following command to get the installation commands for the Unstable channel, where you promoted the release for the `cli-tutorial` application: - - ``` - replicated channel inspect Unstable - ``` - - **Example output:** - - ``` - ID: 2GmYFUFzj8JOSLYw0jAKKJKFua8 - NAME: Unstable - DESCRIPTION: - RELEASE: 1 - VERSION: Unstable-d4173a4 - EXISTING: - - curl -fsSL https://kots.io/install | bash - kubectl kots install cli-tutorial/unstable - - EMBEDDED: - - curl -fsSL https://k8s.kurl.sh/cli-tutorial-unstable | sudo bash - - AIRGAP: - - curl -fSL -o cli-tutorial-unstable.tar.gz https://k8s.kurl.sh/bundle/cli-tutorial-unstable.tar.gz - # ... scp or sneakernet cli-tutorial-unstable.tar.gz to airgapped machine, then - tar xvf cli-tutorial-unstable.tar.gz - sudo bash ./install.sh airgap - ``` - This command prints information about the channel, including the commands for installing in: - * An existing cluster - * An _embedded cluster_ created by Replicated kURL - * An air gap cluster that is not connected to the internet - -1. If you have not already, configure kubectl access to the cluster you provisioned as part of [Set Up the Environment](tutorial-cli-setup#set-up-the-environment). For more information about setting the context for kubectl, see [Command line tool (kubectl)](https://kubernetes.io/docs/reference/kubectl/) in the Kubernetes documentation. - -1. Run the `EXISTING` installation script with the following flags to automatically upload the license file and run the preflight checks at the same time you run the installation. - - **Example:** - - ``` - curl -fsSL https://kots.io/install | bash - kubectl kots install cli-tutorial/unstable \ - --license-file ./LICENSE_YAML \ - --shared-password PASSWORD \ - --namespace NAMESPACE - ``` - - Replace: - - - `LICENSE_YAML` with the local path to your license file. - - `PASSWORD` with a password to access the Admin Console. - - `NAMESPACE` with the namespace where KOTS and application will be installed. - - When the Admin Console is ready, the script prints the `https://localhost:8800` URL where you can access the Admin Console and the `http://localhost:8888` URL where you can access the application. - - **Example output**: - - ``` - • Deploying Admin Console - • Creating namespace ✓ - • Waiting for datastore to be ready ✓ - • Waiting for Admin Console to be ready ✓ - • Waiting for installation to complete ✓ - • Waiting for preflight checks to complete ✓ - - • Press Ctrl+C to exit - • Go to http://localhost:8800 to access the Admin Console - - • Go to http://localhost:8888 to access the application - ``` - -1. Verify that the Pods are running for the example NGNIX service and for kotsadm: - - ```bash - kubectl get pods --namespace NAMESPACE - ``` - - Replace `NAMESPACE` with the namespace where KOTS and application was installed. - - **Example output:** - - ```NAME READY STATUS RESTARTS AGE - kotsadm-7ccc8586b8-n7vf6 1/1 Running 0 12m - kotsadm-minio-0 1/1 Running 0 17m - kotsadm-rqlite-0 1/1 Running 0 17m - nginx-688f4b5d44-8s5v7 1/1 Running 0 11m - ``` - -## Next Step - -Continue to [Step 7: Configure the Application](tutorial-cli-deploy-app) to log in to the Admin Console and make configuration changes. diff --git a/docs/vendor/tutorial-cli-install-cli.mdx b/docs/vendor/tutorial-cli-install-cli.mdx deleted file mode 100644 index 1eb0f60aea..0000000000 --- a/docs/vendor/tutorial-cli-install-cli.mdx +++ /dev/null @@ -1,80 +0,0 @@ -# Step 1: Install the Replicated CLI - -In this tutorial, you use the Replicated CLI to create and promote releases for a sample application with Replicated. The Replicated CLI is the CLI for the Replicated Vendor Portal. - -This procedure describes how to create a Vendor Portal account, install the Replicated CLI on your local machine, and set up a `REPLICATED_API_TOKEN` environment variable for authentication. - -To install the Replicated CLI: - -1. Do one of the following to create an account in the Replicated Vendor Portal: - * **Join an existing team**: If you have an existing Vendor Portal team, you can ask your team administrator to send you an invitation to join. - * **Start a trial**: Alternatively, go to [vendor.replicated.com](https://vendor.replicated.com/) and click **Sign up** to create a 21-day trial account for completing this tutorial. - -1. Run the following command to use [Homebrew](https://brew.sh) to install the CLI: - - ``` - brew install replicatedhq/replicated/cli - ``` - - For the latest Linux or macOS versions of the Replicated CLI, see the [replicatedhq/replicated](https://github.com/replicatedhq/replicated/releases) releases in GitHub. - -1. Verify the installation: - - ``` - replicated version - ``` - **Example output**: - - ```json - { - "version": "0.37.2", - "git": "8664ac3", - "buildTime": "2021-08-24T17:05:26Z", - "go": { - "version": "go1.14.15", - "compiler": "gc", - "os": "darwin", - "arch": "amd64" - } - } - ``` - If you run a Replicated CLI command, such as `replicated release ls`, you see the following error message about a missing API token: - - ``` - Error: set up APIs: Please provide your API token - ``` - -1. Create an API token for the Replicated CLI: - - 1. Log in to the Vendor Portal, and go to the [Account settings](https://vendor.replicated.com/account-settings) page. - - 1. Under **User API Tokens**, click **Create user API token**. For Nickname, provide a name for the token. For Permissions, select **Read and Write**. - - For more information about User API tokens, see [User API Tokens](replicated-api-tokens#user-api-tokens) in _Generating API Tokens_. - - 1. Click **Create Token**. - - 1. Copy the string that appears in the dialog. - -1. Export the string that you copied in the previous step to an environment variable named `REPLICATED_API_TOKEN`: - - ```bash - export REPLICATED_API_TOKEN=YOUR_TOKEN - ``` - Replace `YOUR_TOKEN` with the token string that you copied from the Vendor Portal in the previous step. - -1. Verify the User API token: - - ``` - replicated release ls - ``` - - You see the following error message: - - ``` - Error: App not found: - ``` - -## Next Step - -Continue to [Step 2: Create an Application](tutorial-cli-create-app) to use the Replicated CLI to create an application. diff --git a/docs/vendor/tutorial-cli-manifests.mdx b/docs/vendor/tutorial-cli-manifests.mdx deleted file mode 100644 index 84d15ba90c..0000000000 --- a/docs/vendor/tutorial-cli-manifests.mdx +++ /dev/null @@ -1,35 +0,0 @@ -# Step 3: Get the Sample Manifests - -To create a release for the `cli-tutorial` application, first create the Kubernetes manifest files for the application. This tutorial provides a set of sample manifest files for a simple Kubernetes application that deploys an NGINX service. - -To get the sample manifest files: - -1. Run the following command to create and change to a `replicated-cli-tutorial` directory: - - ``` - mkdir replicated-cli-tutorial - cd replicated-cli-tutorial - ``` - -1. Create a `/manifests` directory and download the sample manifest files from the [kots-default-yaml](https://github.com/replicatedhq/kots-default-yaml) repository in GitHub: - - ``` - mkdir ./manifests - curl -fSsL https://github.com/replicatedhq/kots-default-yaml/archive/refs/heads/main.zip | \ - tar xzv --strip-components=1 -C ./manifests \ - --exclude README.md --exclude LICENSE --exclude .gitignore - ``` - -1. Verify that you can see the YAML files in the `replicated-cli-tutorial/manifests` folder: - - ``` - ls manifests/ - ``` - ``` - example-configmap.yaml example-service.yaml kots-app.yaml kots-lint-config.yaml kots-support-bundle.yaml - example-deployment.yaml k8s-app.yaml kots-config.yaml kots-preflight.yaml - ``` - -## Next Step - -Continue to [Step 4: Create a Release](tutorial-cli-create-release) to create and promote the first release for the `cli-tutorial` application using these manifest files. diff --git a/docs/vendor/tutorial-cli-setup.mdx b/docs/vendor/tutorial-cli-setup.mdx deleted file mode 100644 index a96155a59b..0000000000 --- a/docs/vendor/tutorial-cli-setup.mdx +++ /dev/null @@ -1,35 +0,0 @@ -import KubernetesTraining from "../partials/getting-started/_kubernetes-training.mdx" -import LabsIntro from "../partials/getting-started/_labs-intro.mdx" -import TutorialIntro from "../partials/getting-started/_tutorial-intro.mdx" -import RelatedTopics from "../partials/getting-started/_related-topics.mdx" -import VMRequirements from "../partials/getting-started/_vm-requirements.mdx" - -# Introduction and Setup - -Description
-The KOTS Application custom resource enables features in the Admin Console such as branding, release notes, port forwarding, dashboard buttons, application status indicators, and custom graphs.
The YAML below provides a name for the application to display in the Admin Console, adds a custom status informer that displays the status of the grafana Deployment resource in the Admin Console dashboard, adds a custom application icon, and creates a port forward so that the user can open the Grafana application in a browser.
YAML
-Description
-The Kubernetes Application custom resource supports functionality such as including buttons and links on the Admin Console dashboard. The YAML below adds an Open App button to the Admin Console dashboard that opens the application using the port forward configured in the KOTS Application custom resource.
-YAML
-Description
-The Config custom resource specifies a user-facing configuration page in the Admin Console designed for collecting application configuration from users. The YAML below creates "Admin User" and "Admin Password" fields that will be shown to the user on the configuration page during installation. These fields will be used to set the login credentials for Grafana.
-YAML
-Description
-The KOTS HelmChart custom resource provides instructions to KOTS about how to deploy the Helm chart.
-The HelmChart custom resource below contains a values key, which creates a mapping to the Grafana values.yaml file. In this case, the values.admin.user and values.admin.password fields map to admin.user and admin.password in the Grafana values.yaml file.
During installation, KOTS renders the ConfigOption template functions in the values.admin.user and values.admin.password fields and then sets the corresponding Grafana values accordingly.
YAML
-
-
- [View a larger version of this image](/images/release-promote.png)
-
-## Next Step
-
-Create a customer with the KOTS entitlement so that you can install the release in your cluster using Replicated KOTS. See [Step 5: Create a KOTS-Enabled Customer](tutorial-config-create-customer).
-
-## Related Topics
-
-* [About Channels and Releases](/vendor/releases-about)
-* [Configuring the HelmChart Custom Resource](/vendor/helm-native-v2-using)
-* [Config Custom Resource](/reference/custom-resource-config)
-* [Manipulating Helm Chart Values with KOTS](/vendor/helm-optional-value-keys)
\ No newline at end of file
diff --git a/docs/vendor/tutorial-config-get-chart.md b/docs/vendor/tutorial-config-get-chart.md
deleted file mode 100644
index 7fb34a7821..0000000000
--- a/docs/vendor/tutorial-config-get-chart.md
+++ /dev/null
@@ -1,119 +0,0 @@
-# Step 1: Get the Sample Chart and Test
-
-To begin, get the sample Grafana Helm chart from Bitnami, install the chart in your cluster using the Helm CLI, and then uninstall. The purpose of this step is to confirm that you can successfully install and access the application before adding the chart to a release in the Replicated vendor platform.
-
-To get the sample Grafana chart and test installation:
-
-1. Run the following command to pull and untar version 9.6.5 of the Bitnami Grafana Helm chart:
-
- ```
- helm pull --untar oci://registry-1.docker.io/bitnamicharts/grafana --version 9.6.5
- ```
- For more information about this chart, see the [bitnami/grafana](https://github.com/bitnami/charts/tree/main/bitnami/grafana) repository in GitHub.
-
-1. Change to the new `grafana` directory that was created:
- ```
- cd grafana
- ```
-1. View the files in the directory:
- ```
- ls
- ```
- The directory contains the following files:
- ```
- Chart.lock Chart.yaml README.md charts templates values.yaml
- ```
-1. Install the chart in your cluster:
-
- ```
- helm install grafana . --namespace grafana --create-namespace
- ```
- To view the full installation instructions from Bitnami, see [Installing the Chart](https://github.com/bitnami/charts/blob/main/bitnami/grafana/README.md#installing-the-chart) in the `bitnami/grafana` repository.
-
- After running the installation command, the following output is displayed:
-
- ```
- NAME: grafana
- LAST DEPLOYED: Thu Dec 14 14:54:50 2023
- NAMESPACE: grafana
- STATUS: deployed
- REVISION: 1
- TEST SUITE: None
- NOTES:
- CHART NAME: grafana
- CHART VERSION: 9.6.5
- APP VERSION: 10.2.2
-
- ** Please be patient while the chart is being deployed **
-
- 1. Get the application URL by running these commands:
- echo "Browse to http://127.0.0.1:8080"
- kubectl port-forward svc/grafana 8080:3000 &
-
- 2. Get the admin credentials:
-
- echo "User: admin"
- echo "Password: $(kubectl get secret grafana-admin --namespace grafana -o jsonpath="{.data.GF_SECURITY_ADMIN_PASSWORD}" | base64 -d)"
- # Note: Do not include grafana.validateValues.database here. See https://github.com/bitnami/charts/issues/20629
- ```
-
-1. Watch the `grafana` Deployment until it is ready:
-
- ```
- kubectl get deploy grafana --namespace grafana --watch
- ```
-
-1. When the Deployment is created, run the commands provided in the output of the installation command to get the Grafana login credentials:
-
- ```
- echo "User: admin"
- echo "Password: $(kubectl get secret grafana-admin --namespace grafana -o jsonpath="{.data.GF_SECURITY_ADMIN_PASSWORD}" | base64 -d)"
- ```
-
-1. Run the commands provided in the ouptut of the installation command to get the Grafana URL:
-
- ```
- echo "Browse to http://127.0.0.1:8080"
- kubectl port-forward svc/grafana 8080:3000 --namespace grafana
- ```
-
- :::note
- Include `--namespace grafana` in the `kubectl port-forward` command.
- :::
-
-1. In a browser, go to the URL to open the Grafana login page:
-
- 
-
- [View a larger version of this image](/images/grafana-login.png)
-
-1. Log in using the credentials provided to open the Grafana dashboard:
-
- 
-
- [View a larger version of this image](/images/grafana-dashboard.png)
-
-1. Uninstall the Helm chart:
-
- ```
- helm uninstall grafana --namespace grafana
- ```
- This command removes all the Kubernetes resources associated with the chart and uninstalls the `grafana` release.
-
-1. Delete the namespace:
-
- ```
- kubectl delete namespace grafana
- ```
-
-## Next Step
-
-Log in to the Vendor Portal and create an application. See [Step 2: Create an Application](tutorial-config-create-app).
-
-## Related Topics
-
-* [Helm Install](https://helm.sh/docs/helm/helm_install/)
-* [Helm Uninstall](https://helm.sh/docs/helm/helm_uninstall/)
-* [Helm Create](https://helm.sh/docs/helm/helm_create/)
-* [Helm Package](https://helm.sh/docs/helm/helm_package/)
-* [bitnami/gitea](https://github.com/bitnami/charts/blob/main/bitnami/gitea)
\ No newline at end of file
diff --git a/docs/vendor/tutorial-config-install-kots.md b/docs/vendor/tutorial-config-install-kots.md
deleted file mode 100644
index fdb07531d6..0000000000
--- a/docs/vendor/tutorial-config-install-kots.md
+++ /dev/null
@@ -1,153 +0,0 @@
-# Step 6: Install the Release with KOTS
-
-Next, get the KOTS installation command from the Unstable channel in the Vendor Portal and then install the release using the customer license that you downloaded.
-
-As part of installation, you will set Grafana login credentials on the KOTS Admin Console configuration page.
-
-To install the release with KOTS:
-
-1. In the [Vendor Portal](https://vendor.replicated.com), go to **Channels**. From the **Unstable** channel card, under **Install**, copy the **KOTS Install** command.
-
- 
-
- [View a larger version of this image](/images/grafana-unstable-channel.png)
-
-1. On the command line, run the **KOTS Install** command that you copied:
-
- ```bash
- curl https://kots.io/install | bash
- kubectl kots install $REPLICATED_APP/unstable
- ```
-
- This installs the latest version of the KOTS CLI and the Admin Console. The Admin Console provides a user interface where you can upload the customer license file and deploy the application.
-
- For additional KOTS CLI installation options, including how to install without root access, see [Installing the KOTS CLI](/reference/kots-cli-getting-started).
-
- :::note
- KOTS v1.104.0 or later is required to deploy the Replicated SDK. You can verify the version of KOTS installed with `kubectl kots version`.
- :::
-
-1. Complete the installation command prompts:
-
- 1. For `Enter the namespace to deploy to`, enter `grafana`.
-
- 1. For `Enter a new password to be used for the Admin Console`, provide a password to access the Admin Console.
-
- When the Admin Console is ready, the command prints the URL where you can access the Admin Console. At this point, the KOTS CLI is installed and the Admin Console is running, but the application is not yet deployed.
-
- **Example output:**
-
- ```bash
- Enter the namespace to deploy to: grafana
- • Deploying Admin Console
- • Creating namespace ✓
- • Waiting for datastore to be ready ✓
- Enter a new password for the Admin Console (6+ characters): ••••••••
- • Waiting for Admin Console to be ready ✓
-
- • Press Ctrl+C to exit
- • Go to http://localhost:8800 to access the Admin Console
- ```
-
-1. With the port forward running, go to `http://localhost:8800` in a browser to access the Admin Console.
-
-1. On the login page, enter the password that you created for the Admin Console.
-
-1. On the license page, select the license file that you downloaded previously and click **Upload license**.
-
-1. On the **Configure Grafana** page, enter a username and password. You will use these credentials to log in to Grafana.
-
- 
-
- [View a larger version of this image](/images/grafana-config.png)
-
-1. Click **Continue**.
-
- The Admin Console dashboard opens. The application status changes from Missing to Unavailable while the `grafana` Deployment is being created.
-
- 
-
- [View a larger version of this image](/images/grafana-unavailable.png)
-
-1. On the command line, press Ctrl+C to exit the port forward.
-
-1. Watch for the `grafana` Deployment to become ready:
-
- ```
- kubectl get deploy grafana --namespace grafana --watch
- ```
-
-1. After the Deployment is ready, run the following command to confirm that the `grafana-admin` Secret was updated with the new password that you created on the **Configure Grafana** page:
-
- ```
- echo "Password: $(kubectl get secret grafana-admin --namespace grafana -o jsonpath="{.data.GF_SECURITY_ADMIN_PASSWORD}" | base64 -d)"
- ```
-
- The ouput of this command displays the password that you created.
-
-1. Start the port foward again to access the Admin Console:
-
- ```
- kubectl kots admin-console --namespace grafana
- ```
-
-1. Go to `http://localhost:8800` to open the Admin Console.
-
- On the Admin Console dashboard, the application status is now displayed as Ready:
-
- 
-
- [View a larger version of this image](/images/grafana-ready.png)
-
-1. Click **Open App** to open the Grafana login page in a browser.
-
-
-
- [View a larger version of this image](/images/grafana-login.png)
-
-1. On the Grafana login page, enter the username and password that you created on the **Configure Grafana** page. Confirm that you can log in to the application to access the Grafana dashboard:
-
-
-
- [View a larger version of this image](/images/grafana-dashboard.png)
-
-1. On the command line, press Ctrl+C to exit the port forward.
-
-1. Uninstall the Grafana application from your cluster:
-
- ```bash
- kubectl kots remove $REPLICATED_APP --namespace grafana --undeploy
- ```
- **Example output**:
- ```
- • Removing application grafana-python reference from Admin Console and deleting associated resources from the cluster ✓
- • Application grafana-python has been removed
- ```
-
-1. Remove the Admin Console from the cluster:
-
- 1. Delete the namespace where the Admin Console is installed:
-
- ```
- kubectl delete namespace grafana
- ```
- 1. Delete the Admin Console ClusterRole and ClusterRoleBinding:
-
- ```
- kubectl delete clusterrole kotsadm-role
- ```
- ```
- kubectl delete clusterrolebinding kotsadm-rolebinding
- ```
-
-## Next Step
-
-Congratulations! As part of this tutorial, you used the KOTS Config custom resource to define a configuration page in the Admin Console. You also used the KOTS HelmChart custom resource and KOTS ConfigOption template function to override the default Grafana login credentials with a user-supplied username and password.
-
-To learn more about how to customize the Config custom resource to create configuration fields for your application, see [Config](/reference/custom-resource-config).
-
-## Related Topics
-
-* [kots install](/reference/kots-cli-install/)
-* [Install the KOTS CLI](/reference/kots-cli-getting-started/)
-* [Delete the Admin Console and Remove Applications](/enterprise/delete-admin-console)
diff --git a/docs/vendor/tutorial-config-package-chart.md b/docs/vendor/tutorial-config-package-chart.md
deleted file mode 100644
index eb29af6125..0000000000
--- a/docs/vendor/tutorial-config-package-chart.md
+++ /dev/null
@@ -1,30 +0,0 @@
-import DependencyYaml from "../partials/replicated-sdk/_dependency-yaml.mdx"
-import UnauthorizedError from "../partials/replicated-sdk/_401-unauthorized.mdx"
-
-# Step 3: Package the Helm Chart
-
-Next, add the Replicated SDK as a dependency of the Helm chart and then package the chart into a `.tgz` archive. The purpose of this step is to prepare the Helm chart to be added to a release.
-
-To add the Replicated SDK and package the Helm chart:
-
-1. In your local file system, go to the `grafana` directory that was created as part of [Step 1: Get the Sample Chart and Test](tutorial-config-get-chart).
-
-1. In the `Chart.yaml` file, add the Replicated SDK as a dependency:
-
- Description
-The KOTS HelmChart custom resource provides instructions to KOTS about how to deploy the Helm chart. The name and chartVersion listed in the HelmChart custom resource must match the name and version of a Helm chart archive in the release. The optionalValues field sets the specified Helm values when a given conditional statement evaluates to true. In this case, if the application is installed with Embedded Cluster, then the Gitea service type is set to `NodePort` and the node port is set to `"32000"`. This will allow Gitea to be accessed from the local machine after deployment.
YAML
-Description
-The KOTS Application custom resource enables features in the Replicated Admin Console such as branding, release notes, application status indicators, and custom graphs.
The YAML below provides a name for the application to display in the Admin Console, adds a custom status informer that displays the status of the gitea Deployment resource in the Admin Console dashboard, adds a custom application icon, and adds the port where the Gitea service can be accessed so that the user can open the application after installation.
YAML
-Description
-The Kubernetes Application custom resource supports functionality such as including buttons and links on the Replicated Admin Console dashboard. The YAML below adds an Open App button to the Admin Console dashboard that opens the application using the service port defined in the KOTS Application custom resource.
-YAML
-Description
-To install your application with Embedded Cluster, an Embedded Cluster Config must be present in the release. At minimum, the Embedded Cluster Config sets the version of Embedded Cluster that will be installed. You can also define several characteristics about the cluster.
-YAML
-
-
- [View a larger version of this image](/images/release-promote.png)
-
-## Next Step
-
-Create a customer with the Embedded Cluster entitlement so that you can install the release using Embedded Cluster. See [Step 4: Create an Embedded Cluster-Enabled Customer](tutorial-embedded-cluster-create-customer).
-
-## Related Topics
-
-* [About Channels and Releases](/vendor/releases-about)
-* [Configuring the HelmChart Custom Resource](/vendor/helm-native-v2-using)
-* [Embedded Cluster Config](/reference/embedded-config)
-* [Setting Helm Values with KOTS](/vendor/helm-optional-value-keys)
\ No newline at end of file
diff --git a/docs/vendor/tutorial-embedded-cluster-install.mdx b/docs/vendor/tutorial-embedded-cluster-install.mdx
deleted file mode 100644
index f33f1b01d2..0000000000
--- a/docs/vendor/tutorial-embedded-cluster-install.mdx
+++ /dev/null
@@ -1,111 +0,0 @@
-import KotsVerReq from "../partials/replicated-sdk/_kots-version-req.mdx"
-
-# Step 5: Install the Release on a VM
-
-Next, get the customer-specific Embedded Cluster installation commands and then install the release on a Linux VM.
-
-To install the release with Embedded Cluster:
-
-1. In the [Vendor Portal](https://vendor.replicated.com), go to **Customers**. Click on the name of the customer you created.
-
-1. Click **Install instructions > Embedded cluster**.
-
- 
-
- [View a larger version of this image](/images/customer-install-instructions-dropdown.png)
-
- The **Embedded cluster install instructions** dialog opens.
-
-
-
- [View a larger version of this image](/images/embedded-cluster-install-dialog-latest.png)
-
-1. On the command line, SSH onto your Linux VM.
-
-1. Run the first command in the **Embedded cluster install instructions** dialog to download the latest release.
-
-1. Run the second command to extract the release.
-
-1. Run the third command to install the release.
-
-1. When prompted, enter a password for accessing the KOTS Admin Console.
-
- The installation command takes a few minutes to complete.
-
-1. When the installation command completes, go to the URL provided in the output to log in to the Admin Console.
-
- **Example output:**
-
- ```bash
- ✔ Host files materialized
- ? Enter an Admin Console password: ********
- ? Confirm password: ********
- ✔ Node installation finished
- ✔ Storage is ready!
- ✔ Embedded Cluster Operator is ready!
- ✔ Admin Console is ready!
- ✔ Finished!
- Visit the admin console to configure and install gitea-kite: http://104.155.145.60:30000
- ```
-
- At this point, the cluster is provisioned and the KOTS Admin Console is deployed, but the application is not yet installed.
-
-1. Bypass the browser TLS warning by clicking **Continue to Setup**.
-
-1. Click **Advanced > Proceed**.
-
-1. On the **HTTPS for the Gitea Admin Console** page, select **Self-signed** and click **Continue**.
-
-1. On the login page, enter the Admin Console password that you created during installation and click **Log in**.
-
-1. On the **Nodes** page, you can view details about the VM where you installed, including its node role, status, CPU, and memory. Users can also optionally add additional nodes on this page before deploying the application. Click **Continue**.
-
- The Admin Console dashboard opens.
-
-1. In the **Version** section, for version `0.1.0`, click **Deploy** then **Yes, Deploy**.
-
- The application status changes from Missing to Unavailable while the `gitea` Deployment is being created.
-
-1. After a few minutes when the application status is Ready, click **Open App** to view the Gitea application in a browser:
-
- 
-
- [View a larger version of this image](/images/gitea-ec-ready.png)
-
-
-
- [View a larger version of this image](/images/gitea-app.png)
-
-1. In another browser window, open the [Vendor Portal](https://vendor.replicated.com/) and go to **Customers**. Select the customer that you created.
-
- On the **Reporting** page for the customer, you can see details about the customer's license and installed instances:
-
- 
-
- [View a larger version of this image](/images/gitea-customer-reporting-ec.png)
-
-1. On the **Reporting** page, under **Instances**, click on the instance that you just installed to open the instance details page.
-
- On the instance details page, you can see additional insights such as the version of Embedded Cluster that is running, instance status and uptime, and more:
-
- 
-
- [View a larger version of this image](/images/gitea-instance-insights-ec.png)
-
-1. (Optional) Reset the node to remove the cluster and the application from the node. This is useful for iteration and development so that you can reset a machine and reuse it instead of having to procure another machine.
-
- ```bash
- sudo ./APP_SLUG reset --reboot
- ```
- Where `APP_SLUG` is the unique slug for the application that you created. You can find the appication slug by running `replicated app ls` on the command line on your local machine.
-
-## Summary
-
-Congratulations! As part of this tutorial, you created a release in the Replicated Vendor Portal and installed the release with Replicated Embedded Cluster in a VM. To learn more about Embedded Cluster, see [Embedded Cluster Overview](embedded-overview).
-
-## Related Topics
-
-* [Embedded Cluster Overview](embedded-overview)
-* [Customer Reporting](/vendor/customer-reporting)
-* [Instance Details](/vendor/instance-insights-details)
-* [Reset a Node](/vendor/embedded-using#reset-a-node)
\ No newline at end of file
diff --git a/docs/vendor/tutorial-embedded-cluster-package-chart.mdx b/docs/vendor/tutorial-embedded-cluster-package-chart.mdx
deleted file mode 100644
index ab50d16d32..0000000000
--- a/docs/vendor/tutorial-embedded-cluster-package-chart.mdx
+++ /dev/null
@@ -1,51 +0,0 @@
-import DependencyYaml from "../partials/replicated-sdk/_dependency-yaml.mdx"
-import UnauthorizedError from "../partials/replicated-sdk/_401-unauthorized.mdx"
-
-# Step 2: Package the Gitea Helm Chart
-
-Next, get the sample Gitea Helm chart from Bitnami. Add the Replicated SDK as a dependency of the chart, then package the chart into a `.tgz` archive. The purpose of this step is to prepare the Helm chart to be added to a release.
-
-The Replicated SDK is a Helm chart that can be optionally added as a dependency of your application Helm chart. The SDK is installed as a small service running alongside your application, and provides an in-cluster API that you can use to embed Replicated features into your application. Additionally, the Replicated SDK provides access to insights and telemetry for instances of your application installed with the Helm CLI.
-
-To add the Replicated SDK and package the Helm chart:
-
-1. Run the following command to pull and untar version 1.0.6 of the Bitnami Gitea Helm chart:
-
- ```
- 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.
-
-1. Change to the new `gitea` directory that was created:
- ```
- cd gitea
- ```
-1. View the files in the directory:
- ```
- ls
- ```
- The directory contains the following files:
- ```
- Chart.lock Chart.yaml README.md charts templates values.yaml
- ```
-
-1. In the `Chart.yaml` file, add the Replicated SDK as a dependency:
-
- Description
-The KOTS HelmChart custom resource provides instructions to KOTS about how to deploy the Helm chart. The name and chartVersion listed in the HelmChart custom resource must match the name and version of a Helm chart archive in the release. Each Helm chart archive in a release requires a unique HelmChart custom resource.
YAML
-Description
-The KOTS Application custom resource enables features in the KOTS Admin Console such as branding, release notes, port forwarding, dashboard buttons, application status indicators, and custom graphs.
The YAML below provides a name for the application to display in the Admin Console, adds a custom status informer that displays the status of the gitea Deployment resource in the Admin Console dashboard, adds a custom application icon, and creates a port forward so that the user can open the Gitea application in a browser.
YAML
-Description
-The Kubernetes Application custom resource supports functionality such as including buttons and links on the KOTS Admin Console dashboard. The YAML below adds an Open App button to the Admin Console dashboard that opens the application using the port forward configured in the KOTS Application custom resource.
-YAML
-
-
- [View a larger version of this image](/images/release-promote.png)
-
-## Next Step
-
-Create a customer with the KOTS entitlement so that you can install the release in your cluster using Replicated KOTS. See [Step 5: Create a KOTS-Enabled Customer](tutorial-kots-helm-create-customer).
-
-## Related Topics
-
-* [About Channels and Releases](/vendor/releases-about)
-* [Configuring the HelmChart Custom Resource v2](/vendor/helm-native-v2-using)
diff --git a/docs/vendor/tutorial-kots-helm-get-chart.md b/docs/vendor/tutorial-kots-helm-get-chart.md
deleted file mode 100644
index 7239e490d9..0000000000
--- a/docs/vendor/tutorial-kots-helm-get-chart.md
+++ /dev/null
@@ -1,107 +0,0 @@
-# Step 1: Get the Sample Chart and Test
-
-To begin, get the sample Gitea Helm chart from Bitnami, install the chart in your cluster using the Helm CLI, and then uninstall. The purpose of this step is to confirm that you can successfully install and access the application before adding the chart to a release in the Replicated Vendor Portal.
-
-To get the sample Gitea Helm chart and test installation:
-
-1. Run the following command to pull and untar version 1.0.6 of the Bitnami Gitea Helm chart:
-
- ```
- 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.
-
-1. Change to the new `gitea` directory that was created:
- ```
- cd gitea
- ```
-1. View the files in the directory:
- ```
- ls
- ```
- The directory contains the following files:
- ```
- Chart.lock Chart.yaml README.md charts templates values.yaml
- ```
-1. Install the Gitea chart in your cluster:
-
- ```
- helm install gitea . --namespace gitea --create-namespace
- ```
- To view the full installation instructions from Bitnami, see [Installing the Chart](https://github.com/bitnami/charts/blob/main/bitnami/gitea/README.md#installing-the-chart) in the `bitnami/gitea` repository.
-
- When the chart is installed, the following output is displayed:
-
- ```
- NAME: gitea
- LAST DEPLOYED: Tue Oct 24 12:44:55 2023
- NAMESPACE: gitea
- STATUS: deployed
- REVISION: 1
- TEST SUITE: None
- NOTES:
- CHART NAME: gitea
- CHART VERSION: 1.0.6
- APP VERSION: 1.20.5
-
- ** Please be patient while the chart is being deployed **
-
- 1. Get the Gitea URL:
-
- NOTE: It may take a few minutes for the LoadBalancer IP to be available.
- Watch the status with: 'kubectl get svc --namespace gitea -w gitea'
-
- export SERVICE_IP=$(kubectl get svc --namespace gitea gitea --template "{{ range (index .status.loadBalancer.ingress 0) }}{{ . }}{{ end }}")
- echo "Gitea URL: http://$SERVICE_IP/"
-
- WARNING: You did not specify a Root URL for Gitea. The rendered URLs in Gitea may not show correctly. In order to set a root URL use the rootURL value.
-
- 2. Get your Gitea login credentials by running:
-
- echo Username: bn_user
- echo Password: $(kubectl get secret --namespace gitea gitea -o jsonpath="{.data.admin-password}" | base64 -d)
- ```
-
-1. Watch the `gitea` LoadBalancer service until an external IP is available:
-
- ```
- kubectl get svc gitea --namespace gitea --watch
- ```
-
-1. When the external IP for the `gitea` LoadBalancer service is available, run the commands provided in the output of the installation command to get the Gitea URL:
-
- ```
- export SERVICE_IP=$(kubectl get svc --namespace gitea gitea --template "{{ range (index .status.loadBalancer.ingress 0) }}{{ . }}{{ end }}")
- echo "Gitea URL: http://$SERVICE_IP/"
- ```
-
-1. In a browser, go to the Gitea URL to confirm that you can see the welcome page for the application:
-
-
-
- [View a larger version of this image](/images/gitea-app.png)
-
-1. Uninstall the Helm chart:
-
- ```
- helm uninstall gitea --namespace gitea
- ```
- This command removes all the Kubernetes components associated with the chart and uninstalls the `gitea` release.
-
-1. Delete the namespace:
-
- ```
- kubectl delete namespace gitea
- ```
-
-## Next Step
-
-Log in to the Vendor Portal and create an application. See [Step 2: Create an Application](tutorial-kots-helm-create-app).
-
-## Related Topics
-
-* [Helm Install](https://helm.sh/docs/helm/helm_install/)
-* [Helm Uninstall](https://helm.sh/docs/helm/helm_uninstall/)
-* [Helm Create](https://helm.sh/docs/helm/helm_create/)
-* [Helm Package](https://helm.sh/docs/helm/helm_package/)
-* [bitnami/gitea](https://github.com/bitnami/charts/blob/main/bitnami/gitea)
\ No newline at end of file
diff --git a/docs/vendor/tutorial-kots-helm-install-helm.md b/docs/vendor/tutorial-kots-helm-install-helm.md
deleted file mode 100644
index 3d6dad07ca..0000000000
--- a/docs/vendor/tutorial-kots-helm-install-helm.md
+++ /dev/null
@@ -1,118 +0,0 @@
-# Step 7: Install the Release with the Helm CLI
-
-Next, install the same release using the Helm CLI. All releases that contain one or more Helm charts can be installed with the Helm CLI.
-
-All Helm charts included in a release are automatically pushed to the Replicated registry when the release is promoted to a channel. Helm CLI installations require that the customer has a valid email address to authenticate with the Replicated registry.
-
-To install the release with the Helm CLI:
-
-1. Create a new customer to test the Helm CLI installation:
-
- 1. In the [Vendor Portal](https://vendor.replicated.com), click **Customers > Create customer**.
-
- The **Create a new customer** page opens:
-
- 
-
- [View a larger version of this image](/images/create-customer.png)
-
- 1. For **Customer name**, enter a name for the customer. For example, `Helm Customer`.
-
- 1. For **Channel**, select **Unstable**. This allows the customer to install releases promoted to the Unstable channel.
-
- 1. For **Customer email**, enter the email address for the customer. The customer email address is required to install the application with the Helm CLI. This email address is never used send emails to customers.
-
- 1. For **Customer type**, select Trial.
-
- 1. (Optional) For **License options**, select the **Existing Cluster (Helm CLI)** entitlement.
-
- 1. Click **Save Changes**.
-
-1. On the **Manage customer** page for the new customer, click **Helm install instructions**.
-
- 
-
- [View a larger version of this image](/images/tutorial-gitea-helm-customer-install-button.png)
-
- You will use the instructions provided in the **Helm install instructions** dialog to install the chart.
-
-1. Before you run the first command in the **Helm install instructions** dialog, create a `gitea` namespace for the installation:
-
- ```
- kubectl create namespace gitea
- ```
-
-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. Run the commands in the provided in the **Helm install instructions** dialog to log in to the registry and install the Helm chart.
-
- 
-
- [View a larger version of this image](/images/tutorial-gitea-helm-install-instructions.png)
-
- :::note
- You can ignore the **No preflight checks found** warning for the purpose of this tutorial. This warning appears because there are no specifications for preflight checks in the Helm chart archive.
- :::
-
-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
- ```
-
-1. Watch the `gitea` LoadBalancer service until an external IP is available:
-
- ```
- kubectl get svc gitea --watch
- ```
-
-1. After an external IP address is available for the `gitea` LoadBalancer service, follow the instructions in the output of the installation command to get the Gitea URL and then confirm that you can open the application in a browser.
-
-1. In another browser window, open the [Vendor Portal](https://vendor.replicated.com/) and go to **Customers**. Select the customer that you created for the Helm CLI installation.
-
- On the **Reporting** page for the customer, because the Replicated SDK was installed alongside the Gitea Helm chart, you can see details about the customer's license and installed instances:
-
- 
-
- [View a larger version of this image](/images/tutorial-gitea-helm-reporting.png)
-
-1. On the **Reporting** page, under **Instances**, click on the instance that you just installed to open the instance details page.
-
- On the instance details page, you can see additional insights such as the cluster where the application is installed, the version of the Replicated SDK running in the cluster, instance status and uptime, and more:
-
- 
-
- [View a larger version of this image](/images/tutorial-gitea-helm-instance.png)
-
-1. Uninstall the Helm chart and the Replicated SDK:
-
- ```
- helm uninstall gitea
- ```
-
-1. Delete the `gitea` namespace:
-
- ```
- kubectl delete namespace gitea
- ```
-
-## Next Step
-
-Congratulations! As part of this tutorial, you created a release in the Replicated Vendor Portal and installed the release with both KOTS and the Helm CLI.
-
-## Related Topics
-
-* [Installing with Helm](/vendor/install-with-helm)
-* [About the Replicated SDK](/vendor/replicated-sdk-overview)
-* [Helm Uninstall](https://helm.sh/docs/helm/helm_uninstall/)
-* [Helm Delete](https://helm.sh/docs/helm/helm_delete/)
diff --git a/docs/vendor/tutorial-kots-helm-install-kots.md b/docs/vendor/tutorial-kots-helm-install-kots.md
deleted file mode 100644
index 795bb58170..0000000000
--- a/docs/vendor/tutorial-kots-helm-install-kots.md
+++ /dev/null
@@ -1,147 +0,0 @@
-import KotsVerReq from "../partials/replicated-sdk/_kots-version-req.mdx"
-
-# Step 6: Install the Release with KOTS
-
-Next, get the KOTS installation command from the Unstable channel in the Vendor Portal and then install the release using the customer license that you downloaded.
-
-To install the release with KOTS:
-
-1. In the [Vendor Portal](https://vendor.replicated.com), go to **Channels**. From the **Unstable** channel card, under **Install**, copy the **KOTS Install** command.
-
- 
-
- [View a larger version of this image](/images/helm-tutorial-unstable-kots-install-command.png)
-
-1. On the command line, run the **KOTS Install** command that you copied:
-
- ```bash
- curl https://kots.io/install | bash
- kubectl kots install $REPLICATED_APP/unstable
- ```
-
- This installs the latest version of the KOTS CLI and the Replicated KOTS Admin Console. The Admin Console provides a user interface where you can upload the customer license file and deploy the application.
-
- For additional KOTS CLI installation options, including how to install without root access, see [Installing the KOTS CLI](/reference/kots-cli-getting-started).
-
- :::note
-
-
- [View a larger version of this image](/images/release-promote.png)
-
-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.
-
-1. For **Version label**, open the dropdown and select **1.0.6**.
-
-1. Click **Promote**.
-
-
-## Next Step
-
-Create a customer so that you can install the release in a development environment. See [Create a Customer](tutorial-preflight-helm-create-customer).
-
-## Related Topics
-
-* [About Channels and Releases](/vendor/releases-about)
-* [Managing Releases with the CLI](/vendor/releases-creating-cli)
\ No newline at end of file
diff --git a/docs/vendor/tutorial-preflight-helm-get-chart.mdx b/docs/vendor/tutorial-preflight-helm-get-chart.mdx
deleted file mode 100644
index 1532955e77..0000000000
--- a/docs/vendor/tutorial-preflight-helm-get-chart.mdx
+++ /dev/null
@@ -1,115 +0,0 @@
-# Step 1: Get the Sample Chart and Test
-
-To begin, get the sample Gitea Helm chart from Bitnami, install the chart in your cluster using the Helm CLI, and then uninstall. The purpose of this step is to confirm that you can successfully install the application before adding preflight checks to the chart.
-
-To get the sample Gitea Helm chart and test installation:
-
-1. Run the following command to pull and untar version 1.0.6 of the Bitnami Gitea Helm chart:
-
- ```
- 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.
-
-1. Change to the new `gitea` directory that was created:
- ```
- cd gitea
- ```
-1. View the files in the directory:
- ```
- ls
- ```
- The directory contains the following files:
- ```
- Chart.lock Chart.yaml README.md charts templates values.yaml
- ```
-1. Install the Gitea chart in your cluster:
-
- ```
- helm install gitea . --namespace gitea --create-namespace
- ```
- To view the full installation instructions from Bitnami, see [Installing the Chart](https://github.com/bitnami/charts/blob/main/bitnami/gitea/README.md#installing-the-chart) in the `bitnami/gitea` repository.
-
- When the chart is installed, the following output is displayed:
-
- ```
- NAME: gitea
- LAST DEPLOYED: Tue Oct 24 12:44:55 2023
- NAMESPACE: gitea
- STATUS: deployed
- REVISION: 1
- TEST SUITE: None
- NOTES:
- CHART NAME: gitea
- CHART VERSION: 1.0.6
- APP VERSION: 1.20.5
-
- ** Please be patient while the chart is being deployed **
-
- 1. Get the Gitea URL:
-
- NOTE: It may take a few minutes for the LoadBalancer IP to be available.
- Watch the status with: 'kubectl get svc --namespace gitea -w gitea'
-
- export SERVICE_IP=$(kubectl get svc --namespace gitea gitea --template "{{ range (index .status.loadBalancer.ingress 0) }}{{ . }}{{ end }}")
- echo "Gitea URL: http://$SERVICE_IP/"
-
- WARNING: You did not specify a Root URL for Gitea. The rendered URLs in Gitea may not show correctly. In order to set a root URL use the rootURL value.
-
- 2. Get your Gitea login credentials by running:
-
- echo Username: bn_user
- echo Password: $(kubectl get secret --namespace gitea gitea -o jsonpath="{.data.admin-password}" | base64 -d)
- ```
-
-1. Watch the `gitea` LoadBalancer service until an external IP is available:
-
- ```
- kubectl get svc gitea --namespace gitea --watch
- ```
-
-1. When the external IP for the `gitea` LoadBalancer service is available, run the commands provided in the output of the installation command to get the Gitea URL:
-
- ```
- export SERVICE_IP=$(kubectl get svc --namespace gitea gitea --template "{{ range (index .status.loadBalancer.ingress 0) }}{{ . }}{{ end }}")
- echo "Gitea URL: http://$SERVICE_IP/"
- ```
-
- :::note
- Alternatively, you can run the following command to forward a local port to a port on the Gitea Pod:
-
- ```
- POD_NAME=$(kubectl get pods -l app.kubernetes.io/name=gitea -o jsonpath='{.items[0].metadata.name}')
- kubectl port-forward pod/$POD_NAME 8080:3000
- ```
- :::
-
-1. In a browser, go to the Gitea URL to confirm that you can see the welcome page for the application:
-
-
-
- [View a larger version of this image](/images/gitea-app.png)
-
-1. Uninstall the Helm chart:
-
- ```
- helm uninstall gitea --namespace gitea
- ```
- This command removes all the Kubernetes components associated with the chart and uninstalls the `gitea` release.
-
-1. Delete the namespace:
-
- ```
- kubectl delete namespace gitea
- ```
-
-## Next Step
-
-Define preflight checks and add them to the Gitea Helm chart. See [Add a Preflight Spec to the Chart](tutorial-preflight-helm-add-spec).
-
-## Related Topics
-
-* [Helm Install](https://helm.sh/docs/helm/helm_install/)
-* [Helm Uninstall](https://helm.sh/docs/helm/helm_uninstall/)
-* [Helm Package](https://helm.sh/docs/helm/helm_package/)
-* [bitnami/gitea](https://github.com/bitnami/charts/blob/main/bitnami/gitea)
\ No newline at end of file
diff --git a/docs/vendor/tutorial-preflight-helm-install-kots.mdx b/docs/vendor/tutorial-preflight-helm-install-kots.mdx
deleted file mode 100644
index 28bd64bbfc..0000000000
--- a/docs/vendor/tutorial-preflight-helm-install-kots.mdx
+++ /dev/null
@@ -1,199 +0,0 @@
-import Tabs from '@theme/Tabs';
-import TabItem from '@theme/TabItem';
-import HelmChartCr from "../partials/getting-started/_gitea-helmchart-cr.mdx"
-import KotsCr from "../partials/getting-started/_gitea-kots-app-cr.mdx"
-import K8sCr from "../partials/getting-started/_gitea-k8s-app-cr.mdx"
-import KotsVerReq from "../partials/replicated-sdk/_kots-version-req.mdx"
-
-# Step 6: Run Preflights with KOTS
-
-Create a KOTS-enabled release and then install Gitea with KOTS. This purpose of this step is to see how preflight checks automatically run in the KOTS Admin Console during installation.
-
-To run preflight checks during installation with KOTS:
-
-1. In the `gitea` directory, create a subdirectory named `manifests`:
-
- ```
- mkdir manifests
- ```
-
- You will add the files required to support installation with KOTS to this subdirectory.
-
-1. Move the Helm chart archive to `manifests`:
-
- ```
- mv gitea-1.0.6.tgz manifests
- ```
-
-1. In `manifests`, create the YAML manifests required by KOTS:
- ```
- cd manifests
- ```
- ```
- touch gitea.yaml kots-app.yaml k8s-app.yaml
- ```
-
-1. In each of the files that you created, paste the corresponding YAML provided in the tabs below:
-
- Description
-The KOTS HelmChart custom resource provides instructions to KOTS about how to deploy the Helm chart. The name and chartVersion listed in the HelmChart custom resource must match the name and version of a Helm chart archive in the release. Each Helm chart archive in a release requires a unique HelmChart custom resource.
YAML
-Description
-The KOTS Application custom resource enables features in the Replicated Admin Console such as branding, release notes, port forwarding, dashboard buttons, application status indicators, and custom graphs.
The YAML below provides a name for the application to display in the Admin Console, adds a custom status informer that displays the status of the gitea Deployment resource in the Admin Console dashboard, adds a custom application icon, and creates a port forward so that the user can open the Gitea application in a browser.
YAML
-Description
-The Kubernetes Application custom resource supports functionality such as including buttons and links on the Replicated Admin Console dashboard. The YAML below adds an Open App button to the Admin Console dashboard that opens the application using the port forward configured in the KOTS Application custom resource.
-YAML
-
-
- [View a larger version of this image](/images/gitea-preflights-cli.png)
-
-1. Run the fourth command listed under **Option 1: Install Gitea** to install the application:
-
- ```bash
- helm install gitea oci://registry.replicated.com/$REPLICATED_APP/unstable/gitea
- ```
-
-1. Uninstall and delete the namespace:
-
- ```bash
- helm uninstall gitea --namespace gitea
- ```
- ```bash
- kubectl delete namespace gitea
- ```
-
-## Next Step
-
-Install the application with KOTS to see how preflight checks are run from the KOTS Admin Console. See [Run Preflights with KOTS](tutorial-preflight-helm-install-kots).
-
-## Related Topics
-
-* [Running Preflight Checks](/vendor/preflight-running)
-* [Installing with Helm](/vendor/install-with-helm)
\ No newline at end of file
diff --git a/docs/vendor/tutorial-preflight-helm-setup.mdx b/docs/vendor/tutorial-preflight-helm-setup.mdx
deleted file mode 100644
index 6dd81987d7..0000000000
--- a/docs/vendor/tutorial-preflight-helm-setup.mdx
+++ /dev/null
@@ -1,44 +0,0 @@
-# Introduction and Setup
-
-This topic provides a summary of the goals and outcomes for the tutorial and also lists the prerequisites to set up your environment before you begin.
-
-## Summary
-
-This tutorial introduces you to preflight checks. The purpose of preflight checks is to provide clear feedback about any missing requirements or incompatibilities in the customer's cluster _before_ they install or upgrade an application. Thorough preflight checks provide increased confidence that an installation or upgrade will succeed and help prevent support escalations.
-
-Preflight checks are part of the [Troubleshoot](https://troubleshoot.sh/) open source project, which is maintained by Replicated.
-
-In this tutorial, you use a sample Helm chart to learn how to:
-
-* Define custom preflight checks in a Kubernetes Secret in a Helm chart
-* Package a Helm chart and add it to a release in the Replicated Vendor Portal
-* Run preflight checks using the Helm CLI
-* Run preflight checks in the Replicated KOTS Admin Console
-
-## Set Up the Environment
-
-Before you begin, do the following to set up your environment:
-
-* 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 Google Kubernetes Engine (GKE), Amazon Web Services (AWS), or minikube.
-
- For information about installing kubectl and configuring kubectl access to a cluster, see the following in the Kubernetes documentation:
- * [Install Tools](https://kubernetes.io/docs/tasks/tools/)
- * [Command line tool (kubectl)](https://kubernetes.io/docs/reference/kubectl/)
-
-* Install the Helm CLI. To install the Helm CLI using Homebrew, run:
-
- ```
- brew install helm
- ```
-
- For more information, including alternative installation options, see [Install Helm](https://helm.sh/docs/intro/install/) in the Helm documentation.
-
-* Create a vendor account to access the Vendor Portal. See [Creating a Vendor Portal](/vendor/vendor-portal-creating-account).
-
- :::note
- If you do not yet have a Vendor Portal team to join, you can sign up for a trial account. By default, trial accounts do not include access to Replicated KOTS. To get access to KOTS with your trial account so that you can complete this and other tutorials, contact Replicated at contact@replicated.com.
- :::
-
-## Next Step
-
-Get the sample Bitnami Helm chart and test installation with the Helm CLI. See [Step 1: Get the Sample Chart and Test](/vendor/tutorial-preflight-helm-get-chart)
\ No newline at end of file
diff --git a/netlify.toml b/netlify.toml
index 259f5ef351..87a887c27a 100644
--- a/netlify.toml
+++ b/netlify.toml
@@ -49,19 +49,19 @@
###################################################
[[redirects]]
from = "https://docs.replicated.com/vendor/tutorial-installing-with-existing-cluster"
- to = "https://docs.replicated.com/vendor/tutorial-cli-setup"
+ to = "https://docs.replicated.com/vendor/quick-start"
[[redirects]]
from = "https://docs.replicated.com/vendor/tutorial-installing-with-cli"
- to = "https://docs.replicated.com/vendor/tutorial-cli-setup"
+ to = "https://docs.replicated.com/vendor/quick-start"
[[redirects]]
from = "https://docs.replicated.com/vendor/tutorial-installing-without-existing-cluster"
- to = "https://docs.replicated.com/vendor/tutorial-embedded-cluster-setup"
+ to = "https://docs.replicated.com/vendor/quick-start"
[[redirects]]
from = "https://docs.replicated.com/vendor/helm-mapping-example"
- to = "https://docs.replicated.com/vendor/tutorial-config-setup"
+ to = "https://docs.replicated.com/vendor/quick-start"
[[redirects]]
from = "https://docs.replicated.com/vendor/releases-download-airgap-bundles"
diff --git a/sidebars.js b/sidebars.js
index 0ca79fa580..04f0b12b25 100644
--- a/sidebars.js
+++ b/sidebars.js
@@ -48,54 +48,6 @@ const sidebars = {
// 'vendor/namespaces',
// ],
// },
- {
- type: 'category',
- label: 'Tutorials',
- items: [
- {
- type: 'category',
- label: 'Install a Helm Chart on a VM with Embedded Cluster',
- items: [
- 'vendor/tutorial-embedded-cluster-setup',
- 'vendor/tutorial-embedded-cluster-create-app',
- 'vendor/tutorial-embedded-cluster-package-chart',
- 'vendor/tutorial-embedded-cluster-create-release',
- 'vendor/tutorial-embedded-cluster-create-customer',
- 'vendor/tutorial-embedded-cluster-install',
- ],
- },
- {
- type: 'category',
- label: 'Install a Helm Chart with KOTS and the Helm CLI',
- items: [
- 'vendor/tutorial-kots-helm-setup',
- 'vendor/tutorial-kots-helm-get-chart',
- 'vendor/tutorial-kots-helm-create-app',
- 'vendor/tutorial-kots-helm-package-chart',
- 'vendor/tutorial-kots-helm-create-release',
- 'vendor/tutorial-kots-helm-create-customer',
- 'vendor/tutorial-kots-helm-install-kots',
- 'vendor/tutorial-kots-helm-install-helm',
- ],
- },
- {
- type: 'category',
- label: 'Install with KOTS in an Existing Cluster',
- items: [
- 'vendor/tutorial-cli-setup',
- 'vendor/tutorial-cli-install-cli',
- 'vendor/tutorial-cli-create-app',
- 'vendor/tutorial-cli-manifests',
- 'vendor/tutorial-cli-create-release',
- 'vendor/tutorial-cli-create-customer',
- 'vendor/tutorial-cli-install-app-manager',
- 'vendor/tutorial-cli-deploy-app',
- 'vendor/tutorial-cli-create-new-version',
- 'vendor/tutorial-cli-update-app',
- ],
- },
- ],
- },
{
type: 'category',
label: 'Labs',
@@ -325,19 +277,6 @@ const sidebars = {
'vendor/admin-console-customize-config-screen',
'vendor/config-screen-map-inputs',
'vendor/config-screen-conditional',
- {
- type: 'category',
- label: 'Tutorial: Set Helm Chart Values with KOTS',
- items: [
- 'vendor/tutorial-config-setup',
- 'vendor/tutorial-config-get-chart',
- 'vendor/tutorial-config-create-app',
- 'vendor/tutorial-config-package-chart',
- 'vendor/tutorial-config-create-release',
- 'vendor/tutorial-config-create-customer',
- 'vendor/tutorial-config-install-kots',
- ],
- },
],
},
{
@@ -575,19 +514,6 @@ const sidebars = {
'vendor/preflight-examples',
'vendor/preflight-running',
'vendor/preflight-host-preflights',
- {
- type: 'category',
- label: 'Tutorial: Add Preflight Checks to a Helm Chart',
- items: [
- 'vendor/tutorial-preflight-helm-setup',
- 'vendor/tutorial-preflight-helm-get-chart',
- 'vendor/tutorial-preflight-helm-add-spec',
- 'vendor/tutorial-preflight-helm-create-release',
- 'vendor/tutorial-preflight-helm-create-customer',
- 'vendor/tutorial-preflight-helm-install',
- 'vendor/tutorial-preflight-helm-install-kots',
- ],
- },
],
},
{
diff --git a/static/images/compatibility-matrix-dns-record.png b/static/images/compatibility-matrix-dns-record.png
new file mode 100644
index 0000000000..a6fdfba9e9
Binary files /dev/null and b/static/images/compatibility-matrix-dns-record.png differ
diff --git a/static/images/compatibility-matrix-edit-vm.png b/static/images/compatibility-matrix-edit-vm.png
new file mode 100644
index 0000000000..486a29af11
Binary files /dev/null and b/static/images/compatibility-matrix-edit-vm.png differ
diff --git a/static/images/create-customer.png b/static/images/create-customer.png
index 59c7f5b767..d001231e9d 100644
Binary files a/static/images/create-customer.png and b/static/images/create-customer.png differ
diff --git a/static/images/embedded-cluster-install-dialog-latest.png b/static/images/embedded-cluster-install-dialog-latest.png
index 1b21a38e64..abf9d80141 100644
Binary files a/static/images/embedded-cluster-install-dialog-latest.png and b/static/images/embedded-cluster-install-dialog-latest.png differ
diff --git a/static/images/quick-start-app-dropdown-slackernews.png b/static/images/quick-start-app-dropdown-slackernews.png
new file mode 100644
index 0000000000..323c8c9937
Binary files /dev/null and b/static/images/quick-start-app-dropdown-slackernews.png differ
diff --git a/static/images/quick-start-slackernews-adm-dashboard-ready.png b/static/images/quick-start-slackernews-adm-dashboard-ready.png
new file mode 100644
index 0000000000..536c239f7d
Binary files /dev/null and b/static/images/quick-start-slackernews-adm-dashboard-ready.png differ
diff --git a/static/images/quick-start-slackernews-admin-console-login.png b/static/images/quick-start-slackernews-admin-console-login.png
new file mode 100644
index 0000000000..aae5f144d0
Binary files /dev/null and b/static/images/quick-start-slackernews-admin-console-login.png differ
diff --git a/static/images/quick-start-slackernews-available-updates.png b/static/images/quick-start-slackernews-available-updates.png
new file mode 100644
index 0000000000..6ae14b6834
Binary files /dev/null and b/static/images/quick-start-slackernews-available-updates.png differ
diff --git a/static/images/quick-start-slackernews-configure-slackernews.png b/static/images/quick-start-slackernews-configure-slackernews.png
new file mode 100644
index 0000000000..f3a7b8eabd
Binary files /dev/null and b/static/images/quick-start-slackernews-configure-slackernews.png differ
diff --git a/static/images/quick-start-slackernews-configure-the-cluster.png b/static/images/quick-start-slackernews-configure-the-cluster.png
new file mode 100644
index 0000000000..db389ea904
Binary files /dev/null and b/static/images/quick-start-slackernews-configure-the-cluster.png differ
diff --git a/static/images/quick-start-slackernews-customer-install-instructions-button.png b/static/images/quick-start-slackernews-customer-install-instructions-button.png
new file mode 100644
index 0000000000..accf0a7d3f
Binary files /dev/null and b/static/images/quick-start-slackernews-customer-install-instructions-button.png differ
diff --git a/static/images/quick-start-slackernews-customer-instance.png b/static/images/quick-start-slackernews-customer-instance.png
new file mode 100644
index 0000000000..2cd9c9284e
Binary files /dev/null and b/static/images/quick-start-slackernews-customer-instance.png differ
diff --git a/static/images/quick-start-slackernews-preflight.png b/static/images/quick-start-slackernews-preflight.png
new file mode 100644
index 0000000000..abe5f57e3a
Binary files /dev/null and b/static/images/quick-start-slackernews-preflight.png differ
diff --git a/static/images/slackernews-landing-page.png b/static/images/slackernews-landing-page.png
new file mode 100644
index 0000000000..9742d8f1aa
Binary files /dev/null and b/static/images/slackernews-landing-page.png differ