In my Gruntfile.js I have tried to do this:
connect: {
options: {
port: process.env.PORT,
hostname: process.env.IP,
livereload: 35729
}
}
I tried to run from Cloud 9 terminal and I get the following:
Running "serve" task
Running "concurrent:server" (concurrent) task
Running "connect:livereload" (connect) task Fatal error: Port 8080 is
already in use by another process.
Then I have changed my Gruntfile.js to the following:
connect: {
options: {
port: 9000,
hostname: process.env.IP,
livereload: 35729
}
}
From the terminal I get:
Running "serve" task
Running "concurrent:server" (concurrent) task
Running "connect:livereload" (connect) task Started connect web server
on http://0.0.0.0:9000
Running "watch" task Waiting...
But how do I access http://0.0.0.0:9000 from Cloud 9?
I have tried http://localhost:9000, http://127.0.0.1:9000, am I missing something here?
Apparently, you can actually get Livereload working on Cloud9 when using Apache as web-server, by proxying the websocket request to grunt-watch with "mod_proxy_wstunnel":
1) Add the following directive to /etc/apache2/mods-available/proxy_wstunnel.load
ProxyPass /livereload/ ws://127.0.0.1:35729/
2) Enable "mod_proxy_wstunnel" and it's dependency "mod_proxy"
ln -s /etc/apache2/mods-available/proxy_wstunnel.load /etc/apache2/mods-enabled/proxy_wstunnel.load
ln -s /etc/apache2/mods-available/proxy.load /etc/apache2/mods-enabled/proxy.load
3) Restart Apache
service apache2 restart
4) So far so good, now you must hardcode the websocket URL that Livereload will be using, by modifying the livereload.js script, in my particular case this was located at ~/myworkplace/grunt-contrib-watch/node_modules/tiny-lr/lib/public/livereload.js, you need to change the following line:
this._uri = "ws://" + this.options.host + ":" + this.options.port + "/livereload/";
to
this._uri = "ws://YOUR_WORK_PLACE.c9.io/livereload/";
5) Last but not least, you must reference the livereload.js script directly in your desired page, in my particular instance:
<script src="/ng-boilerplate/node_modules/grunt-contrib-watch/node_modules/tiny-lr/lib/public/livereload.js"></script>
Hope this might help someone and especially save some time :)
Update: On Cloud9, you can use ports 8080, 8081, and 8082 to make this work. For details and an example, you can look at Multiple Ports.
In Cloud9, port 8080 is the only externally accessible port, so please change 9000 to 8080.
The port is in use by another process, which should be stopped first. Use:
kill -9 $(lsof -i:8080 -t)
and restart grunt. That will work.
You can use any port, when it is used for local/loopback connections. From outside your workspace only one port is accessible (at this moment that is, C9 is considering multiple ports). I'm not too familiar with this livereload, sorry. It seems that grunt needs to spawn a browser as well? That will not run on C9.
But why would you not use the 'live preview' that Cloud9 provides?
Just open any html page, click Preview and select 'Live preview'.
All changes to css, html will be applied immediately in the preview frame.
Related
I'm trying to run a docker image, which is essentially the default ASP.Net 6 default API:
docker run my-image-name --restart=aways -d -p 80:5111
I've tried a few different ways of running this, but it appears to always do the same thing. First of all, whether I launch in detached mode or interactive, I get the following display:
{"EventId":14,"LogLevel":"Information","Category":"Microsoft.Hosting.Lifetime","Message":"Now listening on: http://[::]:80","State":{"Message":"Now listening on: http://[::]:80","address":"http://[::]:80","{OriginalFormat}":"Now listening on: {address}"}}
{"EventId":0,"LogLevel":"Information","Category":"Microsoft.Hosting.Lifetime","Message":"Application started. Press Ctrl\u002BC to shut down.","State":{"Message":"Application started. Press Ctrl\u002BC to shut down.","{OriginalFormat}":"Application started. Press Ctrl\u002BC to shut down."}}
{"EventId":0,"LogLevel":"Information","Category":"Microsoft.Hosting.Lifetime","Message":"Hosting environment: Production","State":{"Message":"Hosting environment: Production","envName":"Production","{OriginalFormat}":"Hosting environment: {envName}"}}
{"EventId":0,"LogLevel":"Information","Category":"Microsoft.Hosting.Lifetime","Message":"Content root path: /app","State":{"Message":"Content root path: /app","contentRoot":"/app","{OriginalFormat}":"Content root path: {contentRoot}"}}
It then seems to stall - I can't ctrl-c, nor can I attach to the process (it does show under docker ps). I also can't connect to the API:
http://localhost:5111/swagger
Just returns ERR_CONNECTION_REFUSED
My guess here is that there's something wrong with the dockerfile itself - however, it builds fine. The question I have is: how can I debug this in order to determine the error?
I can't add this as a comment because i don't have the reputation so it will have to be an answer instead.
I am new to Docker myself so I am not sure why it is stalling but when you specify the port with -p 80:5111 you are mapping port 5111 in the container to port 80 on the Docker host.
So you should connect with http://localhost:80/swagger instead.
I am trying to run this docker file https://gitlab.com/snippets/1713665
consoles
I have running iroha container as you can see in right console on 50051 port, but on running the above docker file for web GRPC then you can see in left console it is unable to make connection. as i have also tried with enabling and disabling the firewalls and also with opening the 50051 withudo ufw allow 50051 sudo ufw allow 50051 ...But in the end i have the same results
"Err: connection error: desc = "transport: Error while dialing dial tcp 127.0.0.1:50051: connect: connection refused". Reconnecting... system=system"
I have also posted this issue month ago but no once gave me any response, Thats why i am reposting with further elaboration
Try running the grpc web proxy, with the backend address as localhost, instead of whatever is default in the gitlab post.
ex. ./grpcwebproxy-v0.13.0-osx-x86_64 --backend_addr=localhost:50051 --run_tls_server=false
From the console logs, it looks like it is trying to connect to dev.localdomain:50051
There are various one-liner HTTP server commands, e.g. the best-known is probably python -m http.server. I'm looking for a similar command which would run a server that ignores the file path and send all paths to a specific file, e.g. if you visit /foo or /bar, it will serve both from index.html.
And ideally relying on as little installation hassle as possible for a typical Linux/MacOS machine. (e.g. python and http.server will come out of the box to many users.)
It's the same functionality offered by the htaccess rule RewriteRule (.*) /index.html, but without needing to setup Apache. Not sure if any of those one-liner servers support something similar to it, like a command-line argument that would declare the default file for all paths.
Using php, there is a built in development server from the command line, which is super useful.
First example, in the current folder, serving only the file index.html at 127.0.0.1, port 8080:
php -S 127.0.0.1:8080 index.html
Output
PHP 7.2.24-0ubuntu0.18.04.1 Development Server started at Mon Dec 23 15:37:03 2019
Listening on http://127.0.0.1:8080
Document root is /home/nvrm
Press Ctrl-C to quit.
On this case, only the file index.html will respond at http://127.0.0.1:8080
Any http calls on this port, will be redirected to index.html.
Second example binding the whole current folder to localhost, port 5555:
php -S localhost:5555
Output:
PHP 7.2.24-0ubuntu0.18.04.1 Development Server started at Mon Dec 23 09:59:44 2019
Listening on http://localhost:5555
Document root is /home/nvrm
Press Ctrl-C to quit.
This will serve index.html at the adresss http://localhost:5555
If a file index.php exist, then it will be served first (interpreted as php)
All others files in the (sub)folder(s) are served, example http://localhost:5555/css/style.css will respond as well, if this folder and file exist of course. (Otherwise respond error 404)
Third example, to run from anywhere, pass in a path as third param. Using a local ip is also possible, by doing so, the files are available on the whole local network.
Example local ip: 192.168.1.23.
To retrieve our local ip, we can use ifconfig.
php -S 192.168.1.23:8080 ~/www
This will serve the folder www in the home folder on the port 8080: http://192.168.1.23:8080 to everyone on the network.
Obviously, we can run many servers on many different ports in parallel^
Very useful to dev, but also to quickly share files between virtual machines, devices, phones etc.
Alternatively. Listen to all interfaces by using 0.0.0.0 as ip adress. In some cases, this is the sole command that serve well across every devices in the local network.
php -S 0.0.0.0:5555
And then use the local ip as url: http://192.168.1.23:5555
To be able to close the terminal, but to keep the server running, we can use nohup:
nohup php -S localhost:8080 &
Then to kill it, quickly:
fuser -k 8080/tcp
Last example, using a hostname.
To retrieve the machine hostname from the console, the unix command is hostname.
php -S $(hostname):9999
Will bind to something like http://<session_name>-<machine_name>:9999
It is possible to install only the cli version of php to run this (~4mo). It's included in the core.
sudo apt install php-cli
For more advanced server usages, yet simple to configure, warmly, I recommend caddy server
https://github.com/svenstaro/miniserve
to serve only index.html you just do miniserve index.html. It's written in Rust so you don't need any additional dependencies.
#!/usr/bin/env node
const express = require('express');
const server = express();
server.all('/*', (_, res) => {
// You would probably not want to hard-code this,
// but make it a command line argument.
res.sendFile(__dirname + '/index.html');
});
const port = 8000;
server.listen(port, () => {
console.log('Server listening on port', port);
});
Make the file executable (chmod +x) and save it somewhere within your PATH.
I don't quite get the difference between the two. From the description, seems like both are for opening webserver.
If i used the grunt-serve plugin with the following configurations on my gruntfile.js
serve: {
options: {
port: 9000
}
}
I can open a webserver at the specified port, though i have to open the webserver manually at the browser (not sure how to make it open automatically on my default browser). The webserver is working fine, and can load JSON files without any problem.
However when i tried to do it with grunt connect plugin, with the following configurations
connect: {
server: {
options: {
port: 9000,
livereload: 35729,
hostname: 'localhost',
keepalive:true,
open:true
}
}
},
open: {
dev: {
url: 'http://localhost:<%= connect.server.options.port %>/index.html'
}
}
grunt.registerTask('serve', function (target) {
grunt.task.run([
'connect',
'open:dev'
]);
});
I could automatically opened a webserver at the specified port on my default browser, but the catch is, it couldn't load the JSON data like how grunt serve did.
I'd like to make the webserver works like Yeoman, where when running the command grunt serve, it would connect to the webserver and automatically open it on my default browser, and can load all my PHP/json files. Seems like grunt-serve plugin is the right plugin for this, but i'm sure grunt-connect can do the same thing as grunt-serve too.
according to https://github.com/gruntjs/grunt-contrib-connect the connect task makes the server available for a limited amount of time in order to run other tasks such as unit testing. Once the tasks are complete the server stops. As you have shown there is a keepalive option to prevent the server from stopping. Connect is also useful for connecting to resources on another domain such as a REST API. Typically this would be denied by the browser due to the same origin policy - see https://github.com/drewzboto/grunt-connect-proxy.
So for development I would use the standard pattern "grunt serve" and connect for testing and proxying to resources on another domain :-)
When I use grunt-contrib-connect in the Gruntfile.js for my HTML files, and the task is called, the browser launches and connects with LiveReload without issue.
I am now trying to do the same with PHP files so I am using grunt-php. The author states that grunt-php is "pretty much a drop-in replacement for grunt-contrib-connect".
I have copied the options for grunt-contrib-connect to the grunt-php task, and added keepalive and open, but the browser does not get launched and no connection is made. The terminal however shows:
Running "php:livereload" (php) task
PHP 5.4.17 Development Server started at Mon Nov 11 15:56:04 2013
Listening on http://localhost:9000
Document root is /Users/fisu/Sites/generator-site-playground/dev
My task looks like:
php: {
options: {
keepalive: true,
open: true,
port: 9000,
livereload: 35729,
hostname: 'localhost',
base: 'dev'
},
livereload: {
options: {
open: 'http://localhost:9000',
base: 'dev'
}
}
}
I have tried different hostnames, but still the browser will not launch and connect. Am I missing an option?
It's not just you. The problem seems to be with this method: https://github.com/sindresorhus/grunt-php/blob/master/tasks/php.js#L51-L59 - open() never seems to get called because it's waiting for a HTTP 200 which it won't get unless a browser hits the server and requests something. At least that seems to be the case on my machine, I don't know how well tested that method is or anything. A temporary fix could be to move that call out of that method; go into the node_modules/grunt-php/tasks/ directory and edit the file like so:
(l49) // check when the server is ready. tried doing it by listening
// to the child process `data` event, but it's not triggered...
checkServer('http://' + host, function () {
if (!this.flags.keepalive && !options.keepalive) {
cb();
}
}.bind(this));
// open the browser straight away
if (options.open) {
open('http://' + host);
}
I've also filed an issue. https://github.com/sindresorhus/grunt-php/issues/14