1. Qiita
  2. 投稿
  3. Go

Goの公式dockerイメージを使ってみた

  • 90
    いいね
  • 0
    コメント
この記事は最終更新日から1年以上が経過しています。

Goの公式dockerイメージとは?

  • これの事 : golang Repository | Docker Hub Registry - Repositories of Docker Images
    • アナウンス記事 : Docker Hub Official Repos: Announcing Language Stacks | Docker Blog
    • 「各言語の実行環境が整ったコンテナ を動かすためのイメージ」を公式に公開したぜ、という話
    • ということはつまり、 Goアプリの実行・テスト・プロファイリング・ビルド といった作業を「公式のお墨付き且つ使い捨ての環境」で行うことが出来る という事。素敵
    • 言語のバージョンも揃っているので、バージョン間の挙動差異を確認したい時にサクっと環境をGETすることが出来る

使い方の例

実行環境として使う (Start a Go instance in your app)

Goで作成したcliツールを公式イメージのコンテナで動かすケースを試してみる(拙作 で試してみる)

事前準備

  • 対象goアプリをgit cloneする(ローカルにあればそこにcd)
$ git clone https://github.com/goldeneggg/ipcl.git
$ cd ipcl
  • 公式記事にあるサンプルの形式でDockerfileを用意する
    • FROMで指定するベースイメージは、tagに-onbuildというsuffixが付いているものを選択
      • このイメージには、ONBUILD処理が複数定義されている
    • buildする際、このONBUILDで定義されている処理も動く
      • ONBUILDで処理を定義した場合、 下流の/派生先の Dockerfileのcontextで処理が実行される
        • 派生先DockerfileのFROM句 直後に処理を埋め込むイメージ
      • 公式のサンプルではコンテナ上にappという名前で自・Goアプリがインストールされるけど、ONBUILDを使う事によりbuildを実行したディレクトリの内容次第でこのappの実体が変わる。という仕組み
        • つまり、Dockerfile自体に手を加えること無く使い回しが効く
$ vi Dockerfile

FROM golang:1.3.1-onbuild

# 対象goアプリ/ツールがコンテナ上では app という名前でインストールされるので、その名前を指定して実行
## 実行時引数が無いケース
# CMD ["app"]
## 実行時引数があるケース
CMD ["app", "192.168.56.24/0"]
  • このDockerfileを(任意のtagを付けて)buildする
    • build時に行われる処理の流れ
      • golang/1.3.1/onbuild イメージの親(FROMで指定されてる)イメージの golang/1.3.1 がpull&buildされる
        • Dockerfileはこれ。goバイナリのダウンロード・GOPATH等の環境変数設定・buildで使うwrapperスクリプト go-wrapper のコピー・などなどが実行される
      • golang/1.3.1/onbuild イメージがpull&buildされる。ONBUILDにより下記処理がビルド時に実行される
        • カレントディレクトリのファイル群をコンテナの/go/src/appにコピー
        • go-wrapper downloadの実行
        • go-wrapper installの実行
$ docker build -t my-ipcl .

:
(ONBUILD ここから)
# Executing 3 build triggers
Step onbuild-0 : COPY . /go/src/app
 ---> 370cb70d6c73
Step onbuild-1 : RUN go-wrapper download
 ---> Running in c6751d9cb63b
+ exec go get -v -d
github.com/goldeneggg/ipcl (download)
github.com/jessevdk/go-flags (download)
 ---> bc940f23da94
Step onbuild-2 : RUN go-wrapper install
 ---> Running in 04625b77395b
+ exec go install -v
github.com/goldeneggg/ipcl/parser
github.com/goldeneggg/ipcl/writer
github.com/jessevdk/go-flags
app
 ---> b6115dc12578
 ---> b6115dc12578
(ONBUILD ここまで)
:

goアプリの実行

  • 実行すると、CMDで指定したコマンド(と引数)の結果が表示される
$ docker run -it --rm --name my-running-ipcl my-ipcl

source_cidr : 192.168.56.0/24
network     : 192.168.56.0
mask        : 255.255.255.0
host_num    : 254
min_address : 192.168.56.1
max_address : 192.168.56.254
broadcast   : 192.168.56.255
  • appに渡す引数を動的に指定したい場合は、DockerfileのCMDENTRYPOINTにすれば良い
FROM golang:1.3.1-onbuild

