export fails in container, connecting to different port than the start port

Question

export fails in container, connecting to different port than the start port

tuananh opened this issue 6 years ago · comments

I'm not sure why the server started on port 36573 but somehow, it's connecting to 33435

I'm having this issue in container though, not on my local machine.

[PWA] Started local server on http://localhost:36573
(node:6) UnhandledPromiseRejectionWarning: Error: connect ECONNREFUSED 127.0.0.1:33435
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1161:14)
(node:6) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:6) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled willterminate the Node.js process with a non-zero exit code.

Luke Edwards · Answer 1 · Fri Sep 14 2018 01:25:18 GMT+0800 (China Standard Time)

Hey,

Can you provide any more info on this to replicate? Is it within a Docker? Did you look and see which port was actually used?

Thanks!

Tuan Anh Tran · Answer 2 · Fri Sep 14 2018 07:19:30 GMT+0800 (China Standard Time)

Yes, it's within Docker container. download-chrome.sh script is from chrome-launcher repo

The port looks random to me and it's different every build

FROM bitnami/node:10 as builder

ENV CHROME_PATH /myapp/chrome-linux/chrome

WORKDIR /myapp

# setup chrome headless so that we can run export
COPY scripts/download-chrome.sh /myapp
RUN ./download-chrome.sh

RUN npm i @pwa/cli --global

COPY package.json /myapp
RUN npm install --unsafe
COPY . /myapp
RUN pwa export

FROM nginx:1.15-alpine
COPY --from=builder /myapp/build /usr/share/nginx/html/
EXPOSE 80

Tuan Anh Tran · Answer 3 · Fri Sep 14 2018 11:19:33 GMT+0800 (China Standard Time)

this line launch({ chromeFlags }).then(proc => { seems to be failing but when i catch it, i got nothing. so i don't know what's the actual error is

Luke Edwards · Answer 4 · Sat Sep 15 2018 01:39:07 GMT+0800 (China Standard Time)

I will have to look into it over the weekend :) Off the top of my head, am not sure. If it's possible, I would export the application locally and then have Docker start by copying over the built assets.

Thanks!

Tuan Anh Tran · Answer 5 · Sat Sep 15 2018 06:49:44 GMT+0800 (China Standard Time)

Docker start by copying over the built assets.
That would work if i were to deploy from my local machine. however, i want to use ci/cd pipeline to build the docker images instead of doing it locally.

Luke Edwards · Answer 6 · Sat Sep 15 2018 07:02:34 GMT+0800 (China Standard Time)

Yeah, understood 😃

I'll have time to look at this weekend!

Luke Edwards · Answer 7 · Sun Sep 16 2018 03:45:16 GMT+0800 (China Standard Time)

Hey @tuananh,

Was swamped at the time, so coming back with more information:

Yes, the port that chrome-launcher uses is always random, as is the localhost server that PWA uses. They're throwaways and aren't meant to be user-interactive, so they both use whatever port Node deems available.
The chrome-launcher port is always different from the localhost port (displayed) because CL is a separate process/server that PWA communicates with to programmatically scrape the pages. The address that PWA prints in your console is the HTTP file server (via sirv).

So, this is a chrome-launcher issue running in Docker. I'm not that great with Docker, but I feel like there's an answer somewhere in this Dockerfile.

A quick thing you can try for me:

Does it work if you change this line to this?

let chromeFlags = ['--headless', '--disable-gpu', '--no-sandbox'];

Tuan Anh Tran · Answer 8 · Mon Sep 17 2018 12:09:18 GMT+0800 (China Standard Time)

lemme give those a try later today

Luke Edwards · Answer 9 · Mon Sep 17 2018 12:16:14 GMT+0800 (China Standard Time)

Sounds good, thank you 👏

Tuan Anh Tran · Answer 10 · Mon Sep 17 2018 15:02:04 GMT+0800 (China Standard Time)

@lukeed yes, the '--no-sandbox' works for me. 🎇

Luke Edwards · Answer 11 · Mon Sep 17 2018 15:16:16 GMT+0800 (China Standard Time)

Awesome!

Then that confirms another finding: Learned that you can't run headless Chrome without correct user permissions.

Search for "How do I create a Docker container that runs Headless Chrome?" in this article.

Here's the portion of a Docker file Google links to in order to set up the user properly: https://github.com/ebidel/lighthouse-ci/blob/master/builder/Dockerfile#L35-L40

I'm tempted just to add --no-sandbox to the base flags but I'm reading that it's a really bad idea, which is what I figured... 🤔 Maybe it's not so bad since it's a 2 second instance?

Tuan Anh Tran · Answer 12 · Mon Sep 17 2018 15:56:41 GMT+0800 (China Standard Time)

@lukeed i tried adding chrome user like this https://github.com/ebidel/lighthouse-ci/blob/master/builder/Dockerfile#L35-L40

but the old error persists still until I add '--no-sandbox' option.

Will take a look at this later.

Many thanks for your help

Luke Edwards · Answer 13 · Wed Sep 19 2018 04:03:52 GMT+0800 (China Standard Time)

The next release with have pwa export --insecure which adds the --no-sandbox flag automatically.

I think that as long as sandboxing isn't disabled by default, that should be fine 😅