GoからDocker上のElasticsearchに接続する際にネットワークのSniffingでハマった

問題

Docker で Elasticsearch を起動します。

services:
  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.4.0
    environment:
      - discovery.type=single-node
    ports:
      - 9200:9200
      - 9300:9300

以下の Elasticsearch クライアントライブラリを利用し、http://127.0.0.1:9200へ接続しに行きます。

github.com

   c, err := elastic.NewClient() // デフォルトで127.0.0.1:9200へ接続
    if err != nil {
        log.Println(err)
    }

no active connection found: no Elasticsearch node availableとエラーとなり接続できません。

ちなみに以下では接続できます。

   res, err := http.Get("http://127.0.0.1:9200/?pretty=true")

解決策

以下のようにelastic.SetSniff(false)を引数に与えれば、 Docker 上の Elasticsearch に接続できます。

   c, err := elastic.NewClient(elastic.SetSniff(false))

1 時間以上これで時間を溶かしてしまいました。

原因

デフォルトではクライアントがクラスタの全ノードを自動的に見つけにいきそれらのノードにリクエストを投げる(Sniffing)が、それらのノードは外部からは直接アクセスできないため接続に失敗します。

127.0.0.1:9200以外からElasticsearchにアクセスできない

ここで取得されるノードとは具体的には以下のリクエストで取得されます。 この例では、172.18.0.3:9200にアクセスしにいくことになりますが、127.0.0.1:9200を通さないのでエラーになります。

