'Official' Play framework Docker Container

[Mark Moore]

I asked this question in the contrib gitter channel but it might be better suited to here.

Has there been any discussion about having an official play framework docker container?

I think it would serve a few purposes

1. lower the barrier to entry to deploying a play app (which may not be that high at the moment but every little helps), any service that will take a docker container will now be able to deploy a play app without the user needing to know much more than how to point the service at their repo (elastic beanstalk for example)
2. give existing play users an easier entry point into the world of containers by having a reference Dockerfile that completes a process they are probably currently doing manually
3. if you avail of dockers official image service thing https://docs.docker.com/docker-hub/official_repos/ the play image will be the first one found when people search hub.docker.com for images instead of a collection of probably good but maybe abandoned or unreliably maintained options 

a huge amount of open source projects maintain official images (https://github.com/docker-library/official-images/tree/master/library).

[Rich Dougherty]

I don't know too much about Docker, so I've got a couple of questions. I'm assuming you're talking about using a Docker image for deployments, not for everyday development tasks.

1. At the moment Play supports Docker through an sbt-native-packer Docker plugin: http://www.scala-sbt.org/sbt-native-packager/formats/docker.html. If we made an official Play image, would we just reference this image in the sbt-native-packer Docker settings? I.e. http://www.scala-sbt.org/sbt-native-packager/formats/docker.html#docker-base-image.

2. Play currently uses sbt-native-packer to build itself as a standard Java application, with all JARs bundled. The only dependency needed by a Play distribution is Java. Would we move some of the dependencies into the Docker image and then change the Play build so it excludes these dependencies when it targets Docker?

Cheers

Rich

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/151fe81d-4f59-4b2c-b0ee-e28ee2839e79%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Rich Dougherty

Engineer, Typesafe, Inc

@richdougherty

[Mark Moore]

Thanks for the reply.

So you could use it for everyday development tasks but I think plays development story is good as it is so yes I think it should focus on the deployment story.  I am open to correction on any of the following.

1. I am going to say yes but I don't know much about that plugin.  I have a feeling that plugin might become superfluous with a well set up docker image but I could be wrong.

2.  There is an advantage to moving as many dependancies to the docker image as possible and that is that docker will share an image across any containers extending it.  So on a system wth many play containers running this should result in more efficient disk usage at least although that is probably not that important for most users.

I think these are the advantages I have in mind

1. having a reference 'default' system implementation ready for production.  env variables can be set for various settings in the base image and if people know what they are doing they can override them but if they don't need or want to finely tune their system they know they have a great production ready starting point.
2. Docker makes it easy to add my own customizations to the set-up I add a Dockerfile to the root of my project which extends the official one and I add my configuration while getting all the basics and whatever fine tuning is in the official image for free.  These customizations might be users, or packages or whatever else you want on your system be it related to play or not.
3. the ci / cd process could be 'ready to go', you make a code change and you push, some ci server pulls the change and runs your tests, and if they pass, builds your jar and then pings production to pull the update and production runs the container with a 'prod' flag and it uses the jar.  most of that (what command runs the tests, what command builds the jar, what command starts the play app on prod) can be built into the container so that someone does not have to go find each of those commands in the docs separately and put their own deployment script together unless they want to.
4. You get all the above and the ability to deploy anywhere that will take a docker image

[Steven Marcus]

Using docker during development used to be difficult, especially on the Mac, because of the need to expose your sources directory.

Looks like recent releases of Docker have made this easier.

For an idea of how other people are using Docker during development: http://jhipster.github.io/installation.html

Having all your dependencies, including DB, dockerised, makes onboarding new developers much faster...