CODEWITHSUNDEEP
godocker
Madhav Jha
Madhav Jha

Reputation: 903

Docker publish not working correctly for golang application

I am trying to run a golang web server application (which tries to run a go blog powered by same tools which power golang blog) via docker. It runs fine without docker but fails to give any response if I use docker. I have no clue why this is happening as for a much simpler go web application, the same docker based approach works great. See below for output of various commands I used. Any help would be greatly appreciated.

docker pull maddyonline/gotutorial
docker run -d --publish 8080:8080 --name gotut maddyonline/gotutorial

81bc36e385286326a6d9f74322515a7b9748e493275c3426bcc6848a4589a7e7

docker ps

CONTAINER ID IMAGE COMMAND
CREATED STATUS PORTS NAMES 81bc36e38528 maddyonline/gotutorial "go-wrapper run" 20 seconds ago Up 20 seconds 0.0.0.0:8080->8080/tcp gotut

curl localhost:8080

curl: (52) Empty reply from server

docker exec gotut curl localhost:8080

<!DOCTYPE html>
<html>
<head>

And rest of the file

The docker file I am using is very simple.

FROM golang:onbuild
EXPOSE 8080

I experimented with the same docker file with a much simpler golang application on the same server. And it works.

docker pull maddyonline/gowebapp
docker run -d --publish 8080:8080 --name gowebapp maddyonline/gowebapp
curl localhost:8080/icecream

Hi there, I think I love icecream!

Upvotes: 5

Views: 2340

Answers (1)

Jonathan
Jonathan

Reputation: 5547

I found two issues with your current code.

The first is that the string localhost in your main.go needs to be 0.0.0.0. The problem is that you've told your webserver to only serve requests sent to localhost. Because of the network mangling that Docker does, none of the traffic showing up to your webserver look to the webserver as though they were sent to localhost. By telling your webserver to listen on 0.0.0.0 you're effectively telling it that it doesn't care where the traffic was originally sent and it will accept it all.

var (
    httpFlag   = flag.String("http", "0.0.0.0:8080", "HTTP listen address") // <--- Here it the change. It's roughly line 25 of [main.go](https://github.com/maddyonline/gotutorial/blob/master/main.go#L25)
    originFlag = flag.String("origin", "", "web socket origin for Go Playground (e.g. localhost)")
    baseFlag   = flag.String("base", "", "base path for articles and resources")
)

The second issue has to due with your import paths colliding with the predetermined directory structure of the onbuild Dockerfile from which you were extending. I saw that you were trying to hardcode the import path, which is not a good idea, but I think it was your only option due to the weirdness of the go-wrapper that was being forced onto you by the onbuild Dockerfile. Ultimately you should just have the docker build process stick a static Go binary in that container. That will simplify the process of actually starting up the server in the container.

I didn't mess with your paths in your Go code, I figured you could work that out, but I did grab the upstream onbuild Dockerfile and customize it to what you need. BTW, if you look at the documentation for the onbuild Dockerfile it actually says that it's a bad idea to use that Dockerfile. ;) So, I took their advice and here is my port:

FROM golang:1.4.2

RUN mkdir -p /go/src/github.com/maddyonline/gotutorial
WORKDIR      /go/src/github.com/maddyonline/gotutorial

ADD . /go/src/github.com/maddyonline/gotutorial
RUN go-wrapper download
RUN go-wrapper install

EXPOSE 8080
CMD ["go-wrapper", "run"]

Your other sample server app didn't have the same issues because the import paths weren't specified in the same way they are in this project. Basically, it didn't care where it was living because its dependencies were not being hardcoded to a file path. It is using the normal Go packaging conventions.

Sorry, it probably seems like a lot of change, but I hope it at least helps you move forward on your project. Let me know if anything doesn't make sense.

Upvotes: 5

Related Questions