英文:
Docker publish not working correctly for golang application
问题
我正在尝试通过Docker运行一个golang web服务器应用程序（该应用程序尝试通过与golang blog相同的工具来运行一个go博客），在没有使用Docker的情况下它可以正常运行，但是如果我使用Docker，它就无法给出任何响应。我不知道为什么会发生这种情况，因为对于一个更简单的go web应用程序，相同的基于Docker的方法运行得很好。请参阅下面我使用的各种命令的输出。非常感谢任何帮助。
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>
以及文件的其余部分
我正在使用非常简单的Docker文件。
FROM golang:onbuild
EXPOSE 8080
我在同一台服务器上使用相同的Docker文件进行了一个更简单的golang应用程序的实验。它可以正常工作。
docker pull maddyonline/gowebapp
docker run -d --publish 8080:8080 --name gowebapp maddyonline/gowebapp
curl localhost:8080/icecream
> 嗨，我想我喜欢冰淇淋！
英文:
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!
答案1
得分: 5
我发现你当前的代码有两个问题。
第一个问题是在你的 main.go 文件中，字符串 localhost 需要改为 0.0.0.0。问题在于你告诉你的 Web 服务器只接受发送到 localhost 的请求。由于 Docker 进行的网络操作，所有发送到 Web 服务器的流量都不会被识别为发送到 localhost。通过告诉你的 Web 服务器监听 0.0.0.0，你实际上是告诉它不关心流量最初发送到哪里，它将接受所有流量。
var (
httpFlag = flag.String("http", "0.0.0.0:8080", "HTTP listen address") // <--- 这里是修改的地方。大约在 [main.go](https://github.com/maddyonline/gotutorial/blob/master/main.go#L25) 的第 25 行
originFlag = flag.String("origin", "", "web socket origin for Go Playground (e.g. localhost)")
baseFlag = flag.String("base", "", "base path for articles and resources")
)
第二个问题与你的导入路径与预定的 onbuild Dockerfile 目录结构冲突有关。我看到你试图硬编码导入路径，这不是一个好主意，但我认为这是你唯一的选择，因为 onbuild Dockerfile 强制使用了 go-wrapper。最终，你应该让 Docker 构建过程将一个静态的 Go 二进制文件放入容器中。这将简化在容器中启动服务器的过程。
我没有修改你的 Go 代码中的路径，我认为你可以解决这个问题，但我确实获取了上游的 onbuild Dockerfile，并根据你的需求进行了自定义。顺便说一句，如果你查看一下 onbuild Dockerfile 的文档，它实际上说不建议使用该 Dockerfile。 
所以，我采纳了他们的建议，这是我修改后的版本：
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"]
你的另一个示例服务器应用程序没有相同的问题，因为导入路径没有以与该项目中相同的方式指定。基本上，它不关心它所在的位置，因为它的依赖关系没有被硬编码为文件路径。它使用了正常的 Go 包约定。
抱歉，可能看起来需要做很多更改，但我希望这能帮助你在项目中继续前进。如果有任何不明白的地方，请告诉我。
英文:
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.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论