By deploy, I assume they mean code changes are pushed to production?
If I had 2 or three devs working with me on a project, what is to stop them from pushing changes that break the production site?
What checks and balances do we have to avoid such error? Do you setup a staging and production environment in GAE, having someone manually verify everything appears to work before making live.
If you want to limit individual devs doing uncontrolled pushes to the code.google.com (from which the deploys happen), then arrange for one and only one local repository be the local repo-of-record, and only configure that one to know about the source.google.com 'origin' server. Integrations are pulled into that repo, and (when you're ready) push to deploy from there.
Here's how it works under the covers. When you use gcloud to set up a project, it modifies default/.git/config to know about source.google.com, and to use an authentication helper that ties in to oauth (re-using the token that gcloud auth login will store locally) to authenticate. To limit deployment, make this the integration repo, and configure dev repos to push to it.
If you set up a separate staging version of the app, it's a policy decision on your side about whether to use the same scheme, or let developers deploy to staging individually. The mechanism you'd use to configure this is all .git/config wiring.
Related
I have a Quarkus application already deployed on Google Cloud Run.
It depends on MySQL, hence there is an instance started on Cloud SQL.
Next step in my deployment process is to add keycloak. From what I've read the best option seems to be Google App Engine.
The approved answer in this question gave me some good insight of what needs to be done ... mostly.
What I did was:
Locally I made a sub-directory in the main project.
In that directory I added the app.yaml and the Dockerfile (as described here for instance).
There I executed the said two commands: gcloud init and gcloud app deploy.
I had my doubts about this set up and they were backed up by the error I got eventually:
ERROR: (gcloud.app.deploy) INVALID_ARGUMENT: The first service (module) you upload to a new application must be the 'default' service (module). Please upload a version of the 'default' service (module) before uploading a version for the 'morph-keycloak-service' service (module).
I understand my set up breaks the overall structure of the project but I'm not sure how to mix those two application with the right services.
I understand keycloak is a stateful application, hence cannot live on Cloud Run (by the way the intention is for keycloak to use the same database instance shared with the application).
So does any one know a more sensible set up, or what can I move in mine in order to fix it?
In short:
The answer really is in reading the error message (thanks #gaefan) - about the error itself it explains enough. So I just commented out the service: my-keycloak-service line in the app.yaml (thus leaving gcloud to implicitly mark it as the default one) and the deployment continued.
Eventually keycloak didn't connect to the database but if I don't manage to adjust the configurations that would probably be a subject to a different question.
On the point of project structure and functionality:
First off, thanks #NoCommandLine and #guillaume-blaquiere for your input!
#NoCommandLine the application on Cloud Run is sort of a headless REST API enabled backend. Most of the API calls are secured by keycloack. A next step in the deployment process would be to port an existing UI (React) client on the Firebase hosting (or on another suitable service - I'm still not completely sure which approach is best) and in order for the users to work with this client properly they must make an SSO through keycloak first.
I'm quite new to GCP and the number and variants of the available options are still overwhelming to me - one must get familiar with the nuances but I guess it takes time. So I'm still taking suggestions on how to adjust my project structure to fit better the services stack. Thanks!
I just released my react app in a production environment in Cloud Foundry, but the only problem is that if I make changes to the app, and reupload the app, my users don't see the changes unless they clear their browser data, what can I do?
Reason for this issue: Browser is using its cache not your build to serve the client
Remedy to outcome: Inform the changes in metadata.json
metadata.json is a file that swings between request and browser checks for any mismatch with it's cache. if no then cache is served to client.
There are more then one way, thus am not telling direct solution, instead gothrough the below link will take to through various steps to follow
flexdinesh blog from dev.to
How do I move instances from one project to the next?
Problem: I have frontend production instance and backend production instance in 2 separate project. I would like to have my production instances (both frontend and backend) in the same project.
How do I move instances from one project to the next within Google App Engine?
You could have the 2 apps run as 2 separate services inside the same project. To do that you'd have to deploy the app from the project that will disappear as another service in the project that will remain. Some code changes might be required, depending on how the app is coded. Typically they're small changes, though.
IMHO it would be simpler to keep the project currently hosting the frontend and move the backend over from the project to be retired. The reason is that the frontend is typically better fitted to play the default service role and it is already setup as such, changes should be smaller. Performing the move in the other direction would mean both services would need to changed.
You might need a dispatch.yaml file to route incoming packets, unless the URL mappings of the services are really well done. Not a big deal.
If you're using custom domains, with a bit of care it is possible to make the move (almost) transparent - by having the new service up and running before retiring the old project. DNS propagation time becomes rather irrelevant - both old and new services being simultaneously ready during the transition.
Note: technically you wouldn't be "moving" instances, you'd just stop the ones serving the project to be retired and start new ones for the service added to the project to be kept.
More or less related:
Change runtime from Python to Go in App Engine standard environment
Can a default service/module in a Google App Engine app be a sibling of a non-default one in terms of folder structure?
I need to test my wordpress install which I have set up already and deployed. I have to debug, so waiting 10-15 mins for it to deploy to test one thing isn't going to work.
All they mention in their docs: https://cloud.google.com/appengine/docs/flexible/php/testing-and-deploying-your-app#running_locally
Running locally
"To test your application's functionality before deploying, run your application in your local environment with the development tools that you usually use."
That's it. How can I actually serve my wordpress application? My tools I "usually use" are xampp...very confused.
Can someone help me run my flex env locally to test it?
You may want to take a look at this for the initial tests for your PHP application. You would have to install composer on your shell for it, if you haven't done it already.
Then, for the WordPress application, follow the steps described here to test the Cloud SQL instance that is associated to the app. There is also the possibility to test all the updates you want to apply to the WordPress side. Skip the deploying part until you confirm all your changes work for you, so that you don't have to wait all that time for a deployment.
I am developing an app locally in Google App Engine. I have built a small datastore for development purposes. Rebuilding it after every power cycle on my Mac got tedious so I made it permanent. Now I run my app locally with the following command:
/usr/local/bin/dev_appserver.py "--datastore_path=./permanent.datastore" appengine_prototype
Life is good. I have decided to deploy my app so I can test http post commands from a different machine. When I tried to register my current application id (example), I found that it was unavailable (shocker!). So I registered a different application id and planned to change my local application id to match. However, when I changed the
application: *app-id*
line in my app.yaml file, my app stopped recognizing my permanent datastore.
So, how can I change my application id to the one I registered, maintain the connection to the permanent datastore and then push the whole shebang online? I tried running the app twice locally, first with the permanent datastore referenced in the command and then without, hoping that the default temporary datastore would inherit from the previous permanent datastore. That didn't work. Do I need to start by copying the permanent datastore to the default temporary datastore? How would I do that? Any help would be much appreciated.
Thanks,
Dessie
If your intention is to eventually push your local data to your live environment anyway, then your best bet is to:
use bulkloader.py to backup your local data (while using oldid in your config)
then change your config to your newid
then use bulkloader.py to push your data to your new development server (ran with --datastore_path=./permanent.datastore2 or something)
then use bulkloader.py to push your data to the GAE production server
Details of bulkloader.py can be found in the docs and an example here