klaros-testmanagement / klaros-docker Goto Github PK

As these versions tend to be removed quickly we should rely on the major version only.

For accessing systems using self-signed certificates via HTTPS/LDAPS the Root-CA of these certificates have to be added to the cacerts keystore which is not writable at the moment.

The JVM security folder should be available on a separate volume (jvm-security) to allow changing the contents via the keytool application.

Hi there, would you have any interest in having pre-built images available, either on Docker Hub or here on Github? The latter is super simple to set up and I would be more than happy to provide a PR with the relevant changes to the Github Actions workflow.

How I see it:

• You create the release/tag on this repository when you are ready for a new release
• Workflow kicks in to build the Klaros containers (only the Klaros application Dockerfiles, not the Database ones) and pushes them to the container registry here
• The images can automatically be tagged correctly, i.e ghcr.io/klaros-testmanagement/klaros-docker:v5.3.0-databaseType (and even a plain klaros-docker:databaseType which is always the latest available for that type)

I started thinking about this yesterday when I was building/rebuilding the container locally - and each time it had to download the setup.jar file, which could take upwards of 20/30 mins - might also prevent your bandwidth from being hammered when pesky people like me are constantly building the image ;)

I already took a look at simplifying the workflow file yesterday: https://github.com/PromoFaux/klaros-docker/actions/runs/1342274759/workflow

With a couple of tweaks, it can be made to also upload that image to the GitHub Container Registry, see here for an example of where I have done this on another project:

https://github.com/pi-hole/docker-base-images/blob/master/.github/workflows/ftl-build.yml#L48-L61

Edit: Working example https://github.com/PromoFaux/klaros-docker/pkgs/container/klaros

Starting with Klaros 5.0, hibernate.dialect is no longer a required parameter. It should be removed from the scripts.

Hello,

This is a really serious problem. There is no way to avoid data loss if you are currently using the Microsoft SQL Server database. This should be fixed in 4.12.4.2

How to save your data?
Please keep always a copy of your backup!

To whom fate has now hit that he uses the SQL version and the 4.12.4.1 release. There is a way how you can still save your data.

First, you create a volume backup.
Then you update to tag 4.12.4.2 (it doesn't matter if you create the volume backup afterwards).
Shut down your containers with docker-compose down.
Delete your volume: docker volume rm klaros-data
Create your new image and start a new clean server: docker-compose up --build
Terminate the server with CTRL + C
Open the directory /data/mssql-data/ in your backup file and delete all files EXCEPT klaros.mdf and klaros_log.ldf.
Restore your backup.
Now you should be able to use your server as usual.

If anything didn't work, please let me know.

Both databases still have their default collation set to latin1.

PostgreSQL/klaros/files/catalina-wrapper.sh contains this line:

echo "hibernate.connection.url = jdbc:postgresql://db/${DATABASE_NAME}"

that db is actually the hostname, which klaros will use to connect to the database. This just happens to work since docker-compose.yml spins a container with that name.

However, its no good if the image is used by some other orchestrator, Kubernetes in my case, and/or when the database is to reside on some generic postgresql server, ie. a database cluster or so.

I suggest adding a DATABASE_HOST environment variable with default value db to the klaros Dockerfile. Then its possible to specify something else.