For my application, I have two different environments on GCP: staging and production. My static Angular application is currently deployed on GAE. Now I'm wondering if it's possible to deploy these two environments separately with two different URL's? Or is there another solution better suited for such a setup?
If not I'll probably have to switch back to Google Cloud Run.
Thanks in advance.
2 environments = 2 projects! It's easier and you have App Engine free tier duplicated (per projet)
If you deploy 2 time the same package on the same GAE (so, on the same project), you need to have a app.yaml per deployment. And thus your staging deployment pipeline isn't exactly the same as the production deployment pipeline. And the URL format also. The non default service has his URL prefixed with the service name. And you should have issues with handlers definitions, the scheduler (if you have one),....
No, the easiest is to have 1 project per environment
Related
On GCP, I run Cloud Build from one project and deploy code to App Engine in another project. It looks like the project where build runs from needs to have App Engine Admin API enabled. Is it a real request or I missed the real configurations?
App Engine Admin API is required as it is used for any App Engine-related management operations
Also, based on the link above:
The Admin API provides you with:
An integration point for your development and build tools.
Tighter control around deploying new versions, including the ability to automate traffic
migration between two versions or traffic splitting across one or more versions.
The ability to programmatically manage applications across multiple Google Cloud projects.
So yes, if you plan on deploying code to App Engine using Cloud Build, you need GAE Admin API enabled.
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
I'm looking at moving my application to google cloud and I'm having a hard time understanding how best to organize my project. It seems like you can only have one App Engine application per project with services available to support a microservices architecture and instances representing the App Engine instances created via auto scaling.
What is the correct way to build an App Engine for my API server and an App Engine for my Web Server? Do I need to have a project for each? I'm essentially trying to accomplish the following:
It is straightforward to have a single GAE project implement both your website and an API. You can even do this within a single service. You could put each in a separate service, and the advantage of that is that you can update one without updating the other. For small projects, a disadvantage is that two services are more expensive than one (though GAE is quite inexpensive overall).
For prod vs dev, you'll need to explain your requirements a little more, but here are some thoughts.
Each GAE service has multiple versions. You can deploy your production version to www.mycompany.com and deploy a dev version to dev-dot-myapp.appspot.com (that's the way GAE does URLs for versions of your app). Both of these versions will access the same datastore so you need to be careful with the dev version so that it doesn't mess up your prod implementation.
If you have a dev situation that is bleeding edge and shouldn't be able to access the datastore of your production app, then you would create a different GAE project for that.
Here is a way to visualize it:
Google Cloud Project A
GAE Project A
production www service
production API service (this could be combined with production www service)
dev www service
dev API service
Google Cloud Project B
GAE Project B
bleeding edge www service
bleeding edge API service
Best Practices:
Your Dev and Prod should be in separate projects for both security and billing purposes.
App Engine:
You can only have one App Engine per project. This will create a problem for you to use App Engine for both API Server and Web Server. In this case, I would not use App Engine at all and instead look at Containers on Compute Engine or go for Kubernetes.
Even a single node Kubernetes Cluster will shock you with its flexibility and power. Containers on Compute Engine still have a lot flexibility and power too. If you like the concepts of App Engine Flexible, then you might really like containers. The exception here is that App Engine makes some concepts brain dead simple where you have more work in configuration for Containers or Kubernetes.
You have a Google Cloud project Project1 with App Engine enabled and serving your legacy application.
You want to rebuild your application using a different programming language and hence need a separate project (Project2) with its own separate App Engine.
You want to install some kind of reverse proxy appliance in front of your Project1 App Engine, so that you can gradually route more and more traffic to Project2's App Engine.
What's the best way to achieve this?
Google Cloud Load Balancer doesn't appear to work with App Engine (only Google Compute Engine), so I'm thinking establishing a reverse proxy server (e.g. NginX) container would be the best bet.
Depending on how you want to organize, you can duplicate your entire application within the same project by just deploying as a different service or as new versions of your existing service. For example, say you have two services frontend and backend for a simple web app. (Let's say they're both written in Python)
For deploying as a separate service, you can create a new version of your application in a different language, say Node.js. You can deploy the new services as frontend-node and backend-node.
If you don't want to do that, you can rewrite your application in a different language and then deploy as a new version of your existing services. In the "Versions" section, you can see your versions of the same service and they can be different language runtimes.
Either way, you can then use the "split-traffic" feature to customize and test implementations of your application.
Generally speaking, you should avoid using projects to isolate different variants and/or components of your application unless you really need too. App Engine services can each be a different runtime from each other so there's almost no point in provisioning a whole new project even though you're redeploying in a different language.
Google Cloud's structure related to "projects" has me really confused.
On the one hand all GCP services are encapsulated in a "project" right? So I think, OK I'll create something like "test", "stage", and "prod" projects. All my applications can be tested in "test" and eventually move to "prod" when they are ready to go live. Also, I can have SQL,bigquery,bigtable and whatever else in the test project that developers can hack on without having to worry about effecting production.
But I can only have one app engine app per project? How does that work? I can see how in app engine you have different versions so if I have one project per app engine app the test/staging mechanism is in that app's project, but what about the other GCP services?
If I have a bigtable or bigquery or something on storage multiple apps need to access what "project" do I put that stuff in?
Do I still have a "test","stage","prod" project for my services (where my DBs, storage, etc live), but then also create separate projects for each app engine app?
If multiple apps need to access something, it can live in one of the app's projects- that doesn't make sense.
Edit: google does have some good docs about how projects and services can be organized https://cloud.google.com/appengine/docs/python/creating-separate-dev-environments
While you can only have one App Engine app per project, an App Engine app can host multiple services, each of which has several versions of code deployed.
You can configure resources in one project to allow access to users/apps outside that project. See, for example Setting ACLs for how you can allow multiple projects to access a Cloud Storage bucket. Similar cross-projects access can be configured for most if not all Google Cloud resources/services/apps - but you need to check the respective docs for each of them to see the specific details each of them may have.
With this in mind it's really up to you to organize and map your apps and resources into projects.