XDOCKER-282: Update the process to use an external Solr instance

[GridexX]

Description:

In an effort to streamline and standardize the Solr instance configuration process, this PR introduces a Dockerfile that will automatically place and decompress the necessary JAR files to create default cores.

Previously, the process required manual intervention and user guidance, which can leads to be inconsistent due to variations in documentation across different platforms. By implementing a Dockerfile, this variability is eliminated and improve overall usability.

Here are the key benefits of this Dockerfile:

1. Enhanced Kubernetes compatibility: XWiki services start to operate in a Kubernetes environment. This Dockerfile aligns with the existing infrastructure, avoiding any additional setup or initInstallation steps needed to configure an external Solr instance in Kubernetes. This would drastically facilitate the deployment process.

2. User-friendly: The end user experience is significantly improved as they no longer have to follow complex instructions. They can now simply download the Docker image and it's ready to use.

3. Efficient maintenance: The upkeep of this Dockerfile is straightforward. With each new plugin release, we just need to update the respective version in the Dockerfile, keeping our Solr instance up-to-date.

By making this shift, we're prioritizing simplicity, consistency, and improved user experience. As always, feedback and suggestions for improvement are welcome.

[vmassol]

Note that the tabs were added voluntarily as otherwise it failed the validation on dockerhub official images.

Now, it's true that since then, we've moved away from putting the doc there and we just link to our doc from https://hub.docker.com/_/xwiki

However, if we want to change this, we need an agreement. Not sure it's the best place to do it in this PR. WDYT?

[GridexX]

My formatter change it when I'd save the page and rewrite the summary from the title. I will redo the changes.
Nevertheless, I think it could need a refresh to check if it matches the correct title.

I will leave it as before for now

[vmassol]

missing license header

[vmassol]

And metadata

[vmassol]

This also means that we need to publish this images (and we need to get the agreement from the official image maintainers). I don't see the code or doc to publish this image in the files changed. Maybe I've missed it.

[vmassol]

I don't think this will pass validation as it doesn't do any checksum validation. See the main Dockerfile.

[vmassol]

Thanks @GridexX! I've left a few comments. Sounds like some good improvements.

[GridexX]

Thank you for your great review, @vmassol, which has shed light on our current Docker image and Solr configuration practices.

I've gained a deeper understanding of our templates folder and its crucial role in generating the variety of XWiki images, each designed for a specific database and neatly structured within version-specific folders. While this methodology was likely advantageous during its inception, I believe the continuous evolution in CI/CD practices has opened doors for further optimization.

A particular area that stands out for enhancement is the manual generation of 256 Checksums. This process is not only time-intensive but also prone to potential errors - an area that automation could significantly improve.

To address this, I suggest we leverage the powerful CI/CD features offered by GitHub within our main XWiki platform repository. GitHub's functionalities can efficiently automate and simplify workflows like ours. Here are my proposals:

• Automated Docker build and push: Implementing a GitHub Action that automatically builds our Docker images and pushes them to the Docker registry will save us time and minimize manual errors. You can learn more about Docker's GitHub Actions here.

• Integration with GitHub and Docker Registry: We can employ GitHub's native Docker integration to push our images directly to the Docker registry, thus enhancing our workflow efficiency.

• Versioned Releases based on XWiki Product: By leveraging GitHub's release feature, we can automate the creation and deployment of Docker images corresponding to each new XWiki product release. This will ensure our users always have access to the most updated versions.

Please note that while these suggestions aim to significantly streamline our Docker image creation process, they fall outside the scope of this PR. Therefore, I propose we explore these as separate initiatives within the main XWiki platform repository.

As for the Solr setup, it seems its unique characteristics necessitate a different approach from our conventional database setup. I'm in the process of identifying the most uncomplicated and effective solution. I would be grateful for any thoughts or suggestions you might have on this.

[vmassol]

Automated Docker build and push: Implementing a GitHub Action that automatically builds our Docker images and pushes them to the Docker registry will save us time and minimize manual errors. You can learn more about Docker's GitHub Actions here.

Yes, we already use a GH Action for automatically building our docker build image at https://github.com/xwiki/xwiki-docker-build/blob/master/.github/workflows/build.yml

Please note that while these suggestions aim to significantly streamline our Docker image creation process, they fall outside the scope of this PR. Therefore, I propose we explore these as separate initiatives within the main XWiki platform repository.

I agree that the scope is different than this PR. I like your ideas/proposals and I would encourage you to repost this (maybe with some specific details of how it would work) on the XWiki forum at https://forum.xwiki.org/

As for the Solr setup, it seems its unique characteristics necessitate a different approach from our conventional database setup. I'm in the process of identifying the most uncomplicated and effective solution. I would be grateful for any thoughts or suggestions you might have on this.

Right now, our Gradle build only handles the construction of the XWiki Dockerfile for various environments (XWiki on top of Tomcat but with various DBs). It could be modified to also construct the XWiki Solr image (from the Dockerfile you provided) for the various versions of XWiki (only based on the version and not the DB). Then we could update the dockerhub official image file at https://github.com/docker-library/official-images/blob/master/library/xwiki and add several entries for the XWiki Solr image.

WDYT?

[GridexX]

The other related PR: #36

[vmassol]

Then we could update the dockerhub official image file at https://github.com/docker-library/official-images/blob/master/library/xwiki and add several entries for the XWiki Solr image.

I've asked at docker-library/official-images#15069

[GridexX]

@vmassol Thanks ! The build.gradlew have been updated, it's ready to go

[be-mot]

Hi, I ran into this one today ...
Any news on when this will be merged ?

Thanks in advance !

[vmassol]

Hi, I ran into this one today ... Any news on when this will be merged ?

Thanks in advance !

In the meantime please follow https://github.com/xwiki/xwiki-docker/blob/master/README.md#using-an-external-solr-service