# 実行時引数は docker run 時に指定する
ENTRYPOINT ["app"]
$ docker build -t my-ipcl .
$ docker run -it --rm --name my-running-ipcl my-ipcl 192.168.56.0/24  # <- 実行時引数指定

source_cidr : 192.168.56.0/24
network     : 192.168.56.0
mask        : 255.255.255.0
host_num    : 254
min_address : 192.168.56.1
max_address : 192.168.56.254
broadcast   : 192.168.56.255

# 引数が無い場合Usageを表示する想定だが、その通り動くか? -> OK
$ docker run -it --rm --name my-running-ipcl my-golang-ipcl

Target CIDR(or CIDR list file) is not assigned


Usage:
  ipcl [OPTIONS] <CIDR TEXT | -f <FILE>>

Application Options:
  -f, --file=    Filepath listed target CIDR
  -c, --csv=     Output format is csv
  -t, --tsv=     Output format is tsv
  -v, --version  Print version

Help Options:
  -h, --help     Show this help message

コンパイル環境として使う

自作Goアプリをコンテナ上でビルドしたい場合

事前準備

  • 対象goアプリをgit cloneする(ローカルにあればそこにcd)
$ git clone https://github.com/goldeneggg/ipcl.git
$ cd ipcl

※公式記事のサンプル通りでは動かない

  • 公式記事にあるサンプルの形式でgo buildmake してみる
    • -v-wのpathは$GOPATH/src/<対象appのpackage path>に置き換える
      • GOPATH/go
  • ちょっとハマった...
    • 外部ライブラリに依存している場合、事前にgo getするなりして依存解決しておかないとbuildエラーになる
    • makeコマンドが無い(公式Dockerfileではapt-get installしているはずなのだが)、github上のDockerfileとdockerhubに公開されてるイメージに差分があるのかしら。。。
$ docker run --rm -v "$(pwd)":/go/src/github.com/goldeneggg/ipcl -w /go/src/github.com/goldeneggg/ipcl golang:1.3.1 go build -v

main.go:11:2: cannot find package "github.com/jessevdk/go-flags" in any of:
        /usr/src/go/src/pkg/github.com/jessevdk/go-flags (from $GOROOT)
        /go/src/github.com/jessevdk/go-flags (from $GOPATH)
$ docker run --rm -v "$(pwd)":/go/src/github.com/goldeneggg/ipcl -w /go/src/github.com/goldeneggg/ipcl golang:1.3.1 make

exec: "make": executable file not found in $PATH
  • 対策として、
    • go buildする前に、依存パッケージのgo getを行うようにする
    • makeが動かなかった公式のgolang:1.3.1用Dockerfileをローカルでbuildして使う
      • 折角公開されているイメージをローカルでbuildし直して使う、というのは本来やるべきではないと思うが
$ wget https://raw.githubusercontent.com/docker-library/golang/master/1.3.1/go-wrapper
$ wget https://raw.githubusercontent.com/docker-library/golang/master/1.3.1/Dockerfile

$ docker build -t golang:1.3.1 .

通常コンパイル (Compile your app inside the Docker container)

  • 普通にgo buildする場合
    • -vカレントディレクトリ(=git cloneしたディレクトリ) と コンテナのGOPATH配下(/go配下) をマウント
    • -wでコンテナ側の作業ディレクトリを同じGOPATH配下にしており、ビルドの成果物はここに出力される =マウントしているサーバー側のカレントディレクトリに置かれる
$ docker run --rm -v "$(pwd)":/go/src/github.com/goldeneggg/ipcl -w /go/src/github.com/goldeneggg/ipcl golang:1.3.1 bash -c 'go get -d ./... && go build -v'

github.com/goldeneggg/ipcl/parser
github.com/goldeneggg/ipcl/writer
github.com/goldeneggg/ipcl
  • コンパイルで生成された実行ファイルをサーバー側で確認
$ ls ipcl
ipcl
  • Makefileを用意していてmakeを実行する場合
$ docker run --rm -v "$(pwd)":/go/src/github.com/goldeneggg/ipcl -w /go/src/github.com/goldeneggg/ipcl golang:1.3.1 make

go get github.com/jessevdk/go-flags
go test ./parser
ok      github.com/goldeneggg/ipcl/parser       0.004s
go build -o /ipcl

