Golang docker库映像无法在$ PATH中找到go工具

Question

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.

Answer 1

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