Create Docker image

[nathanweeks]

It would be convenient for consistent deployment on Windows, Mac, Linux, and production servers to provide an official gigwa Docker image. I cobbled together the following example; there is room for improvement (e.g., it would be better for the Dockerfile to first build from source as part of a multi-stage build):

Example Dockerfile

FROM tomcat:8.5-alpine

RUN wget http://southgreen.fr/sites/southgreen.fr/files/uploads/gigwa_releases/Gigwa_V2.0-RC2_Webapp.zip && \
    unzip Gigwa_V2.0-RC2_Webapp.zip && \
    sed -i.orig '/defaultMongoHost/s/127.0.0.1/mongo/' \
        Gigwa_V2.0-RC2_Webapp/gigwa/WEB-INF/classes/applicationContext-data.xml && \
    mv Gigwa_V2.0-RC2_Webapp/gigwa /usr/local/tomcat/webapps && \
    rm -rf Gigwa_V2.0-RC2_Webapp Gigwa_V2.0-RC2_Webapp.zip

Example docker-compose.yml:

version: '3.7'

services:
  tomcat:
    image: gigwa:2.0-RC2
    ports:
      - 8080:8080
    links:
      - mongo
    restart: always
    
  mongo:
    image: mongo:4.0
    restart: always
    command: --slowms 60000 --storageEngine wiredTiger --wiredTigerCollectionBlockCompressor=zlib
    expose:
      - 27017

volumes:
  mongo:

Build docker image & start:

$ docker build -t gigwa:2.0-RC2 .
...
$ docker-compose up

Gigwa is then available at http://localhost:8080/gigwa

[GuilhemSempere]

Many thanks for this excellent initiative. I will mention it in the Gigwa homepage.

[nathanweeks]

I noticed the promising addition of a Dockerfile to the git repo. It currently requires build artifacts COPY'ed from the build context, and there appears to be no separate Dockerfile to generate these build artifacts. Could the developer instructions described in the README.md be materialized in the form of a multi-stage build to generate these build artifacts? This might be facilitated by adding the external repos as git submodules.

That should make it easier for others to contribute and deploy (as the provisional docker-compose file assumes a private or non-existent image).

Thanks!

[GuilhemSempere]

Hi! Actually the required artifacts are not meant to be generated using another Dockerfile but via Maven. The pom.xml defines a "docker" profile that when invoked runs dockerfile-maven-plugin to directly generate the Docker image. And yes the dockerhub repo is still private, I will make it public as soon as v2.3 will be out (probably in march). Then Docker packaging will be officially supported and you may expect everything to work smoothly ;-)

[GuilhemSempere]

As of v2.3 (march 25th, 2020), please refer to the project homepage to be able to use Gigwa as a Docker container.

[nathanweeks]

Apologies for raising this issue again. The recent Log4Shell vulnerability prompted me to revisit Java web apps I've deployed. The guilhemsempere/gigwa:2.4.1-RELEASE container image doesn't appear to be vulnerable (at least per docker scan from Docker Desktop for Mac 4.3.2), but it does use an old base image (tomcat:8.5-alpine, which hasn't been updated in over 3 years, as OpenJDK releases are not officially Alpine (docker-library/tomcat#166)).

It could be useful to provide a Gigwa Dockerfile that captures the complete image build process, so users who deploy Gigwa in their as part of their infrastructure are more capable of addressing security vulnerabilities in a timely manner per their institution's IT security policies (and more easily debug issues & contribute bug fixes). Here's an example multi-stage Dockerfile that uses a maven base image base image to build 2.4.1-RELEASE, and copies the resulting webapp into a (newer) tomcat:<version>-slim base image for deployment:

https://github.com/PeanutBase/Gigwa2/blob/8897c0e5f3fbc323c5e6bd81500907fa0d50053b/Dockerfile

Aside from formalizing a reproducible image build, the above Dockerfile documents a couple cases where it appears that dependencies require backported patches to install a required transitive dependency (note that I'm inexperienced with Maven, and there may be a more elegant way of accomplishing this). Alternatively, to facilitate development and provide a greater degree of control over dependencies, the direct dependencies that maintained in the SouthGreenPlatform GitHub organization as part of this project could be added to the Gigwa repository as git submodules (instead of using curl to fetch tarballs from GitHub).

Thanks for continuing to maintain this project!

[GuilhemSempere]

I must admit that packaging the application is neither the funniest part to me, nor the one I'm most comfortable with. So there is probably much that can be done to improve the current situation. Your contribution is thus much appreciated.

In your case I agree that switching to an official and recent Tomcat image makes much sense, but when I think about people who might want to use Gigwa on their laptop, they would probably be glad to keep it as small as possible (weight is possibly more important than security in that case). Maybe this could become a parameter?

I see your point regarding the possibility of being able to build the image without installing Maven. I had a look at the example you provided, it works neatly but I see a problem with having each dependency version hardcoded in there (I really don't want to spend time tuning that for each new release). I played with git submodules as you suggested and did indeed manage to get a directory hierarchy containing all pom.xml files with a single git pull. However, I'm still not sure how this would help getting the correct version for each dependency. Also, ideally the Dockerfile contents would need to include a generic command able to build those dependencies in the right order, starting with the deepest subfolder (otherwise we could still explicitly define the build order by issuing a list of mvn install commands).

To make it brief, if you can help sorting out the dependency version issue, I'll be glad to consider switching to a solution that suits you better.