I do this already but from my configuration management system on my instances, but one thing I don't have that I'd love if Route53 would help support is being able to run route53 to handle in-addr.arpa zones for my IP addresses so I can get reverse IP looking for my VPC networks without having to run my own resolver.
Dynamic Route53 records for AWS auto scaling groups with Terraform
11–20 of 37 posts
Re: Dynamic Route53 records for AWS auto scaling groups with Terraform
#12Earlier quoted context omitted.
Why should an instance created by an ASG have a host name? These are cattle not pets. I use Serilog for logging with an EC2 enricher that automatically adds the instance Id and the IP address. Since Serilog does structured logging, I can use either an ElasticSearch or Mongo sink and do complex queries. If I routinely need to log into an instance to troubleshoot, I need to be capturing data and sending it to a central…
> Why should an instance created by an ASG have a host name? It means you can connect to it by just knowing its instance ID. Adding the IP address everywhere also works. There can be some nice SSH config options though, like using a particular key for everything *.prod.myaws.com
You can also use SSM and session manager to get a similar experience for those instances: https://docs.aws.amazon.com/systems-manager/latest/userguide...
I haven't had to manage SSH keys in a long time ;)
With this I just have a bash function for my various environments (e.g. dev = dssm) where I provide in the instance ID giving me issues if I really need to log into the server.
e.g.
function dssm { aws --region us-west-2 --profile my-dev-profile-name ssm start-session --target $1 }
Then:
dssm i-abcdef123456
And I'm dropped into a shell. SSM Session manager is far from perfect, but it gets the job done, and is fully auditable, gets logged (including commands ran), and best of all works with SAML IAM profiles right out the gate. No more sharing keys, no more managing keys, it's great!
Re: Dynamic Route53 records for AWS auto scaling groups with Terraform
#13This is a pretty sweet Terraform module that I will personally be testing out soon. I was curious what they are using for the Lambda function, and it turns out is a framework-less Python script[0]. One thing I'm not clear on yet is if using this will imply one such lambda for every autoscaling group or not. [0] https://github.com/meltwater/terraform-aws-asg-dns-handler/b...
I just checked with the Jim, the author of the blog post, and module (we both work for Meltwater).
He confirmed "You only need one instance per account, we have always been fine with just one".
I will let him fill in further details here but I figured you would be interested in a short update on this.
Re: Dynamic Route53 records for AWS auto scaling groups with Terraform
#14I do this already but from my configuration management system on my instances, but one thing I don't have that I'd love if Route53 would help support is being able to run route53 to handle in-addr.arpa zones for my IP addresses so I can get reverse IP looking for my VPC networks without having to run my own resolver.
Interesting, which configuration management system do you use?
Re: Dynamic Route53 records for AWS auto scaling groups with Terraform
#15I do this already but from my configuration management system on my instances, but one thing I don't have that I'd love if Route53 would help support is being able to run route53 to handle in-addr.arpa zones for my IP addresses so I can get reverse IP looking for my VPC networks without having to run my own resolver.
We run our reverse zones on route53. It is just a little bit cumbersome but overall works relatively well with vpc private hosted zones.
Re: Dynamic Route53 records for AWS auto scaling groups with Terraform
#16You can attach an ELB to the ASG. Then DNS name to ELB.
That's how AWS expects you to use it.
Re: Dynamic Route53 records for AWS auto scaling groups with Terraform
#17You can attach an ELB to the ASG. Then DNS name to ELB. That's how AWS expects you to use it.
I can see why you might not want to, though. App ELBs charge by usage and can get somewhat expensive (like running another EC2 instance or two). They can also have cold-start performance issues in specific circumstances (traffic spikes).
Re: Dynamic Route53 records for AWS auto scaling groups with Terraform
#18You can attach an ELB to the ASG. Then DNS name to ELB. That's how AWS expects you to use it.
That doesn't solve the problem of the hostname on the EC2 instance itself being the same across all instances thereby making it harder to see what logs came from what hosts.
It doesn't solve the problem of allowing you to look at logs and then quickly SSH'ing to a single machine in the ASG.
Re: Dynamic Route53 records for AWS auto scaling groups with Terraform
#19You can attach an ELB to the ASG. Then DNS name to ELB. That's how AWS expects you to use it.
That doesn't solve the problem of the hostname on the EC2 instance itself being the same across all instances thereby making it harder to see what logs came from what hosts. It doesn't solve the problem of allowing you to look at logs and then quickly SSH'ing to a single machine in the ASG.
what you need is probably something like https://github.com/adhocteam/ec2ssh (I never used it, but I have built similar ones) -- and then you tag the log entries with instance id.
so you can do "ec2ssh i-0017c8b3"
imho: Hacking around debugging tools is better (mostly because more reliable) than hacking around production configurations (one problem you will see is that changing route53 records frequently will be subject to API rate-limits).
Re: Dynamic Route53 records for AWS auto scaling groups with Terraform
#20You can attach an ELB to the ASG. Then DNS name to ELB. That's how AWS expects you to use it.
I can see why you might not want to, though. App ELBs charge by usage and can get somewhat expensive (like running another EC2 instance or two). They can also have cold-start performance issues in specific circumstances (traffic spikes).
yup. but that's usually negligible to most companies. and it's probably not worth the extra complexity introduced by production hacks.