Access Vue Application on Webpack-Server in Vagrant - node.js

I set up a virtual machine with Vagrant, ubuntu xenial64, installed npm/nodejs and the vue-cli.
I scaffolded a webpack application with vue init webpack myproject. When I now run npm run devthe webpack server starts, but since it's inside the virtual machine I can't access the webpage on my PC.
I found out, that you can run webpack server with --host 0.0.0.0 but since the Vue-Cli generates the whole process, I wasn't able to figure out where I can add this parameter.
Or is there another solution?

Ok fixed it myself :). Just add this to your Vagrantfile:
config.vm.network :forwarded_port, guest: 8080, host: 80
So nothing to do with Webpack, just basic vagrant setup. This will forward the 8080 port to 80 port of your host machine. So you need to type localhost:80 in your browser to get to your application.

Related

Create open 80 port for Storybook for React

Original port for my Storybook installation was port 8080 and 6006 see documentation enter link description here, and figured to change the JSON file to point to port 80
This is the package.json file part of my Storybook installation:
Now I've assigned a domain name since port 80 is hosted under the public ip, the problem is after a while that port closes and we can't see the Storybook because the port is closed again. How do I configure so that the port stays open? I'm using Jelastic as a web hosting environment: https://jelastic.com/
My current configuration is as followed:
Running a VPS with Ubuntu 18.04 installed
Other dependencies:
NPM
Yarn
NodeJS
Create React App : https://reactjs.org/docs/create-a-new-react-app.html
StoryBook for React : https://storybook.js.org/docs/react/get-started/introduction
Chromatic : https://www.chromatic.com/
Storybook's webserver is not meant to be exposed to the internet, it's only for local development. You can create a static build of your Storybook using yarn build-storybook and upload that to any hosting provider. However, since you're using Chromatic, you don't have to, because it gives you free hosting out of the box. See https://www.chromatic.com/docs/document#direct-access-to-your-storybook for details.

Node Debug From Vagrant

Unable to remote debug a node server running on a Vagrant box in Chrome from my host machine. The server is configured to run on port 8123.
Node Version: 7.10.0
In Vagrantfile:
config.vm.network :forwarded_port, host: 9229, guest: 9229
config.vm.network :forwarded_port, host: 8123, guest: 8123
From my vagrant box I run:
$ node --inspect index.js
Debugger listening on port 9229.
Warning: This is an experimental feature and could change at any time.
To start debugging, open the following URL in Chrome:
chrome-devtools://devtools/bundled/inspector.html?experiments=true&v8only=true&ws=127.0.0.1:9229/84085f07-dc42-4e1e-bdd8-532e6dc5c4c6
--- Customer Service---
Connecting to customer repository...
Connected. Starting server...
Server started successfully, running on port 8123.
When I try to access the url in Chrome from my host machine while I don't get an error the sources tab is empty.
Screenshot of devTools
Based on NodeJS 11591 issue. You can't access the Vagrant stuff via localhost (127.0.0.1), so you need to to specify host explicitly:
$ node --inspect=0.0.0.0:9229 index.js
Then you need to set up Target discovery settings in the Chrome. Note that 192.168.33.11 from my sample is the static IP address providing an access to the Vargant host from the local host:

Browsersync within Vagrant VM does not properly proxy

I'm having an issue where browser-sync is not properly proxying my apache2 server. I'm running browser-sync through gulp within an Ubuntu 14.04 VM with Ubuntu 15.04 on the host. I'm using the following configuration:
browserSync({
proxy: 'localhost:80',
port: '8081',
open: false
});
The guest machine's port 80 is mapped to 8080 on the host. The gulp task runs without issue and I get the expected output from browser-sync. If I visit localhost:8081/index.php, it works without any issue. If I try to visit localhost:8081/foo/index.php, however, my browser is redirecting to localhost:8080/foo/index.php, and browser-sync does not function.
If I set logLevel to debug, I see output when I visit localhost:8081/index.php:
[BS] Browser Connected: Chrome, version: 45.0.2454.85
There is no output, however, when I visit localhost:8081/foo/index.php
Is there a bug with browser-sync when used within a VM?

Simple example of Vagrantfile / Dockerfile to run node app

