Hosting a web app using GCE managed instance groups - google-cloud-platform

I have NGINX setup on Google Cloud Compute Engine using a managed instance group setup [powered by managed instance templates].
I simulated a cpu load on one of the servers and that spawned a couple of additional servers, each running NGINX.
So what's the best practice for hosting a website using this?
Do I just create an A-record in DNS and point it to the IP address of the original instance [of the group]? Looks like this would be problematic given that the IPs are ephemeral?!
Do I reserve a static IP address [in VPC Network]? I tried to create a static IP address and attach it to the original instance in the group, but when I did that, the said instance went away leaving another spawned instance as the new primary instance?!
Is there some load balancer hidden somewhere that I can point an A-record to?
Managed instance groups seem like a great idea, but would like to know the best way to set it up that will not break unexpectedly in DNS.

You should setup a load balancer to distribute traffic across the instances in your group. To create a load balancer, you'll have to setup several components, instance groups being one of them. Check out this example. This uses unmanaged groups, but you can use managed instead. Once you've setup a load balancer, I would recommend creating a script in a language of your choice (python, JS, bash) that automates this process. I would even go further and write a script to tear down your load balancer.
As far as your domain is concerned, during the setup of your load balancer, you'll have to create static IPv4 and optional IPv6 addresses. You can then create A/AAAA records that point to these addresses. Finally, make sure you wait ~5-20 minutes after you've pointed your A/AAAA records to these ip's before you wonder why it's not working.

Related

Handling load balancer

I have a website which has main domain and sub domain (I have different subdomain for different countries) eg: mysite.com ( is the main domain ), country-a.mysite.com ( for country A ), country-b.mysite.com ( for country B) NOTE: each country has independent users / data and linked with separate databases.
Now I'm managing them in one EC2 instance. Where I have subfolders for each country and point them to subdomain using Route53. And they are working fine.
But now I wanted to them scalable as I'm expecting more traffic. What is the best practice for such scenario ?
Is it possible to get another EC2 instance and clone all the subfolders and introduce a load balancer to handle the traffic between these 2 instances ? I mean, when a user from country A and B will hit the load balancer, the load balancer will handle it properly and redirect the user to the right subfolder in these 2 instances and manage the traffic ?
If yes, how should I configure the Route53 ?
How the load balancer is handling user sessions ? I mean, let say first time a user hit the load balancer direct the user to 1st instance and when the other request comes from the same user hit the 2nd instance. If a session create on the 1st instance and this session data will be available at 2nd instance?
Also I wonder how I can manage the source codes in these instances. I mean, if I wanted to update the code do I have to update in these 2 instance separately? OR is there a easy way where I upload the files to one of the instance and it will clone to other instances ?
BTW, my website built using Laravel framework and Postgres.
Im new to load balancer, pls help me to find the perfect solution.
If yes, how should I configure the Route53 ?
There is nothing you should be doing in R53. Its load balancer (LB) that distributes traffic among your instances, not R53. R53 will just direct traffic to the LB, nothing else.
How the load balancer is handling user sessions ?
It does not handle it. You could enable sticky sessions in your target group (TG) so that LB tries to "maintain state information in order to provide a continuous experience to clients".
However, a better solution is to make your instances stateless. This means that all session/state information for your application is kept outside of the instances, e.g. in DynamoDB, ElastiCache or S3. This way you are making your application scalable and eliminate a problem of keeping track of session data stored on individual instances.
Also I wonder how I can manage the source codes in these instances. I mean, if I wanted to update the code do I have to update in these 2 instance separately?
Yes. Your instances should be identical. Usually CodeDeploy is used to ensure smooth and reproducable updates of number of instances.

Fixed IP address for service behind aws application load balancer

