Systemd is a system and session manager for Linux operating systems, introduced as the default init system in Fedora 17 and Red Hat Enterprise Linux 7. It replaced the traditional SysVinit and Upstart init systems, providing faster boot times and more efficient resource usage.

Systemd manages the runtime behavior of a Linux system, starting and stopping services, managing processes, and handling various other system administration tasks. It provides a drop-in replacement for the traditional init daemon and offers many additional features such as mounting file systems, setting up automount points, managing sockets and devices, and more.

Running Elastic Search as a Docker containers on a Linux system managed by Systemd offers several additional advantages:

  1. Easy container management: Systemd makes it easy to manage the lifecycle of Docker containers as part of the system’s startup process. You can create Systemd service files for each Docker container and define how they should be started, stopped, restarted, and reloaded. This ensures that your containers are automatically started when the system boots up or when specific events occur.
  2. Integration with system resources: By running Docker containers under Systemd, you can ensure that your containers have access to essential system resources such as network interfaces, file systems, and environment variables. This is particularly useful for long-running services that require consistent access to these resources.
  3. Automatic failure recovery: Systemd provides automatic failure recovery of services, including Docker containers. If a container fails or crashes, Systemd can automatically restart it based on the service unit file configuration, ensuring high availability and minimal downtime.
  4. Graceful shutdown: When shutting down the system, Systemd can send graceful signals to running Docker containers, allowing them to cleanly stop and save any necessary data or perform orderly shutdown procedures. This helps prevent unexpected data loss or corruption.
  5. Better integration with system logs and notifications: By using Systemd to manage your Docker containers, you can easily integrate container logs with the system’s logging infrastructure. Additionally, you can use Systemd notifications to be alerted when specific events occur within your containers.
  6. Simplified configuration management: Managing Docker containers under Systemd makes it simpler to configure and deploy applications as part of a larger system or infrastructure. This is particularly useful in production environments where consistent configuration and reliable service availability are important.

Assuming that Elastic Search was launched as a Docker container with some really common options like so:

docker run --name es --user elasticsearch:elasticsearch -v /es/data:/data -v /es/repo:/backup -p 9200:9200 -p 9300:9300 -e "discovery.type=single-node" -e "cluster.name=bamboo-cluster" -e "node.name=bamboo-cluster-single-node" -e 'http.cors.enabled=true' -e 'http.cors.allow-origin="*"' -e "http.cors.allow-headers: Authorization,Origin,Content-Type,Accept,X-Requested-With" -e 'xpack.security.enabled=false' -e 'path.repo=["/backup"]' -e 'path.data=/data' -e ES_JAVA_OPTS="-Xms4g -Xmx4g" docker.elastic.co/elasticsearch/elasticsearch:8.5.3

With an explanation of the different switches below:

  • --name es: This option sets the name of the container to “es”. You can use this name later to refer to the container in other commands or scripts.
  • --user elasticsearch:elasticsearch: This option sets the user under which the Elasticsearch container should run. In this case, it is set to the default Elasticsearch user (elasticsearch:elasticsearch).
  • -v /es/data:/data: This option mounts a local directory (/es/data) as a data volume inside the container at the path /data. This allows persistent data storage for Elasticsearch indexes and configurations.
  • -v /es/repo:/backup: Similar to the previous option, this command mounts another local directory (/es/repo) into the container as a backup volume at the path /backup.
  • -p 9200:9200: This option binds port 9200 on the host machine to port 9200 inside the container. Elasticsearch usually listens on this port for HTTP requests.
  • -p 9300:9300: This option also binds port 9300 on the host machine to port 9300 inside the container. This is the default transport client connection port in Elasticsearch.
  • -e "discovery.type=single-node": This environment variable sets the discovery type of the Elasticsearch cluster to “single-node”, meaning it will not form a distributed cluster and will run as a standalone instance.
  • -e "cluster.name=bamboo-cluster": This option sets the name of the Elasticsearch cluster to “bamboo-cluster”. Cluster names are used to identify and manage clusters in multi-node configurations.
  • -e "node.name=bamboo-cluster-single-node": This environment variable sets the node name inside the cluster to “bamboo-cluster-single-node”. Each node in a cluster has a unique name.
  • -e 'http.cors.enabled=true': Enables Cross-Origin Resource Sharing (CORS) support for Elasticsearch, allowing it to respond to requests coming from different origins than the one it is running on. -e 'http.cors.allow-origin="*"': This option sets the allowed CORS origins to “”, meaning all origins are allowed to access Elasticsearch.
  • -e "http.cors.allow-headers: Authorization,Origin,Content-Type,Accept,X-Requested-With": These environment variables set the list of headers that are allowed in CORS requests. *-e 'xpack.security.enabled=false': Disables Elastic Stack Security features, such as encryption at rest and role-based access control, to save resources and simplify the setup. *-e 'path.repo=["/backup"]': Sets the backup repository path to “/backup”. This is used by Elasticsearch for storing its snapshots during backup operations. *-e 'path.data=/data': Sets the data directory path to “/data”, which was already mounted as a volume earlier in this command. *-e ES_JAVA_OPTS="-Xms4g -Xmx4g": This environment variable sets the Java heap size for Elasticsearch, allocating 4GB of heap space (-Xms4g is the minimum heap size and -Xmx4g is the maximum heap size).

A Systemd unit file for managing Elastic Search could be the following:

# Unit configuration for managing the ElasticSearch Docker container

# Description of this unit
[Unit]
Description=Manage starting the ElasticSearch Docker container
After=docker.service       # Start this service only after the docker service is up and running
Requires=docker.socket      # Ensure that the Docker socket is available

#--------------------------------------------------
# Service configuration
[Service]

# Always restart the service if it crashes or fails
Restart=always

# Keep the container running after the process terminates
# This is important because Docker will return command immediately after
# launching the container and will not block. Were it not for this line
# Systemd would bail out of the service immediately.
RemainAfterExit=yes

# Attach to the existing Docker container named es.
ExecStart=/bin/sh -c 'docker start --attach es'
# Stop the existing Docker container named es.
ExecStop=/bin/sh -c 'docker stop --time 10 es'

# Wait until ElasticSearch is up and running before moving on to other processes (downstream dependencies)
# This can be essential if any downstream Systemd services depend on the Elastic Search server being
# already up and running by the time they themselves are launched by Systemd.
ExecStartPost=/bin/sh -c 'curl --silent --head --fail --retry 16 --retry-delay 2 --retry-all-errors http://localhost:9200'

#--------------------------------------------------
# Install configuration
[Install]
WantedBy=default.target

Need help with properly setting up Elastic Search? Contact us at www.snowlinesoftware.com for help.