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

[tuananh]

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.

[lukeed]

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!

[tuananh]

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

[tuananh]

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

[lukeed]

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!

[tuananh]

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.

[lukeed]

Yeah, understood 😃

I'll have time to look at this weekend!

[lukeed]

Hey @tuananh,

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

1. 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.

2. 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'];

[tuananh]

lemme give those a try later today

[lukeed]

Sounds good, thank you 👏

[tuananh]

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

[lukeed]

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?

[tuananh]

@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

[lukeed]

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 😅