our company just moved to a new office and therefore also got new network equipment. Es it turns out, our new firewall does not allow pushing routes over VPN that it first has to look up ip addresses for.
As we all know, amazon aws does not allow static ip addresses for its application load balancer.
So our idea was to simply put a network load balancer in front of the application load balancer (there is a pretty hacky way described by aws itself (https://aws.amazon.com/blogs/networking-and-content-delivery/using-static-ip-addresses-for-application-load-balancers/) that seemed to work fine (even if I don't really like the approach with the lambda script registering and deregistering targets)
So here is our problem: as it turns out, the application load balancer only gets to see the network load balancers ip address. This prevents us to use security groups for ip whitelisting which we do quite heavily. On top of that some of our applications (Nginx/PHP based) also do ip address verification and the alb used to pass the clients ip address as an x-forwarded-for header. Now our application only sees the one from the nlb.
We know of the possibility to use the global accelerator but that is a heavy investment as we don't really need what the GA is trying to solve.
So how did you guys solve this problem ?
Thankful for any help :)
Greetings
You could get the list of AWS IP addresses for the region your ALB is located, and allow for them in your firewall. They do publish the list and you can filter through it https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html
I haven't done this myself and I'm unsure if the addresses for ALB are included under the EC2 category of you would take the whole of AMAZON service "to be safe".
Can you expand on this? "We know of the possibility to use the global accelerator but that is a heavy investment as we don't really need what the GA is trying to solve."
GA should give you better, more consistent performance, especially if your office is far away from the AWS Region where the ALB is running

AWS - Can I launch nodes under a DNS domain (Auto Scale Group)?

Use Case
I'm working on an application that uses Presto, and for Presto, I have to set up HTTPS traffic internally (for security compliance reasons).
For this, I preferably need the nodes' FQDN to be in the same domain. E.g. myhost1.mydomain.com, myhost2.mydomain.com.
My Question
AWS automatically gives a FQDN like ip-10-20-30-40.ec2.internal. So, my question is:
Is there a way I can have a new node automatically be created with a FQDN like myhost1.mydomain.com? I know I can create internal "hosted zones" and DNS records for my hosts pretty easily, but I can't figure out how to make that the default domain for a new host.
Also, just FYI, I'm doing this for an auto-scale group; but I suspect that's irrelevant.
When the Amazon EC2 starts, it can run a script passed in via User Data.
You could code this script to create a CNAME record in Amazon Route 53 that points to the IP address of the instance.
I'm not sure how you'd necessarily determine the number within the name, so you could just create a random name. Also, it might be tricky to remove the CNAME entry when the instance is terminated. One way to both assign and remove the record would be to use Amazon EC2 Auto Scaling Lifecycle Hooks, which allows code to be triggered outside of the instance itself. It's more complex but would be fully effective.
I'm not familiar with Presto, but here's a couple of ideas.
First, if you are using an AWS managed load balancer, you can enable HTTPS between it and the instance using self-signed cert: the load balancer will NOT validate the cert, so your connection will be secure.
If that's not what you need, take a look at DHCP option sets for your VPC - I believe you can set your own domain name, rather than use the default ec2.internal.

How can I forward a regional IP to a global forwarding IP?

Tonight, my client is going to be on a high-profile television show to pitch his business. I created their API and had it running on a small server on Google Cloud Platform with a static IP on the instance since that was all that we needed.
Now I am trying to scale it for the inevitable traffic, I'm moving to a load balancer and multiple, scalable instances. I thought I could use the IP address from the instance and transfer it to the load balancer. But the load balancer requires a global forwarding IP, and the IP address of the instance is only regional.
For some reason, the mobile developers hardcoded their URLs to the IP address and not the domain name. It's too late in the day for them to resubmit the app code, so I need a way to forward the regional IP to the global forwarding IP that the load balancer takes.
Could I do this through Google Cloud Platform? Or should I set this up through the domain name provider?
I realize that this may break some rules on SO, but I only need the answer for today, the question can come down tomorrow if it does break rules.
Your best shot today may be to increase the memory/cpu of the current machine type and/or use something like Nginx to proxy requests from the instance to the load balanced fleet.
It is possible to use nginx as a very efficient HTTP load balancer to
distribute traffic to several application servers and to improve
performance, scalability and reliability of web applications with
nginx.
I would do both: increase instance capacity and try an Nginx proxy on that instance. You will still have a single point of failure, but would be able to handle greater capacity.
Essentially this configuration will forward requests from the instance (the regional ip) to your GCP load balancer (the global ip)

AWS EC2 - How to upgrade instance without changing existing public IP?

Is it possible to upgrade EC2 instance without changing existing public IP address? My mobile application is live and unfortunately we didn't use elastic IP in web services. So if I upgrade current instance, it will generate new public IP and the old application users won't be able to use mobile application.
Is there any way to keep current IP as it is? Or any other way to upgrade it without loosing existing users? Please suggest.
Consider this a lesson as to why you should use a load balancer and a DNS entry, especially for anything public-facing. What were you going to do if you the instance failed? Or the availability zone went down?
Personally I would spin up a set new larger instances behind a load balancer, create a Route53 DNS entry that points to the load balancer, and then release an update to the client that points to the DNS entry. As clients update, traffic will gradually move to the load balancer. The undersized single instance's load will drop, so if it is overloaded it will eventually return to normal. Eventually you can kill the old instance when all/most clients have upgraded.
It depends on what sort of software you are running exactly
If you have an application that is sessionless then it would be simple to bring up another server on a different IP and then use route53 to switch over the traffic, with both servers running at the same time
If the application is stateful though and if it stores the sessions locally on the host then that's more of a problem
One possible approach is to bind an elastic ip to the running host, reconfigure your software to listen on all addresses ( a lot of configuration controls allow this with an address of 0.0.0.0 ) then change DNS and gradually see the traffic migrate to the elastic IP, while both addresses work
Once the new address is fully in use (depends on your TTL) it becomes much easier to switch to a new host by reassigning the EIP