英文:
Golang docker library image cannot find go tool in $PATH
问题
我在docker-library/golang#164上提了一个问题,因为我认为这是一个bug。然而,我想在StackOverflow上询问是否有其他人(除了项目贡献者)遇到过这个问题或者有任何想法?
首先,版本号如下:
$ docker version
客户端:
版本: 17.03.1-ce
API 版本: 1.27
Go 版本: go1.7.5
Git 提交: c6d412e
构建时间: Tue Mar 28 00:40:02 2017
操作系统/架构: darwin/amd64
服务器:
版本: 17.03.1-ce
API 版本: 1.27 (最低版本 1.12)
Go 版本: go1.7.5
Git 提交: c6d412e
构建时间: Fri Mar 24 00:00:50 2017
操作系统/架构: linux/amd64
实验性功能: true
$ docker-compose version
docker-compose 版本 1.11.2, 构建 dfed245
docker-py 版本: 2.1.0
CPython 版本: 2.7.12
OpenSSL 版本: OpenSSL 1.0.2j 26 Sep 2016
我遇到了以下错误:
无法启动 web 服务: oci runtime 错误: container_linux.go:247: 启动容器进程导致“exec: "go": 在 $PATH 中找不到可执行文件"
这是我的 Dockerfile
:
FROM golang:1.8
WORKDIR /go/src/gigem
COPY . /go/src/gigem
RUN go build
RUN go install
CMD ["gigem"]
我还在使用Compose(我会包含yml文件,但是无论是否使用Compose都会出现错误):
version: '3'
services:
db:
image: postgres
volumes:
- ./data:/var/lib/postgresql/data
web:
build: .
volumes:
- .:/go/src/gigem
ports:
- "3000:3000"
depends_on:
- db
我的Go程序只有以下内容:
package main
import (
"fmt"
"net/http"
)
func main() {
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
fmt.Fprintf(w, "Hello Docker!")
})
fmt.Println("Running!")
fmt.Println(http.ListenAndServe("0.0.0.0:3000", nil))
}
我不太确定为什么在 $PATH
中找不到go。
英文:
I opened an issue on docker-library/golang#164, because I think this is a bug. However, I thought I'd also ask on StackOverflow to see if anyone else (besides project contributors) have encountered this or have any ideas?
First things first, the version numbers:
$ docker version
Client:
Version: 17.03.1-ce
API version: 1.27
Go version: go1.7.5
Git commit: c6d412e
Built: Tue Mar 28 00:40:02 2017
OS/Arch: darwin/amd64
Server:
Version: 17.03.1-ce
API version: 1.27 (minimum version 1.12)
Go version: go1.7.5
Git commit: c6d412e
Built: Fri Mar 24 00:00:50 2017
OS/Arch: linux/amd64
Experimental: true
$ docker-compose version
docker-compose version 1.11.2, build dfed245
docker-py version: 2.1.0
CPython version: 2.7.12
OpenSSL version: OpenSSL 1.0.2j 26 Sep 2016
I'm getting the following error:
Cannot start service web: oci runtime error: container_linux.go:247: starting container process caused "exec: \"go\": executable file not found in $PATH"
And this is my Dockerfile
:
FROM golang:1.8
WORKDIR /go/src/gigem
COPY . /go/src/gigem
RUN go build
RUN go install
CMD ["gigem"]
I'm also using Compose (and I'll include the yml, but the error occurs with/without compose):
version: '3'
services:
db:
image: postgres
volumes:
- ./data:/var/lib/postgresql/data
web:
build: .
volumes:
- .:/go/src/gigem
ports:
- "3000:3000"
depends_on:
- db
And all that's in my Go program is:
package main
import (
"fmt"
"net/http"
)
func main() {
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
fmt.Fprintf(w, "Hello Docker!")
})
fmt.Println("Running!")
fmt.Println(http.ListenAndServe("0.0.0.0:3000", nil))
}
I'm not quite sure why go is not being found in the $PATH
.
答案1
得分: 0
我最近测试了你的Dockerfile和main.go,并没有发现任何错误。
我认为你应该尝试再次使用docker build --pull .
拉取golang:1.8
。
我修改了你的Dockerfile,在其中添加了两行新代码以调试镜像,请尝试以下内容:
FROM golang:1.8
WORKDIR /go/src/gigem
COPY . /go/src/gigem
RUN echo $PATH
RUN which go
RUN go build
RUN go install
CMD ["gigem"]
echo $PATH
和which go
将显示go
二进制文件是否在PATH中。
英文:
I recently tested your Dockerfile and main.go, and I did not find any errors.
I think you should try to pull golang: 1.8
again using docker build --pull .
I modified your Dockerfile adding two new lines to debug the image, try:
FROM golang: 1.8
    
WORKDIR / go / src / gigem
COPY. / Go / src / gigem
RUN echo $ PATH
RUN which go
RUN go build
RUN go install
CMD ["gigem"]
Echo $ PATH
and which go
will show you if the binary go
is inside the PATH
答案2
得分: 0
从评论中可以看出,我自己测试了这段代码,没有出现错误(尽管是在17.06-rc2上测试的,但行为不应该改变)。鉴于重新启动解决了这个问题,似乎是docker内部发生了一些损坏,需要重新启动来修复(虽然很少见,但这不是我第一次见到这种情况)。对于将来遇到问题的其他人,我建议按照以下顺序尝试解决:
- 拉取新的镜像和/或重新构建,以解决与层相关的任何问题。
- 重新启动docker,以解决守护进程内部的可能损坏。
- 重新启动整个主机,以解决在docker守护进程之外持续存在的运行时配置问题。
- 在停止dockerd的情况下,清除
/var/lib/docker
目录,这将销毁所有容器、镜像和卷(请先备份),然后重新开始。
英文:
From the comments, I tested this code myself without error (admittedly on 17.06-rc2 but the behavior shouldn't change). Given that a restart solved this, there appears to have been some corruption inside of docker that needed a bounce to correct (while rare, it wouldn't be the first time I've seen this). For others encountering problems in the future, I like to try the following in order:
- Pull fresh images and/or rebuild without caching for any issues with the layers
- Restart docker for possible corruption inside the daemon
- Restart the entire host for runtime configuration issues that persist outside of the docker daemon
- With dockerd stopped, wipe
/var/lib/docker
which will destroy all containers, images, and volumes (so backup first) and start clean
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论