is it possible to deploy to the same appengine project from multiple users? Like if I add another user to have access to my appengine project how can the other user also deploy to my appengine? Is this possible?
Yes, multiple users can deploy to the same AppEngine app id. Just give them each permission from the cloud console.
At that point, every authorized developer is the same and can deploy in the normal fashion. Just keep in mind that users can/will overwrite each other's deploys if they push the same version identifier.
The most recent deploy of the same version wins and overwrites the earlier deploy. So, make sure your team workflow accommodates this.
Related
I want to achieve something that Google Play store offers i.e. releasing app to a set of users and the rest of users will keep seeing the existing app.
Is there a way to achieve this with a web app deployed using Docker and GCP?
Someone shared an interesting article about Canary build.
Canary Deployments are where you roll out the new version of your service while keeping the older one alive. Some customers will be routed to the new version while others will be routed to your existing version.
https://stackify.com/canary-deployments/
I would like to know how to deploy the application from bitbucket using pipelines to multiple Google Cloud projects.
Here is our current set up and it is working fine.
On Bitbucket, the application repo with development/UAT test/production branches, once the pull request approved and merged into development/production, it shall deploy to the GCP app engine through the pipelines.
The problem now, we want to isolate each client in GCP which mean each client will have its own GCP project, cloud SQL, App engines, storage bucket, etc...
I need some advice on how to change the deployment workflow in bitbucket and pipelines, so will work for the new set up.
For the branches setup on bitbucket, I'm thinking like below, but if I go for option2, then it seems too much if got more clients.
Option 1 (repo branches)
development/
UAT test/
validation/
production
Option 2 (repo branches)
development/
UAT test client1/
UAT test client2/
validation_client1/
validation_client2/
production_client1/
production_client2/
The first step, I know I have to create different app.yaml for each app engine service for each client, so it can deploy the app engine service to different CGP projects/bucket/SQL instance.
Also just found out the bitbucket-pipelines.yml only support 10 steps, if I create so many branches then it will over the limits for sure.
Does anyone have any suggestions about how should be set up?
Thanks,
You could create Cloud build triggers to specific bitbucket branches or repos (whatever your branching model is defined) and deploy the app engine implementation to the App engine service on the same project, and if you need to customize other steps, you could use custom steps as described here. Finally you can take a look at how to create a basic configuration file for Cloud Build if you are not very familiar with this product
In my previous App Engine projects I used the Cloud Datastore, and during development I could debug my app on the local server and it would use a local database, stored in a file I could wipe out if I wanted to start from scratch.
With Cloud Firestore, even when I'm running locally it's talking to my real cloud database. Is there still a local option? Note that I'm not talking about client-side persistence, I'm talking about a mock development DB.
Google recommends setting up multiple projects if you want dev/staging/production, and I'm guessing that's the answer, but I'd like to know before adjusting my workflow.
I think (now only a few months later) that this is supported. When I run my app, using dev_appserver.py, I see a message
INFO 2019-02-14 00:08:56,030 admin_server.py:150] Starting admin server at: http://localhost:8000
Going to that URL shows me all the instances I have been seeing. These seem to persist even when the dev_appserver is restarted. Reading this and other posts I was convinced that my development was using my actual cloud database, but going to https://console.firebase.google.com/project/myproject was showing completely different content.
Just to be sure (because google is google and everything is named the same) I'm using an appengine app and a gcloud project, storing things to Firestore using ndb.Models...
Oh, but careful. My app I was also using the cloudstorage (blobstore?) and even though the localhost:8000 showed these, THESE WERE THE REMOTE INSTANCES.
There is a local emulator for Firestore when using the Firebase CLI:
https://firebase.google.com/docs/rules/emulator-setup
My team and I are working on the Trendy Lights Tutorial.
We have set up all the files and also have converted the .p12 key to .pem key but failed to run the app on the Google Cloud Platform and constantly got the error message saying:
You do not have permission to access project [...] and service
"cloudbuilt.googleapis.com" is not for consumer..."
We have already whitelisted our service account for the use of Earth Engine. Does anyone know what the problem might be?
Thank you so much!
I see that you are attempting to deploy your application to the App Engine Flexible Environment.
The Flexible environment differs from the Standard environment in that it gives you more control over the individual instances that are running your deployed application. It does this by hosting your application within Docker on Compute Engine virtual machines.
Therefore, you will need to enable the Compute Engine API for your project so that the GCloud tool can start new Compute Engine virtual machines when you deploy your application.
Note: Since the Flexible environment uses Compute Engine resources, you will also need to enable billing for your project.
If after performing the above you still experience the 'cloudbuild.googleapis.com' error, I ask that you run gcloud components update, then ensure that the value of account seen in the output of the command gcloud info has Owner or Editor permissions in your project.
If it still persists after all of the above, you should then open a Public Issue Tracker to inform our backend team of the issue.
We would like to develop and sell custom commercial GAE applications. I would like information on the deployment of GAE applications on arbitrary Google Apps domains (i.e. not appspot).
Suppose our company is abc.com and we are selling app to def.com and xyz.com. What are the steps to deploy our app on our customer's domain?
When an app is deployed on many domains:
Is the code duplicated or shared?
Is the datastore definition duplicated or shared (or more precisly the kinds)?
Any domain attribute add to the entity?
You have three options at the moment, when it comes to a 'multi-tenant' app such as you describe:
You can have a single app that your customers add to their domains. Your app will have a single datastore, but you can use the Host header to determine which customer is accessing the app, and segregate the datastore entries based on that.
Easy to deploy and upgrade
Easy for customers to install
Users have to have Google accounts, not Apps accounts, to log in.
You can deploy a fresh app instance for each customer.
Harder to deploy and upgrade
More customer involvement required to install
Provides firm separation of data
Users can log in with their Apps credentials
You can work with Google to create a new Apps Marketplace app
All the benefits of point 1 and 2, above
Requires Google involvement
No certain release date yet
This is possible but to the best of my knowledge, def.com & xyz.com will have to sign up for Google Apps.
Once the domain is registered with Google Apps by your prospective customers, they can add not only Google Apps like Gmail & Docs to subdomains (mail.def.com & docs.def.com) but also any GAE apps (fooapp.def.com).
Is the code duplicated or shared?
Shared
Is the datastore definition duplicated or shared (or more precisly the kinds)?
While the schemas (definitions) are shared, what isn't shared is the actual datastore. i.e. each instance of your app will have separate data.
Any domain attribute add to the entity?
You can figure out which domain your app is being served under using one of the CGI/HTTP environment variables. I don't remember which variable exactly but I'll update the answer once I look at some old code of mine. Once you find out what is the current domain, you can choose what to do with that info, including saving it to an Entity or simply denying access.
Another cool feature about this is that let's say company def.com is using hosted GMail and have Google Authentication for their employees. Now if your app is using the GAE provided authentication hooks, then you can automatically authenticate just their employees without any code change on your part! At least, that's the theory since I haven't tried it out myself ;-)