diff --git a/docs/enterprise/image-registry-kurl.md b/docs/enterprise/image-registry-kurl.md index a87b1ba84a..70320dbfa9 100644 --- a/docs/enterprise/image-registry-kurl.md +++ b/docs/enterprise/image-registry-kurl.md @@ -16,7 +16,7 @@ To keep the registry from running out of storage, images that are no longer used For more information about the kURL Registry add-on, see [Registry Add-On](https://kurl.sh/docs/add-ons/registry) in the kURL documentation. :::note -Users can also configure their own private registry for kURL installations instead of using the kURL registry. For more information, see [Configure Local Image Registries](/enterprise/image-registry-settings). +Users can also configure their own private registry for kURL installations instead of using the kURL registry. For more information, see [Configure Local Image Registries in the Admin Console](/enterprise/image-registry-settings). ::: ## Trigger Garbage Collection @@ -66,6 +66,6 @@ The kURL registry image garbage collection feature has following limitations: * **Shared Image Registries**: The image garbage collection process assumes that the registry is not shared with any other instances of Replicated KOTS, nor shared with any external applications. If the built-in kURL registry is used by another external application, disable garbage collection to prevent image loss. -* **Customer-Supplied Registries**: Image garbage collection is supported only when used with the built-in kURL registry. If the KOTS instance is configured to use a different registry, disable garbage collection to prevent image loss. For more information about configuring an image registry in the Admin Console, see [Configure Local Image Registries](/enterprise/image-registry-settings). +* **Customer-Supplied Registries**: Image garbage collection is supported only when used with the built-in kURL registry. If the KOTS instance is configured to use a different registry, disable garbage collection to prevent image loss. For more information about configuring an image registry in the Admin Console, see [Configure Local Image Registries in the Admin Console](/enterprise/image-registry-settings). * **Application Rollbacks**: Image garbage collection has no effect when the `allowRollback` field in the KOTS Application custom resource is set to `true`. For more information, see [Application](/reference/custom-resource-application) in _KOTS Custom Resources_. diff --git a/docs/enterprise/image-registry-rate-limits.md b/docs/enterprise/image-registry-rate-limits.md index 6a50497d5e..b17350c2b6 100644 --- a/docs/enterprise/image-registry-rate-limits.md +++ b/docs/enterprise/image-registry-rate-limits.md @@ -1,6 +1,6 @@ # Avoid Docker Hub Rate Limits -This topic describes how to avoid rate limiting for anonymous and free authenticated use of Docker Hub by providing a Docker Hub username and password to the `kots docker ensure-secret` command. +This topic describes how to avoid rate limiting for anonymous and free authenticated use of Docker Hub. The information in this topic applies to applications deployed with Replicated KOTS that have public Docker Hub images that are rate limited. ## Overview @@ -10,20 +10,47 @@ Docker Pro and Docker Team accounts continue to have unlimited access to pull co For more information on rate limits, see [Understanding Docker Hub rate limiting](https://www.docker.com/increase-rate-limits) on the Docker website. -If the application that you are installing or upgrading has public Docker Hub images that are rate limited, then an error occurs when the rate limit is reached. +If your application has public Docker Hub images that are rate limited, then an error occurs when the rate limit is reached. -## Provide Docker Hub Credentials +## Prerequisite -To avoid errors caused by reaching the Docker Hub rate limit, a Docker Hub username and password can be passed to the `kots docker ensure-secret` command. The Docker Hub username and password are used only to increase rate limits and do not need access to any private repositories on Docker Hub. +For any Helm charts in your application that are deployed with the KOTS HelmChart v2 custom resource, configure the HelmChart v2 custom resource `values` key to add an image pull secret named `APP_SLUG-kotsadm-dockerhub` (where `APP_SLUG` is your application slug) to any Docker images that could be rate-limited. This pull secret allows your users to run the `kots docker ensure-secret` command for their installation. -Example: +The HelmChart `values` key creates a mapping between KOTS and the `values.yaml` file for your Helm chart. This allows you to set or delete Helm values during installation or upgrade with KOTS, without having to make any changes to the Helm chart itself. For more information about working with the `values` key, see [Set Helm Values with KOTS](/vendor/helm-optional-value-keys). -```bash -kubectl kots docker ensure-secret --dockerhub-username sentrypro --dockerhub-password password --namespace sentry-pro -``` +**Example:** -The `kots docker ensure-secret` command creates an image pull secret that KOTS can use when pulling images. +```yaml +# kots.io/v1beta2 HelmChart custom resource +apiVersion: kots.io/v1beta2 +kind: HelmChart +metadata: + name: samplechart +spec: + values: + image: + registry: docker.io + repository: org-name/example-docker-hub-image + # Add the dockerhub secret + pullSecrets: + - name: gitea-kotsadm-dockerhub +``` -KOTS then creates a new release sequence for the application to apply the image pull secret to all Kubernetes manifests that have images. After running the `kots docker ensure-secret` command, deploy this new release sequence either from the Admin Console or the KOTS CLI. +## Provide Docker Hub Credentials with `kots docker ensure-secret` + +To avoid errors caused by reaching the Docker Hub rate limit, your users can pass a Docker Hub username and password to the `kots docker ensure-secret` command. The `kots docker ensure-secret` command creates an image pull secret that KOTS can use when pulling Docker Hub images and applies the Secret to application images where necessary. + +:::note +The Docker Hub username and password passed with the `kots docker ensure-secret` command are used only to increase rate limits and do not need access to any private repositories on Docker Hub. +::: + +1. Run the following command: + + ```bash + kubectl kots docker ensure-secret --dockerhub-username sentrypro --dockerhub-password password --namespace sentry-pro + ``` + KOTS then creates a new release sequence for the application to apply the image pull secret to all Kubernetes manifests that have images. + +1. Deploy the new release sequence. For more information, see [docker ensure-secret](/reference/kots-cli-docker-ensure-secret) in the KOTS CLI documentation. diff --git a/docs/enterprise/image-registry-settings.mdx b/docs/enterprise/image-registry-settings.mdx index 1e5c2aa8b6..1bb5e40104 100644 --- a/docs/enterprise/image-registry-settings.mdx +++ b/docs/enterprise/image-registry-settings.mdx @@ -1,7 +1,7 @@ import ImageRegistrySettings from "../partials/image-registry/_image-registry-settings.mdx" import DockerCompatibility from "../partials/image-registry/_docker-compatibility.mdx" -# Configure Local Image Registries +# Configure Local Image Registries in the Admin Console This topic describes how to configure private registry settings in the Replicated KOTS Admin Console. @@ -9,7 +9,7 @@ The information in this topic applies to existing cluster installations with KOT ## Overview -Using a private registry lets you create a custom image pipeline. Any proprietary configurations that you make to the application are shared only with the groups that you allow access, such as your team or organization. You also have control over the storage location, logging messages, load balancing requests, and other configuration options. Private registries can be used with online or air gap clusters. +Using a private registry lets your users create a custom image pipeline. This gives users control over the storage location, logging messages, load balancing requests, and other configuration options. Private registries can be used with online or air gap clusters. ## Requirement @@ -19,7 +19,7 @@ The domain of the image registry must support a Docker V2 protocol. KOTS has bee ## Configure Local Private Registries in Online Clusters -In online (internet-connected) installations, you can optionally use a local private image registry. You can also disable the connection or remove the registry settings if needed. +In online (internet-connected) installations, users can optionally use a local private image registry. To configure private registry settings in an online cluster: diff --git a/docs/enterprise/installing-general-requirements.mdx b/docs/enterprise/installing-general-requirements.mdx index 00c8fabf02..e7b355d1d2 100644 --- a/docs/enterprise/installing-general-requirements.mdx +++ b/docs/enterprise/installing-general-requirements.mdx @@ -260,7 +260,7 @@ After manually creating these RBAC resources, the user must include both the `-- A private image registry is required for air gap installations with KOTS in existing clusters. You provide the credentials for a compatible private registry during installation. You can also optionally configure a local private image registry for use with installations in online (internet-connected) environments. -Private registry settings can be changed at any time. For more information, see [Configuring Local Image Registries](image-registry-settings). +Private registry settings can be changed at any time. For more information, see [Configure Local Image Registries in the Admin Console](image-registry-settings). KOTS has been tested for compatibility with the following registries: diff --git a/docs/partials/helm/_helmchart-v2-configure-step.mdx b/docs/partials/helm/_helmchart-v2-configure-step.mdx new file mode 100644 index 0000000000..d6edf15195 --- /dev/null +++ b/docs/partials/helm/_helmchart-v2-configure-step.mdx @@ -0,0 +1,7 @@ +For each Helm chart in the release, open the corresponding KOTS HelmChart custom resource. In the HelmChart custom resource, do the following: + 1. Update `apiVersion` to `kots.io/v1beta2`. + 1. Rewrite image names to use the Replicated proxy registry and inject the image pull secret for the proxy registry. See [HelmChart v2](/vendor/private-images-kots#helmchart-v2) in _Use the Proxy Registry with Replicated Installers_. + 1. Configure the `builder` key to allow your users to push images to their own local registries. See [Package Air Gap Bundles for Helm Charts](/vendor/helm-packaging-airgap-bundles) and [builder](/reference/custom-resource-helmchart-v2#builder) in _HelmChart v2_. + 1. Configure the `optionalValues` key to rewrite image names for your application and the Replicated SDK to the user's local image registry if a local registry was configured. See [Rewrite Image Names with HelmChart v2 for Local Registries](/vendor/helmchart-local-registries). + 1. Add a pull secret for any Docker Hub images that could be rate limited. See [Configure Local Image Registries in the Admin Console](/enterprise/image-registry-settings). + 1. (KOTS Existing Cluster and kURL Installations Only) Add the `kots.io/backup: velero` and `kots.io/app-slug: APP_SLUG` backup labels to your resources to support backup and restore with the KOTS snapshots feature. See [Configure Snapshots](/vendor/snapshots-configuring-backups). \ No newline at end of file diff --git a/docs/partials/helm/_replicated-deprecated.mdx b/docs/partials/helm/_replicated-deprecated.mdx index cd285df487..9979a6830d 100644 --- a/docs/partials/helm/_replicated-deprecated.mdx +++ b/docs/partials/helm/_replicated-deprecated.mdx @@ -1 +1 @@ -The HelmChart custom resource `apiVersion: kots.io/v1beta1` is deprecated. For installations with Replicated KOTS v1.99.0 and later, use the HelmChart custom resource with `apiVersion: kots.io/v1beta2` instead. See [HelmChart v2](/reference/custom-resource-helmchart-v2) and [Confguring the HelmChart Custom Resource v2](/vendor/helm-native-v2-using). \ No newline at end of file +The HelmChart custom resource `apiVersion: kots.io/v1beta1` is deprecated. For installations with Replicated KOTS v1.99.0 and later, use the HelmChart custom resource with `apiVersion: kots.io/v1beta2` instead. See [HelmChart v2](/reference/custom-resource-helmchart-v2). \ No newline at end of file diff --git a/docs/partials/proxy-service/_step-additional-ns.mdx b/docs/partials/proxy-service/_step-additional-ns.mdx new file mode 100644 index 0000000000..0dc1cdf578 --- /dev/null +++ b/docs/partials/proxy-service/_step-additional-ns.mdx @@ -0,0 +1 @@ +If you are deploying Pods to namespaces other than the application namespace, add the namespace to the `additionalNamespaces` attribute of the KOTS Application custom resource. This ensures that KOTS can provision the `imagePullSecret` in the namespace to allow the Pod to pull the image. For instructions, see [Define Additional Namespaces](operator-defining-additional-namespaces). \ No newline at end of file diff --git a/docs/partials/proxy-service/_step-inject-pull-secret.mdx b/docs/partials/proxy-service/_step-inject-pull-secret.mdx new file mode 100644 index 0000000000..44d1292b00 --- /dev/null +++ b/docs/partials/proxy-service/_step-inject-pull-secret.mdx @@ -0,0 +1,42 @@ +In the HelmChart v2 custom resource, configure the `values` key to inject the Replicated image pull secret into your Helm values. This provides authentication for the proxy registry. Use the KOTS [ImagePullSecretName](/reference/template-functions-config-context#imagepullsecretname) template function to get the pull secret name. + +
+ What is the Replicated image pull secret? +

During application deployment, KOTS automatically creates an `imagePullSecret` with `type: kubernetes.io/dockerconfigjson` that is based on the customer license. This secret is used to authenticate with the proxy registry and grant proxy access to private images. For information about how Kubernetes uses the `kubernetes.io/dockerconfigjson` Secret type to authenticate to a private image registry, see [Pull an Image from a Private Registry](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/) in the Kubernetes documentation.

+
+ + **Example**: + + ```yaml + # kots.io/v1beta2 HelmChart custom resource + + apiVersion: kots.io/v1beta2 + kind: HelmChart + metadata: + name: samplechart + spec: + values: + image: + # Get the pull secret name with ImagePullSecretName + pullSecrets: + - name: '{{repl ImagePullSecretName }}' + ``` + Ensure that you provide this pull secret in any Pod definitions that reference images to be pulled through the proxy registry. + + **Example**: + + ```yaml + apiVersion: v1 + kind: Pod + metadata: + name: nginx + spec: + containers: + - name: nginx + image: {{ .Values.image.registry }}/{{ .Values.image.repository }} + # Access the value to provide the KOTS pull secret + {{- with .Values.image.pullSecrets }} + imagePullSecrets: + {{- toYaml . | nindent 2 }} + {{- end }} + ``` \ No newline at end of file diff --git a/docs/partials/proxy-service/_step-rewrite-helm-values.mdx b/docs/partials/proxy-service/_step-rewrite-helm-values.mdx new file mode 100644 index 0000000000..979a691085 --- /dev/null +++ b/docs/partials/proxy-service/_step-rewrite-helm-values.mdx @@ -0,0 +1,34 @@ +In your Helm chart values file, set your image repository URL to the location of the image on the proxy registry. If you added a custom domain, use your custom domain. Otherwise, use `proxy.replicated.com`. + + The proxy registry URL has the following format: `DOMAIN/proxy/APP_SLUG/EXTERNAL_REGISTRY_IMAGE_URL` + + Where: + * `DOMAIN` is either `proxy.replicated.com` or your custom domain. + * `APP_SLUG` is the unique slug of your application. + * `EXTERNAL_REGISTRY_IMAGE_URL` is the path to the private image on your external registry. + + **Example:** + + ```yaml + # values.yaml + api: + image: + # proxy.registry.com or your custom domain + registry: ghcr.io + repository: proxy/app/ghcr.io/cloudnative-pg/cloudnative-pg + tag: catalog-1.24.0 + ``` + + Ensure that any references to the image in your Helm chart access the field from your values file. + + **Example**: + + ```yaml + apiVersion: v1 + kind: Pod + spec: + containers: + - name: api + # Access the registry, repository, and tag fields from the values file + image: {{ .Values.images.api.registry }}/{{ .Values.images.api.repository }}:{{ .Values.images.api.tag }} + ``` \ No newline at end of file diff --git a/docs/reference/custom-resource-helmchart-v2.mdx b/docs/reference/custom-resource-helmchart-v2.mdx index 1ae9b181d9..dea9f33648 100644 --- a/docs/reference/custom-resource-helmchart-v2.mdx +++ b/docs/reference/custom-resource-helmchart-v2.mdx @@ -101,7 +101,7 @@ The `builder` key is required for the following use cases: * To support online installations that use a local private registry, the `builder` field renders the Helm chart with all of the necessary images so that KOTS knows where to pull the images. - You cannot prevent customers from configuring a local private registry in the Admin Console. If you think any of your customers will use a local private registry, you should use the `builder` key. For more information, see [Configuring Local Image Registries](/enterprise/image-registry-settings). + You cannot prevent customers from configuring a local private registry in the Admin Console. If you think any of your customers will use a local private registry, you should use the `builder` key. For more information, see [Configure Local Image Registries in the Admin Console](/enterprise/image-registry-settings). diff --git a/docs/vendor/embedded-disaster-recovery.mdx b/docs/vendor/embedded-disaster-recovery.mdx index e3d56526a8..4d7d789e87 100644 --- a/docs/vendor/embedded-disaster-recovery.mdx +++ b/docs/vendor/embedded-disaster-recovery.mdx @@ -123,8 +123,7 @@ To configure Velero Backup and Restore custom resources for Embedded Cluster dis registry: '{{repl HasLocalRegistry | ternary LocalRegistryHost "proxy.replicated.com" }}' repository: '{{repl HasLocalRegistry | ternary LocalRegistryNamespace "proxy/my-app/quay.io/my-org" }}/nginx' tag: 1.24-alpine - ``` - For more information about how to rewrite image names using the KOTS [HasLocalRegistry](/reference/template-functions-config-context#haslocalregistry), [LocalRegistryHost](/reference/template-functions-config-context#localregistryhost), and [LocalRegistryNamespace](/reference/template-functions-config-context#localregistrynamespace) template functions, including additional examples, see [Task 1: Rewrite Image Names](helm-native-v2-using#rewrite-image-names) in _Configuring the HelmChart v2 Custom Resource_. + ``` 1. If you support air gap installations, add any images that are referenced in your Backup and Restore resources to the `additionalImages` field of the KOTS Application custom resource. This ensures that the images are included in the air gap bundle for the release so they can be used during the backup and restore process in environments with limited or no outbound internet access. For more information, see [additionalImages](/reference/custom-resource-application#additionalimages) in _Application_. diff --git a/docs/vendor/helm-image-registry.mdx b/docs/vendor/helm-image-registry.mdx index 377df12dae..d81c00d204 100644 --- a/docs/vendor/helm-image-registry.mdx +++ b/docs/vendor/helm-image-registry.mdx @@ -1,5 +1,6 @@ import StepCreds from "../partials/proxy-service/_step-creds.mdx" import StepCustomDomain from "../partials/proxy-service/_step-custom-domain.mdx" +import RewriteHelmValues from "../partials/proxy-service/_step-rewrite-helm-values.mdx" # Use the Proxy Registry with Helm Installations @@ -19,40 +20,7 @@ To use the Replicated proxy registry for applications installed with Helm: 1. -1. In your Helm chart values file, set your image repository URL to the location of the image on the proxy registry. If you added a custom domain, use your custom domain. Otherwise, use `proxy.replicated.com`. - - The proxy registry URL has the following format: `DOMAIN/proxy/APP_SLUG/EXTERNAL_REGISTRY_IMAGE_URL` - - Where: - * `DOMAIN` is either `proxy.replicated.com` or your custom domain. - * `APP_SLUG` is the unique slug of your application. - * `EXTERNAL_REGISTRY_IMAGE_URL` is the path to the private image on your external registry. - - **Example:** - - ```yaml - # values.yaml - api: - image: - # proxy.registry.com or your custom domain - registry: ghcr.io - repository: proxy/app/ghcr.io/cloudnative-pg/cloudnative-pg - tag: catalog-1.24.0 - ``` - -1. Ensure that any references to the image in your Helm chart access the field from your values file. - - **Example**: - - ```yaml - apiVersion: v1 - kind: Pod - spec: - containers: - - name: api - # Access the registry, repository, and tag fields from the values file - image: {{ .Values.images.api.registry }}/{{ .Values.images.api.repository }}:{{ .Values.images.api.tag }} - ``` +1. 1. In your Helm chart templates, create a Kubernetes Secret to evaluate if the `global.replicated.dockerconfigjson` value is set and then write the rendered value into a Secret on the cluster, as shown below. diff --git a/docs/vendor/helm-native-about.mdx b/docs/vendor/helm-native-about.mdx index 8a5502663d..77109aa340 100644 --- a/docs/vendor/helm-native-about.mdx +++ b/docs/vendor/helm-native-about.mdx @@ -56,10 +56,50 @@ When you include a HelmChart custom resource with `apiVersion: kots.io/v1beta2` The `kots.io/v1beta2` HelmChart custom resource does _not_ modify the chart during installation. This results in Helm chart installations that are consistent, reliable, and easy to troubleshoot. For example, you can reproduce the exact installation outside of KOTS by downloading a copy of the application files from the cluster with `kots download`, then using those files to install with `helm install`. And, you can use `helm get values` to view the values that were used to install. -The `kots.io/v1beta2` HelmChart custom resource requires configuration. For more information, see [Configure the HelmChart Custom Resource v2](helm-native-v2-using). - For information about the fields and syntax of the HelmChart custom resource, see [HelmChart v2](/reference/custom-resource-helmchart-v2). +### HelmChart v1 and v2 Differences + +To support the use of local registries with version `kots.io/v1beta2` of the HelmChart custom resource, provide the necessary values in the builder field to render the Helm chart with all of the necessary images so that KOTS knows where to pull the images from to push them into the local registry. + +For more information about how to configure the `builder` key, see [Package Air Gap Bundles for Helm Charts](/vendor/helm-packaging-airgap-bundles) and [`builder`](/reference/custom-resource-helmchart-v2#builder) in _HelmChart v2_. + +The `kots.io/v1beta2` HelmChart custom resource has the following differences from `kots.io/v1beta1`: + + + + + + + + + + + + + + + + + + + + + + + + + + + +
HelmChart v1beta2HelmChart v1beta1Description
apiVersion: kots.io/v1beta2apiVersion: kots.io/v1beta1apiVersion is updated to kots.io/v1beta2
releaseNamechart.releaseNamereleaseName is a top level field under spec
N/AhelmVersionhelmVersion field is removed
N/AuseHelmInstalluseHelmInstall field is removed
+ +### About Migrating Existing KOTS Installations to HelmChart v2 + +Existing KOTS installations can be migrated to use the KOTS HelmChart v2 method, without having to reinstall the application. + +There are different steps for migrating to HelmChart v2 depending on the application deployment method used previously. For more information, see [Migrating Existing Installations to HelmChart v2](helm-v2-migrate). + ### Limitations The following limitations apply when deploying Helm charts with the `kots.io/v1beta2` HelmChart custom resource: diff --git a/docs/vendor/helm-native-v2-using.md b/docs/vendor/helm-native-v2-using.md index 11f2dfd1ab..163664868c 100644 --- a/docs/vendor/helm-native-v2-using.md +++ b/docs/vendor/helm-native-v2-using.md @@ -272,14 +272,14 @@ spec: ## Task 4: Support the Use of Local Image Registries {#local-registries} -Local image registries are required for KOTS installations in air-gapped environments with no outbound internet connection. Also, users in online environments can optionally use a local registry. For more information about how users configure a local image registry with KOTS, see [Configuring Local Image Registries](/enterprise/image-registry-settings). +Local image registries are required for KOTS installations in air-gapped environments with no outbound internet connection. Also, users in online environments can optionally use a local registry. For more information about how users configure a local image registry with KOTS, see [Configure Local Image Registries in the Admin Console](/enterprise/image-registry-settings). To support the use of local registries, configure the `builder` key. For more information about how to configure the `builder` key, see [`builder`](/reference/custom-resource-helmchart-v2#builder) in _HelmChart v2_. ## Task 5: Add Backup Labels for Snapshots (KOTS Existing Cluster and kURL Installations Only) {#add-backup-labels-for-snapshots} :::note -The Replicated [snapshots](snapshots-overview) feature for backup and restsore is supported only for existing cluster installations with KOTS. Snapshots are not support for installations with Embedded Cluster. For more information about disaster recovery for installations with Embedded Cluster, see [Disaster Recovery for Embedded Cluster](/vendor/embedded-disaster-recovery.mdx). +The Replicated [snapshots](snapshots-overview) feature for backup and restore is supported only for existing cluster installations with KOTS. Snapshots are not support for installations with Embedded Cluster. For more information about disaster recovery for installations with Embedded Cluster, see [Disaster Recovery for Embedded Cluster](/vendor/embedded-disaster-recovery.mdx). ::: The snapshots feature requires the following labels on all resources in your Helm chart that you want to be included in the backup: @@ -323,7 +323,6 @@ spec: ### About the HelmChart Custom Resource - For more information about the HelmChart custom resource, including the unique requirements and limitations for the keys described in this topic, see [HelmChart v2](/reference/custom-resource-helmchart-v2). diff --git a/docs/vendor/helm-v2-migrate.md b/docs/vendor/helm-v2-migrate.mdx similarity index 92% rename from docs/vendor/helm-v2-migrate.md rename to docs/vendor/helm-v2-migrate.mdx index a606be9f2e..82325c9c2b 100644 --- a/docs/vendor/helm-v2-migrate.md +++ b/docs/vendor/helm-v2-migrate.mdx @@ -1,3 +1,5 @@ +import HelmChartV2Configure from "../partials/helm/_helmchart-v2-configure-step.mdx" + # Migrate Existing Installations to HelmChart v2 This topic describes how to migrate existing Replicated KOTS installations to the KOTS HelmChart `kots.io/v1beta2` (HelmChart v2) installation method, without having to reinstall the application. It also includes information about how to support both HelmChart v1 and HelmChart v2 installations from a single release, and lists frequently-asked questions (FAQs) related to migrating to HelmChart v2. @@ -20,7 +22,7 @@ To migrate existing installations from HelmChart v1 with `useHelmInstall: true` 1. Create a new release containing your application files. -1. For each Helm chart in the release, find the corresponding HelmChart custom resource and update `apiVersion` to `kots.io/v1beta2`. Then update it to rewrite images, inject image pull secrets, and add backup labels. See [Configure the HelmChart Custom Resource v2](helm-native-v2-using). +1. 1. Promote the release to an internal-only channel that your team uses for testing. @@ -60,7 +62,7 @@ To migrate existing installations from HelmChart v1 and `useHelmInstall: false` 1. Create another new release: - 1. For each Helm chart in the release, find the corresponding HelmChart custom resource and update `apiVersion` to `kots.io/v1beta2`. Then update it to rewrite images, inject image pull secrets, and add backup labels. See [Configure the HelmChart Custom Resource v2](helm-native-v2-using). + 1. 1. In the HelmChart custom resource, under the `helmUpgradeFlags` field, add the `--take-ownership` flag: @@ -124,7 +126,7 @@ To migrate applications that were previously packaged as standard Kubernetes man 1. In the release, add your application Helm chart(s). Remove the application manifests for resources that were adopted into the Helm chart(s). - 1. For each Helm chart in the release, add a corresponding KOTS HelmChart custom resource with `apiVersion` set to `kots.io/v1beta2`. Configure the resource to rewrite images, inject image pull secrets, and add backup labels. See [Configure the HelmChart Custom Resource v2](helm-native-v2-using). + 1. 1. In the HelmChart custom resource, under the `helmUpgradeFlags` field, add the `--take-ownership` flag: diff --git a/docs/vendor/helmchart-local-registries.mdx b/docs/vendor/helmchart-local-registries.mdx new file mode 100644 index 0000000000..983e7769aa --- /dev/null +++ b/docs/vendor/helmchart-local-registries.mdx @@ -0,0 +1,74 @@ +# Rewrite Image Names with HelmChart v2 for Local Registries + +This topic describes how to configure the Replicated KOTS HelmChart v2 custom resource to conditionally rewrite image names for your application to support users that will push images to their own local image registry. + +The information in this topic applies only to Helm charts that are deployed with the HelmChart v2 custom resource. + +## Overview + +Local image registries are required for air gap KOTS installations in existing clusters. Also, users in online environments can optionally use a local registry. For more information about how users configure and push images to a local image registry with KOTS, see [Configure Local Image Registries in the Admin Console](/enterprise/image-registry-settings). + +If you deploy any Helm charts with the HelmChart v2 custom resource, you can configure the HelmChart v2 custom resource `optionalValues` key so that KOTS conditionally rewrites the names of images in your Helm values during deployment, depending on if the user configured a local registry. This is required to support the use of local registries for your users. + +## Prerequisite + +The HelmChart `builder` key must be configured for your users to be able to push images to their own local registries. For more information about how to configure the `builder` key, see [`builder`](/reference/custom-resource-helmchart-v2#builder) in _HelmChart v2_. + +## Rewrite Image Names with `optionalValues` + +You will use the following KOTS template functions in the `optionalValues` key to conditionally rewrite image names, depending on if the user configured a local registry: +* [HasLocalRegistry](/reference/template-functions-config-context#haslocalregistry): Returns true if the installation environment is configured to use a local image registry. HasLocalRegistry is always true in air gap installations. HasLocalRegistry is also true in online installations if the user configured a local private registry. +* [LocalRegistryHost](/reference/template-functions-config-context#localregistryhost): Returns the host of the local registry that the user configured. Alternatively, for air gap installations with Embedded Cluster or kURL, LocalRegistryHost returns the host of the built-in registry. +* [LocalRegistryNamespace](/reference/template-functions-config-context#localregistrynamespace): Returns the namespace of the local registry that the user configured. Alternatively, for air gap installations with Embedded Cluster or kURL, LocalRegistryNamespace returns the namespace of the built-in registry. + +
+ What is the registry namespace? + + The registry namespace is the path between the registry and the image name. For example, `images.yourcompany.com/namespace/image:tag`. +
+ +### Rewrite Application Image Names + +For each of your application images, configure the HelmChart custom resource `optionalValues` key so that the image names are conditionally rewritten to the local registry in the user's installation environment. + +**Example:** + +```yaml +# KOTS HelmChart custom resource + +apiVersion: kots.io/v1beta2 +kind: HelmChart +metadata: + name: samplechart +spec: + optionalValues: + # Define the conditional statement in the when field + - when: 'repl{{ HasLocalRegistry }}' + values: + postgres: + image: + registry: '{{repl LocalRegistryHost }}' + repository: '{{repl LocalRegistryNamespace }}'/cloudnative-pg/cloudnative-pg +``` + +### Rewrite the Replicated SDK Image Name + +The default location for the image used by the Replicated SDK Helm chart is `registry.replicated.com/library/replicated-sdk-image`. To conditionally rewrite the Replicated SDK image if the user configured a local registry, configure the HelmChart `optionalValues` key as shown below: + +```yaml +# KOTS HelmChart custom resource +apiVersion: kots.io/v1beta2 +kind: HelmChart +metadata: + name: samplechart +spec: + optionalValues: + # Rewrite Replicated SDK image to local registry + - when: 'repl{{ HasLocalRegistry }}' + values: + replicated: + image: + registry: '{{repl LocalRegistryHost }}' + repository: '{{repl LocalRegistryNamespace }}/library/replicated-sdk-image' +``` +For more information about the Replicated SDK, see [About the Replicated SDK](/vendor/replicated-sdk-overview). \ No newline at end of file diff --git a/docs/vendor/private-images-about.md b/docs/vendor/private-images-about.md index 8d0e2dec83..a7847c13b3 100644 --- a/docs/vendor/private-images-about.md +++ b/docs/vendor/private-images-about.md @@ -19,7 +19,7 @@ The following diagram demonstrates how the proxy registry pulls images from your The proxy registry requires read-only credentials to your private registry to access your application images. See [Connect to an External Registry](/vendor/packaging-private-images). After connecting your registry, the steps the enable the proxy registry vary depending on your application deployment method. For more information, see: -* [Using the Proxy Registry with KOTS Installations](/vendor/private-images-kots) +* [Use the Proxy Registry with Replicated Installers](/vendor/private-images-kots) * [Using the Proxy Registry with Helm Installations](/vendor/helm-image-registry) ## About Allowing Pull-Through Access of Public Images diff --git a/docs/vendor/private-images-kots.mdx b/docs/vendor/private-images-kots.mdx index 9527486115..c72d71fd71 100644 --- a/docs/vendor/private-images-kots.mdx +++ b/docs/vendor/private-images-kots.mdx @@ -1,22 +1,48 @@ import Deprecated from "../partials/helm/_replicated-deprecated.mdx" import StepCreds from "../partials/proxy-service/_step-creds.mdx" import StepCustomDomain from "../partials/proxy-service/_step-custom-domain.mdx" +import RewriteHelmValues from "../partials/proxy-service/_step-rewrite-helm-values.mdx" +import AdditionalNs from "../partials/proxy-service/_step-additional-ns.mdx" +import InjectPullSecret from "../partials/proxy-service/_step-inject-pull-secret.mdx" -# Use the Proxy Registry with KOTS Installations +# Use the Proxy Registry with Replicated Installers -This topic describes how to use the Replicated proxy registry with applications deployed with Replicated KOTS. +This topic describes how to use the Replicated proxy registry with applications deployed with Replicated installers (Embedded Cluster, KOTS existing cluster, or kURL). -## Overview +## Configure Your Application to Use the Proxy Registry -Replicated KOTS automatically creates the required image pull secret for accessing the Replicated proxy registry during application deployment. When possible, KOTS also automatically rewrites image names in the application manifests to the location of the image at `proxy.replicated.com` or your custom domain. +There are different steps for configuring your application to use the proxy registry depending on how your application is packaged and the Replicated installation method used. -### Image Pull Secret +### HelmChart v2 -During application deployment, KOTS automatically creates an `imagePullSecret` with `type: kubernetes.io/dockerconfigjson` that is based on the customer license. This secret is used to authenticate with the proxy registry and grant proxy access to private images. +This section describes how to configure your application to use the proxy registry for HelmChart v2 installations. -For information about how Kubernetes uses the `kubernetes.io/dockerconfigjson` Secret type to authenticate to a private image registry, see [Pull an Image from a Private Registry](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/) in the Kubernetes documentation. +To use the proxy registry with HelmChart v2 installations: -### Image Location Patching (Standard Manifests and HelmChart v1) +1. + +1. + +1. + +1. + +1. + +1. Create a new release with your changes. Promote the release to a development channel. See [Managing Releases with Vendor Portal](releases-creating-releases). + +1. Install in a development environment to test your changes. + +### HelmChart v1 or Standard Manifests + +:::note + +::: + +For standard manifest-based applications or Helm charts deployed with the [HelmChart v1](/reference/custom-resource-helmchart) custom resource, no additional configuration is required. KOTS automatically rewrites image names and injects image pull secrets during deployment for these application types. + +
+ How does KOTS patch image names? For applications packaged with standard Kubernetes manifests (or Helm charts deployed with the [HelmChart v1](/reference/custom-resource-helmchart) custom resource), KOTS automatically patches image names to the location of the image at at `proxy.replicated.com` or your custom domain during deployment. If KOTS receives a 401 response when attempting to load image manifests using the image reference from the PodSpec, it assumes that this is a private image that must be proxied through the proxy registry. @@ -47,29 +73,32 @@ images: - name: quay.io/my-org/api:v1.0.1 newName: proxy.replicated.com/proxy/my-kots-app/quay.io/my-org/api ``` +
-## Enable the Proxy Registry - -This section describes how to enable the proxy registry for applications deployed with KOTS, including how to ensure that image names are rewritten and that the required image pull secret is provided. - -To enable the proxy registry: +To use the proxy registry with HelmChart v1 or applications packaged with tandard manifests: 1. 1. -1. Rewrite images names to the location of the image at `proxy.replicated.com` or your custom domain. Also, ensure that the correct image pull secret is provided for all private images. The steps required to configure image names and add the image pull secret vary depending on your application type: +1. + +1. Create a new release with your changes. Promote the release to a development channel. See [Managing Releases with Vendor Portal](releases-creating-releases). - * **HelmChart v2**: For Helm charts deployed with the[ HelmChart v2](/reference/custom-resource-helmchart-v2) custom resource, configure the HelmChart v2 custom resource to dynamically update image names in your Helm chart and to inject the image pull secret that is automatically created by KOTS. For instructions, see [Configure the HelmChart Custom Resource v2](/vendor/helm-native-v2-using). +1. Install in a development environment to test your changes. - * **Standard Manifests or HelmChart v1**: For standard manifest-based applications or Helm charts deployed with the [HelmChart v1](/reference/custom-resource-helmchart) custom resource, no additional configuration is required. KOTS automatically rewrites image names and injects image pull secrets during deployment for these application types. +### Kubernetes Operators + +To use the proxy registry with applications packaged as Kubernetes Operators: + +1. + +1. - :::note - - ::: +1. - * **Kubernetes Operators**: For applications packaged with Kubernetes Operators, KOTS cannot modify pods that are created at runtime by the Operator. To support the use of private images in all environments, the Operator code should use KOTS functionality to determine the image name and image pull secrets for all pods when they are created. For instructions, see [Reference Images](/vendor/operator-referencing-images) in the _Packaging Kubernetes Operators_ section. +1. For applications packaged with Kubernetes Operators, KOTS cannot modify pods that are created at runtime by the Operator. To support the use of private images in all environments, the Operator code should use KOTS functionality to determine the image name and image pull secrets for all pods when they are created. For instructions, see [Reference Images](/vendor/operator-referencing-images) in the _Packaging Kubernetes Operators_ section. -1. If you are deploying Pods to namespaces other than the application namespace, add the namespace to the `additionalNamespaces` attribute of the KOTS Application custom resource. This ensures that KOTS can provision the `imagePullSecret` in the namespace to allow the Pod to pull the image. For instructions, see [Define Additional Namespaces](operator-defining-additional-namespaces). +1. Create a new release with your changes. Promote the release to a development channel. See [Managing Releases with Vendor Portal](releases-creating-releases). -1. (Optional) Add a custom domain for the proxy registry instead of `proxy.replicated.com`. See [Use Custom Domains](custom-domains-using). \ No newline at end of file +1. Install in a development environment to test your changes. \ No newline at end of file diff --git a/docs/vendor/releases-creating-cli.mdx b/docs/vendor/releases-creating-cli.mdx index 3d82ffeed9..1effcb52c7 100644 --- a/docs/vendor/releases-creating-cli.mdx +++ b/docs/vendor/releases-creating-cli.mdx @@ -47,7 +47,7 @@ To create and promote a release: mv wordpress-1.3.5.tgz manifests ``` - 1. In the same directory that contains the release files, add a HelmChart custom resource for each Helm chart in the release. See [Configuring the HelmChart Custom Resource](helm-native-v2-using). + 1. In the same directory that contains the release files, add a HelmChart custom resource for each Helm chart in the release. See [HelmChart v2](/reference/custom-resource-helmchart-v2). 1. Lint the application manifest files and ensure that there are no errors in the YAML: diff --git a/docs/vendor/replicated-onboarding.mdx b/docs/vendor/replicated-onboarding.mdx index 8c010feb26..70a2f1b4ba 100644 --- a/docs/vendor/replicated-onboarding.mdx +++ b/docs/vendor/replicated-onboarding.mdx @@ -6,6 +6,9 @@ import Requirements from "../partials/embedded-cluster/_requirements.mdx" import SDKOverview from "../partials/replicated-sdk/_overview.mdx" import TestYourChanges from "../partials/getting-started/_test-your-changes.mdx" import UnauthorizedError from "../partials/replicated-sdk/_401-unauthorized.mdx" +import StepCreds from "../partials/proxy-service/_step-creds.mdx" +import RewriteHelmValues from "../partials/proxy-service/_step-rewrite-helm-values.mdx" +import InjectPullSecret from "../partials/proxy-service/_step-inject-pull-secret.mdx" # Onboard to the Replicated Platform @@ -83,11 +86,25 @@ To create an application: export REPLICATED_APP=my-app ``` -### Task 2: Connect Your Image Registry +### Task 2: Rewrite Image Names in Helm Values to Use the Proxy Registry -Add credentials for your image registry to the Vendor Portal. This will allow you to use the Replicated proxy registry in a later step so that you can grant proxy access to application images without exposing registry credentials to your customers. +Update your Helm values to rewrite image names to use the Replicated proxy registry. The proxy regsitry allows you can grant proxy access to application images without exposing registry credentials to your customers. -For more information, see [Connect to an External Registry](/vendor/packaging-private-images). +:::note +You will add a custom domain for the proxy registry as part of [Task 9: Alias Replicated Endpoints with Your Own Domains](#task-9-alias-replicated-endpoints-with-your-own-domains). +::: + +To rewrite image names to use the proxy registry: + +1. + +1. + +1. If your application is deployed as multiple Helm charts, repeat the previous step to rewrite image names in the Helm values for each of your charts. + +1. Continue to the next task. + + As part of [Task 4: Create the Initial Release with KOTS HelmChart and Embedded Cluster Config](#first-release), you will inject a Replicated-generated pull secret into your Helm values that grants authentication to pull your private images through the proxy registry. ### Task 3: Add the Replicated SDK and Package your Chart @@ -146,15 +163,32 @@ To create the first release for your application: For more information, see [Use Embedded Cluster](/vendor/embedded-overview). - 1. Create a new YAML file. In this file, configure the KOTS HelmChart custom resource by completing the workflow in [Configuring the HelmChart Custom Resource](helm-native-v2-using). + 1. Create a new YAML file named `YOUR_CHART_NAME.yaml`. For example, `samplechart.yaml`. In the file, add the following to create the KOTS HelmChart v2 custom resource for your primary Helm chart, updating the fields as needed to match the name and version of the chart: + + ```yaml + # KOTS HelmChart custom resource + apiVersion: kots.io/v1beta2 + kind: HelmChart + metadata: + name: samplechart + spec: + chart: + # name must match the chart name from the .tgz chart archive + name: samplechart + # chartVersion must match the chart version from the .tgz chart archive + chartVersion: 1.2.3 + ``` + For more information about configuring these fields, see [HelmChart v2](custom-resource-helmchart-v2).
What is the KOTS HelmChart custom resource? - The KOTS HelmChart custom resource is required to install Helm charts with KOTS and Embedded Cluster. As part of configuring the KOTS HelmChart custom resource, you will rewrite image names and add image pull secrets to allow your application images to be accessed through the Replicated proxy registry. + The KOTS HelmChart custom resource is required to install Helm charts with KOTS and Embedded Cluster.
- 1. If your application is deployed as multiple Helm charts, repeat the step above to add a separate HelmChart custom resource for each Helm chart archive in the release. + 1. + + 1. If your application is deployed as multiple Helm charts, repeat the previous steps to add and configure a separate HelmChart custom resource for each Helm chart archive in the release. 1. If there are values in any of your Helm charts that need to be set for the installation to succeed, you can set those values using the `values` key in the corresponding HelmChart custom resource. See [Set Helm Values with KOTS](/vendor/helm-optional-value-keys). @@ -464,9 +498,11 @@ To add support for air gap installations: For many applications, running `helm template` with the default values would not yield all the images required to install. In these cases, vendors can pass the additional values in the `builder` key to ensure that the air gap bundle includes all the necessary images. -1. If you have not done so already as part of [Task 4: Create and Install the Initial Release](#first-release), ensure that the `values` key in the KOTS HelmChart custom resource correctly rewrites image names for air gap installations. This is done using the KOTS HasLocalRegistry, LocalRegistryHost, and LocalRegistryNamespace template functions to render the location of the given image in the user's own local registry. +1. For each Helm chart in your release, update the KOTS HelmChart custom resource `optionalValues` key to conditionally rewrite image names for air gap installations. This is done using the KOTS HasLocalRegistry, LocalRegistryHost, and LocalRegistryNamespace template functions to render the location of the given image in the user's own local registry. + + For more information, see [Rewrite Image Names with HelmChart v2 for Local Registries](/vendor/helmchart-local-registries). - For more information, see [Rewrite Image Names](/vendor/helm-native-v2-using#rewrite-image-names) in _Configuring the HelmChart Custom Resource v2_. +1. If your application uses any public Docker Hub images that are rate limited, configure the HelmChart v2 custom resource `values` key to add a Replicated image pull secret to any Docker images that could be rate-limited. This pull secret allows any users that configure a local registry to avoid rate limits. For more information, see [Avoid Docker Hub Rate Limits](/enterprise/image-registry-rate-limits). 1. Create and promote a new release with your changes. For more information, see [Manage Releases with the Vendor Portal](releases-creating-releases) or [Managing Releases with the CLI](releases-creating-cli). diff --git a/docs/vendor/replicated-sdk-installing.mdx b/docs/vendor/replicated-sdk-installing.mdx index 4517e4e00d..f365fa8f01 100644 --- a/docs/vendor/replicated-sdk-installing.mdx +++ b/docs/vendor/replicated-sdk-installing.mdx @@ -42,7 +42,7 @@ To install the SDK as a subchart: 1. Add the chart archive to a new release. For more information, see [Manage Releases with the CLI](/vendor/releases-creating-cli) or [Managing Releases with the Vendor Portal](/vendor/releases-creating-releases). -1. (Optional) Add a KOTS HelmChart custom resource to the release to support installation with Embedded Cluster, KOTS, or kURL. For more information, see [Configure the HelmChart Custom Resource v2](/vendor/helm-native-v2-using). +1. (Optional) Add a KOTS HelmChart custom resource to the release to support installation with Embedded Cluster, KOTS, or kURL. For more information, see [HelmChart v2](/reference/custom-resource-helmchart-v2). 1. Save and promote the release to an internal-only channel used for testing, such as the default Unstable channel. diff --git a/docs/vendor/snapshots-configuring-backups.md b/docs/vendor/snapshots-configuring-backups.md index 95fd9dfa66..c52eaa0b5f 100644 --- a/docs/vendor/snapshots-configuring-backups.md +++ b/docs/vendor/snapshots-configuring-backups.md @@ -73,9 +73,46 @@ To configure snapshots for your application: ``` -1. (Optional) Configure manifest exclusions. By default, Velero also includes backups of all of the Kubernetes objects in the namespace. +1. For any Helm charts in your release that are deployed with the [HelmChart v2](/reference/custom-resource-helmchart-v2) custom resource, configure the HelmChart custom resource `optionalValues` key to conditionally add the following labels to all resources that you want to be included in backups: + * `kots.io/backup: velero` + * `kots.io/app-slug: APP_SLUG`, where `APP_SLUG` is the unique slug of the application. You can inject the application slug using the `repl{{ LicenseFieldValue "appSlug" }}` template function. - To exclude any manifest file, add a [`velero.io/exclude-from-backup=true`](https://velero.io/docs/v1.5/resource-filtering/#veleroioexclude-from-backuptrue) label to the manifest to be excluded. The following example shows the Secret manifest file with the `velero.io/exclude-from-backup` label: + Use the following `when` statement so that the labels are only applied to resources when the customer license has the `isSnapshotSupported` entitlement: + + ```yaml + when: repl{{ LicenseFieldValue "isSnapshotSupported" }} + ``` + + For more information about working with the `optionalValues` key, see [optionalValues](/reference/custom-resource-helmchart-v2#optionalvalues) in _HelmChart v2_. + + **Example:** + + ```yaml + # kots.io/v1beta2 HelmChart custom resource + + apiVersion: kots.io/v1beta2 + kind: HelmChart + metadata: + name: samplechart + spec: + optionalValues: + # add kots backup labels only when the + # license supports snapshots + - when: repl{{ LicenseFieldValue "isSnapshotSupported" }} + recursiveMerge: true + values: + mariadb: + commonLabels: + kots.io/backup: velero + kots.io/app-slug: repl{{ LicenseFieldValue "appSlug" }} + podLabels: + kots.io/backup: velero + kots.io/app-slug: repl{{ LicenseFieldValue "appSlug" }} + ``` + +1. (Optional) Configure exclusions. By default, Velero includes backups of all of the Kubernetes objects in the namespace. + + To exclude a resource from backups, add the [`velero.io/exclude-from-backup=true`](https://velero.io/docs/v1.5/resource-filtering/#veleroioexclude-from-backuptrue) label. The following example shows a Secret with the `velero.io/exclude-from-backup` label: ```yaml apiVersion: apps/v1 diff --git a/docs/vendor/tutorial-config-create-release.md b/docs/vendor/tutorial-config-create-release.md index 4daa0c11ea..4ed970e10d 100644 --- a/docs/vendor/tutorial-config-create-release.md +++ b/docs/vendor/tutorial-config-create-release.md @@ -129,6 +129,5 @@ Create a customer with the KOTS entitlement so that you can install the release ## 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-embedded-cluster-create-release.mdx b/docs/vendor/tutorial-embedded-cluster-create-release.mdx index b5132b4171..d696b28b8c 100644 --- a/docs/vendor/tutorial-embedded-cluster-create-release.mdx +++ b/docs/vendor/tutorial-embedded-cluster-create-release.mdx @@ -127,6 +127,5 @@ Create a customer with the Embedded Cluster entitlement so that you can install ## 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-kots-helm-create-release.md b/docs/vendor/tutorial-kots-helm-create-release.md index cd592beb65..75eba05622 100644 --- a/docs/vendor/tutorial-kots-helm-create-release.md +++ b/docs/vendor/tutorial-kots-helm-create-release.md @@ -117,7 +117,6 @@ To create a release: 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 +## Related Topic -* [About Channels and Releases](/vendor/releases-about) -* [Configuring the HelmChart Custom Resource](/vendor/helm-native-v2-using) \ No newline at end of file +[About Channels and Releases](/vendor/releases-about) \ No newline at end of file diff --git a/netlify.toml b/netlify.toml index 259f5ef351..031dd27715 100644 --- a/netlify.toml +++ b/netlify.toml @@ -126,7 +126,7 @@ [[redirects]] from="https://docs.replicated.com/vendor/helm-release" - to="https://docs.replicated.com/vendor/helm-native-v2-using" + to="https://docs.replicated.com/reference/custom-resource-helmchart-v2" [[redirects]] from="https://docs.replicated.com/vendor/helm-overview" diff --git a/scripts/update_docs_links.sh b/scripts/update_docs_links.sh index 6b12d68e1e..37e165813d 100755 --- a/scripts/update_docs_links.sh +++ b/scripts/update_docs_links.sh @@ -5,9 +5,11 @@ # Define replacement patterns with the format "[search pattern]:[replacement]" patterns=( - "Replicated Onboarding:Onboard to the Replicated Platform" + # "Replicated Onboarding:Onboard to the Replicated Platform" # Add patterns here, one per line # "Old Title:New Title" + "Configure Local Image Registries:Configure Local Image Registries in the Admin Console" + "Configuring Local Image Registries:Configure Local Image Registries in the Admin Console" ) # Count of files processed and replacements made @@ -29,11 +31,10 @@ for file in $files; do # Split the pattern_pair into search and replacement parts IFS=':' read -r search replacement <<< "$pattern_pair" - # Check if file contains the pattern - if grep -q "see \[${search}\]" "$file" || grep -q "See \[${search}\]" "$file"; then + # Check if file contains the pattern - look for the link format [Title] + if grep -q "\[${search}\]" "$file"; then # Make the replacements - use | as delimiter instead of / to avoid issues with paths - sed -i '' "s|see \[${search}\]|see \[${replacement}\]|g" "$file" - sed -i '' "s|See \[${search}\]|See \[${replacement}\]|g" "$file" + sed -i '' "s|\[${search}\]|\[${replacement}\]|g" "$file" echo "In $file:" echo " Replaced: '$search' → '$replacement'" diff --git a/sidebars.js b/sidebars.js index ff4a157417..3543bb12c9 100644 --- a/sidebars.js +++ b/sidebars.js @@ -264,8 +264,9 @@ const sidebars = { label: 'Configure the HelmChart Custom Resource', items: [ 'vendor/helm-native-about', - 'vendor/helm-native-v2-using', + // 'vendor/helm-native-v2-using', 'vendor/helm-packaging-airgap-bundles', + // 'vendor/helmchart-local-registries', 'vendor/helm-optional-value-keys', 'vendor/helm-v2-migrate', ], @@ -396,6 +397,7 @@ const sidebars = { type: 'category', label: 'Configure Local Image Registries', items: [ + 'vendor/helmchart-local-registries', 'enterprise/image-registry-settings', 'enterprise/image-registry-rate-limits', ],