I'm having difficulty trying to get a simple node app running inside a docker container hosted using vagrant.
This page explains the basic approach: https://www.vagrantup.com/blog/feature-preview-vagrant-1-6-docker-dev-environments.html
What I am unable to do is access the node app from my machine - in theory I believe I should be able to see my "hello world" style node/express app at localhost:8181...
Below is what I have so far:
Vagrantfile:
Vagrant.configure("2") do |config|
config.vm.provider "docker" do |d|
d.build_dir = "."
d.ports = ["8080:5000"]
# Is this necessary if EXPOSE is used in Dockerfile?
d.expose = ["5000"]
d.remains_running = true
d.volumes = ["/shared"]
end
config.vm.network "forwarded_port", guest: 8080, host: 8181
config.vm.synced_folder "~/Documents/shared", "/shared"
end
Dockerfile:
# DOCKER-VERSION 0.8.0
FROM centos:6.4
RUN rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm
RUN yum install -y npm ImageMagick
ADD . /app
# Not necessary because node_modules are bundled
# RUN cd /app; npm install
EXPOSE 5000
CMD ["node", "/app/index.js"]
I've followed the documentation as closely as possible but just can't seem to achieve what I'm after. Any ideas?
Note: node app is working when running normally ie $ node index and accessed at localhost:5000
Thanks in advance
EDIT:
index.js:
var express = require('express'),
http = require('http');
var app = express();
var port = 5000;
app.get('/', function(req, res) {
res.send('Hello World');
});
var server = http.createServer(app);
server.on('listening', function() {
console.log('Express server listening on port ' + port);
});
server.listen(port, '0.0.0.0');
setInterval(function(){
console.log('running');
}, 5000);
package.json:
{
"name": "vagrant-docker-node",
"version": "0.0.0",
"dependencies": {
"express": "^4.1.0"
},
"main": "index.js"
}
I actually ran into the same issue. Not sure if it's intended behavior or bug but setting forwarded_port in a Vagrantfile with a Docker provider does nothing on the host boot2docker machine.
Unless I'm missing something, you have to either provide your own host machine with another Vagrantfile opening the correct ports or modify the one provided by Vagrant.
Approach 1: Provide your own host machine (based on boot2docker)
Here's the base Vagrantfile for the boot2docker host: boot2docker Vagrantfile. You need to edit a copy of this Vagrantfile and set your forwarded ports here.
Then, in your Docker app Vagrantfile, modify as follow:
config.vm.provider "docker" do |d|
# Specify here the path to the updated host Vagrantfile
d.vagrant_vagrantfile = "../boot2docker/Vagrantfile"
... # edited out for clarity
end
Make sure you point to your updated host machine. Here I set it to an upper level shared directory because if you want to share this machine between multiple Docker apps with seperate Vagrantfiles, you'll have to point to the same host Vagrantfile (otherwise it'll try to spin up new host VMs).
Approach 2: Update Vagrant's host machine
You can also update the Vagrantfile automatically used by Vagrant which is located in %VAGRANT_HOME%/data/docker-host/Vagrantfile. Modify the file to open your ports.
Then do a vagrant global-status to get the ID of the host machine and vagrant reload machineId to restart the machine which will trigger the port re-open and update.
I'm not sure if there's a better or sanctionned way to do this but that's the only way I could have the ports forwarded all the way from Docker container to physical machine.
Shouldn't you forward the exposed port 5000 from Docker to your host, using Vagrant?
config.vm.network "forwarded_port", guest: 5000, host: 8181
(to get your app reachable on port 8181 from your host browser, for example)
Instead of:
config.vm.network "forwarded_port", guest: 8080, host: 8181
Flows/redirects summary:
Docker container Vagrant VM Your computer
:8080 => :5000 => :8181
What's your host OS (the one you execute the "vagrant" command on)? If it's non-Linux (e.g. OSX or Windows) then your Docker container will be riding on top of a Linux VM (usually TinyCore Linux inside VirtualBox), and the port forwarding will be done from inside that VirtualBox into the Docker container.
You should see evidence of port forwarding taking effect by looking for listening TCP sockets using "netstat -tlpn" (on Linux) or "netstat -an" (on OSX)

Debug meteorjs application with WebStorm7

I have WebStorm7 installed on a Windows7 machine.
If I run a meteor project in the Windows7 machine with:
>set NODE_OPTIONS=--debug=47977 & meteor
it prints:
=> Meteor server running on: http://localhost:3000/
=> debugger listening on port 47977
and I can debug with WebStorm7 using the_Node.js Remote debug_ configuration, with Host: 127.0.0.1 and Port: 47977.
If I run a meteor project in a Ubuntu machine (within a Oracle VM VirtualBox, with address 192.168.1.9) with:
$ NODE_OPTIONS="--debug=47977" meteor
it prints only:
=> Meteor server running on: http://localhost:3000/
and I cannot debug with WebStorm from the Windows7 machine using the Node.js Remote debug configuration, with Host: 192.168.1.9 and Port: 47977.
From the ubuntu machine a telnet 127.0.0.1 47977 does not work too. It looks like the debugger is not started at all. What am I doing wrong?
the issue might be related to the fact that node.js debugging is only listening on localhost, so you can't connect to the used port from remote host. The workaround is to use a proxy (see http://delog.wordpress.com/2011/04/08/a-simple-tcp-proxy-in-node-js/, for example)
This proxy can be used as follows:
$: node tcpproxy.js 8585 127.0.0.1 5858
8585 here is the 'exposed' port that webstorm will connect to (you can make this what you wish). You are directing traffic that is coming in on 8585 to 5858 (the local debugging port). Ensure 8585 is open on your firewall if you have one. You have to specify this 'exposed' port in your Remote Debug run configuration as a debug port

Resources