Docker fails to build container

[LKay]

I set up the docker build in my build.sbt according to docs but it fails to build the docker container. What is wrong?

my build.sbt:

import org.scalatra.sbt.ScalatraPlugin
import sbt._
import sbt.Keys._

lazy val ScalatraVersion = "2.4.0-RC2-2"
lazy val root = (project in file("."))
  .enablePlugins(DockerPlugin)
  .settings(ScalatraPlugin.scalatraSettings)
  .settings(
    organization  := "com.domain",
    name          := "my-project",
    version       := "1.0.0",
    scalaVersion  := "2.11.6",
    scalacOptions ++= Seq("-feature", "-language:postfixOps"),

    resolvers     ++= Seq(
      Classpaths.typesafeReleases,
      "Scalaz Bintray Repo" at "http://dl.bintray.com/scalaz/releases",
      "amateras-repo" at "http://amateras.sourceforge.jp/mvn/",
      "Apache Maven Central Repository" at "http://repo.maven.apache.org/maven2/"
    ),

    libraryDependencies ++= Seq(
      "org.scalatra"            %% "scalatra"                 % ScalatraVersion,
      "org.scalatra"            %% "scalatra-auth"            % ScalatraVersion,
      "org.scalatra"            %% "scalatra-specs2"          % ScalatraVersion % "test",
      "org.json4s"              %% "json4s-jackson"           % "3.3.0.RC1",
      "org.scalaz"              %% "scalaz-core"              % "7.1.3",
      "jp.sf.amateras"          %% "scalatra-forms"           % "0.1.0",
      "org.scalamock"           %% "scalamock-specs2-support" % "3.2" % "test",
      "io.spray"                %%  "spray-json"              % "1.3.2",
      "com.typesafe.slick"      %% "slick"                    % "3.0.0",
      "com.github.tminglei"     %% "slick-pg"                 % "0.9.0",
      "net.databinder.dispatch" %% "dispatch-core"            % "0.11.2",
      "org.fluentd"             %% "fluent-logger-scala"      % "0.5.1",

      "com.amazonaws"           % "aws-java-sdk"      % "1.9.31",
      "ch.qos.logback"          % "logback-classic"   % "1.1.3" % "runtime",
      "org.eclipse.jetty"       % "jetty-webapp"     % "9.2.10.v20150310" % "container",
      "javax.servlet"           % "javax.servlet-api" % "3.1.0" % "provided"

    ),

    dockerBaseImage := "java",
    maintainer in Docker  := "test",
    packageName in Docker := name.value,
    version in Docker     := version.value,
    dockerExposedPorts in Docker := Seq(8080)
  )

and error when I try to build it in my docker:

bash-3.2$ sbt docker:publishLocal
[info] Loading project definition from /Users/me/Documents/Projects/api/v2/project
[info] Set current project to service-api (in build file:/Users/me/Documents/Projects/api/v2/)
[info] Sending build context to Docker daemon 2.048 kB
[info] Sending build context to Docker daemon 
[info] Step 0 : FROM java
[info]  ---> 49ebfec495e1
[info] Step 1 : MAINTAINER test
[info]  ---> Using cache
[info]  ---> 775bef652a9a
[info] Step 2 : WORKDIR /opt/docker
[info]  ---> Using cache
[info]  ---> 23ef37128b67
[info] Step 3 : ADD opt /opt
[error] opt: no such file or directory
java.lang.RuntimeException: Nonzero exit value: 1
    at com.typesafe.sbt.packager.docker.DockerPlugin$.publishLocalDocker(DockerPlugin.scala:288)
    at com.typesafe.sbt.packager.docker.DockerPlugin$$anonfun$projectSettings$14.apply(DockerPlugin.scala:106)
    at com.typesafe.sbt.packager.docker.DockerPlugin$$anonfun$projectSettings$14.apply(DockerPlugin.scala:105)
    at scala.Function4$$anonfun$tupled$1.apply(Function4.scala:35)
    at scala.Function4$$anonfun$tupled$1.apply(Function4.scala:34)
    at scala.Function1$$anonfun$compose$1.apply(Function1.scala:47)
    at sbt.$tilde$greater$$anonfun$$u2219$1.apply(TypeFunctions.scala:40)
    at sbt.std.Transform$$anon$4.work(System.scala:63)
    at sbt.Execute$$anonfun$submit$1$$anonfun$apply$1.apply(Execute.scala:226)
    at sbt.Execute$$anonfun$submit$1$$anonfun$apply$1.apply(Execute.scala:226)
    at sbt.ErrorHandling$.wideConvert(ErrorHandling.scala:17)
    at sbt.Execute.work(Execute.scala:235)
    at sbt.Execute$$anonfun$submit$1.apply(Execute.scala:226)
    at sbt.Execute$$anonfun$submit$1.apply(Execute.scala:226)
    at sbt.ConcurrentRestrictions$$anon$4$$anonfun$1.apply(ConcurrentRestrictions.scala:159)
    at sbt.CompletionService$$anon$2.call(CompletionService.scala:28)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
