I have been struggling to do the tutorial, https://www.windowsazure.com/en-us/develop/nodejs/tutorials/web-app-with-mongodb/, which basically makes a simple node.js application that has access to a Mongo DB. I keep running into the following issue when launching the program locally with the command Start-AzureEmulator:
"No connection could be made because the target machine actively refused it 127.0.0.1:27017"
I tried various ports and configurations with no success. Oddly enough, when I run mongodb.exe, the database launches without hiccup (this is just through the command line not within the Azure Emulator). I have also tried reinstalling all of the tools multiple times. It seems I am at a loss of what to do next.
Have any of you experienced this problem or have been able to complete this tutorial?
As a side note, do any of you know any cloud providers that allow the use of sockets with node.js? This is one of the main reasons I am trying to use Azure.
I assume you've followed the instructions step by step and haven't modified anything yet?
I note from the screenshot below, that the sample tries to open Mongo at 127.255.0.1:27017, not 127.0.0.1:27017:
I suggest checking your Azure services' URL's in case you're looking for Mongo on the wrong address.
Related
I am very new to development, so I apologize in advance if I am not being clear enough. I appreciate any feedback on the question and how to better pose it.
I'm currently working on an angular app hosted in WSL2. To get it to run locally, this is what I do:
Launch solution in VS Code
From terminal, run npm start
Then, I click on Run and Debug
Once I get the Now listening on: ..... message, I move on to Chrome to start debugging my app
Since this morning, I keep getting a ERR_CONNECTION_REFUSED in the browser, and I'm currently waiting on IT to step in as there could have been some security changes placed that are blocking the requests. Also, I'm not using the VPN.
In the meantime, is there a way to know for sure (or get as close as possible to) what is causing the connection to be refused in my particular scenario? I'm curious about it, but I don't know how to even search the topic properly due to lack of proper terms.
What should one do to at least obtain more details about the issue on their own (perhaps, to help expedite help by collecting important info upfront)? Where my apps are hosted in WSL2, I get very confused between the ip address originating the request and that of the server.
I appreciate any guidance anyone could provide.
It turned out there was a VPN software running where the firewall was ON, even though I was not in the VPN (it went on after I connected to the VPN the previous day). I guess there was nothing else I could have done anyway.
Feels like I've searched the entire web for an answer...to no avail. I have a puppeteer script that works perfectly locally. My local machine is a little unreliable, so I've been trying to push this script to the cloud so that it can run there. But I have no idea where to start. I'm sitting here with an IBM cloud account with no idea what to do. Can anyone help me out?
Running Puppeteer scripts can be done on any cloud platform that
exposes a Node.js environment
enables running a browser (Puppeteer will need to start Chromium)
This could be achieved, for example, using AWS EC2.
AWS Lambda, Google Cloud Functions and IBM Cloud Functions (and similar services) might also work but they might need additional work on your side to get the browser running.
For a step-by-step guide, I would suggest checking out this article and this follow-up.
Also, it might just be easier to look into services like Checkly (disclaimer: I work for Checkly), Browserless and similar (a quick search for something along the lines of "run puppeteer online" will return several of those), which allow you to run Puppeteer checks online without requiring any additional setup. Useful if you are serious about using Puppeteer for testing or synthetic monitoring in the long run.
I'm moving my Three.js app and its customized node.js environment, which I've been running on my local machine to Google Cloud. I want to test things out there, and hopefully soon get some early alpha testing going with other people.
I'm not sure which is the wiser way to go... to upload the repo I've been running locally as-is onto a VM which users would then access via the VM's external IP until I get a good name to call this app... or merge my local node.js environment with what's available via the Google App Engine and run it on GAE.
Issues I'm running into with the linux VM approach... I'm not sure how to do the equivalent on the VM of what I've been doing locally. In Windows Powershell I cd into the app directory and then enter node index.js. I'm assuming by this method of deployment that I can get the app running as soon as the browser hits the external IP. I should mention too that the app will allow users to save content as well as upload images, and eventually, 3D models as well as json datasets.
Issues I'm running into with the App Engine approach: it looks like I only have access to a linux-based command line, and have to install all the node.js modules manually. Meanwhile I have a bunch of files to upload, both the server-side node files and all the frontend stuff. I don't see where to upload those files, and ultimately what I'd like to do is have access to a visual, editable file-tree interface, as I have in Windows and FileZilla, so I can swap files in and out, etc. Alternatively I suppose I could import a repo from Github? Github would be fine as long as I can visually see what's happening. Is there a visual interface for file structure available in GAE somewhere? Am I missing something?
I went through the GAE "Hello World" tutorial and that worked fine, but was left scratching my head afterward regarding how to actually see and edit the guts of the tutorial app, or even where to look for the files.
So first off, I want to determine what's the better approach, and then if possible, determine how to make the experience of getting my app up there and running a more visual, user-friendly experience.
Thanks.
There are many things to consider when choosing how to run an app, but my instinct for your use case is to simply use a VM on GCE. The most compelling reason for this is that it's the most similar thing to what you have now. You can SSH into the machine and run nohup node index.js & (or node index.js inside tmux/screen if you prefer) and it will start the app and not stop it when you log out of SSH. You can use SCP / SFTP with whatever GUI client you want to upload files. You don't have to learn anything new! If you wanted to, you could even use a Windows VM (although I think you have to pay a little more than for a comparable Linux VM due to the licensing fees).
That said, the other way is arguably more "correct" by modern development standards, but it will involve a lot more learning that will prevent you from getting your app running somewhere other than your laptop in the short term:
First, you'll need to learn about Docker and stateless containers, which is basically what your app runs inside of on AppEngine.
Next, you'll need to learn how to hook up a separate stateful service (database, file server, ...) to your app's container so you can store your files, etc. in it, and then probably rewrite your app somewhat to use it to store stuff.
Next, you'll probably want some way to automatically deploy this from code instead of manually doing it, which gets you into build systems, package managers, artifact storage, continuous integration systems, and on and on and on.
This latter path is certainly what you should choose for a long-running production service if you work with a big team of developers -- but that doesn't mean that it's necessarily the right path for your project today. If you don't care about scaling up automatically, load balancing between nodes, redundant copies of your app running in different regions in case there's a natural disaster, etc., then go with the easy way for now, and you can learn new ways to improve the service when they're actually needed.
Here is the problem: We have a client that uses Progress Openedge database, we need to execute queries on this database from our servers.
Currently the drivers are installed on our Windows server, and the PHP code uses ODBC to run the queries.
Now we would like to move the code to a Linux server. We tried before to work with their linux drivers but that attempt has failed.
The question is, Is it possible somehow to run PHP code on a linux server, this code communicates with the Windows server, runs the query on the Windows server, and return the results to Linux?
How would you access to this problem.
Thanks!
Yes, it's possible. Your question boils down to "how can my Linux server ask my Windows server to do something" (where the "something" happens to be "talk to a database"), and there are a variety of ways to accomplish that. You could run a web service (RESTful or SOAP) on the Windows server, for example.
Make sure you think about security: if you deploy a service on your Windows server that lets remote clients modify a database, you have to be mindful of which remote clients are allowed to use that service. The last thing you want to do is accidentally allow random strangers to run arbitrary queries against your database.
We have a Knowledgebase Article detailing some setup procedures for Linux installations; it also has a video explaining some aspects of the setup. If the other answered haven't provided a complete solution for you, hopefully our article can at least get you started in the right direction.
Also keep in mind that depending on your version of OE, the driver libraries may be different.
I've just installed Neo4j 1.8.2 onto Azure by following this step-by-step process...
http://de.slideshare.net/neo4j/neo4j-on-azure-step-by-step-22598695
Unfortunately, when I browse to http://:7474/webadmin Fiddler says Error 10061 - No connection could be made because the target machine actively refused it.
I've followed the instructions exactly and haven't received any errors.
Any help much appreciated.
So, I think I got to the bottom of this. I think it was due to the size of compute / VM I was creating. It looks like the problem is caused when running on Extra Small instances. I created a new installation using a Small instance and everything now works :).
Try setting the server to accept connections form all hosts, and maybe use a newer Neo4j, say 1.9.4
http://docs.neo4j.org/chunked/stable/security-server.html#_secure_the_port_and_remote_client_connection_accepts
The way the VM Depot image is set up, it's pre-configured to allow all hosts to connect, and the Neo4j server will auto-start. The only thing you need to take care of, when constructing your VM, is to open an Input Endpoint, with any public port you want (preferably 7474 to stay true to Neo4j) and internal port 7474.
Note that the UI changed a bit since the how-to was published: You can specify the endpoint as the last step before creating your virtual machine. Other than that, the instructions should be the same. And... once the VM is up and running (it'll take about 5-10 minutes), you just visit http://yourservicename.cloudapp.net:7474 and you should see the web admin. Note: this is not the same as your vm name. If you named your VM something like 'neo' then you do not want http://neo:7474 or http://neo.cloudapp.net:7474. You need to use your cloud service name (you had to create a name for the service when you deployed the VM.
I've deployed that image several times in demos, and just tried again right now to make sure nothing wonky happened. Worked perfectly.