Can't deploy Sonarqube 8.5 to Azure Kubernetes

Report a bug
#1

I’m able to deploy Sonarqube 8.3 and 8.4.1, but attempting to use the 8.5 docker image to deploy into Azure Kubernetes gives the following error on container startup:

2020.10.14 12:53:11 ERROR web[][o.s.s.p.PlatformImpl] Web server startup failed
java.lang.IllegalStateException: Fail to unzip plugin [python] /opt/sonarqube/lib/extensions/sonar-python-plugin-3.1.0.7619.jar to /opt/sonarqube/data/web/deploy/plugins/python
        at org.sonar.server.plugins.ServerPluginJarExploder.explode(ServerPluginJarExploder.java:60)
        at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
        at java.base/java.util.HashMap$ValueSpliterator.forEachRemaining(HashMap.java:1675)
        at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
        at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
        at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913)
        at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
        at java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578)
        at org.sonar.server.plugins.ServerPluginManager.extractPlugins(ServerPluginManager.java:87)
        at org.sonar.server.plugins.ServerPluginManager.start(ServerPluginManager.java:66)
        at org.sonar.core.platform.StartableCloseableSafeLifecyleStrategy.start(StartableCloseableSafeLifecyleStrategy.java:40)
        at org.picocontainer.injectors.AbstractInjectionFactory$LifecycleAdapter.start(AbstractInjectionFactory.java:84)
        at org.picocontainer.behaviors.AbstractBehavior.start(AbstractBehavior.java:169)
        at org.picocontainer.behaviors.Stored$RealComponentLifecycle.start(Stored.java:132)
        at org.picocontainer.behaviors.Stored.start(Stored.java:110)
        at org.picocontainer.DefaultPicoContainer.potentiallyStartAdapter(DefaultPicoContainer.java:1016)
        at org.picocontainer.DefaultPicoContainer.startAdapters(DefaultPicoContainer.java:1009)
        at org.picocontainer.DefaultPicoContainer.start(DefaultPicoContainer.java:767)
        at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:136)
        at org.sonar.server.platform.platformlevel.PlatformLevel.start(PlatformLevel.java:90)
        at org.sonar.server.platform.platformlevel.PlatformLevel2.start(PlatformLevel2.java:112)
        at org.sonar.server.platform.PlatformImpl.start(PlatformImpl.java:213)
        at org.sonar.server.platform.PlatformImpl.startLevel2Container(PlatformImpl.java:179)
        at org.sonar.server.platform.PlatformImpl.init(PlatformImpl.java:87)
        at org.sonar.server.platform.web.PlatformServletContextListener.contextInitialized(PlatformServletContextListener.java:43)
        at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4689)
        at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5155)
        at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
        at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1412)
        at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1402)
        at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
        at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: java.io.IOException: Failed setLastModified on /opt/sonarqube/lib/extensions/sonar-python-plugin-3.1.0.7619.jar
        at org.apache.commons.io.FileUtils.setLastModified(FileUtils.java:2561)
        at org.apache.commons.io.FileUtils.doCopyFile(FileUtils.java:1400)
        at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:885)
        at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:835)
        at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:802)
        at org.sonar.server.plugins.ServerPluginJarExploder.explode(ServerPluginJarExploder.java:56)
        ... 33 common frames omitted
2020.10.14 12:53:12 INFO  web[][o.s.s.a.EmbeddedTomcat] HTTP connector enabled on port 9000
2020.10.14 12:53:12 INFO  web[][o.s.p.ProcessEntryPoint] Hard stopping process
2020.10.14 12:53:12 INFO  app[][o.s.a.SchedulerImpl] Process[web] is stopped
2020.10.14 12:53:13 INFO  app[][o.s.a.SchedulerImpl] Process[es] is stopped
2020.10.14 12:53:13 WARN  app[][o.s.a.p.AbstractManagedProcess] Process exited with exit value [es]: 143
2020.10.14 12:53:13 INFO  app[][o.s.a.SchedulerImpl] SonarQube is stopped
1 Like
No languages after clean sonarqube:8.4.0-developer Docker install?
#2