クロスコンパイル (Cross-compile your app inside the Docker container)

  • 通常コンパイルと異なるのは下記の2点
    • 使用するオフィシャルイメージはtagに-crossというsuffixの付いたもの
      • 通常コンパイル同様、ローカルでbuildして使う
        • これもベースイメージをローカルでbuildしたからであって、ローカルでbuildし直して使う のは本来やるべきではない
    • docker runの際に-eでプラットフォーム環境変数を指定する
      • GOOS
      • GOARCH
  • ベースとなっているgolang:1.3.1イメージをローカルでbuildしたので、golang:1.3.1-crossもローカルでbuildする
    • Dockerfileはこれ。go自体をクロスプラットフォームでbuildする処理を行っている
$ wget https://raw.githubusercontent.com/docker-library/golang/master/1.3.1/cross/Dockerfile
$ docker build -t golang:1.3.1-cross .
  • クロスコンパイル実行 (go buildで)
    • -eでプラットフォーム環境変数指定。例としてwindowsを
      • windowsを指定しているので実行ファイルは.exe形式で生成される
$ docker run --rm -v "$(pwd)":/go/src/github.com/goldeneggg/ipcl -w /go/src/github.com/goldeneggg/ipcl -e GOOS=windows -e GOARCH=386 golang:1.3.1-cross bash -c 'go get -d ./... && go build -v'

github.com/goldeneggg/ipcl/parser
github.com/goldeneggg/ipcl/writer
github.com/jessevdk/go-flags
github.com/goldeneggg/ipcl
  • コンパイルで生成された実行ファイルをサーバー側で確認
$ ls ipcl.exe
ipcl.exe
  • こんな感じのスクリプトを用意しとけば、複数プラットフォーム向けのクロスコンパイル → 実行ファイル取得 までを 常に同じGo環境を使って一括実施する ことができる
$ vi cross_compiles.sh
#!/bin/sh

PKG_PATH=$1
P=`basename ${PKG_PATH}`
PKG_NAME=${P%.*}

OS_S=("linux" "windows")
ARCH_S=("386" "amd64")

for os in ${OS_S[@]}
do
  for arch in ${ARCH_S[@]}
  do
    bin=${PKG_NAME}_${os}_${arch}
    if [ ${os} = "windows" ]
    then
        bin=${bin}.exe
    fi

    docker run --rm -v "$(pwd)":/go/src/${PKG_PATH} -w /go/src/${PKG_PATH} -e GOOS=${os} -e GOARCH=${arch} golang:1.3.1-cross bash -c "go get -d ./... && go build -o ${bin} -v"
  done
done
$ ./cross_compiles.sh github.com/goldeneggg/ipcl

github.com/goldeneggg/ipcl/parser
github.com/goldeneggg/ipcl/writer
github.com/jessevdk/go-flags
github.com/goldeneggg/ipcl
github.com/goldeneggg/ipcl/parser
github.com/goldeneggg/ipcl/writer
github.com/jessevdk/go-flags
github.com/goldeneggg/ipcl
github.com/goldeneggg/ipcl/parser
github.com/goldeneggg/ipcl/writer
github.com/jessevdk/go-flags
github.com/goldeneggg/ipcl
github.com/goldeneggg/ipcl/parser
github.com/goldeneggg/ipcl/writer
github.com/jessevdk/go-flags
github.com/goldeneggg/ipcl

$ ls ipcl*
ipcl_linux_386  ipcl_linux_amd64  ipcl_windows_386.exe  ipcl_windows_amd64.exe

所感

  • これまで言語の実行環境用イメージは自前でDockerfileを書いて用意していたが、「dockerの公式」という箔が付いたイメージが公開された事で、種々の作業について合意形成が行い易くなったと思う
    • イメージの内容について理解する必要がない。勉強して理解したい人だけがやればいい
    • イメージの内容を保証する必要がない
    • オレオレ文化の抑止効果
      • 個人・部署・会社を跨いだノウハウ共有のハードルが下がった
  • とはいえ、公式イメージも随時修正されるもの(という想定)で考えておかねばならないわけで、現場で公式イメージを使用する運用を行うのであれば「どの / いつ時点の commitのイメージを使用したか?」はチーム内で管理・共有しておくべきである気がする
    • 管理・共有が面倒であれば「社内では、ある時点で公式をforkして、docker buildし直したイメージを使うようにする」とか良しなにルールを決めるなり何なり