To access them dynamically I would like to use different property config files for my environments, like
config-production.properties
config-preprod.properties
config-sandbox.properties
Is there a system variable I could use to get the name of the environment the app is deployed in (production/preprod/sandbox)?
Or do I have to specify this manually as a property while deploying? Any idea or best practices?
There is no predefined variable with the environment name for applications deployed to CloudHub. You could set a property manually in Runtime Manager for that application, to define the environment name for the property file.
Another option could be to use Anypoint Platform REST APIs to get the name but it will require to make several request to different endpoints (at the least login, account, deployment, environments)
Related
Pub/Sub is really easy to use from my local work station. I set the environment variable GOOGLE_APPLICATION_CREDENTIALS to the path to my .json authentication object.
But what if you need to interact with multiple different Pub/Sub projects? This seems like an odd way to do authentication. Shouldn't there be a way to pass the .json object in from the Java code?
How can I use the client libraries without setting the system's environment variable?
Thanks
You can grant access for PubSub in different project using single Service Account and set it as env variable. See PubSub Access Control for more details.
A service account JSON key file allows to identify a service account on GCP. This service account is the equivalent of a user account but for the app (without user, only machine).
Thereby, if your app need to interact with several topic from different projects, you simply have to grant the service account email with the correct role on each topics/projects.
Another important thing. The service account key file are useful for app outside GCP. Else it's bad. Let me explain this. The service account key file is a secret file that you have to keep and store securely. And a file, it's easy to copy it, to send it by email and even to commit it into public git repository... In addition, it's recommended to rotate this key at least every 90 days for security reasons.
So, for all these reasons and the difficulty in security that represent the service account key files, I don't recommend you to use them.
With your local environment, use your user account (simply use the gcloud SDK and perform a gcloud auth application-default auth). Your aren't a machine (I hope!!)
With GCP component, use the component "identity" (load a service account when you deploy a service, create a VM,..., and grant the correct role on this service account without generating JSON key
With external app (other cloud provider, on premise, Apigee, CI/CD pipeline,...), generate a JSON file on your service account, you can't avoid them in this case.
I deploy my Docker image to default GAE by gcloud app deploy --image-url=us.gcr.io
I have successfully mapped my custom domain to this application with custom runtime and flex env.
My dispatch.yaml sends requests to its sub-domain:
dispatch:
- url: "dev.domain.com/*"
service: default
Now I want to use different images from Container Registry for test.domain.com and domain.com
While having all these images sharing same Cloud Storage and Firebase credentials.
Being new to GCP I wanted to learn any simple approach to organize such basic structure without going into services and versions (just by assigning proper images to serve relevant domains).
Is it even possible to do within one GAE project or I should create separate projects for it?
Mapping custom domains can only be done at the service level, so if you don't want to go into services separate projects is your only choice.
Actually using separate projects instead of services (or service versions) for implementing different environments has some advantages, I'd choose separate projects, too. See Advantages of implementing CI/CD environments at GAE project/app level vs service/module level?
I'm not sure if sharing the storage and credentials between production and other environments is a good idea (what if something goes wrong?). I'd keep them separate, too (maybe with some jobs to populate non-production projects with production data, if you need to). But if you do want to share them across projects you'll probably need to make some extra steps.
I want to access datastore (and storage) data of an AppEngine project via google-cloud-datastore and google-cloud-storage with an Python program on my own server.
This works with my AppEngine staging server, by creating a service account and giving it owner access (to the project).
Doing the same thing with the production AppEngine instance fails with
google.api_core.exceptions.PermissionDenied: 403 Missing or insufficient permissions.
Part of the problem might be, that I might be using the wrong project to create the service account with. There are more than one project with the same name in my cloud console. How do I identify the correct one?
How do I get more details about the problem?
First, note that the Datastore and the Cloud Storage are 2 different products with 2 different accessing methods.
The Datastore is closely tied to the GAE project - each project has its own datastore. The external access procedure in general is captured in How do I use Google datastore for my web app which is NOT hosted in google app engine?.
When switching the project (staging to production in your case) there are 2 things to keep in mind:
as you observed, you need to change the project you're accessing.
you also need to change the credentials you load and use for access to match the project you select, as each project has it own service account key configured in the above-mentioned procedure
For the google-cloud-datastore library both of these are simultaneously configured via the datastore.Client() call parameters (emphasis mine):
class google.cloud.datastore.client.Client(project=None,
namespace=None, credentials=None, _http=None, _use_grpc=None)
project (str) – (Optional) The project to pass to proxied API methods.
credentials (Credentials) – (Optional) The OAuth2 Credentials to use for this client. If not passed (and if no _http object is passed),
falls back to the default inferred from the environment.
The Cloud Storage is completely independent from GAE, the GAE project/credentials you use (if any) have no bearing on bucket/object access restrictions whatsoever. There's nothing you need to do from the google-cloud-storage library perspective when switching from one GAE project to another
To eliminate the confusion created by multiple projects having the same name just go to the IAM & admin Settings page, select the respective projects from the drop-down list on the top blue bar and rename them using meaningful names (click in the Project name box to edit the name, then click SAVE). Then re-check if you're using the right keys for the desired project.
I am writing a web service (java servlet) in the flexible environment of Google App Engine and I would like to be able to retrieve the GCP project ID that I am running in at runtime programatically. How?
There is a SystemProperty which contains such thins as project id, app version, etc:
SystemProperty.applicationId.get()
Javadoc is here: https://cloud.google.com/appengine/docs/java/javadoc/com/google/appengine/api/utils/SystemProperty
SystemProperty is a part of com.google.appengine.api which is not available on App Engine Flex environment.
On Flex your project name is available as environment variable.
So you simply can use just this:
System.getenv("GCLOUD_PROJECT");
Please see Migrating Services from the Standard Environment to the Flexible Environment for more details.
Also please note that on local development server running Jetty this environment variable might not be set. If so the above code will return null on your development machine.
You might want to set it explicitly though for your local development server needs. For example if you use Bash you can do:
export GCLOUD_PROJECT=myproject
Also you can add it to your development server startup script or to your ~/.bashrc script, whatever works better for your needs.
I have solution containing silverlight project, wcf service project and other projects of C# i want to have one app settings file from where all projects can load settings. Which will be useful in case of db interaction, logging etc..
Currently i m changing all app settings file in all projects.
I have used Nini successfully for some time now. It allows you to put all your config settings in a central file which can then be referenced from all your server-side projects, be it web applications, scheduled jobs, wcf services etc. For the Silverlight client apps, I created a WCF configuration service. All the different Silverlight apps access this service at startup to load their settings. This means that the server-side apps only need to know the location of the Nini configuration file, and the Silverlight clients only need to know the url to the configuration service (transferred through the in the .aspx page). The configuration service then accesses the Nini config file and returns a collection of ConfigurationSettingEntity objects. These just contain a key and a value. Of course it is of extreme importance to make sure that all sensitive settings (e.g. db connection strings) are never transferred over the configuration service. Nini allows you to divide your config file into sections. I have three sections currently. One for the Silverlight clients ("ClientSettings"), one for server-side settings only ("ServerSettings") and one that contains any shared settings ("CommonSettings"). This way you can make sure that the configuration service never returns anything from the ServerSettings section. This has worked really well for my purposes.
Have a look at Configure Silverlight 3 Applications using the Web.config File from ASP.NET