-
Notifications
You must be signed in to change notification settings - Fork 486
add new terraform docs #34221
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
add new terraform docs #34221
Conversation
|
@jubrad thanks for reviving this! |
kay-kim
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey ... won't have time to add a patch to this today (double-checking the upgrade)... so, am leaving some comments for now in case people have a window free.
Depending on when, I'll continue reviewing or patching. Heads up ... I'm out starting Monday next week.
| {{</ tip >}} | ||
| | Guide | Description | | ||
| |-------|-------------| | ||
| | [Terraform Provider](/installation/install-on-aws/terraform-module/) | Install Materialize on AWS using our new Unified Terraform Provider | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the Description for the new Unified .... Do we want to add Recommended annotation? like
| Recommended. Install Materialize ...
| | Guide | Description | | ||
| |-------|-------------| | ||
| | [Terraform Provider](/installation/install-on-aws/terraform-module/) | Install Materialize on AWS using our new Unified Terraform Provider | | ||
| | [Terraform Provider (legacy)](/installation/install-on-aws/legacy-terraform-module/) | Install Materialize on AWS using our Terraform Provider (legacy) | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The description "using our Terraform..." -> "using our legacy Terraform Provider"
doc/user/content/installation/install-on-aws/appendix-deployment-guidelines.md
Outdated
Show resolved
Hide resolved
doc/user/content/installation/install-on-aws/appendix-deployment-guidelines.md
Outdated
Show resolved
Hide resolved
doc/user/content/installation/install-on-aws/appendix-deployment-guidelines.md
Outdated
Show resolved
Hide resolved
doc/user/content/installation/install-on-aws/terraform-module/_index.md
Outdated
Show resolved
Hide resolved
doc/user/content/installation/install-on-aws/terraform-module/_index.md
Outdated
Show resolved
Hide resolved
doc/user/content/installation/install-on-aws/terraform-module/_index.md
Outdated
Show resolved
Hide resolved
|
|
||
| ```hcl | ||
| name_prefix = "simple-demo" | ||
| aws_region = "us-east-1" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we mention as a comment that they can change the aws_region?
doc/user/content/installation/install-on-aws/terraform-module/_index.md
Outdated
Show resolved
Hide resolved
| @@ -0,0 +1,187 @@ | |||
| --- | |||
| title: "Upgrade Overview" | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh ... this was incorporated into the landing page https://github.com/MaterializeInc/materialize/pull/34221/files#diff-eac74265be1711fcdccf99e1c740cdcc0054ab604c658782a67e6aa26daad915L15
So, I think this can go away?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh yeah, I did just notice that, and I'm not sure I agree.
I knid of want the landing page portion to go away and think we should move back to an upgrade overview doc 😆
Probably best to chat through this through on zoom.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's only because of the current organization that it's included at the top. That is, for the upgrade landing page, we would want to reorg the other files.
Currently, as it stands, we have:
- Self-Managed Deployments
- Install on kind
- Upgrade
- Install on AWS
- TF
- TF Legacy
- Install
- Upgrade
- Req Config
- Install on Azure
- TF
- TF Legacy
- Install
- Upgrade
- Req Config
- ...
- Upgrading
- Install on kind
So ... we might want to go:
- Self-Managed Deployments
- Install
- Install on kind
- Install on AWS
- ...
- Upgrade <-- This can be the separate landing page overview.
- Upgrade on kind
- Upgrade on AWS
- ...
- Install
09c8029 to
718192a
Compare
- Moves the install, upgrade, and configuration docs into a subdirectory called Terraform Provider (Legacy) - Creates aliases for each of the moved pages - `Installation > Install on GCP `-> `Installation > Install on GCP > Terraform Provider (Legacy) > Install` - Removed terraform references from the Deployment guideline appendix and pushed them into the Configuration appendix - Changed from "Required configuration" to just "configuration" docs: Relabel AWS guides as legacy Terraform guides - Does the same work as the GCP commit docs: Relabel Azure guides as legacy Terraform guides - Does the same thing as the GCP commit - Removes terraform configuation values given they weren't rendered. e.g. enable_disk_support Update doc links Add docs for new terraform modules.
718192a to
1a2e83b
Compare
| @@ -0,0 +1,353 @@ | |||
| --- | |||
| title: "Self-Managed Deployments" | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
|
|
||
| 1. **Connect to the instance**: Use the Materialize Console on port 8080 to | ||
| connecto to the `console` service endpoint or SQL client on port 6875 to | ||
| connect to the `balancerd` service endpoint. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👉 this had previous said environmentd, but I think it's balancerd?
|
|
||
| ## How can I downgrade Self-Managed Materialize? | ||
|
|
||
| {{< include-from-yaml data="self_managed/upgrades" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh ... let me know if you want me to include this you can't downgrade also in our upgrade guides.
| terraform apply | ||
| ``` | ||
|
|
||
| - To deploy with <red>**public NLB**</red> for Materialize access: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👉 This feature is not yet in the TF. Let me know if:
a) this is in progress or
b) you want me to remove this from the docs
c) make the couple of lines PR
d) file an issue
|
|
||
| ```bash | ||
| # aws eks update-kubeconfig --name <your-eks-cluster-name> --region <your-region> | ||
| aws eks update-kubeconfig --name $(terraform output -raw eks_cluster_name) --region us-east-1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just wondering ... if we should include the region in the output so that people don't need to manually update the region.
|
|
||
| ## Cleanup | ||
|
|
||
| {{% self-managed/cleanup-cloud %}} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👉 As an FYI -- I've now gone past the weird zsh error by using shivam's branch + main ... but even running this terraform destroy four times, I keep getting
│ Error: deleting Security Group (sg-037dbf999aed801cc): operation error EC2: DeleteSecurityGroup, https response error StatusCode: 400, RequestID: d7ea4727-cd42-4021-a87f-3c9e28fc8c6b, api error DependencyViolation: resource sg-037dbf999aed801cc has a dependent object
│
│
There's a thread on this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we don't sort out, I could add a tip stating the workaround:
aws ec2 describe-network-interfaces \
--region us-east-1 \
--filters Name=group-id,Values=<your_security_group> \
--query "NetworkInterfaces[].{ENI:NetworkInterfaceId,Desc:Description,Status:Status,Attachment:Attachment.InstanceId,Owner:OwnerId,Requester:RequesterId,Subnet:SubnetId,PrivateIp:PrivateIpAddress}"
and delete
aws ec2 delete-network-interface \
--region <your_region> \
--network-interface-id <eni_to_delete>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh ... this was fixed with MaterializeInc/materialize-terraform-self-managed#125 🎉🎉🎉
|
|
||
| - `mz_system` as the user | ||
| - Your `<dns_name>` as the host | ||
| - `6875` as the port: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With auth enabled, mz_system can use 6875 🎉 (We'll need to clarify the troubleshooting section where we have people port forward 6877)
|
|
||
| {{< /note >}} | ||
|
|
||
| #### Connect using the Materialize Console |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI -- the azure/google simple examples do not have auth enabled like aws's simple example.
| deployment | ||
| guide](/self-managed-deployments/deployment-guidelines/gcp-deployment-guidelines/). | ||
|
|
||
| {{< note >}} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👉 Do we want to make this forward-looking statement?
We could
| deployment | ||
| guide](/self-managed-deployments/deployment-guidelines/azure-deployment-guidelines/). | ||
|
|
||
| {{< note >}} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👉 Do we want to make this forward looking statement? Depending on where we are, we could make it slightly more generic that things might change instead.
| {{% include-from-yaml data="self_managed/installation" | ||
| name="installation-verify-status" %}} | ||
|
|
||
| ### Step 5: Connect to Materialize |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI -- the azure/google simple examples do not have auth enabled like aws's simple example.
| compatible version of your currently deployed Materialize Operator. | ||
|
|
||
| To stage, but **not** rollout, the Materialize instance version upgrade, you can | ||
| use the `kubectl patch` command; for example, if the **App Version** is {{< self-managed/versions/get-latest-version >}}: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👉 am omitting the fact that although the Materialize instances do not upgrade until you requestRollout, the balancerds do upgrade versions.
|
|
||
| ### Using YAML Definition | ||
|
|
||
| Alternatively, you can update your Materialize custom resource definition directly: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Q: Just wondering ... for this (and kind upgrade I suppose) ... should we have it broken into two parts as well? ... One to stage and the other to requestRollout?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One step works as well. This is the same as Staging and applying in a single command
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can also make this a child of that section
| - name: upgrade-order-rule | ||
| content: | | ||
| **Always** upgrade the Materialize Operator **before** | ||
| upgrading the Materialize instances. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Merged the previously 2 bullet point to above:
Always upgrade the operator first and ensure version compatibility between the operator and the Materialize instance you are upgrading to.
Always upgrade your Materialize instances after upgrading the operator to ensure compatibility.
(since I think they're saying the same thing).
|
|
||
| - **Always** upgrade the operator first and ensure version compatibility between | ||
| the operator and the Materialize instance you are upgrading to. | ||
| - **Always** check the [version specific upgrade |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will remove this as folded into the consolidated yaml file in the future
| @@ -0,0 +1,271 @@ | |||
| --- | |||
| title: "Upgrading" | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Heh .. I've been going back between Upgrades vs Upgrading ... eh.
Preview:
https://preview.materialize.com/materialize/34221/self-managed-deployments/
Motivation
Revival of Jun's Pr to shift the cloud specific terraform install and upgrade structure +docs for the new terraform.