About James docker images

[Matthieu Baechler <ma...@apache.org>]

Hi,

I'm currently reworking the way we build our docker images to use jib
(see https://github.com/GoogleContainerTools/jib)

Today, the building of our images requires too many steps:

   1. we build an image in which we install the right maven version

   2. we then use this image to run maven and we mount directories to
   retrieve the built artifacts

   3. we finally build images that will contain artifacts built at step
   2 and some configuration files

With jib, we can do step 2 and 3 at the same time: maven knows the
modules and their dependencies and jib uses that model to create a slim
docker image containing the right artifacts.

It should brings us:

   * smaller images
   * faster build
   * an easier build process

While working on that topic, I wondered why we embed configuration
files into the image and the answer I came with is: we want the image
to do something by default.

We failed at one thing: it actually doesn't work by default because we
ask the user to create a keystore before building the image.

So my proposal is the following:

   1. publish the conf directory as a volume in docker to make it clear
   we expect the user to override the default configuration

   2. bundle sample configuration files that actually allows the
   service to start without any customization step (and that means
   disabling TLS by default or auto-generate an auto-signed
   certificate)

   3. make it clear in the documentation that images work by default
   for testing but further configuration is required for production
   usage

Obviously, every feedback is welcome about that.

Cheers,

-- 
Matthieu Baechler



---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: About James docker images

[Benoit Tellier <bt...@linagora.com>]

Hello Mathhieu,

Thanks for these nice proposals

Having easy-to-override docker images seems like a good idea to me.

Also, JIB looks promissing. Do you have results/experiments to share on
that topic?

I believe there is another topic. Currently docker images are shipped
under **linagora** organization. I do believe releases should be shipped
under **apache** organization (https://hub.docker.com/u/apache/). We
should invest on that topic too.

Regards,

Benoit

On 13/05/2019 21:38, Matthieu Baechler wrote:
> Hi,
>
> I'm currently reworking the way we build our docker images to use jib
> (see https://github.com/GoogleContainerTools/jib)
>
> Today, the building of our images requires too many steps:
>
>    1. we build an image in which we install the right maven version
>
>    2. we then use this image to run maven and we mount directories to
>    retrieve the built artifacts
>
>    3. we finally build images that will contain artifacts built at step
>    2 and some configuration files
>
> With jib, we can do step 2 and 3 at the same time: maven knows the
> modules and their dependencies and jib uses that model to create a slim
> docker image containing the right artifacts.
>
> It should brings us:
>
>    * smaller images
>    * faster build
>    * an easier build process
>
> While working on that topic, I wondered why we embed configuration
> files into the image and the answer I came with is: we want the image
> to do something by default.
>
> We failed at one thing: it actually doesn't work by default because we
> ask the user to create a keystore before building the image.
>
> So my proposal is the following:
>
>    1. publish the conf directory as a volume in docker to make it clear
>    we expect the user to override the default configuration
>
>    2. bundle sample configuration files that actually allows the
>    service to start without any customization step (and that means
>    disabling TLS by default or auto-generate an auto-signed
>    certificate)
>
>    3. make it clear in the documentation that images work by default
>    for testing but further configuration is required for production
>    usage
>
> Obviously, every feedback is welcome about that.
>
> Cheers,
>

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org