There is documentation on migrating GCP App Engine services from standard to flexible, though none on going the other direction. It seems flexible is more stringent, and so less work is required going from flex to standard, but I'm not certain, as a simple change in the app.yaml is breaking the app.
Any insight out there on smoothly changing from GCP App Engine flex env to standard?
thank you-
The vast majority of the time, code written for Flex will work on Standard (unchanged). What you do need to do is make sure to make all the necessary changes in your app.yaml (it's not as simple as just removing env: flex).
One option to do this is pull up the Flex app.yaml reference side-by-side with the Standard app.yaml reference and make sure you:
Use valid settings for Standard (e.g. runtime: python39 instead of using the runtime_config field)
Remove any settings that are not applicable for Standard (e.g., Healthchecks)
In particular, pay attention to the Scaling settings, as they are similar, but have some easily-missed differences (e.g. min_num_instances for Flex, min_instances for Standard).
Also, if you are using Cloud SQL, there are some differences in how you configure the connection.
Related
I have made a basic App Engine Flexible Rest API that uses Cloud endpoints for authentication and uses Spring for the MVC framework.
Does anyone have any recommendations on how to switch this over to App Engine Standard?
I thought to change the app.yaml file would work but I am a bit lost.
Thanks
Modifying your app.yaml is the primary method of changing from flexible to standard environment, or vice versa. Barring any other special configuration for your particular project, this could be all you need to do.
To deploy to standard environment, instead of flexible:
Try simply commenting out the env property in your app.yaml:
#env: flex
By default, you'd deploy to the standard environment if env is not defined (is what my experience has been).
Beyond this, you'd have to look at individual properties in your app.yaml, as perhaps some of them may only apply to a specific deployment type. For example, instance_class is not a property used in flexible environment, whereas you can define that in standard environment. In theory, I would remove or comment-out instance_class if deploying to flexible environment, or just maintain a second app.yaml (e.g. named app_standard.yaml).
On a side note, one thing I did stumble upon recently (for Go, anyways):
For a flexible deployment, this failed...
# This failed for flexible deployment, but it's what Google docs states to use (no period in the number)
runtime: go111
Meanwhile, I had to define the period for flexible deployment...
# This worked on a flexible deployment (had to include the period in the number)
runtime: go1.11
However, for the exact same app, with no code changes, simply going to standard environment, I defined runtime version WITHOUT A PERIOD, as Google's docs say to do, and it worked:
# This worked for standard environment (no period in the number)
runtime: go112
Just illustrating how fine details in the app.yaml matter.
It takes so long to deploy an app to App Engine by this command
gcloud app deploy
After I updated my source code, even if it's just one line of change, I had to issue this command again to upload the changes to App Engine. Again it will take a long time to deploy for just one line of code change. Is there a way to quickly update the code on App Engine instead of doing this time consuming deploy again?
I am looking for options that can speed up the code update after it's first deployment to App Engine. Since I am using flex, would using standard make it faster to update the code? Is it true that there is no way around it on App Engine and the only way to do it is to use another service such as Compute Engine?
Yes, standard env app deployment in such context is much faster, because it only involves uploading the modified files and restarting the instances.
But using standard env is often not an option for other reasons. The potential duplicate post I referenced contains itself references to both explanations and suggestions for potential speed improvements. I don't see a point in duplicating them.
The most common reasons for choosing flex env:
language support
restrictions of the standard env sandbox
See also: Google App Engine Standard or Flexible environment?
(Sep 2021): First of all, the issue you describe for App Engine (flexible) does not apply to App Engine (standard), which is almost a completely different product. (For those who are new, here is a comparison b/w both products.) This question is a few years old, and there are a few more options available to you now:
App Engine standard: If your app can run in Python 3.7+, Java 11, Go 1.12+, PHP 7, Node.js 10+, or Ruby 2.5+, then this is the obvious place to go. A deploy should take less than 1 minute.
Cloud Functions: If you don't have an entire app or your app is made up of one function/route or is otherwise short & simple, consider turning it into a microservice for Cloud Functions. Its deployment time is also less than a minute.
Cloud Run: If you're using App Engine flexible because your app is containerized, consider Cloud Run, which runs containers in a serverless way. A big bonus is that a Dockerfile is optional (due to Cloud Buildpacks). It has taken many GAE flexible use cases. Deployment is also less than a minute. If interested, I produced a pair of videos on how to migrate from App Engine standard to Cloud Run, using Docker as well as no Docker. At some point, I'll do one on transitioning from GAE flexible.
App Engine flexible: If none of the options above work, requiring you to stay on GAE flexible, then yes, you'll have to deal with its longer deployment time (due to the complexities of the system and all the resources it needs to spin-up & manage on your behalf). If you have a container and Cloud Run isn't an option, also consider GKE Autopilot or GCE MIGs (managed [VM] instance groups).
I see a lot of google-app-engine questions from users mixing up the standard environment with the flexible environment, especially when it comes to documentation, often attempting to follow the wrong instructions, obviously with undesired results.
How can one easily tell which GAE environment a certain page is applicable to?
Most (if not all) of the GAE documentation is structured by the environment. When looking at a certain documentation page the environment is clearly indicated in several places:
the second section at the top of the left-side documentation navigation bar
the navigation trail at the top of the actual documentation page (which may vary slightly depending on the programming language)
the docs/flexible vs docs/standard strings in the doc page URLs
some pages applicable to multiple programming languages and/or environments (maybe with small differences) have tabs indicating:
the currently selected language and environment
the other languages and environments the page applies to (selectable)
the languages and environments the page doesn't apply to (grayed out)
Examples:
If the documentation page doesn't show the above mentioned patterns (for example if it's a page about some other Google Cloud product somehow related to the App Engine), then check about the App Engine feature being discussed and try to locate the respective GAE documentation.
What may also help with the distinction would be to check these guides putting the 2 environments and/or their features side by side:
Choosing an App Engine Environment
App Engine Flexible Environment for Users of App Engine Standard Environment
Migrating Services from the Standard Environment to the Flexible Environment
Note: when multiple language versions are listed/mentioned under the standard environment (excepting Node.js) they refer to the 1st and 2nd generation standard environment, significantly different from each-other. You should also check the comparison and/or migration guides for these cases:
Understanding differences between Python 2 and Python 3 on the App Engine standard environment
Migrating from Java 7 to Java 8 Runtime
Migrating Your App from PHP 5.5 to PHP 7.2
Migrating your App Engine app from Go 1.9 to Go 1.11
I'm starting to build a web/mobile app that is going to be offered as SaaS.
I have seen many cloud options for hosting (Heroku, AWS) but finally decided to go with Google Cloud App Engine.
My back-end will be Java based, and I'm confused about going with the Standard or Flexible Env.
I have read several docs online but still undecided.
Considerations to tackle:
I am not very experienced with Docker and this is my first Saas App.
My app should run perfectly with the offering of the Standard Env.
Migrating from the Standard to the Flex environment seems to bring
some headache.
Would you please help me decide on the way to?
We try to cover the key differences in this doc:
https://cloud.google.com/appengine/docs/the-appengine-environments
To cover your considerations:
You don't need to understand Docker to use flex or standard
If your app can run in Standard - that's great!
Migrating from Standard to Flex is a fair bit of work. We try to cover it here
Read over those docs, and let me know if you have any other questions!
Being very new to googles app engine, i have used Intellij IDEA plugins to deploy my REST java app. Having that passed smoothly, together with my app ive got two compute engine virtual machines. What are they for? Why two and how does they select required VMs configuration?
It sounds like you are using the App Engine flexible environment AND that you're using the older version of it rather than the new beta version. The older version has vm: true in your app.yaml file. The newer version, which was just announced on Nov 15, 2016, uses env: flex in the app.yaml file.
The flexible environment runs on top of Compute Engine virtual machines. In the older version these your app's instances would show up under Compute Engine. With the newer version these now display in the console on the App Engine instances page.
You're going to want to look into migrating your app to the new version of the flexible environment before the old beta version is deprecated at some point in the next year. If you used on the "compat" runtimes from before, you might check to see if you really need to use the flexible environment or does the standard environment support your app's needs? Depending on your app, one environment might be cheaper than the other.
All that said, you can configure the underlying virtual machines in the flexible environment by using the app.yaml file. See the resource settings in the app.yaml reference for details. Later, if you needed to debug your code on the instances, see Debugging an instance.