この記事はなに

タイトル通り。
主にsbt-native-packagerのとりあえずの使い方紹介。
Akka-HTTPでWebアプリを実装し、sbt-native-packagerを使ってDockerイメージを作成、localhostで稼働させてHTTPリクエストを受け付けられるようにするまで。

環境

Scala 2.12.4
sbt 1.0.4
Akka-HTTP 10.0.10
sbt-native-packager 1.3.3

ScalaのWebアプリ

build.sbtにはAkka-HTTPの依存を追加しておく。

libraryDependencies += "com.typesafe.akka" %% "akka-http" % "10.0.10",

続いて動かすmainクラスの実装。
実装自体は何でもよいので、シンプルに。

import akka.actor.ActorSystem
import akka.event.Logging
import akka.http.scaladsl.Http
import akka.http.scaladsl.server._
import akka.stream.ActorMaterializer

import scala.concurrent.Await
import scala.concurrent.duration.Duration

object main extends App with Directives {
  implicit val system: ActorSystem = ActorSystem("my-sample-app")
  implicit val materializer: ActorMaterializer = ActorMaterializer()

  // GET /indexでリクエストのURLパラメータとUserAgentを返却する
  val route: Route =
    (get & pathPrefix("index") & extractUri & headerValueByName("User-Agent")) {
      (uri, ua) =>
        logRequestResult("/index", Logging.InfoLevel) {
          complete(s"param: ${uri.query().toMap}, user-agent: ${ua}}")
        }
    }
    
  val host = sys.props.get("http.host") getOrElse "0.0.0.0"
  val port = sys.props.get("http.port").fold(8080) { _.toInt }

  val f = Http().bindAndHandle(route, host, port)

  println(s"server at [$host:$port]")

  Await.ready(f, Duration.Inf)
}

Akka-HTTPのHttp().bindAndHandleした結果をAwait.readyで無限に待つ。
簡単に動かすだけならこれでよい。
sbt runすれば起動するはず。

build.sbtにdockerizeの設定を書く

まずはproject/plugins.sbtに以下を書く

// https://github.com/sbt/sbt-native-packager
addSbtPlugin("com.typesafe.sbt" % "sbt-native-packager" % "1.3.3")

続いてbuild.sbtに以下のように設定を記述する

enablePlugins(JavaAppPackaging)
// enablePlugins(JavaServerAppPackaging) // どっちでも動く

// Dockerfileに書く内容
packageName in Docker := "sample-webapp"
version in Docker := "1.0"
dockerRepository := Some("petitviolet")
maintainer in Docker := "petitviolet <mail@example.com>"
dockerExposedPorts := List(8080)
dockerBaseImage := "openjdk:latest"
dockerCmd := Nil

Dockerfileを書いたことがあれば何となくわかるはず。
in Dockerって書くかどうかが若干難しいが、dockerXxxなら不要でそうじゃないなら必要、くらいでよいはず(間違ってたら指摘して欲しいです)。

これでpetitviolet/sample-webapp:1.0としてイメージを作ることが出来る。

Dockerイメージを作る

sbtでコマンドを実行するだけで良い

sbt 'project main' 'docker:publishLocal'

docker:publishLocalでdocker buildしてくれる。
結果を見るにはdocker imagesすればいい。

$ docker images
REPOSITORY                   TAG    IMAGE ID       CREATED         SIZE
petitviolet/sample-webapp    1.0    5032e8dc5fa9   1 minutes ago   800MB

ちなみにこの際にdocker buildで使用するDockerfileがtarget/docker/stage配下に生成されていて、中を見るとこうなっている。

FROM openjdk:latest
LABEL MAINTAINER="petitviolet <mail@example.com>"
WORKDIR /opt/docker
ADD opt /opt
RUN ["chown", "-R", "daemon:daemon", "."]
EXPOSE 8080
USER daemon
ENTRYPOINT ["bin/main"]
CMD []

ADDするoptディレクトリ内には起動用のshellスクリプト(bin/main)と、依存ライブラリ(lib)が入っている。

ENTRYPOINTについて

実行可能なmainクラスが1つしかなければ、target/docker/stage/opt/docker/bin/mainに実行ファイルが置かれる。
そのためENTRYPOINT ["bin/main"]となっていて動くようになっている。

複数のmainクラスが存在した場合、たとえばnet.petitviolet.MainServerとnet.petitviolet.MainClientみたいにあった場合、
target/docker/stage/opt/docker/bin/配下にmain-serverとmain-clientという2つの実行ファイルが配置される。
しかし、ENTRYPOINTはbin/mainを動かそうとするため、docker runするとコケてしまう。

これに対する解決策は2つある。

mainクラスを指定する
- mainClass in Compile := Some("net.petitviolet.MainServer")とすれば、bin/mainで実行可能
ENTRYPOINTを指定する
- dockerEntryPoint := List("bin/main-server")として実行するファイルを決め打ちする

前者の方が実行ファイル名に意識を向けなくてもよいため楽でいいが、ローカルで複数のmainクラスを動かしたい時にrunMainしないといけなくて面倒になる。
一方で後者は実行ファイル名に意識を向ける必要があってちょっと歪になってしまうかも。
mainClassの指定もdockerEntryPointの指定も、文字列でミスっていた場合にはdocker runするまでわからないため、ミスの怖さは同等。

ローカルで起動する

普通にdocker run -dすればデーモン起動する。

$ docker run -d -p 8080:8080 --name sample petitviolet/sample-webapp:1.0
9fc179ccfc37b654d766b1eeda944e5f17e29d6b1d51ea08c2322eabc873ba8b

$ docker ps
CONTAINER ID        IMAGE                           COMMAND             CREATED             STATUS              PORTS                    NAMES
9fc179ccfc37        petitviolet/sample-webapp:1.0   "bin/main"          7 seconds ago       Up 1 second         0.0.0.0:8080->8080/tcp   sample

リクエストを送ってみる。

$ curl 'localhost:8080/index?key=value' -A hoge
param: Map(key -> value), user-agent: hoge}

普通に標準出力に垂れ流しているアプリケーションログはdocker logsをすれば見ることが可能。