Golang Docker库镜像在$PATH中找不到go工具。

huangapple go评论164阅读模式
英文:

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 $PATHwhich 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内部发生了一些损坏,需要重新启动来修复(虽然很少见,但这不是我第一次见到这种情况)。对于将来遇到问题的其他人,我建议按照以下顺序尝试解决:

  1. 拉取新的镜像和/或重新构建,以解决与层相关的任何问题。
  2. 重新启动docker,以解决守护进程内部的可能损坏。
  3. 重新启动整个主机,以解决在docker守护进程之外持续存在的运行时配置问题。
  4. 在停止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:

  1. Pull fresh images and/or rebuild without caching for any issues with the layers
  2. Restart docker for possible corruption inside the daemon
  3. Restart the entire host for runtime configuration issues that persist outside of the docker daemon
  4. With dockerd stopped, wipe /var/lib/docker which will destroy all containers, images, and volumes (so backup first) and start clean

huangapple
  • 本文由 发表于 2017年6月9日 08:17:46
  • 转载请务必保留本文链接:https://go.coder-hub.com/44447458.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定