[error] (docker:publishLocal) Nonzero exit value: 1
[error] Total time: 1 s, completed Jul 31, 2015 6:21:16 PM

[muuki88]

You are not using any archetype. So currently nothing is packaged. Replace DockerPlugin with JavaAppPackaging . This will enable the DockerPlugin and configure your build package.

[brianlow]

I hit this too because DockerPlugin is mentioned in the docs under Required Settings

[muuki88]

@brianlow what would have helped you to solve this issue on your own? The getting started guide doesn't mention the DockerPlugin.

[brianlow]

This section confused me on the docker page:

• The heading above indicates DockerPlugin is required. However, I can remove enablePlugins(DockerPlugin) from my build.sbt and still run sbt docker:publishLocal. It doesn't appear to be required so I'd remove this section.

• Perhaps instead it should mention that you need to enable an archetype if all archetypes work with docker. If not, list the archetypes that do work.

Some of my problem was just being new. I didn't understand formats vs archetypes. Also I started on the Docker page rather than Getting Started Guide since that was more specific to my goal.

[muuki88]

The heading above indicates DockerPlugin is required.

And it is. The JavaAppPackaging simply depends on it, because it supports building docker images. Thus sbt enables the DockerPlugin automatically. If you want to generate a custom configuration without an archetype and build a docker image you have to enable the plugin manually.

It doesn't appear to be required so I'd remove this section.

This is a crucial part of the more detail documentation, when you want to customize things and get deeper into native-packager.

Perhaps instead it should mention that you need to enable an archetype if all archetypes work with docker

Only the JavaAppPackaging archetype works with docker. The JavaServerAppPackaging depends on JavaAppPackaging, but doesn't add anything useful to docker.

Also I started on the Docker page rather than Getting Started Guide since that was more specific to my goal

The getting started page is always a good point to start as the name suggests ;)

[brianlow]

👍

[seglo]

I agree with @brianlow . I just wanted to quickly dockerize my Scala app without considering the other packaging it is doing under the hood. I had no idea that JavaAppPackaging depended on DockerPlugin, in fact I assumed it would have been the reverse. The docker documentation leads you down the path of adding DockerPlugin without even mentioning JavaAppPackaging.

I would recommend adding a short paragraph explaining this to the docker docs.

[muuki88]

@seglo thanks for your input :)

I would love to merge a pull request adding this small paragraph to the docker, debian, rpm, universal and windows section. This question comes up far too often and adding this little piece of extra information hopefully does the trick.

[joan38]

Thanks for this, I was confused too

[ljwagerfield]

Also hit this issue, but this thread cleared it up for me.

I would agree with @brianlow and @seglo too; I think a lot of people will be landing on the "Docker Plugin" webpage: you do a Google search for sbt docker:publishLocal and it's the first thing that pops up. When you read through the page, it implies all you need to do is add enablePlugins(DockerPlugin) and then sbt docker:publishLocal should work. The error is also quite confusing, although that might be harder to address than updating the documentation.

I think what's technically correct and what's useful aren't always going to be the same thing. It might not be technically correct to put a hint: on that page, but I think it will do more good than bad (I think).

[muuki88]

@ljwagerfield Adding a hint is definitely a good start. Do you have the time to make a pull request for this? If you need guidance, feel free to ask 😄