Deploy app into two environments: Staging and Production.

[Bill]

Hello,

I have a Laravel app with app.yaml and cloud_build.yaml files. I need to deploy the master branch to production and dev branch to staging. Such that each environment has its own URL.

Do I need a separate Cloud Project for each environment? Or I can use the same App Engine to host both the Production and Staging?

If I need two separate projects, how can I have two app.yaml and two cloud_build.yaml files?

Regards

Bilal Haidar

[Elliott (Cloud Platform Support)]

Hello Bill,

I was able to find the information you need at least to get started. The following document describes what a project is and how you may use one or more than one depending on your use case. Since you want two urls, each environment has its own URL.

“You control the scope of your projects. A single project might contain multiple separate apps, or conversely a single app might include several projects. Projects can contain resources spread across multiple regions and geographies.”

The article goes on and provides a recommendation…

“to have one project per application per environment. For example, if you have two applications, "app1" and "app2", each with a development and production environment, you would have four projects: app1-dev, app1-prod, app2-dev, app2-prod.”

The reason is that the environments will be isolated from each other to prevent changes from one application affecting the other.

The article gives an example that you may “grant all developers access to development projects but restrict production access to your CI/CD pipeline.”

The article goes on that your project structure depends on your business case and requirements.

There is an example structure here.

You also asked about having separate app.yaml and cloud_build.yaml files. From my understanding, it is possible to have separate configuration files in each project. 

I hope I provided the information you need.

[Bilal Haidar]

Thanks a lot Elliot! That is really so much helpful!

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/c4760782-abf3-4722-8951-afab3c577fa5n%40googlegroups.com.

[Kaan]

My .02 but keep in mind that I don't use cloud build

Build your apps to be identity aware, app.yaml doesn't even include the app id anymore, the app can know whether it's in staging or production

So basically, in theory, previously you only needed a build step that renamed app.yaml's project ID, now you don't even need it, just deploy to staging or production

[Bilal Haidar]

The only difference is the env variables.

I am considering defining this inside build_cloud.yaml file under "options" to make them global ones. However, I am not sure Laravel/PHP will pick up those env variables. I still need to try it out.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/c7dd2ad4-b4ef-494a-aeff-c382250cfa44n%40googlegroups.com.

[Denis T (Google Cloud Platform Support)]

Hello Bill,

Specifying the environment variables (env) under options[1] will make them global for your build steps.
However, if you want to define the environment variables that would be available to your app, you can do that in the "app.yaml" - [2].

Regards,

Denis T.
_______

[1]: https://cloud.google.com/cloud-build/docs/build-config#options
[2]: https://cloud.google.com/appengine/docs/standard/python3/config/appref#environment_variables

[Bilal Haidar]

Thanks a lot.

I’m a bit confused here. When under App Engine, build takes place on one server and then deployment happens on another server? All this under the umbrella of App Engine? 

To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/09b0a16a-250b-45ba-8c61-2775649d2989n%40googlegroups.com.

[methkal]

Hello,

In general, when you run `gcloud app deploy`, your app source code will be uploaded to a storage bucket then a docker image will be built for your app. After that, this image will be used to deploy containers of your app on App Engine servers.

[Bilal Haidar]

Thanks for the info! I appreciate it.

Basically, App Engine is just a platform and family of services then. Good to know. 

Even if I don't package my cloud_build to use docker images, eventually, my app is put in a docker image?

Thanks

To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/2d4f73dd-9054-4669-a5de-c22c6beebb23n%40googlegroups.com.

[Daniel (Google Cloud Support)]

You are right. As advised on the product description for App Engine Standard [1] you are just basically deploying an application into  container instances running on Google's infrastructure.

In the specific case of App Engine Flexible you can even define your own Dockerfile [2] for a custom docker image. Also notice that the base images for all the runtimes are publicly available for your inspection (e.g. Python [3] , or PHP [4]).

[1] https://cloud.google.com/appengine/docs/standard

[2] https://cloud.google.com/appengine/docs/flexible/custom-runtimes/about-custom-runtimes

[3] https://github.com/GoogleCloudPlatform/python-runtime

[4] https://github.com/GoogleCloudPlatform/php-docker

[Bilal Haidar]

Thanks a lot 

On 13 Jan 2021, at 1:10 PM, 'Daniel (Google Cloud Support)' via Google App Engine <google-a...@googlegroups.com> wrote:

You are right. As advised on the product description for App Engine Standard [1] you are just basically deploying an application into  container instances running on Google's infrastructure.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/81275797-132b-4672-abf3-9bccc49fe289n%40googlegroups.com.