9

I am trying to run a sonarqube app on the AWS fargate platform. When I run the raw docker image it works like a charm. But If I pass the JDBC properties to the container as an argument I am facing the following issue. Apparently, the elastic search needs a new config. If it is an ECS cluster I would have ssh into the EC2 instances and update these properties. In the case of fargate, how do I achieve this?

max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]

Karthikeyan
  • 2,634
  • 5
  • 30
  • 51

2 Answers2

12

From the github issue seems like it not possible as there is no EC2 instance or Host ivolvole in Fargate.

the workarounds for the max_map_count error appear to be setting max_memory_map directly on the host (which may result in undesirable side effects, or using the sysctl flag on on the docker run command. Unfortunately, neither of these options are not supported in Fargate since it involves interacting with the container instance itself.

But the other way is to increase file limit and disable mmap check.

I had to properly configure U limits on my ECS task definition, something like:
"ulimits": [
  {
    "name": "nofile",
    "softLimit": 65535,
    "hardLimit": 65535
  }
]

I've disabled mmap in ElasticSearch, which gets rid of the max_map_count setting requirement. This can be done by configuring the sonar.search.javaAdditionalOpts SonarQube setting. I wasn't able to do it with an environment variable since ECS seems to be eating them, but in the end I just passed it as a parameter to the container, which works since the entrypoint is set and consumes arguments properly. In my case:

"command": [
  "-Dsonar.search.javaAdditionalOpts=-Dnode.store.allow_mmapfs=false"
]

sonarqube disable nmap

Adiii
  • 54,482
  • 7
  • 145
  • 148
  • 3
    Thanks for saving my weekend ;-) – Karthikeyan Jul 12 '20 at 15:27
  • 2
    Been banging my head against the keyboard over this, THANK YOU! – Brian Antonelli Oct 15 '20 at 14:37
  • doesn't work for es 5.3, any other workaround? – Huan Jiang Feb 24 '21 at 04:15
  • 1
    To make the multi node Fargate deployment working I had to disable the memory mapping with: node.store.allow_mmap=false Still not sure how good that can be and will it reflect the performance but at least the Elasticsearch Cluster is starting now. – moo Nov 29 '21 at 09:21
  • 1
    This property has changed to "node.store.allow_mmap". `org.sonar.process.MessageException: Property 'node.store.allow_mmapfs' is no longer supported. Use 'node.store.allow_mmap' instead.` – Yash Digant Joshi Nov 08 '22 at 05:43
1

Adding the variable discovery.type = single-node under the "Environment Variables" section (edit the es container) in the task definition resolved the issue for me. If you're using the json file, then add the following section

"environment": [
        {
          "name": "discovery.type",
          "value": "single-node"
        }
      ],

Unfortunately, I don't know why that worked.

grandmaestr
  • 139
  • 4
  • This worked for me too. I did try both approaches for use with ECS using Fargate. I span up a single container today on my machine without the ulimit set, and this was enough to get me across the line. – Baza86 Nov 22 '21 at 16:17
  • When you set `single-mode`, then ELK will ignore `cluster.publish.timeout`. Maybe it's related with this behavior or some kind of actions when ELK instance search additional nodes. [Elastic.co > Discovery mode](https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-discovery-settings.html) – Jacek Labuda May 17 '22 at 17:59