I have a simple site built using revel containerized in a docker image. I'm trying to run this image in Cloud Run. Unfortunately when I go to the URL for the site, I see a 502 in the browser and this log line
2020/10/30 17:27:07 http: proxy error: dial tcp 0.0.0.0:16166: connect: connection refused
I would assume it had something to do with the port, but I tried mapping the port originally to 9898 and I still saw a random port number in the log line. Currently I have the port in my revel application set to ${PORT} as recommended by the GCP documentation.
I should mention I can deploy the container locally with no issues.
Dockerfile:
FROM golang:1.15 AS build
ENV CGO_ENABLED 0
ADD . /go/src/app
# Install revel framework
RUN go get -u github.com/revel/revel
RUN go get -u github.com/revel/cmd/revel
# Run revel app
EXPOSE ${PORT}
ENTRYPOINT revel run -a /go/src/app -p ${PORT} -m dev
Revel app.conf snippet:
# The IP address on which to listen.
http.addr = 0.0.0.0
# The port on which to listen.
http.port = ${PORT}
UPDATE: It was suggested to use the hardcoded port of 8080 and see if that works. I still see the 502. I tried running it locally again and it looks like revel is trying to set up on one port and then listenining as a reverse proxy on another. So unless I'm thinking this may be a revel issue and not a Cloud Run issue
docker run --publish 8080:8080 app
Revel executing: run a Revel application
Changed detected, recompiling
Parsing packages, (may require download if not cached)... Completed
INFO 02:34:24 app run.go:34: Running revel server
INFO 02:34:24 app plugin.go:9: Go to /@tests to run the tests.
Revel engine is listening on.. 0.0.0.0:44795
Time to recompile 8.0340966s
Revel proxy is listening, point your browser to : 8080
Notice the last line Revel proxy is listening, point your browser to : 8080 but also Revel engine is listening on.. 0.0.0.0:44795
So after further investigation and discussion, it seems like when you run revel applications via revel run a proxy is set up on a random port and that connection was what was failing. Furthermore, the largest benefit of running via revel run is hot swapping of deployed code, which is unnecessary in a deployed context. So the solution here was to build the application via revel build and running that application that way so that only the application port is used for connections.