$ curl http://localhost:9200/_nodes/http\?pretty\=true

  "nodes" : {
    "bzn5IyC2T3GJj_MGhdwyFQ" : {
      "transport_address" : "172.18.0.3:9300",
      "host" : "172.18.0.3",
      "ip" : "172.18.0.3",
      "build_type" : "docker",
      "http" : {
        "bound_address" : [
          "0.0.0.0:9200"
        ],
        "publish_address" : "172.18.0.3:9200",
        "max_content_length_in_bytes" : 104857600
      }

実際のコード

NewClientメソッド内の条件分岐です。 有効の場合、sniffメソッドが呼ばれます。

   if c.snifferEnabled {
        // Sniff the cluster initially
        if err := c.sniff(ctx, c.snifferTimeoutStartup); err != nil {
            return nil, err
        }
    } else {
        // Do not sniff the cluster initially. Use the provided URLs instead.
        for _, url := range c.urls {
            c.conns = append(c.conns, newConn(url, url))
        }
    }

sniffメソッド内ではノード情報を取得するsniffNodeメソッドがありここで Docker 外からは通信できないPublishAddressを取得することで今回の問題が発生しました。

func (c *Client) sniffNode(ctx context.Context, url string) []*conn {
    var nodes []*conn

    // Call the Nodes Info API at /_nodes/http
    req, err := NewRequest("GET", url+"/_nodes/http") // このリクエストでノード情報を取得する、ここで Docker 外部からアクセスできないURLを取得してしまう
    if err != nil {
        return nodes
    }

    // 略

    res, err := c.c.Do((*http.Request)(req).WithContext(ctx))
    if err != nil {
        return nodes
    }
    defer res.Body.Close()

    var info NodesInfoResponse
    if err := json.NewDecoder(res.Body).Decode(&info); err == nil {
        if len(info.Nodes) > 0 {
            for nodeID, node := range info.Nodes {
                if c.snifferCallback(node) {
                    if node.HTTP != nil && len(node.HTTP.PublishAddress) > 0 {
                        url := c.extractHostname(c.scheme, node.HTTP.PublishAddress) // ここでノード情報を取得している
                        if url != "" {
                            nodes = append(nodes, newConn(nodeID, url))
                        }
                    }
                }
            }
        }
    }
    return nodes
}

クライアントはolivere/elasticかelastic/go-elasticsearchか

スター数が最多であり、実際にelastic/go-elasticsearchより扱いやすかったのでこちらを採用しました。 ビルダーパターンでクエリを作成できるのがシンプルで分かりやすいです。 例えば、res, err := c.Search().Index(targetIndex).Query(multiMatchQuery).Size(1).Do(context.Background())のようにクエリを書けます。

参考

Sniffing · olivere/elastic Wiki · GitHub

Docker · olivere/elastic Wiki · GitHub

CI上でのマルチステージビルドにおけるキャッシュ活用の銀の弾丸を見つけたかもしれない(Buildx, BuildKit)

銀の弾丸

以下でキャッシュ活用、ビルド、Push をよしなに行ってくれます。

$ docker login -u $DOCKERHUB_USER -p $DOCKERHUB_PASS # Docker Hub や ECR にログイン
$ export DOCKER_CLI_EXPERIMENTAL=enabled # Buildxを有効にする
$ docker buildx create --use --driver docker-container # ビルダーを作成(これがないと--pushオプションが使えない)
$ docker buildx build \
    --tag $IMAGE:latest \ # タグを付与
    --cache-from type=registry,ref=$IMAGE:cache \ # キャッシュのPull先を指定(レジストリを指定)
    --cache-to type=registry,ref=$IMAGE:cache,mode=max \ # キャッシュのPush先を指定(レジストリを指定)、mode=maxにより中間イメージのキャッシュも含める
    --push \ # 最終イメージのPushも行う
    .

はじめに

これまで、CI でのマルチステージビルドのキャッシュ活用についてさまざまな記事を書いてきました。

キャッシュのためにDockerビルドで中間イメージをタグ付けしレジストリにPushする - 🤖

GitHub Actionsを例にCI環境でのマルチステージビルドのキャッシュの活用について🐳 - 🤖

これらでは中間ステージのキャッシュに苦労しました。 各々のステージにタグを付与し各々のステージを Push していて、面倒くさいし可読性が低くなっていました。

Buildxのドキュメントを読む機会があり、簡単にマルチステージビルドでキャッシュを活用できるようでした。 この機能はDocker 19.03 から利用可能です。

github.com

Buildx とは

Docker Buildx は Docker コマンドを拡張する CLI プラグインであり、Moby BuildKit ビルダーツールキットにより提供される機能に完全対応するものです。 Docker ビルドと同様のユーザー操作を提供し、さらにスコープ化されたビルダーインスタンス、複数ノードへの同時ビルドなど、数多くの新機能を提供します。

元々、Docker には BuildKit の一部の機能は含まれていました。 しかし、Buildx を利用することで、BuildKit の全ての機能を利用できます。 Buildx がbuildkitdという BuildKit デーモンをコンテナで立ち上げてそこでビルドを行うことで実現しています。

Buildx なしで BuildKit を使おうとすると、--cache-fromオプションは利用できましたが--cache-toオプションは利用できませんでした。 Buildx を利用すると、--cache-to type=registry,ref=$IMAGE:cache,mode=maxと書くことで中間ステージのキャッシュも含めて外部レジストリに Push できます。

以下でキャッシュ活用、ビルド、Push をよしなに行ってくれます。

$ docker login -u $DOCKERHUB_USER -p $DOCKERHUB_PASS # Docker Hub や ECR にログイン
$ export DOCKER_CLI_EXPERIMENTAL=enabled # Buildxを有効にする
$ docker buildx create --use # ビルダーを作成(これがないと--pushオプションが使えない)
$ docker buildx build \
    --tag $IMAGE:latest \ # タグを付与
    --cache-from type=registry,ref=$IMAGE:cache \ # キャッシュのPull先を指定(レジストリを指定)
    --cache-to type=registry,ref=$IMAGE:cache,mode=max \ # キャッシュのPush先を指定(レジストリを指定)、mode=maxにより中間イメージのキャッシュも含める
    --push \ # 最終イメージのPushも行う
    .

実際に GitHub Actions で使用している例は以下のようになります。

github.com

GitHub Actions ではこれで Buildx を利用できましたが、 AWS CodeBuild では Buildx を使えませんでした。 以下のようにして、CLI プラグインを導入する必要がありました。

$ export DOCKER_BUILDKIT=1
$ docker build --platform=local -o . git://github.com/docker/buildx
$ mkdir -p ~/.docker/cli-plugins
$ mv buildx ~/.docker/cli-plugins/docker-buildx

この処理によるオーバーヘッドが大きいので、AWS CodeBuild では Buildx を使うのは微妙ですね。

github.com

CodeBuild のベースイメージに最初から Buildx 加えればいいのではと思いましたが、

Unfortunately, we won't be adding any experimental features.

と言われました。

参考

docs.docker.com

qiita.com

roy-n-roy.github.io

Dockerfileを書かずにBuildpacksで圧倒的に軽量なDockerイメージを作成する(539MB->245MB)

はじめに

2018 年 10 月に Cloud Native Buildpacks は Cloud Native Computing Foundation (CNCF)に Sandbox として受け入れられました。 CNCF には Kubernetes, Prometheus, Envoy, Fluentd など有名プロジェクトも多く受け入れられています。 Buildpacks を使うことで、Dockerfile を書かなくても Docker イメージを作成できます。 また、作成されるイメージはかなり軽量でした。

buildpacks.io

試してみた

今回は、以下のリポジトリの Java アプリケーションの Docker イメージを作成します。 github.com

インストール

# Mac
$ brew install buildpacks/tap/pack

# Linux
$ wget https://github.com/buildpacks/pack/releases/download/v0.12.0/pack-v0.12.0-linux.tgz
$ tar xvf pack-v0.12.0-linux.tgz
$ rm pack-v0.12.0-linux.tgz
$ ./pack --help

# Windows
$ choco install pack --version=0.12.0

チュートリアルにある例 (301MB)

pack build <image-name>でイメージを作成します。 301MB のイメージが作成されました。 docker runでアプリケーションを起動できました。

$ pack build myapp --builder cnbs/sample-builder:bionic
$ docker run -it -p 8080:8080 myapp:latest

ビルダーを--builderで指定します。 他にもさまざまなビルダーを選択できます。

Suggested builders:
    Google:                gcr.io/buildpacks/builder:v1                 Ubuntu 18 base image with buildpacks for .NET, Go, Java, Node.js, and Python
    Heroku:                heroku/buildpacks:18                         heroku-18 base image with buildpacks for Ruby, Java, Node.js, Python, Golang, & PHP
    Paketo Buildpacks:     gcr.io/paketo-buildpacks/builder:base        Ubuntu bionic base image with buildpacks for Java, NodeJS and Golang
    Paketo Buildpacks:     gcr.io/paketo-buildpacks/builder:full-cf     cflinuxfs3 base image with buildpacks for Java, .NET, NodeJS, Golang, PHP, HTTPD and NGINX
    Paketo Buildpacks:     gcr.io/paketo-buildpacks/builder:tiny        Tiny base image (bionic build image, distroless run image) with buildpacks for Golang

spring-boot(2.3.0) からの新機能 (245MB)

github.com

Java 限定の話になりますが、Spring Boot 2.3.0 から Buildpacks を内部的に使っている機能が組み込まれました。 mvn spring-boot:build-imageで Docker イメージを作成できます。

pom.xmlを編集してビルドするプロジェクトの Spring Bootのバージョンを 2.3.0 以上へアップデートします。

 <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.3.0.RELEASE</version>
        <relativePath/> <!-- lookup parent from repository -->
    </parent>

mvn spring-boot:build-imageでビルドできます。 245MBと最も軽量なイメージが作成されました。 docker runでアプリケーションを起動できました。

$ mvn spring-boot:build-image
$ docker run -it -p 8080:8080 sample:0.0.1-SNAPSHOT

自分で Doker Build (539MB)

自分で Dockerfile を書く方法です。 マルチステージビルドを利用してビルドしても、他より重い539MB でした。

FROM maven:3.6.3-jdk-8 as builder

WORKDIR /apps/java-maven

COPY pom.xml pom.xml
RUN mvn dependency:resolve

COPY src src
RUN mvn package -DskipTests=true

FROM openjdk:8

WORKDIR /apps/java-maven
COPY --from=builder /apps/java-maven/target/sample-0.0.1-SNAPSHOT.jar /apps/java-maven/target/sample-0.0.1-SNAPSHOT.jar
ENTRYPOINT ["java", "-jar", "/apps/java-maven/target/sample-0.0.1-SNAPSHOT.jar"]
EXPOSE 8080

通常通り、以下のコマンドでビルドしてアプリケーションを起動します。

$ docker build -t self-build .
$ docker run -it -p 8080:8080 self-build:latest

おわりに

本記事では Java での例でしたが、Go,Node,Ruby,PHP,Python などであればビルドできます。 pack build <image-name> --builder gcr.io/paketo-buildpacks/builder:tinyなどのコマンドで言語にあったビルダーを指定すればビルドできます。

自分で Docker ビルドをする場合はイメージは 539MB でしたが、Buildpacks を利用すれば Dockerfile を書かなくてもすむ上にイメージは 245MB になりました。

なんで小さくなるかはdiveで深掘りしたり、ドキュメント読んだりしてまた記事にしますか

— kotaroooo0 (@kotaroooo0) 2020年8月16日

Docker で立てた CI で Docker Build する -Docker in Docker と /var/run/docker.sock

はじめに

CI では毎回まっさらな環境でテストやビルドができます。 これには、多くは Docker が用いられています。 さらには、Docker で実現されたまっさらな環境でも Docker ビルドなど Docker を利用できます。

前提知識: Docker クライアントと dockerd

dockerクライアントとdockerd

アーキテクチャの理解 — Docker-docs-ja 1.11.0 ドキュメント

Docker コマンドとdockerdは別物で、API クライアントと API サーバーのような関係です。 dockerdは、Docker デーモンのことです。

例えば、Docker for Mac ではこのようなイメージです。 Docker は Linux カーネルを必要とするため、Mac 単体では動きません。 そこで、HyperKit を使い VM 上に LinuxKit を立ち上げています。 Mac のターミナルから、LinuxKit の dockerd に命令を送っています。

Docker for Mac

CI では Docker コンテナで Docker コマンドを使う

EC2 上で Docker により Jenkins を動かす時などでは Docker コンテナ内で Docker コマンドを使う必要があります。 docker build でイメージをビルドして、docker push でレジストリにイメージをプッシュすることが多々あります。 どのようにコンテナ上で Docker を利用するべきでしょうか。

docker in docker

docker in docker は以下のようなイメージです。

docker in docker は元々、Docker の開発自体のために作られました。 Docker インストール済みのコンテナを使用しコンテナ内でホストとは別に dockerd を動かす方法です。 dindと一般的に呼ばれています。

$ docker run --privileged --name dind -d docker:dind

--privileged オプションにより、コンテナ内からホストのリソースを扱える権利を持たせます。

GOOD

• ホストの Docker とは完全に別物の Docker 環境が利用可能

BAD

• -privilegedを使う必要があり脆弱性があります
• /var/lib/dockerをマウントするので Data Volume がファイルが溜まっていきます
• CI が再ビルドを行う時、dind コンテナを再起動するたびにそのキャッシュを無効になります

/var/run/docker.sockをマウント

ホストの dockerd のソケットファイルをマウントして、そこに処理をリクエストします。 イメージは以下です。

Docker out of Docker(dood)と呼ばれます。

GOOD

• dockerd はホストのものを使うので、毎回同じでありキャッシュが利用できます
• ディスクスペースを節約できます

BAD

• ホストで動いている他のコンテナも見えます(完全に独立していない)
• ホストマシンのルートを取れます

$ docker run -t -i -v /var/run/docker.sock:/var/run/docker.sock debian:jessie /bin/bash
$ apt-get update && apt-get install wget -y && wget -qO- https://get.docker.com | sh
$ docker images # ホストのイメージが表示される
$ docker run -t -i -v /:/host debian:jessie /bin/bash
$ chroot /host # ホストのルートが取れる

どっちを使うべき

EC2などで自分でCIを構成する場合は、doodを使うのが好ましいです。 また、GitHub ActionsなどカスタマにCIを提供する場合では、dindが好ましいです。

参照

jpetazzo.github.io

toris.io

rimuru.lunanet.gr.jp

キャッシュのためにDockerビルドで中間イメージをタグ付けしレジストリにPushする

WHY: なぜ中間イメージをタグ付けするのか

今では Docker イメージの軽量化のためにマルチステージビルドは欠かせません。 ローカルでの実行では問題ありませんが、CI 環境などの dockerd が毎度変わる Docker In Docker(dind)では問題が起こります。

最終イメージの中にビルドプロセスの全てが含まれていれば 1 Dockerfile 1 Cache で単純な--cache-from を指定するだけで良いです。 マルチステージビルドは最終イメージの軽量化が目的であるため、最終イメージにキャッシュすべき情報はほとんど含まれておらずキャッシュしても無意味です。 キャッシュしたいステージを明示的に--targetで指定して、ビルドされたイメージを外部に保存する必要があります。

例えば、以下の Dockerfile を考えます。 stage1とstage2は、キャッシュしたいです。

FROM alpine:latest as stage1
LABEL stage=1
WORKDIR /workdir
RUN sleep 3 && touch stage1.txt


FROM alpine:latest as stage2
LABEL stage=2
WORKDIR /workdir
RUN sleep 6 && touch stage2.txt

COPY --from=stage1 /workdir/stage1.txt /workdir/stage1.txt

FROM alpine:latest as stage3
LABEL stage=3
WORKDIR /workdir
COPY --from=stage1 /workdir/stage1.txt /workdir/stage1.txt
COPY --from=stage2 /workdir/stage2.txt /workdir/stage2.txt

HOW: どう中間イメージをタグ付けするのか

BuildKit を使ってビルドする場合とそうでない場合でやり方が異なります。 また、最終ステージにはCOPYのみのため、キャッシュを利用しません。

BuildKit なし

DockerfileでLABELを使いラベル付けし、docker imagesで--filterオプションを使うことタグ付したいイメージを取得できます。 LABEL stage=1のステージを取得するには、$(docker images --filter 'label=stage=1' -q | head -n 1)とすれば良いです。

export DOCKER_BUILDKIT=0

# キャッシュのためにPull
# &とwaitで並列実行
docker pull test:stage1 || true &
docker pull test:stage2 || true &
wait

# ビルドする
docker build --cache-from= .

# 中間イメージにタグ付けする
docker tag $(docker images --filter 'label=stage=1' -q | head -n 1) test:stage1
docker tag $(docker images --filter 'label=stage=2' -q | head -n 1) test:stage2

# キャッシュのためにPush
# &とwaitで並列実行
docker push test:latest &
docker push test:stage1 &
docker push test:stage2 &
wait

他の選択肢

このようにしてもできます。 キャッシュが効くのでタグ付けのためのビルドはすぐ終わるとはいえ、上のやり方の方が早いので良いです。

# ビルドする
docker build -t test:latest .

# 中間イメージにタグ付けする
docker build -t test:stage1 --target stage1 --cache-from test:stage1 .
docker build -t test:stage2 --target stage2 --cache-from test:stage2 .

BuildKit あり

最近では、BuildKit を使ってビルドするのが当たり前になっています。 BuildKit ではDockerfileをパースしステージ間の依存関係を解釈するためstage1とstage2を並列にビルドでき、ビルド時間の短縮につながります。

しかし、BuildKit を使ったビルドでは中間イメージが生成されません。 docker imagesしても、最終イメージしか表示されません。 理由は分かりませんが、容量を圧迫しないようにあえてそうしているのでしょうか。

そのため、BuildKit なしの場合のように、docker tagによるタグ付けができません。 したがって、個別にビルドすることによってタグ付けします。

export DOCKER_BUILDKIT=1

# ビルドする
docker build -t test:latest --cache-from=test:stage1,test:stage2 --build-arg BUILDKIT_INLINE_CACHE=1  .

# 中間イメージにタグ付けする
# &とwaitで並列実行
docker build -t test:stage1 --target stage1 --cache-from test:stage1 --build-arg BUILDKIT_INLINE_CACHE=1  . &
docker build -t test:stage2 --target stage2 --cache-from test:stage2 --build-arg BUILDKIT_INLINE_CACHE=1  . &
wait

# キャッシュのためにPush
# &とwaitで並列実行
docker push test:latest &
docker push test:stage1 &
docker push test:stage2 &
wait

--cache-fromはまずレジストリからメタデータのみを取得し、キャッシュヒットの可能性があるレイヤーのみを Pull します。

docs.docker.com

BuildKit で最終ステージまでビルドしてから個別にステージをビルドすると一番無駄が少ないです。

ツールを使うことで簡単にビルドスクリプトを生成できます。 最終ステージをキャッシュするかどうかなど細かいチューニングは人の手で行ってください。

github.com

$ go get -u github.com/kotaroooo0/melancholy
$ melancholy -i image_name
# ----- Build image -----
docker build -t image_name:latest --cache-from=image_name:stage1,image_name:stage2,image_name:latest --build-arg BUILDKIT_INLINE_CACHE=1 .
# ----- Attach tags -----
docker build -t image_name:stage1 --target=stage1 --build-arg BUILDKIT_INLINE_CACHE=1 . &
docker build -t image_name:stage2 --target=stage2 --build-arg BUILDKIT_INLINE_CACHE=1 . &
wait
# ----- Push images -----
docker push image_name:stage1 &
docker push image_name:stage2 &
docker push image_name:latest &
wait

Dockerイメージ分析ツール「dive」を利用してDockerイメージを軽量化する

はじめに

Docker イメージサイズは小さければ小さいほど、Push と Pull の高速化につながり嬉しいです。 docker historyによってイメージレイヤーごとのサイズは分かりますが、どのレイヤーのどのファイルのサイズが大きいかは分かりません。

$ docker history maven:3-amazoncorretto-11
IMAGE               CREATED             CREATED BY                                      SIZE                COMMENT
eb8a5bbcd061        12 days ago         /bin/sh -c #(nop)  CMD ["mvn"]                  0B
<missing>           12 days ago         /bin/sh -c #(nop)  ENTRYPOINT ["/usr/local/b…   0B
<missing>           12 days ago         /bin/sh -c #(nop) COPY file:2bbb488dd73c55d6…   327B
<missing>           12 days ago         /bin/sh -c #(nop) COPY file:1b3da5c58894f705…   1.65kB
<missing>           12 days ago         /bin/sh -c #(nop)  ENV MAVEN_CONFIG=/root/.m2   0B
<missing>           12 days ago         /bin/sh -c #(nop)  ENV MAVEN_HOME=/usr/share…   0B
<missing>           12 days ago         |4 BASE_URL=https://apache.osuosl.org/maven/…   11.3MB
<missing>           12 days ago         |4 BASE_URL=https://apache.osuosl.org/maven/…   200MB
<missing>           12 days ago         /bin/sh -c #(nop)  ARG BASE_URL=https://apac…   0B
<missing>           12 days ago         /bin/sh -c #(nop)  ARG SHA=c35a1803a6e70a126…   0B
<missing>           12 days ago         /bin/sh -c #(nop)  ARG USER_HOME_DIR=/root      0B
<missing>           12 days ago         /bin/sh -c #(nop)  ARG MAVEN_VERSION=3.6.3      0B
<missing>           12 days ago         /bin/sh -c #(nop)  ENV JAVA_HOME=/usr/lib/jv…   0B
<missing>           12 days ago         /bin/sh -c #(nop)  ENV LANG=C.UTF-8             0B
<missing>           12 days ago         |1 version=11.0.8.10-1 /bin/sh -c set -eux  …   279MB
<missing>           12 days ago         /bin/sh -c #(nop)  ARG version=11.0.8.10-1      0B
<missing>           3 weeks ago         /bin/sh -c #(nop)  CMD ["/bin/bash"]            0B
<missing>           3 weeks ago         /bin/sh -c #(nop) ADD file:788af9048b1c16334…   163MB

dive

A tool for exploring a docker image, layer contents, and discovering ways to shrink the size of your Docker/OCI image.

このツールでは、レイヤーごとにどのファイルが追加・削除されたのか、どれくらいのサイズなのかが分かります。 Go で書かれていて、20000 スターくらいついています。

github.com

インストール

# brewでインストール
$ brew install dive

# go getでインストール
$ go get github.com/wagoodman/dive

Dockerでも実行できたり他のインストール方法もREADMEに書いてあります。

使い方

# Analyze
$ dive <your-image-tag>

# Build & Analyze
$ dive build -t <some-tag> .

以上のコマンドでツールが起動します。 ターミナル上であれこれできるのをTUIというようです。

dive で軽量化

今回は、maven:3-amazoncorretto-11を軽量化します。 dive の実際の使い方を紹介しながら説明します。

github.com

まず、上のリポジトリのdocker-maven/amazoncorretto-11/Dockerfileをビルドし、diveを起動します。

$ docker build -t before-maven-amazoncorretto-11 .
$ dive before-maven-amazoncorretto-11

dive起動時の画面

いきなり画面にたくさん表示されて最初は訳がわからないと思います。

• 画面左上Layers:どのレイヤーまでを調査するか選択
• 画面左中Layer Details: そのレイヤーでなにを実行しているかを表示
• 画面左下Image Details: イメージ全体の情報を表示
• 画面右Current Layer Contents: Layersで指定したレイヤーに含まれているファイルツリーをサイズと共に表示

TabでLayersとCurrent Layer Contentsを移動しながら使います。 最初はディレクトリが開かれていて画面右にファイルがたくさん表示されて見づらいので、Spaceでディレクトリ閉じていきます。 ^Spaceで一気に閉じられるようですが、Mac のショートカットと衝突して使えませんでした。

画面右はディレクトリを閉じるとスッキリ

見やすくなりました。 Layersで上下に移動すると、それに対応してCurrent Layer Contentsも変化しディレクトリやファイズのサイズの変化が分かります。

Layersを確認すると、サイズ大きく増えるボトルネックとなりうるレイヤーは上から 3 つと分かります。 上から1 番目と 2 番目のレイヤーはAmazon Linux の/usrと amazoncorretto の/usr/lib/jvmの追加であり、これはベースイメージなので改善できません。

上から3 番目レイヤーでは、/var/cache/yumが 82B から 195MB へ増加しました。 このレイヤー全体のサイズは 206MB なので、ほとんどが/var/cache/yumと分かります。 黄色は選択したレイヤーによってサイズが変わった部分を表しています。

/var/cache/yumのサイズが増加

このレイヤーではyum install -y tar which gzipが実行されています。 これらのコマンドは実行できれば問題ないので 195MB の膨大なキャッシュは不要です。

このように dive を利用することで不要なファイルを発見することができました。 あとは、Dockerfile 上で不要なファイルを削除すれば完了です。

RUN yum install -y tar which gzip \
  && rm -rf /var/cache/yum/* \
  && yum clean all

このようにすれば、キャッシュは削除できます。 &&でつなげないと余計なレイヤーが追加されるだけで軽量化には繋がりません。

元々のイメージサイズは 659MB でしたが、変更後は 464MB に削減することができました。 ちょうど、/var/cache/yumの 195MB 分です。

ここでの修正はプルリクエストとして出してマージされました。 github.com

Mavenの公式DockerイメージにコントリビュートしてOSSデビューした、嬉しい https://t.co/RxBbrRem5f

— kotaroooo0 (@kotaroooo0) 2020年7月28日

おわりに

diveによってレイヤーのディレクトリごと、ファイルごとにサイズの変化を観察することができました。 かなり強力なツールだなと感じました。 欲を言うなら、名前順でソートではなくサイズ順でソートできるようになったり、^Space でなく違うコマンドでディレクトリが畳めたら嬉しいと思いました。

また、コマンドによってどんなファイルが生成されるか分かりやすいため、パッケージマネージャのコマンドがなにをしているかも理解が進むという嬉しい副作用もありました。

今回は dive を使うのが半分目的だったのでdive -> Dockerfileの順で見たのですが、Dockerfile -> diveの順で見ればyum installのキャッシュを削除すればよさそうだなと当たりをつけることができたかもしれません。 まさか、公式Dockerイメージにこんなにシンプルな修正箇所が残っているとは思いませんでした。 偶然にもOSSへ貢献することができラッキーでした。

過去に書いた Docker ビルド関係の記事

GitHub Actionsを例にCI環境でのマルチステージビルドのキャッシュの活用について🐳 - 🤖

GitHub ActionsでのDockerビルドをキャッシュで高速化する - 🤖

Dockerfileを正しく書けるように指摘してくれる静的解析ツール「hadolint」 - 🤖

Dockerイメージのビルドで使うキャッシュの種類(レイヤーキャッシュ, BuildKit, CI) - 🤖

DockerイメージのビルドをBuildKitで並列実行し高速化する - 🤖

Go製CLIツールを使うDockerイメージをダイエットしてみた - 🤖

GitHub Actionsを例にCI環境でのマルチステージビルドのキャッシュの活用について🐳

はじめに

以前、CI 環境での Docker ビルドのキャッシュについて記事を書きました。

kotaroooo0-dev.hatenablog.com

前回の記事のようにマルチステージビルドでない場合は、1 Dockerfile 1 Cache で問題ありませんでした。 しかし、今では Docker イメージの軽量化のためにマルチステージビルドは欠かせません。 ローカルでの実行では問題ありませんが、dockerd が毎度変わる CI 環境や Docker In Docker(dind)では問題が起こります。

最終イメージの中にビルドプロセスの全てが含まれていれば 1 Dockerfile 1 Cache で単純な--cache-fromを指定するだけで良いです。 マルチステージビルドは最終イメージの軽量化が目的であるため、最終イメージにキャッシュすべき情報はほとんど含まれておらずキャッシュしても無意味です。 キャッシュしたいステージを明示的に--targetで指定して、ビルドされたイメージを外部に保存する必要があります。

マルチステージビルドになるとキャッシュが難しくなります。

試す選択肢

1.普通のdocker build🐭

キャッシュが効かない普通のdocker build .です。 GitHub Actions は毎回 dockerd が変わりステートレスなのでこのままではレイヤーキャッシュは効きません。

2.普通のdocker build + BuildKit🐶

🐭 と同様ですが、BuildKit を効かせます。 環境変数にDOCKER_BUILDKIT=1をセットしdocker build .するだけです。

3.actions/cache + docker save & load 🦊

GitHub Actions では、actions/cache を使うことでキャッシュできます。 また、docker save とdocker loadにより、イメージを tar 形式のファイルにセーブしたりロードできます。

docs.docker.jp

4.外部レジストリのキャッシュdocker build --cache-from🐷

これは外部キャッシュです。 今回は Docker Hub ですが、AWS の ECR などへも同様にキャッシュできます。 これによりレイヤーキャッシュが効きます。 --build-arg BUILDKIT_INLINE_CACHE=1のオプションも必須です。

ビルダーはレジストリからメタデータのみを取得し、キャッシュヒットの可能性があるレイヤーのみを pull します。 そのため、事前にdocker pullをする必要はありません。

docs.docker.com

試してみた

以下の Dockerfile で今回は試してみました。 前半の builder ステージで Go のソースコードからバイナリを生成して、最終イメージにバイナリをコピーしています。

FROM golang:1.14-alpine as builder

WORKDIR /go/src/github.com/kotaroooo0/snowforecast-twitter-bot/app

COPY go.mod go.sum ./
RUN go mod download

COPY . .
RUN go build -o main

FROM alpine:latest

COPY --from=builder /go/src/github.com/kotaroooo0/snowforecast-twitter-bot/app/main /main
COPY .env /

EXPOSE 3000

ENTRYPOINT ["/main"]

1. 普通のdocker build 🐭

.envファイルを作成しているのはアプリケーションに必要なためであり、本質的には関係ありません。

  build_no_cache:
    runs-on: ubuntu-18.04
    steps:
      - uses: actions/checkout@master
      - name: Create .env file
        run: echo "${{ secrets.GITHUBACTION_ENV }}" > .env
      - name: Build
        run: docker build .

48 秒でした。 https://github.com/kotaroooo0/snowforecast-twitter-bot/runs/886546983?check_suite_focus=true

2. 普通のdocker build + BuildKit 🐶

DOCKER_BUILDKIT: 1とすると、BuildKit が有効になります。

  build_no_cache_buildkit:
    runs-on: ubuntu-18.04
    steps:
      - uses: actions/checkout@master
      - name: Create .env file
        run: echo "${{ secrets.GITHUBACTION_ENV }}" > .env
      - name: Build
        env:
          DOCKER_BUILDKIT: 1
        run: docker build .

31 秒でした。 https://github.com/kotaroooo0/snowforecast-twitter-bot/runs/886567325?check_suite_focus=true

3.actions/cache + docker save & load 🦊

 build_with_docker_save_load:
   runs-on: ubuntu-18.04
   steps:
   - uses: actions/checkout@master
   - name: Create .env file
     run: echo "${{ secrets.GITHUBACTION_ENV }}" > .env
   # actions/cacheを使うためにpathとkeyを指定
   - id: docker-cache-step
     uses: actions/cache@v1
     with:
       path: /tmp/saveload-cache
       key: docker-saveload-${{ hashFiles('Dockerfile') }}
   # キャッシュがあるならdocker loadでイメージを取得
   - run: docker load -i /tmp/saveload-cache/go-builder.tar || true
     if: steps.docker-cache-step.outputs.cache-hit == 'true'
   # のちにdocker saveしたいため中間イメージのみをビルド
   # --cache-from=thing-cacheによりdocker loadで読み込んだものをキャッシュとして利用
   - run: docker build . -t thing --target builder --cache-from=thing-cache
   # 最終イメージをビルド
   # 中間イメージをすでにビルドしているのでキャッシュは効く
   - run: docker build . --cache-from=thing-cache
   # 中間イメージをdocker saveで保存
   - run: docker tag thing thing-cache && mkdir -p /tmp/saveload-cache && docker save thing-cache -o /tmp/saveload-cache/go-builder.tar && ls -lh /tmp/saveload-cache || true
     if: always() && steps.docker-cache-step.outputs.cache-hit != 'true'

キャッシュがヒットしない 1 回目は 1 分 8 秒でした。 加えて、キャッシュを保存するのにさらに 45 秒かかりました。 https://github.com/kotaroooo0/snowforecast-twitter-bot/runs/909479280?check_suite_focus=true

キャッシュがフルでヒットする場合は 13 秒でした。 加えて、キャッシュの復元に 33 秒かかりました。 https://github.com/kotaroooo0/snowforecast-twitter-bot/runs/909484937

キャッシュが一部ヒットするような変更(main.goの修正など)をした場合にどれだけ時間が短縮できるか調べました。 ビルド自体は 39 秒でした。 加えて、キャッシュの復元に 35 秒かかりました。 https://github.com/kotaroooo0/snowforecast-twitter-bot/runs/909488577?check_suite_focus=true

4.外部レジストリのキャッシュ docker build --cache-from 🐷

  cache-from-with-build-arg:
    runs-on: ubuntu-18.04
    steps:
    - uses: actions/checkout@master
    - name: Create .env file
      run: echo "${{ secrets.GITHUBACTION_ENV }}" > .env
    - name: login
      run: docker login -u $DOCKERHUB_USER -p $DOCKERHUB_PASS
    # 最終イメージはビルドプロセスのキャッシュを含んでいないため、中間イメージをビルドしてプッシュ
    - name: build builder image
      run: docker build --target builder --cache-from $IMAGE:builder --tag $IMAGE:builder --build-arg BUILDKIT_INLINE_CACHE=1 .
    - name: build image
      run: docker build --cache-from $IMAGE:builder --cache-from $IMAGE:latest --tag $IMAGE:latest --build-arg BUILDKIT_INLINE_CACHE=1 .
    # &とwaitで並列実行
    - name: push image
      run: |
        docker push $IMAGE:builder &
        docker push $IMAGE:latest &
        wait

キャッシュがヒットしない 1 回目は 35 秒でした。 加えて、キャッシュを保存するのにさらに 6 秒かかりました。 https://github.com/kotaroooo0/snowforecast-twitter-bot/runs/897778413

キャッシュがフルでヒットする場合は 24 秒でした。 加えて、キャッシュを保存するのにさらに 5 秒かかりました。 https://github.com/kotaroooo0/snowforecast-twitter-bot/runs/897795622

キャッシュが一部ヒットするような変更(main.goの修正など)をした場合にどれだけ時間が短縮できるか調べました。 ビルド自体は 36 秒でした。 加えて、キャッシュの保存に 9 秒かかりました。 https://github.com/kotaroooo0/snowforecast-twitter-bot/runs/897844111?check_suite_focus=true

まとめ

🐷 でキャッシュがフルヒットする場合が最速ですがこのようなことは稀であるので、キャッシュを無理に使わずに BuildKit でビルド 🐶 するのが安定して高速であり実用的です。 中間イメージのキャッシュを効かせる 🦊🐷 が時間がかかってしまったのは、中間イメージのサイズが大きくdocker save や docker load、docker pull や docker push に時間がかかってしまうためだと考えられます。 中間イメージは 200MB 程度、成果物である最終イメージは 10MB 程度です。 キャッシュを効かせる準備をするより、BuildKit でさっさとビルドする方が良いということです。 YAML もすっきりしていて良いです。

GCP の CloudBuild であれば、Google 製のコンテナ内で動くコンテナビルダーの kaniko が簡単に使えるそうで良さそうです。 kaniko なら、マルチステージビルドだろうとなんだろうとキャッシュのことを考えずにいい感じにビルドしてくれます。 GitHub Actions でも利用できるようようなので試してみたいです。

github.com

CI 上でのマルチステージビルドのキャッシュは難しいです。

過去に書いた Docker ビルド関係の記事

GitHub ActionsでのDockerビルドをキャッシュで高速化する - 🤖

Go製CLIツールを使うDockerイメージをダイエットしてみた - 🤖

DockerイメージのビルドをBuildKitで並列実行し高速化する - 🤖

Dockerイメージのビルドで使うキャッシュの種類(レイヤーキャッシュ, BuildKit, CI) - 🤖

Dockerfileを正しく書けるように指摘してくれる静的解析ツール「hadolint」 - 🤖