[
https://issues.apache.org/jira/browse/TIKA-1518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16390284#comment-16390284
]
Dave Meikle edited comment on TIKA-1518 at 3/7/18 9:41 PM:
-----------------------------------------------------------
It is a choice we have to make. There are three mains routes to Docker
packaging that I have used:
# Automated builds that pull in pre-packaged and then get bundled into an
image on any change in the an repository - like what we are doing n
docker-tikaserver approach where is goes and downloads the signed JARs
# Automated builds that compile the code in the image (e.g. using the maven
Docker image) and then package them
# Building a release image and then distributing that - which is what this
does but requires us to decide when an official release is available and push
it somewhere
The first and second are really good for leveraging things like Docker Hub to
automatically build from your repository, where as the third means you have to
have Docker on your machine when you want to build an image.
I never really like number two as it means the builds are always recompiles of
the code each time a change is triggered, so you can easily be packing up
different code as the same version without realising it.
The challenge with the approach in docker-tikaserver is maintaining when assets
that are being pulled in move - i.e. when an release JAR is move from
dist.apache.org - but that could easily be solved by going to Nexus for the
JARs based on the release packages.
I personally quite like the third approach as it means you explicit create an
image that has its own life and was thinking that we could potentially add this
to the release process, pushing the image from the release build to Docker
Hub/Nexus/Another Repos so it is an official build. So just like when we do a
mvn release we can go to tika-server and do a mvn dockerfile:build and if happy
mvn dockerfile:push (once we bottom out where).
Not sure what others think?
was (Author: davemeikle):
It is a choice we have to make. There are three mains routes to Docker
packaging that I have used:
# Automated builds that pull in pre-packaged and then get bundled into an
image on any change in the an repository - like what we are doing n
docker-tikaserver approach where is goes and downloads the signed JARs
# Automated builds that compile the code in the image (e.g. using the maven
Docker image) and then package them
# Building a release image and then distributing that - which is what this
does but requires us to decide when an official release is available and push
it somewhere
The first and second are really good for leveraging things like Docker Hub to
automatically build from your repository, where as the third means you have to
have Docker on your machine when you want to build an image.
I never really like number two as it means the builds are always recompiles of
the code each time a change is triggered, so you can easily be packing up
different code as the same version without realising it.
The challenge with the approach in docker-tikaserver is maintaining when assets
that are being pulled in move - i.e. when an release JAR is move from
dist.apache.org - but that could easily be solved by going to Nexus for the
JARs based on the release packages.
I personally quite like the third approach as it means you explicit create an
image that has its own life and was thinking that we could potentially add this
to the release process, pushing the image from the release build to Docker
Hub/Nexus/Another Repos so it is an official build.
Not sure what others think?
> Docker with Tika Server
> -----------------------
>
> Key: TIKA-1518
> URL: https://issues.apache.org/jira/browse/TIKA-1518
> Project: Tika
> Issue Type: New Feature
> Reporter: Paul Ramirez
> Assignee: Dave Meikle
> Priority: Major
> Fix For: 2.0, 1.17
>
> Attachments: tika-server-docker-err-msg.txt
>
>
> This version should be able to demonstrate as many of Apache Tika's
> capabilities as possible. For instance with GDAL, Tesseract, and FFmpeg to
> show parsers which require installation of other dependencies. In addition,
> this should help move TIKA-1301 forward and should leverage the suggestion
> made by [~lewismc] of a script which can pull down the latest version of
> Apache Tika.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
