Hi,

Maybe I miss here something, but I cannot use golang:1.6-onbuild to build my go project.

This is the error message I'm getting from running the build:

Deploying '<unknown>  Dockerfile: Dockerfile'...
Building image...
Step 1 : FROM golang:1.6-onbuild

�[91m# Executing 3 build triggers...
�[0m
Step 1 : COPY . /go/src/app

Step 1 : RUN go-wrapper download

 ---> Running in 1b0f1d10c79a

�[91m+ exec go get -v -d
�[0m
�[91mgithub.com/gaia-adm/pre-store-enricher (download)
�[0m
�[91mgithub.com/streadway/amqp (download)
�[0m
Step 1 : RUN go-wrapper install

 ---> Running in 7d3fa4d1abc7

�[91m+ exec go install -v
�[0m
�[91mgithub.com/gaia-adm/pre-store-enricher/vendor/github.com/Sirupsen/logrus
�[0m
�[91mgithub.com/gaia-adm/pre-store-enricher/log
�[0m
�[91mgithub.com/gaia-adm/pre-store-enricher/vendor/github.com/streadway/amqp
�[0m
�[91mgithub.com/gaia-adm/pre-store-enricher/amqpconnector
�[0m
�[91mgithub.com/streadway/amqp
�[0m
�[91mapp
�[0m
�[91m# app
./main.go:35: cannot use connectedToRabbit (type chan *"github.com/streadway/amqp".Connection) as type chan<- *"github.com/gaia-adm/pre-store-enricher/vendor/github.com/streadway/amqp".Connection in argument to amqpconnector.InitRabbitConn
�[0m
Error: ResponseItem.ErrorDetail[code=0,message=The command '/bin/sh -c go-wrapper install' returned a non-zero code: 2]
Failed to deploy '<unknown>  Dockerfile: Dockerfile': The command '/bin/sh -c go-wrapper install' returned a non-zero code: 2

for some reason it looks for the vendor directory in my project although I did not vendor the 3rd party packages

I tried to run it with vendoring amqp and without - the same result.
I also tried to use golang:1.6 - the same result.

When I'm running "go install" not via docker everything works fine (I'm using Go 1.6 SDK on Windows).

The code that cause it:

From main.go I have this code:

import (
    "os"
    "os/signal"
    "syscall"
    "github.com/streadway/amqp"
    "github.com/gaia-adm/pre-store-enricher/log"
    "github.com/gaia-adm/pre-store-enricher/amqpconnector"
)

...
...

connectedToRabbit := make(chan *amqp.Connection)
go amqpconnector.InitRabbitConn(connectedToRabbit)

and in amqpconnector package I have this code:

import (
    "os"
    "time"
    "github.com/gaia-adm/pre-store-enricher/log"
    "github.com/streadway/amqp"
)

...
...

func InitRabbitConn(connected chan<- *amqp.Connection) {
    ticker := time.NewTicker(5 * time.Second)
    defer ticker.Stop()
    for ; ; <-ticker.C {
        conn, err := amqp.Dial(pseAmqpUrl)
        if err != nil {
            log.Log.Warn("failed to connect to rabbit (", pseAmqpUrl, "): ", err)
            log.Log.Warn("trying to reconnect to rabbit in 5 seconds...")
            continue
        } else {
            log.Log.Info("successfully connected to rabbit (", pseAmqpUrl, ")")
        }
        connected <- conn
        return
    }
}

for now my workaround is to use golang:1.5.3-onbuild instead (I do not enable vendoring in this case)

Thanks,
Shay

It seems the golang images don't have ssh installed. This prevents using git to pull things from ssh repos not hosted with a git daemon.

Could ssh be added to the image?

I just found this issue: #33 which has valid points. My use case is using the golang image as a base in ci/cd system (drone), so I need to be able to pull from private repos.

I want to install ffmpeg in the golang container and my approach is to get access to the shell as

docker run -t -i my-webservice /bin/bash
(I have tried /bin/csh, /bin/tcsh, /bin/ksh, /bin/sh as well)

In contrary to the ubuntu:14.04 image, I don't get access to the bash shell. How can that be?

I have also found an image, where the ffmpeg is already configured and installed (https://registry.hub.docker.com/u/cellofellow/ffmpeg/). Is it possible to get access to the container from the golang container or do I have to install ffmpeg into my own docker image?

Dockerfile has a single line: "FROM golang:onbuild"

Get the following error:

jgolio@joe-Precision-WorkStation-T5500: > docker build -t golang .
Sending build context to Docker daemon 2.048 kB
Sending build context to Docker daemon
Step 0 : FROM golang:onbuild
onbuild: Pulling from golang
6d1ae97ee388: Already exists
8b9a99209d5c: Already exists
2e05a52ffd47: Already exists
80887d145531: Already exists
ec064956c4f0: Already exists
c8a688c71293: Already exists
03f519453f95: Already exists
b449de9eb16c: Already exists
7ab9945f3cbe: Already exists
7cb2cf0c147e: Already exists
b56020e12f7a: Already exists
1c3154f0cc14: Already exists
d556268f76ae: Already exists
0eca3aede538: Already exists
cf249b900631: Already exists
e76f6354d97b: Already exists
3b257c27c645: Already exists
d9d76b3f6346: Already exists
cce7e8018ea3: Already exists
040bcbc1f0fe: Already exists
golang:onbuild: The image you are pulling has been verified. Important: image verification is a tech preview feature and should not be relied on to provide security.
Digest: sha256:48a136c23844f202883c7181a86383098da6900153099daf5a0b3556af6ae62c
Status: Downloaded newer image for golang:onbuild

Executing 3 build triggers

Trigger 0, COPY . /go/src/app
Step 0 : COPY . /go/src/app
Trigger 1, RUN go-wrapper download
Step 0 : RUN go-wrapper download
---> Running in 445b2396dc17

• exec go get -v -d
  can't load package: package app: no buildable Go source files in /go/src/app
  The command '/bin/sh -c go-wrapper download' returned a non-zero code: 1

Note that I'm pretty much a Docker and Golang novice, so I'm thinking it's something fairly stupid that I'm doing.

I have a project that depends on libaspell-dev, but I can't install this before the ONBUILD commands are run.

Could you include an additional ONBUILD command before the others, or modify go-wrapper, to include something similar to this?

if [ -x .docker/action_hooks/pre-build ]; then
  echo " -----> Running .docker/action_hooks/pre-build"
  .docker/action_hooks/pre-build
fi

I was able to shink the image from 413.7MB to 359.7MB using the Dockerfile below.

FROM debian:wheezy

ENV GOLANG_VERSION 1.3.1
# Go building deps and SCMs for "go get"
RUN apt-get update && apt-get install -y \
        gcc libc6-dev ca-certificates curl \
        bzr git mercurial \
        --no-install-recommends \

  && curl -sSL http://golang.org/dl/go$GOLANG_VERSION.src.tar.gz \
    | tar -v -C /usr/src -xz \


  && cd /usr/src/go/src && ./make.bash --no-clean 2>&1 \
  && apt-get purge -y gcc libc6-dev curl \
  && apt-get autoremove -y

ENV PATH /usr/src/go/bin:$PATH

RUN mkdir -p /go/src
ENV GOPATH /go
ENV PATH /go/bin:$PATH
WORKDIR /go

How to reproduce it:

$ docker run --rm golang:1.6.2-alpine ls /etc/ssl
ls: /etc/ssl: No such file or directory

It also happens with 1.5-alpine and 1.7-alpine.
I think it relates to f376892.

Because I built the image from 0ce8041 and /etc/ssl existed.

I am not sure if this is a expected behavior but one builds project which send https request will get x509: failed to load system roots and no roots provided.

How about adding RUN apk add ca-certificates to Dockerfile or using another tag?
I would like to create a pull request.

https://groups.google.com/forum/#!msg/golang-nuts/zndSPkE2DVE/bcOu35-OBwAJ

I want to use Sourcegraph for golang code search, browsing, and usage examples. Can an admin enable Sourcegraph for this repository? Just go to https://sourcegraph.com/github.com/docker-library/golang. (It should only take 30 seconds.)

Thank you!

Some non-trivial application (like etcd) import subpackages from their own import paths, and thus expect to be stored at a fixed location in GOPATH, example:

import "github.com/coreos/etcd/log"

Currently he onbuild variant ADD the source code in GOPATH/src/app, this causes go get ./... to fetch this kind of dependencies remotely and possibly ignore local change.

One possible solution is to add support for a .godir file defining the application import path at the root of the source directory, see:
GoogleCloudPlatform/golang-docker#10
GoogleCloudPlatform/golang-docker#12

Hi,

to me, mostly influenced by http://peter.bourgon.org/go-in-production/, the nicest way to vendor dependencies is by just adding a second GOPATH pointing to your/import-path/_vendor.

Since the ON-BUILD steps happen before you can set any env variables in your Dockerfile, you can't use this pattern right now.

Therefor I suggest to set a second GOPATH pointing to _vendor like this. I assume that should work by simply setting GOPATH to "/go:/go/src/app/_vendor". This way people can just add the deps they want to _vendor and they're done.

Git is pretty critical to most go get processing. It's present in the debian version of golang 1.6 but not the alpine version

https://golang.org/dl (which we scrape in update.sh already) includes a SHA1 Checksum column; while we're there scraping the "latest version", we should scrape that goVERSION.src.tar.gz checksum value and verify our downloads 👍

Hi,

I have a proposal for this image that, as I believe, will improve Go development experience a lot.
I'm talking about hot code reloading. I'm not sure if it will work good for big projects, but for my use case which is tons of small Go apps, it will be a huge time saver.

Implementation should not be complicated, all we need to do is to add some file system watcher that will trigger builds after *.go file changes and restart app after successful builds.

I get this error with 1.5.0 and 1.5.1 images, as part of a Dockerfile that wants to install mysql-client:

Status: Downloaded newer image for golang:1.5.1
 ---> e80a32407c21
Step 1 : RUN apt-get update -q && apt-get install mysql-client -q -y
 ---> Running in cd15b40f30bc
Err http://httpredir.debian.org jessie InRelease

Err http://httpredir.debian.org jessie-updates InRelease

Err http://security.debian.org jessie/updates InRelease

Err http://httpredir.debian.org jessie Release.gpg
  Could not resolve 'httpredir.debian.org'
Err http://security.debian.org jessie/updates Release.gpg
  Could not resolve 'security.debian.org'
Err http://httpredir.debian.org jessie-updates Release.gpg
  Could not resolve 'httpredir.debian.org'
Reading package lists...
W: Failed to fetch http://httpredir.debian.org/debian/dists/jessie/InRelease  

W: Failed to fetch http://httpredir.debian.org/debian/dists/jessie-updates/InRelease  

W: Failed to fetch http://security.debian.org/dists/jessie/updates/InRelease  

W: Failed to fetch http://httpredir.debian.org/debian/dists/jessie/Release.gpg  Could not resolve 'httpredir.debian.org'

W: Failed to fetch http://httpredir.debian.org/debian/dists/jessie-updates/Release.gpg  Could not resolve 'httpredir.debian.org'

W: Failed to fetch http://security.debian.org/dists/jessie/updates/Release.gpg  Could not resolve 'security.debian.org'

W: Some index files failed to download. They have been ignored, or old ones used instead.
Reading package lists...
Building dependency tree...
Reading state information...
E: Unable to locate package mysql-client

Those URLs give a 404.

Hi,

I'm doing something like this:

docker run --rm \
    -v ${PROJECT_DIR}:${CONTAINER_PROJECT_DIR} \
    -e GODEBUG=netdns=go \
    -e GOPATH=${CONTAINER_PROJECT_GOPATH} \
    -w "${CONTAINER_PROJECT_DIR}" \
    golang:1.5.3-alpine \
    go test -v -race 

But the race detector will crash with this error:

# runtime/cgo
exec: "gcc": executable file not found in $PATH

This doesn't happen with the golang:1.5.3 image.
I've tried the go 1.6 rc2 image and the same outcome.

With these results, I've decided to upgrade the Go image with the missing gcc stuff and so I've created this:

FROM golang:1.5.3-alpine
MAINTAINER Florin Patan "[email protected]"

# SSL certs
RUN apk add --update ca-certificates g++ gcc make musl musl-dev \
    && rm -rf /var/cache/apk/*

Then I've used the newly created image to replace the golang:1.5.3 image and I've ran the above command again.
The outcome was that the binary now compiles again however there's a new error at runtime:

# runtime/race
race_linux_amd64.syso: In function `__sanitizer::InternalAlloc(unsigned long, __sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator32<0ul, 140737488355328ull, 0ul, __sanitizer::SizeClassMap<17ul, 64ul, 14ul>, 20ul, __sanitizer::TwoLevelByteMap<32768ull, 4096ull, __sanitizer::NoOpMapUnmapCallback>, __sanitizer::NoOpMapUnmapCallback> >*)':
gotsan.cc:(.text+0x1681): undefined reference to `__libc_malloc'
race_linux_amd64.syso: In function `__sanitizer::ReExec()':
gotsan.cc:(.text+0xd937): undefined reference to `__libc_stack_end'
race_linux_amd64.syso: In function `__sanitizer::InternalFree(void*, __sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator32<0ul, 140737488355328ull, 0ul, __sanitizer::SizeClassMap<17ul, 64ul, 14ul>, 20ul, __sanitizer::TwoLevelByteMap<32768ull, 4096ull, __sanitizer::NoOpMapUnmapCallback>, __sanitizer::NoOpMapUnmapCallback> >*)':
gotsan.cc:(.text+0x5ec8): undefined reference to `__libc_free'
collect2: error: ld returned 1 exit status

I believe that the last error is caused by the ThreadSanitizer race detector which is shipped with Go but that's a separate issue imho.

As such, I'm not sure what's the best way to continue. Ideally I'd like to compile the binary and run the tests against the same libraries and using golang:1.5.3 for running the tests and golang:1.5.3-alpine to build the binary doesn't seem as the way to move forward.

Thank you.

There's been some discussion previously about switching the base of this collection of images from debian:wheezy to debian:jessie, especially since Go is very young (comparatively), so most packages for it target really recent versions of libraries.

I figured we should open an issue and actually discuss it. Thoughts? 😄

My build failed because it seems to try to overwrite a subfolder in my project named /app with the output binary.

Output:

Step onbuild-2 : RUN go-wrapper install
 ---> Running in 96a4e82eb692
ln: `/go/src/github.com/hansrodtang/digitalmagasinet/app': cannot overwrite directory

Dockerfile:

FROM golang:1.3.3-onbuild
CMD ["./digitalmagasinet"]

.godir :

github.com/hansrodtang/digitalmagasinet

Maybe this is obvious but I've been trying to find a solution for this for an hour or two without any success.

Trying to use golang:1.3.3-onbuild against my private repository fails with:
fatal: could not read Username for 'https://github.com': No such device or address

This comes as no surprise since I haven't stated any authentication anywhere. How do I authenticate to make go get work against a private repository?

At least golang:alpine does not install git, which means go get is a bit crippled. Any chance of adding it?

Docker's best practices states:

If a service can run without privileges, use USER to change to a non-root user.

I'm wondering if we should make a non-root user to own /go and to not open this security can of worms by default.

I'd love to have an sshd built in the image.
It seems a reasonable request to me...
thank you

We are using golang:1.4.2-wheezy for automatic building of go binaries. Unfortunately the machine which runs the container is not allowed to reach the www through IPv6. And apparently an apt-get command within the container uses IPv6 by default. Is it possible to change this? I have already tried to add -o Acquire::ForceIPv4=true to the apt-get command, but this does now work.

09:26:08 Step 1 : RUN apt-get -y update
09:26:08  ---> Running in 6d151ec1148b
09:27:12 Err http://http.debian.net wheezy Release.gpg
09:27:12   Cannot initiate the connection to http.debian.net:80 (2001:41c8:1000:21::21:35). - connect (101: Network is unreachable) [IP: 2001:41c8:1000:21::21:35 80]

The onbuild and wheezy variants include the go-wrapper script, but the alpine one does not. It seems to be missing the COPY command in the Dockerfile.

I have created a GCE instance as described at https://blog.golang.org/docker. Because I'm using a private repository, I have to manually run the container (sudo docker run my/image) works fine and the http server IP can be reached.

Two containers seems to run, though I would have expected only one running:

~$ sudo docker ps
CONTAINER ID IMAGE COMMAND PORTS NAMES
c71dedc0b6de my/image:latest "/bin/sh -c /Users/n 8080/tcp cocky_wright
959df573ccb0 my/image:latest "/bin/sh -c /Users/n k8s--compute_-_webservice.5ebf7573--1.http--bac9fbf1

Now, stopping both containers (docker stop container_id) and re-running my container makes the server IP not reachable and only one container is running in contrary to the first time the container is run. What is the problem here?

Moreover, mounting a volume always creates only one container and hence the server can newer be reached (only a problem on the GCE instance, it works locally):

sudo docker run -v /local/mount/dir:/image/mount/dir my/image:latest --rm my/image:latest

Cross builder for 1.5 needed

Why alpine images recompile Go from source instead of using the binary distribution?
Is it an issue with libc?

Why alpine images use Go 1.4.3 as boostrap instead of the latest binary distribution (1.5 or 1.6)?

Thank you

I want to use Sourcegraph for golang code search, browsing, and usage examples. Can an admin enable Sourcegraph for this repository? Just go to https://sourcegraph.com/github.com/docker-library/golang. (It should only take 30 seconds.)

Thank you!

I'm trying to start with vendoring and Go 1.6.1, but I'm having issues in the sense that my vendor folder isn't getting picked up:

root@b7f75d02a32f:/go# go run flags.go
flags.go:3:8: cannot find package "github.com/namsral/flag" in any of:
        /usr/local/go/src/github.com/namsral/flag (from $GOROOT)
        /go/src/github.com/namsral/flag (from $GOPATH)
root@b7f75d02a32f:/go# GO15VENDOREXPERIMENT=1 go run flags.go
flags.go:3:8: cannot find package "github.com/namsral/flag" in any of:
        /usr/local/go/src/github.com/namsral/flag (from $GOROOT)
        /go/src/github.com/namsral/flag (from $GOPATH)
root@b7f75d02a32f:/go# find -type d -name flag
./vendor/github.com/namsral/flag
root@b7f75d02a32f:/go# go version
go version go1.6.1 linux/amd64
root@b7f75d02a32f:/go#

From what I understood, I should never use '/vendor/' in import paths, so I'm using this:

import "github.com/namsral/flag"

but with no success. Any ideas what's going on here? I created the vendor/ folder with gvt fetch (using justin cormacks docker image from docker hub).

Hi @tianon ,

Can "go-wrapper" from this repo be copied to another base image repo?

Specifically, we would like to use it for building the base image for Go on App Engine apps.
The repo is here:
https://github.com/GoogleCloudPlatform/golang-docker

Can I simply copy it to the "base" subdirectory of this repo, or are there steps that I must take before doing the copy?

Thanks!
-- Glenn

I'm new on Docker so I'm not sure if I'm write.

According to Docker Hub, apline latest image of Golang size should actually be 67 MB.

But, with the following Dockerfile:

FROM golang:alpine

MAINTAINER Sullivan SENECHAL <[email protected]>

RUN apk add --update git mercurial && rm -rf /var/cache/apk/*

RUN go get github.com/fcambus/rrda

CMD ["rrda"]

My image size is now 351.3 MB.

BTW, the downloaded golang:alpine image size is 262.5 MB.

Is this normal? As you can see, my Dockerfile just installs two package and do a go get command.

Additional informations:

$ docker images
REPOSITORY              TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
rrda                    latest              755e0f84227d        5 minutes ago       351.3 MB
golang                  alpine              ab806b36241f        2 weeks ago         262.5 MB

$ docker history rrda
IMAGE               CREATED             CREATED BY                                      SIZE                COMMENT
755e0f84227d        8 minutes ago       /bin/sh -c #(nop) CMD ["rrda"]                  0 B                 
c6541d89cdee        8 minutes ago       /bin/sh -c go get github.com/fcambus/rrda       28.04 MB            
ddb143a056a7        8 minutes ago       /bin/sh -c apk add --update git mercurial &&    60.72 MB            
203c618d8255        13 days ago         /bin/sh -c #(nop) MAINTAINER Sullivan SENECHA   0 B                 
ab806b36241f        2 weeks ago         /bin/sh -c #(nop) WORKDIR /go                   0 B                 
fc6c18901fb3        2 weeks ago         /bin/sh -c mkdir -p "$GOPATH/src" "$GOPATH/bi   0 B                 
1c84d116ee5b        2 weeks ago         /bin/sh -c #(nop) ENV PATH=/go/bin:/usr/local   0 B                 
6edd7a120c4a        2 weeks ago         /bin/sh -c #(nop) ENV GOPATH=/go                0 B                 
f5391dc8533e        2 weeks ago         /bin/sh -c set -ex  && buildDeps='bash ca-cer   257.3 MB            
a3d9ad2bd015        2 weeks ago         /bin/sh -c #(nop) ENV GOLANG_BOOTSTRAP_SHA1=4   0 B                 
ce6bd1428c20        2 weeks ago         /bin/sh -c #(nop) ENV GOLANG_BOOTSTRAP_URL=ht   0 B                 
dae1044b495d        2 weeks ago         /bin/sh -c #(nop) ENV GOLANG_BOOTSTRAP_VERSIO   0 B                 
c9882838f8e6        2 weeks ago         /bin/sh -c #(nop) ENV GOLANG_SRC_SHA1=c7d78ba   0 B                 
15f26cbe3faf        2 weeks ago         /bin/sh -c #(nop) ENV GOLANG_SRC_URL=https://   0 B                 
c1f463b977c8        2 weeks ago         /bin/sh -c #(nop) ENV GOLANG_VERSION=1.5.2      0 B                 
49578ed3d0d5        2 weeks ago         /bin/sh -c #(nop) ADD file:5642360cf39258931f   5.254 MB            

Regards.

I have a Go program that writes to both stderr and stdout. If I run this within golang:1.5-onbuild base image, the output I get from the container when I attach to stdout of the container (using -i -t -a stdout) also contains the output from program's stderr.

I'm guessing this is happening because of go-wrapper. Should this be fixed or is it by design?

From reading the Image Dockerfile I needed to make the following changes to get the "Start a Go instance in your app" to work, if anyone has the same problem I can create a pull request

Dockerfile ?

Should CMD not be
CMD ["app"]
rather than CMD ["./myapp"]

• If the Dockerfile is in the same directory then the executable will be "app" based on the content being copied to the /go/src/app directory
• Also relies on /go/bin being on the path and since go install is called via the wrapper, hence no local executable in the WORKDIR

Build step ?

docker build -t my-golang-app
Missing a trailing " ." to build for current directory

I have a go install -a -v in my Dockerfile, and tried to run "docker build"

Initially I saw such error:
.....
#runtime/cgo
exec: "gcc": executable file not found in $PATH
....

After adding "apk add gcc" into Dockerfile, I saw this error:
.....

runtime/cgo

/usr/local/go/src/runtime/cgo/cgo.go:54:19: fatal error: errno.h: No such file or directory
compilation terminated.
.....

It takes time to cross-compiling golang project for multiple platforms one by one.
If we use mitchellh/gox, we can compile them parallelly, and takes less time.

So I've built docker images which is used mitchellh/gox and official golang image:

• tcnksm/dockerfile-gox
• tcnksm/gox Repository | Docker Hub Registry - Repositories of Docker Images

I know adding new tags in this projects is not good and gox is not official tool. But if you don't mind that, I want to merge my project into this project with gox tag.

Currently we require user to set .godir to their import path in order ONBUILD ADD their source in the right location.

We should also look at Godeps/Godeps.json when present to get the same information:
https://github.com/coreos/etcd/blob/master/Godeps/Godeps.json#L2

Hello docker-library/golang.

Thanks for making a combo alpine/golang. I find it very useful. I did notice one oddity. it appears it contains 36M of leftover bootstrap code, that I suspect can be deleted to the delight of everyone.

The alpine container uses gcc and golang 1.4 to bootstrap and build golang latest.

It appears the bootstrap is meant to be deleted after use, since in the in the Dockerfile, I see

    && rm -rf /usr/local/bootstrap \

But in /usr/local/go/pkg I see 36M of other bootstrap leftovers.

/usr/local/go/pkg # du -c -m bootstrap
0   bootstrap/src/bootstrap/asm/internal/arch
0   bootstrap/src/bootstrap/asm/internal/asm
0   bootstrap/src/bootstrap/asm/internal/lex
0   bootstrap/src/bootstrap/asm/internal/flags
0   bootstrap/src/bootstrap/asm/internal
0   bootstrap/src/bootstrap/asm
0   bootstrap/src/bootstrap/link/internal/arm
0   bootstrap/src/bootstrap/link/internal/amd64
0   bootstrap/src/bootstrap/link/internal/arm64
0   bootstrap/src/bootstrap/link/internal/ppc64
0   bootstrap/src/bootstrap/link/internal/x86
0   bootstrap/src/bootstrap/link/internal/ld
1   bootstrap/src/bootstrap/link/internal
1   bootstrap/src/bootstrap/link
0   bootstrap/src/bootstrap/internal/gcprog
0   bootstrap/src/bootstrap/internal/obj/arm
0   bootstrap/src/bootstrap/internal/obj/arm64
0   bootstrap/src/bootstrap/internal/obj/ppc64
0   bootstrap/src/bootstrap/internal/obj/x86
1   bootstrap/src/bootstrap/internal/obj
1   bootstrap/src/bootstrap/internal
0   bootstrap/src/bootstrap/compile/internal/arm
0   bootstrap/src/bootstrap/compile/internal/amd64
1   bootstrap/src/bootstrap/compile/internal/gc
0   bootstrap/src/bootstrap/compile/internal/arm64
0   bootstrap/src/bootstrap/compile/internal/big
0   bootstrap/src/bootstrap/compile/internal/ppc64
0   bootstrap/src/bootstrap/compile/internal/x86
2   bootstrap/src/bootstrap/compile/internal
2   bootstrap/src/bootstrap/compile
4   bootstrap/src/bootstrap
4   bootstrap/src
18  bootstrap/bin
1   bootstrap/pkg/linux_amd64/bootstrap/asm/internal
1   bootstrap/pkg/linux_amd64/bootstrap/asm
2   bootstrap/pkg/linux_amd64/bootstrap/link/internal
2   bootstrap/pkg/linux_amd64/bootstrap/link
2   bootstrap/pkg/linux_amd64/bootstrap/internal/obj
2   bootstrap/pkg/linux_amd64/bootstrap/internal
9   bootstrap/pkg/linux_amd64/bootstrap/compile/internal
9   bootstrap/pkg/linux_amd64/bootstrap/compile
14  bootstrap/pkg/linux_amd64/bootstrap
14  bootstrap/pkg/linux_amd64
14  bootstrap/pkg
36  bootstrap
36  total

I don't see this bootstrap directory in the other golang binary downloads .

Useful? Intentional? Mistake?

I'd love to see && rm -rf /usr/local/bootstrap \ added and save 36M if possible.

thanks all!

nickg

p.s. the /usr/local/go/test directory (10MB) also looks suspicious, but I'm less certain about it.

When trying to port to golang:1.6.2-alpine from golang:1.6.2, the Go HTTP client gets errors like:

x509: failed to load system roots and no roots provided

when making HTTPS requests.

Minimum case:

In the Dockerfile:

FROM golang:1.6.2-alpine
CMD ["sh"]`

And then run go run foo.go with a foo.go of

package main

import (
    "fmt"
    "net/http"
)

func main() {
    _, err := http.Get("https://www.google.com")
    fmt.Printf("welp %s\n", err)
}

Seems like something went wrong while updating the Hub images. Although the repo info refers to 1.5 final the image contains the 1.5-rc1 build.

λ date
Wed Aug 19 22:12:29 BRT 2015

λ docker pull golang:1.5
1.5: Pulling from library/golang

4369e3fe1080: Pull complete
3be1c44fbed9: Pull complete
ca3f71735a69: Pull complete
3df2046d03fa: Pull complete
dd9c8b6f8c75: Pull complete
699f00c80133: Pull complete
9d19f5fb1f9f: Pull complete
ff564014946c: Pull complete
1a1bf494ce01: Pull complete
902b87aaaec9: Already exists
9a61b6b1315e: Already exists
1ff9f26f09fb: Already exists
607e965985c1: Already exists
0f5121dd42a6: Already exists
Digest: sha256:cb09dc8bac0c7c4851307465f7f5ebf362f1fff2885e70349e4e44c146ee431f
Status: Downloaded newer image for golang:1.5

λ docker run --rm golang:1.5 go version
go version go1.5rc1 linux/amd64

Also, the golang:latest still contains the 1.4.2 build.

λ date
Wed Aug 19 22:18:58 BRT 2015

λ docker pull golang:latest
latest: Pulling from library/golang

902b87aaaec9: Already exists
9a61b6b1315e: Already exists
1ff9f26f09fb: Already exists
607e965985c1: Already exists
0f5121dd42a6: Already exists
8d38711ccc0d: Already exists
8ddc08289e1a: Already exists
d86979befb72: Already exists
b279b4aae826: Already exists
63e9d2557cd7: Already exists
8fb45e60e014: Already exists
141b650c3281: Already exists
69c177f0c117: Already exists
124e2127157f: Already exists
Digest: sha256:e8279dcc2ac54d8b31529a1bac48ff696b6ff807969976440646efca80c57cc3
Status: Image is up to date for golang:latest

λ docker run --rm golang:latest go version
go version go1.4.2 linux/amd64

I've tested this in multiple hosts with same results.

Note that, I'm located in Brazil, maybe this is just the CDN cache? If so, pretty weird Hub behavior.

It would be nice if the onbuild docker image supported 1.5 Go Vendor Experiment.

I would like to standardize on using the golang Dockerfile for Go apps running on Managed VMs, but to do this, I need to pass -tags appenginevm to go build and it appears that the current go-wrapper does not yet support the tags flag.

Before I start adding this to go-wrapper, @tianon , does this sound like something that might be accepted?

I was thinking that a developer's Dockerfile could add a line like this:

ENV GOTAGS 'tag list'

and then go-wrapper would add -tags 'tag list' to the go build command.

Hello, I have been attempting to use your image as a base for a Go project of mine. When I attempt to run my Dockerfile:

FROM golang:1.3.1-onbuild
CMD ["./main"]

I get the following error (FYI I use Vagrant to manage my containers):

» vagrant up --provider=docker
Bringing machine 'default' up with 'docker' provider...
==> default: Docker host is required. One will be created if necessary...
    default: Docker host VM is already ready.
==> default: Syncing folders to the host VM...
    default: Rsyncing folder: /Users/sdagostino/Dev/SociableLabs/Odysseus/customer-api-laerte/ => /var/lib/docker/docker_1412176823_67424
    default: Rsyncing folder: /Users/sdagostino/Dev/SociableLabs/Odysseus/customer-api-laerte/ => /mnt/docker_build_a241b1b5a712f9c18d06e9bcd6aa8b68
==> default: Building the container from a Dockerfile...
A Docker command executed by Vagrant didn't complete successfully!
The command run along with the output from the command is shown
below.

Command: "docker" "build" "/mnt/docker_build_a241b1b5a712f9c18d06e9bcd6aa8b68"

Stderr: Uploading context 179.7 kB
Uploading context
2014/10/01 15:20:22 COPY has been deprecated. Please use ADD instead

Stdout: Step 0 : FROM golang:1.3.1-onbuild
# Executing 3 build triggers
Step onbuild-0 : COPY . /go/src/app

I noticed that in your documentation you use the COPY command to move the directory into the GOPATH. It seems this command has been deprecated?

Any idea if this is a bug in the base image, or maybe I am not doing something right?

As specified by golang.org/s/go14customimport we could (ab)use that convention and infer the import path from comments after package main, ex:

package main // import "github.com/coreos/etcd"

It's usually not set on package main, but it would provide us with the same information that .godir gives us today.

wdyt? /cc @nf

There are latest and 1 and 1-onbuild and 1-cross, but what about latest-onbuild and latest-cross? Is that just an omission? Should latest be dropped? It's the same as 1 (when 2 eventually arrives it will certainly be incompatible with 1).

https://golang.org/dl/#go1.7rc3

and has no write permissions for other users

which means you can't run go get in a container running as non-root fails.

sven@3a8fb991af94:~$ docker run --rm -it  -v /home/sven/go:/go --volumes-from app_shell_1 -u 1000 golang:1.4-cross bash
WARNING: Your kernel does not support memory swappiness capabilities, memory swappiness discarded.
I have no name!@492649734cdd:/go$ 
I have no name!@492649734cdd:/go$ ls
I have no name!@492649734cdd:/go$ go get github.com/spf13/hugo
package github.com/spf13/hugo: mkdir /go/src: permission denied
I have no name!@492649734cdd:/go$ ls
I have no name!@492649734cdd:/go$ ls -la
total 8
drwxr-xr-x  2 root root 4096 Sep 14 15:01 .
drwxr-xr-x 53 root root 4096 Sep 14 15:01 ..

Now that Go 1.5 has been released, is there any news on when a relevant Docker container will be made available via DockerHub?

I have several local packages that my main application depends on, and I have problems setting up the Dockerfile in a correct way. When I ADD the parent directory I get "../shared-webservice/: no such file or directory". What's the problem here?

The Docker file:
ENV GOPATH /go/
ADD . /go/src/webservices/compute-webservice
ADD ../shared-webservice/ /go/src/webservices/shared-webservice

RUN go install webservices/compute-webservice
RUN go install webservices/shared-webservice

ENTRYPOINT /go/bin/compute-webservice

The file structure:
go/
-- src/
---- webservices/
------ compute-webservice/
-------- main.go
-------- services/
---------- foo.go
------- shared-webservice
--------- foo.go