Updating SonarQube via docker compose

SonarQube
,
1

Hi community,

I’m using SonarQube Developer 9.3.0, installed via Docker - using docker-compose.yml according to the example in documentation. Then, we’re booting it up with docker-compose up -d

I’ve been having issues updating it. There is information about it in documentation, but it explains only manual stoping/removing the container, etc. As there are no additional notes about docker compose, I thought just swapping Docker image tags in docker-compose file and executing again docker-compose up -d would be sufficient - according to the Docker Documentation, that would essentially do the same thing:

If there are existing containers for a service, and the service’s configuration or image was changed after the container’s creation, docker-compose up picks up the changes by stopping and recreating the containers (preserving mounted volumes).

This method worked first few times without any issues, but yesterday I ended up with completely ruined / damaged database indexes and SonarQube was not able to start… Logs showed tons of error stack trace, but the main exception I guess is this:

failed to merge org.apache.lucene.index.CorruptIndexException: checksum failed (hardware problem?)

Luckily we’ve created a snapshot earlier, so we could just roll back to the previous VM state and not even tried to fix the issue (as we already had once issue with db indexes being destroyed just by rebooting VM).

Can someone explain me what could be the problem in my approach or what should be the proper way to update SonarQube? This is already 2nd time in 4 months I’ve managed to destroy the db :see_no_evil:

Thanks,
Paula

1 Like
2

Hi Paula,

It sounds like a problem, not with the DB but with the Elasticsearch indexes. Can you delete them and try starting again?

 
Ann

3

Hi Ann,

Thank you for your answer.

Unfortunately, I cannot tell, as I used the VM snapshot to immediately reverse to the previous (working) state.
Could you please tell me if the way I update SonarQube is ok, or is there another preferred way to update?

Thanks in advance!

BR,
Paula

4

Hi, I have the same problem. I also use Docker-Compose to host Sonarqube and wanted to update the containers today. The Sonarqube container sonarqube:community built 6 days ago doesn’t start anymore and gives the error: org.apache.lucene.index.CorruptIndexException: checksum failed (hardware problem?) The error is also thrown by the ElasticSearch database as described here, so I already tried to delete the directory es7 in the data volume of the container so that this is recreated on startup. Unfortunately this does not solve the problem. Are there any other things I can try? If you want, I can post the whole stacktrace here.

5

Also getting this issue after SonarQube updated their docker to alpine 3.15.3.

If you build your own SonarQube docker (9.3.0 or 9.4.0 I’ve tested) on alpine 3.15.2, you should be unblocked.

1 Like
6

FYI another thread about this issue here: Zlib 1.2.12 getting corruption errors - #4 by warkolm - Elasticsearch - Discuss the Elastic Stack

7

I was also experiencing the same issue after upgrading to sonarqube:9.4-developer image.

The reason is probably the same, as in @dm-ion link - I run the container under VM on xcp-ng (PVHVM mode) but AFAIK I can’t change cpu type for the VM.

Building custom image with alpine 3.15.2 worked ok for me :wink:

8

In my post I only referenced the latest alpine version. The SonarQube docker is on the 3.14 line, so for our docker of SonarQube I’ve been using 3.14.2 to be consistent with what SonarQube has been using. No reason to believe this would be any different then 3.15.2 for SonarQube, but going with what they’ve tested.

So any alpine version after (and including) these you may have some Zip CRC issues, or issues with elastic search checksums it seems:
3.12.11
3.13.9
3.14.5
3.15.3

9

So, looks like the root of the problem is updated zlib library to v1.2.12 in the alpine images, which changes are then reflected in rebuilt docker images of sonarqube?

I am also running Sonarqube via Docker inside a VM on a Proxmox server - suggested solution is to change the CPU type to Haswell - does anyone know what are consequences of this? I am also running some other services on the same VM at the moment… Is this indeed an intended behavior from zlib or should this be fixed from their side for kvm64 CPU architecture type?

Thanks in advance!

10

Hi looks like this will be fixed in a newer version of the SonarQube docker when they update alpine or if they force updating of zlib. The alpine folks have updated ZLib to include a patch for this issue and pushed to the 3.15 repo and I can confirm it works.

So to do this you simply copy paste the SonarQube Dockerfile, upgrade alpine to 3.15.4, then add this command:
RUN apk upgrade zlib

Correct incorrect inputs provided to the CRC functions. · madler/zlib@ec3df00 (github.com)

aports - Alpine packages build scripts (alpinelinux.org)

1 Like
11

Fast forward… It’s been now more then 2 months, here is even an issue on GitHub about this topic: No longer able to run sonarqube:9.3.0-community · Issue #544 · SonarSource/docker-sonarqube · GitHub

We know that solution to problem is updating zlib library to 1.2.12-r1. However, I’m not keen on writing my own Docker image just bcos of this. So, I ask here the same question as it was asked on GitHub (above): Is this one-line fix going to be implemented from Sonarsource (@ganncamp ), or we have to take care of it? Or I have to make a pull request on my own on GitHub?

Best regards,
Paula

14

Hi all,

Sorry for the late reply, and delay in dealing with this. This should have been fixed with 9.5. Furthermore, we were also waiting on Alpine to publish a new version of 3.15 which would include some other fixes as well. I’ll update our base image today. This will be part of the upcoming 9.6 version.

15

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.