What is meant by "staging instances" of your application in this Google Cloud Debugger doc? As per this question it seems that only the default version of an application can be used with Google Cloud Debugger. Does Google simply intend that you can use this with the default version of a separate application which you dedicate to your staging environment?
Google Cloud Debugger can be used with any module or any version of your running application. The question you referred to is obsolete.
Many projects setup a module/version or simply another project to be used as their 'staging instance' to test their code before pushing to the production instance. There is no one way to implement a 'staging instance'.
The term staging in programming mostly refers to the term development.
In the app engine, you can have multiple instances of your application. One in Production environment(one instance) and other in a Staging environment(another instance).
So production means that its a version currently running or available to the public. Staging means that it is running only for testing purposes (usually new features) before its being deployed to the public
Google saying:
You can use the Cloud Debugger on both production and staging instances of your application
Simply means that you can you the Cloud Debugger on both the Production and Staging(Development) version of your application.
Related
I have created a GCP Project and using App Engine standard environment for deployment purposes.
I have various developers working with me on the same project and deploying on App engine using various versions, however, we are using a default version to which all the traffic is allocated.
So are there any ways by which we can restrict the deployment on the default version. i.e we want specific people to be able to deploy on default version without removing deployment rights of other people on the same project.
And is there any alternative approach to this situation.
It depends on the runtime where you are deploying the application.
For example, in Python, if you are using the command gcloud app deploy (see the documentation), you can do the following:
gcloud app deploy --no-promote --version=<MY-VERSION-NAME>
The --no promote flag will avoid allocating all of the traffic to the version you are deploying, while the --version=<MY-VERSION-NAME> specifies the name of the version that you will create from the deployment, and replace an older one with the same name if it exists.
AFAIK there is no way to restrict deployment of a specific version. All access control method revolve around a certain identity being allowed access to deploy a certain GAE project or not. The version string used (i.e the version being deployed to in your approach) is irrelevant.
This falls into the "allows you to separate IAM roles" advantage mentioned in the accepted answer to Advantages of implementing CI/CD environments at GAE project/app level vs service/module level?.
As a note: you're attempting to implement environments at the service/module version level, which is IMHO worse than both methods compared in that post, see Continuous integration/deployment/delivery on Google App Engine, too risky?
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).
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.
I'm wondering if there is any way to run and test GAE Go apps using the standard go test || go build etc tools and if it's not possible what's the technical reason.
The Go App Engine SDK contains the standard Go packages and tools, but a modified version of them.
The GAE SDK also contains local versions of the GAE platform services API implementations which are not part of the SDK (not even the API). So you can't just use the standard Go SDK. When you build or test with the GAE SDK, the SDK takes care of a context mockup so your app will have everything (or most of the things) required to "feel" it is running in the GAE environment. The SDK also contains the sandbox restrictions that are in effect in the production environment (e.g. you can't write to local files).
Also note that some features of the GAE SDK also rely on a Python runtime (because the Go GAE SDK was created using the existing Python GAE SDK), not everything is rewritten in go.
So taking all these into consideration it would not be feasible to build/test using the standard Go SDK and it is not even possible.
I have this application that will be run in a local network where a number of devices should interact with a database. I could use xampp and go for CherryPy or any other Python framework (Python is usually my choice) but it is the sum of a lot of different things: Python, Apache, MySQL... With GAE, which I have previously used in a number of applications successfully, I feel everything is neatly packed in a single box. Thay may not be true, but using the Google App Engine Launcher to create a local working copy of an app couldn't be easier.
But is it reliable? Should it be used like that? I know it's intended for development, so I'm unsure about using it as a local server in production. A few versions ago there even was this nasty bug that flushed the local datastore from time to time. But it seems that they fixed it and now data persists.
Would you recommend GAE for an application running in a local network or should I stick to LAMP (P for Python)?
Other alternative is http://code.google.com/p/appscale/.
May be you can check the the project TyphoonAE. I think it is exactly what you need.
The TyphoonAE project aims at providing a full-featured and productive
serving environment to run Google App Engine (Python) applications. It
delivers the parts for building your own scalable App Engine while
staying compatible with Google's API.