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.
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?
I have a website on AppEngine that is 99% static. It is running on Python 2.7 runtime. Now the time has come to evolve this webapp, and since I have almost none Python code in it, I'd prefer to write it in Go instead.
Can I change runtime from Python 2.7 to Go, while keeping the project intact? Specifically, I want to keep the same app-ID, the same custom domain attached to it, the same SSL certificate, and so on.
What do I have to do in order to do that? I surely have to change runtime in the app.yaml. Is there anything else?
Bonus question: will such change happen without a downtime?
I'd be grateful for any links to documentation on exactly that (swapping runtime on a live app). I can't find any.
Specify a runtime as well as a new value for version. When deployed you'll have an older version that is Python and a newer version that is Go. There won't be any downtime (same as when deploying a newer version of Python).
Rather than trusting links/docs (that may be out of date or not 100% exactly what you're trying to do), why not create a new GAE-Std project for testing purposes and try it yourself. Having a GAE-Std test project is good for testing new function (especially by other testers who won't have access to the dev environ on your laptop).
The GAE services offer complete code isolation. So it should be possible to simply deploy a new version of the service, which can be written in a different language or even use a different GAE (standard/flex) environment. Personally I didn't go through a language change, but I did go through a split of a single-service app into a multi-service one, I see no reason for which the same principles wouldn't apply.
Maybe develop the new version as a separate app first, to be able to test it properly without risking an accidental impact on the old version and only after that bring the code as a new version in the old app. That'd be using the GAE project isolation. You can, in fact, test the entire version migration as a separate app if you so desire without even touching the existing app. I am using this technique - a separate app ID - to implement a staging environment for my app, completely isolated from my production app, see How to copy / clone entire Google App Engine Project
Make sure to not switch traffic to the new version at deployment time. This keeps the app working with the old version. Test first that the new version works as expected using Targeted routing. Then maybe use Splitting traffic across multiple versions to perform A/B testing with just a small percentage of the traffic going to the new version. Finally, when happy with the results, switch all traffic to the new version.
You need to pay special attention to the app-level configs (dispatch, cron, queue, datastore indexes), shared by all services/versions. They need to be functionally equivalent in the 2 versions. The service isolation doesn't apply to them, only project isolation can ensure no impact to the old version.
There should be no need to make any change to the app ID, custom domain mapping or SSL config. The above mentioned tests should confirm that.
A few potentially interesting posts related to re-working services/modules:
Converting App Engine frontend versions to modules
Google App Engine upgrading part by part
Migrating to app engine modules, test versions first?
Advantages of implementing CI/CD environments at GAE project/app level vs service/module level?
The Go SDK currently ships with Go version is 1.6.2 but the most recent is 1.7.1 . I need some enhancements/bugfixes that were released since 1.6.2 . However, when I replace the goroot directory in the SDK directory that contains Go 1.6.2 with a symlink that points to 1.7.1, I get an error that has to do with not being able to find bin/goapp, which looks to be AppEngine-specific and not provided in the standard Go build.
Does anyone know a way to upgrade the Go available in the AppEngine SDK? Does this mean that the Go in production is also 1.6.2?
Unfortunately you're stuck with the Go version that comes bundled in the latest App Engine Go SDK.
Even if you "switch" it locally with Go 1.7.1 and somehow you manage to compile and run your app with Go 1.7.1 (by adding the missing files from the SDK's Go root), the production environment currently also uses Go 1.6.2, so your app and Go code will run into errors in the live environment when code that is missing from 1.6.2 is referenced. Most likely even the deployment would fail.
Also note that when you deploy your app to App Engine, only the source files are uploaded, and your app is compiled in the cloud. So you can't even "trick" it by compiling it locally and somehow "exclude" source files and upload only the binaries (binaries are not even uploaded).
You can't do anything else but wait for Go 1.7.1 (or a newer version) to make it to the SDK. Note that the Go version bundled in the SDK usually lags a few versions behind, because for it to become the "live" version, it usually needs modifications / altering for the sandboxed environment of App Engine (certain restrictions must be applied / implemented), and it needs further / additional testing / strengthening regarding security.
At this point you should be able to upgrade - App Engine has supported Go 1.8 since 2017 and recently announced early support for 1.9.
In general, though, you're pretty much stuck with the versions supported in production - there's no way to link in your own version of Go to the SDK, and I'd argue that it would be extremely ill-advised to do so even if you could.
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.
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.