add general deployment documentation#686
Conversation
❌ Deploy Preview for nebari-docs2 failed.
|
| description: Common GitOps setup, deploy, verify, update, and destroy steps shared by all NIC-managed providers. | ||
| --- | ||
|
|
||
| This page covers the lifecycle steps that are common across all NIC-managed providers: setting up a GitOps repository, storing credentials, running `nic deploy`, verifying the cluster, signing in for the first time, updating, and tearing down. |
There was a problem hiding this comment.
Small thing: since the provider pages drive the actual flow and this page fills in the shared steps, it might help to say that at the top (something like "start on your provider's page, this covers the steps it links to").
This will make it clear to open the provider page first.
| ## Configuration | ||
|
|
||
| Download a starter config from your provider's page. At minimum, every config requires these fields: | ||
|
|
||
| ```yaml | ||
| project_name: my-cluster # lowercase alphanumeric, hyphens, underscores | ||
| domain: nebari.example.com # a hostname you own | ||
|
|
||
| certificate: | ||
| acme: | ||
| email: you@example.com # required for Let's Encrypt; renewal notices go here | ||
|
|
||
| git_repository: | ||
| url: "https://github.com/<your-org>/<your-gitops-repo>.git" | ||
| path: clusters/my-cluster # subdirectory in the repo; conventionally matches project_name | ||
| auth: | ||
| token_env: GIT_TOKEN # matches GIT_TOKEN set in .env | ||
|
|
||
| cluster: | ||
| <provider>: | ||
| # Provider-specific fields — see your provider's page for required options. | ||
| ``` | ||
|
|
||
| For the full schema, see the [NIC configuration reference](https://github.com/nebari-dev/nebari-infrastructure-core/blob/main/docs/design-doc/appendix/16-configuration-reference.md). |
There was a problem hiding this comment.
I noticed the provider pages already include a complete starter config, so this generic version felt a bit redundant to me, and it's another place to keep in sync when a field changes.
Maybe we keep just the schema-reference link here and let each provider page own the full config?
| After deploy completes, your cluster needs a DNS record to be reachable: | ||
|
|
||
| - **Cloudflare-managed domains:** add `CLOUDFLARE_API_TOKEN` to your `.env` with `Zone:DNS:Edit` permission on your domain's zone. `nic` creates the record automatically. | ||
| - **All other DNS providers:** `nic` prints the load balancer's IP address or hostname at the end of deploy. Create an **A record** at your DNS provider pointing your domain to that value. The cluster will not be reachable over HTTPS until the record propagates. |
There was a problem hiding this comment.
Small inconsistency I noticed: here we say to create an "A record", but the AWS page calls it an "A/CNAME record". It might be worth aligning the two pages on the same wording to avoid confusion.
| - **Automatic TLS** for every service you publish ([cert-manager](https://cert-manager.io/) + Let's Encrypt). | ||
| - **Single sign-on** across all services ([Keycloak](https://www.keycloak.org/)). | ||
| - **Ingress routing** for any service you expose ([Envoy Gateway](https://gateway.envoyproxy.io/)). | ||
| - **GitOps-driven updates:** future changes flow through a Git repo you own ([ArgoCD](https://argo-cd.readthedocs.io/)). |
There was a problem hiding this comment.
Small wording thing: this bullet lost the "roll out or roll back" detail the AWS page had. Spelling out that you deploy or revert apps by committing to the repo would make it less vague, I think.
|
|
||
| ```bash | ||
| GIT_TOKEN=github_pat_... # read+write, used by nic during deploy | ||
| ARGOCD_GIT_TOKEN=github_pat_... # read-only, used by ArgoCD to pull manifests |
There was a problem hiding this comment.
Might be worth adding "optional" here. This is up to you.
Co-authored-by: Khuyen Tran <khuyentran@codecut.ai>
|
Thanks for the review, @khuyentran1401! I addressed all the comments. If you could give it another look, I would really appreciate it! |
| --- | ||
|
|
||
| This page covers the lifecycle steps that are common across all NIC-managed providers: setting up a GitOps repository, storing credentials, running `nic deploy`, verifying the cluster, signing in for the first time, updating, and tearing down. | ||
| Start on your provider's page — it walks you through the full deployment and links here for the shared steps. This page covers the lifecycle steps that are common across all NIC-managed providers: setting up a GitOps repository, storing credentials, running `nic deploy`, verifying the cluster, signing in for the first time, updating, and tearing down. |
There was a problem hiding this comment.
It is easy for readers who skim to miss this. Maybe add it in a note block?
Syntax:
:::note
Your content
:::
|
|
||
| Start on your provider's page — it walks you through the full deployment and links here for the shared steps. This page covers the lifecycle steps that are common across all NIC-managed providers: setting up a GitOps repository, storing credentials, running `nic deploy`, verifying the cluster, signing in for the first time, updating, and tearing down. | ||
|
|
||
| Provider-specific prerequisites, configuration, and cost notes are on each provider's page ([AWS](/docs/how-tos/providers/aws)). |
There was a problem hiding this comment.
This one only lists one provider. Can you link to this provide page instead? /docs/how-tos/providers
This page contains the support matrix and will be available after #685 is merged.
|
@andrewfulton9 After this merges, let's split That only became clear to me after I scoped #680, so it's not on your work here. I'd merge this as-is and do the split as follow-up. |
Co-authored-by: Khuyen Tran <khuyentran@codecut.ai>
|
Thanks for the feedback, @khuyentran1401! I addressed all the above comments. CI will fail until #685 is merged in |
Reference Issues or PRs
Closes #680
What does this implement/fix?
Put a
xin the boxes that applyTesting
Documentation
Access-centered content checklist
Text styling
H1or#in markdown).Non-text content
Any other comments?