Reputation: 4502
I have a Play application(built with Scala) that I am trying to run on Docker container.
The following are the parts of docker-compose.yml and build.sbt I am using to spin up a container to run the sbt command.
↓ docker-compose.yml
version: '3.7'
services:
service-name:
entrypoint: >
sh -c 'cd /root/project_dir && sbt service/run'
volumes:
- ./project:/root/project_dir/project
- ./service_src:/root/project_dir/service_src
- ./build.sbt:/root/project_dir/build.sbt
- ./.ivy2/:/root/.ivy2/
- ./.sbt/:/root/.sbt/
↓ build.sbt
lazy val service = project
.in(file("./service_src"))
:
)
When I start a container with this setting, for some reason I end up getting the following error
[error] java.nio.file.NoSuchFileException: /root/.ivy2/cache/org.webjars.npm/wrappy/jars/wrappy-1.0.2.jar
which actually exists in the cache.
Where should I look into to figure out what could cause this?
Update:
From observation, I have figured out that mounting the Windows host directory in the container seems to be causing the problem.
Instead of mounting, copying the files/directories via docker copy
eliminates the error...
How can I achieve the same using the volumes or it this something that cannot be done?
Upvotes: 0
Views: 791
Reputation: 2566
You don't need to copy the .sbt
and .ivy2
dirs.
I advise to use sbt native packager so it would create an image for you, instead of reinventing the wheel:
Add addSbtPlugin("com.typesafe.sbt" % "sbt-native-packager" % "1.3.18")
to a file called project/plugins.sbt
.
Then in your build.sbt
add .enablePlugins(JavaAppPackaging, DockerPlugin)
to your project:
lazy val service = project
.in(file("./service_src"))
:
).enablePlugins(JavaAppPackaging, DockerPlugin)
You can change the image settings with sbt configuration:
dockerExposedPorts := Seq(9000)
dockerBaseImage := "openjdk:8-jre"
version in Docker := "1.0.0"
In order to build an image on your computer, run sbt docker:publishLocal
.
You can see the created docker image by running sbt docker:stage
.
See the documentation for further help, or ask here.
See the Alpine section if you want to run your app with Alpine (lightweight Linux distribution).
Upvotes: 2
Reputation: 7275
The problem might be related to access rights used within docker image.
Check that the file does exist and can be read manually with a bash/shell from within container.
docker-compose run service-name sh
Or if container is running
docker-compose exec service-name sh
This should yield sh
command line and run
ls -al /root/.ivy2/cache/org.webjars.npm/wrappy/jars/wrappy-1.0.2.jar
Check that file exists and what rights are assigned to it.
If rights are not the problem, do your debug within shell of the container.
Upvotes: 1