I understand that AppEngine project is defined to only one region and Google automatically handles the load balancing for you. But if I have apps in different regions across the world (In different projects as it seems to be a requirement) then how can I use the HTTPS load balancer in Google Cloud to automatically route the traffic based on the location where the request is coming from? (Consider both Standard and Flexible)
The Load Balancer in GCP can balance the traffic to different instances based on the region.
But, to do this, you should be using VM instances in the same project. If you are using App Engine Flexible, Instance Groups are created, for each service, when you deploy your app, to manage your instances, so, they can be added to your Load Balancer.
Then, you could move the other apps you have in other projects, in the Flexible environment, to the project where you have the Load Balancer, as different services, and then, added to the Load Balancer.
Sadly, the only solution for the apps in the Standard environment is that they should be moved to the Flexible environment, in the same project as the Load Balancer, to be able to add them there.
Related
Does App Engine automatically load balance if we configure the App Engine to auto-scale? Or do we manually need to add a load balancer for an app hosted on App Engine?
I just started learning GCP this week and I have been given an assignment by my trainer to deploy an application on App Engine and to connect it to a load balancer and a CDN. I have understood how to use load balancers with Compute Engine. But since App Engine takes care of auto-scaling without us having to configure anything, does it also take care of load-balancing automatically? Or do we have to manually setup a load balancer? I tried to search a lot about load balancers with App Engine but the only thing I could find was some "Network Endpoint Groups(NEG)". I couldn't understand any of NEG articles because I am not familiar with containers and Kubernetes. Can someone please explain load balancing for App Engine and how to do it?
Yes, GAE includes a load balancer. As soon as you scale to 2 instances, this is necessary and GAE takes care of it for you. GAE does an amazing job of taking care of this for you (much better than AWS Elastic Beanstalk for example).
For more complicated situations (e.g., Kubernetes), you can manually create and configure a load balancer. I don't think you would ever you use a custom load balancer with GAE.
In the documentation for App Engine it says:
Meeting your latency, availability, or durability requirements are
primary factors for selecting the region where your apps are run.
You cannot change an app's region after you set it.
In App Engine Standard Environment (with automatic scaling), what should I do if my application starts getting a lot of requests from a region far away from mine? For example if my region is us-east1 but I get a lot of requests from asia?
For some reason I thought that App Engine would spin up new instances in the region the request is coming from.
If wanting to build a globally accessible and fast app, this seems like a big limitation to me. Is GAE standard environment a bad choice then?
For the most part, Google App Engine is designed for small, simple and easy to deploy server instances.
If you need global load balancing and auto scaling, then you will need to select and configure the services yourself. Google's load balancer supports global geolocation based load balancing. You can define, in advance, which regions it will load balance to. Combined with Google Compute Engine and Instance Groups, you can define the global characteristics of your site.
The tradeoff for you is how much effort do you want to spend in planning, deploying and managing your setup. Google App Engine makes this easy, but you are limited in some options. Google Compute Engine takes more effort, but you have a larger set of options to chose from and manage.
Start with some research on Google's Load Balancer to better understand the options available to you.
GOOGLE CLOUD LOAD BALANCING
You have a Google Cloud project Project1 with App Engine enabled and serving your legacy application.
You want to rebuild your application using a different programming language and hence need a separate project (Project2) with its own separate App Engine.
You want to install some kind of reverse proxy appliance in front of your Project1 App Engine, so that you can gradually route more and more traffic to Project2's App Engine.
What's the best way to achieve this?
Google Cloud Load Balancer doesn't appear to work with App Engine (only Google Compute Engine), so I'm thinking establishing a reverse proxy server (e.g. NginX) container would be the best bet.
Depending on how you want to organize, you can duplicate your entire application within the same project by just deploying as a different service or as new versions of your existing service. For example, say you have two services frontend and backend for a simple web app. (Let's say they're both written in Python)
For deploying as a separate service, you can create a new version of your application in a different language, say Node.js. You can deploy the new services as frontend-node and backend-node.
If you don't want to do that, you can rewrite your application in a different language and then deploy as a new version of your existing services. In the "Versions" section, you can see your versions of the same service and they can be different language runtimes.
Either way, you can then use the "split-traffic" feature to customize and test implementations of your application.
Generally speaking, you should avoid using projects to isolate different variants and/or components of your application unless you really need too. App Engine services can each be a different runtime from each other so there's almost no point in provisioning a whole new project even though you're redeploying in a different language.
I have an application deployed to an app engine service. I have many services under the same app engine. How can I make the application available to certain white-listed IPs? In other words, I want this application to accept requests from certain IPs and deny all other request?
Can we do this by writing some configurations in app.yaml file?
Note: I just want to apply the rule to one service only so that other services will not be affected.
Applying this kind of restriction at a service level is, at the moment, not possible.
The best option would be to deploy the services you want to protect on a different project, and use the App Engine firewall there.
I am currently experimenting with the Google App Engine flexible environment, especially the feature allowing you to build custom runtimes by providing a Dockerfile.
Docker provides a really nice feature called docker-compose for defining and running multi-container Docker applications.
Now the question is, is there any way one can use the power of docker-compose within GAE? If the answer is no, what would be the best approach for deploying a multi-container application (for instance Nginx + PHP-FPM + RabbitMQ + Elasticsearch + Redis + MongoDB, ...) within GAE flexible environment using Docker?
It is not possible at this time to use docker-compose to have multiple application containers within a single App Engine instance. This does seem however to be by design.
Scaling application components independently
If you would like to have multiple application containers, you would need to deploy them as separate App Engine services. There would still only be a single application container per service instance but there could be multiple instances of each service. This would grant you the flexibility you seek of scaling each application component independently. In addition, if the application in a container were to hang, it could not affect other services as they would reside in different VMs.
An added benefit of deploying each component as a separate service is that one need not use the flexible environment for every service. For some very small tasks such as API backends or serving relatively slow-changing web content, the standard environment may suffice and may be less expensive at low resource levels.
Communication between components
Since one of your comments mentions getting instance IPs, I thought you might find inter-service communication useful. I'm not certain for what reason you wish to use VM instance IPs but a typical use case might be to communicate between instances or services. To do this without instance IPs, your best bet is to issue HTTP request from one service to another simply using the appropriate url. If you have a service called web and one called api, the web service can issue a request to api.mycustomdomain.com where your application is hosted and the api service will receive a request with the X-Appengine-Inbound-Appid header specified with your project ID. This can serve as a way a identifying the request as coming from your own application.
Multicontainer application using Docker
You mention many examples of applications including NGinx, PHP-FPM, RabbitMQ, etc.. With App Engine using custom runtimes, you can deploy any container to handle traffic as long as it responds to requests from port 8080. Keep in mind that the primary purpose of the application is to serve responses. The instances should be designed to start up and shut down quickly to be horizontally scalable. They should not be used to store any application data. That should remain outside of App Engine using tools like Cloud SQL, Cloud Datastore, BigQuery or your own Redis instance running on Compute Engine.
I hope this clarifies a few things and answers your questions.
You can follow following steps to create a container with docker-compose file in Google App Engine.
Follow link
You can build your custom image using docker-compose file
docker-compose build
Create a tag for local build
docker tag [SOURCE_IMAGE] [HOSTNAME]/[PROJECT-ID]/[IMAGE]
Push image to google registry
docker push [HOSTNAME]/[PROJECT-ID]/[IMAGE]
deploy Container
gcloud app deploy --image-url=[HOSTNAME]/[PROJECT-ID]/[IMAGE]
please add auth for docker commands to run.