Merge pull request #907 from infosiftr/golang-tweaks

Unroll "golang:onbuild", update to 1.8, and use "%%IMAGE%%"
This commit is contained in:
yosifkit 2017-05-12 15:48:53 -07:00 committed by GitHub
commit 39babb9b37
1 changed files with 14 additions and 10 deletions

View File

@ -13,13 +13,17 @@ Go (a.k.a., Golang) is a programming language first developed at Google. It is a
The most straightforward way to use this image is to use a Go container as both the build and runtime environment. In your `Dockerfile`, writing something along the lines of the following will compile and run your project:
```dockerfile
FROM golang:1.6-onbuild
FROM %%IMAGE%%:1.8
WORKDIR /go/src/app
COPY . .
RUN go-wrapper download # "go get -d -v ./..."
RUN go-wrapper install # "go install -v ./..."
CMD ["go-wrapper", "run"] # ["app"]
```
This image includes multiple `ONBUILD` triggers which should cover most applications. The build will `COPY . /go/src/app`, `RUN go get -d -v`, and `RUN go install -v`.
This image also includes the `CMD ["app"]` instruction which is the default command when running the image without arguments.
You can then build and run the Docker image:
```console
@ -27,20 +31,20 @@ $ docker build -t my-golang-app .
$ docker run -it --rm --name my-running-app my-golang-app
```
*Note:* the default command in `%%REPO%%:onbuild` is actually `go-wrapper run`, which includes `set -x` so the binary name is printed to stderr on application startup. If this behavior is undesirable, then adding `CMD ["app"]` (or `CMD ["myapp"]` if a [Go custom import path](https://golang.org/s/go14customimport) is in use) will silence it by running the built binary directly.
*Note:* `go-wrapper run` includes `set -x` so the binary name is printed to stderr on application startup. If this behavior is undesirable, then switching to `CMD ["app"]` (or `CMD ["myapp"]` if a [Go custom import path](https://golang.org/s/go14customimport) is in use) will silence it by running the built binary directly.
## Compile your app inside the Docker container
There may be occasions where it is not appropriate to run your app inside a container. To compile, but not run your app inside the Docker instance, you can write something like:
```console
$ docker run --rm -v "$PWD":/usr/src/myapp -w /usr/src/myapp golang:1.6 go build -v
$ docker run --rm -v "$PWD":/usr/src/myapp -w /usr/src/myapp %%IMAGE%%:1.8 go build -v
```
This will add your current directory as a volume to the container, set the working directory to the volume, and run the command `go build` which will tell go to compile the project in the working directory and output the executable to `myapp`. Alternatively, if you have a `Makefile`, you can run the `make` command inside your container.
```console
$ docker run --rm -v "$PWD":/usr/src/myapp -w /usr/src/myapp golang:1.6 bash -c make
$ docker run --rm -v "$PWD":/usr/src/myapp -w /usr/src/myapp %%IMAGE%%:1.8 make
```
## Cross-compile your app inside the Docker container
@ -48,13 +52,13 @@ $ docker run --rm -v "$PWD":/usr/src/myapp -w /usr/src/myapp golang:1.6 bash -c
If you need to compile your application for a platform other than `linux/amd64` (such as `windows/386`):
```console
$ docker run --rm -v "$PWD":/usr/src/myapp -w /usr/src/myapp -e GOOS=windows -e GOARCH=386 golang:1.6 go build -v
$ docker run --rm -v "$PWD":/usr/src/myapp -w /usr/src/myapp -e GOOS=windows -e GOARCH=386 %%IMAGE%%:1.8 go build -v
```
Alternatively, you can build for multiple platforms at once:
```console
$ docker run --rm -it -v "$PWD":/usr/src/myapp -w /usr/src/myapp golang:1.6 bash
$ docker run --rm -it -v "$PWD":/usr/src/myapp -w /usr/src/myapp %%IMAGE%%:1.8 bash
$ for GOOS in darwin linux; do
> for GOARCH in 386 amd64; do
> go build -v -o myapp-$GOOS-$GOARCH