Closed cloudwheels closed 5 years ago
@cloudwheels, please ignore my previous comment. I think the better way to get this working is to add this line in src/index.ts
:
options.rest.host = appEnv.isLocal ? options.rest.host : appEnv.host;
i.e.
export async function main(options: ApplicationConfig = {}) {
// Set the port assined for the app
if (!options) options = {};
if (!options.rest) options.rest = {};
options.rest.port = appEnv.isLocal ? options.rest.port : appEnv.port;
// ------- ADD THIS LINE ----------
options.rest.host = appEnv.isLocal ? options.rest.host : appEnv.host;
// ---------------------------------
const app = new TodoListApplication(options);
I'll submit a PR to update the docs. Thanks for reporting this issue.
~@cloudwheels, I'm just trying out as well. It might be related to the recent change: https://github.com/strongloop/loopback-next/commit/2e7d4bb6e7b30aedfcc373a0d2bed3c0f1ad07c8. My workaround is not to use the config
value in index.js
, i.e.~
Thank you much @dhmlau -confirm this works - please see next comment for more succinct summary than this one...
I have / had taken time to check the repo & issues & web generally before posting this issue, so I can see how hard you are all working and pressing issues such as reviewing & extending the deployment docs for various platforms are being dealt with via the monthly milestones.
I'm sure you are aware there is little more frustrating to a developer than the cycle: 2 minute working quick start all looks amazing > follow instructions carefully on learning more > doesn't work, so multiple hours head-bashing > finally get correct info on 10 second fix and find problem is due to undocumented change in the code base
My suggestion would be to start deployment documentation with the simplest (ping) starter with the assumption that developer has no working knowledge of IBM Cloud/cloud foundry/bluemix whatsoever (I'm coming from Google coud so I don't struggle with the concepts of PaaS, just IBMs silly names for the same things), so that the basics of setting up and deploying to a free tier can be understood and verified before moving to more complex examples. (Adding a cloudant database both remotely & locally for the todo example within the 'deployment' how to introduces other potential problems in the code / environment and has nothing to do with learning about deployment.)
The deployment how to should also follow the same login / CLI tool installations and commands as the node.js SDK starter app on CF (ie using the bx
commands) .
I have seen that the ability to use a local explorer is now live and partially documented: with the redirected version I get a probable CORS error from the cloud foundry app (and in my 'local' google cloud shell environment where I have no control over CORS). I would be helpful to know whether I need to get involved with the 'api' section of the cloud foundry console: 'expose manged api' etc. to manage CORS for the cf app and/or how this is relevant to loopback app running on cf and how to deal with this issue.
I will attempt to turn these comments into more granular / useful contributions to existing specific issues when I have some time [update - see comments below], so apologies this is a bit of an unstructured record of my experience / rant, and many thanks for all the excellent work on this exciting project and the help getting over this little hurdle.
So, tldr;
$ node -v
v?.?.?
$ npm --v
?.?.?
npm i -g @loopback/cli
lb4 app
or download examplecd [myApp]
npm i cfenv [?? --save]
- install cloud foundry environment module (? save to package.json)npm run build
before starting locally or deploying and presumably has a better solution based on environment variables and/or adding/modifying build scripts)cfenv
and add lines to src/index.ts
to get host & port using cfenv.getAppEnv()
// Modified src/index.ts (Generated Starter Application) for deployment to IBM Cloud Foundry
// Use cfenv.getAppEnv() to get port & host environment variables
import {StarterApplication} from './application';
import {ApplicationConfig} from '@loopback/core';
const cfenv = require('cfenv');
const appEnv = cfenv.getAppEnv();
export {StarterApplication};
export async function main(options: ApplicationConfig = {}) {
// Set the port and host assigned for the app
if (!options) options = {};
if (!options.rest) options.rest = {};
options.rest.port = appEnv.isLocal ? options.rest.port : appEnv.port;
options.rest.host = appEnv.isLocal ? options.rest.host : appEnv.host;
const app = new StarterApplication(options);
await app.boot();
await app.start();
const url = app.restServer.url;
console.log(`Server is running at ${url}`);
console.log(`Try ${url}/ping`);
return app;
}
curl -sL https://ibm.biz/idt-installer | bash
)manifest.yml
(perhaps not necessary)I have just written this as an aide-memoir so will work through and check that it works :) & comment back...
Could a 'Deploy to IBM cloud?' option be added to the generator to automatically install the 2 necessary dependencies and generate a modified src/index.ts to include the cfenv variables? (and going forward run the bx
commands to login & deploy to the correct endpoint)
Related open issues:
As above, I think it is confusing to introduce data persistence within the deployment tutorial - why do I want to start messing with docker when I'm trying to see if I can get a simple ping from the cloud? (more below)...
In any event adding hosted cloudant URL to the cloudant datasource connector and using the same database for local and cloud versions for the time being is a lot simpler to describe and understand as a temporary development step (no need to even add the cloudant service to the app in the console - the benefits of doing so can be explained later), and avoids having to use the docker environment which has other complications: e.g. using Google Cloud Shell I can get a cloudant in docker set up running on port 9000 at the same time as my app is running on 3000, but cannot connect to it from the app because the GCShell preview context it's running in is tied to my google account, so the request for the db url just gets back the Google accounts auth page (and I'm unaware if this can be overcome by adding a bearer token to the header in the controller code for example). OK, I worked out my own workaround using the hosted database only (no separate cloudant-in-docker) but having to deal with additional issues like this when following 'quickstart' tutorials at a tender stage of learning is somewhat frustrating and off-putting.
@cloudwheels, thanks for your feedback and the feature proposal! I agree that the how-to guide should contain more detailed information (perhaps with screenshots especially for the IBM Cloud side). We've investigated there are additional steps required if the LoopBack application is using other IBM Cloud service for persistence, so think that it would be useful to include it as well.
Based on your feedback, I'd like to propose the following to move things forward:
options.rest.host
line as mentioned in my previous comment so that users can deploy by following the instructionThoughts?
@dhmlau - thank for the swift reply :)
I confirm I now have todo running on the IBM cloud by making these changes (but no docker database or connected services, just a connection string from the cloudant connector shared by both environments - simples! - I was guided in this by I think the docs for the github sample (which didn't build for me btw and is probs a bit outdated also)).
With some minor level of familiarity now I was able to just update the manifest to upload the todo example over the ping starter: ibmcloud cf create-app-manifest lb4-starter-app -p manifest.yml
Your plan sounds good.
Absolutely - step by step breakdowns where poss - get a ping (starter + deployment), add a simple controller (hello), add more complex (todo)/related (todoList) models & controllers, get external api stuff (github stargazer), persist data in memory, persist to single hosted cloudant, setup cloudant dev in docker, add authentication etc. etc. User can always jump to the most complex example and run that first if they want or are returning / progressing their experience: each should work as a unit.
Then, yes, see it all working all ultimately as one pagers / clickers for the best ux. (ref. google cloud where for many examples a button click in the product overview will pull code into the console from git, build & deployed for you, apis enabled etc with a bit of entering your email address.)
I would say trying to align / integrate it to the current process on the IBM (Bluemix / whatever) console for creating a node.js sdk app, with the prefilled copy-pasta commands, with 'setup as a loopback app' being an option from here to provide relevant instructions from a single point that the user has to go to in order to set up the node app anyway (no duplication of documentation) [does that make sense].
Please also go with one CLI tool for this across all example documentation if that is workable (seems to be) i.e. the one currently referred to in these node.js docs, and clarify which commands of bluemix
,bx
,cf
,ibmcloud
etc. are relevant and how used.
Hope that helps! Look forward to following progress :)
ie.
@dhmlau - I have added this suggestion to my #2038
@cloudwheels, since it's similar to the other issue you created https://github.com/strongloop/loopback-next/issues/2072, I'd like to close this issue and continue the discussion over there. Thanks.
Description / Steps to reproduce / Feature proposal
cf
(as per deployment docks),ibmcloud cf
bx
(as per the cloud foundry node.js documentation after setting up an app. There are very few examples of this process around and those that exist seem to be conflicting, although they all seem to achieve the same results. Depending on which you choose and what prompts you receive, it can take some time to work out exactly what the required 'endpoint', 'org' and 'space' parameters for logging in and settings app endpoints. This is not covered at all in the deployment documentation.bx
and specifying app name seemed to negate the need for this.Current Behavior
The app seems to build, start successfully and then crash, most lately / consistently with exit code 137 (which may possibly indicate memory problems with the cf container?). The app's routes are not available in the cloud. Extract of log, my package.json & node version below.
Please help - this has been driving me mental for 24hours, I've had plenty of stabs at different approaches but it just doesn't seem to work. I must be missing something really obvious but I have the fear that this version is all a bit bleeding edge right now and things seems to be in a state of flux with the IBM CLI tools!