Add a section on setting vm.max_map_count

[roborourke]

On Ubuntu and other Linux systems the ElasticSearch container is in production mode which requires the Docker VM setting vm.max_map_count to be a minimum of 262144.

https://www.elastic.co/guide/en/elasticsearch/reference/current/docker.html#_set_vm_max_map_count_to_at_least_262144

[hm-linter]

Linting failed (4 errors).

4 notices occurred in your codebase, but none on files/lines included in this PR.

[roborourke]

Props to @kadamwhite for running into this and persevering with debugging via slack.

[hm-backport]

The backport to v3-branch failed:

Commits ["ff545eba8f348be2e0730a33a60d8d79bdb1b732"] could not be cherry-picked on top of v3-branch

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub.
git fetch
# Create new working tree.
git worktree add .worktrees/backport v3-branch
# Navigate to the new directory.
cd .worktrees/backport
# Cherry-pick all the commits of this pull request and resolve the likely conflicts.
git cherry-pick ff545eba8f348be2e0730a33a60d8d79bdb1b732
# Create a new branch with these backported commits.
git checkout -b backport-160-to-v3-branch
# Push it to GitHub.
git push --set-upstream origin backport-160-to-v3-branch
# Go back to the original working tree.
cd ../..
# Delete the working tree.
git worktree remove .worktrees/backport

Then, create a pull request where the base branch is v3-branch and the compare/head branch is backport-160-to-v3-branch.

[joehoyle]

Hmm how come we are running ES in prod mode in those cases? Can we change that?

[roborourke]

@joehoyle it’s nothing we’re doing, there’s something to do with the way docker engine runs when it’s on Linux - I’m not sure we can control it. I’ll look into it though as I agree - this is also going to affect the Travis environment