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.
Related
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?
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 an existing app that uses the deprecated Python 2.5 and the deprecated master/slave datastore. According to the docs, I must migrate the datastore to HRD before I can upgrade to Python 2.7. Before I can migrate my M/S datastore to HRD, I need to do some work on the app and test it using the dev server.
However, I upgraded to the most recent version of the SDK (1.8.6), and it does not support Python 2.5. Somebody else encountered this problem and learned that the latest SDK that supports Python 2.5 by default is Python SDK 1.7.5. From where can that be downloaded? Or, is there a way I can make the SDK 1.8.6 work with Python 2.5?
In the 1.8.6 SDK, there's an old_dev_appserver.py that works with Python 2.5. That'll help you along as you migrate.
Dave W. Smith gave me the answer but I didn't know how to implement it until I made a discovery that maybe most people already know, But in case it might be helpful to somebody, I will tell it here:
I do all my GAE/Python/Flex development work in Eclispe, except that I used the launcher for local testing and deploying. (I am command-line adverse.) I discovered that using the PyDev Eclipse plugin it is easy to set up a "run configuration" (under the PyDev "Run" menu) whereby you can set up command line parameters, etc. and run any python program from within Eclipse. I now use that facility for running dev_appserver.py (and when needed for my Python 2.5 app, old_app_devserver.py). I no longer have a need to use the launcher. I also set up a PyDev run configuation to deploy my app and performing various appcfg.py functions (vacuum indexes, etc.).
first question from newbie. Haven't needed to post a question for months now -- so many great answers already posted. I am stuck on this one, though.
Developing on a Mac, Python 2.7, Django with the django-nonrel project, GAE datastore. Up to and including GAE SDK 1.6.3, all goodness. After upgrading to GAE SDK 1.6.4, noticed 3 strange things:
Dev server (python manage.py runserver) fails immediately with "Error: No module named webob." No other errors or output. I rooted around under /usr/local/google_appengine/lib/... and, indeed, no module named webob. There are two close matches -- webob_0_9 and webob_1_1_1. I made a symlink webob -> webob_1_1_1 to get past the error.
Startup messages from the dev server include an INFO: message that the SDK version is later than the advertised version. Google has 1.6.4 on their download site, so not seeing how my 1.6.4 is later than the latest.
Django's syncdb command (python manage.py syncdb) will no longer create the .gaedata/datastore file. It says it's creating tables, it prompts me for the superuser creds, it even says it installed a bunch of objects from my fixture file. It gives no errors, but when it completes, it has done none of these things -- the .gaedata/datastore file doesn't even exist.
Prior to 1.6.4, syncdb worked great, including loading fixture data. I tried starting a fresh project with only bare bones files in it and a simple model (one class having one field) to see if some complexity I had introduced might be the cause of the problem. Even in simple-land, syncdb wouldn't create the datastore.
My only solution was to fall back to GAE SDK 1.6.3 -- everything works once again. Anyone else seeing similar symptoms with SDK 1.6.4? Are there obvious diagnostic steps I should be taking?
Fixed in latest django-nonrel. Either sync to latest code, or manually integrate this pull request:
https://github.com/django-nonrel/djangoappengine/pull/24
Haven't seen this problem, don't know.
There's a workaround, but it's not merged into the master branch yet, you'll have to manually integrate the changes.
https://github.com/django-nonrel/djangoappengine/pull/25