Additional notes about using Terraform to manage resources during mig… #25
Conversation
|
Hi Joseph, could you please review? Thanks! |
src/cloud/aws/migration.md
Outdated
| - See below for sample Terraform code to specifically select the subset of subnets that are public. Note that valid choices for the `values = ["public"]` line are `public`, `private` and `campus` (if the campus subnet has been shared with your account). | ||
|
|
||
| ```admonish info | ||
| data "aws_vpc" "default" { | ||
| default = false | ||
| id = "vpc-0c31fe331850b85b5" | ||
| } | ||
|
|
||
| data "aws_subnets" "default" { | ||
| filter { | ||
| name = "vpc-id" | ||
| values = [data.aws_vpc.default.id] | ||
| } | ||
| filter { | ||
| name = "tag:subnet-type" | ||
| values = ["public"] | ||
| } | ||
| } | ||
| ``` |
There was a problem hiding this comment.
I recommend placing this on the network page rather than the migration page and then referring to it.
There was a problem hiding this comment.
I have attempted to do this and will push the updated docs to the repo.
|
|
||
| Additional notes about using the AWS Systems Manager automation document: | ||
| - If you use this automation, you will end up with two identical VM's running at the same time. | ||
| - Please consider what this will mean for any other systems depending on this VM. |
There was a problem hiding this comment.
After doing a few more of these, it's better to shut down the instances before running the automation. Can you modify this to read that way?
There was a problem hiding this comment.
I have attempted to do this and will push the updated docs to the repo.
|
|
||
| Once the automation document has been run, you will need to: | ||
| - manually reassign any Elastic IP addresses from the source instance to the new instance, if applicable. | ||
| - reassign any EC2 instance roles, if applicable. | ||
| - clean up (delete/terminate) the source instance and any associated resources. | ||
| - update any DNS records or other references to the source instance. | ||
| - Potentially update the DNS servers within the VM. Note that the VM's internal DNS servers may be reset to use the default AWS provided DNS server. In particular, if using the campus shared subnet and you have overridden the default DNS servers to point to Infoblox, you will need to set this up again to enable proper DNS resolution for campus resources. |
There was a problem hiding this comment.
Is this true? If someone manually specified DNS servers in the operating system, copying the ec2 instance should not affect that as it makes no changes to disk contents.
There was a problem hiding this comment.
This was my experience and is why I noted it. I agree it should not have happened, but it did. Hence why I documented it.
|
|
||
| If you were using Terraform to manage the old VM and want to continue using it to manage the new VM resource, you will need to define new resources and then import the copied VM into that. A way to get the correct syntax to use for importing is to run `terraform plan` and see how it defines the resource name. Once you have the name correct, if you were using a module for instance, import with something like `terraform import module.<module_name>.aws_instance.<resource_name> <instance_id>`. Once imported, run `terraform plan` again to see what it says will need to be changed. Observe what it would change, then update your Terraform code so unwanted changes would not occur. Keep doing this loop until the output of `terraform plan` reflects the actual changes (if any) that you want to make. Some common things that you may need to update inclued: | ||
| - AMI - you will need to update to reflect the automatically created AMI from the automation | ||
| - Key pair - set to "" if you didn't specify this when making the copy |
There was a problem hiding this comment.
I'm sorry, but I don't see the value of complicating this document with more information. We're almost done with the migrations and no one that's left is using terraform, so this is really isn't for anyone. I am more in favor of a general terraform guidance document apart from this with tips and tricks like this.
There was a problem hiding this comment.
Ok, then do you have an alternate location that such content can be placed instead?
src/cloud/aws/networking.md
Outdated
| @@ -9,7 +9,7 @@ The Technology Services Cloud Services team provides all AWS customers with a Vi | |||
|
|
|||
| The TAMU VPCs are available in the `us-east-1` and `us-east-2` regions with large public, private, and campus-accessible subnets in multiple availability zones. | |||
|
|
|||
| - **Public Subnets**: These subnets are used for resources that need to be accessible from the internet. | |||
| - **Public Subnets**: These subnets are used for resources that need to be accessible from the internet. Don't get confused that the IP addresses encompassed are not themselves direcly publicly routable. It's about the route table and gateway setup. | |||
There was a problem hiding this comment.
Let's link to the AWS document on subnet types instead: https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-types
There was a problem hiding this comment.
I feel like linking to the doc is less obvious than what I wrote, but am willing to defer. I have updated to reflect what you asked for. But ask that you consider keeping what I wrote and adding the link for more details.
src/cloud/aws/networking.md
Outdated
| @@ -39,7 +39,7 @@ If you have a specific use case that requires a different network design, please | |||
|
|
|||
| ### Using Subnets | |||
|
|
|||
| When you create resources in AWS, you will need to select a subnet to place the resource in. You should select the subnet that best fits the requirements of the resource you are creating. A reference table of the subnets and their IDs available in the TAMU VPC is provided below. | |||
| When you create resources in AWS, you will need to select a subnet to place the resource in. You should select the subnet that best fits the requirements of the resource you are creating. A reference table of the subnets and their IDs available in the TAMU VPC is provided below. Note that the following Availability Zones are not available for use due to cost reasons: `use1-az3`, `use1-az5`, `use1-az6`, `use2-az4`, `use2-az5`, `use2-az6`. Be sure any existing resources that are using any of these AZ's get moved to a supported AZ from the list below. | |||
There was a problem hiding this comment.
Can we make this less specific like "Note that not all regions and availability zones are enabled on the shared VPCs. If you require a service or resource type that is not available in the existing zones, please contact the Cloud Services team at [email protected].
There was a problem hiding this comment.
I don't understand what we gain by making things more vague. I prefer explicit answers where possible. But, I'm willing to be persuaded.
With that in mind, I've altered it to read as below and will include that in my push.
A reference table of the subnets and their IDs available in the TAMU VPC is provided below. Note that the following Availability Zones are not available for use due to cost reasons: use1-az3, use1-az5, use1-az6, use2-az4, use2-az5, use2-az6. Be sure any existing resources that are using any of these AZ's get moved to a supported AZ from the list below. If you require a service or resource type that is not available in the existing zones, please contact the Cloud Services team at [email protected].
|
I made most of the changes you mentioned and have pushed again. Please review again. Thanks! |
I added some additional notes primarily focused around using Terraform during migration as well as other notes that I tripped me up as I did my migrations.