Following along in the managed VMs tutorial, I wanted to run some of the later examples locally. (As I would for development/testing.) When I deploy my project to the cloud it works very happily, but when I run it locally (gcloud preview app run ./app.yaml) I get an import error because flask wasn't installed / the docker image wasn't updated.
Is there a way to build and run the container locally?
Set the environment variable GAE_LOCAL_VM_RUNTIME to 0:
export GAE_LOCAL_VM_RUNTIME=0
gcloud preview app run app.yaml
This behavior is described in the Cloud SDK RELEASE_NOTES for version 0.9.71:
For several months on the Managed VMs team we've been testing a new mode of
dockerless local development on gcloud that makes developing a module for
Python, Java and Go users similar to development of regular App Engine
applications. This new mode relaxes the sandbox constraints present in the
devappserver for vm: false applications, and does not require Docker to be
installed.
You can currently opt-into this behavior by setting GAE_LOCAL_VM_RUNTIME=1;
In this release of the Cloud SDK, we will be making this behavior the
default for Managed VM users who are using gcloud.
You can still opt-out of this behavior by setting: GAE_LOCAL_VM_RUNTIME=0.
Related
I'm trying to set a Local Development Server for Lightning Web Components according to this link but when I try to install the plugin #salesforce/lwc-dev-server I get this error message :
Code: ShellParseError
and a .js file named npm-cli.js opens in my editor with this content:
#!/usr/bin/env node
require('../lib/cli.js')(process)
Anyone knows what to do? Thanks in advance.
In general, the local development for Lightning Web Components still has beta status: Local Development (Beta)
However, even the beta version can now be used relatively reliably. To set up local development you only need to authorize an org and install the development server. This allows you to develop locally without the need to push your components to an org first.
The local development server and its configuration are provided by a Salesforce CLI plugin. Before you install the plugin make sure you are using the latest Salesforce CLI version by running:
sfdx update
Then the lwc-dev-server plugin can be installed as follows:
sfdx plugins:install #salesforce/lwc-dev-server
After installing the plugin, to start the server on http://localhost:3333 and access all components of the project just run:
sfdx force:lightning:lwc:start
There is even a short official guide on how to set it up: Set Up LWC Local Development
We have an older application based on the AppEngine SDK (now deprecated) and the superseded Cloud Datastore.
In the process of migrating to Google Cloud SDK we also decided to move from JPA/Datanucleus to Objectify.
Given that the Cloud Datastore will be automatically upgraded to Cloud Firestore in Datastore mode sometime in the future, we decided to test our application as described at the bottom of this page:
https://cloud.google.com/datastore/docs/upgrade-to-firestore#testing_an_existing_application
1) Create a new project. In this project, create a Cloud Firestore in Datastore mode database.
2) Using the managed export service, export some of your application's data to Cloud Storage.
3) Using the managed import service, import your application's data to your new project.
4) Copy app logic you want to test to the new project or simulate app behaviour against the new project.
That's what we did and after some issues we could make a portion of our application run fine with the new datastore in a separate test project.
Now to the actual issue...
We wanted to test if the updated application could also run with the superseded Cloud Datastore, so we won't have to worry when the automatic upgrade occurs (as our app will be already ready).
So we deployed it as a new version of the existing AppEngine project (v2-dot-.....): unfortunately running the new version throws a permission error as soon as the app tries to read the datastore:
com.google.cloud.datastore.DatastoreException: Missing or insufficient permissions
So the questions are:
- could this be related to the Cloud Datastore not being upgraded to Cloud Firestore in Datastore mode for our project yet?
- is there anything we can do (add specific permissions maybe) to make it work anyway?
Our concern is that we need to have the new version of the app deployed before July 2020 (that's when the older AppEngine SDK will stop working), and we are worried that the automatic upgrade of the datastore will occur later.
Thank you for your help.
Turned out our project doesn't have the PROJECT_ID#appspot.gserviceaccount.com member in IAM.
It has a pletora of other members (for example: PROJECT_NUMBER-compute#developer.gserviceaccount.com, PROJECT_NUMBER#cloudservices.gserviceaccount.com, service-PROJECT_NUMBER#compute-system.iam.gserviceaccount.com, etc) which I guess are legacy members used in previous versions of Google App Engine.
Adding PROJECT_ID#appspot.gserviceaccount.com with the role Editor fixed the issue: now the new version can be deployed to the old projects and it works fine even if the datastore has not yet been converted to Cloud Firestore in Datastore Mode.
I just ran into this issue and spent way too much time troubleshooting it. Nine times out of ten if you're running into this issue it's because the default App Engine service account doesn't have permission to edit Cloud Datastore. The default App Engine service account is used by default if you're doing a simple gcloud app deploy and nothing else fancy. I solved the problem by giving the default App Engine service account the roles/datastore.owner role with the following:
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="serviceAccount:PROJECT_ID#appspot.gserviceaccount.com" \
--role="roles/datastore.owner"
Trying to build the optashift-employee-rostering project
I followed the instructions in the readme file to build the app from this repo, but it fails every time. When I try it locally on my Windows 10 with Docker and the "oc.exe" tool, it simply hangs and the oc fails to open even the openshift local console (the one on localhost).
I've created an account on openshift (Starter: US East (Virginia) For individual learning and experimenting.)
When I do it in openshift online, it fails the build but doesn't tell me the reason.
Here are the logs:
http://pasted.co/47eed571
How can I deploy this app to openshift or to some other cloud (Google Cloud/Microsoft Azure etc.)
OpenShift Online (= free edition) has less than 1GB of RAM for the build pods, which isn't enough to build it (GWT compilations needs more). That leads to error code 137 during GWT compilation.
But OpenShift Online is enough to run it.
Workaround: Build the war locally with ./provision.sh deploy employee-rostering --binary
as explained here in the readme. I hope that GWT and OpenShift play along better in the future.
Google Compute Platform
I've got an Angular (2) app and a Node.js middleware (Loopback) running as Services in an App Engine in a project.
For the database, we have a Compute Engine running PostgreSQL in that same project.
What we want
The testing has gone well, and we now want to have a test version (for ongoing upgrade testing/demo/etc) and a release deployment that is more stable for our initial internal clients.
We are going to use a different database in psql for the release version, but could use the same server for our test and deployed apps.
Should we....?
create another GCP project and another gcloud setup on my local box to deploy to that new project for our release deployment,
or is it better to deploy multiple versions of the services to the single project with different prefixes - and how do I do that?
Cost is a big concern for our little nonprofit. :)
My recommendation is the following:
Create two projects, one for each database instance. You can mess around all you want in the test project, and don't have to worry about messing up your prod deployment. You would need to store your database credentials securely somewhere. A possible solution is to use Google Cloud Project Metadata, so your code can stay the same between projects.
When you are ready to deploy to production, I would recommend deploying a new version of your App Engine app in the production project, but not promoting it to the default.
gcloud app deploy --no-promote
This means customers will still go to the old version, but the new version will be deployed so you can make sure everything is working. After that, you can slowly (or quickly) move traffic over to the new version.
At about 8:45 into this video, traffic splitting is demoed:
https://vimeo.com/180426390
Also, I would recommend aggressively shutting down unused App Engine Flexible deployments to save costs. You can read more here.
I packaged my Scala/LiftWeb app with the sbt one-jar plugin into a single executable jar file and packed it up with Docker, exposing the embedded Jetty's port in the Dockerfile.
It runs fine locally on Docker and appearently deploys clean on AWS EB using the CLI deployment tools. On the received EB URL however, all I see is the congrats page saying "Your Docker Container is now running in Elastic Beanstalk on your own dedicated environment in the AWS Cloud.".
So, where is my app? Do I miss any steps making my app publicly available on my EB instance?
For future reference, the problem was caused by using an obsolete 2.x version of the aws-eb-cli tools package. Upgrading it to 3.x made the error obvious - building the docker image has failed on AWS.
What I was looking for was running an existing docker image, I found instruction for this scenario at https://aws.amazon.com/blogs/aws/aws-elastic-beanstalk-for-docker/.
Thanks a lot for Nick for asking the right questions which made me realize the obsolete tools package!