尝试使用Go官方的docker镜像

2 年 ago
宇, 华
5 minutes

Go的官方docker镜像是什么？

    • これの事 : golang Repository | Docker Hub Registry – Repositories of Docker Images

アナウンス記事 : Docker Hub Official Repos: Announcing Language Stacks | Docker Blog

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

用法示例

在你的应用程序中启动一个Go实例作为执行环境。

尝试在官方镜像容器中运行使用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のCMDをENTRYPOINTにすれば良い

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 build や make してみる

-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 .

通常情况下，在Docker容器中编译您的应用程序。

    • 普通に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

在Docker容器中进行交叉编译您的应用程序

    • 通常コンパイルと異なるのは下記の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し直したイメージを使うようにする」とか良しなにルールを決めるなり何なり

✖
广告
将在 10 秒后关闭
bannerAds