Hi @Brian_Balderston ,

while this is not officially supported, i will try my best to help you on this one.

there was a recent change in the way plugins are handled in sonarqube. what kind of storage is underneath your PVs and what PVCs do you have in your deployment?

#3

It’s using an Azure StorageV2 file share. I’ve attached the kubernetes deployment yaml (with the actual SONAR_JDBC_ values removed).sonarqube-k8.txt (1.6 KB)

#4

I’m hitting the same.

#5

I was able to install sonar in Azure AKS but with a lower sonarquebe image (mage: sonarqube:7.1). followed this post.

#6

Hello…

Did you find any solution?

#7

Hello everyone :wave:

i currently do not have a AKS cluster to validate this but can you look for a PodSecurityPolicy set that enforces a ReadOnlyRootFilesystem ?

we were reworking our plugins to have a fixed version of our analyzers be deployed with each release of sonarqube, so the stack trace indicates that there is a tried file operation to all analyzers in /opt/sonarqube/lib/extensions/ that is denied by said PSP.
The workaround would be to create a PVC for this directory and mount it in there (please be careful as all language analyzers are in there so copy the files to this new PVC) or to write a PSP that does not enforce a ReadOnlyRootFilesystem and start sonarqube in a pod that uses this new PSP.

Hope that helps

#8

Hi…

The default value for readOnlyRootFilesystem is false. But I put it under securityContext anyway. I also tried fsGroup: 1000 changing the folder group to sonarqube. I also tried runAsUser: 1000 and runAsGroup: 1000.

Nothing above works.

But the problem happens only when unzipping to the folder /opt/sonarqube/data/web/deploy/plugins/python. I can see other files within /opt/sonarqube/data. And the volume mapped to /data was originally empty. Therefore, the folder has write permission.

Log: Failed to unzip the [python] /opt/sonarqube/lib/extensions/sonar-python-plugin-3.1.0.7619.jar plugin to /opt/sonarqube/data/web/deploy/plugins/python

The same default Yaml configuration (without any of the changes above) works well with version 8.4.2.

If I change the version to 8.6.0 after a start the Sonarqube once with 8.4.2 version, it works fine. I guess that que data folder was alredy initialized by the 8.4.2 version.

#9

Hi…

Creating the volumes using PersistentVolumeClaim do the trick. Works well with version 8.6.

The problem is actually related to the use of the storage account (file sharing).

Would be interesting see why previous version works fine with file share and 8.6 don’t. File share has some advantages, so much so that was the first choice of many people in this thread.

#10

I have the same issue, but with another plugin (CSS):
Fail to unzip plugin [cssfamily] /opt/sonarqube/lib/extensions/sonar-css-plugin-1.3.1.1642.jar to /opt/sonarqube/data/web/deploy/plugins/cssfamily
.

.
Caused by: java.io.IOException: Failed setLastModified on /opt/sonarqube/lib/extensions/sonar-css-plugin-1.3.1.1642.jar

Before I dive into creating beautiful new PV’s and PVC’s, I want to get something cleared up first.

My impression from the logfile is that the failure is occurring on the ‘/opt/sonarqube/lib/…’ path, not on the ‘/opt/sonarqube/data/…’ path. The former is part of the docker image right???

When I examine my file-store in Azure, I see that the ‘sonar-css-plugin-1.3.1.1642.jar’ is present in the expected path there…
My hunch is that the unzip works fine, but the ‘setLastModified’ on the source jar (present in the docker image) fails…

I think that the ‘solution’ of creating a persistent opt/sonarqube/lib/… storage and then manually copying data from the image into that share is a bit convoluted…

Thank you for listening!

#11

Where might I find the analyzers as used by/included for SonarQube 8.6 developer?

#13

@Tobias_Trabelsi Do you think this issue would be fixed in the next version of SonarQube?