[REQUEST] Specify a reference Dockerfile which is tested in CI

[e-lo]

Is your feature request related to a problem? Please describe. I was frustrated with getting the validator up and running. I'd like to have a reproducible environment specified that "just works".

Describe the solution you'd like

1. A Dockerfile for a reference environment which is tested in the CI suite.
2. A docker-compose with setup for the simple UI

Describe alternatives you've considered

• More step by step instructions with special instructions for every hardware/software/data combination issue
• More time spent troubleshooting individual hardware situations

Additional context Some discussion in : https://github.com/MobilityData/gtfs-validator/issues/383

[ghost]

Thks for the very good suggestion.

While we haven't tried that on our side just yet, it is our understanding that any linux image with a Java 11 (at a minimum) setup should be able to run the validator.

[barbeau]

FYI, the gtfs-validator could probably use a very similar Dockerfile to gtfs-realtime-validator (swapping Maven for Gradle), which is here: https://github.com/CUTR-at-USF/gtfs-realtime-validator/blob/master/Dockerfile

We also have a Docker image built on each commit and pushed to Docker Hub so it can be easily pulled and run - see the docs here: https://github.com/CUTR-at-USF/gtfs-realtime-validator#docker

[ghost]

We need to merge #421 before having this on master but the first image is already available at https://github.com/orgs/MobilityData/packages/container/package/gtfs-validator

Note that a new image will be tagged and visible on the same page for subsequent PRs (snapshot versions) as well as released version.

As mentioned in the updated documentation on #395 , the validator .jar is usable directly from the root directory of the container

Let us know if that satisfies your request

[e-lo]

This is great. Some suggestions to provide flexibility to those who want to manage their code updates either via DockerHub or GitHub Clone:

1. Maintain a Dockerfile in the repo base which you push to Docker Hub. ( similar to what @barbeau said he did for rt)
2. Maintain a docker-compose.yml file to setup the simple web UI

Ultimately this information isn't "only" held in the GitHub action.

[ghost]

Maintain a Dockerfile in the repo base

Said file is in the list of changes in the linked PR to copy the cli app jar to the root folder of the Docker container https://github.com/MobilityData/gtfs-validator/pull/395/files#diff-3254677a7917c6c01f55212f86c57fbf

which you push to Docker Hub.

For simplifying setup and maintenance on our side, using the integrated GitHub Container Registry tool seems to provide similar functionality to Docker Hub. Our CI pushes an image on the GitHub Container Repository: https://github.com/MobilityData/gtfs-validator/actions/runs/281471068/workflow#L57 I actually considered the Docker Hub, created an account on our shared internal reserved shared email address... then realized we'd have to create an organization inside Docker Hub and potentially have to manage a whole set of new employees/collaborators in their system. As opposed to have it handled by what we already have in place in GitHub It didn't seem worth the investment given what we perceive as going from docker pull mobilitydata/gtfs-validator:master
to docker pull ghcr.io/mobilitydata/gtfs-validator:master

(add ghrc.io in front of the organization name). This command is visible on the Github Container Registry Package page

The Github Container Registry Package page is linked in the updated documentation: https://github.com/MobilityData/gtfs-validator/pull/395/files#diff-04c6e90faac2675aa89e2176d2eec7d8R19

Is there anything we're missing?

Maintain a docker-compose.yml file to setup the simple web UI

The web UI being still not merged on master (we don't have all the tests we need), I'll stay high level or the mixing of both subjects details could make the conversation quite complex IMHO

The server-spring-boot and client-react modules will be packaged as a single war file. Please see the documentation update here: https://github.com/MobilityData/gtfs-validator/pull/365/files#diff-04c6e90faac2675aa89e2176d2eec7d8R129

To mimic what was done with rt, we intent to use an entrypoint in the Dockerfile : https://github.com/CUTR-at-USF/gtfs-realtime-validator/blob/7352c5c0ac8276a79723dceccbe0861feb624333/Dockerfile#L9 pointing to the war copied in the container in a similar fashion that is done in the linked PR

We do not intend to spin services up in a docker stack at this point, which is our understanding of the use of a docker-compose file, but maybe those can be used to pass commands inside the container itself and spin up trhe server and client react web app?

We do wonder if we should provide one image with both the CLI and the web app setup with an entry point. It seems dubious as the web server process would eat resources otherwise available for the command line executable. We could either do that and document instruction to stop the web server inside the container before invoking the cli app jar OR Provide two distinct Docker images on our package page via the GitHub Container Registry

It will be decided before merging #395 on master but we certainly welcome any opinions at this stage

[barbeau]

We do wonder if we should provide one image with both the CLI and the web app setup with an entry point.

Couldn't you just add two JAR files (one for CLI and one for web server) to the same Docker image? And then the user could execute whichever they want from the comand-line?

The only additional resources this would require would be the additional JAR in the image, but I can't imagine the JAR for the web server is that big.

[ghost]

Couldn't you just add two JAR files (one for CLI and one for web server) to the same Docker image? And then the user could execute whichever they want from the comand-line?

Yes that would be easy but I think the idea was for the end user not to have to run any command inside the container to have the web ui available

[ghost]

We could either do that and document instruction to stop the web server inside the container before invoking the cli app jar

After discussion, we will go in that direction of providing a single image containing both jar with instructions to stop the web server.

[ghost]

@e-lo Can we assume our answer is to your satisfaction regarding the Dockerfile and the absence of a docker-compose file?

[e-lo]

Yup! Thanks for checking!