Merge branch 'main' into local-deploy-explain-domain

Author: viniciusdc

docs/community/maintainers/release-process.md

@@ -47,24 +47,15 @@ For example, the first Nebari CalVer release was `2022.10.1`. If a hotfix releas
 
 We use the following guidelines to manage `git` branches by assigning certain roles to particular branches.
 
-- [`develop`](https://github.com/nebari-dev/nebari/tree/develop) - Represents the active development branch and is the _default_ branch on the GitHub repository.
+- [`main`](https://github.com/nebari-dev/nebari/tree/main) - Represents the active development branch and is the _default_ branch on the GitHub repository.
 
-- [`main`](https://github.com/nebari-dev/nebari/tree/main) - Represents a production-ready state of the code-base, with an appropriate tag to match the most recent release.
+## Release Tags
 
-- `release/YYYY-MM-releaseNumber` - Represents the branch for the upcoming release and only briefly exist while actively preparing for the release.
+- `YYYY-MM-releaseNumber` - Represents the tag for a particular release.
 
 ### Process
 
-Although this process is captured in the [release checklist template](https://github.com/nebari-dev/nebari/issues/new?assignees=&labels=type%3A+release+%F0%9F%8F%B7&template=release-checklist.md&title=%5BRELEASE%5D+%3Cversion%3E), it's worth making clear how branches are managed.
-
-- Active development occurs against the `develop` branch.
-- When it's time for a release, the Release Captain will create the release branch `release/YYYY-MM-releaseNumber` and prepare the branch for the release. At times, this might mean cherry-picking commits that are needed for this release and at other times, this might mean merging `develop` into this release branch.
-- As soon as this release branch is ready, the Release Captain can open a pull request against `main`. From here, all of the changes that are included in the release should be visible in the "Files changed" section of the pull request.
-- Once CI passes, all manual tests are successful and the team is happy with the changes, the Release Captain can complete the release checklist and cut the release.
-
-#### Hotfixes
-
-In the event that a patch or hotfix release is needed, release process is the same as outlined above. The only difference is that the commits that are merged into the hotfix release branch will need to be cherry-picked from the `develop` branch.
+The release process is captured in the [release checklist template](https://github.com/nebari-dev/nebari/blob/main/.github/ISSUE_TEMPLATE/release-checklist.md). In the event that a patch or hotfix release is needed, release process is the same as outlined above.
 
 ## Related packages
 

docs/community/maintainers/reviewer-guidelines.md

@@ -62,7 +62,7 @@ Only maintainers can merge pull requests. Please follow these guidelines:
   - If the contribution is made to the `nebari-dev/nebari` repository, then you'll need to trigger the Kubernetes tests
     by commenting `/bot run tests` on the PR.
   - If the contribution is made to the `nebari-dev/nebari-docs` repository, then make sure to check the Netlify build and preview.
-- In case of merge conflicts, ask the PR submitter to rebase on `develop`.
+- In case of merge conflicts, ask the PR submitter to rebase on `main`.
 - Squashing commits or cleaning up commit messages of a PR that you consider too messy is OK.
   Remember to retain the original author’s name when doing this.
 - When you want to reject a PR: if it’s very straightforward, you can close it and explain why. If it’s not,

docs/community/nebari-tests.md

@@ -91,7 +91,7 @@ To test on cloud Kubernetes, deploy Nebari in the normal way on the cloud, but m
 - [Use a development branch](#use-a-development-branch) to specify the Docker images based on the latest development code in `nebari-config.yaml`.
 
 :::warning
-Testing your contribution by deploying Nebari on the cloud (AWS, GCP, Azure, and Digital Ocean) can consume a lot of time and resources.
+Testing your contribution by deploying Nebari on the cloud (AWS, GCP, and Azure) can consume a lot of time and resources.
 Always prefer local testing when possible.
 It will be easier to debug, may be quicker to deploy, and is likely to be less expensive.
 :::

docs/docs/explanations/advanced-configuration.md

@@ -265,7 +265,6 @@ domain: demo.nebari.dev
 
 `provider`: Determines the cloud provider used to deploy infrastructure related resources on Nebari. Possible values are:
 
-- `do` for DigitalOcean
 - `aws` for Amazon Web Services
 - `gcp` for Google Could Provider
 - `azure` for Microsoft Azure
@@ -316,7 +315,7 @@ The CI/CD workflow that is best for you will depend on your organization, but th
 - Advanced Nebari users may also want to add a step in their deployment flow that includes a `nebari render` so that the administrator may preview the resulting diffs to IaC and/or CI/CD files before `nebari deploy` is executed.
 
 :::note
-In order for your CI/CD pipeline to be able to deploy changes into your Nebari cloud hosting provider, you must set the appropriate authentication environment variables for your GitLab or GitHub CI/CD execution environment. See the Authentication section for deploing to [AWS](https://www.nebari.dev/docs/how-tos/nebari-aws/#authentication), [Azure](https://www.nebari.dev/docs/how-tos/nebari-azure#authentication), [GCP](https://www.nebari.dev/docs/how-tos/nebari-gcp/#authentication), or [Digital Ocean](https://www.nebari.dev/docs/how-tos/nebari-do/#authentication) for Nebari's required variables. Guidance on how to set these for your repository/project can be found in the documentation for [GitHub Actions](https://docs.github.com/en/actions/learn-github-actions/variables) and [GitLab CI/CD](https://docs.gitlab.com/ee/ci/variables/).
+In order for your CI/CD pipeline to be able to deploy changes into your Nebari cloud hosting provider, you must set the appropriate authentication environment variables for your GitLab or GitHub CI/CD execution environment. See the Authentication section for deploing to [AWS](https://www.nebari.dev/docs/how-tos/nebari-aws/#authentication), [Azure](https://www.nebari.dev/docs/how-tos/nebari-azure#authentication), or [GCP](https://www.nebari.dev/docs/how-tos/nebari-gcp/#authentication) for Nebari's required variables. Guidance on how to set these for your repository/project can be found in the documentation for [GitHub Actions](https://docs.github.com/en/actions/learn-github-actions/variables) and [GitLab CI/CD](https://docs.gitlab.com/ee/ci/variables/).
 :::
 
 ### Certificates

docs/docs/explanations/advanced-provider-configuration.md

@@ -98,6 +98,103 @@ amazon_web_services:
   permissions_boundary: arn:aws:iam::01234567890:policy/<permissions-boundary-policy-name>
 ```
 
+### EKS KMS ARN (Optional)
+
+You can use AWS Key Management Service (KMS) to enhance security by encrypting Kubernetes secrets in
+Amazon Elastic Kubernetes Service (EKS). This approach adds an extra layer of protection for sensitive
+information, like passwords, credentials, and TLS keys, by applying user-managed encryption keys to Kubernetes
+secrets, supporting a [defense-in-depth strategy](https://aws.amazon.com/blogs/containers/using-eks-encryption-provider-support-for-defense-in-depth/).
+
+Nebari supports setting an existing KMS key while deploying Nebari to implement encryption of secrets
+created in Nebari's EKS cluster. The KMS key must be a **Symmetric** key set to **encrypt and decrypt** data.
+
+:::warning
+Enabling EKS cluster secrets encryption, by setting `amazon_web_services.eks_kms_arn`, is an
+_irreversible_ action and re-deploying Nebari to try to remove a previously set `eks_kms_arn` will fail.
+On the other hand, if you try to change the KMS key in use for cluster encryption, by re-deploying Nebari
+after setting a _different_ key ARN, the re-deploy should succeed but the KMS key used for encryption will
+not actually change in the cluster config and the original key will remain set. The integrity of a faulty
+deployment can be restored, following a failed re-deploy attempt to remove a previously set KMS key, by
+simply re-deploying Nebari while ensuring `eks_kms_arn` is set to the original KMS key ARN.
+:::
+
+:::danger
+If the KMS key used for envelope encryption of secrets is ever deleted, then there is no way to recover
+the EKS cluster.
+:::
+
+:::note
+After enabling cluster encryption on your cluster, you must encrypt all existing secrets with the
+new key by running the following command:
+`kubectl get secrets --all-namespaces -o json | kubectl annotate --overwrite -f - kms-encryption-timestamp="time value"`
+Consult [Encrypt K8s secrets with AWS KMS on existing clusters](https://docs.aws.amazon.com/eks/latest/userguide/enable-kms.html) for more information.
+:::
+
+Here is an example of how you would set KMS key ARN in `nebari-config.yaml`.
+
+```yaml
+amazon_web_services:
+  # the arn for the AWS Key Management Service key
+  eks_kms_arn: "arn:aws:kms:us-west-2:01234567890:key/<aws-kms-key-id>"
+```
+
+### Launch Templates (Optional)
+
+Nebari supports configuring launch templates for your node groups, enabling you to customize settings like the AMI ID and pre-bootstrap commands. This is particularly useful if you need to use a custom AMI or perform specific actions before the node joins the cluster.
+
+:::warning
+If you add a `launch_template` to an existing node group that was previously created without one, AWS will treat this as a change requiring the replacement of the entire node group. This action will trigger a reallocation of resources, effectively destroying the current node group and recreating it. This behavior is due to how AWS handles self-managed node groups versus those using launch templates with custom settings.
+:::
+
+:::tip
+To avoid unexpected downtime or data loss, consider creating a new node group with the launch template settings and migrating your workloads accordingly. This approach allows you to implement the new configuration without disrupting your existing resources.
+:::
+
+#### Configuring a Launch Template
+
+To configure a launch template for a node group in your `nebari-config.yaml`, add the `launch_template` section under the desired node group:
+
+```yaml
+amazon_web_services:
+  region: us-west-2
+  kubernetes_version: "1.18"
+  node_groups:
+    custom-node-group:
+      instance: "m5.large"
+      min_nodes: 1
+      max_nodes: 5
+      gpu: false  # Set to true if using GPU instances
+      launch_template:
+        # Replace with your custom AMI ID
+        ami_id: ami-0abcdef1234567890
+        # Command to run before the node joins the cluster
+        pre_bootstrap_command: |
+          #!/bin/bash
+          # This script is executed before the node is bootstrapped
+          # You can use this script to install additional packages or configure the node
+          # For example, to install the `htop` package, you can run:
+          # sudo apt-get update
+          # sudo apt-get install -y htop"
+```
+
+**Parameters:**
+
+- `ami_id` (Optional): The ID of the custom AMI to use for the nodes in this group; this assumes the AMI provided is an EKS-optimized AMI derivative. If specified, the `ami_type` is automatically set to `CUSTOM`.
+- `pre_bootstrap_command` (Optional): A command or script to execute on the node before
+  it joins the Kubernetes cluster. This can be used for custom setup or configuration
+  tasks. The format should be a single string in conformation with the shell syntax.
+  This command is injected in the `user_data` field of the launch template. For more
+  information, see [User Data](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html).
+
+> If you're using a `launch_template` with a custom `ami_id`, there's an issue with updating the `scaling.desired_size` via Nebari configuration (terraform). To scale up, you must recreate the node group or adjust the scaling settings directly in the AWS Console UI (recommended). We are aware of this inconsistency and plan to address it in a future update.
+
+:::note
+If an `ami_id` is not provided, AWS will use the default Amazon Linux 2 AMI for the
+specified instance type. You can find the latest optimized AMI IDs for Amazon EKS in your
+cluster region by inspecting its respective SSM parameters. For more information, see
+[Retrieve recommended Amazon Linux AMI IDs](https://docs.aws.amazon.com/eks/latest/userguide/retrieve-ami-id.html).
+:::
+
 </TabItem>
 
 <TabItem value="azure" label="Azure">
@@ -129,37 +226,6 @@ azure:
 
 </TabItem>
 
-<TabItem value="do" label="DigitalOcean">
-
-DigitalOcean has a restriction with autoscaling in that the minimum nodes allowed (`min_nodes` = 1) is one but is by far the least expensive provider even accounting for `spot/pre-emptible` instances.
-In addition, Digital Ocean doesn't have accelerator/gpu support.
-
-Digital Ocean is a good choice for trying out Nebari, but we recommend selecting a different provider for your production Nebari deployment.
-
-To see available instance types refer to [Digital Ocean Instance Types](https://www.digitalocean.com/docs/droplets/).
-Additionally the Digital Ocean cli `doctl` has [support for listing droplets](https://www.digitalocean.com/docs/apis-clis/doctl/reference/compute/droplet/list/).
-
-```yaml
-digital_ocean:
-  region: nyc3
-  kubernetes_version: "1.21.10-do.0"
-  node_groups:
-    general:
-      instance: "g-4vcpu-16gb"
-      min_nodes: 1
-      max_nodes: 1
-    user:
-      instance: "g-2vcpu-8gb"
-      min_nodes: 1
-      max_nodes: 5
-    worker:
-      instance: "g-2vcpu-8gb"
-      min_nodes: 1
-      max_nodes: 5
-```
-
-</TabItem>
-
 <TabItem value="existing" label="Existing Kubernetes clusters">
 
 Originally designed for Nebari deployments on a "local" minikube cluster, this feature has now expanded to allow users to deploy Nebari to any existing kubernetes cluster.
@@ -221,7 +287,6 @@ local:
 :::note
 Many of the cloud providers regularly update their internal **Kubernetes versions** so if you wish to specify a particular version, please check the following resources.
 This is _completely optional_ as Nebari will, by default, select the most recent version available for your preferred cloud provider:
-[Digital Ocean](https://docs.digitalocean.com/products/kubernetes/changelog/);
 [Google Cloud Platform](https://cloud.google.com/kubernetes-engine/docs/release-notes-stable);
 [Amazon Web Services](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html);
 [Microsoft Azure](https://docs.microsoft.com/en-us/azure/aks/supported-kubernetes-versions?tabs=azure-cli).

docs/docs/explanations/architecture.mdx

@@ -52,11 +52,7 @@ import TabItem from '@theme/TabItem';
 ![GCP Architecture Diagram](/img/explanations/architecture-diagram-gcp.png)
 
 </TabItem>
-<TabItem value="do" label="Digital Ocean">
 
-![DO Architecture Diagram](/img/explanations/architecture-diagram-do.png)
-
-</TabItem>
 <TabItem value="aws" label="Amazon AWS">
 
 ![AWS Architecture Diagram](/img/explanations/architecture-diagram-aws.png)

docs/docs/faq.md

@@ -48,8 +48,8 @@ If you'd like to retain the latest version of an environment and only remove spe
 ## How do I use preemptible and spot instances on Nebari?
 
 A preemptible or spot VM is an instance that you can create and run at a much lower price than normal instances. Azure
-and Google Cloud platform use the term preemptible, while AWS uses the term spot, and Digital Ocean doesn't support
-these types of instances. However, the cloud provider might stop these instances if it requires access to those
+and Google Cloud platform use the term preemptible, while AWS uses the term spot.
+However, the cloud provider might stop these instances if it requires access to those
 resources for other tasks. Preemptible instances are excess Cloud Provider's capacity, so their availability varies with
 usage.
 
@@ -84,10 +84,6 @@ Spot instances aren't supported at this moment.
 
 Preemptible instances aren't supported at this moment.
 
-##### Digital Ocean
-
-Digital Ocean doesn't support these type of instances.
-
 ## Why doesn't my code recognize the GPU(s) on Nebari?
 
 First be sure you chose a [GPU-enabled server when you selected a profile][selecting a profile]. Next, if you're using PyTorch, see [Using GPUs on Nebari][using gpus]. If it's still not working for you, be sure your environment includes a GPU-specific version of either PyTorch or TensorFlow, i.e. `pytorch-gpu` or `tensorflow-gpu`. Also note that `tensorflow>=2` includes both CPU and GPU capabilities, but if the GPU is still not recognized by the library, try removing `tensorflow` from your environment and adding `tensorflow-gpu` instead.

docs/docs/get-started/cloud-providers.mdx

@@ -36,17 +36,8 @@ import TabItem from '@theme/TabItem';
 For detailed instructions on how to deploy Nebari on **GCP** visit the [How to deploy Nebari on GCP][nebari-gcp] section.
 
 </TabItem>
-<TabItem value="do" label="Digital Ocean">
 
-<div class="text--center">
-  <img src="/img/get-started/started-digital-ocean-logo.png" width={420} />
-</div>
-
-[DigitalOcean](https://docs.digitalocean.com/products/kubernetes/) is a cloud hosting provider that offers cloud computing services and Infrastructure as a Service (IaaS) known for its pricing and scalability.
 
-For detailed instructions on how to deploy Nebari on **Digital Ocean** visit the [How to deploy Nebari on Digital Ocean][nebari-do] section.
-
-</TabItem>
 <TabItem value="aws" label="Amazon AWS">
 
 <div class="text--center">
@@ -75,7 +66,6 @@ For detailed instructions on how to deploy Nebari on **Azure** visit the [How to
 
 [nebari-aws]: /how-tos/nebari-aws.md
 [nebari-azure]: /how-tos/nebari-azure.md
-[nebari-do]: /how-tos/nebari-do.md
 [nebari-gcp]: /how-tos/nebari-gcp.md
 [nebari-local]: /how-tos/nebari-local.md
 [nebari-how-tos]: /how-tos/index.mdx

docs/docs/get-started/deploy.mdx

@@ -29,7 +29,7 @@ If you are not sure which option to choose, a cloud installation is likely your
 :::note
 The cloud installation is based on Kubernetes, but knowledge of Kubernetes is **NOT** required nor is in-depth knowledge about the specific provider required either.
 
-Currently, Nebari supports [Amazon AWS][nebari-aws], [DigitalOcean][nebari-do], [Google GCP][nebari-gcp], and [Azure][nebari-azure].
+Currently, Nebari supports [Amazon AWS][nebari-aws], [Google GCP][nebari-gcp], and [Azure][nebari-azure].
 :::
 
 </TabItem>
@@ -73,14 +73,12 @@ For instructions on installing and deploying Nebari on a particular cloud provid
 
 - [Deploying Nebari on AWS][nebari-aws]
 - [Deploying Nebari on Azure][nebari-azure]
-- [Deploying Nebari on Digital Ocean][nebari-do]
 - [Deploying Nebari on GCP][nebari-gcp]
 
 <!-- Internal links -->
 
 [nebari-aws]: /how-tos/nebari-aws.md
 [nebari-azure]: /how-tos/nebari-azure.md
-[nebari-do]: /how-tos/nebari-do.md
 [nebari-gcp]: /how-tos/nebari-gcp.md
 [nebari-local]: /how-tos/nebari-local.md
 [nebari-deploy]: /get-started/deploy.mdx

docs/docs/get-started/installing-nebari.md

@@ -98,7 +98,6 @@ Already made your mind about deployment? Check our handy how-to-guides:
 
 - [Deploying Nebari on AWS][nebari-aws]
 - [Deploying Nebari on Azure][nebari-azure]
-- [Deploying Nebari on Digital Ocean][nebari-do]
 - [Deploying Nebari on GCP][nebari-gcp]
 - [Deploying Nebari on a local cluster][nebari-local]- using [`kind`](https://kind.sigs.k8s.io/) no cloud required
 
@@ -107,7 +106,6 @@ Already made your mind about deployment? Check our handy how-to-guides:
 [advanced-configuration]: /explanations/advanced-configuration.md
 [nebari-aws]: /how-tos/nebari-aws.md
 [nebari-azure]: /how-tos/nebari-azure.md
-[nebari-do]: /how-tos/nebari-do.md
 [environment-management]: /how-tos/nebari-environment-management.md
 [nebari-extension-system]: /how-tos/nebari-extension-system.md
 [nebari-gcp]: /how-tos/nebari-gcp.md