Skip to content

Elasticsearch #2139

Description

@MickLesk

Name of the Script

Elasticsearch

Script Type

CT (LXC Container)

Does this script support arm64?

arm64 supported

📋 Script Details

Single-node Elasticsearch from the official Elastic repository. Requested in discussion #5074.

The open question from the earlier assessment — vm.max_map_count in an unprivileged LXC — is resolved. Per Elastic's docs, bootstrap checks are only warnings in development mode (loopback binding) but hard failures in production mode (non-loopback), and an LXC is only useful bound to the LAN. However vm.max_map_count is not namespaced: the container inherits it from the Proxmox host. So it cannot and need not be set inside the container.

The script therefore checks the inherited value and aborts with an actionable message if it is too low:

vm.max_map_count is <n>, Elasticsearch needs at least 262144
Set it on the PROXMOX HOST, not in this container:
  echo 'vm.max_map_count=1048576' >/etc/sysctl.d/99-elasticsearch.conf && sysctl --system

In practice this passes: systemd has defaulted to 1048576 since v255, and Proxmox 9 is well past that.

  • setup_deb822_repo against artifacts.elastic.co/packages/9.x/apt (verified HTTP 200), JAVA_VERSION="21" setup_java.
  • discovery.type: single-node, network.host: 0.0.0.0, data relocated to /opt/elasticsearch_data.
  • Security on, TLS off — authentication is enabled so the node is not wide open, but HTTP stays plain so it is usable on a LAN without certificate juggling. Flagged as a warning.
  • No credentials file (anti-pattern 14); the CT footer prints the elasticsearch-reset-password command instead.
  • Heap pinned to 1 GB in jvm.options.d/heap.options.

Source: https://www.elastic.co/elasticsearch

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions